
Debian 9.4 released - merraksh
https://www.debian.org/News/2018/20180310
======
hyper_reality
The fact that the vast majority of these bugfixes and CVEs are minor is a
testament to the continuing stability and quality of Debian and its ecosystem.
I've run Debian on several machines for years and have upgraded confidently
without a hitch. A big thank you to the maintainers and developers for making
this possible.

~~~
krutzger
Debian is like Arch but the opposite

~~~
dmix
Arch is very stable when using mainline packages, which are the default
packages...

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.

~~~
anonacct37
> 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.

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?

~~~
dmix
Well, how did git "break" exactly?

~~~
krutzger
Edit: I've been told this meme is pretty accurate
[https://i.redd.it/jo3ylah5yti01.png](https://i.redd.it/jo3ylah5yti01.png)

------
teddyh
Please note: Starting with Debian 7, the minor number is not part of the
Debian release number, and numbers with a minor component like 8.7 or 9.4 now
indicate a _point_ release. Basically, only security updates and major bug
fixes, with new updated installation media images. This, 9.4, is _not_ a new
major release of Debian.

------
mariusmg
Thumbs up for Debian, the workhorse of the entire Linux ecosystem.

------
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.

~~~
shp0ngle
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.

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

~~~
tetraodonpuffer
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...

------
jordigh
Can someone explain this to me? I've had an issue with Postgres on Debian
stable because Postgres had to address a CVE which changed its dump format in
a backwards-incompatible way. This meant that my local Debian on my laptop
couldn't load a dump I created on a patched Ubuntu server. Postgres 9.6.8 is
the one that fixes this CVE in the 9.6 series.

This says the stable package is still vulnerable:

[https://security-tracker.debian.org/tracker/CVE-2018-1058](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...](https://security-
tracker.debian.org/tracker/status/release/stable)

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...](https://security-
tracker.debian.org/tracker/status/release/stable?filter=1&filter=unassigned_urgency&filter=nodsa)

~~~
eikenberry
On that later page, if you check "￼include issues tagged <no-dsa>" that
Postgres issue shows up.

~~~
jordigh
So this has taught me something I didn't know about all Debian: not all CVEs
have the same priority or have to be fixed in point releases. Many CVEs don't
even get acknowledged by a Debian Security Advisory at all. I guess if I want
security to be the utmost priority, I should be using OpenBSD.

~~~
anarazel
In this case you probably should just be using postgres' apt repository,
which'll carry new releases very promptly.

~~~
jordigh
Kind of the point for me of using Debian is to not have to go shopping around
all of the web for packages and because I want to have a uniform packaging
standard: Debian Policy. That's why I don't trust anyone but Debian to produce
Debian packages. It's a lot of hard work to make sure all packages adhere to a
common standard, a standard that upstream distributors will not follow.

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.

------
ergo14
How is debian nowdays for setting up things like containers? I've tried lxc in
the past few years ago and got it working but it was not a pleasant
experience, templates were broken.

I would love them to gain back more server marketshare.

~~~
juanmirocks
I use for nearly all my docker containers the distro Alpine Linux.

It is much lighter. I commonly find that Alpine images use at least 300MB less
disk than Debian ones.

~~~
oweiler
For containers I'd suggest using Debian slim.

~~~
juanmirocks
Interesting, I didn't know about Debian slim.

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...](https://elegantinfrastructure.com/containers/cotw-debian-jessie-slim/)

~~~
amenod
This is always a dilemma for me... Alpine allows for really small packages,
but I never got used to its packaging tools (and I don't feel confident
writing Dockerfiles with it). A matter of practice I guess. Besides, Docker
caches layers so if you're using some common base layer (like Ubuntu or
Debian) it's probably already on the machine. So I usually write Dockerfiles
as `FROM debian` and then later adapt them to Alpine if they're meant to be
distributed.

~~~
juanmirocks
Yes, I did like you before. But once I got used to Alpine, apk (its package
manager), and ash (its shell), I feel myself at home. Furthermore, in most
occasions I find newer updated software on Alpine vs. Debian.

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.

~~~
amenod
Sorry for late reply. Depends on what is in the package. Docker is just a thin
separation of processes, so the situation is very similar to size of packages
on host Linux OS. What matters is the size of binaries and loaded data, which
I guess is not that different between distributions.

------
passthejoe
Depending on your use case, Debian Stable can be a great thing. If it worked
great on a given computer (i.e. everything works), and I was just writing or
using programs that were themselves fairly "stable," then it will work.

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.

------
notyourday
Frankly, I do not understand the fawning over Debian. It became the same kind
of "try to be everything and do nothing well" distribution Slackware was.

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?

------
facorreia
I'm a bit surprised that the Docker image is not released as part of the same
release process.

They seem to be released by a separate project / org called
"debuerreotype"[1].

[1]
[https://github.com/debuerreotype/debuerreotype](https://github.com/debuerreotype/debuerreotype)

------
keithpeter
Debian servers and mirrors still showing 9.3 (UK, 17:45 Saturday 10th March)

I just downloaded v9.3 DVD1/2 to make an offline installation.

Anyone know where the 9.4 upgrade iso is?

------
squarefoot
Obligatory reference to the list of platforms Debian has been ported to and
the "blends" it can be customized to.
[https://www.debian.org/ports/index.en.html](https://www.debian.org/ports/index.en.html)
[https://www.debian.org/blends/](https://www.debian.org/blends/)

BTW, many moons ago I used Red Hat on Alphas, so I know it's not the only one.
Still it's impressive.

------
fosco
I realize the decision is said and done but can anyone share in easy to
understand terms what the big deal is with systemd?

~~~
dsr_
Systemd is an init system that tries to do everything: system init, hardware
monitoring to load drivers on demand, configure networking, rerun failed jobs,
service management, and it comes with a binary-format logger.

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.

~~~
chimeracoder
> 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.

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).

~~~
gsaga
>Systemd provides huge advantages for administering desktops and servers as
well

Can you list some of them?

~~~
oblio
Creating unit files is trivial and you're sure that you're getting high
quality service supervision, unlike with home grown scripts.

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? :) )

~~~
dozzie
> Creating unit files is trivial [...]

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.

~~~
vbernat
Many services don't log to syslog. For example, on Debian derivatives,
/etc/init.d/networking was logging to the console only. Good luck to get the
output once the system has booted. With systemd/journald, you get the info.

~~~
dozzie
> For example, on Debian derivatives, /etc/init.d/networking was logging to
> the console only. Good luck to get the output once the system has booted.

Well, this is my luck: /var/log/boot, written by bootlogd, which is installed
from distribution packages on Debian. So? What of it?

