Unix simply doesn't have a "way" in that regard, other than a loose convention to put text files in "/etc". Every application comes up with its own format. Parsing that file is application-specific. Updating a value in a text file means re-writing the whole file again. It is a technically-inferior approach that has survived in time because text files are still text files.
So? The registry doesn't have much of a way either - the actual fields are simply a loose convention.
> Every application comes up with its own format.
Same with Windows applications - one application might store an IP address as a dotted-octet string, another might store it as a single 32 bit integer.
> Parsing that file is application-specific.
Same for Windows applications; the subtree for any application is very specific to that application and almost always differs from the subtree for other applications.
> Updating a value in a text file means re-writing the whole file again.
Not a problem, when it means that breaking a value in a text file breaks only that one application. Break the registry almost always breaks something else, if not the entire system.
I'm not saying files in /etc aren't without their problems, I'm saying that all /etc problems are already present in the registry, but the registry adds a few more of its own.
Let alone some windows program end up just save a blob in it and totally ignore the typing.
Who care about the field type if I can save everything in a single blob(?
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\BrowserEmulation\ClearableListData]\UserFilter
Er-readying values isn’t done usually with apps.
You can get corrupted files if two instances fight for the same file. If that’s your thing, please use mongo. Also, please provide support to all the users.
Lastly, if you messed up certain configuration or data files, your system won’t boot either on ANY system.
Sounds like you’re just one of many anti-windows people, exactly what was pointed out about people bashing the registry.
You're right, you shouldn't. If you are able to, your distro is very odd and I'd recommend seeking a new one.
> Sounds like you’re just one of many anti-windows people, exactly what was pointed out about people bashing the registry.
There's no need to attack people.
If you absolutely could not write to /etc, then you would never be able to change your password.
The passwd, chsh, chfn, and other utilities allow a non-privileged user to make controlled changes to privileged files via the setuid/gid system calls.
A user can trigger controlled writes to files in /etc.
Since we're talking about Linux, I would refrain from using absolute clauses like "never".
systemd-homed allows you to create "portable" user profiles which contain everything pertaining to a particular user, including his password. So user profiles (including your files, etc) can be moved between computers simply by rsync'ing that directory, or putting it on a network share.
`homectl passwd` (which changes a portable user's password) does not require writable /etc.
I think I've seen a few other solutions like that.
The administrator in this case has an automated tool that handles this requæst but the actual user the writing occurs under is the root user.
Personally, I feel it is the same thing.
I don't believe you can. What distribution is this?
There’s no /etc for users. That’s why we get all these dot.dirs. At least some apps use ~/.config/
https://specifications.freedesktop.org/basedir-spec/basedir-...
It’s not a choice. It’s the default. It’s like saying it’s a choice to run mongodb without authentication.
Lastly, why should I be using XDG Desktop variables on something that don’t haveA desktop environment?
It always seems like registries are trying to solve three different problems: configuration, status and process shared state. Registries seem to work poorly compared to text files for configuration, and work somewhat well for some level of shared state. I think to compare functionality with Linux, you would have to compare /etc, .configs and the /proc filesystem.
As for tecnically inferior, the *ix approach seems to have made the right tradeoffs, via the hand of Darwin, rather than some brilliant engineering insight. The article did a good job of explaining what's wrong with Windows' implementation of the registry. What is right with the *ix approach is that configuration files are usually read on startup, and only written to when configuration is changed (which should be infrequent). This works really well for server software, command line utilities, and an awful lot of GUI software. For some GUI software, particularly where you have really complex feature sets, we need to save state of widgets (i.e. saving the default zoom level) and text files may be problematic for this (i.e two instances of the app running), and this is where the registry really shines.
What do you mean? You are mixing multiple things, most of var and lib are also only root writable (unless tied to a specific user). For GUI application you generally end up with a system where etc holds the system defaults and user configuration is in $XDG_USER_CONFIG which defaults to $HOME/.config. This is the case for the vast majority (>90%) of GUI applications.
If we're are talking state, that typically ends up $HOME/.cache (if it should be temporary) or $HOME/.local/var (if it should be persistent). There are also XDG variables for these but I forgot them at the moment.
So can you elaborate what you mean with your perceived problem?
freedesktop.org is that central documentation. Sure, there are applications that don't implemente that spec but it is not for there not being any documentation but either because the maintainers of those applications don't care or because the applications are older than the spec and moving configuration is not always trivial.
One Rust example being https://github.com/dirs-dev/dirs-rs
> The library provides the location of these directories by leveraging the mechanisms defined by
> the XDG base directory and the XDG user directory specifications on Linux and Redox
> the Known Folder API on Windows
> the Standard Directories guidelines on macOS
I really wish that was true but nasty stuff like wpa_supplicant/, resolv.conf (now usually a systemd-resolved managed symlink), NetworkManager/ and X11/ lives there, very mutable and often constantly changing under the hood.
Configuration for all supported packages is stored in files under /etc/config in UCI's own text format, and OpenWRT's init scripts generate service-specific config files based on the UCI settings when the service is (re)started. For example, to configure Samba, users don't edit smb.conf directly, they set UCI settings like samba.workgroup, sambashare.path, etc.
There's a `uci` command-line utility to read and modify settings, and UCI forms the basis for the OpenWRT web interface.
debconf does something similar for Debian packages, though I haven't seen any packages that use debconf to completely supplant vendor configuration formats the way UCI does. https://en.wikipedia.org/wiki/Debian_configuration_system
But more seriously, what do you want from an OS? Cleaner design? Plan 9 comes to mind. QNX is very elegant, too. Some microkernel thing? Fuchsia, but some say it's inelegant and overdesigned right off the bat. Minix has some nice properties but somehow nobody but Intel seems to use it. Also, QNX again (but as the name suggests it's similar to Unix)... Distributed computing? I don't know, seems OK to run it mostly in user space.
My favorite alternatives are Plan 9, QNX and L4 (I know it's not an OS), of which QNX is the only one I have actually used. Shame about Fuchsia, I believe the negative opinions because I looked at some documentation and code before I read them and had a sort of "THAT is supposed to be Google's better OS?!" moment.
It seems strange that we are essentially trading on isotopes of OS thinking from about 2000 when Linux took the mantle of UNIX and Windows converged on the XP code.
Is this it? Is producing an OS now so incredibly expensive and hard that we are never going to try again, and just keep bolting things on to what we have? I feel a little sad at that, even if the reasoning is impeccable.
Overall, really cool idea (dropped my jaw when I first saw it in action), but poorly implemented.
What's rather messy about Nix is nixpkgs with its helper functions all over the place alongside pretty shallow / non-existent documentation (which is unrelated to the language). Thankfully they've started to work on that recently: https://discourse.nixos.org/t/documentation-team-flattening-...
Well, there's Haskell, and I expect any Haskell programmer to be able to pick up Nix very quickly.
Guix has gone with a strict language, Scheme, but I understand they have their own monadic DSL to cope with the peculiarities of following the Nix model. So again, not something that a mainstream language can do well, and even as a Schemer, you're going to have to learn their macro language.
The latest release has included "flakes", promoted from an add-on to an opt-in feature and which, among other things, lets me pin my dependencies and the environment I need to build my private projects. I then don't have to worry about going out of sync with the main package set, and I can share private projects in a (hopefully) fully reproducible way, with people using different versions of nix.
I think it's also really easy to underestimate all the tooling built around text. As soon as you try out some other way, you loose out on version control, diffing, grepping, and a whole bunch of other general tools built for text.
I think the only way to get around this is to build generalized tools for working with binary data as a data structure. The problem with this approach is that now you need to maintain a database that describes every possible binary format, where text editors only really have to concern themselves with ASCII & unicode to be useful for most cases.
The baseline is only text and files on systems that don't have anything better to offer.
Something flexible like FuseFS is sorely missing on windows, the stuff google drive had to do creating a new letter drive is pretty gnarly.
Also pretty much all external programs on Windows. Anything that isn't itself implemented as a PowerShell cmdlet has this problem. And it's all shell-specific.
But in tons of situations actually doing anything that way involves a ton of boilerplate, and it's very clunky. It's acceptable for automation, but it's not something that feels very good to do in an interactive shell.
Stuff like Convert-FromJson is nice, but it's not as nice as whole ecosystem there the interchange format for external programs is sort of just 'understood'. It's also not streaming— it reads in a single JSON object as a string. So you need some extra boilerplate if the expectation is that you're piping output from a command that yields a stream of data.
PowerShell is great, but an environment where streaming objects in some other format between different programs, regardless of the languages they're in or the runtimes they use, would be better and closer to a real version of 'Unix pipelines but with objects'.
If you lament this as a programmer, build applications that only work on your OS of choice, make them so good or take a dependency on a feature not available with macOS or Windows so that it can’t be ported, and then you can show the world the light of the UNIX mentality or whatever.
The flip side of this argument is that the experience of using computers for that 99.9% of users sucks.
As software engineers, it's almost our responsibility to argue in favor of better platforms, because every day not spent fighting the platform is a day we could be building better experiences for our users. (Not to mention, every day the platform doesn't inadvertently mess up the user experience is a day of smaller support costs.)
Secondly with device drivers being tied to the registry there is not a simple system upgrade of taking out the hard drive and placing it into a new computer.
Just not everyday occurrences for most but still exist.
I personally do this all the time. At most you get an extra restart the first time the drive is in a new set of hardware and after that you're good to go.
My main Windows install is probably 8 years old at this point, it's gone between multiple motherboards.
The biggest annoyance is a few pieces of software that tie activation to the motherboard.
If you want to make it even more portable you can install Windows to a vmdk.
And if you want to get a special complicated, you can have that vmdk act as essentially a secondary variant of your main operating system complete with symlinking most of the files and application info, to both save space and so you have most of the same state across both os's, but still can play around and easily roll back any changes.
And cumulatively I spent significantly less time on Linux than I did on Windows.
Of course most people don't care about those things, but as a developer, the main issue I see with Windows and macOS, is that they build specialized interfaces that lock you into certain ways of doing things, which may be convenient, but are difficult to migrate away from, and a pain to automate and reproduce.
I really value that the UNIX philosophy is geared more towards building simple tools that are designed to be combined with other simple tools to solve a more complex problem, and that it doesn't try to lock you into using any particular tool to solve a problem.
So no, I may not provide binaries for Windows & Mac for personal projects, but I'm not going to be openly hostile towards people who want to build things from source or contribute fixes for Windows & macOS.
The bet on "everything is an object" was a honest and competent one, but unfortunately it didn't work. "Everything is a file" works better on practice. Unfortunately, that was the last real attempt on Windows to improve things.
Yes, the lack of diversity in OSes is bad. But Windows doesn't fix it. (Android and iOS were the last large attempt of innovation there, and implemented some really good things, but it's also useless to have the OSes completely managed by large corporations that antagonize both their customers and society as a whole.)
With the right interface, the object approach can be more pleasant to use. Administration via PowerShell is way more consistent than in Bash.
Unless you meant OS/2? My understanding is the original intent there was very much to make everything an object,and the UI fully composable based on that ( in the sense of being able to link things together semi-arbitrarily, like pipes, only they never got that far )
But that's based on a half remembered article from years ago, I may have that completely wrong.
Agree with the other post that PowerShell's object view of the environment is pretty nice - not always a panacea of course, but mostly highly functional and productive
Plan 9 was supposed to be the better designed UNIX all around and it did not even dent it. It wasn't significantly better that UNIX to displace it.
http://www.catb.org/esr/writings/taoup/html/plan9.html
> We know what Unix's future used to look like. It was designed by the research group at Bell Labs that built Unix and called ‘Plan 9 from Bell Labs’.[154] Plan 9 was an attempt to do Unix over again, better.
> The long view of history may tell a different story, but in 2003 it looks like Plan 9 failed simply because it fell short of being a compelling enough improvement on Unix to displace its ancestor. Compared to Plan 9, Unix creaks and clanks and has obvious rust spots, but it gets the job done well enough to hold its position. There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough.
UNIX was also written to run on minimal hardware. Even if Multics had been open-sourced, UNIX would still have won.
https://distrowatch.com/dwres.php?resource=links
It's just that they don't have market share or a raison-d'etre for widespread adoption.
I would actually not even compare it to them, and just say it's flat out Radical.
Its only really big misstep (apart from the fundamental issues with the registry in general) is that file associations and COM registrations are all intermingled in the same namespace. But those can be and are interconnected (see how the Office file types handle their registrations, for example), so it's kind of understandable how they ended up where they did.
Except that is for serving from a single file share ir a replicated site across a farm of IISes.
This has nothing with 'complex configurations'
Configurations under unix are a mixture of stdin, config files, env variables and bespoke solutions.
Under Windows, you have all of the above and on top of that the registry.
Any attempt at a solution in this regard risks being a rerun of the notorious xkcd: 14 ways to specify configurations -> this should satisfy everyone -> 15 ways to specify configurations.
It's not just "another option". It's a system standard option that exists, and can be easily accessed programmatically. There's no equivalent in Unix, since there is no standard, and whatever is available will depend on the distribution.
"Here's a built in option, but do whatever" is very different than "do whatever!".
As your link show, Windows has homogeneity, with good config options built into the frameworks. In those frameworks, those built in config options can't be consider just "another option". There's no real homogeneity in *nix, so the only options is misc files to put misc paths.
Yes. Nothing standardized in this area in UNIX/linux-land. We do have FHS, some xdg specifications and the series of configurations options that were born with dconf which resemble windows registry a bit.
For user-specific configuration there's also ~, as with ~/.vimrc and ~/.bashrc. Windows has something similar in C:\Users\theuser\AppData.
edit And ~/.config/, as others have mentioned.
GNOME has the gsettings command for this, which is the equivalent of the `defaults` command in macOS. Many guides still refer users to the `dconf` command, though, which is technically a lower-level tool but basically does the same thing for 99.999% of GNOME installations. (Users/distro-makers can actually choose the storage format on GNOME's case.)
With luck you might be able to find the correct terminal commands to disable services and fingers crossed they don't automatically restart themselves before you are done editing.
(Open)LDAP uses a hierarchical structure and saves its data in a database:
* https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Databa...
The religious text files scattered everywhere on the FOSS clones?
The adoption of registry ideas by GNOME on gconf?
The configuration databases used by HP-UX and Aix?
The plists used by NeXTSTEP and macOS?
The settings per app used on Android (technically UNIX based at its Linux kernel)
Unix is a bit of a mess, at least that's understandable because it's 'open'.
MS registry is a bit nutty, it should be refactored in some simple, clean way, which is apparently extremely difficult to do for big companies, especially those that consider 'backwards compatibility' to be 'everything'.
Thank god there are companies that still think about backwards compatibility and are not intent in breaking everything because there's a shiny new thing ... ahem ... "refactoring in some simple clean way"
'Backwards Focus Absolutism' means we live in a world of stupid cobwebs and terrible design. The Windows Registry is a hack, it was originally designed to do something mundane and simple. It just grew, like a virus.
It also means that until ~Windows 7/10 you could run even win3.1-era apps. And you didn't run into situations like "any 32-bit apps no longer work" or "any apps not updated in more than a year will be removed" as we've seen with Apple.
"If a change results in user programs breaking, it's a bug in the kernel. We never EVER blame the user programs. How hard can this be to understand?" - from his famous rant [1]
So Linux prioritizes backwards compat as well. It would be insane for any project relied on by half the computing world not to. MS just throwing out their registry and rewriting it would probably break a million programs and possibly break literal billions of people's computers in some way. Its a universal problem - the more dependants any piece of code has, the harder it is to change.
I think this is insane and narrow minded.
I suggest there should be 'eras' of version where things do change.
If they make OS changes, notify early, prepare basic materials, create 'auto-updaters' and allow a few years for change.
But it needs to be done.
https://www.ibm.com/docs/en/aix/7.1?topic=subsystem-device-c...
https://docstore.mik.ua/manuals/hp-ux/en/5992-4616/ch01s01.h...
The one thing you lose by using a real database is that filesystems are only locally coherent, while databases try very hard to be globally coherent. If it has heavy access, the database way will lose performance much faster.
I think you'd get slightly more performance if you were to store "Folder" and "Key" separately -- either three fields or using a parent-child table. You'd be able to index "Folder", and it would make building the tree structure itself easier and more efficient, and looking up all the values in a specific tree simpler.
One of the critiques in this article is that, because you have to know/guess/assume what encoding is used for various strings, there isn’t one for the registry, either.
If so, both approaches suffer from that (but Unix a bit more because it tends to store multiple items under a file system ‘key’, while Windows programs rarely store multiple items under a single registry key)
I do wonder what RegEdit.exe does here. Does it infer encoding, have a long list of key-to-encoding mappings, or a combination of the two?
I did a bit of experimentation on this too and we think it has a heuristic to guess encodings of strings. (Which to be fair isn't a terrible idea - it's very easy and almost entirely reliable to determine if a string is ASCII/UTF-8 or UTF-16LE which are the major encodings found.)
If the data has the REG_SZ, REG_MULTI_SZ or REG_EXPAND_SZ type, and the ANSI version of this function is used (either by explicitly calling RegGetValueA or by not defining UNICODE before including the Windows.h file), this function converts the stored Unicode string to an ANSI string before copying it to the buffer pointed to by pvData.
[1]: https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf...
Anyway, where in the hivex code do you handle these non-Unicode encoded REG_SZ values?
Btw, the comment for hivex_value_multiple_strings is based on a mistaken interpretation of the documentation. There's nothing contradictory to what MoveFileEx does[1], it simply has a list with a single entry in the case of deletions, and a list with two entries in case of renames.
The REG_MULTI_SZ documentation[2] just points out, correctly, that you can't have a zero-length string within a list of other strings (ie with at least one non-empty string after it). This is of course obvious and hence redundant, but they highlight it for novice programmers.
[1]: https://docs.microsoft.com/en-us/windows/win32/api/winbase/n...
[2]: https://docs.microsoft.com/en-us/windows/win32/sysinfo/regis...
Here's an example of someone doing that very thing.
It's an interesting point and it would really be nice if there were some kind of standard, especially a standardized C library within the standard C library for configuration files, but in practice almost all of them are also easily understood `key=value` pairs that only differ by how they denote this.
Still, it would be very nice to be able to inspect and modify them by standardized tools but in practice almost any configuration file opened is obvious.
Today, there is no broadly used file system that can replace any of this. The difference in performance is just too big.
Any files that would be expected to be in shared directories like /usr/bin, /usr/lib or /etc, are replaced by symbolic links. Except for symbolic links, the installation of a package must not change anything outside its private directory.
In my opinion this is the only sane way of managing software packages, because otherwise, also on Linux, but especially on Windows, I have wasted far too much time during the years with debugging various problems caused by the installation/uninstallation programs.
https://docs.microsoft.com/en-us/deployedge/configure-micros...
> You can also use REGEDIT.exe on a target computer to view the registry settings that store group policy settings. These policy settings are located at this registry path: HKLM\SOFTWARE\Policies\Microsoft\Edge.
Which are these? I assume Qubes OS sidesteps the problem entirely... NixOS?
Apache Jackrabbit Oak [1] implements a tree-format data model called JCR [2]. It's used as database engine for the Adobe Experience Manager (enterprise-level CMS).
[1] https://jackrabbit.apache.org/oak/docs/ [2] https://en.wikipedia.org/wiki/Content_repository_API_for_Jav...
Wasn't there a SPARC port of Windows? Did it run on any other big-endian machines? Were the MIPS and POWER ports little-endian?
In any case, I can see why Microsoft paid SQLite for a custom set of features.
https://web.archive.org/web/20190108142751/https://blogs.msd...
I think you might mean relational database. IIRC, the registry is already a database, just not a relational one.
Instead I would make an HTTP like interface where you talk to a service that provides the get/set functionality and which always use a text format like an extended JSON with native support for date, int32, etc.
This also enabled much easier and better backwards compability as you can specify app-version in the requests, so a version 5 server can respond in version 4 format.
With a service it doesn't matter if things are stored as a single sqlite DB or as multiple files.
There would be two use cases, storing hierarchical/tree like data aka JSON, YAML, etc and arbitrary graph like data with complex references.
The same could be done with the shell. libcli would be called to parse the command line arguments and your program will have an entry point that receives the parsed data.
libcli could also be used to produce structured program outputs which then can be fed into applications, possibly skipping the serialisation deserialization steps.
Since libcli will have a standard interface each distro can choose their own CLI format or whether they output their data as JSON or CBOR.
In both cases the benefit is that the choice of the data storage mechanism has been decoupled from the application.
I mean, the versioning part sounds good, but JSON like request?
I do believe people don't know what inefficient/efficient a system can be depending on the data format they are using.
It's tooling created for security and forensics that tries to manually read it.
Registry settings already have ACL items applied. You can see this behavior if you log in as a non admin user then try to view another users registry settings.
https://docs.microsoft.com/en-us/windows/win32/sysinfo/regis... The thing is pretty free form with a choice of some very basic data types dword/qword and strings ascii/unicode/lists of strings.
Adding a wrapper around the existing call to go towards a json schema registry could be a helpful thing.
I suspect if the concept of the registry was created today it would look more like a database (e.g. Sqlite), although organizing it like a virtual FileSystem does have a certain appeal, and unfortunately I don't know of a database engine that supports such a layout. The Registry's Key-Value pairs are 1:1 with a database table's column-values pairs, it is just the multiple tiers of organizing "folders" above that that are a difficult implementation detail.
The UNIX way is undeniably more flexible since it isn't a virtual filesystem, it is just a filesystem. The problem is that everyone invented their own configuration format to store configuration data in /etc and there's no format agnostic API to access that information (you can open it, but can you understand it?).
Both UNIX and Windows suffer from the same orphan issue wherein information can be written, the application removed, and it is unsafe to ever remove it since you may not know the author and or all consumers.