Hacker News Reader

Hacker News

Comment by ausjke | Hacker News Reader

Full thread

ausjke

Debian for server, definitely.

Ubuntu for desktop, which is similar to Debian.

Openwrt for devices that has limited RAM.

FreeRTOS for MCUs with real-time needs.

That covers the universe for me, enjoy them all.

View on HN

I started installing Debian on desktop. It is far more stable than Ubuntu. And if you install the non-free Debian, there are usually no issues with wifi or graphic drivers (you need the non-free version though).

There was time where Ubuntu on desktop made sense, but now Debian is just better and more stable.

Has things changed ? Debian stable was too old and testing used to break something every time I updated. I moved to ArchLinux since then

From my perspective the mindset with Debian is that distribution packages are never going to be the super latest, but are going to usually work well.

If I need something bleeding edge it's straightforward to just download the source from wherever and install it myself with stow in /usr/local, which makes it easy to remove/upgrade if needed. I anyways do pretty much everything in VMs, so package availability for my "base" system (which I mostly use only to run VMs) is not that big of a deal. If I need bleeding edge I can always spin up an arch linux VM...

Been running Debian with XFCE on Testing lately. No problems here.

Debian stable has never been terribly old for several generations now.

Does what you do with your computer matter? Then you probably want to consider doing it on a stable platform.

Do you want to experiment? Sure thing, have fun — but be aware that you may lose data as a result.

Debian stable has been an excellent platform for me for the better part of a decade. But I'm unafraid to install newer version of some software where appropriate (e.g. emacs, or graphics drivers).

Debian testing hardly breaks anything unless one does a blind dist-upgrade instead of upgrade. The normal "apt-get upgrade" attempts to install the latest software versions unless the process requires the removal of other software (except the older version of course) so that (newer versions bugs aside) it won't break the system. The "apt-get dist-upgrade" will attempt to install the latest version even though it could force the removal of other packages, which can completely bork the system in many ways (missing libraries, etc). When I use it I often do a normal upgrade followed by a dist-upgrade and check all packages it would uninstall before allowing it to proceed, if I do. I've burned myself multiple times before learning this:)

Ironically, the "dist-upgrade" must be explicitly called on the command line, but is the default setting in Synaptic (called "smart upgrade" there). Synaptic is a GUI package manager most newbies would probably use in place of the command line, so I would expect its default settings to be more on the safe side.

same here: see my profile for how I set up from scratch debian for desktop and debian for xen+kubernetes. I personally like to have complete control of what gets installed in my system in terms of packages, have been running debian for years and it's been serving me very well.

I do think it's good to have Ubuntu to compete in the "turn key" / "new linux user" / "enterprise support" spaces, but it's good to be able to run plain debian without issues these days.

That's my experience, too. I have nothing against Ubuntu, but when I've had issues with it, they're always... some Ubuntu addon to Debian, and it turns out that I don't care about whatever feature that is. So last time I had reason to reinstall the OS for the main desktop machine, I just went back to Debian. Haven't had any regrets.

(All of my experiments with Docker/K8s/Terraform/etc. are running on VMs under FreeBSD/BHyve, another OS I'm solidly back to loving after being distracted by shiny objects, but that's a different story.)

I’ve had numerous colleagues pitch Debian testing for desktop as stable has absolutely ancient packages. It’s never worked as well as Arch.

This is the new stack:

    Desktop/Laptop: Arch
    Server: CentOS/Amazon
    Small footprint: Alpine

I’ve had my Arch install for 5 years and it still works with no issue. Latest packages, runs like a dream.

Docker makes the base OS largely irrelevant for testing in my workflows.

It's better to use Debian Unstable because Testing doesn't get timely security updates.

Unstable (aka Sid) rarely lives up to its name, having ran it as my daily driver for a few years. Comparatively, the months I spent on Arch were marred by packaging issues resulting in me switching back to Debian.

I want the maintainer to hold back an update and write patches when there are noteworthy regressions that hurt my workflow. The Debian package maintainers consistently act in my best interest, not that of the developer's or outside political interests. Turns out I find that really useful.

