I doubt it; they already maintain patchsets for a lot of their packages, and one to change what gnome defaults to would be trivial. This was a deliberate move.
You can only see it as a “move” if you consider Debian to be a single reasoning entity. But consider: the person making such a patchset would be the Gnome maintainers, and they would not really have an incentive to do so; Gnome upstream probably changed the default for a reason, and the maintainers of the Debian Gnome package, being voluntary maintainers, probably are philosophically aligned with Gnome upstream. The rest of Debian, like the package maintainer who chooses what Desktop Environment should be the default, can not make such a change to the Gnome package without a quite adversarial process involving the Technical Committee, and in practice this process is rarely used, and even when used, rarely successful.
Therefore, it is the expected result that Debian should follow the upstream Gnome into using Wayland.
I'm honestly astounded by how much fallout is generated by GNOME alone: GNOME strongly integrating with systemd pushing systemd itself[1] onto major distributions, now GNOME forcing 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.
GNOME is not even that good even, not from a programming perspective (glib/gobject/gtk hell) nor from a usability perspective (features being removed left and right, high memory usage, etc). I personally think that tiling WMs do it way better, but even things like openbox and KDE are just more usable than GNOME. I am surprised that it is still the default in so many distros, something related to tradition i presume?
Maybe sircmpwn could comment on this: Could wlroots (originally for Sway) make the transition process easier for other tiling window mangers wanting to port to Wayland?
Wait. So I haven't used Wayland at all yet but why would the graphics driver need to have support for a tiling WM? isn't that in a whole different later and shouldn't matter at all?
Does NVIDIAs driver has any special code to make i3 work on X11 but missing code to make sway work on Wayland?
It’s the other way around: on X11, nVidia implements all the standard APIs, so window managers like i3 don’t need driver-specific code.
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.
Oh dear, so right from the start there is unnecessary complication hindering adoption of Wayland in yet another way. After reading your comment I assumed at least all the other drivers would implement EGLStreams too but following your link reveals no, so you couldn't even implement a simple compositor that only supports one.
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.
Note that Wayland doesn't have a full driver abstraction layer in userland like X does. Every Wayland compositior is expected to call into the Linux kernel drivers for the graphics card directly. GBM is just a thin wrapper that hides the fact that Linux never standardised the buffer creation interface across different hardware - it assumes that all those driver-specific interfaces wrap essentially the same shared Linux buffer management code, and it doesn't abstract stuff like modesetting at all. NVidia managed to reimplement enough of the Linux modesetting interface that existing code mostly works, but their own buffer management infrastructure is apparently different enough that they couldn't make it look like the one existing Wayland compositors are expecting to use. So they ended up creating their own slightly higher-level API instead.
That’s probably not a bad thing. We have the benefit of hindsight of decades of GUI management and it probably isn’t more than a weekend project to get a baseline library worked out to build cool things (like awesomewm and i3 and dwm) off of. Which probably already exists.
Xmonad[1] cannot be ported, but there is a Waymonad[2]. So yes, in most cases that would mean rewriting from scratch. What is worst of all this - no existing plugins/extensions/etc would work...
Yeah, aside from GNOME/KDE trying to do a smooth transition, it's kind of a breaking point for everything. We now have Sway as an i3 successor, for example. There are similar projects for other popular window managers, but from what I understand none of them are in a very usable state the way Sway is. This[0] page can serve as an informal list of all the Wayland compositors succeeding old window managers. Waybox is likely relevant to your interests.
It’s still not ready, especially the KDE and GNOME situations. Things just aren’t very reliable. Mouse events are dropped and things like menus respond inconsistently. The XWayland layer doesn’t work smoothly, so X11 games and browsers aren’t very performant. Without that, there’s no transition layer, so it’s a cold-turkey jump to Wayland applications, of which there aren’t many.
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.
I don't think you'll have much luck with Weston, it's not really designed to be used as a base (libweston is tacked on and the devs acknowledge that it's not great).
If I'm reading the announcement right, it's the default for GNOME alone, which makes sense:
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.
As a random sidenote, I find it very interesting that Wayland has pretty much all the same architectural decisions as Mac OS X 18 years later. Convergent evolution. It seems in general like the Linux world is a bit more stubborn to change.
Hasn't been for a while. The last release to include official m68k support was 4.0 (etch).
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.
It's "there", it's just not official anymore. AFAICT, Debian has no such thing as different "tiers" for official ports, everything official is at "tier 1" at least wrt. official support (LTS is not wholly 'official' and may skip some architectures).
I used to run Debian, but I switched to Fedora a few years ago and haven't looked back. Fedora is always sleek and up-to-date, unlike Debian, which due to its outdated packages always ends up looking like the plain step-sister. I also strongly prefer DNF to apt. With that being said, they both play crucial roles in the Linux ecosystem - Debian being the base for Ubuntu and Mint, and Fedora being the distribution which upstreams the most code.
Running Debian testing is generally the practice I recommend on systems which are single-user, like desktops and laptops. It's quite stable and very up to date, except for a couple of months in the run-up to freeze.
I've been told before that this advice isn't appropriate for anyone who isn't a Debian developer. Things can break and testing may not get important security patches until a while after unstable and stable.
The security patches is certainly a concern (though testing-security does exist, albeit not with the coverage of security-updates from stable). In my experience, testing is quite stable for 95% of packages; I can only think of a few instances in the last decade that testing has really broken my computer in a way that required me to break out my developer skills. More frequently, you'll find packages which can't be installed because they've been dropped from testing due to RC bugs -- but that's not necessarily a bad thing!
Not a Debian developer here. I've been running both Debian testing and unstable on various machines for about a decade and it's been great.
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.
I think that having to check the issue tracker before installing packages is exactly the kind of thing that people are talking about when they say "here be dragons". By your argument, we would also be able to call Arch Linux a very reliable distro. It can be if you know what you are doing, but it isn't something I would want to recommend to the average user...
> 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/
I've had a more pleasant experience using Fedora than Debian Testing.
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.
As a long time Debian user, I think you're doing Debian a disservice giving that advice. Debian testing is stable... except when it's not. Tell people that it's relatively stable, not that it's stable. And please don't tell them to run their daily driver on it unless they know what they're potentially getting into.
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 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)
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.
That would be the one! I posted a stackoverflow question along with my workaround not knowing the cause. Fortunately, someone else identified timidity as the root cause. Definitely one of the stranger issues I've run into using testing in recent years, but far from the only one.
I think it's reasonable advice if the user explicitly wants a rolling release, and knows what that entails.
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.
Yes, big transitions with desktop environments can lead to glitches for a while too. Theoretically independent parts can be upgraded at different times, but show subtle compatibility bugs not captured in the dependencies. I experienced this with big KDE Plasma updates. Nothing too big, and when you know about it it's easy to avoid with temporary pinning.
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).
Running Debian, and in my case Devuan never leaves me hanging. Ubuntu and similar distro's often break everything with a regular update. Thanks for your hard work, a huge fan for 20 years+!!!
I've used Debian unstable and agree, but given that most packages in testing usually only lag behind those in unstable by a few weeks... any particular reason?
That's kind of the same question I would have about choosing testing over sid.
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.
In my experience, testing is (across the entire release cycle) often more buggy than sid, especially as it will get scant detailed attention in, say, the first year after a stable release. Using testing (for me) is usually just another annoying speedbump too - for example, one's issue is usually fixed in unstable and you are "just" waiting for it to migrate but it won't due to some boring, unrelated reason about 7-dependencies deep that might take a week or so to be resolved...
Debian Testing is always more or less up to date and in the several years I've been using it I've never encountered a system breaking bug. It all seems to get ironed out in the Unstable branch.
I was debating doing the same thing, but I found MX Linux to be an appealing hop after years of Debian. I don't particularly care for sleek looks and really like XFCE, but my hardware can handle much more anyway so why not.
Used Redhat 20 years ago, switched to Debian based distros 10 years later, never looked back.
Debian distros provide a reliable and consistent experience. I don't have to use one distro flavor on my notebook, another on my workstation and yet another when I need updates for my enterprise server.
Do more than 5% of Linux users use Fedora? I doubt it. It sounds like you're stuck on a marginally important distro but for some reason can't move on. Enjoy your niche IBM Linux distro!
I used Debian on servers and something more recent for my desktop (Fedora or Arch), but recently I've been playing with openSUSE since it has both use cases covered, as well as an enterprise upgrade path.
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.
On the contrary I left Redhat at 8.0(long time ago, before Fedora) and started using debian/ubuntu and never looked back, in my opinion, while Redhat made a fortune by its business model, Debian and ubuntu are the true community OS, I can't ask for more.
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.
Been meaning to ask a Fedora user... does it still rely on 3rd party repos? I switched to Debian around RHL 6 or so due to the reliance on 3rd party repos and I know RHEL/Centos still rely on it and was curious if Fedora did?
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.
Debian is as sleek as you want to it to be, in your case if you're after bleeding-edge packages the release you want to try is either Testing or Unstable, not Stable(in this case aka. Buster). APT was recently updated and shortened to a 3 letter command(à la DNF) and is now run as simply #apt update.
People that have used both Ubuntu and Debian, what are the cons of using Debian over Ubuntu? Also, which is the best supported desktop environment these days for Debian?
I run Debian everywhere, it's super stable, had machine that was running production jobs for almost 3 years without downtime (around 1000 days uptime) and it went down because of server power supply failure. Have plenty of machines with 1+ year of uptime.
I also run Debian (almost) everywhere. For those who want a rolling release, Debian testing is also surprisingly stable. One of my laptops has been on testing getting continuous updates for about 7 years now and still runs great.
Even Debian unstable is reasonably stable for me (despite the name), comparable to other rolling-release distros I think. Really not-ready-to-ship stuff is uploaded to 'experimental' instead. The main precaution I take is having 'apt-listbugs' installed. It checks for any new high-severity bugs in the packages you're upgrading. You can take a look at them before deciding whether to upgrade, which occasionally helps avoid installing something broken.
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.
You're describing my setup exactly. Stable for servers, testing for personal machines, with apt-listbugs installed (the install guide recommended this at one point, not sure if it still does). I also ran unstable for about two years and, like you said, it was fine.
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.
I would argue that’s mostly due to the Linux kernel being stable. Not to take anything away from Debian the hard work of the maintainers and contributed of Debian.
There are a lot of live patching solutions available, paid and free. On my Debian systems, I use KernelCare (like $2.50/server/mo) for a hands-off experience, have only had good experiences over the years.
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.
1000 days of uptime means the server never rebooted for 3 years, since you need to reboot to apply kernel update / firmware update. ( and plz don't mention ksplice ect .. those are not intended for that )
How do you update firmware without rebooting for 3 years? And no it's a stupid idea to use Ksplice for that long and I'm 99.9% sure that OP didn't use Ksplice or similar solution anyway, it's just bad mgmt.
I know this sort of personally aggressive comment is common in some technical circles, but it's not ok on HN. Would you mind reviewing https://news.ycombinator.com/newsguidelines.html and sticking to those rules, and spirit, when posting here? We'd appreciate it.
I second this, Debian is the professionals stable platform. Never does an update leave me F*%@, as I've mentioned in this same thread I'm a Devuan guy (sorry to be repetitive) but I simply cannot get down with systemD - maybe I am just old... Devuan is great, but much much much thanks to the Debian guys for provide a beautiful and solid base. Thanks Debian team you guys are amazing!
...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.
how long before ubuntu switches over to this? i don't even know if ubuntu has forked from debian or it's pretty much the same, but with different package management?
I believe that Ubuntu gets their packages from Debian unstable not stable. So the latest Ubuntu most likely already has very similar packages (if not slightly newer) to this.
Ubuntu is cut from Debian testing, not stable. Testing uses a rolling release, so any recent Ubuntu will already have most of the changes that went into Buster today.
thanks all. does anyone have any experience with debian in production for hosting restful api backends? i use ubuntu almost exclusively, but i always see something about it being derived from (debian) 'stretch' or whatever so was wondering what i'd typically get in terms of benefit compared to ubuntu.
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.
I remember installing Linux when I was like 14 and having a hard time trying to understand what x86/x86_64/x64/arm64 was. Knowledge that is mandatory, isn't explained in the place where kids encounter it for the first time, but completely useless if all you want to do is use a computer.
I think that says more about the attention span of people in 2019 than anything else... below the announcement and description of "what's changed" there is this:
The installation images may be downloaded right now via bittorrent (the recommended method), jigdo, or HTTP; see Debian on CDs for further information.
Really? What about the "Download Debian 10.0" link in the top right of the home page? Or "The latest stable release of Debian is 10.0" down near the fold? There's also the "Getting Debian" link at the head of one of the columns right in the middle of the page.
None of those are actually download links. Keep digging. Go past the definition of "free", turn left at the difference between a USB stick and a flexible USB stick, and then the third door from the end of the hall across from the one marked JIGDO MIPSEL will take you into a dark closet filled with laundry and checksums. It may as well be root/.workspace/.garbage.
Which is not the first link one sees for "Getting Debian" on the left-justified front page. In fact the first link one sees for "Getting Debian" is called "Getting Debian", and it takes you into the upside down.
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 agree that the links are there on the front page, but the page as a whole is so busy that they’re hard to spot!
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.
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.
I'm not sure what you mean because I've never had to type anything manually at the grub prompt in an installation use case -- the boot images seem to be configured right, to give you a ramdisk and go into an installer.
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.
to be fair that is the free version and a majority of end users will likely need non-free versions with driver support for wi-fi and such, with is relatively annoying to find.
What? There is no such thing as 'non-free' Debian. The Debian repositories do contain the 'non-free' section which is used to deliver non-free firmware among other things.
There are unofficial "non-free" Debian images (both install and live) that contain said non-free firmware, though. And though they're 'unofficial', they may be needed to enable even fairly baseline features on recent hardware.
I would not trust any unofficial installer. Luckily many problems can be solved with a USB-Ethernet adapter and later configuration of the systen, since the issue usually lies in exotic network hardware.
I upgraded a couple days ago from stretch and was happy with the no hassle experience. I got newer nvidea drivers and cuda 10.1 and finally managed to figure out how to get nvenc encoding to work. I installed it fresh on a virtual machine for a server project I am working on and was glad to find all my scripts work as expected (about 100 of them)
Congratulations to the Debian team on their new release! I will certainly be upgrading to it soon enough. Just for fun, I downloaded the ISO shortly after it went up and recorded my first impressions of using it on the happy path with the default GNOME environment. I would consider myself a technical user, but I use GNOME rarely and am not familiar with it personally.
* 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.
> * 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`).
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).
Yeah, sudo su always annoys me: sudo -i if you want a login shell and sudo -s if you don’t (e.g. you cd-ed somewhere and forgot to become root, but don’t want to cd again because the path is long or you have done some complicated setup.
IIRC, the Debian installer will make your user account sudo if you leave the root password field blank during the installation wizard. If you provide a root password then your user is not made into a sudoer by default.
I believe that is the case. I probably was not paying close attention at that stage.
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.
I feel like a lot of these are a little vague to write proper bug reports. If I get around to it and can re-produce the behavior that I was seeing with software center, that would probably be narrow enough in scope to file a bug report. But other issues like "the search screen is slow" are probably rather broad.
> 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.
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?
My understanding is that every Wayland compositor automatically runs XWayland by default for compatibility reasons, and will do for the foreseeable future.
Xwayland is Xorg. It is one of the DDX backends available for Xorg, along with kdrive, XQuartz, Xephyr, the xfree86 backend, etc. If Xorg "becomes problematic to continue using", it will simply be removed. Xwayland will be removed too, since "nobody actually uses the legacy X protocol anymore". That's the goal, to keep X around for as long as is needed for "modern" toolkits and "modern" applications to transition fully to Wayland, before removing X entirely.
> 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).
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.
> I wonder, why use Wayland at all? What are the benefits?
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.)
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.
> I wonder, why use Wayland at all? What are the benefits?
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!"
I would cite the OpenBSD approach[1] as being particularly good. Ultimately, what you want is a list associating SSIDs with passwords, and that's all it is. It does not handle WPA2 enterprise though, which is sometimes a pain.
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.
Unfortunately the bold decision to take on Wayland (due to Gnome) in the upstream debian buster isn't going to propagate to low end hardware like Raspberry Pi incl. Pi4.
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.
> 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)
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.
In these contexts people usually mean "GNU/Linux desktop" when they say "Linux". It is not as if we have any meaningful choice of desktop environment on Android-land anyway.
The person you're replying to said scaling not spacing.
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.
I could also criticize the spacing, but much ink has already been spilled on Gnome 3.X on both sides of the argument; I'm not looking to start a flame war.
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.
There are themes that address the spacing / padding problem. I want to try Nextwaita [1] when I'll find the time to upgrade my Ubuntu 16.04 system. I have a try to Ubuntu 18.04 on a separate partition and padding is really unbearable.
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.
Themes are not supported: https://stopthemingmy.app/ and cannot be changed via the happy path GUI, though I did see that Debian 10 includes Gnome Tweak Tool out of the box.
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.
I believe Ubuntu also ships a tool for changing the theme in the default install. However the upstream (Gnome) is adversarial to this (https://news.ycombinator.com/item?id=20376442).
> If you're willing to fiddle around, there are a few good themes that don't waste so much space.
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.
> * 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`).
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.
I wonder if the timing of this is significant.
For people wanting a rock solid, free, stable distro, Debian and CentOS are two of the top choices. Even though RHEL 8 released, CentOS 8 still isn't out. I'm running CentOS 7 on my server, and it's getting long in the tooth. Debian 10 releasing before CentOS 8 will likely result in me giving it a spin.
Will someday debian authors and die hard fans understand that old libc and old Firefox or Gimp are different and one really can mean stable and another can be just outdated?
Is it possible that desktop should be developed in other manner than server?
Ah yes, Arch certainly is much better. I've had enough to do with Arch when they totally borked my workflow three times in a row in a couple of months. One of the issues was rebuilding all of the Qt5 libraries without testing any of their dependents. All Qt5 applications simply stopped working.
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.)
Actually, Debian stable uses Firefox ESR, which is updated roughly once a year. I've used Debian exclusively on the Desktop since around Etch/Lenny, and never see the need to update my browser often.
The notion of a linux distribution repackaging software released by others has always seemed a bit strange to me and a bit of an outdated practice. I get that it has its origin in the inherent need of distributions to explode packages in a distribution specific way all over the file system using distribution specific practices, scripts, file locations, etc. This indeed causes lots of headaches and creates a need for a lot of managing and testing. So don't do that. These days with things like docker and snap, there's no need for any of that and you can get your software straight from those most committed to developing, maintaining and fixing it: the original developers.
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.
Do you think that's typical? I wasn't trying to be contentious, I've always installed the latest firefox as soon as it's packaged and the other Debian users I've known were doing similar. I know ESR exists and works, but I've never gotten the impression that many people actually use it as their 'daily driver'.
I use Firefox ESR on desktop with Debian stable as well. I've never felt the need to update it, while several times, when reading about things that break in non-ESR releases, I was glad I didn't use non-ESR versions.
They could implement something like Fedora modules: you have a stable base system, and then you have separate module streams for some software packages, which are updated separately, with multiple versions supported concurrently. For example, you can install the latest Fedora, and then pull the postgresql-9.6 module (or 10, or 11, or all three in parallel), despite 11 being the "official" version.
Tangential but this is misunderstood widely, so I cannot resist the urge to explain.
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.
After spending 25 years in tech as a dev I can unequivocally state that 'stability' is a mostly meaningless meme and most all arguments built around stability=good ships with some deep and profound caveats.
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'.
Not upgrading versions of desktop applications means I won't have to deal with nasty surprises like configuration files changing, defaults changing and requiring changing configuration, disappearing features, incompatibilities with existing plugins/extensions or integration with other tools.
Can you just not upgrade on your own machine.
Why other should suffer?
Changes in life are inevitable.
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 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.
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.
It's impossible when you just need pick up one distro and get new desktop software as it releases, and it also being supported by commercial vendors.
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)
> Will someday debian authors and die hard fans understand that old libc and old Firefox or Gimp are different and one really can mean stable and another can be just outdated?
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.
1. Mac OS somehow achieved exactly this.
2. Actually no-changes and no-brainers are bad for mental health of elderly. In that age brain needs training.
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.
> god only knows how entire install base of mac and windows machines works today
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.
This is the point of flatpak and appimage (and snap, though it is meant more for servers). To address the need for the mix of stable parts of the system and up-to-date parts. Between the applications and the OS.
As in all threads on Debian stable, I see criticisms that stable software is stale / too old. That really misses the point: this is not a bug, it's a feature of stable!
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.
I use a ton of flatpaks on my system and don't notice the difference between them and "real" packages. I use Signal, Telegram, a few games, and the Steam flatpak, which is a great way to use Steam without enabling multilib on Arch.
This is particularly useful in the context of today's release policies. Between the ease of updating, the (perfectly justified!) "release early, release often" policy and the occasional rewrite frenzy, many open source projects never have a truly stable release. On every release, at least some of the components or new features are, at best, beta-quality. The next release (typically) solves some of the bugs, but introduces new ones -- because it includes a new (and pretty much unfinished) feature, or something got rewritten and so on.
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.
While this is true it widens the gap between stable -> unstable. So your only choice is either have really old [1] or really new.
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.
> While this is true it widens the gap between stable -> unstable. So your only choice is either have really old [1] or really new.
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%).
Or you can just select to hold that package for updates in a package manager in a competent distro that actually gets needed security and usability updates.
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)
Turning on AppArmor by default was a mistake. It completely broke Firefox, because my homedir is accessed via a symlink and AppArmor refused to let Firefox write its lockfile via a symlink. The diagnostics are pretty much non-existent and it took me the best part of a day to figure out what the problem was. The AppArmor docs say it's only really intended to be used with system daemons, having user apps like Firefox use it is just asking for trouble. I disabled it via grub and uninstalled out all the userland components as well.
Lucky for you. The tinkerboard is actually pretty nice gear aside from the god forsaken hw accel.
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 my anecdata, I'm seeing Debian growing into the role that Red Hat used to have in the enterprise, on VPSs, and as a stable build server requiring older gcc and other backports etc., with Ubuntu being the the most used O/S by developers now (more than Mac OS, let alone Windows, at my recent customers). I'm quite ok with it, as it keeps the door open for Devuan to get rid of SystemD as RH looses influence. With their focus on stable, I wonder if Debian could collect maintenance contributions (code or cash) from enterprises.
I have been running Stretch without systemd very happily, and I believe that should still work with Buster, at least for server uses. (It is harder to avoid Gnome and systemd on desktop setups with dynamic network / power / device reconfiguration.)
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.
I'd disagree, there's a huge amount of evidence not to use it, mainly in the form of thousands of forum and bug tracking posts with very genuine complaints and issues with systemd.
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.
It's a dependency cruft issue. "It does many things, poorly" is a common complaint.
"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 just like to thank the excellent responses here. They are food for thought and have reconsidered my view. It's a shame there's not more turnkey options for popular linux distros.
Don't like the speculation 'old software is stable', sounds like cheap marketing. If any software was released X years ago nothing doing this old release "better" or "stable", bugs happens everywhere.
That's not the sort of "stable" that is meant by "debian stable". It's "stable" as in "doesn't change". Things shouldn't break randomly every couple of months. You shouldn't wake up one morning and realize that one of your applications needs to be ported to a new API to keep working. If something works today, it should still work in 6 months, while still receiving security fixes. You should be able to reliably narrow down weird bugs without it becoming a heisenbug due to the shifting sands of your underlying software distribution.
265 comments
[ 5.0 ms ] story [ 257 ms ] threadTherefore, 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?
[1] https://github.com/xmonad/xmonad
[2] https://github.com/waymonad/waymonad
[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.
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.
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.
Debian distros provide a reliable and consistent experience. I don't have to use one distro flavor on my notebook, another on my workstation and yet another when I need updates for my enterprise server.
Do more than 5% of Linux users use Fedora? I doubt it. It sounds like you're stuck on a marginally important distro but for some reason can't move on. Enjoy your niche IBM Linux distro!
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/
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.
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.
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.
https://acronyms.thefreedictionary.com/BD-ROM
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...
If I'm deploying node to a server the first thing I do is set the system up to use nodesource's repos.
* 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.
https://www.debian.org/Bugs/
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:
https://packages.debian.org/jessie/debbugs
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.
[0] https://keithp.com/x-ideas/x-security/
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.
1 - https://man.openbsd.org/hostname.if
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...
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.)
[0] https://www.debian.org/security/2019/
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.
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)
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)
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.