Sorpigal

How about we stop mincing around and make some gut-wrenching modifications? As long as you're going to go through all the trouble of shuffling things around let's kill more than one bird at a time. Let's not worry about legacy needs, let's just worry about current needs. We no longer care about disk space and (for the most part) things can be tab-completed, so there's little reason to keep anything small if there's a down side.

What's attractive about /usr? A lot of things, but mostly: single export-point, possible to separately mount (from a network, read only, whatever), logically nice to have all those directories not polluting /.

I propose that / should contain the following directories:

/cfg/ /home/ /local/ /mnt/ /system/ /tmp/

You would mv /boot /dev /bin /sbin /var /root /proc /sys /usr /lib /run /system, then mv /opt /local

/etc/ is renamed /cfg/ just because I can and left in / because some things really are global configuration (and we can't be mounting /etc ro all the time).

But don't stop there, because now /system/ is a mess. You obviously still can't treat /system as /usr because e.g. /dev is there, so put /dev, /proc and /sys under /system/kernel, because these things are figments of the kernel's imagination anyway. Under /system/boot/ throw in a directory for your bootloader, initrd and whatnot and one for any statically-linked binaries you have, if you have any (hey, it's optional). No need for a lib, because it's all static or in the initrd. Just because I'm a mean curmugeon who hates greybeards and love n00bs, let's mv /system/var /system/data. Inside /system/usr let's merge files from games, bin and sbin into bin and get rid of the empty directories. Then mv /system/usr/local/ /local/usr/.

Speaking of /local/, it'd have two subdirs: /local/opt/ and /local/usr/. The former would contain an opt-style directory hierarchy and the latter would be like /system/usr, only with the purpose of the FHS /usr/local. Okay, so the /local/ stuff isn't to be found in an exported /system/usr/, but /local/ is just a fetish of mine. You could put it in /system/usr/, too. And yes, /system and part of its structure is required to be on / during boot. So sue me.

Now you have:

/cfg/ /home/ /local/ /local/usr/ /local/opt/ /mnt/ /system/ /system/data/ /system/boot/loader/ /system/boot/sbin/ /system/kernel/dev/ /system/kernel/proc/ /system/kernel/sys/ /system/root/ /system/run/ /system/usr/bin/ /system/usr/lib/ /system/usr/share/ /tmp/

Now you have a tree for homes, a tree for the whole system, which has a splits where you might need them for partitioning and exporting, a tree for configuration, which also has a name users can understand, a tree for non-packaged software, which allows for both crazy-opt style layout and traditional, and you have your global tmp and temporary mount point root.

Did I leave anyone out?

Partitioning has some security and performance gains. Different filesystems for different workload (e.g. perhaps xfs for database files and reisterfs for /tmp), mounting with noexec or ro in some cases.

In Windows from a cmd.exe prompt you rely on the contents of %PATH% to access programs. This is a holdover. In Windows proper there are other methods; from cmd.exe you can use the 'start' program to invoke executables in a Windowsy way. The most convenient/reliable way to set up an easy to use/remember way to launch an executable in Windows is to go to the registry and locate hklm/software/microsoft/windows/currentversion/app paths/, inside of which are a series of keys. Each key is the name of an alias and its default reg_sz value is the path to the executable to invoke when the alias is passed to 'start' (or entered into the run prompt, or what have you). You will find a number of these already in existence on any Windows box, most notably iexplore.exe.

BSD is in a position to differentiate in a way that Linux just isn't. In Linux all* software is third party, except for the kernel and util-linux (and maybe fileutuls or some other set of GNU software).

To me the BSD distinction doesn't make much sense anyway. You still have to just know which bits are "local" and which are not, plus anything I pull in that isn't a port gets lumped in with them anyway.

This is why it is essential for people who are concerned about privacy to use run Firefox and install the RequestPolicy extension. I simply don't whitelist facebook's domains and thus couldn't be tracked even if I had a Facebook account.

Read it again, they are.

Quote from the proposal: "For example, the adoption of Universal Time would give new flexibility to economic management in the vast East-West expanse of Russia: everyone would know exactly what time it is everywhere, at every moment. Opening and closing times of businesses could be specified for every class of business and activity. If thought desirable, banks and financial institutions throughout the country could be required to open and to close each day at the same hour by the world time. This would mean that bank employees in the far East of Russia would start work with the sun well up in the sky, while bank employees in the far west of Russia would be at their desks before the sun has risen. "

The article omits this in its summary.

The real innovation in this calendar, which I don't rememebr seeing in previous perpetual calendar proposals, is the system for 7-day-week seasonal drift adjustment. Adding an "extra" 5 days to every year is much more common, but not popular.

What I can't figure out is what algorithm they use to calculate when to add an extra week. It seems slightly irregular, but I asssume there must be a simple formula I could use in a date library to account for it.

Compliance with biblical mandates is a popularity hack. You need popularity if you want a new calendar to be adopted (or you need massive power on the level of an emperor^Wdictator.

For people who are apparently enlightened enough to realize that no calendar, however rational and perfect, will be accepted if it violates a certain religious rule (the sabbath), they are apparently quite ignorant in their advocacy of UTC for all purposes.

It's all well and good to eliminate time zones as such and have each region operate on a fixed clock, but to suggest that people will simply stop paying attention to the sun is insane. If you want wide adoption you can't expect people to make radical change in their lives. Most people prefer to wake with the sun and sleep when it's dark; some studies suggest that we are biologically predisposed to want or need this. Whether it's 05:00 when I wake or 16:00 when I wake is immaterial to me (that's just a number, just what you call it) but whether it's daylight when I'm out and about just plain matters.

In effect you'll probably always need a way to divide the world by when the sun is up, even if the clock doesn't change.