Debian 10 “Buster” Released
debian.org
debian.org
Stability doesn't only mean "lack of (big) bugs", it also mean that it's dependable: it won't change under you, and what is inside is well understood (including limitations). This require using mature enough software. In any non-trivial piece of software novelty will brings exciting new features but also regressions in some cases. There's an inherent trade-off between freshness and stability in this sense.
Debian stable is made for stability in the full sense, like a Red Hat. If one prefers something more recent, but with more frequent changes, it's fine. Either use a distro with more frequent releases (e.g.: regular Ubuntu or Fedora) or even a rolling one like Arch, of Debian testing (sort of) or unstable. There's room for all of this, it's just different trade-offs.
Lastly, as I've said elsewhere it's possible to mix and match. One rarely needs the latest in all, and it's possible to use stable as a base to avoid problems, and add fresh versions on top for only the software one care about. With the various languages package managers and flatpack/snapd this is becoming very easy. For some it may be a better trade-off than moving to a rolling distro.
On an Ubuntu system, snaps works great as well.
So if you're running an "unstable" system, you get a new set of bugs each time you upgrade, and a new set of workarounds, and so on. Debian's stability means that, at the very least, you get to work around one set of bugs every two years or so.
It's not ideal, but a lot of people prefer it that way, and frankly, I understand where they're coming from. It is a trade-off, just like it's a trade-off to run distros with more frequent releases or a rolling-release distro.
This is why I prefer Archlinux’s package selection which is nicely in between new & stable. You get the latest packages but not the alpha/beta or broken RCs.
(Not to start a distro flame war, but it’s a reality of using Debian unstable is that it’s going to break often.)
[1] a while back the 2yr+ old Gnome 3 package in Debian was way uglier than a new redesign HiDPI/retina-friendly version around 3.10 I believe, but took 2 yrs to show up. Which was around the time Gnome was finally catching up to Apple in the basic attention to detail at the pixel level. Which makes Debian a non-starter for Linux desktop to me, but fine for lower security servers.
It does. It's not necessarily something that I consider a good approach in every way, I just understand it. I myself took it for a few years, during the Great Rush to Rewrite Everything between cca. 2012 and 2017. I used to run Gentoo (at home) and Arch (at work) up to that point but I temporarily moved over to Debian (which I hadn't used since 2007 or so) until the storm settled for a bit.
Yeah, it does mean that things that are broken tend to remain broken for two years, but you also don't need a set of new workarounds for two years. I very un-fondly remember that back in 2013 or so when I said no more, my machine was perpetually broken in some way.
(FWIW, I've been back on Arch on my main station for more than two years now, it's gonna be hard to start a flamewar with me by arguing about Arch's package selection :-) ).
I guess it depends a lot on everyone's usage patterns, too, there's a lot of diversity in this space, more than many younger FOSS developers (and UX designers!) realize. Some of the nastier things I do to my station are deeply rooted in my first days of running Unices almost twenty years ago, and while I do my best to make sure that not all old habits die hard, it can be hard to convince people to let go of the good ones.
(Of course, "good ones" is subjective, hence the flamewars. I guess 50% of my habits are good, I just don't know which 50%).
Doesn't help that some ""stable"" packages are outright broken and won't be fixed until the next release (ie. MinGW is stuck on a broken version of 8.3 which has a buttload of compiler bugs I keep hitting)
* I didn't notice anything out of place with the Wayland switch. I haven't tested suspend/resume/hibernate/external monitors yet though. Personally, I won't be using Wayland on my main machine once I update that as I'm a CWM user, and Wayland support probably isn't every going to happen for that.
* My user account wasn't added to the sudo group by default, and using `su` broke something with PATH (/sbin wasn't in PATH after running `su`).
* GNOME apparently does not support configuring multiple wifi adapters, which was a problem since I had intended to use a USB adapter to download the nonfree drivers for my internal adapter, but GNOME did not have a menu to configure them separately.
* The problems that GNOME 3.X has always had continue to be present -- chiefly the UI scale is too large on low-res screens (the machine I was testing with has a 1366x768 display), and graphics performance continues to disappoint (animations stutter very noticeably on the "search" screen for example, this was on a 2nd gen mobile i7).
* The much-touted software center seemed to have several polish issues. The first time I launched it it threw a bunch of inscrutable errors and didn't work until I re-booted the machine. It still threw inscrutable errors, but worked after this. Lists of software would take 60s+ to download (render? not sure what part was slowing it down).
From the perspective of a technical user, I don't care about any of these. They either affect software I don't use, or could be fixed easily enough. However, if the objective is to support non-technical users who don't have the knowledge/time/interest to troubleshoot, I feel that this release falls short.
For reference, the hardware used to test was a ThinkPad X220 with a 2nd gen i7, 12GB RAM, and an SSD.
The default profile for users (/etc/profile) hasn't included sbin paths for the entire time that I've used Debian, which always seemed a little weird to me, since there are definitely binaries in there that normal users can still use (e.g. lsmod).
I am unsure of why this is the default behavior, however.
https://salsa.debian.org/debian/util-linux/blob/debian/2.33....
It's certainly not a difficult problem to fix, I was simply commenting on the fact that it had to be fixed, which has not been the case on most other distros I have used.
How to report a bug: https://www.debian.org/Bugs/Reporting
There is an interface package, "reportbug", to assist in filing:
https://packages.debian.org/stretch/reportbug
And also debbugs for querying / working with the BTS:
I've been thinking about this myself, as I use a handful of programs which I am unwilling to give up but which Wayland will probably never properly support (intentionally; I'm fond of recording and playing back arbitrary input events, which Wayland has helpfully blocked for security reasons). My reading of the docs is that it's possible to run Wayland+xwayland as, effectively, a complete X server... well, it's not even a drop-in replacement, it's just an X server that happens to be implemented differently. So I think that if/when Xorg starts to become problematic to continue using, I can just swap it out for xwayland running in root window mode, and then run my X window manager and programs on top. Might need to mess with environment variables to mask Wayland so nothing tries to use it directly.
Anybody else have thoughts/plans on the future of X if Wayland really does take over?
I have been thinking about this for a few years at least (happy i3wm user).
I am looking at moving to Sway https://github.com/swaywm/sway (drop in replacement) at some point as it seems the development is really healthy. sircmpwn (Drew DeVault) has done a lot of really nice contribution to the FOSS community, in particular wlroots https://github.com/swaywm/wlroots I also thoroughly enjoy reading his blog https://drewdevault.com (articles from there often get posted here) there has been many a time I've read something he's written and thought "hear hear" in my mind.
It is also impacting my purchasing choices in regard to going for AMDGPU instead of NVIDIA for my next system that I plan to buy in a few months (mostly waiting for 3rd party Navi cards at this point).
Because drawbacks are huge (large number of apps would need to be customized and tiling managers would probably need to rewritten completely)
I don't use it and I don't have any issues with my current Linux desktop (using xmonad).
It looks like there's an effort to port it to Wayland https://github.com/waymonad/waymonad
The fact is X11 is being supported mostly by Fedora and they're going to stop using it too.
It is already in maintenance mode with no new releases scheduled. Eventually it will be completely unmaintained, probably around 2029 when RHEL8 support is dropped.
https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fed...
Muh security and muh pixel perfect frames.
But mainly, Red Hat is going all in on Wayland and has decided that X11 is deprecated. So if you want to develop applications for Linux that will be compatible going forward you will target Wayland and not X. (Realistically, the toolkits will use Wayland and not X and you will target those. Eventually GTK and Qt will drop X support altogether.)
I watch movies in VLC and I don't complain about pixels :)
(BTW. I don't care much about security of my desktop behind 2 routers and a NAT - yeah I know I'm still a target, but there are easier ones).
Wayland enthusiasts usually use "pixel-perfect frames" to mean lack of tearing -- what happens when the framebuffer is changed in the middle of the "electron beam's" scan down the display and you get half of one image and half of another. Eliminating tearing generally means forcing vsync, which means your framerate is capped at 60fps, and a few milliseconds of input latency are introduced -- meaning there's a bit of a tradeoff between the fastest desktop and the smoothest. (This is true regardless of display stack, whether Windows, Quartz, X or Wayland). Xorg drivers can often run in a "tear-free" mode, but Wayland blah blah modern architecture blah blah designed from the ground up blah blah. Plus, Nobody Ever Uses the X protocol anymore. (Basically, you don't have a choice -- Wayland compositors are required to force vsync and operate in tear-free mode.)
Security is, largely, a non-issue unless you run untrusted binaries all the time and/or open ports on your X server to random places that can then run random programs on your display. However, for the paranoid (and a little healthy paranoia is a good thing), it would be more involved but still not a whole lot of work[0] to modify the X server architecture to support a more Wayland-like security model by default, while still allowing trusted apps to do things like take screenshots and respond to global hotkeys.
The advantages of Wayland thus boil down to "it's what the community wants". And by "the community" I largely mean Red Hat and the GNOME Foundation. Basically, younger programmers who were weaned on Macs or Windows want a more Mac- or Windows-like experience than X, which offers a more Unix-workstation experience, provides. So they decided that the graphics stack needs to optimize for local applications running on a composited desktop with fancy effects -- not local and remote clients all drawing to one display. Plus it gives them the opportunity to do what every programmer longs to do -- a Great Rewrite From Scratch, using Modern Frameworks and Modern Techniques because the end result will be so much better and this never turns out badly.
But you're going to have to deal with Wayland regardless of whether it offers advantages to you, personally, again, because our benevolent lords at Red Hat have spoken on the matter and they say X is dead.
The question is "why write Wayland at all", and the answer is that re-inventing wheels is more fun than maintaining them and This Time We'll Get It Right™.
And then, after another decade or so, when enough corner cases have been dealt with that Wayland finally offers the usability of X circa 2009, a new bunch of kids will look at it and say "what's all the cruft in this codebase? Why all these messy corner cases? Let's start from scratch!"
And the Circle of Free Software will begin again.
I'm using nm-connection-editor and nmtui (depending on m mood) on my daily driver, and will probably continue to do so for the foreseeable future.
Though the Buster based raspbian will be available, they will continue using the LXDE version as Gnome is too heavy for the Pi.
I had tried Wayland for Pi3 earlier in my effort to get a smoother desktop experience on the Raspberry Pi[1], it was the smoothest desktop environment among other options but unusable due to XWayland apps crashing due to framebuffer issues.
I've settled for HW accelerated, Xfce4, Arch Linux (btrfs/zswap) on RPi3.
[1]: https://abishekmuthian.com/getting-smoother-desktop-experien...
It's not just Gnome that does that. There's an entire generation of designers that's cargo-culting mobile designs at the moment. Breeze, KDE's default theme, is equally space-wasting. They're great if you have a touch screen but it would be really cool if you could turn them off on systems without touch screens, i.e. about 99% of the current Linux installations I'm guessing :-).
If you're willing to fiddle around, there are a few good themes that don't waste so much space.
> about 99% of the current Linux installations
Not if you include Android!
How many Android installations running Gnome have you seen in the wild :-)?
Very different issues. They may have optimal spacing but their scaling is being handled incorrectly by the system, or they may have perfect scaling but suboptimal spacing. Or they're both good or they both suck.
It's best not to conflate the two.
However, I was under the impression that previous versions of Gnome supported non-integer scaling factors, which seems to be gone from current GTK versions(?). Just being able to set the scale to 0.5 or 0.75 would go a long way for people with lower res screens.
Even though I don't use Gnome myself, this still affects me, since many applications use GTK, and thus have massive Fisher Price buttons compared to other programs I use.
[1] https://www.gnome-look.org/p/1289376/
Furthermore the Nvidia driver and Gnome Shell work only at 40 Hz. The screen flickers noticeably at 60 Hz (Quadro K1000m). No problems on 16.04 with Gnome Flashback, which is GTK3 and Compiz. I didn't check 19.04 yet.
There is going to be a way as long it's based on CSS files on the file system. I definitely don't want the default theme, I prefer scrollbars and other things my way.
Developers of Linux apps should accept they have difficult users. I'll buy a Mac when I'll settle for UIs I don't like.
The point of this "first impressions" exercise was to explore the happy path.
> It's not just Gnome that does that. There's an entire generation of designers that's cargo-culting mobile designs at the moment. Breeze, KDE's default theme, is equally space-wasting.
I would agree with that sentiment, though I didn't want to get into that flame war today. I think a lot of other people have already written extensively on this subject and I don't feel I can contribute anything new. Here are some relevant articles...
Several of these are about CSDs, which I think are a big point of contention with respect to the design philosophy of GTK/Gnome 3.X. This list does not include much about the KDE/Qt side, which I'm less familiar with.
I would certainly like to expand the side of this list on the "Pro Gnome" side in the interest of a more fair and balanced debate.
Pro Gnome 3.x:
Client-Side Decorations Initiative - https://wiki.gnome.org/Initiatives/CSD
Restyling apps at scale - https://blogs.gnome.org/tbernard/2018/10/15/restyling-apps-a...
Introducing the CSD Initiative - https://blogs.gnome.org/tbernard/2018/01/26/csd-initiative/
Against Gnome 3.x:
Why do we keep building rotten foundations? - https://davmac.wordpress.com/2016/07/05/why-do-we-keep-build...
GNOME (et al): Rotting In Threes - https://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotti...
Torvalds on Gnome - https://web.archive.org/web/20190313090648/https://plus.goog...
Sway and client side decorations - https://drewdevault.com/2018/01/27/Sway-and-client-side-deco...
Server side decorations and Wayland - https://blog.martin-graesslin.com/blog/2018/01/server-side-d...
The problem with GNOME 3 - https://felipec.wordpress.com/2013/06/12/the-problem-with-gn...
It's been like this since day one; people started to expect a different behavior after Ubuntu became popular, but Debian is consistent in this regard. Adding an account to the sudo/wheel group should be a conscious decision on the part of the administrator as it has major security implications.
* UEFI Secure Boot support
* AppArmor now installed by default, with profiles for various programs
* APT can optionally be sandboxed with seccomp-bpf (but not yet enabled by default)
* nftables replaces iptables as the network filter
* GNOME/Wayland by default
[1] https://www.debian.org/releases/buster/amd64/release-notes/c...
There's a lot of negative PR and not much evidence of why people shouldn't use it. Comes across as like the same recommendations of "don't use chrome, use this fork instead", one that's run by a tiny team of people who face very little consequences for messing up.
Many of those posts have been met with ignorance from the developers, even resorting to "it's not a bug" when it clearly is. Systemd has been pushed into distros based on improvement of boot times (their PR), not as a basis of a stable replacement of an init system. There were no problems of existing init systems to resolve, and SSD's have made the boot times pointless. My fully-loaded Devuan install boots 3 seconds quicker than Mint, Solus or Fedora.
Genuine outstanding issues highlighted in the forums are things like not being able to get unit files to start services at boot up, difficulty in finding start up errors due to the order of other services starting, errors not showing up in logs and untraceable boot delays. These are not made up, just take a look at forum threads tagged with systemd.
It has also become much more than an init system. This has resulted in bigger dependency issues, in turn resulting in not being able to install some applications purely because of a dependency on systemd somewhere down the chain. On non-systemd distros applications don't care which init system you use.
It's not negative PR, it's real users having real issues that have had something pushed on to them. For systemd's original portrayed purpose there is no reason devs couldn't have spent their time creating configuration utilities for the existing inits. At least when something breaks on the established ones, there is only an init system to look at.
"Systemd also provides a number of other executables (systemd-udevd, systemd-logind, systemd-resolved, systemd-networkd, systemd-tmpfiles, systemd-localed, systemd-machined, systemd-nspawn, etc.), libraries (libsystemd, libudev), a PAM module (pam_systemd.so) and a UEFI boot manager (systemd-boot), among other components. So any other package that needs any of these components, even if it is just one, would pull in THE WHOLE SYSTEMD PACKAGE as a dependency."
* build system actively makes it difficult to build one component without the others, seemingly for political rather than technical reasons
* build system relies on Python, making bootstrapping more difficult (not quite desirable for "building blocks to build an OS from")
* needless overlap with countless other pre-existing projects including binfmt-support, lxc/runc, and libdbus
* cgroups2 hierarchy model which is unworkable for rootless containers unless they register with systemd via dbus or are running directly as systemd services
* The dependency model has lots of corner cases and gotchas. OpenRC and the LSB headers are much simpler and just as effective.
* Events are done in a hacky way: device events are performed by tucking "SYSTEMD_WANTS=..." away in a udev rule somewhere, IPC and timer events have their own unit types. This model is not extensible, and it obscures the policy rules that can be used to start a particular service.
* All the positive PR and marketing has left a bad taste in my mouth. Why did RedHat fly Lennart across the world dozens of times just to sell this hunk of C to literally anybody that would listen? It was a waste of petrol and shows that systemd did not win on merits alone.
* does not make any attempts at portability, and does not follow any pre-existing standardized interfaces that can be easily emulated on other OSs.
* Reliant on dbus as its primary IPC mechanism, when it does not even need a bus in the first place. JSON over a socket could have been a simpler and cleaner choice.
I hear you that ubuntu is the most common docker base image and laptop linux OS but debian's big decisions are all based on redhat, afaict.
Therefore, it is the expected result that Debian should follow the upstream Gnome into using Wayland.
Hell, RHEL even dropped KDE support entirely in version 8.
I'm not saying change is inherently bad, but I'm amazed how much change is caused by a single project.
[1] https://lists.debian.org/debian-devel/2013/10/msg00578.html
If only there were some sort of (M) Advanced Traditional Environment they could default to instead..
disclaimer: i probably haven't given any recent gnome version a fair shot
You may be waiting a very long time.
Does NVIDIAs driver has any special code to make i3 work on X11 but missing code to make sway work on Wayland?
For Wayland, nVidia only implements the EGLStreams buffer management API, whereas other drivers implement the GBM API. Individual compositors (like sway) need to add support for EGLStreams.
See also https://wiki.archlinux.org/index.php/Wayland#Requirements
Personally I avoid NVIDIA like the plague, but at work we have to support VMware running with 3d acceleration on all kinds of cards on Linux, including NVIDIA with proprietary drivers. Apart from VMware having announced no plans yet on supporting Wayland this seems like yet another small reason to stay with X11 until the end of time.
what technical justifications are you using to make this claim?
[0] https://github.com/swaywm/wlroots/wiki/Projects-which-use-wl...
I think starting fresh from a Weston or wlroots base is the only way we’re going to get decent desktop environments. GNOME and KDE are “translating” the X11 stuff over to Wayland methodology, but that’s not going very quickly.
It’s great that Debian is leaving the old X11 within arms reach. This is a very pragmatic way of pushing Wayland a bit while not screwing over the users.
GNOME now defaults to Wayland and the other desktops default to X, Debian has no reason to second-guess them. Worse, changing the defaults in this area would be a fork in all but name.
On servers I prefer Debian stable though. I like my mail server running unattended with only security upgrades, and rolling-release distros tend to introduce config-breaking changes exactly when I have the least time to deal with them.
Testing is usually only a few weeks behind unstable though, so if your primary motivation is to have relatively recent software and a rolling release so that you never have to stop everything and deal with full system upgrade breakages, then testing is great.
It's possible that you can do it yourself on Debian (maybe look into https://packages.debian.org/stable/kernel/kpatch), but it was a bit labor intensive, last time I checked, as you have to manually select patches to apply.
...unless you want a fully functioning desktop machine.
You only have to look at the effort put in by the MX Linux team to keep the shim functioning to realise a non-server Debian system without systemd is a headache for a ordinary user.
If I'm deploying node to a server the first thing I do is set the system up to use nodesource's repos.
I hope this next dist upgrade goes much quicker, due to the automations we've built (config management with Ansible, Continuous Delivery).
Pip is not some random third-party library, it's part of the official installation that you can get from python.org.
Looks like Armbian Buster is alread out: https://www.armbian.com/tinkerboard/
Keep an eye on the temp though - seems to run hot. I managed to get mine to behave without a fan by adding significant thermal mass. (~pound of copper)
From a practical standpoint, m68k is old to the point that it doesn't seem practical to run any kind of modern Linux system on it anymore. The last new processor in the family (the 68060) was released in 1994, and ran at 75 MHz.
Scratch that.
How do you find that without knowing exactly where it is already? What do you click on? Where is it on the page? What and how much do you have to ignore before you finally get to the part at every stage that's actually relevant to the breadcrumb trail?
[edit] The "click Get Debian" responses are absolutely killing me. OH YES AND THEN WHAT? How many paragraphs of jargon do you have to casually slide past? How many links do you have to _not_ click? How do you know which links to actually click vs all the ones that you're supposed to not click? The definition of "free"? The "installation manual"? Will the small image be incomplete? What's the difference between a small CD and a tiny CD? What's the difference between a USB stick and a "flexible" USB stick? Can't I put a DVD on a USB stick? I swear this kind of UX aspect blindness is why people hate SWEs.
From there you have roughly 5 options:
1) small installer that gets packages over the internet (netinst)
2) large installer that includes a bunch of packages ("CDs")
3) same as 2 but delivered to you physically
4) qcow2 cloud images
5) a live CD + installer
6) a computer with debian preinstalled
netinst is recommended if you can have a network interface that is supported out of the box.
Ubuntu's installation would be equivalent to 5) and is the friendliest UX.
You are expected to know which architecture you are using although branding makes it really hard for new users to figure that out.
>(x64 testing + non-free firmware)
why testing?
The installation images may be downloaded right now via bittorrent (the recommended method), jigdo, or HTTP; see Debian on CDs for further information.
So in order to use your link, first you need to be lucky or wired (because that download doesn't include the wifi firmware that most people will need for the install), and then you need to either already know where not to go or spend time digging around and backtracking.
I think the OP is right that the Debian homepage could probably do with some simplification - there’s nothing wrong with having all these options available, but most people are just going to want a CD image they can write to a USB stick these days.
2.4.1. CD-ROM/DVD-ROM/BD-ROM
2.4.2. USB Memory Stick
2.4.3. Network
2.4.4. Hard Disk
2.4.5. Un*x or GNU system
2.4.6. Supported Storage Systems
I am going to burn a CD-ROM and/or DVD-ROM. It's been a while and feels very retro, I guess I could do this. What is a a BD-ROM?
I am going to use dd to copy the image onto a USB Memory Stick. I've done that.
I am going to do a Network install, no I am not going to do this.
Hard Disk install, this is how I installed it previously. Let me find my notes.
Whether it's CD-ROM, DVD-ROM, USB Memory Stick, or Hard Disk install, the tricky bit is getting the computer to boot the image from that media. And, the tricky part about this is knowing the incantation for GRUB to do this. And, the additional tricky part is the mangled PC EUFI/Secure boot settings. If it's the raspberry pi it's easy: I stick the USB Memory stick in the pi and go. If it's the PC, it's well, as you said: forensics.
I wish that I could download a little install program, and install a fresh OS into one of the many free partitions on the PC, and that the installer would automatically configure GRUB to recognize that new OS without the incantations, and without stomping on other distros.
But I will say:
> I am going to do a Network install, no I am not going to do this.
For Debian netinst really is the best. Debian has a lot of packages. I haven't kept up with all the full media over the years [first time I did a debian install was '99 or so], but it's always seemed pretty "completist", and contains more than I'll ever use. With netinst you get a base system, it gets you to a shell quickly and you can apt-get exactly what you need without a lot else.
A Bondage and Domination video on a plastic disk?
http://cdimage.debian.org/cdimage/unofficial/non-free/cd-inc...
Is it possible that desktop should be developed in other manner than server?
I don't blame them though, one of the maintainers was supporting like, 3000 packages? I don't recall the exact number, but it was an impossible amount of work for a single individual. This strongly implies there was zero QA for these packages (an he really was doing it himself, it was not a front for an organization.)
My experience with Debian, Red Hat, etc. is to ignore packages for basically anything I care about for both Development and Production. It's likely to be the wrong version of what I need and quite possible for it to have distribution specific issues and quirks. E.g. for OpenJDK I would never put Debian provided packages in production and instead use a package from one of the several licensees of the testsuite (Amazon Coretto, Azul, etc.). I have actually run into issues with e.g. certificates, premature releases of non released versions of the jdk, etc. Much better to use Docker and CI test the entire container before it goes near production with exactly those dependencies that I tested and hand picked. Even Docker itself I prefer to get straight from the source when I build AMIs in Amazon (using packer). Most things I use are well supported with packages by their developers.
https://docs.fedoraproject.org/en-US/modularity/using-module...
First of all, modules can not be installed in parallel [1].
Secondly, it is not a new technological development at all. Modules in essence are just a fancy version of maintaining multiple overlay repositories on top of your base distribution. Only difference is it adds a more streamlined usage to dnf. You could do the same thing 15 years ago with yum or apt by manually enabling/disabling repositories.
This is the easy part.
Real hard work that goes to modules is actually creating and maintaining those separate modules having separate versions of the same software stack. And that is the thing none of the distributions were willing to do until recently. Heck, maintaining multiple versions of the same library or the same program in a distribution release was a taboo. Distribution developers dreaded the idea of doing that and avoided it as possible as they can.
Jury is still out on how well it'll work in practice and how much useful it'll be (in that will maintainers be actually eager to do the hard work of maintaining multiple stacks in parallel, how long will they support each version or how many versions will they maintain in parallel etc.)
I have the best wishes Fedora developers with the modules idea and I hope it'll prove to be successful thus maybe other distributions would be more open to the idea in the future.
[1] > Modularity brings parallel availability, not parallel installability. Only one stream of a given module can be enabled on a system https://docs.fedoraproject.org/en-US/modularity/architecture...
For PostgreSQL in particular, the Debian / pgdg packages support concurrent installation of multiple versions https://wiki.postgresql.org/wiki/Apt
Do not drink the stability cool-aid, its 98% poisonous nonsense.
Perhaps this is different on non-linux platforms, but if you find yourself there you have far greater problems than 'stability'.
Let me remind you that binary distros emerged for convenience and speed – you dont need to compile bunch of stuff when internet and computing power was limited, e.g. new version of gimp (or mpv) with feature you really waited and wanted.
I have never (never!) encountered security problems, and sudden config changes in most updates (lates major versions of KDE are exceptions) and this is not a problem at all on my desktop machine.
Problem is when can't intsall new version wihout learning new often sophisticate upgrade procedures or even compiling/building (let me remind you it's 2019 today).
Debian is not universal, it's a server distro with desktop packages appeared in repos by as a result of some mistake.
How can I know which packages and which versions will be incompatible upgrades beforehand? How can I rely on distribution maintainers to know and warn me against incompatibilities with any kind of customization or 3rd party integration I've had outside of the distribution. Why should I spend time before and after every upgrade to assess something won't/isn't broken.
> Why other should suffer?
They shouldn't. Dozens of other distributions with different release policies are available and well supported.
> I have never (never!) encountered security problems, and sudden config changes in most updates (lates major versions of KDE are exceptions) and this is not a problem at all on my desktop machine.
You can't say that as the very first example you've given in your above post, Firefox, has been notorious with the breakages for the better part of the last decade; with every single new release either breaking extensions, removing features that users have relied on, introducing anti-features that required disabling or any combination of these.
> Debian is not universal, it's a server distro with desktop packages appeared in repos by as a result of some mistake.
You must hurry tell that to Debian developers so they can stop wasting their time packaging thousands of desktop programs, then.
I guess you also never encountered a red-bellied black snake. That doesn't mean it's not a problem for the 25,000,000 people who share an island with it.
Good for you, but don't presume your use cases and requirements are the only valid ones.
I'm sorry, but what is stopping you or other people from using distros with faster release cycle or rolling release?
If anything, there are so many rolling release distros nowadays, that Debian Stable is a breath of fresh air in the sea of release first, fix later mentality (especially when it comes to desktop environment).
But I digress, in the end just choose the distro that suits your needs and requirements and be happy.
Amazing example of why linux desktop goes wrong direction is so many distros. When you have many answers – you don't have answer.
Ubuntu studio for artists, Kubuntu for those who like KDE, Debian for thos who don't like updates (._.), gentoo, etc etc.
Why on windows and mac user can compile, and update anything? Just install photoshop (or newer version of gimp that available for majority of users on windows earlier than on linux before snap/appimage) and you get "distro" for artists.
And even snaps/appimages go wrong direction and overthink problem with security and sandboxing — when majority of users just need one runtime to deal with, like in SteamClient.
No one wants download or plug special repo/package for debian or fedora — this is amazing resource waisting! (insane even)
1. Things depend on one another. Keeping the base system stable while iterating everything else more quickly can end up being infeasible because it's turtles all the way down. Application X wants a newer CMake to build, which wants a newer something else, which wants yet another newer version of something, and then your base system changes underneath you.
2. I really, really love to “fire and forget” a Debian installation for a few years. I've got elderly family members on Linux that are really sensitive to changes in the UI. Things being not changing for years rather than months or weeks is a blessing.
If the only thing keeping me cognitively engaged in old age will be UI changes, I might as well die.
You're right - that's why macos definitely hasn't spawned suspiciously debian-like package managers in an attempt to handle all these problems.
And if we're talking about "app bundles", if you dig a bit deeper you'll find most of these applications which "just work" just bundle all of their dependency libs. God knows if they bother to update them or do a security release if vulnerabilities are found in their bundled libs!
Mother of God! Very popular argument. No one cares (in terms of architecture).
> vulnerabilities are found in their bundled libs!
Yes, god only knows how entire install base of mac and windows machines works today (this problem is not as big as you try to present here).
Your arguments like debate about linux monolithic and minix micro kernel architecture. Minix is more advanced in theory, linux (not linux desktop) working in reality.
The issue being that, for a lot of people, they often work a little too well.
If you're going to follow the philosophy that caring about the correctness, lack of duplication and security of an installed application is too esoteric to be relevant, I'll remind you that you're entirely free to do that to any extent you like with linux. Equally people like me are free to tell people who do that that they will receive no support from me for such a setup.
Disclaimer: I'm a Debian developer.
In my experience, the "here be dragons" description of testing/unstable is way overstated... they're both very reliable. If you install apt-listbugs and `apt-mark hold` anything with bugs that sound scary, you'll be fine.
It seems like a lot of people try Debian stable (perhaps thinking of it as an upgrade path from Ubuntu), are surprised by the ancient software packages, and then look elsewhere. Debian might want to consider changing the recommendations they make for new users. Instead of stable / testing / unstable, they could be server / workstation / testing.
> Instead of stable / testing / unstable, they could be server / workstation / testing.
I would love to see something like that, but I think it would need significant changes to Testing to make it usable for the masses. Some years ago there was some work towards that direction with Constantly Usable Testing, which explains some of the challenges: https://old.lwn.net/Articles/406301/
Debian is great in general but the wonkyness surrounding the freeze period gave me the impression that Debian Testing really is something that should only be used if you are interested in helping Debian produce the next Debian Stable release. Some packages don't get timely updates and are only updated close to the freeze period, in preparation for the next stable release. And during the freeze period itself everything is super awkward because preparing the next stable release takes priority over keeping Debian Testing usable.
My own experience is that things can be broken for months in testing and of course good luck finding any help when that happens. For example, since the freeze for Buster I had broken sound drivers for a couple of months until someone else found that it wasn't actually the drivers but another broken package that as of a month or so ago still wasn't fixed (but the problem had been reported)
That's been my experience with testing for the last 3-4 Debian releases: it works great... except for a handful of annoying bugs that seem to linger almost until release. And assuming you know exactly which package is broken (which can be difficult to narrow down for driver/system level issues), you may or may not get the problem addressed in a timely manner. Then there's also the case of the occasional package that you depend on that disappears from testing for a month or two for any number of reasons.
I had the _exact_ same problem (the issue ended up be a MIDI program called timidity). The main problem for me was that Debian doesn't give any advice on how to report such issues (the website is firmly planted in the early 90s), and the mailing lists I found all appear to be dead. I wish Debian had a slightly more modern website.
What other options do I have if my criteria are:
- rolling release
- not Arch
As far as I can tell, Debian testing is still the least headachy way to get a rolling release, with the added bonus of out-of-the-box compatibility with most of the "we support Linux!" software that only ever gets tested on Ubuntu.
During my ten years (five release cycles) of using Debian testing, there hasn't been an update that required get-out-the-recovery-disk levels of surgery to fix. All of them have been minor user-facing software bugs or package version inconsistencies that could be safely ignored until I had the time or the inclination to investigate. But yes, you do have to be willing to poke around a bit, and not everybody likes that.
But this is why I wanted a rolling release in the first place. I prefer to do minor repair work on a regular basis (but on my own schedule) in order to avoid major repair work every 6-24 months (on somebody else's schedule).
I also don't really mind the investigative work when something goes wrong, since it forces me to learn more about how my system works, and that knowledge invariably ends up being useful later. Some people absolutely hate this, and they would probably be better off using something else.
Like all rolling distros, it's best to be a bit technically savvy and know your way around the distro to handle those glitches. That's the big interest of stable: no bad surprise. Stability is not just lack of bugs, it's also lack of changes with the unavoidable little regressions here and there. There's room for both stable and current, but it's different and criticizing stable because it's stale misses the point IMHO.
Anyway, I agree with you that testing (and rolling distributions in general) are probably not a good idea for newcomers. For those who like to roll their sleeves and dig in once in a while, and like to learn, then fine.
Also, people usually don't need the latest in all. So stable with a few select up to date packages is usually a very good compromise. Just get the latest for what you really care about, and for the rest the no worry but slightly old is just fine. With flatpack/snapd and each language package manager this mix and match is really easy to do and probably a better trade-off than a rolling distro for many people (but not all, so just use what's best for you).
If the intention is to be on rolling-release, you might as well just use sid. If you'd rather just be on rolling-release until the stable release is carved out (new features desired, for example), testing is pretty fine since it will transition into being the stable release.
That said, Fedora is a fine alternative.
I mean, the entire point of Debian is that all of the packages are stable.
If you don't want stable, don't use Debian. Don't knock Debian for working as intended.
I love Debian and I'll always recommend it for servers, and it makes a reasonable desktop too. However, it's not right for everyone.
Ubuntu/Debian has been my primary Desktop/Server for the last 15 years, life is good with them. Thanks so much for the maintainers and contributors to put so much efforts into them.
Not true, Canonical doing business too.
Leaved Debian/Ubuntu ~5 years ago and never looked back.
Take CentOS for example... No 3rd party repos are required to run the system, but everywhere I've seen CentOS used in production they've installed packages from EPEL.
More about the difference between Debian releases: https://www.debian.org/releases/