Hacker News Reader

Comment by smoldesu | Hacker News Reader

The delineation of this argument is what made me switch to Linux. On Windows, things that should have been getting easy were getting harder for me: software management was getting worse, updates were getting worse, and everything that should "just work", just wouldn't. My experience on MacOS was just as bad, with all of the 32-bit apps I used gone in the wind. Now the 64-bit apps are up on the chopping block, and I had to look for other options.

The learning curve for Linux was larger than Windows or MacOS, but I only learned the truth. By cutting away abstraction, I can actually understand what my system is doing, and be a better citizen of my operating system. Linux is arranged masterfully, and makes the Windows filesystem look like a joke in comparison. It's also faster than any of the Macs I own, with the freedom to plug in a modern Nvidia GPU and play whatever games I want.

View on HN

I love Linux based operating systems and I've used them pretty much exclusively for at least a decade now, and I agree with a lot of your post, but

>By cutting away abstraction,

I don't think I agree with this take. You haven't cut away abstraction, you've changed to a different kind of abstraction. Linux's 'everything is a file' abstraction is just that, an abstraction.

>Linux is arranged masterfully, and makes the Windows filesystem look like a joke in comparison

It's arranged more simply and straightforward, masterfully though, I dunno...

Every flavour of Linux uses a different layout for its root directories, stores configs in different places and generally is not consistent from distro to distro.

User configs are also scattered in random places at times. They could be in .config they could be in .local they could be in .$APP_NAME they could be in the app's directory, they could be in /usr/ somewhere. Maybe in a couple different places at once. Who knows? It's a mystery until you track it down.

Dependencies and libraries are a huge pain to deal with, especially when you start mixing and matching distro provided libraries with custom built ones.

I'm not trying to disagree with your post or anything. I love the way Linux lets you have control over your computer and doesn't try to stop you. But, it's definitely got some issues. I've only touched on a few related to your comment itself.

My early web dev experience was mostly just figuring out where the hell config and log files for apache, php and mysql were. If the docs told you the default location of the config file, you could be sure that on your distro they are somewhere completely different.

>My early web dev experience was mostly just figuring out where the hell config and log files for apache, php and mysql were

Yeah but once you track it all down you feel like a developer superstar genius...

Then you confidently sit down and proceed to repeat the process on another distro and immediately feel like a complete noob again as nothing is where it should be and you realize, you mastered nothing.

There's also a lot of sub-ecosystem issues which are more prominent on Linux, like the long-standing surprise that NPM doesn't have a global rc file in /etc:

https://github.com/npm/npm/issues/533

The argument from the maintainer is reasonable that distros can just patch it, but realistically, everyone wants a newer version of things than what their distros ship—a similar tug-of-war ends up happening in the Python world, where distros like Ubuntu and Debian ship patched versions of pip/setuptools, and then users are encouraged to self-upgrade those tools to the upstream versions.

Anyway, this kind of thing isn't necessarily anyone's fault, but it is just a pretty different experience from Mac or Windows where you tend to have things be more self contained, like "here's where my Python installation lives because it's the path I put in the box when I ran setup.exe."

Node is definitely a bit of a mess, it's misuse of the Linux system doesn't really come as a surprise.

Re: abstractions, I think what seperates Window/MacOS abstractions from Linux/UNIX abstractions is obfuscation. The aggressively closed-source nature means that *nix abstractions, to a reasonable degree, anyway, reflect the underlying structure in a way that closed source abstractions can't. Of course the file abstraction is an abstraction is an abstraction, but it's also implemented transparently as a concept in the kernel --- Whereas Windows manipulates their interface so that the interface _is_ the implementation, as far as the user can see and as far the user should care. At least, this is my experience, and it fits well with what I'd expect from the operating systems' respective development models.

> Every flavour of Linux uses a different layout for its root directories, stores configs in different places and generally is not consistent from distro to distro.

As a very casual Linux user (macOS is my daily driver), are there any efforts to solve these "death by 1,000 cuts" arbitrary (I assume) differences?

