>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.
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.
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."
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?
A bit of an exaggeration, but well...pretty much that.
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.
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.
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.
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.
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)
as a workaround try to use a bind-mount
Are people finally following the XDG standard? [0]
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.
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 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.
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.
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.
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.
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.
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?
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.
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".
> 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’d be lost without wsl.
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.
But what about 3rd party plugins? As far as I understand, most of these won't work on Linux either.
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.
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.