Yes, Really, Even After All That
This was an unexpectedly phenomenal discussion:
Thank you, DEV, seriously, I'm blown away by how many of you were compelled to add your take. The discussion there turned into a highly useful resource with a wide array of perspectives, experiences, and opinions from people who really know what they're talking about, and I'll be returning to it as a reference time and again.
I carefully read every single comment, and took all of your well-informed perspectives into consideration, but ultimately went with my initial instinct and installed Debian Buster.
The first half of this post is a somewhat defensive run-down of why I picked Debian instead of, oh, pretty much anything else, and the second half is a log of the installation process and post-install configuration I've done so far, more for my own reference than anything else.
Trusting Instinct
I'm sure many of you are shaking your heads at me, wondering how I could have made such a poor choice after all that discussion. It's actually happening to me too, don't worry. I'm looking at this as an experiment.
The two runners up after reading through the responses were KDE Neon and Pop!_OS. I hadn't even considered Pop!_OS initially, and am quite glad so many DEV users spoke so highly of it - it's considerably cooler than I thought. I think there's a good chance y'all are correct about Debian and its shortcomings as a main work distribution, and if so I'm headed straight for Pop!_OS. I guess I just need to see it for myself first.
At the end of the day, while I think Manjaro or Solus sound fun, or sticking with Gentoo or a derivative like Calculate, Debian compatibility was the primary driving factor. Once that decision had been made, it came down to whether I wanted to pin to Debian Stable or Ubuntu LTS as a base.
Between those two, most (but not all) of you recommended Ubuntu (or an Ubuntu derivative like both Neon and Pop!_OS) because it more squarely fits my "just forget about it" criterion. Debian's philosophy and user experience is great for servers, but perhaps not designed for desktop end-users. I think that's generally true, but wasn't completely sold that it wasn't right for me specifically anyway.
The primary shortcoming mentioned for Debian was that all of my software will always be out of date. I gave this some thought and looked at my current software usage, and concluded that I don't actually care. I'd much rather have a system that's thoroughly vetted and tested than get all the cool new stuff that comes out. I often never use it anyway, or at least am happy to wait for some nifty KDE trick until it does trickle its way into Debian in a few years. I kind of can't believe how long I spent on bleeding edge rolling-release distributions for - if I'm being honest with myself - very little reason. It makes sense for a lot of people who do care about and use that stuff, but I really just don't. So what if the version of cairo I'm on is years old? It's doing the thing I need it to do. More specifically, what I need is for it and all of my system components to play well together, regardless of what specific versions of each I'm running. That's Debian's entire raison d'être: stable doesn't break.
I also don't need everything to "just work" without intervention, which is Ubuntu's sales pitch. Thinking about it more, I don't think "just forget about it" is really my goal. I want to keep learning from my system, I just don't want to waste time. I don't think Gentoo itself is necessarily the culprit (it's definitely me, I'm the culprit), but it's not helping in that regard either. Debian is boring in a way that I need it to be, and Gentoo isn't.
That said, I am capable of and generally don't mind configuring my system and do like retaining that control. I had to install non-free drivers for my wireless and graphics cards, so now I know what my system needs in the Debian universe. Now that I've done it once, it's just as much a non-issue ongoing maintenance-wise as Ubuntu would have been. The problems come for me when that extra control leads to time wasted, or creating extra work for work's sake. I don't mind a little real work to get everything the way I want it to be, though, especially if it results in a highly stable system.
There is still a bit of hesitation, because I know inevitably I will want a more updated version of something than what Buster includes, and I did get a bit of a mixed review when it comes to selectively updating specific packages. Debian packaging itself is mythically horrific, a far cry from what I'm used to with ebuilds.
Ultimately, I chose Debian because it's an industry standard, and the base from which all these other operating systems are derived. I think it's important to become well versed in what's actually widely used in the real world as well as what I find elegant and fun. This philosophy guides a lot of my tool choices - my two main programming languages right now are C++ and Rust, I like experimenting with alternate shells like zsh and fish and scripting tools like ClojureScript/planck but I still make sure to learn plain bash, I try to make a point of practicing functional programming concepts in both Haskell and JavaScript, et cetera. I get a lot out of comparing and contrasting the tools I learn by learning two sides of a particular coin concurrently, and end up with (I think) a deeper understanding of the pros and cons of both as well as a working familiarity with the one more likely to be useful in the long term. It makes sense to me to apply this thinking to my OS as well.
For this reason, I've decided to see Debian through for a while and then potentially re-assess down the road if it turns out I am spending too much time making it work instead of working. At that point, a more polished Ubuntu LTS-based experience will likely be the remedy. I know it's far too early to really tell, but for now I'm completely satisfied with Debian Stable.
Installation Log
The above was a mild fib. The very first action I took was trying to install KDE Neon, but the live disc didn't boot on my hardware in either graphical or OEM mode. It got through GRUB and then crashed, every time. I wrote it to different media, tried multiple times, nothing. While I still kinda would have liked to try this distro, and know there absolutely would have been a way to get it running - I'm pretty sure it's just a graphics card issue - that's a poor first impression, and pretty much why I ran straight to Debian next, and in retrospect I am glad I did.
Getting to First Boot
As expected, Buster installed without a hitch on the first try. New in Buster is UEFI Secure Boot support, so I didn't have to do a thing first. I just cleared the way in my partition table and let the installer do it's thang. It correctly found my other operating systems (Windows 10, NixOS) and installed GRUB the way I would have done it myself with minimal hand-holding.
The migration from Gentoo was painless. I tarballed all my PDFs and popped them on a flash drive, then reformatted my Gentoo partition. Seven years of configuration, obliterated in a mkfs. Everything else I need is hosted in an offsite git repo, including dotfiles. No use getting sentimental!
Okay, I lied again - It actually wasn't quite without a hitch but it was my fault, not Debian's. I was a little stupid and didn't bother customizing the install, so initially I had a similar problem to the KDE Neon disc - it would start the boot process and then die trying to load the graphics driver. Luckily, the Debian live disc has a "recover" mode, and I was able to enter a rescue shell on my brand new install. All I needed to do was edit /etc/apt/sources.list to include contrib and non-free:
# https://unix.stackexchange.com/questions/449794/installing-nvidia-driver-for-debian-stretch
sudo sed -i.bak 's/buster[^ ]* main$/& contrib non-free/g' /etc/apt/sources.list
Then I ran apt update && apt install nvidia-drivers. This actually ended up crashing the live CD once the driver was installed, but then it booted up from the hard drive perfectly. Solved!
I used a wired connection to run the installation from the netinst disc image. The default installation didn't install the proprietary driver I needed for my Realtek WNIC, but the above step enabled the non-free repository I needed. I installed the firmware with apt install firmware-realtek and was immediately able to connect to my home LAN, no other configuration was needed. The base KDE installation came with NetworkManager and plasma-nm.
Post-Install
I decided instead of trying to replicate any experience I had in the past from a tools-first perspective off the bat based on a preconceived notion of what I'd need, I'd just try to go about my business normally. This would force me to install and configure stuff as I go organically in hopes of cutting to the core of what I actually care about. This is what I've done so far.
Preloaded Software
My first order of business was a web browser. My currently preferred browser is Firefox and the options I chose at install came preloaded with Firefox ESR v68.3.0. Eventually this might be one that I look in to getting more recent updates for especially if I end up working more with web development than I currently do but it's fine with me for now.
I did a quick webcam test call, both audio and video worked out of the box on my external USB device with no additional installation or configuration.
I also use LibreOffice for schoolwork and spreadsheets. This installation came preloaded with version 6.1.5.2 - also fine with me. I also frequently use both GIMP and Imagemagick, which were both preloaded as well. Core components like gpg and ssh were also preloaded and I was able to configure both as needed with no surprises. A comprehensive suite of KDE software is included, unlike Gentoo which gives you the basic desktop and lets you pick and choose. There's a bunch of these I don't use but some I do almost daily like Spectacle, Dolphin, Kate, KNotes, KCalc, and Okular. It was honestly great to not have to install anything extra to click right back into my familiar, comfortable workflow.
All in all, the default set of packages is not excessively bloated at all and largely consists of either things I actively want and use or little extra KDE components that I don't mind having around and may even want to try someday. The extra stuff I installed was pretty much entirely confined to development environment tools. That's an A+ experience in my book.
Acquiring My Development Environment
Before getting started with the process of building out the system I need, I needed to add my user to the sudo group. Weirdly usermod lives in /usr/sbin but that's not in $PATH by default, so I added export PATH="$PATH:/usr/sbin/" to .bashrc for both root and my non-admin account. Then I was able to run usermod -a -G sudo ben, narrowly avoiding starting off my Debian career by having an unauthorized sudo incident ominously reported.
Now able to run apt safely from my user account, I decided to pull down a few Rust and C++ repositories I've worked on recently and compile them.
First, though, I installed my preferred development editors. Emacs went in with apt install emacs, but lately I use Visual Studio Code for pretty much everything except a few specific cases. Buster doesn't package this one, so I downloaded the .deb directly and invoked sudo apt install ./code_1.41.1-1576681836_amd64.deb - easy enough. I also needed to install rustup directly using their curl one-liner which doesn't come by default. At that point I grabbed a few other extras I knew I'd need immediately: apt install curl git htop tmux. At this point I've always been in the habit of installing neovim, but I skipped it for now - there's nothing wrong with nano for tasks I used to use nvim for, and it's usually available everywhere.
The Rust toolchain installed fine, but cargo install cargo-update failed when building openssl_sys. I needed to install both pkg-config and the ssl development headers: apt install pkg-config libssl-dev. To build my music project that interfaces with the system audio output device, I needed the ALSA development headers: apt install libasound2-dev.
Getting my nannou_dots project running was a little more complicated. I needed the following tools from Buster repos: apt install cmake python3-distutils libxcb-render0-dev libxcb-xfixes0-dev libxcb-shape0-dev. It also depends on the Vulkan SDK, and I was pleasantly surprised to find I could follow the instructions to add the Ubuntu 18.04 PPA exactly and have it work fine: apt update && apt install vulkan-sdk. Afterwards the vkvia test program executed without errors and I could build and run my demo app.
I've heard that's a pretty bad idea. How bad, exactly, is it? What Ubuntu<->Debian incompatibilities should I be aware of?
For C++, I installed a few tools: apt install clang cppcheck gdb valgrind.
I also use Haskell sometimes: apt install ghc.
I set up Node and pnpm with sudo apt install npm && sudo npm install -g pnpm.
I also have a soft spot for bc for doing arithmetic in a terminal: apt install bc.
At this point, I feel I've more or less met all the needs I have after only a few hours, and feel generally confident both that I will be able to meet new ones as they arise and that I shouldn't need to touch it much at all. Being Debian-compatible does feel like a breath of fresh air even though I did genuinely enjoy Gentoo and found it easy to use, and being Debian itself hasn't thus far proven to be a roadblock.
Notes
You can search for a package by keyword with apt-cache search. You can get the current Debian version in /etc/debian_version: 10.2.
Top comments (10)
Great readings both articles. Let me share how I manage packages in my Debian system and install from unstable and testing without breaking things.
The thing is to create separate config files for stable, testing and unstable, and configure it so packages priority comes like so: Stable > Testing > Unstable.
now in
/etc/apt/sources.list.d/Rename your
/etc/apt/sources.listinto/etc/apt/sources.list.oldto use the new stabe, testing, unstable list created.NEVER install ubuntu PPAs (wiki.debian.org/DontBreakDebian), if you need a more recent package (be aware of installing things like KDE or other huge packages with a lot of dependencies) just
apt -t unstable install firefox(or -t testing). There are also backports.debian.org/ at your disposal.For Haskell, rust, node, go and ruby I use github.com/asdf-vm/asdf. Docker, Mongo, Vscode and other stuff I install from their official packages (not the debian ones). That way I have an up-to-date runtime and devel environment with a rock-solid base system.
Compared to gentoo, debian package system is like you said
horrid, but backport packages from testing/unstable to stable is not that difficult: wiki.debian.org/BuildingFormalBack...Anyway, good luck and I'm looking forward to reading the 3rd part of this series!
Incredible, thank you SO much for the write up! This is precisely what I was looking for, this config setup is the first thing I'll do when I get back home today.
I was worried about that. Fair enough. To fix the damage, will it be sufficient for me to
apt purgethe offending package, remove the offending line fromsources.list, then do anapt update && apt autoremove? Then, to actually obtain the needed package, they only provide Ubuntu.debfiles and generic tarballs. When you run into a similar situation, do you just stick to the tarball or try to build a Debian package?Asdf has been on my radar for some time but I never got around to trying it - Gentoo covered my needs out of the box here. I'm not opinionated about any of these except Rust, which I use
rustupfor. What's the benefit of usingasdfinstead?I noticed when I installed VS Code it actually added a PPA for me during the transaction, which is both awesome (I thought it was forever going to be up to me) and scary (I didn't even know a package could do that, and I don't recall
aptletting me know it was taking that action). Have you run into packages where this behavior is problematic, or should that generally be the accepted solution?Thanks again, huge help!
I forgot about those situations where only Ubuntu packages (or no packages at all) are available (hello AMD). In those cases I directly use the tarball, the only downside is that I have to update it manually. In my case, it's very simple because as for today I don't use/need any external software not covered by Debian packages. However, I doubt that you are going to run into any problem with just the Vulkan SDK, so, if it works right now, let it be, but next time try to avoid using Ubuntu packages unless there is no other option :).
I didn't know about rustup! I only toyed with rust but nothing serious.
I use asdf because I'm lazy and having one tool to rule them all seems convenient, but I don't think it has any real advantage over rustup.
Some Debian packages install in your /etc/source.list.d/ a
.listarchive with a repository. For example, in the case of VSCode:http://packages.microsoft.com/repos/vscode stable main. The main difference is that this repository is maintained by Microsoft instead of the community. Other examples, like Docker:https://download.docker.com/linux/debian buster stable.These repositories tend to stay up-to-date, as a rule of thumb, if there is an official repo/package I install them over the stable packages unless I don't care about the version.
Don't break Debianwiki page has really good advice.Lastly, Glad to help and welcome to the Boretown!
Heh, I made it maybe 90 minutes before breaking a core "Don't Break Debian" tenet. That's a great link, will definitely be more careful going forward - might just clean this up anyway and switch to the tarball to keep it clean.
I do think
asdfsounds good in general - I use Rust a lot but the rest of those languages are more casual, experimental things for me so it's a perfect fit. Good stuff!Great exchange! I learned a lot, specially with the first reply of @flrnd and the way to set up stable -> testing -> unstable repos. Thanks A LOT for sharing your knowledge Florian :)
I faced the same issue recently on a Devuan install. I think you can do this too:
Then you won't need to change
$PATHand stuff.Great article to read. As far as I know you can't go wrong with Debian. It can be what you want it to be.
Personally however, I did not have a good experience with upgrading a point release distro, ever. So I usually choose rolling release distros for my work machines. Rolling releases are getting better now and they are quite reliable. If I were to use Debian, I would go with Devuan (because SystemD is too much of a bloat for me) and go with testing repos. That would give me a rolling release type of a setup with latest packages and reasonable stability.
Outside of Debian, I would choose Void Linux. It is so much faster that I couldn't believe when I first installed it on my system. It runs blazingly fast with runit init system, instead of SystemD. I was a skeptic at first to use a new init system, but it was surprisingly easy and felt like how an init system should work. Everything is a file, like unix philosophy says and so light. I even ran GNOME3 from a EXT4 (without journal) filesystem from a USB flashdrive, which I could not do with Arch with that responsiveness.
But whatever works for you is the best distro to go with.
Ah, thanks! on My Debian install
/usr/sbinwasn't inroot's$PATHeither, but it's possible I missed something.I hadn't heard of Devuan, thanks for the suggestion. Good to note about point release updates, I've really only ever used rolling release so I'm sort of waiting to see how that goes in April.
I was also curious about SystemD, because I've used OpenRC for years, but it doesn't bother me. Sure, it does a lot more, but I've found it highly easy to use - I guess it's a personal preference thing. I have pretty standard needs.
I do already use Void Linux on my laptop, and love it, but have had trouble getting some of my development tools like
dotnetinstalled. I'm not quite ready to use it exclusively, but in generally think very highly of it.Thanks for your thoughts!
So you've finally going Debian I see? 😌
I'm having an extremely hard time setting up dual wifi on the raspberry Pi 4. The purpose is to be able to leave it hooked up to my monitor in my work space which isn't in the same room as my router.
No snap please