221–230 of 306 posts
Earlier quoted context omitted.
Coming from a Linux background, what is the windows registry and why do things need to write to it? All I ever read about it seem to be horror stories. Can't you store stuff alongside the install? Or in some user data location?
It's just /etc
Some files in /etc have manpages.
It feels like the Windows Registry is one of those well-intentioned ideas that ended up being a tremendous mess in actual implementation. "Let's use a central database to store things that the OS, drivers, and UI need to access" somehow became "half assed KV dumping ground for every process and their dog to litter with whatever while acting as a singular bottleneck". See also: https://news.ycombinator.com/item?id=322…
The real issue is that this is known since Win 95 days , yet some people don't get it.
Earlier quoted context omitted.
I don't think FTL drives were ever going to be in KSP2. Interstellar travel was going to be via torchships. You can argue _those_ are unrealistic, but they're at least feasible without needing to break the fundamental laws of the universe.
I thought it was warp drives, and possibly stargates. (See the arches with the carvings on Mun). Regardless, we're talking travel time in hundreds of years. Even with time warp, that's pretty boring.
Earlier quoted context omitted.
> Coming from a Linux background, what is the windows registry and why do things need to write to it? All I ever read about it seem to be horror stories. The Windows Registry is the NT Kernel's system config/preference store. The closest Linux equivalent is dconf. Like dconf it is built to be a read-mostly/read-optimized database. It's not as strongly focused on a service-bus architecture as dconf. It tries to heavil…
A bit weird that cross platform apps use dot files or dot directories directly in %Home% on Windows. If they already are cross platform, thus taken the time and resources to do that, why not add a compile flag to move them into %AppData%?
One of the things that made a work computer more complicated than it needed to be was that part of the network setup redirected %Home% some of the time to a network drive (Z:) (a "Home" drive) and other times %Home% was still on the default drive in the default user folder location. I'd constantly have to copy files like npm's .npmrc from one folder to the other to make sure that every use of npm found a right copy of .npmrc.
That "home drive" setup is a relatively common in my experience ancient Windows corporate hack for hand roaming some user files (sometimes including %Documents% which was likely the real intent but %Home% used to be easier to redirect than just %Documents%), so there is a sense of irony in some tools using %Home% as a non-roaming storage only to have it haphazardly roam due to some ancient corporate policy. It's also funny that it is possible for there to be two %Home% folders on Windows in competing locations with different contents, because the %Home% redirect seems buggy.
I think part of it is that there is a growing sense on Windows that %Home% is for "non-roaming, developers might to text edit this" configuration and %AppData% is for more UI-driven config that is less expected to be edited. A lot of developers learn %AppData% just fine, but there is some cross-platform convenience for developer life if you can always in PowerShell (or bash) just vim `~\.somercfile` and expect that to always work. But I still think using %AppData% more consistently is possibly a better thing for Windows apps to do.
KSP2 is really becoming the premier example of "Nearly perfect labour of love's legacy ruined after being bought by a larger company." More on topic: I have no idea why one would want to use the registry to store this information.
Well, kinda. Big company just bought IP and hired small "labour's of love" company to do it. The ideas how to progress the game were great! And players liked it! But after failing the deadline twice (I assume they lied to take2 about funds required) T2 kicked them off the project and poached developers that did it (basically "if you still love KSP come work for us). And again, it looked great! The improvements they w…
Earlier quoted context omitted.
How do you find it? How do you install it? Do you need root/admin permissions to create it? How do you provide access control for it? There's a lot of value to having something like this "built in" where the plumbing isn't something you worry about. You don't have to worry about the state of your users' file systems (User deleted 'My Documents', User doesn't have a $HOME folder, you don't have write permissions for %…
> I think if someone went off and redesigned a global KV store for an OS they'd probably require authentication tokens for mutations, so your app would only be able to communicate with the subtrees of the store that it has permissions to (but also, kind of like a file system?) If I had to design an OS from scratch, this is basically what I would do. I'd provide an API for a prefix-tree based KV store with specific da…
Earlier quoted context omitted.
[dead]
No guesstimates, but it's generally very bad. Especially when there's some corporate "security" software in the loop. And that's the case you have to really code against.
Earlier quoted context omitted.
> what is the windows registry and why do things need to write to it? It's a centralized, high-performance small key value store that's the alternative to writing a million config files in random places. It's arguably much better in my experience. E.g. one of the never-ending headaches I always have on Linux is updating config files when a package updates. There's no automatic file merge in general (hence .pacnew and…
"high-performance" We might have differing opinions about that. (I've got experience for example in Windows kernel mode drivers and service development.)
Also note that performance isn't just speed either.
Earlier quoted context omitted.
No guesstimates, but it's generally very bad. Especially when there's some corporate "security" software in the loop. And that's the case you have to really code against.
You already realize it's your security software that's slowing your system calls. Blaming it on the registry makes no sense. It's like blaming HN for being slow because your ISP is slow.
Besides, registry is not a rocket even on a clean system.
Earlier quoted context omitted.
"high-performance" We might have differing opinions about that. (I've got experience for example in Windows kernel mode drivers and service development.)
What are you comparing against here that's leading you to a different opinion? Are you claiming file I/O would be faster or that you could write the equivalent functionality faster? Also note that performance isn't just speed either.