Debian 9.4 released
debian.org
debian.org
I find the Gentoo wiki has the clearest information about specific things, and the Arch wiki has the clearest information on how to put them together.
I really feel like easy internet access has taken good documentation away from us. It's too easy to Google for something, find some crappy blog with barely enough instructions to fix the problem. We've become reactive, rather than pro-actively educating ourselves.
I've been running Arch for about three years now and I've had one very minor problem when I didn't read the notes properly.
This is "Arch is unstable" thing is very much a myth pushed forward by people who only dabbled with Arch once or twice then had it break, then completely dismissed it as unstable. Without first learning how to use it even at an intermediate level - not even expert.
I too had Arch break when I was a newbie but I learned quickly how not to and it's been incredibly stable ever since. Not worse than Debian and more so than Fedora in my experience.
In retrospect my actions which had broke it originally had little to do with ArchLinux itself but a general inexperience with Linux and over-eagerness when using beta software (which you have to opt in to, it's not default with Arch).
The end result is that I've come out of it a far better Linux user with skills highly applicable to Debian and other distros. It's a far easy place to learn Linux/Unix properly and become familiarized with the OS/dir structure/config than any other distro.
I don’t have to be careful about opting in to beta software or anything else with NixOS. If I want to try something, I can do so, and roll right back if it doesn’t work out. The destructive nature of Arch package installs and updates is its biggest flaw.
This accurately describes my experience. I stopped using Arch around the time git broke when I updated. I'm not clear what mistake I made. What level of Arch intermediate or expert level Arch knowledge is required to keep git working?
Example 1: Using System Python on Debian is a notoriously terrible experience for example, because they split up the venv module from Python itself and distribute it separately. I've had so many issues because of that and there's no good reason to do it. It's part of the stdlib, it doesn't need a separate package.
Example 2: Debian Jessie shipped with the ancient pip 1.5.6 (https://packages.debian.org/jessie/python-pip - upstream is at 9.0.1 since 2016) which never got updated, just stayed stuck there, wtf? Such old versions of pip are lacking support for a bunch of things that python packages today use on setup, so it would install things in a weird way and then packages would be broken, users wouldn't understand why. One of the many cases of not giving users access to a more recent version of a package, causing the user's experience to be severely impacted (and of course, they won't know to blame debian or the pip version in this case).
Edit: Incidentally, that last bit is why I always, always do `pip install --upgrade pip wheel setuptools` whenever I create a new virtual environment to make sure I don't get issues installing packages.
pip relies on bundled libraries and tries hard to fight any unbundling (by using slightly patched versions of the dependencies if I remember correctly). This makes it difficult to package. You can see as an additional proof of Debian messing with packages while on the Debian side, this is just the application of a distro-wide policy. If every piece of software should get an exception to the rule, we don't have a distribution anymore.
And from what i can tell, quite a bit of upstream would see that as a good thing. They just want to stuff their thing into a container and call it a day, distros be damned.
To me that is like going back to the DOS days of software, or even close to the present day of Windows software, where everything is dangling off in their own sub-dir with all their snowflake variants of dependencies.
Damn it, go back a few years and Microsoft go burned by this when they discovered that there was a vulnerability in the VC++ redistributable dlls. All they could do was issue updates for their own software, a tool for scanning the drive for vulnerable copies of the dlls, and a wish that customers would badger their software providers for updated versions of affected software.
From a distribution perspective I sometimes wonder if it wouldn't be a better idea to call the system python/perl something like system-python/system-perl to make it more obvious they are not meant for use, and have a /usr/bin/python that tells you to install pyenv...
Having had quite a lot of experience of both, what I call, maintained packages and wild west packages (e.g. pypi), I would trust the former over the latter any day of the week. Developers generally do not make tremendously good maintainers. They tend to to only really care about the latest versions of anything, don't take particular care to make sure their package works well with other packages, rarely backport security fixes, and frequently do everything in a unilateral way. (I've seen it all, subtly different tarballs uploaded under the same version number, old releases deleted, breaking changes released under minor version bumps, addition of user-hostile "features", downloading & installing unexpected random binaries from the internet in attempt to make everything "just work", and of course they're forever bundling odd versions of other packages which they then don't maintain...)
Maintainers working on a "distribution" have a responsibility to make the whole distribution of software work well & stably together, and they generally do so quite well with the odd slip up (I'm looking in the direction of the debian-openssl screwup).
These days I tend to use a debian base system with Nix on top of it for when I need specific, repeatable or more recent versions of something.
Is there a policy that requires Debian package maintainers to seek mentorship of upstream when patching core packages?
I understand your point about maintained packages. But it's only a significant advantage if the maintainer's decisions must be filtered through the lens of the software maintainers. Otherwise one must trade the narrow expertise of the software maintainer for the wider expertise of the package maintainer.
That doesn't seem like a wise tradeoff IMO, and I don't see how a future openssl debacle could be prevented otherwise.
In 2006, a big security flaw was introduced into Debian's OpenSSL by the maintainer, because he changed code that he did not fully understand. The flaw wasn't discovered until 2008:
https://www.schneier.com/blog/archives/2008/05/random_number...
But we've got to remember that attitudes to security and understanding of subtleties around crypto code were very different a decade ago, the output from automated checking tools was trusted significantly more, and we're talking about OpenSSL, a project whose source is generally acknowledged to be full of Weird And Inadvisable Shit anyway. The example you're leaning on was basically a perfect storm that resulted in the worst possible scenario.
On the other hand, package maintainers fix security issues on versions of packages the developers have stopped caring about every day of the week, and of course these never hit the headlines.
And of course I'd never suggest that any package maintainer could ever know better than you. Though unfortunately such superior and unilateral attitudes are one of the things that maintainers are needed to protect against.
Their policy on language specific package management is also pretty reasonable. There's no point duplicating effort packaging things in both Pip and the Debian repos when those package managers work fine under Debian. It lets Python devs use the same tools as every other Python developer on other systems, and avoids Debian specific instructions for package installation. It also completely side steps the problem of following upstream for all of those packages.
The advice I've always followed is to always use the language specific package management unless I'm specifically building a package for Debian.
The author of xscreensaver became so upset by similar circumstances that he threw down a gauntlet; ship the ancient package with an updated splash screen warning users of how old it is, or stop shipping it.
https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop...
Then again JWZ is quite the character...
The maintainers never seem to push anything not security related, most of the changes being backports of fixes from upstream.
Obliviously the price of stability is that the system runs slightly old software versions, but together with containers this is not a problem anymore. Stable OS running cutting edge containers is a combo that works well for me.
The policy for debian stable is to only push security fixes.
The corollary is that they don't push new version for bug fixes or features.
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.
There was time where Ubuntu on desktop made sense, but now Debian is just better and more stable.
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...
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).
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.
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.
(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.)
This is the new stack:
Desktop/Laptop: Arch
Server: CentOS/Amazon
Small footprint: Alpine
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.
It's not unstable at all.
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.
"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.
AIUI installed packages get to run scripts with superuser privileges. This to me says "Danger Will Robinson!".
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.
* 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.
This says the stable package is still vulnerable:
https://security-tracker.debian.org/tracker/CVE-2018-1058
But Postgres doesn't show up here:
https://security-tracker.debian.org/tracker/status/release/s...
The 9.6.8 version indeed isn't on stable yet. So is the latter link just buggy? Or is Postgres getting filtered out?
Edit: Never mind, after messing with the filter (guess there's no Debian Security Advisory for this CVE), I was able to get Postgres in the second link:
https://security-tracker.debian.org/tracker/status/release/s...
In this case, however, the Postgres packager is also the Debian packager, so I decided to trust his direct upstream Debian packages and installed them. This is a rare exception, and I don't want to be doing this all the time.
I would love them to gain back more server marketshare.
I'm sure the maintainers would love to hear from you.
It is much lighter. I commonly find that Alpine images use at least 300MB less disk than Debian ones.
For comparison, I just found this blog post [1], claiming the following:
> According to the docker images command, the debian:jessie-slim container clocks in at 88MB, compared to the full-fat debian:jessie container at 123MB. For reference, the ubuntu:xenial and centos:7 base containers are 130MB and 193MB respectively, where as the alpine base container is only 4MB, as mentioned in my post about the alpine base container.
[1] https://elegantinfrastructure.com/containers/cotw-debian-jes...
Also besides disk space, I really have no idea how docker manages memory, but my assumption (naive?) is that smaller images will consume less RAM memory. I didn’t benchmark this though.
I've not looked at "naked" lxc for quite some time - but I've used Lxd on Ubuntu a bit, and that's a great experience.
If what you want is "containers" (single-purpose, ephemeral) - I'd say for now the docker tooling is best. But there's not much isolation - there lxc is better.
I've yet to try alternative "run times" like rkt - but I believe that's the better way forward compared to docker. For now we use docker mostly for packing up an application and managing dependencies - not for resource/security isolation.
I suggest reading over :
https://coreos.com/rkt/docs/latest/rkt-vs-other-projects.htm...
https://linuxcontainers.org/lxd/getting-started-cli/
If you are an lxd fan you probably want to move to Ubuntu or maybe even Ubuntu core.
If you're a developer and don't mind older packages, or if you install and manage your dev tools from outside the distribution, it can also work for you. This is a lot of people.
But if you rely on your distribution to provide reasonably up-to-date packages (and for better or worse, that's me right now), then Debian Stable might not be the right choice. When I do development in Linux, I tend to be more comfortable in Fedora, which is much more aggressive when it comes to updating packages during the life of a release. I'm not crazy about major upgrades every 6 months, though you can do it once a year if you wish.
For better or worse, I think that Ubuntu + PPAs is the path of least resistance -- if you trust the maintainers of your PPAs, that is.
Up until 8 it was still good for servers but 8 brought systemd, which maybe has a place on a Desktop, but is definitely not anything useful for servers. Ok, so lets pretend it is a desktop. Oh wait, it is a desktop that does not contain the lastest video drivers? It is a desktop that does not contain seamless switch between free nvidia and proprietary nvidia?
They seem to be released by a separate project / org called "debuerreotype"[1].
I just downloaded v9.3 DVD1/2 to make an offline installation.
Anyone know where the 9.4 upgrade iso is?
BTW, many moons ago I used Red Hat on Alphas, so I know it's not the only one. Still it's impressive.
The claimed advantages of systemd are mostly relevant, IMHO, for mobile devices that change configuration often. It brings no particular advantage to servers or desktops, unless you tend to swap out lots of peripherals on your desktop.
The disadvantages are partially political -- systemd tries to take over every job it can; the originator has made it clear that his vision is for every system function to be handled by systemd -- and partially philosophical: it used to be the case that most subsystems were independent of each other, so that they could be replaced more or less easily if the sysadmin had different needs.
The current stable Debian still makes it possible to run a different init system with just a line of package installation and a reboot.
Systemd provides huge advantages for administering desktops and servers as well. I'd actually go so far as to say those are the main reasons that systemd won (it's the default init system for all of the top ten Linux distributions by marketshare).
Can you list some of them?
Seeing the logs of every service is also trivial since it's standardized. No more spelunking through /var/log or some random location.
There's also other parts I'm probably forgetting right now, but in general having a standard interface for service interaction is really, really useful.
Sometimes I get the impression that Linux folks underestimate the benefits of standardization. For example there's still no good, standard way to check the exact name and version of a distribution. If they can't agree about something as banal as that... (I think there is a convergence towards /etc/os-release, but when was the first distro launched? 1992? :) )
Unless you expect anything but most trivial use cases, e.g. some user-owned directory under /var/run (/run). Then you need to wild-guess at what combination of options needs to be set. Good thing that those options are at least described in docs.
> Seeing the logs of every service is also trivial since it's standardized. No more spelunking through /var/log or some random location.
syslog already was standard. We gained nothing really from journald.
What do I type in my terminal?
And about that "quick" part, I'd rather have a way to do that that's either easy to recall or easy to re-develop. journald's magical incantations that don't compose to any consistent language (unlike Vim or Emacs keybindings, for instance) nor are the same as in virtually any other software are not convenient by any stretch. I have my memory cluttered enough by half a dozen of different languages I use, their runtimes, runtimes of languages I don't write in but need for some software I run, twice that of DSLs and specialized languages, options and functions of dozens of services, wire formats of network protocols, management procedures of various Linux subsystems, and so on. I don't need an option to a command to tell me what you ask, I can work my way through grep/sed/awk faster than you read man page, thank you very much.
The real question is:
> I have two service from totally different origins. What do I type in my terminal to see their logs, with syslog or other widely used init systems currently in use, except for systemd?
So? :)
At some point Unix will learn that in the wild opt-out is better than opt-in. When you make doing the right thing easy, everyone will do it. When you don’t, everyone does what they want, which is generally bad.
The fact that we have to ag or grep -R is a kludge. There’s NO technical reason the folder structure shouldn’t be flexible but standardized and also NO reason why there shouldn’t be some system scaffolding to help with that. Call it systemd or whateverd, it should be there.
But sensible defaults are important. Software design is important. Unix basically skirts the issue by throwing all these decisions in the user's lap. I can take these decisions, but I don't always want to have to do it. And there's many situations where you can't necessarily do it, either due to technical limitations, political limitations, budget constraints, etc.
In short, I'm glad systemd is winning. Sure, the average user loses a bit on the purity front but he gains a lot on the practical front.
* http://jdebp.eu./Softwares/nosh/guide/logging-cheatsheet.htm...
Well, this is my luck: /var/log/boot, written by bootlogd, which is installed from distribution packages on Debian. So? What of it?
lsb_release -a?
(lsb = Linux standard Base)
(It should be noted that while our company runs an awful lot of 1st party stuff, what our team works with is exclusively 3rd party stuff over which we have precisely no control)
I was initial skeptical about their benefit - after all, an init script is just shell, it can be debugged literally with `sh -x`.
But that also means a) people write/ship fucking terrible init scripts, mostly because b) it's not necessarily simple to write an init script in pure shell.
The problem with systemd is the politics and the project's approach to the community (including their self-defined role/goals).
But note that unit files along with their PID 1 cannot be debugged now. Which is a big step backwards.
Sure, I'll concede that. But, due to their nature, there's also less need for ops/packager level users to debug unit files.
* https://unix.stackexchange.com/questions/428615/
* https://unix.stackexchange.com/questions/428689/
* https://unix.stackexchange.com/questions/428474/
* https://unix.stackexchange.com/questions/427836/
* https://unix.stackexchange.com/questions/427806/
* https://unix.stackexchange.com/questions/427712/
* https://unix.stackexchange.com/questions/427710/
That's just one WWW site, just the ones that I encountered (because I do not read them all), and just since the beginning of this month.
* http://uselessd.darknedgy.net./ProSystemdAntiSystemd/
* http://blog.darknedgy.net/technology/2015/09/05/0/
* http://jdebp.eu./FGA/run-scripts-and-service-units-side-by-s...
I simply gave an example of how it's an improvement over e.g. sysvinit.
The Uselessd Guy has some rather sharp comments, such as "you’ve been living under a rock for years", for that sort of thing. Even the Debian Hoo-Hah involved analysis of four systems.
"The politics" that you critique include failures to look around and learn from (and indeed about) what already exists and has been done. Don't make the same mistake.
One person asked about advantages of systemd. I listed one, and acknowledged systemd has issues.
I didn't compare it to any specific init system. I didn't even claim that systemd is overall better or worse.
I literally said:
> Declarative system service configuration files are an advantage
Even though it is an old discussion (and will probably remain this way for a long time), the arguments are almost always purely technical and create a good picture of the pros and cons of systemd. As someone who migrated away from Linux before the systemd inception, I'm always learning a lot on "flame wars" like these. So thanks, I guess, and please keep the technical arguments coming :)
Edit: s/OP/parent/