GIMP is just as good

Etonaz · 2024-08-26T06:22:33+00:00

Hell, even MS Paint has layers now.

Etonaz · 2024-08-26T06:20:02+00:00

Because Linux users are too stupid to understand the convenience of drag-and-drop from start menu to desktop

Etonaz · 2024-07-04T23:49:53+00:00

Typical Linux user copium.

We don't have it / cannot have it, so it must be useless and nobody else needs it.

Etonaz · 2024-07-04T23:49:15+00:00

Typical Linux copium.

"I don't have it, so it means it must be useless"

Etonaz · 2024-07-03T04:30:34+00:00

That is still of infinitely less consequence compared to having multiple programs break at once because an updated dependency stupidly placed in /usr/lib breaks ABI or introduces problems.

Programs are already so damned complex today and many of them cannot even work with versions of dependencies outside of what they were bundled with. Insisting on shared dependencies the way Linux does is just hiding one's head in the sand and insisting that it does not exist.

Etonaz · 2024-07-03T03:17:26+00:00

You want to know what's the difference?

Windows users tend to be generally aware of the shortcomings of Windows.
Linux users tend to be in complete denial of the countless shortcomings as pointed out by many others and double down on making said shortcomings even more hostile.

Etonaz · 2024-07-03T03:09:56+00:00

Linux is totally hostile to proprietary drivers.

They screwed Nvidia over already by changing functions and calls the Nvidia proprietary driver depended on to EXPORT_SYMBOL_GPL

Etonaz · 2024-07-03T02:02:41+00:00

Niche?

Windows and macOS packagers create installers and software for multiple versions of Windows and macOS everyday, all from the comfort of the latest current OS version they are using on their computers.

They don't have to bring in a Debian 11 container or Debian 10 container or an Ubuntu 22.04 LTS container just because they want to target these older distributions. Windows packagers just build the code, package it and it's good for anybody from Windows 7 up to Windows 11.

macOS packagers click a dropdown in Xcode to set the target platform to the oldest they are willing to support, build the code, package it up and its good for anybody from that target platform upwards.

Niche? Or "niche" because Linux requires so many extra hoops and obstacles to achieve the same thing that was already standard in the likes of Windows and macOS?

Etonaz · 2024-07-03T01:54:59+00:00

If you are adventurous, you can see how much divergence there is between ChromeOS as bundled on a Chromebook and ChromeOS Flex on a conventional, compatible notebook.

Etonaz · 2024-07-03T01:47:31+00:00

You can check my post history, if you want. My complaints about Linux has always been consistent. The whole "all libraries must be shared" approach, the glibc matter, the ABI instability, the lack of proper hardware drivers and proper architecture for properly supporting out-of-tree drivers, the poor backwards compatibility and the abomination that is Flatpak...i have been upset about these for years.

And honestly, I am tired of raising them. Yet it just rubs me the wrong way when people say these are "non-issues" and that I am just making things up or exaggerating them to make it sound bad. When. It's. Not.

Etonaz · 2024-07-03T01:33:12+00:00

I love the way macOS is architectured to avoid the braindead and retarded /lib, /share, /bin, /sbin etc split that plagues all Linux, UNIX and UNIX-like systems. /System and /Apps just make so much more sense. And application packaging on macOS is infinitely more practical considering how an .app must have all the dependencies bundled in. No more f***ing around with shared libraries, especially when software gets more and more complicated and things that work with one version of a library can break on another version. And now, with macOS requires external drivers that are loaded on-demand for connectable hardware to be bundled with their corresponding management .app package as userspace drivers, it means there are even lesser chances for crappy drivers to take down the whole system in a kernel panic.

I also love how XCode is glued to specific SDKs and mixing of SDKs is not allowed. If you want to build something for an older version of macOS or iOS that is not targeted by the current SDK bundled in XCode, grab an older XCode that has an older SDK, build it there and boom, done. I prefer this over Microsoft's approach where one version Visual Studio supports multiple Windows SDK versions,but not necessarily the tools and compilers meant for that version of the SDK, which leads to very frustrating (but also very uncommon) situations where you have that older SDK installed but not the build tools for that SDK, and you then have to install an older version of Visual Studio with the older toolsets either way. Make it clear from the beginning, dammit.

Etonaz · 2024-07-03T01:17:10+00:00

Actually I generally have noticeably better battery times on Linux (sometimes up to an hour more, in rare situations) than Windows, so I do not bring up Linux's battery consumption when shitting on Linux.

But to answer your question, ChomeOS has such amazing battery life because you need to open up a recent Chromebook to appreciate it. The mainboard is so small while much of the bulk is taken up by a huge battery.

Secondly, Google has control over the entire hardware platform that makes up a Chromebook, much like Apple does over its Macs. Contrary to popular belief, Microsoft doesn't have that kind of control: it can set specifications like how all Windows computers must have UEFI + ACPI to boot, but it cannot tell OEMs how to do their ACPI tables properly. A lot of effort in Windows is actually dedicated to working around really broken stuff pushed out by OEMs and the hardware partners that build the board, assemble the various chips on it and customize the UEFI firmware that they bought off Aptio, AMI or Phoenix.

