[krisdol]

So I like coding in linux too. I absolutely prefer it over anything else; but, lately my ubuntu distro has not been able to wake up from suspend so I force a reboot when I get back to my computer after a prolonged break. And I was pretty intentional about not futzing around with X11 and third-party graphics with this distribution specifically to avoid this kind of thing happening and have a long-term Linux OS.

I also recently got a bluetooth adapter and found out I simply cannot turn on bluetooth. When I was younger, I had more patience to hack around with things until they work exactly as I like, but I'm surprised that I'm still encountering issues like these in 2021 on a desktop-focused OS.

I wish other OSes followed the unix philosophy more. I wish I could separate the windowing manager from the desktop in OS X, and have more extensive customization options over everything. It'd be nice if Windows had as nice of a filesystem organization story as any linux distro.

[Enginerrrd]

Honestly, it's weird that Ubuntu has the reputation that it does. I still conceive of it as a "user-friendly" distro in the back of my mind, but my experience is that it constantly finds new and interesting ways to break. Compare that to Arch, which was a PITA to setup once, but since I have, I've had one minor thing break on an AUR package and that's it. But Arch has the reputation as the one that breaks on updates.

My experience is definitely contrary to my conception of, and the reputation of these distros.

[shrimp_emoji]

Yeah. PPAs are such a user-unfriendly alternative to the AUR, which just has everything.

Also, Ubuntu (with GNOME), Kubuntu, and Xubuntu (but not Lubuntu...) recently switched to some new crypto greeter (the thing you put your password into to unlock your encrypted drive at boot) which glitches out very badly. On every other boot, it flickers between its graphical facade and the underlying CLI prompt, and single keypresses are interpreted as multiple ones. Lubuntu, however, uses the same crypto greeter as Manjaro seems to, which still works.

Also, a funny thing: my keyboard (a Code V3)'s Num/Caps Lock LED keys don't illuminate at all in any of the *buntus, though they do in Debian, Manjaro, and Arch (on both newer and older kernels than Ubuntu 20.04 currently uses).

It's pretty disappointing.

On the other hand, after around 2 years of using Manjaro without problems, kernel 5.10 got me recently. :D It has big problems. Same problems in Arch. But, unlike in Arch, a kernel rollback in Manjaro is an in-OS GUI and/or a GRUB selection away. Manjaro's been the sweet spot for me, and it looks like it'll continue to be.

On the other hand², some software I recently had to build explicitly refuses to run on any unsupported *nix systems, and it doesn't support Arch or Arch-flavored distros. :c (Hence my recent adventures in Ubuntu.)

So there's definite downsides to straying off of the Ubuntu-flavored Linux reservation, but Ubuntu's always been surprisingly buggy for me compared to Arch and Manjaro.

[wayneftw]

Sticking with an LTS/Recommended kernel has served me well in Manjaro. Currently I'm running 5.4.95-1.

Last year I was running a 4.x kernel but I began having an issue with some piece of software (I forget) that, when I researched it found everybody recommending a switch to a 5.x kernel which fixed it immediately for me.

Switching kernels indeed is extremely easy!

[shrimp_emoji]

Yep, rolling back to 5.4 saved me. :p

Just watch out for 5.10. Happily, 5.11 seems okay, but it's still experimental.

Sticking to the LTS is a great idea, though part of me wants to go "Well then why not just run Ubuntu?! ;w;", despite having some answers. (Funnily, Ubuntu 20.04 LTS actually updates from 5.4 to 5.8. Apparently, the Ubuntu LTS doesn't stick to the LTS kernel now! Unless it never really did.)

[shrimp_emoji]

>Also, Ubuntu (with GNOME), Kubuntu, and Xubuntu (but not Lubuntu...) recently switched to some new crypto greeter (the thing you put your password into to unlock your encrypted drive at boot) which glitches out very badly. On every other boot, it flickers between its graphical facade and the underlying CLI prompt, and single keypresses are interpreted as multiple ones. Lubuntu, however, uses the same crypto greeter as Manjaro seems to, which still works.

EDIT: it turns out that the falling back to the underlying CLI is the greeter's response to arrow key input (e.g., the up arrow key is "^[[A", which is multiple characters[0]). XD And, with Num Lock turned off, the numpad keys work as arrow keys.

0: https://unix.stackexchange.com/q/103608

[AnIdiotOnTheNet]

> It'd be nice if Windows had as nice of a filesystem organization story as any linux distro.

...are you serious? There's a lot of words to describe the Linux filesystem organization and 'nice' is definitely not one of them. Windows file hierarchy has some problems to be sure, but at least it doesn't scatter every application's files all over the hierarchy and require a specialized tool and database to track which ones belong to which applications.

[pizza234]

What do you refer, specifically?

Based on "application's files all over the hierarchy" it seems you talk about configuration files (data files can be spread all over, in any operating system; binaries in Linux reside in a few directories (/opt and /usr)).

If you refer to gconf/dconf, AFAIK they require a specialized tool but they're not scattered (you interact through the tool, after all, so they're centralized).

