> https://wiki.archlinux.org/index.php/Systemd#Arch_integration > "Warning: /usr must be mounted and available at bootup (this is not > particular to systemd). If your /usr is on a separate partition, you > will need to make accommodations to mount it from the initramfs and > unmount it from a pivoted root on shutdown. See the mkinitcpio wiki > page and freedesktop.org#separate-usr-is-broken" > https://wiki.archlinux.org/index.php/Mkinitcpio#.2Fusr_as_a_separate_partition > http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken The link actually says this has nothing to do with systemd but I think that's lies and the arch post is correct in that it's not just systemd. > I should have read up on this before my previous post! Aside from most of the pro points being incorrect like actually widening the difference between unixes (solaris being a minority), there are things they have overlooked too. _________________________________________________________________________ "we now just expect /usr to be pre-mounted from inside the initramfs, to be available before 'init' starts" _________________________________________________________________________ Well you used to execute /sbin/init and rc scripts after mounting /. so what's the real reason that hasn't been bothered to be mentioned with lennart pointing back to the thread that doesn't mention it. Also Lennart says _________________________________________________________________________ "Now you only have to pull out your rescue CD, if /boot is corrupted and not if / is corrupted." _________________________________________________________________________ Not true, you could always fix some errors but lots of things can not be fixed this way else the kernel/initramfs would be or as large as the filesystem which equates to more ignorance of busybox and embedded. On OpenBSD the critical files are on / and so is the kernel. /usr holds the well audited and so files that almost never need updating. /usr/local holds packages so you can update them whilst reducing the risk of trojaning login or damaging critical filesystems for example. You can easily update and backup the root filesystem too. /usr on Linux is far far more likely to have problems mounting as it is large and heavily used so actually you have made Linux less reliable not more reliable (as lennart argues) just like systemd does to. If it has all these functional bugs that seem to still be appearing and is so difficult to review the code then the only people that are likely to find the security bugs are the criminals and those getting paid many more times than Google pay for bugs in chrome not to mention that those who can find those bugs will not be running and so auditing systemd in any case. The simplicity of controlling the init scripts was a major factor in my choice of arch. The fast updates and simple and secure default stance led me to believe Arch held security highly and which I no longer believe. So as soon as my free time permits (which unfortunately may be a while). I shall have to join Baho in his quest for another OS. The decision to move to systemd actually has very little to do directly with my decision but the manner of the decision process and unbalanced summing up in arch is far more worrying and much more one sided than the summary made by RedHat devs. There may be more developer contention and balance than was dared to be made public, but it is unclear to me. A couple of devs murmured dislike of systemd, a couple made rediculous comments (not you Tom, you got hot headed and a little offensive at times but I understood why) but most devs reacted to lets move to systemd now for an easy life and an easy life has nothing to do with what I strive to achieve. Suggestion for distros without systemd and which hold security or code correctness and little enabled by default are welcome. Tom: Seccomp is only really there for a very particular usage by Google in Chrome. It is far too large grained to add security to daemons. Kc -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
