Very dumb
|
| Author | Content |
|---|---|
| Grishnakh Nov 03, 2011 9:04 PM EDT |
It's really sad to see so much stupidity going on with various premiere Linux distros these days; Ubuntu with their cr@ppy Unity, Gnome3, and now Fedora making this idiotic move. It's common practice in bash and shell scripts for the first line to be #!/bin/sh. There's untold countless scripts out there with this convention hardcoded in them, because it's been customary for so long to have sh in the /bin directory in Unix systems. Now Fedora wants to change this? Stupid. The split between /bin, /sbin, /lib and /usr/bin, /usr/sbin, /usr/lib goes back to the days when hard drives were tiny and it was common for Unix systems to have a local hard drive with only the bare essentials installed on it, and then the rest of the software remotely-mounted. So /bin and friends were on the local drive, while /usr was a mounted volume, or a separate partition, or whatever. In summary, that's the whole reason /usr exists. These days, hard drives are huge, and there's no reason to split up your OS/application files on separate volumes; sure, there's good reasons to have remotely-mounted volumes, or volumes on separate partitions, such as for the /home directory, but not for the system files. So if they want to clean up the directory hierarchy in Linux, the answer isn't to move everything into /usr, the answer is to get rid of /usr altogether: put the binaries in /bin, the system binaries (things only the sysadmin needs to use) in /sbin, the libraries in /lib, etc. This would also preserve the #!/bin/sh convention. |
| dinotrac Nov 03, 2011 9:08 PM EDT |
@grish.... It really riles me up to have to agree with you. It would be nice to see folks move into the 21st century in that regard. Heck, the last part of the 20th. |
| gus3 Nov 03, 2011 9:52 PM EDT |
There is a very good reason to put /usr on its own: system crashes during updates. Leave the root read-only, and it's protected, and available in times of super-critical need (like recovering /usr). |
| Scott_Ruecker Nov 03, 2011 9:57 PM EDT |
Can't we just put everything in the 'C' drive like normal people? ;-) |
| Grishnakh Nov 03, 2011 9:59 PM EDT |
@gus3: Maybe I'm missing something, but I don't see how putting some binaries in /usr protects anything from system crashes during updates. For instance, if your update is updating files in the root, then it obviously can't be read-only, or else you can't update. The only way I can see to really protect the system from corruption caused by crashes during system updates is to have a different kind of filesystem with atomic writes (where basically all the files being updated have to be updated all at once, or not at all); this would probably require huge fundamental changes to our OSes though. We do this kind of thing with version-control systems, but not at the filesystem level itself. |
| gus3 Nov 03, 2011 10:28 PM EDT |
It isn't putting some binaries in /usr that matters; it's keeping some binaries far away from /usr that counts. Things like fsck.*. If something hoses the partition with /usr on it, you don't want your system check/recovery programs on that (hosed) partition, right? |
| Grishnakh Nov 03, 2011 10:58 PM EDT |
Maybe, but in practice, these days most systems have /usr and / on the same partition. I've been running Linux since 1999 and I've always done it that way; I do always keep /home on a separate partition, as well as a separate file storage area called /stor (for movies, music, etc. that's read-only and easily shared over the network), but I've never bothered keeping /usr separate. If something hoses /usr, then I might as well reinstall the system. Why bother trying to repair it? With all the important data in /home and /stor, there's little reason to bother saving the rest of the system when it can be reinstalled in an hour or less. |
| tuxchick Nov 03, 2011 10:59 PM EDT |
You bad Scott. No beer for you. This is a landmark week, I agree with Grishnakh too. |
| mbaehrlxer Nov 04, 2011 12:47 AM EDT |
the separation of / and /usr is going to be harder and harder to achieve and is no longer serving its purpose. more and more stuff is being added to / making it less and less useful to put it on its own device. the stuff that you really need to boot and fix things could almost fit into an initrd. one problem with separating /usr is that it doesn't really solve the problem. you also need to separate /var, /tmp, /srv, /home, /opt and /usr/local, and that's just to many partitions for a desktop system unless you play around with links (i usually put /srv, /home, /opt and /usr/local into /local and /tmp on /var/tmp/root). with all that it becomes easier to just separate /boot and be done with it. my /boot is nowadays just as large as my / partitions used to be. as for history, actually the separation of /usr came from the original unix. the operating system was in /. /usr was where everyone could share their custom utilities. (hey, i got this little tool called more, which lets you look at a file one screenful at a time instead of letting it scroll past you at the speed of your terminal...) that's why it's called /usr. greetings, eMBee. |
| cr Nov 04, 2011 1:38 AM EDT |
The 68020-based 'Plexus' UNIX-alike system I dealt with back in '91 treated /usr the way we treat /home nowadays: ~crb3 was /usr/crb3. So, the roots of our current tree are shallow in places. That said, I rather like the current system, with a stabilizing FHS that changes only in a slow and methodical manner, and a natural tiering which fits system priority. It makes sense to me to have the vitals in one pocket, /bin, where they can be tripwire-checked on the hour if you're paranoid. If these people don't, nothing says they can't stuff /usr/bin with symlinks to everything in /bin, then they can have their "simplified" scripts work and we can have ours still work. There seems to be some kind of mind-virus going around lately of reduction-to-absurdity and make-work for the sake of discovering limits by surpassing them. Is this some kind of Jobs-creation tactic for dealing with the recession? It's a global thing, so it can't be drugs or Death Eaters. |
| BernardSwiss Nov 04, 2011 3:12 AM EDT |
It's not how it's done in Windows -- there must be something wrong with it! |
| rahulsundaram Nov 04, 2011 4:44 AM EDT |
@Grishnakh, did you or others agreeing with you ever read the feature page at all? It doesn't seem so. https://fedoraproject.org/wiki/Features/UsrMove Hint: symlinks |
| Koriel Nov 04, 2011 9:23 AM EDT |
Im not sure whether its a good idea or bad idea, but niether am i sure that a mass of symlinks is a good idea either just look at Windows 7 structure more links than you can shake a stick at making it confusing at first glance. Im on the fence on this one. |
| number6x Nov 04, 2011 10:17 AM EDT |
Lately, Fedora and Ubuntu seem to be working very hard at making debian and Slackware look good. |
| JaseP Nov 04, 2011 10:53 AM EDT |
Symlinks... symlinks are your friend... |
| dinotrac Nov 04, 2011 11:34 AM EDT |
@JaseP - they're also a PITA. |
| BernardSwiss Nov 04, 2011 1:57 PM EDT |
I propose a movement to simplify knives. We can start by getting rid of the point, and the complex curve associated with that -- after all the edge is the important part that does the cutting. That would leave use with a nice, straight edge -- much simpler. While we're at it let's get rid of the handle too, and makes manufacturing much more complicated than it needs to be (if that's too radical in one jump, we could start by just disposing of the crosspiece, as that's the worst offender against simple, straight-forward design). |
| number6x Nov 04, 2011 2:14 PM EDT |
@BernardSwiss If the sharp edge is what is important, why not get rid of everything else? Even the blade. All you need is the edge, so remove the curve, the handle and all of the blade that is not the edge. A very simple design indeed. |
| mbaehrlxer Nov 04, 2011 2:44 PM EDT |
you mean stuff like this? http://en.wikipedia.org/wiki/Wire_saw greetings, eMBee. |
| Grishnakh Nov 04, 2011 3:35 PM EDT |
I'm with Koriel on this one. I see what they're getting at with having all that stuff in /usr and allowing it to be read-only and shared across multiple machines (with /var, /etc, and /run (which I assume has a /run/tmp directory)) not shared and machine-specific, but having a giant mess of symlinks back to /bin, /sbin, and /lib sounds like a bad idea. Symlinks have their place, and this doesn't seem like it. For instance, what if someone does a package update on one of these setup where you're sharing /usr across a bunch of nearly-identical machines, and this changes or deletes a file in /usr/bin? Suddenly you've got a dead symlink in /bin in all those machines. Symlinks are normally maintained along with the files they're pointing to. So, for instance, with shared libraries, you'll have libfoo.so.1.0.0.1.2, and then a symlink to that from libfoo.so.1, and another symlink to that from libfoo.so. But that library and its symlinks are all in the same directory together, so when you do a package update that affects them, they all get updated at once. You don't have to worry about them being on different partitions or volumes, one of those volumes being somewhere else on the network or read-only, etc. |
| Fettoosh Nov 04, 2011 4:32 PM EDT |
Quoting: but having a giant mess of symlinks back to /bin, /sbin, and /lib sounds like a bad idea. Symlinks have their place, and this doesn't seem like it. Am I missing something? I believe the symbolic links are for backward compatibility and for transitional period. Eventually, they might disappear. |
| gus3 Nov 04, 2011 5:27 PM EDT |
That touches on a good point, Fettoosh. What will be the determining factor for their final removal? Lack of new Fedora bug reports? Other distros following suit? Or maybe they'll stay in forever? Symlinks don't use much space. Inquiring minds want to know. (Apropos: my virtual keyboard thought I meant "disastrous" for "distros".) |
| BernardSwiss Nov 04, 2011 5:34 PM EDT |
@number6x
@mbaehrlxer That did occur to me, but I didn't think it fair to carry the analogy quite that far. The problems with the current system are plain enough, but I strongly suspect that the proposed solution would be merely replacing one set of problems with a different set. And I also suspect that overall the current arrangement would prove more satisfactory over-all, but that it would (for human rather than technical reasons) be far more difficult to return to a more structured arrangement again. (Disclaimer: I'm a "hobbyist", not a "coder", so my opinion may be worth about as much as you paid for it. But I shall be very interested in what the genuine *nix grey-beard gurus have to say on the matter.) |
| Fettoosh Nov 05, 2011 12:09 PM EDT |
Quoting: What will be the determining factor for their final removal? I guess the fundamental question becomes, is there a valid enough reason to remove them? I don't see one and I don't see any harm in keeping them. So, my choice would be Or maybe they'll stay in forever? Symlinks don't use much space. |
| chalbersma Nov 05, 2011 7:19 PM EDT |
You guys should check out the FreeBSD system. Core materials under / but everything that has been customized for the system under /usr/local. So I can make a partition /, one one for /usr/home one for /usr/local and one for /usr/ports. This gives me the ability to move a system by simply copying /, move a system with all of my apps by copying / and /usr/local. All my data is in /usr/home so that's recoverable. And if I have customized development I can keep /usr/ports out of the process. I can tell you that there Linux needs a better system of seperating it's core utils and key chain from it's installed apps. It would make administrator much simpler. |
| 750 Nov 06, 2011 7:46 AM EDT |
Been using Gobolinux for 3-4 years now and there things have been taken all the way. The legacy tree is maintained via symlinks and the various binaries, libs and such are in a separate dir tree sorted by package name and version. Funny thing is that this results in a very robust system. Robust in that each installed version is in its own subdir, allowing a botched install to rolled back. I have even rolled back core package updates using a livecd and some effort. Sadly the distro is growing stale because the community is small and various compilation scripts needs to be patched to play nice with the layout (in the past Gnome have been a struggle, and KDE4 turned out to be a pain because of the switch to cmake). |
| mbaehrlxer Nov 06, 2011 11:37 AM EDT |
the gobolinux devs should take a look at the conary package manager and build tools. the package recipes are python classes inheriting a parent class where all the common behaviour is defined. with that it would be easy to define a class that sets different prefix and destdir etc values for each package, and creates the necessary symlinks. there shouldn't be any patching necessary just to stuff each package into a separate subdir. greetings, eMBee. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!