Possibly you refer to the Freedesktop configuration files. Those are definitely scattered, and some concepts are very obscure (the defaults system is indeed terrible, as it's scattered, and it has different concepts of default). However, they don't require specialized tools - in my experience, they're always text files.

[jcelerier]

> binaries in Linux reside in a few directories (/opt and /usr)).

and .local/bin and $HOME/bin and $that_path_where_python_and_ruby_put_stuff and let's not forget that one executable which is in /usr/lib/name_of_the_app for some reason...

[pizza234]

There's no limit to where applications can put their files, and this applies to any operating system, so complaining about, say, version managers has nothing to do with a given operating system.

If you take Windows, you're going to have %USERPROFILE%.pyenv for example, when it comes to Python (pyenv).

It's unlikely, but not impossible, that a binary ends under /usr/lib, since it wouldn't be in $PATH. If it's there, it's likely invoked via a script somewhere, and this is not good practice, and again, not inherently Linux.

$HOME/.local/bin is not good practice, for the same reason (not being in the standard $PATH).

$HOME/bin seems actually a good place for placing user-specific binaries, since there must be one place for them, and I think it's a proper place.

[AnIdiotOnTheNet]

I mean literally the application and its files. A package for something like KeePassXC[0] places its assets, "shared" libraries, and binaries in disparate directories mixed with other applications binaries, assets, and libraries.

[0] https://packages.ubuntu.com/groovy/amd64/keepassxc/filelist

Configuration files are a whole 'nother garbage fire mess, but that's true in Windows too so whatever.

[pizza234]

ok, you're referring to package management.

if you talk about configuration files, well behaved packages will differentiate removal and purge; the latter will remove configurations and data.

> [0] https://packages.ubuntu.com/groovy/amd64/keepassxc/filelist