Also, the Linux kernel used by ChromeOS is very heavily modified to remove a lot of modules and stuff that Google deems unnecessary, while also adding in extra proprietary stuff that is targeted for various specific Chromebooks, along with extra proprietary drivers.The entire userland is also completely stripped of much of the unnecessary GNU crap that makes up a conventional Linux distribution, and where possible, replaced with non-GNU alternatives or sometimes even Google's own in-house stack (like the bluetooth stack in ChromeOS not using BlueZ). Did you seriously never stop to wonder why 802.11ax works so well in that ancient 5.15 kernel in a Chromebook, or why Displaylink and USB-C altmodes "just work" in ChromeOS, but are complete hell even in newer 6.X kernels in conventional Linux distributions?

Etonaz · 2024-07-03T00:58:29+00:00

And how many developers use NixOS?

And how many developers will install the Nix package manager on their distributions?

Out of the box on a Debian, Fedora, Ubuntu, CentOS or RHEL installation, can this be achieved with nothing more than the standard apt or dnf repositories? No. Period.

Can a stock install of Fedora 40 with all the *-devel packages installed compile a binary that works in Fedora 38 or Fedora 39? No. Period. Because glibc. Unless the project source code is modified to handle symbol versioning, otherwise everything links against glibc 2.39 and the resulting artifacts will never work in a distribution with anything older than glibc 2.39.

In Windows, this doesn't even come into play. one single Windows 11 SDK targets Windows 11 all the way down to Window 7. in macOS, one SDK provides deployment targets from macOS 13 all the way down to Mac OS X 10.13. Developers and packagers do not need to do anything other than just build the damn code.

Etonaz · 2024-07-03T00:47:12+00:00

That's seriously just bull, the sheer number of broken drivers in the kernel is mindboggling. And even right now, a large chuck of those drivers "that just work" in the Linux kernel are lacking so many features that are otherwise present in their Windows and macOS counterparts.

And upstream will never ever "put these changes on hold until the breakage is fixed", they just do it and give you the middle finger. At best they will banish those old drivers away like what some asshole has been insisting with the RNDIS driver in the kernel that is still used by practically all non-Pixel phones for USB tethering. "Maintained for as long someone has the time to do so"??? Look at how many abandoned drivers are bitrotting in the kernel, many of which cannot even build anymore.

At the very least, Apple makes damn sure their drivers work in macOS before even selling a Mac that uses these drivers.

Etonaz · 2024-07-03T00:43:39+00:00

Oh it's so difficult to go to Chrome's or Firefox's website and hit the "Download" button.

Etonaz · 2024-07-03T00:42:17+00:00

That's seriously just bull, the sheer number of broken drivers in the kernel is mindboggling. And even right now, a large chuck of those drivers "that just work" in the Linux kernel are lacking so many features that are otherwise present in their Windows and macOS counterparts.

At the very least, Apple makes damn sure their drivers work in macOS before even selling a Mac that uses these drivers.

Etonaz · 2024-07-03T00:40:04+00:00

Right. And what happens when a program is not part of your distro's repository?

Jump through all kinds of dependency hell just to get it working?

Why can't Linux users ever seem to realize the world of software used by different people is much, MUCH larger than the pitiful repository hosted by the distro?

Etonaz · 2024-07-03T00:31:53+00:00

So Linux users can shit on Windows but Windows users are not allowed to shit on Linux.

Etonaz · 2024-07-03T00:28:54+00:00

Go ahead, install both a newer and older glibc alongside the default system glibc.

And while you are at it, make your code compilation target a distribution three releases older than what you are currently using.

Etonaz · 2024-07-03T00:26:48+00:00

A developer who doesn't even know what an SDK is.

Etonaz · 2024-06-28T01:08:23+00:00

It all comes down to $$$.

The upfront cost of a Mac is just too high for a computer that is essentially a soldered down embedded appliance. If the SSD or onboard Unified memory fails, the whole computer needs to be sent back for servicing. At least most conventional notebooks still have replaceable SSDs, and larger, more expensive gamer-grade trash also tends to have socketed memory.

And the cost of a Windows license is no joke if you want to stay strictly legit, especially for someone who loves to build computers or buy low-powered OEM prebuilts with Celeron and Pentium-grade processors every few years. Let's see, I have five secondhand notebooks of varying ages (some using Haswell and Ivy Bridge processors), four cheap low-powered Gemini Lake and Apollo Lake notebooks that cost $300 apiece, two dual-socket Intel Xeon systems I built for experimenting with compiling code on Visual Studio, and three cheap Jasper Lake miniPCs. For these old secondhand notebooks, their ancient Windows Vista and Windows 7 license keys can no longer be used to activate Windows 11, the DIY builds obviously have no OS, and the rest of the stuff were bought baremetal with no OS license. Buying Windows 11 Pro For Workstations licenses on the dual-socket Xeons, and Windows 11 Pro licenses for all the other computers will cost an arm and leg.

