User talk:Falconindy

Mkinitcpio

And again, why did you just revert my 1KB edit on the hooks section and only leave me as explanation: "Most of this is no longer relevant with new lvm2, and this edit suggests wrong syntax in HOOKS."

• Because it was too much effort to pick out the few decent contributions from the misleading and wrong information. If you don't want to see such large reverts of your work in the future, then don't make such large edits with unrelated content. It's really that simple. Falconindy (talk) 18:25, 4 November 2012 (UTC)

This does not explain to me why unneeded html and other ugly formatting has to stay, why an example line only with the autodetect hook is better than an explanation what it does, why there should be no sentence mentioning that the wrong order can leave the system unbootable, why the unconventional LUKS on LVM is preferable over LVM on LUKS, why removing pata and scsi has a problem if root is on a sata device, [...]! Please be a bit more carefull when reverting edits, a few sentences on a linked talk page won't hurt anyone!

• Sure, feel free to change that. Do not suggest blatantly wrong syntax like "(keymap)" in the HOOKS array. Falconindy (talk) 18:25, 4 November 2012 (UTC)

Trying to understand your explanation above (Most of this is no longer relevant with new lvm2) it came in my mind maybe you meant there is auto-rearrangement done by hooks that fixes in example "wrong" order of encrypt and lvm2. I don't know of that and am not going to look in the code or testing it and maybe having to chroot into an unbootable system. If you know better do appropriate changes but please don't bring back html-formatting! :-)

• Maybe you should keep up with the news before guessing at what might be right and wrong. The new LVM2 package in core and was talked about on the mailing lists and makes ordering for LVM2 irrelevant. Again, if you want to contribute or improve things fine, but do not spread misinformation. Falconindy (talk) 18:25, 4 November 2012 (UTC)

I also noticed that hooks only affecting image generation but not runtime (in example filesystems, ...) obviously can get listed earlier or later than advised in different articles over the arch wiki. However I think it's best to explain that hooks are executed in the order listed and in general it is good practice to list any hooks in a reasonable order.

As said if you know they do not affect runtime this could get neglected but for some of them (like filesystems) you can't know they won't need runtime capabilities in the future and/or are not expanded by users so maybe this is not even worth mentioning?

• The abhorrent table that describes the runtime and buildtime functionality of each hook sort of points out that hooks like filesystems don't have a runtime component. Explaining in a circuitous fashion that some hooks can be ordered differently than others does zero good. Rather, explain the basic concepts and not the applications: what a hook is and what it consists of, and how ordering might affect each component. This would be useful information. Falconindy (talk) 18:25, 4 November 2012 (UTC)

The other part of your explanation (this edit suggests wrong syntax in HOOKS) I think you meant the brackets around keymap and shutdown in the LVM on LUKS example line. It is just said there in the sentence above that the keymap hook is optional and I also think it is self explanatory not to really place those brackets there. However I agree in that this is not good formatting and now tried to solve this using italics (not nice as well I personally think) with my last edit.

If you just wanted to remove the crypto content from the article because you are personally not interested in that feel free to take the Merge-Template for granted. I can do the merge if you would rather delete one and copy the other though ;-) just leave me a message here on your talk-page. Note the example line without autodetect can get removed too. As long as the templates are there this section looks unnecessary strange so I will remove the autodetect line if there comes no veto. As well I will remove the merge template if getting no feedback on this after a week or so. --Nonix (talk) 18:08, 4 November 2012 (UTC)

• I'm not personally interested in duplicating information on the wiki. It belongs to the wiki page about crypto. Falconindy (talk) 18:25, 4 November 2012 (UTC)

base group is assumed to be installed on all Arch Linux systems

... at least according to the note in Arch_Build_System#Build_package, even though you say otherwise. See also https://bbs.archlinux.org/viewtopic.php?id=164891 . -- Karol (talk) 04:30, 15 January 2014 (UTC)

Is this just a semantic distinction over the words "assumed to be installed"?

The pacstrap script installs base by default if no package list is given [1]. The Installation Guide and the Beginner's Guide both instruct the user to install the "base" group.

If we, as AUR package maintainers, cannot assume that the "base" group is installed, depends arrays will get messy quickly or package maintenance will be a headache from having to look at the dependency trees to find the top-level packages to include in the depends arrays, which is why I find this to be disheartening. Do I really need to go through my 40 AUR packages to make sure none of them are missing dependencies on packages in the "base" group?

I don't think Karol and I are unique in thinking that the "base" group is assumed to be installed. Should a message clarifying this issue be sent to the aur-general mailing list?

-- Jstjohn (talk) 06:59, 15 January 2014 (UTC)

There are pros and cons to either situation and I personally don't care if it's decided one way or another (I don't maintain any packages ;P), but I'd like to get this sorted out. -- Karol (talk) 07:56, 15 January 2014 (UTC)

systemd and scripts on boot

I added that section after figuring out how to run scripts at startup through stumbling on this however the tmpfiles method is clearly better. Ironically the example I used doesn't work with tmpfiles as it changes a file under /sys as noted in the Tmpfiles section. If you have a better way to do what was in the example that isn't confusing or onerous to new users (as it is something that they will want to change immediately before they start exploring Arch) I would love for you to add it here; at the moment I'm not well enough versed in Arch to do it any other way. My concern is that it is not at all clear to new users that the tmpfiles method is an option,(I am not the only person who has noticed this). Is there a way to make it clear that users who wish to run things at startup can use the tmpfiles method without having to read the section as there is no reason for a user to think that the "Temporary Files" section has anything to do with running things at startup? Bytefyre (talk) 20:35, 8 February 2014 (UTC)

You can expand Autostarting too. -- Karol (talk) 20:55, 8 February 2014 (UTC)