Not really no. The differences between distros are essentially rooted in philosophical beliefs defended by near religious zealotry. Entire identies are defined around the differences between distros.

A bit of an exaggeration, but well...pretty much that.

These differences mostly come down to package manager variations, which should be one of the main considerations when picking out a distro in the first place. My personal advice is to use Arch/Manjaro with pacman, and avoid all snaps/flatpaks. The AUR is designed for people to integrate these apps like Spotify and Bitwig into the proper locations, instead of snaps and flatpaks making their own folders and such.

See File System Hierarchy Standard[0], or `man hier`.

[0]: https://refspecs.linuxfoundation.org/fhs.shtml

> You haven't cut away abstraction, you've changed to a different kind of abstraction.

Yes, Linux depends upon abstractions. Everything in computing is an abstraction, including those 1's and 0's that tell the processor what to do. (Anything below that is electrical engineering.) The differentiators are the complexity and stability of that abstraction. When people talk about "everything being a file", they are referring to lower level abstractions that are relatively simple and stable. Likewise, when people talk about HTML/CSS/JS they are referring to lower level abstractions that are relatively simple and stable. This is less true (sometimes significantly less true) when people start discussing frameworks/libraries, whether that's in Linux or web development.

Simplicity is harder to do than it looks. When you see something simple that actually works, something made to be easy to understand, that can take a lot of work to arrive at. So while it may not be much to look at, few people can actually accomplish that. Unix is a good example. It looks easy, but when you see people try to improve on something the failure rate is quite high.

Let me give you an example of something that used to be clear and trivial in Unix that isn’t anymore because people «improved» it: telling your system about name servers.

i strongly disagree with this:

Every flavour of Linux uses a different layout for its root directories, stores configs in different places and generally is not consistent from distro to distro.

there are differences, but it's 90% the same in the major distributions.

and while you do have a point about user configs, it is getting better. .config and .local are getting used more and more and are an improvement over every app dropping stuff in $HOME.

>there are differences, but it's 90% the same in the major distributions.

Yes and that 10% can cause some unexpected, sometimes hard to fix problems. A poorly written build script or installer that expects a specific distro's directory layout can cause some problems. Especially if it's a large convoluted build system that hard codes the directories in multiple places.

I've actually had to deal with this, it sucks. That was as an end user trying to use an app, not as a developer.

You run into this a lot trying to build small libraries and stuff. There's unfortunately a lot of poor programming habits out there. Directories inevitably sometimes get hardcoded and this causes problems because of the inconsistencies between distros.

>and while you do have a point about user configs, it is getting better. .config and .local are getting used more and more

And yet there's hundreds of apps that will never be updated or changed to conform to standards.

>are an improvement over every app dropping stuff in $HOME.

Tell that to snap. It insists its folder must sit nicely in my home folder and nowhere else.

And yet there's hundreds of apps that will never be updated or changed to conform to standards.

i suspect many of those are no longer actively maintained. at best they receive security patches from distributions.

Tell that to snap. It insists its folder must sit nicely in my home folder and nowhere else.

my (low) opinion of snap aside, the bad here is that the location is not configurable. as a library of applications, i would want snap in $HOME. or i would put it in $HOME/lib or an equivalent. maybe .local would be appropriate too, but i understand it's for app specific user-data, so it doesn't look like whole apps should be in there. (edit: elsewhere i just read that .local is supposed to be like a user specific /usr/local, so snap should fit in there somewhere)

I don't want to turn this into a snap bad mouthing thread, but yeah. You can't even symlink it or it causes problems. It really bugs me because I don't tend to allocate too much space to my home partition and keep most of my stuff on data partitions. So if I get a bunch of snap apps, it starts eating up all the space in home.

Can you wrap its invocation in a script that sets a snap specific version of the $HOME environment variable? If it's perverse, it ignores $HOME in favor of reading the passwd entry itself, in which case I'm happy to have never encountered it.

i hear you. in fact, i do use data partitions as well, and if my snap directory grew to much i would want to move it too.

