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).
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.
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.
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.
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.
Everyone always gives the Windows Registry guff. 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. And now you're seeing tooling, like Docker, which is specifically designed to isolate the mess around each mess-user (essentially creating a bundle of mess).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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 ?).
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.
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.
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)
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.
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.
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"...
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.
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.
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.
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.
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.
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.
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.
You can diff registry files and any subtree. You could diff the entire system if you wanted to. Yes, you do have to export to files but you still get one consistent format no matter how deep you want to go.
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.
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.
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.
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.
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?
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. :)
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
> 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.
102 comments
[ 4.1 ms ] story [ 147 ms ] threadThe 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.
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.
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.
Edit: or most systems, the point is that the ugliness is not intrinsic to unix-likes
(This sounds flippant, but is actually important as these are completely subjective. The answer may turn out to be OSX..)
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 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.
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.
Edit: note that Gobolinux came to be without demanding that everything in the Linux ecosystem danced to their pipe.
Anyone who actually threatens someone over a Linux process should be mocked openly and probably forever.
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.
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 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.
Really?
C:\Windows - Windows itself
C:\Program Files - Applications
C:\Users - User data
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.
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 ?).
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.
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)
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.
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.
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"...
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.
http://vpri.org/html/writings.php (search for 'steps' reports, last from 2011)
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.
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.
Really? On which versions of Windows does the registry include executables critical to system function?
E.g. man page synopsys for just two programs:
There are countless others there. /etc/daily, /etc/weekly, etc (pun intended).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.
There might be an argument to be made but it's clearly not unambiguously wrong.
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.
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.
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.
Explaining a confusing standard does not make the standard clear or good.
It's a very poor designer that blames their users.
Would you call someone out writing a Windows application that didn't install its binaries under PROGRA~1? Same principle.
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man7/...
https://www.freebsd.org/cgi/man.cgi?query=hier&sektion=7
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.
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?
Least it's a lot faster & better on the sites that actually need it. :)
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.
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.
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.
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.
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.
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 love my Ubuntu cold boot time of less than a second.
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.
For me the fact that each software has a different syntax (some even use programming language for configuration purposes) is what makes life hard.
http://www.gobolinux.org/?page=at_a_glance
> 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...