6 ms·

I'm sorry but you seem to be misplacing a lot of your judgments. NTFS is awesome. What's not so awesome is the performance of Windows's I/O subsystem when openi

I'm sorry but you seem to be misplacing a lot of your judgments. NTFS is awesome. What's not so awesome is the performance of Windows's I/O subsystem when opening files, and this doesn't really have much to do with NTFS. Also I don't know how you're compiling files, but if you're using GCC and observing it to be much slower than on Linux, you should be aware that that's a GCC issue and not an OS issue; it neither happens with Clang, nor with MinGW versions of GCC. As for the whole "registry is flawed" thing, I've never heard one good argument for that assertion. It's a meme people keep repeating without even bothering to make good arguments for it. "Trying to bring every setting and registered library into one single infrastructure" is literally what the filesystem does too. Except if you're on Linux it drags in random stuff like /proc and /dev in for the ride. All the registry is is a very fast and well-implemented hierarchical key-value store for small bits of data. Either you want such a thing, in which case the registry is a great implementation, or you don't, in which case the problem isn't the registry. I haven't experienced greater joy dealing with ~/.config or dconf than the registry, but if you want those you can always use %AppData%.

throwaway675309 5y ago
I don't know if they've changed it, but I can think of one very simple disadvantage to the registry in about five seconds, and that is that they combined windows registry settings and user application registry settings into the same registry which meant that they were acting in the same space which from a security / permission standpoint as well as from a possible data loss and corruption standpoint is TERRIBLE; they should've had physically separate registry hive files for each of these spaces to keep them separate and protected.
- dataflow 5y ago
  I don't follow, sorry. They aren't in the same "space" any more than files are in the same "space". Users put files in C:\ and so does the system, so filesystems are terrible?
- legalcorrection 5y ago
  More poorly informed registry bashing. 1. Every registry key can have its own ACL (Access Control List). So you can have highly granular permissions. 2. "The registry" is not stored in one file. It's actually a few different hives which are stored as separate files. Your user-level registry settings are stored in your user profile (i.e. home directory) and roams with your user account to different machines in a domain.
rwmj 5y ago
https://rwmj.wordpress.com/2010/02/18/why-the-windows-registry-sucks-technically/ https://rwmj.wordpress.com/2010/02/18/why-the-windows-regist...
- dataflow 5y ago
  Ok fine, I'll bite. #1 is pretty terrible. It's like complaining that a bicycle is a half-baked car. #2 (and part of #1) is also irrelevant. "The format is badly constructed, fragile, endian-specific, underspecified and slow." So what? The file format is not the business of anyone actually using the registry, and nobody was making claims about the file format anyway. What you have is the APIs and the guarantees those provide you. Complaining about the file format when you will never even be accessing the file contents is like complaining that the remote engineer you hired has a rip in their T-shirt. You just care because you're breaking into the house from Linux and then getting upset that it doesn't look the way you like. #3 is again pretty terrible. "The upshot of this is you can easily hide stuff in the Registry binary which is completely invisible to Windows." OK, so if you don't like that then don't do that. I'm sorry (?) the Windows registry was not designed with making life easy for Kali Linux hackers. #4 is at least on the same planet as something I could consider as maybe vaguely interesting. But it's not like your life is any different on a filesystem. Even .txt files could be ASCII, UTF-8 with BOM, UTF-32, or some weird code page. If you hate that fact of life, you need to direct your hate toward the person who made the file whose contents you're trying to read. #5 is vaguely interesting but again, practically irrelevant for people writing applications (unless you're writing a registry editor I guess). It's more relevant for end-users dealing with .reg files, and the interchange format for them is pretty obvious: follow whatever regedit does. If you find that file format poorly documented... big deal. Just export what you want and look at how it gets encoded, and you'll remember it thereafter. "The registry sucks" does not follow from "I have to spend 5 minutes figuring out how to write this text file for something irrelevant to >99% of use cases because it's not well-documented". If that's your standard then the Linux kernel would be an absolute dumpster fire with how lacking it is in the documentation department. #6 finally something I can at least comprehend. OK, so evolution & backward compatibility introduces some warts, just like it does on Linux or any other OS. Documentation of internals could probably be better... just like with Linux or any other OS. Though "non-standardized" is a strange complaint for Windows, given there aren't 1000 different companies releasing their own Windows distributions like there are with Linux, for whom having a standard would actually make sense. And it's not like you don't have %AppData% at your disposal if you really like files. #7 is again like #1. The registry is intended for low-latency, low-throughput access to small bits of data. The filesystem is intended for high-latency, high-throughput access to large & growing data. You don't complain that your knife can't cut down trees; you use a chainsaw instead. You need to use the right tool for the job. "It should be a database!" ...sure, so should ext4. #8 is almost onto something here, but misses it and veers 90 degrees in the wrong direction. The argument you could make is "it's difficult to manage registry ACLs separately from the filesystem", which I could understand; Windows security is complicated, which is not great for security. You could flesh this out into a good argument here, though it wouldn't really be specific to the registry. But the grumbling (yet again) about the format of the hive file because it's not "hackable" enough for Linux users' taste really is... I don't even know what word to use for this, but a good argument it does not make. Unless your audience is Windows hackers using Kali Linux, I guess. #9 Huh? That's not even new; both "Application Data" and "Local Settings\Application Data" were a thing before Vista. Vista just redid the folder structure for {reasons}. The new thing it added (I think?) was e.g. LocalLow, which hardly anyone has a reason to use. The registry is neither obsolete nor a mess just because you claim it so. It took me > 1 hour to write this, so I hope it's useful.
