People keep recommending it, I guess I will give it a try.
For a minute I was fascinated by GOBO Linux, and I really thought it would take off, but I think the developers must have moved on since there have been no updates. However, the ‘recipes’ seem to get actively updated, so maybe it is a stable enough system.
Nope. I’ve been running Debian for the past six years after I got tired of messing with arch. I’m over my shiny new thing syndrome and am happy with old but stable software. I’ve tried some flatpaks but the only two that I use are Spotify and signal. They take a lot of space and updating is slow.
I agree that stability is important, perhaps paramount, in a computing system. Still, some software like Cura, improve with every release, and it is worth upgrading for every new feature.
Anyways, I have never been concerned with space. On the whole programs don’t take up that much space compared to everything else I would put on my system like games. Also, I am the kind of person who wants all the software they would ever use installed on their system. I want my computer to be useful even when the internet goes out.
If you’re playing games, then latest software in terms of kernel and libraries are important. There’s a reason why valve switched to arch as a base for steamos. For my use case, I do a lot of coding in C using emacs so thing don’t really change that much. To each their own, that’s the beauty of Linux!
Thank you for saying this! The negativity here has been jarring. I understand preferences, but no reason to be mean about them.
I wanted to stay with Arch awhile back but I kept messing up the install of Nvidia drivers in like every distro, so I just have a lot of apprehension. Maybe it is better now. Still, I am in a good place distro wise.
Emacs the portable lisp machine that can do virtually everything. That must be so fun.
I seem to be in the minority here but I personally prefer using $ and # to denote root. I like this because not everyone uses sudo and might not even have it installed.
That being said, if you already have other commands that are using sudo -u … to run commands as a different user then it might be best to just be consistent and prefix everything with it, but if there is only a few of those maybe a # cp foo bar && chown www-data bar is an alternative.
Yeah, being consistent is definitely important. I can avoid sudo in many cases, but there are other pages where half the commands need to be executed as some user.
My Nextcloud page has that problem where php scripts need to be executed by the right user. But it also contains the installation instructions and there I can avoid using sudo. It’s like a 50/50 split between using # and sudo -u on that page :/
If you want a rolling release and like fedora maybe looking at rawhide. Otherwise suse tumbleweed is a solid choice.
Since you’re asking about Debian then SID is pretty much the rolling release version. This is what Ubuntu pulls from before doing their stuff. If you want close to bleeding edge this is a great way to get that rolling release feel. I know a few people who swear by it! I ran SID for a little while and it was okay but not for me. Arch was definitely better IMO for that. It’s also pretty easy to install arch (or gentoo) these days.
the fact with arch is that I’m a bit scared of messing things up, I was reading some articles about it and the AUR and I don’t know if I’m ready yet
how much unstable is debian unstable (XD) in your personal experience?
Personally, I'm looking for reproducible environments where if you create a lock file of your packages, you will get the exact same system on another machine if you copy it over
What’s good about AppImages? Imo they’re the worst packaging format; you can’t install and upgrade them from the command line like with native packages or Flatpaks, there’s not a repository-like centralized place for them, they get messy quickly since there’s not really an “official” default installation path so it’s up to you to keep them organized, they don’t integrate with system themes very well and you need a separate program (AppImage Launcher) to even get them to show up as an installed program or even pin them to your taskbar.
You have outdated information. There are no longer any tradeoffs to AppImages:
Yes there is no “official” default installation path, but like how XDG_DATA_PATH isn’t technically a standard but practically it is, the de-facto standard is ~/Applications now, and most AppImage-based tools respect that.
They integrate fine with the system. Better than Flatpack and Snap, actually. I’ve had lots of issues with flatpaks not respecting themes, but never AppImages. Not sure where you got that from.
I solved the other problem with AppImages with a package manager I wrote. Centralized location pointing to AppImage urls, and it downloads and keeps them updated. And no, you don’t need to write your own, there are multiple AppImage package managers out there.
On the flip side, there’s no weird extra locations like how flatpak installs apps, you know exactly where the program is in case you want to launch it manually, you can mix apps available in your package manager with ones you download directly seamlessly, no dependency hell or version problems as AppImages are self contained (even multiple versions at the same time), etc, etc, etc all the benefits people spout about AppImages.
AppImages imo are the superior cross-platform package format as there are no tradeoffs and no downsides, meanwhile:
Snaps are slow and proprietary
Flatpaks suck to create and maintainers select all on sanboxing, so it’s a complicated mess for no reason, and they also have bad theming that never works half the time.
I like this take. I am reading up on how flatpak works, and what seems to be most important is including the dependencies needed to run an application, regardless of what the system has, which is great.
I still need to try out Gentoo one day… but it seems like Nixos is the new Gentoo?
Idk about “new Gentoo,” as they’re going for different things, for sure, but a lot of the reasons people like Gentoo seem to be true for Nix. Definitely still give Gentoo a try some day.
I used it for a few months and only moved on bc compiling was taking too long and was annoying me :)
I had fedora installed the last few years, and was digging flatpak.... until I wasn't. One day I ran out of disk space - 230 Gb of flatpak dependencies. I run a pretty slim system, so what the actual heck? Did some research, learned how to flush cached and redundant packages, shrunk my flatpak deps to.... 150 Gb
It was likely the build up of a few years' packages, updates, and so on, but it eventually came to a head and I had to wipe and load. Maybe it's better now, but I think I started that install around Fedora 34? So not too long ago
I use flatpaks mostly. Flatpak dependencies (runtimes) are stored separately from the host system so and don’t bloat my system with unwanted libraries and binaries. App data and configs are stored separately and better organized. Everything runs in sanboxes. I use overrides extensively. All these are very convenient for me.
That is a good deal. I was briefly under the impression that those were not accessible, but that would be totally against the principles of everything Linux is about. So permissions set by the developer are just their biased defaults, nothing permanent.
Some points I handpicked for you. Ignore the uninformed masses.
The Debian GNU/Linux FAQ
Chapter 3 Choosing a Debian distribution
3.1 Which Debian distribution (stable/testing/unstable) is better for me?
If you are a desktop user with a lot of experience in the operating system and do not mind facing the odd bug now and then, or even full system breakage, use unstable. It has all the latest and greatest software, and bugs are usually fixed swiftly.
3.1.5 Could you tell me whether to install stable, testing or unstable?
Testing has more up-to-date software than Stable, and it breaks less often than Unstable. But when it breaks, it might take a long time for things to get rectified. Sometimes this could be days and it could be months at times. It also does not have permanent security support.
Unstable has the latest software and changes a lot. Consequently, it can break at any point. However, fixes get rectified in many occasions in a couple of days and it always has the latest releases of software packaged for Debian.
3.1.6 You are talking about testing being broken. What do you mean by that?
Sometimes, a package might not be installable through package management tools. Sometimes, a package might not be available at all, maybe it was (temporarily) removed due to bugs or unmet dependencies. Sometimes, a package installs but does not behave in the proper way. When these things happen, the distribution is said to be broken (at least for this package).
3.1.7 Why is it that testing could be broken for months? Won’t the fixes introduced in unstable flow directly down into testing?
The bug fixes and improvements introduced in the unstable distribution trickle down to testing after a certain number of days. Let’s say this threshold is 5 days. The packages in unstable go into testing only when there are no RC-bugs reported against them. If there is a RC-bug filed against a package in unstable, it will not go into testing after the 5 days. The idea is that, if the package has any problems, it would be discovered by people using unstable and will be fixed before it enters testing. This keeps testing in a usable state for most of the time. Overall a brilliant concept, if you ask me. But things aren’t always that simple.
tldr: “The goal of the Debian project is to produce Stable”. Sid is essentially a rolling release, it’s nothing like Fedora Rawhide in the old days when was essentially a testbed for Red Hat but it’s not meant to be as smooth as, let’s say, Arch or Tumbleweed. Testing in the other hand isn’t merely some layer between Unstable and Stable, it’s part of a bigger project, Testing exists for the sake of Stable, not for the sake of Testing. Same logic applies to Unstable but you do achieve some level of “just works” when you’re just pushing all the latest software, after all Debian also has Experimental but you should still expect breakage when something truly major happens.
Although this is useful information, gratuitous displays of hubris are gross. You should do yourself a favor and keep reading - it is clear that the decision should be up to the user after careful consideration.
All of the issues in regard to testing have well known mitigations which are trivial to implement. You can find this information and the corresponding links here
It is a good idea to include unstable and experimental in your apt sources so that you have access to newer packages when needed. With the APT::Default-Release apt config setting or with apt pinning you can have packages from testing by default but if you manually upgrade some packages to unstable or experimental, then you will get upgrades within that suite until those packages migrate down to unstable or testing. The apt pinning needs priorities lower than 990 and equal to or higher than 500 for this to work nicely. You can also pin some packages to unstable/experimental that you always want the latest versions of.
It is a good idea to install security updates from unstable since they take extra time to reach testing and the security team only releases updates to unstable. If you have unstable in your apt sources but pinned lower than testing, you can automatically add temporary pinning for packages with security issues fixed in unstable using the output of debsecan.
Although this is useful information, gratuitous displays of hubris are gross.
Oh, looks like I hit a nerve.
It is a good idea to include unstable and experimental in your apt sources so that you have access to newer packages when needed. With the APT::Default-Release apt config setting or with apt pinning you can have packages from testing by default but if you manually upgrade some packages to unstable or experimental, then you will get upgrades within that suite until those packages migrate down to unstable or testing. The apt pinning needs priorities lower than 990 and equal to or higher than 500 for this to work nicely. You can also pin some packages to unstable/experimental that you always want the latest versions of.
It is a good idea to install security updates from unstable since they take extra time to reach testing and the security team only releases updates to unstable. If you have unstable in your apt sources but pinned lower than testing, you can automatically add temporary pinning for packages with security issues fixed in unstable using the output of debsecan.
And that’s why Windows users say Linux is for nerds. At that point it would easier to switch to Arch, or at least just use Sid and maybe set up some rollback mechanisms.
When I first used it it felt like they were usually out of date or missing. But nowadays It seems like I can find like 90% of the apps I use as flatpaks, leaving packages mainly for backend and terminal stuff.
Just keep in mind that you will not be receiving speedy security updates, and in some cases you will need to wait for quite a while before packages you have will be updated (weeks, maybe longer).
If you want a proper rolling release distro that is not Arch/Gentoo/Void/Nix/GuixSD, you could go for openSUSE, which provides a rolling release distro with a system rollback feature by default. Nice, easy to use GUIs for whatever you need. Although openSUSE also is sometimes a bit slow with the security updates for some packages, it’s nowhere near as slow as Debian testing.
What you’re proposing is creating a Frankendebian, which Debian explicitly warns against doing. The proper way of getting security patches from unstable would be to pull the source debs and compile it yourself against the current Debian testing base.
This lane of thinking however seems to be completely misguided when it comes to the target audience here, that is, a user who is not even experienced with Linux in general enough to know about various rolling release distros. Telling a user this inexperienced to go with either of those is in bad taste at the very least.
linux
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.