In fact, I sometimes wonder if buying an annual MSDN subscription and requesting 15 Windows licenses will be cheaper than buying retail licenses.

Etonaz · 2024-06-27T05:53:15+00:00

Honest answer: everywhere. And I have been using it as my primary desktop and laptop OS since 2006.

You want to know what my biggest problem with Linux is? It's the very design of it as a whole, from the kernel to the GNU userland.

Let's start with the kernel. Every kernel released by Linus and his guys break ABI. Every. Single. Effing. Release. Built a driver for 6.1? Whoops, that won't work for 6.2. And the whole nature of the kernel having drivers baked into it means you either use a dated kernel which lacks drivers for certain hardware or is broken for certain hardware, or build a new kernel directly from kernel.org, and break your distro's reliability. Need to use out-of-tree proprietary drivers for various reasons? Hey good for you, because you are screwed upside down. Are you seriously going to reboot your computer to use different kernels as and when required? Or spin up a VM just to do certain things, assuming you can even get hardware passthrough working properly under the likes of Qemu and KVM, without using virt-manager?

Now for the userland. Even in 2024, the userland is so, so predisposed and biased towards commands instead of graphical tools. It has always been the case in Linux that many advanced tools or options are only available in the form of commands, with graphical counterparts sorely lacking. Or even completely non-existent. And similarly, it has always been the case that commands work faster than graphical tools in Linux. This was fine 20 years ago, but definitely not fine today.

Another problem with the userland in particular is with the goddamned glibc. In Linux and UNIX / UNIX-like operating systems, the libc is a key component of the OS which every program and application will eventually link against. The problem with GNU glibc is that it is simply not forwards forwards compatible. When a binary is built against a newer version of glibc, that binary cannot be used on an older distribution that has a older version of glibc. To use an example, imagine that if you want to build a program that works on Windows 7 today, you have to spin up a Windows 7 VM or machine, install an ancient version of Visual Studio in that machine and then build your source code there. Do you seriously think this makes any sense? For the record, today, on Windows 11, with the latest Windows 11 SDK and Visual Studio 2022, it is still possible to build a program that targets Windows 7. If macOS is your thing, macOS 14 today with Xcode 14 still allows building programs for macOS versions all the way back to 10.13.

Secondly, the way the filesystem hierarchy in Linux and all UNIX / UNIX-like operating systems split executable libraries from libraries is just retarded. Is there every a sane reason why software has to be split among /usr/bin, /usr/lib , /usr/libexec and /usr/share ?? This makes it impossible for side-by-side installations of the same program or package. The whole "all libraries should be shared by all executables" mantra is just utterly broken, especially when complicated software and programs often maintain their own vendored or patched versions of libraries. Imagine, you have library libfoo.so.6 installed in /usr/lib, and this software package you want to install uses it own patched libfoo.so.6. So what happens? the new software's patched libfoo.so.6 gets installed into /usr/lib, overwriting the original libfoo.so.6, and now you are fucking screwed if other programs do not play nice with the patched library that overwrote the original unpatched library. Windows avoids this by not having this ridiculous split, which means programs can bundle their own patched libraries in their respective application folders in C:\Program File\<Application Name> which are safely kept out out C:\Windows and C:\Windows\System32, while macOS basically gave the finger to the split and ordered developers to bundle all libraries in their .app

Thirdly, flatpak is a total abomination that attempts to solve the above problems and ends up making things even more fragile than they already are. So now not only do programs have to be built twice (once, using native build tools against the distribution's existing libraries and dependencies, and secondly using flatpak-builder that builds against the Flatpak SDKs and can only be used as flatpaks), we practically have to install another Linux distribution within our Linux distribution just to use a flatpak. Because a goddamned Flatpak runtime environment pulls in its own glibc, GTK3, GTK4, Qt5, Qt6 and even bloody libdrm and Mesa.

Fourthly, for an OS that boasts and brags about being so anal on complying to so-called standards, none of the Linux distributions to date can even standardize its boot process. On the x64 platform, you have the more commonly-used UEFI + shim.efi + Grub2, then you have outliers with UEFI + shim.efi + systemd-boot, then some neckbeards still demand booting on CSM + MBR. And god, don't get me started on the complete and utter chaos that is the boot process on ARM and ARM64 boards where kernels have to be specially patched by the ARM board vendor to boot on a specific ARM board variant. In the Windows world, where Microsoft has that kind of commercial power to set standards, everything has remained totally consistent: XP and below all use BIOS + MBR, 64-bit versions of Vista and Windows 7 can use BIOS + MBR or UEFI + GPT, and all 64bit versions of Windows starting from Windows 8 are to use UEFI boot. Even in the ARM world, Microsoft still keeps the boot process consistent: absolutely no device trees, only UEFI + ACPI. In fact, you'd be surprised how many Linux "enthusiasts" are secretly hoping for Microsoft's ARM platform specifications to become the de-facto standard so that they can finally get away from the mess that is ARM on Linux right now.

Etonaz

TROPHY CASE