what's wrong specifically with that? based on the list of files, the package is well-behaved, as it's placing the files in the expected locations (I personally didn't know about /usr/share/metainfo, but seems correct). also, it's not clear why the quotes in "shared" libraries; .so is a shared library extension, and it's proper design to make it available.

apt takes care of those files, so there's no problem. how it handles the data files should be described in the scripts, but this is up to the package maintainer.

Windows, for comparison, is hell, since applications install files pretty much where they want, and that's why Windows, in the long term, gets more polluted than Linux (worst offender - leftover DLL, which impact the system).

OS X could be the good reference for your isolation standards, but keep in mind that that level of isolation prevents reuse, and indeed, the open source package management reference is Brew, which has its own rules.

[AnIdiotOnTheNet]

As I said, what's wrong is that organizing files in this way is that it necessitates something like a package manager to keep track of which files are associated with which applications. This is not a "nice" way to organize things, it's a needlessly complicated one as evidenced by the operating systems, both current and historical, that don't do that and don't need a package manager.

> Windows, for comparison, is hell, since applications install files pretty much where they want, and that's why Windows, in the long term, gets more polluted than Linux (worst offender - leftover DLL, which impact the system).

Applications rarely install files (other than configuration files) outside of their own 'Program Files' directory. What you are saying was true until about XP, IIRC, but generally isn't today.

In my opinion RiscOS, NeXT, the original MacOS and current MacOS have the right idea with their single-object applications. It prevents reuse, yes, but the majority of "shared" libraries are used by exactly one application anyway, and the continued interest in container technology are evidence of all the problems caused by trying to share everything anyway.

[cycloptic]

I don't see how the current MacOS is any different from Linux there. For end-user applications you can have the user download an app bundle (equivalent to AppImage) or get it off the app store (equivalent to flatpak/snap). For random open source libraries and utilities, you still would want to use Brew or Macports, which are package managers.

[cycloptic]

It's popular for Linux distributions to have a scattered hierarchy with a package manager, but it certainly isn't a requirement. Take a look at AppImages.

[AnIdiotOnTheNet]

AppImages are pretty great, when they actually exist for your applications. It is exceptionally disingenuous, however, to suggest that the existence of some AppImages invalidates the file hierarchy organization problems of any distro.

You might have been better to point out the existence of GoboLinux, but that is but one not very popular distro among many.

[cycloptic]

Please do not baselessly accuse me of being "disingenuous," I'm trying to help you. If you won't use GoboLinux or ask packagers to make AppImages for the apps you want then I don't know what to say, those are solutions to your problem. If you're saying you want all other distributions to be like GoboLinux, I doubt that would happen because that comes with its own set of other problems. Edit: You can do some pretty interesting things here with Nix/Guix too although that still requires a package manager. The reason I said AppImages is because that's currently the best method that doesn't require any package manager at all.

[AnIdiotOnTheNet]

> Please do not baselessly accuse me of being "disingenuous," I'm trying to help you.

Help me with what exactly? Am I in need of saving for my denial of The One True UNIX Way?

> If you won't use GoboLinux or ask packagers to make AppImages for the apps you want then I don't know what to say, those are solutions to your problem.

There are lots of reasons I don't use GoboLinux, not the least of which is that I don't think compiling applications from source is a reasonable application distribution method in 2021. As for asking application developers to make AppImages: why do you assume that I don't?

Regardless, the point is that the "Linux filesystem organization story" referred to by the parent is neither GoboLinux nor a bunch of AppImages and you are being disingenuous to pretend otherwise. It's a tired old Linux Desktop evangelism tactic roughly equivalent to "well, Linux is just a kernel...", which is to say that the argument is that what Linux Desktop (and by extension its filesystem organization) is is so ill defined that it can be whatever you want it to be -- provided you write most of it yourself, from the kernel up, like Android.

However there is a clear "way things are done" for the vast, vast majority of Linux distros and that is obviously what's being talked about here.

[cycloptic]

I haven't "pretended otherwise" or evangelized anything, please don't make these accusations at me. I can only offer you suggestions on what to do, I'm not going to argue about what the "right" way to do is as that's simply not interesting to me. The vast majority of Linux distributions may not do things the "right" way but they also support AppImages, so use that to your advantage. If you had no success in getting upstream to make AppImages then you'll have to make them yourself. It seems that's what a lot of flatpak and snap packagers ended up doing, just my observation.

To put this another way: We can sit here making the same complaints about Ubuntu and RHEL that have been made for decades, but what's the point? Let's do something about it. And if that doing something means we turn the whole system into AppImages, then... what else would you really want? It sounds like your problem would then be solved.

[teh_klev]

Can I refer you to:

https://news.ycombinator.com/newsguidelines.html

Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

I have no idea how you got the idea that cycloptic was being disingenuous, evangelising or trying to save you "for my denial of The One True UNIX Way".

> I clearly neither asked for, nor want your suggestions! (from below)

On HN most people like to chip in what they think might be suggestions. Either say thanks, but no thanks, or just say nothing instead of being rather rude.

[grifball]

What laptop do you have? You may know this, but for anyone who doesn't: with Linux, you really have to choose the laptop model from a list. Here's a good list for Ubuntu: https://certification.ubuntu.com/desktop

I've got two thinkpads that I've never had any real problems with. One is a 2-in-1 and the tablet mode is amazing with xournalpp (I've never owned an iPad so I can't compare).

Bluetooth is always a little testy though. Lately, it's been getting a lot better, but if bt is a make-or-break feature, you might wanna try wsl or a VM.

Also, remember to 'sudo apt upgrade'. It fixes a lot of random problems.

[krisgenre]

>>ubuntu distro has not been able to wake up from suspend

Yes, this has been bugging me too. At work, I recently upgraded to a Dell Precision running Ubuntu 20.04 and this has been happening quite frequently (a bit less since a firmware upgrade). Strangely this was never an issue on my previous Dell Latitude running the same.

[BrS96bVxXBLzf5B]

Possible avenue of investigation from my experience years ago, it was Light Locker. Across multiple installs.

[kitsunesoba]

For the bluetooth adapter, you might need a distro with a newer kernel. I recently put an Intel AX200 wifi+BT combo card in an old laptop and couldn't get it working in Debian 10, but it works perfectly out of the box with Pop!_OS 20.10.