Debian Unstable is the base for Ubuntu.

It's not unstable at all.

The "unstable" there means that everything changes all the time. It does not mean that things break (although they do break way more often than stable - when I tried it, I did have to reinstall the OS every few years).

I was under the impression that `unstable` is... well, not stable (that it breaks). Is it usable for someone who doesn't want to spend much time fixing the system?

In Debian 'unstable' means that the package versions installed aren't stable. That is, there is a high level of package churn just like any rolling release. It isn't any more buggy/crash prone than any other rolling release. There is just a risk at running bleeding edge vs. vetted/known working software.

"better and more stable." How so? I never had any issue on the desktop using Ubuntu and it has better driver support. Debian has only old packages and the only way to get new one is to use testing / unstable.

When I tried changing into Ubuntu on the desktop (many years ago) the packages it added on the default installation kept breaking everything.

I am pretty sure that if you have a very standard machine and stay mostly focused on the GUI Ubuntu gives you a pretty good experience, but I did give up on it already.

For the same reasons I don't run Ubuntu on a server, I won't run it on my desktop, either. Too many times my Ubuntu systems have gotten themselves into some weird state where I can't keep using it and have to reinstall from scratch. For situations where I need more modern versions of stuff, there are either third-party apt repositories, there are static binaries I can download, or I can compile them myself and install them into /opt.

Ubuntu's best on servers IMHO. Can't beat PPAs for installing stuff. It's just the easiest.

Snaps are even better, but probably not worth the extra memory usage on servers

I concur, it's very hard to beat the diversity of package retention policies of all the different PPAs. There's no other solution among the package managers that allows you to get your system to the state that you can't replicate on some other server because the versions went missing.

Well, you can.

"PPAs" are just ubuntu-hosted Apt repos.

I've yet to find a server-focussed package that is both not sufficiently up-to-date in the main or back ports repos and there isn't a vendor repo for it.

Sure, adding a 1 line text file in `/etc/apt/sources.list.d` and a gpg keyring to `/etc/apt/trusted.gpg.d` is probably slightly more work than running `apt-add-repository`, but if that's what defines how you pick a server distro, I'd like to very much never work with you please.

PPAs make me very nervous. They're often on Launchpad (which appears to offer credibility) but AFAIK there are no checks on them, they're private repos the owner has given access to. Sure there are some, like inkscape-dev that I've can trust without too much issue.

AIUI installed packages get to run scripts with superuser privileges. This to me says "Danger Will Robinson!".

This is kind of my view.

Some are definitely operated by smart people e.g. Ondřej Surý offers his PHP packages for Ubuntu via a PPA (and via a regular apt repo for Debian).

As for the packages: they're literally just regular .deb packages, which means they're installed as root, which means yes they could do anything.

Of course you can also examine/extract them just like with a regular repo, but it's definitely an issue of trust for most people.

I trust that e.g the Varnish project, or Percona or the aforementioned Ondřej Surý are not putting shifty shit in their packages. I can't trust JimmyB on Launchpad the same way.

Since the headline here is Debian 9, it is worth nothing that changes in Debian 9 address a small part of this overall problem. One can nowadays at least not give one repository owner the power to sign impostors of every repository that one has configured, by associating a public key directly with an individual repository rather than placing it into a global keyring.

* http://jdebp.eu./Softwares/package-repositories.html#Debian

The rest of the problem still exists, though. Only one package manager that I know of even tries to address it, by having pre/post-install/upgrade/remove actions use a specialist declarative language for things like making directories and dedicated user accounts. But even that has a loophole that allows arbitrary scripts to be executed from within that language.

* https://freebsd.org/cgi/man.cgi?query=pkg-create#PLIST_FORMA...

* http://man.openbsd.org/pkg_create#PACKING-LIST_DETAILS

The loophole exists because the provided language simply isn't sufficient for everyday needs. It's quite hard to come up with one that is, whilst not being as worrysome as general-purpose shell script, too.

Reply on news.ycombinator.com