Boiling frog, or when did we lose it with /etc?(blog.surgut.co.uk)
blog.surgut.co.uk
Boiling frog, or when did we lose it with /etc?
http://blog.surgut.co.uk/2015/03/boiling-frog-or-when-did-we-loose-it.html
10 comments
This issue, configuration, seem too fuzzy for anyone. Unix was simple in the days because it was tiny on limited hardware with a core set of developpers. Linux grew out of this in another context. Some distributions tried to get back to simplicity (slack, arch), but in the of arch, it's back to complexity imposed by current components. As someone reminded me on some web site, polkit is configured in javascript. Every system has it's own way, from the time he was designed (early 2Ks had xml, then it was js,...). The lack of core design is cause the lack of elegance. It's been said that languages suffer this too when they're not the fruit of a single mind (~BDFL).
Windows registry was binary and too ad-hoc, things were unorganized and hacked too. It doesn't address the social issues of compatibility.
I'd love to have a peek at VPRI 100KLoC system to see how their system was described in source.
Windows registry was binary and too ad-hoc, things were unorganized and hacked too. It doesn't address the social issues of compatibility.
I'd love to have a peek at VPRI 100KLoC system to see how their system was described in source.
Just curious, what's VPRI? Does it have any core design in this area?
Viewpoint Research Institute, ~~employs~~founded by the famous Alan Kay. They carried the STEPS projects, trying to create an operating system in 100K LoC (whereas Windows is more about 10M LoC). OS with network, gui, office, reflective and programmable.
http://vpri.org/html/writings.php (search for 'steps' reports, last from 2011)
http://vpri.org/html/writings.php (search for 'steps' reports, last from 2011)
But while I think the Windows Registry has a lot of problems, it also is a step forward on the mess if incompatible configuration files found within /etc (and /usr/local/etc) on your average modern UNIX-like OS.
Not really. You have certain apps using the file system and others that use the highly limited key-value quasi-file system that is the Registry. There is no single point of truth at all.
see systemd, which is trying to evolve classic UNIX concepts and getting massively attacked, even death threats as a result
Yeah, that flame war's pretty visceral, but there's plenty of reasons systemd gets criticized (chief of which is the perception that it in fact devolves classic concepts).
Windows' file system is also a mess.
Windows' file system hierarchy is an enormous mess far surpassing the FHS in Unix. /etc/hosts vs C:\windows\System32\drivers\etc\hosts. Enough said. The FHS at least has some semantic meaning that is more-or-less consistent or can be easily deduced, but Windows is just a hodgepodge.
The UNIX world is in cryogenic suspension
No, there's many people who are trying new approaches. The problem really isn't the use of a hierarchical file system, it's the lack of semantic categorization of configuration locations.
Not really. You have certain apps using the file system and others that use the highly limited key-value quasi-file system that is the Registry. There is no single point of truth at all.
see systemd, which is trying to evolve classic UNIX concepts and getting massively attacked, even death threats as a result
Yeah, that flame war's pretty visceral, but there's plenty of reasons systemd gets criticized (chief of which is the perception that it in fact devolves classic concepts).
Windows' file system is also a mess.
Windows' file system hierarchy is an enormous mess far surpassing the FHS in Unix. /etc/hosts vs C:\windows\System32\drivers\etc\hosts. Enough said. The FHS at least has some semantic meaning that is more-or-less consistent or can be easily deduced, but Windows is just a hodgepodge.
The UNIX world is in cryogenic suspension
No, there's many people who are trying new approaches. The problem really isn't the use of a hierarchical file system, it's the lack of semantic categorization of configuration locations.
The "death threat" was a tongue in cheek comment on IRC late one night after someone had spent their day bug fixing a borked boot after a systemd update or some such.
It pretty much amounted to someone musing about using kickstarter to crowd fund an assassin.
1. there is no way it would get past the kickstarter people.
2. it is unlikely that enough people hate poettering so much that it would get off the ground.
It was a badly off color joke made by someone mentally exhausted from having to fix something someone else broke.
Sadly since then the "for the lulz" troll brigades has latched onto systemd as a source of "amusement"...
It pretty much amounted to someone musing about using kickstarter to crowd fund an assassin.
1. there is no way it would get past the kickstarter people.
2. it is unlikely that enough people hate poettering so much that it would get off the ground.
It was a badly off color joke made by someone mentally exhausted from having to fix something someone else broke.
Sadly since then the "for the lulz" troll brigades has latched onto systemd as a source of "amusement"...
100% agree. I've used both for decades and I far prefer /etc to the mishmash of Windows registry and ini files.
You've used both for "decades" but think ini files are a substantial part of Windows' inner workings? Microsoft migrated to XML files for non-registry configuration. There's a small handful of legitimate ini files left on Windows (largely for backwards compatibility reasons e.g. win.ini).
I never said ini files dominated. There are still apps that use them, as dagw mentioned. Not all apps are written by Microsoft.
Windows might not use .ini files, but lots and lots of windows apps still do.
Not really. XML and SQLite are by far more popular for anything written recently.
But anything written recently isn't popular
> The FHS at least has some semantic meaning that is more-or-less consistent or can be easily deduced, but Windows is just a hodgepodge.
Really?
C:\Windows - Windows itself
C:\Program Files - Applications
C:\Users - User data
Really?
C:\Windows - Windows itself
C:\Program Files - Applications
C:\Users - User data
Yes, you're completely ignoring all the special folders, the shell namespace and then of course everything at the bottom level of what you listed. Various NTFS features like reparse points and ADS do not help the case.
It seems clearer but when you install wamp or xampp you'll find a php.ini in c:\wamp\apache and c:\wamp\php (or sthg).
Nice names (be it /etc or C:\Users) don't prevent developers to put their config file wherever they can read it.
Usually in C:\Users\Alice\Ubisoft if they are in the game business.
Or C:\Program Files\Steam\Steamapss if they are in the game business.
Nice names (be it /etc or C:\Users) don't prevent developers to put their config file wherever they can read it.
Usually in C:\Users\Alice\Ubisoft if they are in the game business.
Or C:\Program Files\Steam\Steamapss if they are in the game business.
Talking about where PHP (a unix program) puts it's configuration on Windows is hardly a valid point. Even on Linux, that sucker can be hard to find. On my Linux server it is at least 5 levels deep and I have to run phpinfo() just to find it.
> Talking about where PHP (a unix program) puts it's configuration on Windows is hardly a valid point.
That's because it's not my point but an example of "it's up to the dev to be consistent or to follow the platform's guideline" which is my point along and with "`Program Files' is a nice folder name but you are going to find some user configuration files in there'".
If I remember correctly Foobar asks you when installing where to put its configuration files: user home, or program files. It should not. It should be in C:\Users\Alice\Local Settings (or was it LocalApps ?).
That's because it's not my point but an example of "it's up to the dev to be consistent or to follow the platform's guideline" which is my point along and with "`Program Files' is a nice folder name but you are going to find some user configuration files in there'".
If I remember correctly Foobar asks you when installing where to put its configuration files: user home, or program files. It should not. It should be in C:\Users\Alice\Local Settings (or was it LocalApps ?).
There are guidelines for where developers are supposed to store configuration, and since Vista, it isn't in Program Files. In fact, making changes in Program Files is restricted to the System, or elevated processes. It is often times an indicator that a program is violating accepted practices if it requires elevation of privilege to run. Changes like that are supposed to be stored in the users AppData directory.
For backwards compatibility. Vista and descendants provides a virtualized space where writes to restricted directories are allowed, but they are committed to a different isolated space on the disk, preventing a rogue program from, modifying files for which it should not have access.
Neither Windows or Linux are perfect in this respect, but for a decade, Microsoft has been trying to unify how applications store user specific data and configuration. There are still ways for developers to abuse the system, but they are considerably restricted from the most glaring mistakes and in general it has gotten better with each revision.
For backwards compatibility. Vista and descendants provides a virtualized space where writes to restricted directories are allowed, but they are committed to a different isolated space on the disk, preventing a rogue program from, modifying files for which it should not have access.
Neither Windows or Linux are perfect in this respect, but for a decade, Microsoft has been trying to unify how applications store user specific data and configuration. There are still ways for developers to abuse the system, but they are considerably restricted from the most glaring mistakes and in general it has gotten better with each revision.
[deleted]
Applications go in Program Files (or is it Program Files (x86) or good old PROGRA~1), which is why you can find Chrome in C:\Users\username\AppData\Local\Google\Chrome\Application\chrome.exe
User data goes in C:\Users\username\My Documents, except when it's a savedgame or the user saves it to the desktop or the application decides to keep it in AppData instead. Or if the user installs or inserts another disk.
Windows is confined to Windows, apart from the bootloader. But sometimes, with an especially hapless error, you can get Windows to reassign the drive letter for C:, and all hell breaks loose.
It sounds like people actually want Windows CE (no drive letters, everything OEM installed goes into \Windows, no exceptions)
User data goes in C:\Users\username\My Documents, except when it's a savedgame or the user saves it to the desktop or the application decides to keep it in AppData instead. Or if the user installs or inserts another disk.
Windows is confined to Windows, apart from the bootloader. But sometimes, with an especially hapless error, you can get Windows to reassign the drive letter for C:, and all hell breaks loose.
It sounds like people actually want Windows CE (no drive letters, everything OEM installed goes into \Windows, no exceptions)
> which is why you can find Chrome in %AppData%
Chrome installs in %AppData% so a non-admin user can install it and a non-admin process can update it. It is debatable if this is good behaviour, but it has nothing to do with the supposed confusion over Program Files.
> Program Files (or is it Program Files (x86) or good old PROGRA~1)
On 64 bit Windows 64 bit installations go in Program Files and 32 bit installations go into Program Files (x86). This is transparent to the installers themselves as Windows directs the installation appropriately based on bitness. 8.3 filenames are depreciated and only exist for backwards compatibility with MS Dos applications.
> User data goes in C:\Users\username\My Documents
No user data goes in the aptly named AppData folder (i.e. %AppData% or C:\Users\[user]\AppData). Personal files go in the Documents folder (it hasn't been called "My Documents" in approx. five years).
> But sometimes, with an especially hapless error, you can get Windows to reassign the drive letter for C:, and all hell breaks loose.
Your above issues are pretty sketchy but this one is now getting into the realm of absurd. You're effectively arguing that when you go out of your way to try and break Windows it, well, breaks. That is an astounding revelation.
> It sounds like people actually want Windows CE (no drive letters, everything OEM installed goes into \Windows, no exceptions)
People want a container model where everything is together.
Chrome installs in %AppData% so a non-admin user can install it and a non-admin process can update it. It is debatable if this is good behaviour, but it has nothing to do with the supposed confusion over Program Files.
> Program Files (or is it Program Files (x86) or good old PROGRA~1)
On 64 bit Windows 64 bit installations go in Program Files and 32 bit installations go into Program Files (x86). This is transparent to the installers themselves as Windows directs the installation appropriately based on bitness. 8.3 filenames are depreciated and only exist for backwards compatibility with MS Dos applications.
> User data goes in C:\Users\username\My Documents
No user data goes in the aptly named AppData folder (i.e. %AppData% or C:\Users\[user]\AppData). Personal files go in the Documents folder (it hasn't been called "My Documents" in approx. five years).
> But sometimes, with an especially hapless error, you can get Windows to reassign the drive letter for C:, and all hell breaks loose.
Your above issues are pretty sketchy but this one is now getting into the realm of absurd. You're effectively arguing that when you go out of your way to try and break Windows it, well, breaks. That is an astounding revelation.
> It sounds like people actually want Windows CE (no drive letters, everything OEM installed goes into \Windows, no exceptions)
People want a container model where everything is together.
> /etc/hosts vs C:\windows\System32\drivers\etc\hosts. Enough said.
Great example if that wasn't a big exception to everything in Windows; pointing it out really just proves the opposite in general. Everything else in Windows in terms of the file system is more straight forward.
The registry provides one single format for all configuration. It's not INI, a made up format, JSON, XML, etc. It's still abused by some developers but you can't do much about that.
Great example if that wasn't a big exception to everything in Windows; pointing it out really just proves the opposite in general. Everything else in Windows in terms of the file system is more straight forward.
The registry provides one single format for all configuration. It's not INI, a made up format, JSON, XML, etc. It's still abused by some developers but you can't do much about that.
My point is said single format's inconsistent use means you end up in the situation where configuration is unevenly distributed between the hierarchical file system, the shell namespace and the key-value store of the Registry with its flaws and misuse. Evidently many find the single format to be limited.
No.
A binary blob as a configuration store is unambiguously wrong.
The difference between all the bins and all the sbins is clearly explained in the Linux Filesystem Hierarchy Standard. It's not Linux's (or UNIX's) fault if someone doesn't read or follow that.
A binary blob as a configuration store is unambiguously wrong.
The difference between all the bins and all the sbins is clearly explained in the Linux Filesystem Hierarchy Standard. It's not Linux's (or UNIX's) fault if someone doesn't read or follow that.
I don't see why a strongly typed binary blob is worse than a mess of untyped randomly formatted configuration files.
There might be an argument to be made but it's clearly not unambiguously wrong.
There might be an argument to be made but it's clearly not unambiguously wrong.
Here is a reason: You can view the configuration files and logs of a damaged system by mounting its disk in another system and using any old text editor. There is no need to install special tools.
I agree that's the advantage of text formats. Just as that's the advantage of text networking protocols over binary protocols (you can read them with wireshark or even use telnet).
But you have to weigh that advantage over other advantages. If it was this simple, every database (and we are talking about a database here) would just be text to make recovery easier.
But you have to weigh that advantage over other advantages. If it was this simple, every database (and we are talking about a database here) would just be text to make recovery easier.
I agree that you have to weigh the advantages, but we are talking about a special type of database. Most configuration data is read-only during normal operation. It's not as if anyone stores customer data in /etc or the Windows registry.
'regedit' is not a special tool on windows. It's in every install of windows and you can use it open any registry file.
Sure, but what if my only Windows system won't boot? I am sure that I can access the registry from a Linux system somehow, but it's not as easy as invoking less or vim. That is especially true if the Linux system doesn't have a GUI. I don't need a GUI to read a text file.
Strongly typed as long as your type is one of this very short list: https://msdn.microsoft.com/en-us/library/windows/desktop/bb7...
In practice, almost everything is binary, string or DWORD.
The world would have been a very different place if the registy had supported comment fields and/or online help.
In practice, almost everything is binary, string or DWORD.
The world would have been a very different place if the registy had supported comment fields and/or online help.
because when something gets corrupted, the damage is limited.
The windows registry isn't a binary blob; It's a filesystem. A mountable, grow-and-shrinkable filesystem, that happens to be mounted from a loopback device. You can mount arbitrary SAM files at arbitrary paths in your windows registry (though I don't recommend ever doing it).
This isn't really an argument for the windows registry (it's a whole separate filesystem just for configs? With none of the versioning, inheritance, whatever features you want for configs?), but it is another way to think of it.
This isn't really an argument for the windows registry (it's a whole separate filesystem just for configs? With none of the versioning, inheritance, whatever features you want for configs?), but it is another way to think of it.
Re: blob, please elaborate. Simply stating that something is wrong does not contribute to the discussion.
Explaining a confusing standard does not make the standard clear or good.
Explaining a confusing standard does not make the standard clear or good.
> It's not Linux's (or UNIX's) fault if someone doesn't read or follow that.
It's a very poor designer that blames their users.
It's a very poor designer that blames their users.
I'm not the designer. I'm a user, blaming other users, for not reading the fine manual.
Would you call someone out writing a Windows application that didn't install its binaries under PROGRA~1? Same principle.
Would you call someone out writing a Windows application that didn't install its binaries under PROGRA~1? Same principle.
Ugh, the registry was etc but strictly worse. You must use a specialized, and might I add insanely crappy, tool to edit it, it can be corrupted, there is only one so you can't swap out a registry with certain features for another, the list goes on. The registry deserves every bit of guff it ever got.
I've got multiple Registry editing tools:
Regedit - which has an OK UI.
Powershell - https://technet.microsoft.com/en-us/library/dd315270.aspx
WMI - https://msdn.microsoft.com/en-us/library/aa394600(v=vs.85).a...
And different Hives live in different places. The user Hives live in each user's profile folder, so that part gets swapped out depending on whose security context you're in.
Regedit - which has an OK UI.
Powershell - https://technet.microsoft.com/en-us/library/dd315270.aspx
WMI - https://msdn.microsoft.com/en-us/library/aa394600(v=vs.85).a...
And different Hives live in different places. The user Hives live in each user's profile folder, so that part gets swapped out depending on whose security context you're in.
> Ugh, the registry was etc but strictly worse.
Really? On which versions of Windows does the registry include executables critical to system function?
Really? On which versions of Windows does the registry include executables critical to system function?
On which UNIX-like does /etc contain executables critical to system function?
Don't know if they've changed it since OpenBSD 5.2, but /etc is very critical there.
E.g. man page synopsys for just two programs:
E.g. man page synopsys for just two programs:
/etc/rc - command scripts for system startup
/etc/netstart - command script for network startup
SunOS certainly did, Solaris does, AIX has at various points... probably the majority of Unix variants, in fact.
Linux, /etc/init.d/ or /etc/rc.d/init.d/
The death threats are a ridiculous disaster for the community. Things should never come to that and it's unacceptable.
However, there is an important lesson about change management here. People don't like change. And people need to believe their concerns have been taken into account in order to change. And the proposed solution needs to be genuinely better for everyone's use cases.
However, there is an important lesson about change management here. People don't like change. And people need to believe their concerns have been taken into account in order to change. And the proposed solution needs to be genuinely better for everyone's use cases.
That "threat" didn't come out of the blue.
It was made as a in-joke on a IRC chat dedicated to a mobile distro that has already adopted systemd.
The person making the joke did so after he and others had spent the day fixing stuff that the then latest systemd release broke in said distro.
So it was more a case of "can we get some more sane leadership on this project?" than "lets rid the world of systemd!".
IRC as a medium is more a conversation than anything else, and spur of the moment tasteless lines do happen.
It was made as a in-joke on a IRC chat dedicated to a mobile distro that has already adopted systemd.
The person making the joke did so after he and others had spent the day fixing stuff that the then latest systemd release broke in said distro.
So it was more a case of "can we get some more sane leadership on this project?" than "lets rid the world of systemd!".
IRC as a medium is more a conversation than anything else, and spur of the moment tasteless lines do happen.
Not all modern OS have that directory mess:
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man7/...
https://www.freebsd.org/cgi/man.cgi?query=hier&sektion=7
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man7/...
https://www.freebsd.org/cgi/man.cgi?query=hier&sektion=7
Looks pretty much the same as in Linux?
> see systemd, which is trying to evolve classic UNIX concepts and getting massively attacked, even death threats as a result
Anyone who actually threatens someone over a Linux process should be mocked openly and probably forever.
Anyone who actually threatens someone over a Linux process should be mocked openly and probably forever.
You can't criticise "modern UNIX" in general based on the ugliness of the filesystem hierarchy of one system.
Edit: or most systems, the point is that the ugliness is not intrinsic to unix-likes
Edit: or most systems, the point is that the ugliness is not intrinsic to unix-likes
That's fair. Which modern UNIX variant has a nice filesystem layout and has modernised etc?
http://www.gobolinux.org/ has a fun filesystem layout experiment, at least.
This seems like how I read some old unix guide on compiling software. I put it all in ~/local/$software/$version with $software/latest symlink. I really prefer it as I can wipe software just with removing the directory.
I hate software like MySQL though which seems to ignore me setting --prefix in configure and still insisting to be default look in random directories.
With software with a good makefile and pkgconfig file, I've not had major trouble compiling all the software I use from source.
I hate software like MySQL though which seems to ignore me setting --prefix in configure and still insisting to be default look in random directories.
With software with a good makefile and pkgconfig file, I've not had major trouble compiling all the software I use from source.
Yep. And if you look back you find that GNU have a tool called Stow that do pretty much the same thing to compiled code.
Gobolinux started out as a tool for managing user compiled code inside said users home directory. And a variant of that still exist in the form of Rootless, but i can't comment on how well maintained the tool is.
BTW the first few releases of Gobolinux used a different distro as a base, and overlaid the Gobo tree on top.
Gobolinux started out as a tool for managing user compiled code inside said users home directory. And a variant of that still exist in the form of Rootless, but i can't comment on how well maintained the tool is.
BTW the first few releases of Gobolinux used a different distro as a base, and overlaid the Gobo tree on top.
Appreciate the link. They did a clean-slate redesign with better usage and backward compatibility. Excellent work.
Been using it for a few years (i think the actual install was 013, updated over time to something akin to 014, so i still have /system/Links rather than /System/Index) and i keep being surprised how many tarballs i can basically go "MakeRecipe Foobar x.y.z example.com" on and follow it up with a "Compile Foobar" to get it installed if there is not already a recipe in the repo.
Some larger projects are a fair bit more hairy however (Hello Mozilla) and i think people basically gave up getting Gnome to play along...
Also the guy that did the 015 release claimed he spent more time getting the whole consolekit+polkit+desktop rigmarole working than getting the kernel and such going.
Some larger projects are a fair bit more hairy however (Hello Mozilla) and i think people basically gave up getting Gnome to play along...
Also the guy that did the 015 release claimed he spent more time getting the whole consolekit+polkit+desktop rigmarole working than getting the kernel and such going.
I believe it. I've paused with a "wtf" look on my face plenty of times dealing with the complexity and many odd decisions of those. It's what made me briefly use Fluxbox/Openbox distro's just to avoid the complexity. A bit too manual on the app side, though, so I reluctantly went back to a more full desktop environment. I'm sure we'll continue to see more competition in that area and maybe a solid alternative in the future to what we have.
Something similar is NixOS (uses systemd) and Guix (uses DMD).
Edit: note that Gobolinux came to be without demanding that everything in the Linux ecosystem danced to their pipe.
Edit: note that Gobolinux came to be without demanding that everything in the Linux ecosystem danced to their pipe.
That's awesome, way better than the status quo.
Archlinux has it a bit simpler than most; with /bin /sbin /usr/sbin all symlinked to /usr/bin.
GoboLinux has something completely different from the FHS.
Define "modern" and "nice".
(This sounds flippant, but is actually important as these are completely subjective. The answer may turn out to be OSX..)
(This sounds flippant, but is actually important as these are completely subjective. The answer may turn out to be OSX..)
Who has legitimately tried to improve upon either or both? Even if the definitions are subjective the problems are easier to quantify, and thus we can say improvement has achieved if the problems are lessened.
GoboLinux, I suppose. Can't say I'm personally a big fan of it, but many have given it notice.
The way I see it the whole /bin, /sbin, /usr/bin, /usr/local/bin, /usr/local/sbin and home and /var and /home/bin and friends come from the fact Unix was time shared some eons ago and designed to run on mainframe/clusters with different part of the OS living in different rooms and that carried over to Linux somehow and it made sense to map directories like that but nowadays it feels weird because we are running Debian or CentOS or BSD or whatever on a single computer that could live in the hive of a mainframe but will not. And a binary will run if the x flag is set so everything just works in the end (most of the time). Most of us are users, not sysadmin (even though reading the man page you'd think you should be one to run any distro).
It's like X. It's designed and battle tested to be ran through a network but most Ubuntu users won't ever need to know it or do it.
My pet peeve of mine is dotfiles used as configuration files. It means I can't have a clean home folder since data, ~/bin and settings(.) are all mixed up. I should be able to install apache in ~/bin and use .apache/ to configure it.
Maybe have 3 homes ? One for each purpose (data, binaries and settings). Sigh, I suppose more intelligent people than me have thought very hard about that and it'd be a pain to implement. But frankly this is cosmetic comparing to the systemd and wayland/mir topic.
Reminds me of http://sta.li/filesystem
Filesystem
This is a editable proposal for a filesystem layout that will fit the changed principles of the OS.
/bin - all executables /boot - all boot files /dev - devices /etc - system configuration /home - user directories /root - the root home /var - spool, run, log, cache /share - man pages, locales, dependencies /devel - development environment /devel/include /devel/lib /devel/src
Based on the Linux assumption:
/sys - sys files /proc - proc files
For old style emulation:
/emul - chroot for packages that are too infected
Don't know if that project is still alive though.
It's like X. It's designed and battle tested to be ran through a network but most Ubuntu users won't ever need to know it or do it.
My pet peeve of mine is dotfiles used as configuration files. It means I can't have a clean home folder since data, ~/bin and settings(.) are all mixed up. I should be able to install apache in ~/bin and use .apache/ to configure it.
Maybe have 3 homes ? One for each purpose (data, binaries and settings). Sigh, I suppose more intelligent people than me have thought very hard about that and it'd be a pain to implement. But frankly this is cosmetic comparing to the systemd and wayland/mir topic.
Reminds me of http://sta.li/filesystem
Filesystem
This is a editable proposal for a filesystem layout that will fit the changed principles of the OS.
/bin - all executables /boot - all boot files /dev - devices /etc - system configuration /home - user directories /root - the root home /var - spool, run, log, cache /share - man pages, locales, dependencies /devel - development environment /devel/include /devel/lib /devel/src
Based on the Linux assumption:
/sys - sys files /proc - proc files
For old style emulation:
/emul - chroot for packages that are too infected
Don't know if that project is still alive though.
sta.li itself is dead, but it has an active successor in the form of Morpheus Linux.
Is it the same people behind Morpheus ?
The existence of /sbin should be preserved for statically compiled programs, which are necessary for basic system administration and can't assume the system has all the basic libraries loaded.
[deleted]
No, Windows RT "Apps" are nothing about progress. It's simply MS trying to piggyback in the profitability of the Google Play and Apple stores.
There are many software packages that can install without mixing stuff, just check the option of USB install, or standalone install.
In fact, check all the applications in http://portableapps.com/
They have NOTHING to do with WinRT.
There are many software packages that can install without mixing stuff, just check the option of USB install, or standalone install.
In fact, check all the applications in http://portableapps.com/
They have NOTHING to do with WinRT.
[deleted]
The desktop linux dudes sure do pick weird topics to get excited about.
First it was cold boot time, resulting in the hilarious neverending clown rodeo that is systemd.
Then it was that they didn't understand IPC, so it was the gloriously undesigned protocol 'dbus' which has to get wedged into the kernel because the user space version is so bad that it's useless.
Now it's that there's a number of config files in /etc? And so we should take that number down to zero, because reasons?
Can't wait for them to discover that bytes are 8 bits, rather than a more pleasing 5 or 10.
First it was cold boot time, resulting in the hilarious neverending clown rodeo that is systemd.
Then it was that they didn't understand IPC, so it was the gloriously undesigned protocol 'dbus' which has to get wedged into the kernel because the user space version is so bad that it's useless.
Now it's that there's a number of config files in /etc? And so we should take that number down to zero, because reasons?
Can't wait for them to discover that bytes are 8 bits, rather than a more pleasing 5 or 10.
I have found myself thinking about the term "the road to hell is paved with good intentions" whenever some desktop Linux developer/pundit fire off a new blog/email these days.
Hey!
I love my Ubuntu cold boot time of less than a second.
I love my Ubuntu cold boot time of less than a second.
And then spend a minute watching the unresponsive desktop because all the deferred daemons being started?
Not really. I click on Skype and it's three seconds until all contacts appear, and those seconds can be blamed on the network.
The only thing that loads slowly is Chrome with my 50 open tabs, and I don't think it's the fault of the OS.
In the same hardware what you describe actually happens every time with Windows 7 (I can't upgrade the Windows version, corporate policy) and it's a really annoying process.
The only thing that loads slowly is Chrome with my 50 open tabs, and I don't think it's the fault of the OS.
In the same hardware what you describe actually happens every time with Windows 7 (I can't upgrade the Windows version, corporate policy) and it's a really annoying process.
OpenBSD has been reducing the files in the directory. I was in a bit of a panic when I noticed sysconfig.conf was missing. Now if you need to change the settings you add a local file.
Every time I read about BSDs I wanna try. The core team appear to make a coherent cohesive tractable system. Unlike the bazaar model used by Linux (intractable but working).
OpenBSD works fine in a VM. Look through the FAQ http://www.openbsd.org/faq/index.html and away you go.
The only part of installation that is a bit confusing (to me at least) is the first time doing disc partitioning. The auto is fine, but you might want to read a bit.
Install your favorite software from packages http://www.openbsd.org/faq/faq15.html and have fun. Its a simple, logical system http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man7/...
Every 6 months is a new release. Do the upgrade and then upgrade your packages. Its really pretty easy. Do patches between releases which aren't that hard, but they are not binary. The instructions on the website are simple with very direct and good warnings.
The only part of installation that is a bit confusing (to me at least) is the first time doing disc partitioning. The auto is fine, but you might want to read a bit.
Install your favorite software from packages http://www.openbsd.org/faq/faq15.html and have fun. Its a simple, logical system http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man7/...
Every 6 months is a new release. Do the upgrade and then upgrade your packages. Its really pretty easy. Do patches between releases which aren't that hard, but they are not binary. The instructions on the website are simple with very direct and good warnings.
OpenBSD was amazing when it still fit my server needs. I was very impressed. I would go back in a heartbeat if I could.
Any old and generic box will love it. It has ridiculously low resource demands and generic hardware will ensure you have no esoteric driver problems.
Any old and generic box will love it. It has ridiculously low resource demands and generic hardware will ensure you have no esoteric driver problems.
Why not give it a shot? Running BSD is a low cost proposition.
I don't know, the fear of hardware support, some random source of resistance that delay it. I'm sure one day I'll switch, just like when I told that old friend Windows he'd only be 3% of my computer time now. Right now I have a crippled nas4free running but I can't mess with the system too much. I'm already surprised to see subtle differences between linux base utilities. Makes you think. Also feels like LFS.
Try it out in virtualbox? Even less investment.
Doesn't tell you if your hardware will work with it, and it's too easy to just switch to the host OS when you hit something you don't know how to do rather than having to learn how to do it in the OS you're trying out.
It doesn't feel like living in it.
When did blogs start showing a 'loading' screen, then doing a weird scroll thing at load, and having stuff unfolding near the scrollbar?
When they got bloated down by designers trying to reinvent HTML 1.1 in Javascript.
This page won't show with Javascript disabled, and that's a shame. There's nothing on that page that can't exist as flat HTML. There's nothing on that page that requires Javascript, but the page won't function without it for some reason.
Do we still downvote/flag comments that aren't directly related to the content of the linked material?
This page won't show with Javascript disabled, and that's a shame. There's nothing on that page that can't exist as flat HTML. There's nothing on that page that requires Javascript, but the page won't function without it for some reason.
Do we still downvote/flag comments that aren't directly related to the content of the linked material?
Have an up vote. I get down voted every time I complain about the javascriptification of the web.
Did the same as JustSomeNobody for same reason. We did a ton of stuff without Javascript in late 90's and even automated lots of it. Even did menus without it (see dynamicdrive.com). Now even basic blog entries need it to prevent a messed up experience. "Progress." (sighs)
Least it's a lot faster & better on the sites that actually need it. :)
Least it's a lot faster & better on the sites that actually need it. :)
Having no files in /etc is considerably less discoverable.
It can be handled with good documentation or example files in /usr/share/doc but it's still harder that way.
Of course there are downsides that this article brings up. But is the problem simply the existence of a file in /etc ? Because that doesn't seem to be a problem to me, instead the problem is upgrades that are harder because they have to merge changes.
Seems to me the solution is to use 3 way diffs like how source control system do it, and update configuration files automatically as much as possible.
It can be handled with good documentation or example files in /usr/share/doc but it's still harder that way.
Of course there are downsides that this article brings up. But is the problem simply the existence of a file in /etc ? Because that doesn't seem to be a problem to me, instead the problem is upgrades that are harder because they have to merge changes.
Seems to me the solution is to use 3 way diffs like how source control system do it, and update configuration files automatically as much as possible.
I love the discoverability of /etc files, and the ability to read & edit them with whatever tools you like. If the files only included changes to default settings, and the defaults are hidden away in program binaries, how are we to discover what settings even exist in the first place?
Verbose /etc config files are human-friendly and that's a good thing. Managing updates and merging config changes is still do-able. The logic to do the merges might be more complicated, but I'd rather let the complicated stuff be handled by the upgrade tools and not forced upon the user.
Verbose /etc config files are human-friendly and that's a good thing. Managing updates and merging config changes is still do-able. The logic to do the merges might be more complicated, but I'd rather let the complicated stuff be handled by the upgrade tools and not forced upon the user.
[deleted]
its not even just a windows / unix thing.. my software company can't even pick a method.
registry keys .exe.config files .xml files .ini files .cfg files
true false entries, bitwise operators... custom "hosts" file type configs
all for one application... each developer that gets an enhancement uses whatever they want to to build/configure it.
registry keys .exe.config files .xml files .ini files .cfg files
true false entries, bitwise operators... custom "hosts" file type configs
all for one application... each developer that gets an enhancement uses whatever they want to to build/configure it.
Sorry, no. Even if it is the default configuration I want to know it, see it and be able to manipulate it whether it is my 1st or 100th time of configuring a particular software.
What puzzles me most, is why one would spent so much time looking inside /etc. Editing files inside /etc? Sure, many times per day. Opening /etc inside a file manager? Never. Running ls inside /etc? Maybe once a month.
What puzzles me most, is why one would spent so much time looking inside /etc. Editing files inside /etc? Sure, many times per day. Opening /etc inside a file manager? Never. Running ls inside /etc? Maybe once a month.
From the article: When was the last time you looked at /etc and thought - "I honestly know what every single file in here is". Or for example had a thought "Each file in here is configuration changes that I made".
I first started administering Linux servers and workstations in 1998, and /etc/ was already full of scores of config files, including such horrors as X86Config and M4-generated sendmail.cf files. (And sendmail.cf itself dates from the 80s.) There were conf.d directories and mysterious networking configuration files, nearly all of which were supplied by the OS.
In other words, this frog was thoroughly boiled 20 years ago. If the world you're looking for ever existed, it would have been back when VAXes still roamed the earth.
I first started administering Linux servers and workstations in 1998, and /etc/ was already full of scores of config files, including such horrors as X86Config and M4-generated sendmail.cf files. (And sendmail.cf itself dates from the 80s.) There were conf.d directories and mysterious networking configuration files, nearly all of which were supplied by the OS.
In other words, this frog was thoroughly boiled 20 years ago. If the world you're looking for ever existed, it would have been back when VAXes still roamed the earth.
Ditto. My name's likely in your Linux distro, but I also started in 98, and even then you would never expect a given package to work without default config files.
Is there anything out there trying to describe a whole system in a consistent way? Probably not, but some minimal standard would go a long way.
For me the fact that each software has a different syntax (some even use programming language for configuration purposes) is what makes life hard.
For me the fact that each software has a different syntax (some even use programming language for configuration purposes) is what makes life hard.
NixOS
> In NixOS, the entire operating system — the kernel, applications, system packages, configuration files, and so on — is built by the Nix package manager from a description in a purely functional build language. The fact that it’s purely functional essentially means that building a new configuration cannot overwrite previous configurations. Most of the other features follow from this.
> You configure a NixOS system by writing a specification of the functionality that you want on your machine in /etc/nixos/configuration.nix.
https://nixos.org/nixos/about.html
and
GuixSD
> The Guix System Distribution supports a consistent whole-system configuration mechanism. By that we mean that all aspects of the global system configuration—such as the available system services, timezone and locale settings, user accounts—are declared in a single place. Such a system configuration can be instantiated—i.e., effected.
> One of the advantages of putting all the system configuration under the control of Guix is that it supports transactional system upgrades, and makes it possible to roll-back to a previous system instantiation, should something go wrong with the new one (see Features). Another one is that it makes it easy to replicate the exact same configuration across different machines, or at different points in time, without having to resort to additional administration tools layered on top of the system’s own tools.
http://www.gnu.org/software/guix/
http://www.gnu.org/software/guix/manual/html_node/System-Con...
> In NixOS, the entire operating system — the kernel, applications, system packages, configuration files, and so on — is built by the Nix package manager from a description in a purely functional build language. The fact that it’s purely functional essentially means that building a new configuration cannot overwrite previous configurations. Most of the other features follow from this.
> You configure a NixOS system by writing a specification of the functionality that you want on your machine in /etc/nixos/configuration.nix.
https://nixos.org/nixos/about.html
and
GuixSD
> The Guix System Distribution supports a consistent whole-system configuration mechanism. By that we mean that all aspects of the global system configuration—such as the available system services, timezone and locale settings, user accounts—are declared in a single place. Such a system configuration can be instantiated—i.e., effected.
> One of the advantages of putting all the system configuration under the control of Guix is that it supports transactional system upgrades, and makes it possible to roll-back to a previous system instantiation, should something go wrong with the new one (see Features). Another one is that it makes it easy to replicate the exact same configuration across different machines, or at different points in time, without having to resort to additional administration tools layered on top of the system’s own tools.
http://www.gnu.org/software/guix/
http://www.gnu.org/software/guix/manual/html_node/System-Con...
Another reader posted this Linux. It's filesystem is truly a 180. Plus backward compatible.
http://www.gobolinux.org/?page=at_a_glance
http://www.gobolinux.org/?page=at_a_glance
The whole filesystem layout is pretty poor, with massive amounts of inconsistencies (/bin, /sbin, /usr/bin, /usr/local/bin, /usr/local/sbin) between different software and even distributions. So you just wind up with everything scattered all over the place, and package managers exist essentially to corral the mess.
Everyone loves to talk about how UNIX is simple, and how UNIX concepts date back to at least the 1970s, and while that is true in theory, in practice the inconsistent behaviour and lack of much evolution has ultimately meant that UNIX's simplicity doesn't scale very well as the systems become more complex with more moving pieces.
But nobody is willing to touch or even criticise the mess that is modern UNIX because they know they will get massively criticised by the old guard and the die hards (see systemd, which is trying to evolve classic UNIX concepts and getting massively attacked, even death threats as a result).
Windows' file system is also a mess. But at least Microsoft are trying something with Windows RT "Apps," at least they're trying to move forward and progress. The UNIX world is in cryogenic suspension, even Apple has only hidden a lot of the mess and not really fixed much of it.