Hacker News Reader

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.

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)

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.

> /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 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

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.

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.

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)

> 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.

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"...

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

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.

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.

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.

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.

'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.

diff

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.

because when something gets corrupted, the damage is limited.

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.

> 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.

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.

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.

> Ugh, the registry was etc but strictly worse.

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:

   /etc/rc - command scripts for system startup
   /etc/netstart - command script for network startup

There are countless others there. /etc/daily, /etc/weekly, etc (pun intended).

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.

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.

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

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.

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

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.

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.

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.

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.

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..)

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.

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.

sta.li itself is dead, but it has an active successor in the form of Morpheus Linux.

Is it the same people behind Morpheus ?

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.