as a workaround try to use a bind-mount

I don't use Snap. The only real "bloat" in my home directory is my Bitwig folder, which isn't that bad considering I use the program on a near-daily basis.

> and while you do have a point about user configs, it is getting better

Are people finally following the XDG standard? [0]

[0] https://wiki.archlinux.org/index.php/XDG_Base_Directory

i have no hard data, but my impression is that more and more apps are

> It's arranged more simply and straightforward, masterfully though, I dunno...

It's easy to make "complicated". It's very hard to make "simple and straightforward".

Whether that's an indication of mastery is not a closed question.

> I don't think I agree with this take. You haven't cut away abstraction, you've changed to a different kind of abstraction. Linux's 'everything is a file' abstraction is just that, an abstraction.

If I try to interpret the bit about abstraction, I lean more towards "less opaque" being the intended meaning. On Windows and Mac, it's harder to see what is happening. On Linux, it's all exposed and there to tinker with.

> It's arranged more simply and straightforward, masterfully though, I dunno...

I would argue that simple and straightforward is masterful!

I don't know if you are talking about Linux the kernel, Linux the entire distro, Linux the filesystem (out of tens of supported filesystems), but "arranged masterfully" is big statement. From 2 days ago:

https://news.ycombinator.com/item?id=26821298

I wish wish wish I could move over to Linux but its font rendering situation is terrible [1] I've tried Manjaro and Ubuntu to no avail.

I have no idea what causes it or if people on Linux are not as sensitive to it or its a specific hardware setup which causes terrible fonts but once you read Windows fonts stuff looks so much better to me. Apparently its a hot debated topic but its so obvious to some it seems.

[1] https://pandasauce.org/post/linux-fonts/

Hah: I am very particular about fonts myself but what bugs me most isn't sub-pixel hinting (which is "good enough" with the latest freetype IMHO) it's the size of fonts. Windows is so far off the mark on 99% of computers and it drives me crazy!

Repeat after me:

    72pt is one inch tall!
    72pt is one inch tall!
    72pt is one inch tall!

The "point" scale of fonts is actually a precise, real-world measurement like inches, millimeters, etc. Fonts may differ in how much space each glyph takes up but in general they should at least be close to the correct size.

Test it: Open up a word processor and load some reasonably normal font (e.g. Arial) and make some text that's 72pt. Then hold a ruler up to your screen: Is it about 1 inch tall? How far off the mark is it?

If you're using a modern, high-DPI display it's probably waaaaay TF off, haha. Even with regular displays it'll be off and there's actually no way to fix it because you can't tell Windows the precise DPI of your display! It tries to guess based on the DDC data given by your display but then averages the X/Y together to scale fonts. So if your X DPI is higher than your Y DPI it'll always get it wrong. Always!

Macs cheat in this area by always having displays of a fixed DPI. For the longest time all Apple displays were precisely 96 dpi (with perfectly square pixels) but recently changed it to 220-ish and made adjustments in their font rendering engine to match. I have no idea how they're handling non-Apple displays these days.