ulkesh 5y ago
No, compilation is six times faster in Linux in almost every single language I’ve compiled using the exact same hardware setup. I/O in windows should have been solved with SSDs. I’ve not yet heard or read anything actually good about NTFS as compared to Mac and Linux file systems. You’re quite the outlier in my 25 years of experience within the industry of all three OSes to state NTFS is awesome. Everyone has their favorites, I base mine on experimental data. Clearly Linux is king with compilation time. Since that affects my business work in a multitude of ways, it will continue to be my choice of dev environment. Windows is horrendous for this. I’ve tried numerous times. And with all the same hardware, there are only two main issues: file system and I/O driver/kernel. If SSDs didn’t solve I/O for windows then I’ll concede the I/O is garbage, but I’m yet to be convinced NTFS doesn’t factor in. Simply put: Windows needs a ground-up overhaul and to stop catering to the old win32/NTOS/NTFS model. But I don’t really intend nor expect to convince anyone.
- dataflow 5y ago
  > Everyone has their favorites, I base mine on experimental data. So do I. If all you care about is raw speed, sure, Linux with ext4 might be "king". But I don't just look at speed. I also look at the design both inside and outside, the capabilities, the resilience & robustness, and a ton of other things besides raw speed. Maybe those aren't relevant to you, and that's fine. They are to other folks though. > I’m yet to be convinced NTFS doesn’t factor in. I'm not saying it doesn't "factor in" (I'm sure you could measure some % difference across any filesystem, and you should actually benchmark against FAT32 and exFAT and whatnot before blaming NTFS), but it's not the dominant factor you can blame it on. You can read more here if you're interested (you'll have to expand the hidden comments): https://github.com/microsoft/WSL/issues/873#issuecomment-425272829 https://github.com/microsoft/WSL/issues/873#issuecomment-425... > No, compilation is six times faster in Linux in almost every single language I’ve compiled using the exact same hardware setup. I have no idea what you're doing when compiling, but I'm going to guess you either have lots of tiny files that otherwise compile very quickly (thus the slowness in opening files hits you), or you're running a ton of shell scripts in your "compilation" (process spawning is slow on Windows), or you have antivirus or something turned on, or you have some compiler with quirks like GCC. If you give more details I can help you track down what is going on, but a 6x slowdown is simply not something that you can attribute to NTFS by itself. There's something else going on. I'm going to take a guess that you're using Unix-first tools that have been ported to Windows, rather than designed for tools Windows from the ground-up, and finding that there's an impedance mismatch here. Unix tools are designed around shoving every little thing into a tiny file (whether it's a data, script, or executable file), because that's the religion. Windows just isn't designed with that philosophy (e.g., it assumes you'll access the registry for configuration, load DLLs for external functionality, etc.), and hence Windows-native tools don't deal with nearly as many files as ported Linux-native tools do. There are lots of architectural differences (this is just one example), and they do come with their own advantages and disadvantages. > If SSDs didn’t solve I/O for windows then I’ll concede the I/O is garbage I'm confused... are you saying your "experimental data" is from before the SSD era? So this "6x faster" we've been arguing about your experience from over a decade ago? on hard disks? If so, that's a frustrating way to argue about these. > Simply put: Windows needs a ground-up overhaul and to stop catering to the old win32/NTOS/NTFS model. But I don’t really intend nor expect to convince anyone. It's kind of bizarre to read that given your experience seems to be from a different era (?) and when it is in fact Linux who has been forced to overhaul its I/O design from the ground-up with uring. (Compare Windows's IOCP from > 2 decades ago with Linux's epoll. The epoll model itself literally did not even make sense for disk I/O, never mind its implementation.) I could of course argue about the details all day, but I do agree with you that the case you're trying to make isn't convincing. That is, except if your case is "Linux is better for raw speed if you ignore everything else", in which case, yes I agree.
ubercow13 5y ago
As a user I have certainly experienced greater joy dealing with ~/.config, with vim, than dealing with the registry using 1995's regedit.exe
- dataflow 5y ago
  As a user I get a lot more joy when I can get a .reg file and double-click it to apply a setting rather than having to manually do whatever it takes to modify the uber-modern ~/.config folder.
  - ubercow13 5y ago
    That is an advantage. I don't find myself needing to merge settings that way much in Linux because the config files are self-documenting or at least well-documented, and I can edit them myself. On Windows changing a setting involves going to some ad-infested website like windows10tricks.com to find the magic reg file incantation for each setting I need to change.
    - dataflow 5y ago
      No, "self-documenting" is not what I would ~/.config. At best you have to Google till you find random documentation like [1] and manually go and edit the file. At that point I fail to see how that's any easier than downloading the .reg file right there and just double-clicking it. Moreover, if you insist on doing it the hard way, it's just a matter of copy-pasting the path in 2022 (not 1995)'s regedit and then right-click -> New -> Value. Still just as easy (arguably easier) than modifying a text file. And Microsoft documents a lot of keys too, just not everything. Not like Linux is exactly known for fantastic documentation either. [1] https://wiki.archlinux.org/title/font_configuration#Anti-aliasing https://wiki.archlinux.org/title/font_configuration#Anti-ali...
      - ubercow13 5y ago
        I dunno, I think that's reasonably well-documented without needing Google: https://linux.die.net/man/5/fonts-conf https://linux.die.net/man/5/fonts-conf.

throwaway675309 5y ago

I don't know if they've changed it, but I can think of one very simple disadvantage to the registry in about five seconds, and that is that they combined windows registry settings and user application registry settings into the same registry which meant that they were acting in the same space which from a security / permission standpoint as well as from a possible data loss and corruption standpoint is TERRIBLE; they should've had physically separate registry hive files for each of these spaces to keep them separate and protected.

dataflow 5y ago
I don't follow, sorry. They aren't in the same "space" any more than files are in the same "space". Users put files in C:\ and so does the system, so filesystems are terrible?
legalcorrection 5y ago
More poorly informed registry bashing. 1. Every registry key can have its own ACL (Access Control List). So you can have highly granular permissions. 2. "The registry" is not stored in one file. It's actually a few different hives which are stored as separate files. Your user-level registry settings are stored in your user profile (i.e. home directory) and roams with your user account to different machines in a domain.

rwmj 5y ago

https://rwmj.wordpress.com/2010/02/18/why-the-windows-registry-sucks-technically/ https://rwmj.wordpress.com/2010/02/18/why-the-windows-regist...

dataflow 5y ago
Ok fine, I'll bite. #1 is pretty terrible. It's like complaining that a bicycle is a half-baked car. #2 (and part of #1) is also irrelevant. "The format is badly constructed, fragile, endian-specific, underspecified and slow." So what? The file format is not the business of anyone actually using the registry, and nobody was making claims about the file format anyway. What you have is the APIs and the guarantees those provide you. Complaining about the file format when you will never even be accessing the file contents is like complaining that the remote engineer you hired has a rip in their T-shirt. You just care because you're breaking into the house from Linux and then getting upset that it doesn't look the way you like. #3 is again pretty terrible. "The upshot of this is you can easily hide stuff in the Registry binary which is completely invisible to Windows." OK, so if you don't like that then don't do that. I'm sorry (?) the Windows registry was not designed with making life easy for Kali Linux hackers. #4 is at least on the same planet as something I could consider as maybe vaguely interesting. But it's not like your life is any different on a filesystem. Even .txt files could be ASCII, UTF-8 with BOM, UTF-32, or some weird code page. If you hate that fact of life, you need to direct your hate toward the person who made the file whose contents you're trying to read. #5 is vaguely interesting but again, practically irrelevant for people writing applications (unless you're writing a registry editor I guess). It's more relevant for end-users dealing with .reg files, and the interchange format for them is pretty obvious: follow whatever regedit does. If you find that file format poorly documented... big deal. Just export what you want and look at how it gets encoded, and you'll remember it thereafter. "The registry sucks" does not follow from "I have to spend 5 minutes figuring out how to write this text file for something irrelevant to >99% of use cases because it's not well-documented". If that's your standard then the Linux kernel would be an absolute dumpster fire with how lacking it is in the documentation department. #6 finally something I can at least comprehend. OK, so evolution & backward compatibility introduces some warts, just like it does on Linux or any other OS. Documentation of internals could probably be better... just like with Linux or any other OS. Though "non-standardized" is a strange complaint for Windows, given there aren't 1000 different companies releasing their own Windows distributions like there are with Linux, for whom having a standard would actually make sense. And it's not like you don't have %AppData% at your disposal if you really like files. #7 is again like #1. The registry is intended for low-latency, low-throughput access to small bits of data. The filesystem is intended for high-latency, high-throughput access to large & growing data. You don't complain that your knife can't cut down trees; you use a chainsaw instead. You need to use the right tool for the job. "It should be a database!" ...sure, so should ext4. #8 is almost onto something here, but misses it and veers 90 degrees in the wrong direction. The argument you could make is "it's difficult to manage registry ACLs separately from the filesystem", which I could understand; Windows security is complicated, which is not great for security. You could flesh this out into a good argument here, though it wouldn't really be specific to the registry. But the grumbling (yet again) about the format of the hive file because it's not "hackable" enough for Linux users' taste really is... I don't even know what word to use for this, but a good argument it does not make. Unless your audience is Windows hackers using Kali Linux, I guess. #9 Huh? That's not even new; both "Application Data" and "Local Settings\Application Data" were a thing before Vista. Vista just redid the folder structure for {reasons}. The new thing it added (I think?) was e.g. LocalLow, which hardly anyone has a reason to use. The registry is neither obsolete nor a mess just because you claim it so. It took me > 1 hour to write this, so I hope it's useful.

ulkesh 5y ago

No, compilation is six times faster in Linux in almost every single language I’ve compiled using the exact same hardware setup. I/O in windows should have been solved with SSDs. I’ve not yet heard or read anything actually good about NTFS as compared to Mac and Linux file systems. You’re quite the outlier in my 25 years of experience within the industry of all three OSes to state NTFS is awesome. Everyone has their favorites, I base mine on experimental data. Clearly Linux is king with compilation time. Since that affects my business work in a multitude of ways, it will continue to be my choice of dev environment. Windows is horrendous for this. I’ve tried numerous times. And with all the same hardware, there are only two main issues: file system and I/O driver/kernel. If SSDs didn’t solve I/O for windows then I’ll concede the I/O is garbage, but I’m yet to be convinced NTFS doesn’t factor in. Simply put: Windows needs a ground-up overhaul and to stop catering to the old win32/NTOS/NTFS model. But I don’t really intend nor expect to convince anyone.

dataflow 5y ago
> Everyone has their favorites, I base mine on experimental data. So do I. If all you care about is raw speed, sure, Linux with ext4 might be "king". But I don't just look at speed. I also look at the design both inside and outside, the capabilities, the resilience & robustness, and a ton of other things besides raw speed. Maybe those aren't relevant to you, and that's fine. They are to other folks though. > I’m yet to be convinced NTFS doesn’t factor in. I'm not saying it doesn't "factor in" (I'm sure you could measure some % difference across any filesystem, and you should actually benchmark against FAT32 and exFAT and whatnot before blaming NTFS), but it's not the dominant factor you can blame it on. You can read more here if you're interested (you'll have to expand the hidden comments): https://github.com/microsoft/WSL/issues/873#issuecomment-425272829 https://github.com/microsoft/WSL/issues/873#issuecomment-425... > No, compilation is six times faster in Linux in almost every single language I’ve compiled using the exact same hardware setup. I have no idea what you're doing when compiling, but I'm going to guess you either have lots of tiny files that otherwise compile very quickly (thus the slowness in opening files hits you), or you're running a ton of shell scripts in your "compilation" (process spawning is slow on Windows), or you have antivirus or something turned on, or you have some compiler with quirks like GCC. If you give more details I can help you track down what is going on, but a 6x slowdown is simply not something that you can attribute to NTFS by itself. There's something else going on. I'm going to take a guess that you're using Unix-first tools that have been ported to Windows, rather than designed for tools Windows from the ground-up, and finding that there's an impedance mismatch here. Unix tools are designed around shoving every little thing into a tiny file (whether it's a data, script, or executable file), because that's the religion. Windows just isn't designed with that philosophy (e.g., it assumes you'll access the registry for configuration, load DLLs for external functionality, etc.), and hence Windows-native tools don't deal with nearly as many files as ported Linux-native tools do. There are lots of architectural differences (this is just one example), and they do come with their own advantages and disadvantages. > If SSDs didn’t solve I/O for windows then I’ll concede the I/O is garbage I'm confused... are you saying your "experimental data" is from before the SSD era? So this "6x faster" we've been arguing about your experience from over a decade ago? on hard disks? If so, that's a frustrating way to argue about these. > Simply put: Windows needs a ground-up overhaul and to stop catering to the old win32/NTOS/NTFS model. But I don’t really intend nor expect to convince anyone. It's kind of bizarre to read that given your experience seems to be from a different era (?) and when it is in fact Linux who has been forced to overhaul its I/O design from the ground-up with uring. (Compare Windows's IOCP from > 2 decades ago with Linux's epoll. The epoll model itself literally did not even make sense for disk I/O, never mind its implementation.) I could of course argue about the details all day, but I do agree with you that the case you're trying to make isn't convincing. That is, except if your case is "Linux is better for raw speed if you ignore everything else", in which case, yes I agree.

ubercow13 5y ago

As a user I have certainly experienced greater joy dealing with ~/.config, with vim, than dealing with the registry using 1995's regedit.exe

dataflow 5y ago
As a user I get a lot more joy when I can get a .reg file and double-click it to apply a setting rather than having to manually do whatever it takes to modify the uber-modern ~/.config folder.
- ubercow13 5y ago
  That is an advantage. I don't find myself needing to merge settings that way much in Linux because the config files are self-documenting or at least well-documented, and I can edit them myself. On Windows changing a setting involves going to some ad-infested website like windows10tricks.com to find the magic reg file incantation for each setting I need to change.
  - dataflow 5y ago
    No, "self-documenting" is not what I would ~/.config. At best you have to Google till you find random documentation like [1] and manually go and edit the file. At that point I fail to see how that's any easier than downloading the .reg file right there and just double-clicking it. Moreover, if you insist on doing it the hard way, it's just a matter of copy-pasting the path in 2022 (not 1995)'s regedit and then right-click -> New -> Value. Still just as easy (arguably easier) than modifying a text file. And Microsoft documents a lot of keys too, just not everything. Not like Linux is exactly known for fantastic documentation either. [1] https://wiki.archlinux.org/title/font_configuration#Anti-aliasing https://wiki.archlinux.org/title/font_configuration#Anti-ali...
    - ubercow13 5y ago
      I dunno, I think that's reasonably well-documented without needing Google: https://linux.die.net/man/5/fonts-conf https://linux.die.net/man/5/fonts-conf.