4 ms·

I think the issue is that frequently the problem is with a small part of a complex subsystem that you don't understand (or perhaps didn't even know existed) bef

I think the issue is that frequently the problem is with a small part of a complex subsystem that you don't understand (or perhaps didn't even know existed) before something went wrong. This sort of problem is extremely time consuming to debug via "properly" learning about the system, so you end up (much like Fabien) taking a fix from somewhere without fully understanding it. There's also a timing issue. Often when something goes wrong it's at a random time when I'm probably intending to do something else. I don't want to put off that other thing even more by taking a "slower" route to fixing the issue. You can of course still learn a lot along the way, as you say. So, it's not all lost, but it does seem sub-optimal.

fragmede 4y ago
Part of it is the binary config nature of Regedit though. I can't, from first or second principles, reason about which binary key to flip in order to change the behavior I'm looking for. Was it HKLM/ffebdcaaf, or HKLM/afbedccfh? Meanwhile if, eg dns got broken on my Linux box, there's a series of config files and daemons to check in order to figure out what's broken and then to get it working again. There's no way to learn anything with Regedit other than knowing you can just Google for the name of the key to set by looking up the problem.
- ddulaney 4y ago
  Eh, having worked with both systems, I'd say they're roughly equally impenetrable. For sure, the registry sucks. But at least it's uniform and scriptable. Once you know what needs to be changed, you can write a .reg file and be reasonably confident it will at least change the registry in a valid way. On the other hand, if the solution to a problem on Linux is to change some dotfile controlling some daemon, reliably scripting it can be difficult to impossible. Did the distro put the config file somewhere weird? Is awk good enough here? What if the key I'm looking to update is found in a comment, and what is the commenting structure for this file anyway? What if the daemon rewrites its config file on exit [0]? Or has a config file with an extremely complex format [1]? Or I need to poke several /sys files in a particular order [2]? Both systems are hard to reason about, especially if you don't know them. But Linux isn't easy to approach for the first time, and there are advantages to the way Windows does things. [0]: https://askubuntu.com/questions/251797/transmission-daemon-keeps-resetting https://askubuntu.com/questions/251797/transmission-daemon-k... [1]: https://www.sudo.ws/docs/man/1.8.15/sudoers.man/#SUDOERS_FILE_FORMAT https://www.sudo.ws/docs/man/1.8.15/sudoers.man/#SUDOERS_FIL... [2]: https://www.youtube.com/watch?v=9-IWMbJXoLM https://www.youtube.com/watch?v=9-IWMbJXoLM
m463 4y ago
I think the two problem spaces are slightly different. - for windows, the problem is solved by: 1) common sense troubleshooting 2) web search for the problem 3) ask the developer - for linux, you also get: 4) break out the source 5) push an update
torginus 4y ago
Usually the adoption and uniformity as well as the generally higher quality of Windows, in addition to the availability of good debugging tools (which work) makes troubleshooting easier. I recently had an OpenGL related issue on Linux, I googled the error message and got 1 search result. Now I can speculate, is my program wrong? Or is it the Nvidia driver, perhaps Xorg? Did the Ubuntu devs configure something wrong etc. Why won't Nsight or Renderman work on my machine? Windows has by contrast a significantly larger userbase, an architecture that's set in stone, meaning I can find relevant answers from a decade ago, and there's thankfully no Windows 'distributions' so the issue I face is likely to appear on any person's machine.

fragmede 4y ago

Part of it is the binary config nature of Regedit though. I can't, from first or second principles, reason about which binary key to flip in order to change the behavior I'm looking for. Was it HKLM/ffebdcaaf, or HKLM/afbedccfh? Meanwhile if, eg dns got broken on my Linux box, there's a series of config files and daemons to check in order to figure out what's broken and then to get it working again. There's no way to learn anything with Regedit other than knowing you can just Google for the name of the key to set by looking up the problem.

ddulaney 4y ago
Eh, having worked with both systems, I'd say they're roughly equally impenetrable. For sure, the registry sucks. But at least it's uniform and scriptable. Once you know what needs to be changed, you can write a .reg file and be reasonably confident it will at least change the registry in a valid way. On the other hand, if the solution to a problem on Linux is to change some dotfile controlling some daemon, reliably scripting it can be difficult to impossible. Did the distro put the config file somewhere weird? Is awk good enough here? What if the key I'm looking to update is found in a comment, and what is the commenting structure for this file anyway? What if the daemon rewrites its config file on exit [0]? Or has a config file with an extremely complex format [1]? Or I need to poke several /sys files in a particular order [2]? Both systems are hard to reason about, especially if you don't know them. But Linux isn't easy to approach for the first time, and there are advantages to the way Windows does things. [0]: https://askubuntu.com/questions/251797/transmission-daemon-keeps-resetting https://askubuntu.com/questions/251797/transmission-daemon-k... [1]: https://www.sudo.ws/docs/man/1.8.15/sudoers.man/#SUDOERS_FILE_FORMAT https://www.sudo.ws/docs/man/1.8.15/sudoers.man/#SUDOERS_FIL... [2]: https://www.youtube.com/watch?v=9-IWMbJXoLM https://www.youtube.com/watch?v=9-IWMbJXoLM

m463 4y ago

I think the two problem spaces are slightly different. - for windows, the problem is solved by: 1) common sense troubleshooting 2) web search for the problem 3) ask the developer - for linux, you also get: 4) break out the source 5) push an update

torginus 4y ago

Usually the adoption and uniformity as well as the generally higher quality of Windows, in addition to the availability of good debugging tools (which work) makes troubleshooting easier. I recently had an OpenGL related issue on Linux, I googled the error message and got 1 search result. Now I can speculate, is my program wrong? Or is it the Nvidia driver, perhaps Xorg? Did the Ubuntu devs configure something wrong etc. Why won't Nsight or Renderman work on my machine? Windows has by contrast a significantly larger userbase, an architecture that's set in stone, meaning I can find relevant answers from a decade ago, and there's thankfully no Windows 'distributions' so the issue I face is likely to appear on any person's machine.