Hacker News Reader

Comment by daxvena | Hacker News Reader

I get where you're coming from, but I think the biggest pro for the "UNIX way" is that text on a filesystem extremely accessible. You don't need a specialized tool to read & modify configuration, you just need a text editor. And while there's no standard for how the data is structured, it's usually pretty easy to figure it out from context.

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.

View on HN

General Linux tools built for text, in a world where everything is plain text and the shell doesn't know how to navigate anything other than a file system. In PowerShell you can cd into HKEY_LOCAL_MACHINE as easily as any drive, and Select-String is perfectly capable of searching registry keys.

The baseline is only text and files on systems that don't have anything better to offer.

Isnt there FuseFS for that? It can show the gconf registry as a file tree, allowing you to use tools like recursive diff etc. https://metacpan.org/release/LSIM/GConf-FS-0.01

Something flexible like FuseFS is sorely missing on windows, the stuff google drive had to do creating a new letter drive is pretty gnarly.

You mean https://docs.microsoft.com/en-us/windows/win32/projfs/projec...?

Interesting, I hadn't seen that. Did Google Drive go with the virtual drive letter thing mainly for backwards compatibility to older windows?

> The baseline is only text and files on systems that don't have anything better to offer.

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.

Not really, if it’s a .NET assembly Powershell can dynamically load, call and use types from it. Not to mention first-class support for standard data interchange formats like JSON, XML etc without having to convert back/forth from text or use tools to process it.

In a few situations, actually calling .NET code from PowerShell doesn't suck, like setting persistent environment variables.

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

Windows and macOS dominate because 99.9% of users do not care about the difference between registries, file systems, text or binary tools, UNIX-like, POSIX, etc… none of these things matter to them! They just want to use a computer and get on with their life.

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.

> Windows and macOS dominate because 99.9% of users do not care about the difference between registries, file systems, text or binary tools, UNIX-like, POSIX, etc… none of these things matter to them! They just want to use a computer and get on with their life.

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

The registry does not impact those users' experience. Needing to learn how to use a shell, does.

I would disagree that it does impact users' experience because when the registry gets corrupt you have to start by installing Windows from scratch. Nothing like Windows 10 update disabling registry backups to save space on low capacity storage and finding out after the fact when attempting to recover Windows 10.

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.

Windows these days works extremely well with just taking out the hard drive and placing it into a different computer, even across different processor brands completely different hardware etc.

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.

The registry does not get corrupt. This is not a thing that happens without the system files themselves being corrupted. People blame any old problem on the registry the way they blame any old problem on /etc. Nor, in the case of an actual registry problem, do you have to reinstall Windows from scratch; restoring the registry from backup is the entire point of system restore points, which are created on every update and most program installs. As a bonus, yes, I did upgrade my computer that way. This stuff is pure superstition.

I've reinstalled Linux due to borked sound on update way more times than I reinstalled Windows due to corrupt registry.

And cumulatively I spent significantly less time on Linux than I did on Windows.

I'm not saying the UNIX philosophy is the "best" way, I'm just stating why it's valuable.

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.

Reply on news.ycombinator.com