Daniel J. Bernstein, around the turn of the century, proposed a /package hierarchy (for package management without the need for conflict resolution) and a /command directory. (http://cr.yp.to/slashpackage.html) Their major problem was the idea that one had to register things with what was to most of the world just some bloke on another continent. But they had concepts like a hierarchical package naming scheme ("admin/", "mail/", &c.), self-contained build trees with versioned names, and an "index" directory full of symbolic links.
then people that can't work together with others (eg Jobs) does retarded things like /localLibrary which benefit nobody, not even themselves. just throw everything up. then if those folks succeed despite that, it becomes the new immutable thing to follow, like gnome is doing with following blindly apple ui specs.
edit: i never tried to contribute to any larger standard. i did develop against most of them, cursed at their anachronistic ways and coded around it praising consistency. so i am pretty sure i am part of the problem described above. I'm not saying the fine people in those ivory towers are the problem. I'm glad we have that little help for world consistency. it's just not enough.
where it came from originally is not much of concern. but the fact that it is the best we have, is.
But sadly it doesn't present the nice object concept NeXTSTEP and OS X have.
What about OpenSSH does that mean any program that uses SSH needs its own copy and then we have 12 different versions of SSH?
Its not easy but I am sure someone is smart enough to figure this stuff out. NixOS and Gobo Linux have tried.
These are packages that other packages can refer to rather than massively duplicating the content within themselves.
These frameworks will in turn be versioned, so that if package X wants framework Z, while Y wants Z+1 they can both be happy without descending into dependency hell.
Note that Gobolinux gets around this to a degree by using age old soname and symlinks. This in that ld and similar is pointed at a directory containing symlinks.
libxyz.so.1 will be pointing to whatever is the active version of libxyz, while something like libxyz.so.1.1 will be pointing to that specific lib version.
Disabling a specific lib version is done by removing the relevant symlinks.
Gobolinux provides tools for doing this, but they are basically shell scripts. And so in a pinch someone can do all that manually.
At that point the shared libraries are useless, they don't provide security (update in one place and have all aps using it patched), doesn't save RAM (each app loads their own version of library, instead of multiple apps sharing the same code), and you get worse performance (there's overhead for using shared libraries).
What lsaferite suggested makes sense, if the library is used only by given app, why not compile it statically? You have everything in a single file, and at least you're not losing performance by using shared objects.
That said, once compiled a binary package can be produced by simply creating a compressed archive of the content of /Programs/app-name/app-version (an official binary package is a bit more involved to ensure compatibility with the latest released iso).
Beyond that i am not quite sure what you are asking.
It seems to be working pretty good, actually, with compartmentalization and tight security.
Meaning Java, which makes POSIX irrelevant.
Tight security? Well, how about Stagefright? Cyanogen no longer supports my phone. Even when they did, it wasn't well-supported: each new release had a high chance of breaking something fundamental. Right now I'm stuck on a "milestone" release that isn't even the newest one (it's over a year old now!), because later ones all have some unacceptable problem, like GPS not working or cell data not working. I can't just install an updated browser component package, because Android is monolithic. On Debian it'd be in a package like libwebkit, and it'd be a simple "apt-get upgrade" away.
So I'm stuck with a vulnerable Android version. If I try to upgrade to fix it, I'll lose GPS or cellular data. The only way to get a fix is to buy a new phone.
Now Google is trying to push more of the components into its Google Play Service app/framework. So, great: more parts can be upgraded independently of the monolithic core. But that also means that Google can push out updates to more components without my knowledge or consent: not great. That means more instances of feeling something warm in my pocket, pulling out my phone, and finding that Google Play Services has kept my phone awake for 10 hours and my battery is at 12%.
This has happened to me on multiple occasions: one day my phone works fine. The next day it eats the battery like candy. I didn't change any settings or install any updates--Google merely decided to push out an automatic update to its APKs without my knowledge or consent, and Google Play Services constantly crashes every 5 seconds, popping up a dialog box that I have to manually dismiss. I can't even do a simple task like send an SMS or check my email, because every 5 seconds it pops up another "Unfortunately..." box. There's no practical way to roll it back, nor even to report the problem. The best I can do is find people reporting the same problem on Reddit and hope that Google gets its act together so I can actually have a usable phone again; maybe one morning I'll wake up and my phone will not be "sick" anymore. In the meantime I have a really dumb "smartphone" that keeps my leg warm.
I have had high hopes for Android, but I now consider it to be a mess, and consider Google to be a highly irresponsible steward. I don't want an iPhone, but if someone wants a reliable smartphone without nasty surprises, they are probably better served with one.
Similar problems happen with Debian as well. E.g. hibernation breaks or WiFi stops working.
Sure, I could use Android without Google Play Services. That would also mean not being able to use the vast majority of apps in the Play Store--and I don't mean games. That would mean not being able to use, e.g. Google Maps.
So to use Google Maps, I should have to give Google free rein to push updates to its software to my phone whenever it wants, including untested updates that cause breakage, crashes, and battery draining causing high temperatures?
This is what's wrong with Android.
And you can't seriously claim that such drastic breakage happens on a regular basis with Debian Stable.
I would also like to have more control over what Google does in my Android phone while not losing the ability to install apps easily.
In addition to the problems you describe with google moving more core functionality into its "Google Apps" packages, it also means that running android without the google bits is getting increasingly hard. It's missing some core functionality that other non-google apps expect.
Public build service is https://openrepos.net/ and it already has lots of packages that you know from a normal Linux desktop and you can also host your custom stuff there. High-level package manager is packagekit or zypper.
Having a private repo is easy, too. Package format is RPM, repo format is http://createrepo.baseurl.org/
Given the thin APIs exposed in the NDK, Google could change it by any UNIX flavored kernel and no one would notice.
The OEMs might be a bit pissed off if they had to change the APIs, but that's all.
In short: because having things in /usr is equally compatible, and makes some useful things like atomically snapshotting /usr to snapshot all executables, mounting /usr readonly, etc. possible.
But it is this kind of stuff that they are trying to change (as usual for systemd, without fully thinking why people do it differently now).
Of course, another part is that this is an old idea, already implemented once in the commercial Unices a quarter of a century ago. They merged /bin into /usr/bin, with a symbolic link from the former to the latter.
Plus there are a handful of tools with smart option that take advantage of the multiple partition approach, like rm and rsync's --one-file-system option.
[root@mail /]# ls -laF /etc/init
ls: cannot access /etc/init: No such file or directory
If you want to have a separate read-only partition for system programs (and require going into single-user mode to modify that), go for it. But the rest of the /bin /etc /usr /usr/local nonsense is just because it's easier than changing to something better for most people.
The thinking behind the file system layout had nothing to do with the available disk space or having a read-only file system. It was, originally, entirely a hedge against corruption; before journaling file systems and all that jazz, if your system was hit by a power outage and it was in the middle of some operation or another it might corrupt whatever file system it was working in.
So, you would create multiple partitions and have different directories as the mount point for each partition. Say for instance that, as a cautious sysadmin, you put /sbin on its own partition. Excellent! Since /sbin rarely gets touched, if everything goes pear-shaped, the system will still boot into single user mode and you can use tools like fsck and mount, which are under the uncorrupted /sbin partition and are statically linked. If you couldn't for some reason recover the file system on a particular partition, then you might be looking at having to load, say, /etc from backups, instead of everything under /.
Over time, other software started to take advantage of multiple partition layouts to protect you from getting hurt. You could mark some partitions noexec, nosuid, or restrict operations like rm or rsync to specific partitions without having to worry about whether or not they'll crawl out of that partition and eat the world.
But that's pretty old-school now. As file systems improved and corruption was less of a problem and everybody sort of gave up caring about what options rm accepted, more and more systems just mounted everything under / so that you would be maximally boned if ever there was a filesystem problem. Progress!
OpenBSD is one of few operating systems left that has a set of recommendations for how to partition your system: http://www.openbsd.org/faq/faq4.html#Partitioning
So that's why I'm not a fan of "novel file system layouts"; the previous layout was designed and existed for some good reasons and I have a hunch that the people that are happy about novel file system layouts don't know about those reasons.
If my filesystem gets corrupted, I boot into a live cd, just like everybody does.
With btrfs and integrated parity, checksums, cow and scrubbing on the horizon filesystem reliability is only a minor thing to care about. With subvolumes we can snapshot as many things atomically as we want.
Simlicity is now what trumps your arguments overwhelmingly. The filesystem hierarchy has to be intuitive, consistent and simple, which it is currently not.
Booting a LiveCD would not have fixed affected partitions.
You're not the first on HN to say in so many words that the sometimes expensive lessons I've learned over 30 years of computing are suddenly irrelevant now. I used to argue that, but I don't see much point to it anymore.
Another argument was more fine grained permission control. You can do that by other means, for example with subvolumes.
So, after all, possible corruptions are not alleviated by complex partition struture, or only with a bad trade-off for complexity. Instead, do backups. Easy and reliable. Everbody is happy, without many partitions.
Simplicity is crucial and it's one thing the free software ecosystem is consistently getting wrong. I see it as the major showstopper for many people to use it more intensively.
The filesystem hierarchy is just one culprit, but a fundamental one.
Take a look at at some fundamental pure mathematics lectures or books. You can immediately see that this was designed to be as easy as possible. Software must be the same.
Basically that exact capability is why people adopted Linux in the first place to run the servers that run the net.
I don't see how having a / that can get up and running even when the larger system housed in /usr and such is down for the count, is anything more complex that the piles of VMs and containers that is being advocated today.
Don’t misunderstand simplicity for triviality for they are not the same. We need to make non-trivial problems simple.
Linux desktop penetration: ~1.33% (http://www.netmarketshare.com/operating-system-market-share....)
1.3% * 136mm = 1.77mm
Let's ignore Amazon, Google, Microsoft, Facebook, and so on, each of whom are by themselves rumored or reported to have over a million computers in their DCs. Let's further ignore the long tail of the second tier of providers, who are thousands in number and have merely hundreds of thousands of computers each in their DCs. Let's go on to ignore all of the self serve corporations in the hundreds of thousands of data centers across the world, running Linux or a derivative on thousands to hundreds of computers each.
Let's also ignore all the routers, switches, file servers, and miscellaneous other networking equipment running Linux or a derivative.
Let's further ignore all of the televisions, media players, microwaves, appliances, and other consumer goods running Linux or a derivative.
Let's look only at Android phones, which run an embedded derivative of Linux. The phone market shipped 341.5 million year over year in 2015 Q2 (http://www.idc.com/prodserv/smartphone-os-market-share.jsp). Android had an 82.8% marketshare, so that's 282.77mm.
The number of linux computers that have the ability to boot "a live cd" is 6 thousandths (.6%) of one segment of one part of the linux embedded and server market.
Linux on the desktop has not only been dead for the last 18 years, it's barely a rounding error on a single segment of a single part of the embedded and server market.
By the way, "the complexity of the default" has been fine for over 30 years, and it's still fine. Just because you don't understand it, doesn't mean it's not the right answer.
And that is what makes someone take the road trip to the server farm at 2am because a ge-wiz dev thought the exact same and never considered a "rescue" mode with network capability.
I'm 100% certain I remember the instructions for partitioning being related to file system corruption, but that may well have come long after the original design of the FSH.
I was able to recover the machine with a LiveCD but still, it was annoying.
This so that it is less likely that anything with hardcoded paths will throw a hissy fit.
Frankly Gobo demonstrate the massive flexibility of classic unix tools, as most of it is shell script and symlinks. There is perhaps a few binaries, purely for performance (and those are third iteration, the first being shell script, the second Python).
However isn't the problem that we need everyone to agree to do this? Additionally it is nice to have all config in /etc
Heck, it originated as one guy's solution for managing self-compiled programs within his home dir on the university mainframe (or some such).
You can still find Rootless (the bootstrap tool for using Gobolinux in the home directory) on the Gobolinux site, but i can't comment on how well maintained it is these days.