4 ms·

>their fork is designed to allow a system to be started even if the /usr/ directory hasn't been mounted yet. What a terrible reason to fork. This feature is us

by oofabz 14y ago

>their fork is designed to allow a system to be started even if the /usr/ directory hasn't been mounted yet. What a terrible reason to fork. This feature is useless. Putting /usr/ on a separate filesystem made sense 20 years ago when storage capacities were small, but not anymore. On Fedora, /bin, /sbin, and /lib are symlinks to their counterparts in /usr. I applaud them for this effort to simplify Unix and move away from cargo cult ritual.

dfc 14y ago
Is cargo cult the correct term? I have never seen it used to mean "doing things a certain way because they have always been done that way."
- secure 14y ago
  http://en.wikipedia.org/wiki/Cargo_cult_programming http://en.wikipedia.org/wiki/Cargo_cult_programming says: Cargo cult programming is a style of computer programming that is characterized by the ritual inclusion of code or program structures that serve no real purpose. Cargo cult programming is typically symptomatic of a programmer not understanding either a bug he or she was attempting to solve or the apparent solution (compare shotgun debugging, voodoo programming).[1] The term cargo cult programmer may also apply when an unskilled or novice computer programmer (or one not experienced with the problem at hand) copies some program code from one place and pastes it into another place, with little or no understanding of how the code works, or whether it is required in its new position. I think that applies here.
  - yankcrime 14y ago
    So we're saying that every Unix and Unix-like implementation in recent times that supports and indeed advocates [1] placing /usr, /tmp, /var, and so on on seperate filesystems have done so because the developers are unskilled novices with no understanding or experience of the problem at hand? Sorry, I think it's entirely the wrong term. [1] http://www.openbsd.org/faq/faq4.html#Partitioning http://www.openbsd.org/faq/faq4.html#Partitioning
    - oofabz 14y ago
      Yes, that is what I'm saying. Security: Adding a layer of security on a per-filesystem basis is not sufficient or necessary. It is only conceivably useful as a backup plan when the actual security system has failed, and at that point it is not sufficient to prevent compromise. Stability: Quotas are a superior solution. Speed: Not an issue for /usr, which is rarely written to. Integrity: We have journaled filesystems now. If you lose a filesystem it is almost certainly because the device has gone bad and needs to be replaced. For last-ditch system recovery, an initrd solution like Dracut works better, since it can solve problems involving the root partition. Size: Modern computers can boot from any size partition. fsck: Preventing fsck is no longer useful. It doesn't take an hour like it used to. If there was a power interruption I would prefer to fsck all my filesystems anyway.
  - dfc 14y ago
    For the purposes of this discussion I am assuming that the traditional FHS with multi partitions is useless and or detrimental feature. Not something I agree with but for the sake of argument... How then do you differentiate between legacy cruft and cargo cult?
mst 14y ago
> What a terrible reason to fork. Sure, but as qznc's comment makes clear there's quite a few things udev have done that together count as sufficient reason for the eudev authors. > This feature is useless. Running out of space on /usr tends to be significantly less obnoxious than running out of space on /. So it's not entirely useless; whether it's worth the additional complexity is a separate matter that I don't have a considered opinion on.
alexlarsson 14y ago
1) Udev doesn't do anything about separate /usr, its systemd that does. Both are in the same source tree but unrelated at runtime(i.e. udev can be used without systemd). 2) systemd only prints a warning about separate /usr, it then continues to go on as before, so it does not affect this working or not. 3) The reasons that separate /usr are broken is not because of systemd, but the other parts of the system that rely on things in /usr in early boot. This happens in a variety of cases where services or hw support code rely on binaries in /usr/bin or data in /usr/share. Nothing you change in udev or systemd can make this work better, its all about fixing the rest of the system, something nobody cared to do for the 10 years before systemd added the warning to tell people of this problem.
JoachimSchipper 14y ago
I have no opinion on this fork, but note that keeping /usr separate shields valuable hand-edited configuration data (/etc, sometimes /root) from problems with the (much larger, and therefore more likely to suffer from e.g. bad sectors) /usr. (The usual "/bin, /sbin are statically linked, /usr/bin, /usr/sbin are dynamically linked" also makes it much easier to recover from some problems. Of course, putting stuff in /usr/etc/ or dynamically linking /bin makes these benefits moots - but that would be Doing It Wrong.)