Linux, on the other hand does it right (at least X11 and KDE do) in that it scales fonts very accurately based on the DPI presented by your display via the DDC protocol (or if your monitor doesn't provide that you can set both X and Y DPI manually).

Gnome and GTK applications have the same problem as Windows though in that they only take one DPI setting and if the DDC protocol gives separate X/Y values it'll just average them and the results can be... Ridiculous. You don't really notice the weirdly-stretched fonts until you open a KDE application side-by-side with a GTK one.

On top of that mess you describe here lives the web designer pixel mess.

Web designers loved to do their web pages with pixel measurements instead of real lengths in millimeters or points. Which is a horrible idea because of the different DPIes.

DPIes became bigger and bigger over time and browser developers were between two fronts of bullshit. The OS told them a bullshit DPI and web pages gave them a bullshit pixel length design. What did they do? The invented a third layer of bullshit to fix the other two (a little): the fake pixel. "Pixels" in web pages today have not the same length like the screen's real pixels, they are somehow scaled.

This is all broken beyond repair.

I wished that browser developers would have implemented it the right way. A pixel is a pixel and an inch is an inch. Many sites would be broken after that and the web designers would be forced to fix that and to use for example millimeters or points for lengths. And in a perfect world the OS would then use the correct DPI to display the rendered result.

I have never seen a display with non-square pixels, except maybe on cameras. Where are those typically installed?

CRT monitors will naturally display non-square pixels, depending on the resolution. Sometimes LCD's are run in non-native resolution due to GPU or driver issues, which results in a stretched display where the input pixels are not square.

CGA displays had non-square (logical) pixels. The ratio for 320×200 resolution is 1.6, but it is shown on a 4:3 (1.333) screen.

Where can I read more about how 72pt ~ 1 inch? Where does one g to for a "course on typography"?

This was posted recently: https://tonsky.me/blog/font-size/

Wow, first time I hear that as the main and apparently only argument to using Windows over any Linux distro.

With HiDPI displays all over the place, is subpixel rendering really still a thing? Pixels have gotten so small, I can't see individual ones anymore even if I'm trying. They could leave out anti-aliasing altogether in fonts and I'd hardly notice.

Or I'm just getting old.

I think that people are just too fussy. I have anti-aliasing disabled on my 142 dpi laptop screen and it looks better in most applications provided that screen fonts are used. Yes, you can see the pixels and you get the odd rendering artifact. On the other hand, the fuzziness of anti-aliasing is a steep price for edges that appear smoother.

Most desktop environments will offer subpixel AA, and with GNOME and KDE, I think it's enabled by default.

FreeType and slight hinting + subpixel antialiasing looks great to me, really... Windows has strong pixel-fitting and at the same time softer outlines. That is after using the ClearType tuner to tweak it to my liking. I'm not particularly fond of that look. You talk about hardware. The gamma of your screen makes a difference - antialiasing relies on it. The ClearType tuner has a page or three about that. I guess on Linux you better set your display gamma to the standard value, there is no good reason (except visual impairment or something) to set it to anything else anyway.

By the way, font rendering in Chrome for Linux used to be really awful (no subpixel AA or something). It was fixed a few years ago - it looks like any other app now.

I omitted some detail that you can easily find in your favorite search engine.

I’ve changed entire distros, back in the day, based on font rendering. However, you’re on crack if you think Windows fonts are great. MacOS makes everything else look like children’s scrawl. I’ve been running on Macs for about 6 years now (with a PC connected to the same external monitor) and I still sometimes just stop and admire how nice the fonts are.

I have a 4K and 5k display, and I find it as pleasant as my 2019 MacBook. I’m not sure if it’s because I’m not sensitive to it, or what. (I’m using Fedora with Gnome 40.)

>> The learning curve for Linux was larger than Windows or MacOS, but I only learned the truth. By cutting away abstraction, I can actually understand what my system is doing, and be a better citizen of my operating system. Linux is arranged masterfully, and makes the Windows filesystem look like a joke in comparison.

What windows filesystem (FAT, FAT32, exFAT, NTFS) look like a joke and compared to which Linux filesystem? Ext2? Ext3? Ext4? ReiserFS? ZFS? It’s pretty clear that you never used Linux in the 90’s from your comment. And the main problem with Linux at the time had nothing to do with the filesystem but mainly with the immaturity of the complete system. I am very curious to understand what great truth you understood by using Linux. Would you kindly teach me this great knowledge and illuminating experience that I somehow missed?

> What windows filesystem (FAT, FAT32, exFAT, NTFS) look like a joke and compared to which Linux filesystem?

I was referring more to the layout of the root directory (oftentimes referred to as "the filesystem", but now that you bring it up I also hate the Windows filesystems. FAT32 needs to go out to the pasture, and it wouldn't even exist if exFAT support was so broken on lower-end systems. NTFS is fine, but pathetically bare-bones. I'm a BTRFS evangelist, but even ext3 makes NTFS look old by comparison.

> It’s pretty clear that you never used Linux in the 90’s from your comment.

This is true.

> And the main problem with Linux at the time had nothing to do with the filesystem but mainly with the immaturity of the complete system.

"at the time" meaning 2018 or the 90s? Maybe 30 years ago Linux was immature, but now it's the benchmark of maturity. Very few *nix systems have share it's pedigree.

> I am very curious to understand what great truth you understood by using Linux. Would you kindly teach me this great knowledge and illuminating experience that I somehow missed?

Nope, probably not. If using Linux wasn't an enlightening experience because you last used it in the 90s or because you have an FAT fetish, I can't really help you.

Linux is also stable. The binary interface isn't going to change. It's possible to write Linux software that you can boot directly into and it will never stop working or do anything you don't want it to do.

Because there's a BDFL at the top. Linus understands that the whole point of a kernel is having a stable binary interface to run programs on, anytime somebody wants to break userspace he goes on a rant and rejects the idea, rightfully so.

Many other projects do not follow this way of thinking or don't have a BDFL. They break API's because... someone felt like it? Every once in a while I dig into the changelogs or migration guides of projects (sometimes they don't even have a migration guide which is just awful) and you'll see things like changed names of functions, swapped argument orders or even complete removal of functions. But why? We don't know and my guess is it usually boils down to someone "feeling like it".

Yeah. I suppose without Linus's leadership Linux just wouldn't be the same project anymore. The world has come to trust him because he makes good decisions. We depend on his core values such as "don't break userspace". I wonder what it's gonna be like in the future...

> They break API's because... someone felt like it?

I empathize with them. Designing software is essentially philosophy. The interfaces reflect the developer's current understanding of the world. When this understanding improves, people are tempted to update software because they feel like the software is wrong and unelegant when it doesn't match what's in their minds.

It takes a really good engineer to reject this impulse and take responsibility for interfaces people came up with in the 90s.

I have been having a terrible time staying away from conda in windows, but the ridiculous amount of time and spent trying to install some python modules using pip is just not worth it.

I’d be lost without wsl.

> My experience on MacOS was just as bad, with all of the 32-bit apps I used gone in the wind.

Were you forced to update to Catalina? I'm still on Mojave right now. My 32-bit apps still work, happily unaware of the fact that they're no longer supposed to.

I would love to to use Linix as my daily driver, but keep needing to go back to Windows for Ableton and gaming.

I switched to Bitwig, which has a native version for Linux. The workflow is very similar to Ableton Live, with a little bit of extra configuration. As for gaming, it's a case-by-case situation, but Valve Proton is good enough for 80% of the games I like.

Yeah I've heard that Bitwig could be a good solution, and is made by the original developers of Ableton.

But what about 3rd party plugins? As far as I understand, most of these won't work on Linux either.

You are spot on. And now, try OpenBSD. It's the next step in removing useless abstractions.

I'm an avid Linux user, completely unfamiliar with BSD. Could you shed some light on how it further removes abstractions? I don't mind trying it out by booting it from a usb

> Could you shed some light on how it further removes abstractions?

By not running hundreds of useless programs, I guess. If you launch htop inside OpenBSD, it'll fill half of your terminal, and the rest is empty.

The easiest way to try it is to install it on a virtual machine. You'll see that not much is needed to get to a point to launch firefox from an xterm.

but that's the case for some linux distros too, e.g void

Top itself is enough, you don´t need htop.

I find htop's ability to view the tree structure of a process quite useful. Name your threads!

Totally agree. But I'm somewhat used to silly things about htop, like selecting a process to kill using the arrow keys, or a default refresh rate of less than 1 second.

Linux is a large ecosystem, supporting many different functions (embedded to some extent; desktop; server; supercomputer clusters, etc). For any one of these, the other 'stuff' represents cruft. The BSDs (I am partial to NetBSD) tend to give you a basic substrate of 'the system', and you add what you need via 'packages'. It's a different philosophy, but no less valid.

Reply on news.ycombinator.com