by oofabz 14y ago

dfc 14y ago

Is cargo cult the correct term? I have never seen it used to mean "doing things a certain way because they have always been done that way."

secure 14y ago
http://en.wikipedia.org/wiki/Cargo_cult_programming http://en.wikipedia.org/wiki/Cargo_cult_programming says: Cargo cult programming is a style of computer programming that is characterized by the ritual inclusion of code or program structures that serve no real purpose. Cargo cult programming is typically symptomatic of a programmer not understanding either a bug he or she was attempting to solve or the apparent solution (compare shotgun debugging, voodoo programming).[1] The term cargo cult programmer may also apply when an unskilled or novice computer programmer (or one not experienced with the problem at hand) copies some program code from one place and pastes it into another place, with little or no understanding of how the code works, or whether it is required in its new position. I think that applies here.
- yankcrime 14y ago
  So we're saying that every Unix and Unix-like implementation in recent times that supports and indeed advocates [1] placing /usr, /tmp, /var, and so on on seperate filesystems have done so because the developers are unskilled novices with no understanding or experience of the problem at hand? Sorry, I think it's entirely the wrong term. [1] http://www.openbsd.org/faq/faq4.html#Partitioning http://www.openbsd.org/faq/faq4.html#Partitioning
  - oofabz 14y ago
    Yes, that is what I'm saying. Security: Adding a layer of security on a per-filesystem basis is not sufficient or necessary. It is only conceivably useful as a backup plan when the actual security system has failed, and at that point it is not sufficient to prevent compromise. Stability: Quotas are a superior solution. Speed: Not an issue for /usr, which is rarely written to. Integrity: We have journaled filesystems now. If you lose a filesystem it is almost certainly because the device has gone bad and needs to be replaced. For last-ditch system recovery, an initrd solution like Dracut works better, since it can solve problems involving the root partition. Size: Modern computers can boot from any size partition. fsck: Preventing fsck is no longer useful. It doesn't take an hour like it used to. If there was a power interruption I would prefer to fsck all my filesystems anyway.
- dfc 14y ago
  For the purposes of this discussion I am assuming that the traditional FHS with multi partitions is useless and or detrimental feature. Not something I agree with but for the sake of argument... How then do you differentiate between legacy cruft and cargo cult?

mst 14y ago

> What a terrible reason to fork. Sure, but as qznc's comment makes clear there's quite a few things udev have done that together count as sufficient reason for the eudev authors. > This feature is useless. Running out of space on /usr tends to be significantly less obnoxious than running out of space on /. So it's not entirely useless; whether it's worth the additional complexity is a separate matter that I don't have a considered opinion on.

alexlarsson 14y ago

1) Udev doesn't do anything about separate /usr, its systemd that does. Both are in the same source tree but unrelated at runtime(i.e. udev can be used without systemd). 2) systemd only prints a warning about separate /usr, it then continues to go on as before, so it does not affect this working or not. 3) The reasons that separate /usr are broken is not because of systemd, but the other parts of the system that rely on things in /usr in early boot. This happens in a variety of cases where services or hw support code rely on binaries in /usr/bin or data in /usr/share. Nothing you change in udev or systemd can make this work better, its all about fixing the rest of the system, something nobody cared to do for the 10 years before systemd added the warning to tell people of this problem.

JoachimSchipper 14y ago

I have no opinion on this fork, but note that keeping /usr separate shields valuable hand-edited configuration data (/etc, sometimes /root) from problems with the (much larger, and therefore more likely to suffer from e.g. bad sectors) /usr. (The usual "/bin, /sbin are statically linked, /usr/bin, /usr/sbin are dynamically linked" also makes it much easier to recover from some problems. Of course, putting stuff in /usr/etc/ or dynamically linking /bin makes these benefits moots - but that would be Doing It Wrong.)