Slashdot Mirror

fyi, debian has a reproducible builds project as well
https://wiki.debian.org/Reprod...

If you are against binary closed blobs, then I guess windows is a no go for you and your special unamed hardware.

I've had no problem using kodi or vlc to watch x264.

In fact, x264 playback is even in Debian without needing to install extra repos (and unless Debian has changed allot over the years, if Debian feels it's free and safe enough to use, I'm sure Ubuntu and most the other main distros play it just fine.)

https://wiki.debian.org/Multim...

features a 10-inch display, integrated kickstand, and Windows 10

I guess the foam helmet is extra? :P

p.s. When you're ready to remove the training wheels, Linux will be waiting.

For many years Google had their own Ubuntu distro called Goobuntu. Google recently replaced Goobuntu with gLinux, a Debian distro based on Debian Testing. So it's not all about ChromeOS.

In there you'll see you can happily use your computer while those nasty background services you incorrectly claim are making the hourglass spin (they don't, that's the whole point of background service) are quickly loaded.

I can technically "use" File Explorer once I log in, but if I actually try to open anything, the process will be told to get in line for use of the HDD behind all the other updater processes that are trying to use the HDD right now.

You're comparing an update check to something that actively scans every file when it is accessed.

The antivirus "actively scans" the update check executable "when it is accessed." And once the update check is running, it reads the existing main executable to see which version is installed, which causes the antivirus to "actively scan[]" the main executable "when it is accessed." That's two scans per updater at every login.

It may surprise you to know that Core2Duos haven't gotten any slower

Agreed. But the updaters of newer versions of popular Windows applications have become more bloated. Whether it's a Core 2 Duo or the latest i7 matters little because it's not the CPU; it's the HDD. And unless the PC owner splurges for an SSD and an external enclosure for his existing HDD, the laws of physics limit how many random inputs and outputs per second (IOPS) you can get out of an HDD.

My Core 2 Duo laptop running Debian is still snappy. But Debian has the advantage that only one updater is running at once (APT), compared to a separate updater for each application on Windows. Even if background update (such as unattended-upgrades ) is enabled, APT is single-threaded, which gives other applications a chance to use the HDD while APT is using the CPU. In addition, unattended-upgrades doesn't run at every login; it runs only once daily.

You want benchmarks? Make some.

Microsoft already made some of the tools used in my benchmark. Since Windows 8, Task Manager displays what fraction of time is spent servicing disk I/O requests. When a bunch of updaters are running, that's pegged at 100%, which can take a minute or more. Before that, one could look at the HDD access light or just listen to the HDD's head moving back and forth and use a stopwatch from pressing Enter on the password screen to when it settles.

Or use some common sense such as examining the CPU time or memory footprint of the processes on any machine so you can see how completely and utterly irrelevant they actually are.

In my experience, CPU time and memory footprint are less relevant to responsiveness at login than HDD usage time.

Side note: Yes you absolutely should tell those pensioners to throw away Vista, and if their Core2Duos can't run Windows 7 or Linux then throw away the entire PC.

Agreed. But in most cases, an Xfce-based GNU/Linux distribution (such as Debian Xfce or Xubuntu) works well on older hardware, with the exception of oddball laptop hardware without good Linux drivers. So for someone whose PC's preinstalled operating system's support period has ended, my advice is "backup user profiles, wipe, and Linux".

Its main upside appears to be being written in rust.

Yay for a language with API breaks that make its compiler unbuildable with previous minor versions of itself, and such a stellar portability.

No, I didn't know that. In the past, several laptops such as the ASUS T100TA and X205TA have had serious problems with X11/Linux. Basic hardware features lacked working drivers, such as Wi-Fi, audio, backlight brightness, and suspend. (Source; check its revision history)

Bruce,

OK, so that's fair enough, but is there any real reason for Devuan to behave as anything other than a normal Debian derivative?

When they were trying to "eradicate every last work by Mr. Pottering", including libsystemd0, that wasn't going to work, since Debian doesn't really have a workable way to have two versions of the same package, differently linked (well, not without an explosion of foo-without-libsystemd packages, which wasn't going to get past the ftpmasters).

Now that they seem to have rowed back a little from that position, it seems like the main thing is the maintenance of alternative packages, and the testing of the coherent whole, both of which could be pushed upstream to some extent.

If all the packages could be pushed upstream, then Devuan might even be able to be a Debian Blend, or perhaps even a Debian Pure Blend, which would then allow them to release in a timely manner. Even without that, I'm sure that there are Debian users that would appreciate the option of using the main components like eudev.

Looking for evidence of attempts to package eudev for Debian, this is about it as far as I can see:

    https://bugs.debian.org/cgi-bi...
and
    https://lists.debian.org/debia...

neither of which have gone anywhere since.

Given that the packages now exist, it ought to be pretty trivial to upload them to Debian. That is likely to attract more people to use them, resulting in more effort being available to keep them maintained in future, so everyone wins.

If there's some reason that they cannot be uploaded to Debian in their current state, then it would be helpful to have the ITP ( https://wiki.debian.org/ITP ) in the BTS ( https://wiki.debian.org/BTS ), with blockers being described, providing somewhere to discuss how to address that situation.

Cheers, Phil.

Bruce,

OK, so that's fair enough, but is there any real reason for Devuan to behave as anything other than a normal Debian derivative?

When they were trying to "eradicate every last work by Mr. Pottering", including libsystemd0, that wasn't going to work, since Debian doesn't really have a workable way to have two versions of the same package, differently linked (well, not without an explosion of foo-without-libsystemd packages, which wasn't going to get past the ftpmasters).

Now that they seem to have rowed back a little from that position, it seems like the main thing is the maintenance of alternative packages, and the testing of the coherent whole, both of which could be pushed upstream to some extent.

If all the packages could be pushed upstream, then Devuan might even be able to be a Debian Blend, or perhaps even a Debian Pure Blend, which would then allow them to release in a timely manner. Even without that, I'm sure that there are Debian users that would appreciate the option of using the main components like eudev.

Looking for evidence of attempts to package eudev for Debian, this is about it as far as I can see:

    https://bugs.debian.org/cgi-bi...
and
    https://lists.debian.org/debia...

neither of which have gone anywhere since.

Given that the packages now exist, it ought to be pretty trivial to upload them to Debian. That is likely to attract more people to use them, resulting in more effort being available to keep them maintained in future, so everyone wins.

If there's some reason that they cannot be uploaded to Debian in their current state, then it would be helpful to have the ITP ( https://wiki.debian.org/ITP ) in the BTS ( https://wiki.debian.org/BTS ), with blockers being described, providing somewhere to discuss how to address that situation.

Cheers, Phil.

Bruce,

OK, so that's fair enough, but is there any real reason for Devuan to behave as anything other than a normal Debian derivative?

When they were trying to "eradicate every last work by Mr. Pottering", including libsystemd0, that wasn't going to work, since Debian doesn't really have a workable way to have two versions of the same package, differently linked (well, not without an explosion of foo-without-libsystemd packages, which wasn't going to get past the ftpmasters).

Now that they seem to have rowed back a little from that position, it seems like the main thing is the maintenance of alternative packages, and the testing of the coherent whole, both of which could be pushed upstream to some extent.

If all the packages could be pushed upstream, then Devuan might even be able to be a Debian Blend, or perhaps even a Debian Pure Blend, which would then allow them to release in a timely manner. Even without that, I'm sure that there are Debian users that would appreciate the option of using the main components like eudev.

Looking for evidence of attempts to package eudev for Debian, this is about it as far as I can see:

    https://bugs.debian.org/cgi-bi...
and
    https://lists.debian.org/debia...

neither of which have gone anywhere since.

Given that the packages now exist, it ought to be pretty trivial to upload them to Debian. That is likely to attract more people to use them, resulting in more effort being available to keep them maintained in future, so everyone wins.

If there's some reason that they cannot be uploaded to Debian in their current state, then it would be helpful to have the ITP ( https://wiki.debian.org/ITP ) in the BTS ( https://wiki.debian.org/BTS ), with blockers being described, providing somewhere to discuss how to address that situation.

Cheers, Phil.

Bruce,

OK, so that's fair enough, but is there any real reason for Devuan to behave as anything other than a normal Debian derivative?

When they were trying to "eradicate every last work by Mr. Pottering", including libsystemd0, that wasn't going to work, since Debian doesn't really have a workable way to have two versions of the same package, differently linked (well, not without an explosion of foo-without-libsystemd packages, which wasn't going to get past the ftpmasters).

Now that they seem to have rowed back a little from that position, it seems like the main thing is the maintenance of alternative packages, and the testing of the coherent whole, both of which could be pushed upstream to some extent.

If all the packages could be pushed upstream, then Devuan might even be able to be a Debian Blend, or perhaps even a Debian Pure Blend, which would then allow them to release in a timely manner. Even without that, I'm sure that there are Debian users that would appreciate the option of using the main components like eudev.

Looking for evidence of attempts to package eudev for Debian, this is about it as far as I can see:

    https://bugs.debian.org/cgi-bi...
and
    https://lists.debian.org/debia...

neither of which have gone anywhere since.

Given that the packages now exist, it ought to be pretty trivial to upload them to Debian. That is likely to attract more people to use them, resulting in more effort being available to keep them maintained in future, so everyone wins.

If there's some reason that they cannot be uploaded to Debian in their current state, then it would be helpful to have the ITP ( https://wiki.debian.org/ITP ) in the BTS ( https://wiki.debian.org/BTS ), with blockers being described, providing somewhere to discuss how to address that situation.

Cheers, Phil.

This is still a thing. https://www.debian.org/ports/k...

i'm ready to pay not once, not twice, but thrice the Apple Tax for anyone willing to provide a stable linux environment for me

Install this: https://www.debian.org/
Choose KDE for your DE.

Contact me to know where to send your check

Last I checked, Wine required an X server, and Microsoft didn't provide one for WSL. Nor has the free version of Xming been updated in over a decade.

Or are you referring to running Linux on the bare metal and running applications in Wine? That works so long as Linux and X.Org support your PC's hardware. Though some PCs work better with Linux, others work better with Windows, sometimes fairly spectacularly.

I much prefer nvi over vim, not the least due to file locking

Then please make noise, maybe someone will finally deign to include some badly needed bug fixes in the upcoming Debian release, especially one related to locking, as well as getting rid of an embarassing security hole someone managed to introduce by blindly messing around with the recovery scripts.

I have a lot of other bug fixes, especially related to multibyte support, but judging by the reactions, it seems that I'm the only nvi user left on Debian; there's hope, however: someone found it worth his time to make the building of the nvi package dependent on systemd ;-)

I much prefer nvi over vim, not the least due to file locking

Then please make noise, maybe someone will finally deign to include some badly needed bug fixes in the upcoming Debian release, especially one related to locking, as well as getting rid of an embarassing security hole someone managed to introduce by blindly messing around with the recovery scripts.

I have a lot of other bug fixes, especially related to multibyte support, but judging by the reactions, it seems that I'm the only nvi user left on Debian; there's hope, however: someone found it worth his time to make the building of the nvi package dependent on systemd ;-)

I much prefer nvi over vim, not the least due to file locking

Then please make noise, maybe someone will finally deign to include some badly needed bug fixes in the upcoming Debian release, especially one related to locking, as well as getting rid of an embarassing security hole someone managed to introduce by blindly messing around with the recovery scripts.

I have a lot of other bug fixes, especially related to multibyte support, but judging by the reactions, it seems that I'm the only nvi user left on Debian; there's hope, however: someone found it worth his time to make the building of the nvi package dependent on systemd ;-)

I much prefer nvi over vim, not the least due to file locking

Then please make noise, maybe someone will finally deign to include some badly needed bug fixes in the upcoming Debian release, especially one related to locking, as well as getting rid of an embarassing security hole someone managed to introduce by blindly messing around with the recovery scripts.

I have a lot of other bug fixes, especially related to multibyte support, but judging by the reactions, it seems that I'm the only nvi user left on Debian; there's hope, however: someone found it worth his time to make the building of the nvi package dependent on systemd ;-)

No, he's a good little Entemanns.

It's better than being a Little Debian Snack Cake.

I have never nor have I witnessed anyone who has had a driver issue with linux.

Then you are fortunate not to have been handed an ASUS Transformer Book T100TA. As of 2018, many things are still broken, including suspend, screen backlight control, Bluetooth, and the internal camera. Audio and networking require proprietary firmware packages that Debian cannot include in the install image, and good luck downloading said packages without networking.

They've chosen Clang over GCC for political reasons: despite a codebase without historical baggage, Clang is at least several percent slower than GCC, it only compiles faster. A good rule of thumb is that Clang-built code executes as GCC at one optimization level less, with compilation speed being likewise faster. Obviously, this wildly differs per test case.

Also, Clang's portability is pretty bad.

Looks like the Debian Popularity Contest mixed in with some hardware reports. Doesn't look that odd to me.

You can completely uninstall "popularity-contest" by doing an "apt-get purge popularity-contest" and away it goes.

Is it an annoyance to have to uninstall it after doing a "fresh install" of Debian? Yes, but at least it's better than Micro$haft Windoze 10 that will not let you uninstall or even turn off their "customer experience" crap.

When the day comes that the Debian Community makes "popularity-contest" a permanent "always on" aspect of their Linux distribution, well, that's the day when even Linux has gone the way of Windoze.

Hell, you can uninstall Windows altogether from your PC and still have a usable PC.

That's true of select PCs. But good luck getting usable suspend on something like a ASUS Transformer Book T100TA after installing a competing operating system. From that page: "Closing the lid triggers automatic suspend to RAM, which causes a full freeze."

Looks like the Debian Popularity Contest mixed in with some hardware reports. Doesn't look that odd to me.

Yeah, essentially we now know what is most popular among a handful of bored or zealous users.

The Debian Popularity Contest automatic rolling poll has package-level info on a couple hundred thousand systems. Of course systems != users and monitoring the atime of a file overcounts things that get run automatically on occasion (e.g. if some application isn't complying with Debian standards and opens nano or vim instead of the system's "sensible-editor" default, it would affect those results even if the user hates said editor.) And you have to find all the different flavors/major versions to get a complete count on a package. But still, a much more robust data set

Yep. If someone asks me what kind of laptop to buy, I don't even hesitate. I always say ASUS. It doesn't matter what kind of laptop they are looking for, or how much they want to spend, ASUS not only has an answer but it probably won't suck. [Praises Eee PC] and their driver support tends to be top-notch.

On the other hand, ASUS made the Transformer Book T100TA, which Debian contributors still haven't managed to get working after several years.

I can take the ubuntu source, build it and run it on just about any PC

And be without accelerated graphics, audio, WLAN, and suspend until you install blobs.

No I can get free versions of many of those drivers, and i can build kernel modules to install many of the proprietary ones like the nvidia ones if i wish. Do any of the Android vendors provide buildable kernel modules that allow you to upgrade the kernel and still install the driver?

Good luck building Debian or any other GNU/Linux distribution from source and installing it on an ASUS T100TA, for which many key blobs were never remade for Linux (source).

There will always be exceptions to the general rule and there are outlier cases in the PC world but in the Android world that's the norm. You can always find some niche combination of variables and point to that as an example of the exception to the rule but that doesn't prove anything we don't already know.

No the point is that you can't just take AOSP, build it and install it on any device.

Google is trying to fix that. Treble in Android 8 is an ABI allowing new versions of Android to install on top of the hardware abstraction layer provided by the manufacturer of an Android 8+ device. It'll be more like Windows or some GNU/Linux distributions, where the blobs are their own separate package and have their own test suite (Treble VTS on Android or HCK on Windows).

I can take the ubuntu source, build it and run it on just about any PC

And be without accelerated graphics, audio, WLAN, and suspend until you install blobs. Good luck building Debian or any other GNU/Linux distribution from source and installing it on an ASUS T100TA, for which many key blobs were never remade for Linux (source).

I have a watch that is a computer for real. It is the EZ430

Most digital wristwatches aren't nearly as user-programmable as the eZ430-Chronos.

And yes, the iPad has a processor that you can program, so it is, indeed, a computer.

The iPad is not shipped as a general-purpose computer but can be turned into one with an additional purchase of a proprietary product. In the case of an iPad, buying a Mac new enough to run the latest Xcode turns it into a general-purpose computer.

If one could program it using only free software (as opposed to the full IDE or Xcode), I would count it as already general-purpose. Android devices are this way, as Debian provides a functional free subset of the Android SDK.

There is no way I would ever use proprietary software for anything mission critical again.

Would that include your CPU's microcode, your motherboard's BIOS or UEFI, or the driver for its GPU or WLAN chipset? If, say, you have a computer that performs this poorly if switched to free software (no suspend, no backlight brightness control, no Bluetooth, no webcam, proprietary audio, proprietary WLAN), with what computer of a similar form factor (tablet with attachable keyboard) would you replace it?

Go to PC World (or your local equivalent), look at the laptops and choose a small one. How hard can it be?

Harder than you might think. The only 10 inch laptop in a local Best Buy is an ASUS Transformer Book, and those are known to have serious problems with Linux compatibility.

Maybe because it is? Go look at the Great Computer Language Benchmark game. C absolutely *dominates* all but the closest 2-3 other languages. So, where are you coming from?

I'm still using one of the first T100s [...] Never given me any grief.

Last I checked, GNU/Linux on a T100 was missing a whole bunch of stuff. In particular, backlight brightness cannot be controlled, the camera is not detected, and suspend causes a full freeze.

Debian Stable, as of this writing, has Chromium [1] version 63.0.3239.84-1~deb9u1, which is roughly up to date with the current Chrome Stable Channel release. Given this, I'm not sure why you claim it is out of date. Are you running oldstable? In which case, you would have Chromium [2] version 57.0.2987.98-1~deb8u1, which is indeed about 9 months out of date and vulnerable.

[1] https://packages.debian.org/st...
[2] https://packages.debian.org/je...

Debian Stable, as of this writing, has Chromium [1] version 63.0.3239.84-1~deb9u1, which is roughly up to date with the current Chrome Stable Channel release. Given this, I'm not sure why you claim it is out of date. Are you running oldstable? In which case, you would have Chromium [2] version 57.0.2987.98-1~deb8u1, which is indeed about 9 months out of date and vulnerable.

[1] https://packages.debian.org/st...
[2] https://packages.debian.org/je...

A quality laptop using any OS you like.

That'd be fine if companies still made 10.1" laptops designed to run desktop operating systems.

I have an Asus Transformer T100 that I bought well after December 2012.

As of the latest update to the Debian project's compatibility page for the T100TA, suspend and Bluetooth are "Error (Couldn't get it working)", screen backlight is "Unsupported(No Driver)", and WLAN and audio are "Only works with a non-free driver and or firmware".

Or does "any OS you like" mean "any OS you like so long as it is Windows" in the same way that the Ford Model T came in "any color that he wants so long as it is black"? Does "systems" refer to both Windows 8.1 and Windows 10?

Here's one you can buy for $300. [ASUS Transformer Book T101HA-C4-GR]

Is Linux more compatible with the T101HA than with the T100TA? In this forum post, a user complains about "missing sound."

For example, Debian's SysV init scripts:
https://wiki.debian.org/LSBIni...

X-Start-Before: boot_facility_1 [boot_facility_2...]
X-Stop-After: boot_facility_1 [boot_facility_2...]

provide reverse dependencies, that appear as if the listed facilities had should-start and should-stop on the package with these headers.

And once again a systemd opponent proves to be an idiot or a liar. Handling a degraded array and making it bootable has always been the job of the initramfs. See this Debian bug dealing with this issue, for example, where the maintainer himself admits so.

There's many hours of reading the Debian CTTE and bug archives about the system init discussion if you have a bit of time and are that interested.

A short version, which is mostly still applicable and accurate for the large part from the past 2 years, is the Debian debate wiki pages with the arguments for and against various init systems to switch to. It's notable that *no-one* wanted to use sysvinit moving into Jessie, and the votes for upstart were heavily partisan being current and ex-canonical employees or upstart developers ... those without that specific background preferred to switch to systemd. The other semi-serious candidate was openrc but it had poor documentation at the time and wasn't even in the debian archives at the point the discussions started. It was also seen as only a slightly incremental improvement over sysvinit/insserv and not worth the effort of a major modernisation of init ... if everything was going to shift then it needed capabilities like socket activation etc which left upstart or systemd as contenders.

The debian init debate points

The bug for the default init for the CTTE to decide"

There's many hours of reading the Debian CTTE and bug archives about the system init discussion if you have a bit of time and are that interested.

A short version, which is mostly still applicable and accurate for the large part from the past 2 years, is the Debian debate wiki pages with the arguments for and against various init systems to switch to. It's notable that *no-one* wanted to use sysvinit moving into Jessie, and the votes for upstart were heavily partisan being current and ex-canonical employees or upstart developers ... those without that specific background preferred to switch to systemd. The other semi-serious candidate was openrc but it had poor documentation at the time and wasn't even in the debian archives at the point the discussions started. It was also seen as only a slightly incremental improvement over sysvinit/insserv and not worth the effort of a major modernisation of init ... if everything was going to shift then it needed capabilities like socket activation etc which left upstart or systemd as contenders.

The debian init debate points

The bug for the default init for the CTTE to decide"

A big ol ball? My init.d was about 13 scripts big which were readable and editable.

On what distro was this?

Remember on many systems running sysvinit, you used to have something like rc.sysinit, which was a few thousand lines of shell script written to try and get every possible ordering possible dependencies to get all required filesystems in /etc/fstab mounted. For example, is /var on RAID on local disks? Or is it on LVM on top of local software RAID? Or is it LVM on FC? Or is it LVM on top of LUKS on top of RAID? Or LUKS on LVM on iSCSI? And is /usr on NFS accessed over a tagged VLAN interface? The dependency-based approach systemd takes for this simplifies a lot of things, but can be a bit more confusing when something isn't working.

Ever tried to edit systemd files?

Yes, and it is much easier having a pre-defined, well-documented set of features I can use (like trivially set LimitNOFILE when the distro's package maintainer didn't ever think about supporting this) and be sure that my changes won't be clobbered by a security update.

Depending on systemd version you have to create overrides, modify symlinks or edit systemd files straight up which can be in about 5 different locations and on top of that, systemd can have overrides on any changes either with an update or just inherited.

Since I started using systemd (which was before the release of RHEL7), the file locations documented in the current systemd.unit man page have worked.

You copy the existing file from /usr/lib/systemd/system to /etc/systemd/system, make any changes you want, and run systemctl daemon-reload. This provides an easy mechanism to ensure that your changes don't get overwritten by a future package upgrade, and it is very easy to see what has been customised, or mass-customise a lot of systems.

Systemd makes every system into a dependency mess.

Remove/fail a hard drive and your system will boot into single user mode, not even remote access will be available so you better be near the machine just because it was in fstab and apparently everything in fstab is a hard dependency on systemd.

Sure, one of my pet peeves is that I don't know why sshd isn't configured with fewer dependencies, but I don't think this is a specific limitation of systemd, but just with people optimising the sshd.service unit file for different use cases (like "don't start sshd until my users with NFS homes can log in", or "don't start sshd until my network-based user-management is accessible because then nscd negative caches my users and they can't log in for an hour).

However, if you want your system to boot when a device is not available, state that (as documented in fstab(5) as 'nofail'. The behaviour systemd has is correct, and avoids systems with non-local filesystems (e.g. boot from iSCSI or boot from SAN) failing to boot due to transient issues when retrying a few times would make it succeed.

According to it's documentation, FreeBSD behaves the same way (thought the option name is different):

If the option ``failok'' is specified, the system will ignore any error
          which happens during the mount of that filesystem, which would otherwise
          cause the system to drop into single user mode. This option is imple-
          mented by the mount(8) command and will not be passed to the kernel.

systemd fails silently if something is wrong in /etc/fstab. It just doesn't finish booting.

So, it behaves correctly according to the fstab(5)man page from the release before they switched to systemd?

Which is moderately annoying if you have access to the system console and you can guess that an unchanged /etc/fstab from before systemd that worked for a while with systemd is now suddenly toxic

As far as I know, this (correct according to documentation/intent) behaviour has been the same since any stable distribution shipped systemd as the default init.

If you do not have easy access to the system console or you are not blessed with divine inspiration, that is quite a bit more than annoying.

And should teach you to always 'mount -a' when you have made a change to your /etc/fstab.

Thanks to the binary log files you cannot even boot something random and read the logs, but at least you aren't missing anything, because nothing pertinent to the error is logged anyway.

In most of the cases I have seen this, it is when someone wrote a service unit file without even bothering to read systemd.service(5) and didn't put a Type= parameter in their service file, in which case the default of simple (which is intended to replace the xinetd behaviour) applies and results in systemd assuming that it should not log stderr from the service's process. In this case, using Type=forking would probably have done what was expected. For example, on one of my systems, ntpd, dhcpd etc. use Type=forking, and they log correctly so that systemctl status dhcpd shows any errors in starting dhcpd.

One nice feature of systemd here is that you don't have to go hunting for log files (and possibly add new rules to your syslog daemon to log the facility in question first) to find the other lines of log files about you need to fix the problem, almost all services now have useful logging easily accessible by default.

If you have other examples where systemd behaves incorrectly (according to documentation of the services/features in question), maybe you could provide them.

Systemd does that bit rather impressively well. It's just terrible at actually booting the system, all the early boot stuff that you could depend on old init to get right every time, or at least spit out aggressive messages about why it failed.

So, you were relying on bugs to boot your systems?

Since the Debian community's leaders were pretty well split on whether they should adopt systemd,

Not really "pretty well split":

The Technical committee had 8 members.

Just taking the first preferences of the members four wanted systemd, two wanted upstart and two wanted further discussion.

Debian's voting system being somewhat more complicated than almost any other on earth it ended up as a tie between systemd and upstart (only one person didn't put sysvinit as the last or next to last choice). The chair of the committee cast his tie breaker for systemd.

The gory details are publicly available here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6729

why isn't the logical thing for Debian to do to simply provide both options?

I am getting fucking bored of saying this, so I will shout: Debian DOES provide both options!

Ever tried to edit systemd files?

Yes. But I did have to read some documentation.

Depending on systemd version you have to create overrides, modify symlinks or edit systemd files straight up which can be in about 5 different locations and on top of that, systemd can have overrides on any changes either with an update or just inherited.

Nope. First, you should never modify symlinks. Second, if you are looking for/creating a unit file, you only need to look in two locations: /lib/systemd/system -- for unit files that belong to packages. /etc/systemd/system -- for unit files that are customized for the local system, these can override unit files found in the above.

Pretty simple and straightforward, actually.

Remove/fail a hard drive and your system will boot into single user mode

If you have a non-essential hard disk in fstab, you should specify "nofail" in the options field. It's right there in the second paragraph under FSTAB of the FM,
https://manpages.debian.org/st...

Hi lkcl,

I know you are on a crusade against systemd, but don't you consider it unethical to spread FUD every time?

And, hey, systemd while implementing everything (according to critics) still has less bugs than sysvinit alone. systemd: 272 bugs; sysvinit: 383 bugs.

https://bugs.debian.org/cgi-bi...
https://bugs.debian.org/cgi-bi...

No wonder people wanted to leave that buggy sysvinit ship.

Hi lkcl,

I know you are on a crusade against systemd, but don't you consider it unethical to spread FUD every time?

And, hey, systemd while implementing everything (according to critics) still has less bugs than sysvinit alone. systemd: 272 bugs; sysvinit: 383 bugs.

https://bugs.debian.org/cgi-bi...
https://bugs.debian.org/cgi-bi...

No wonder people wanted to leave that buggy sysvinit ship.

Drop this selinux shit. It's too complicated and causes more problems than it solves.

I think the utility called audit2allow summarizes well the immense "value" of selinux.

generate SELinux policy allow/dontaudit rules from logs of denied operations

https://manpages.debian.org/un...

The first time I heard about it I thought it was a prank.

Some heads-up / warning: after the update the display locks up solid very quickly on 5th generation Intel CPU, making the system unusable and requiring a hard power cycle. I worked around it by manually installing the previous kernel, after a boot in recovery mode and disabling the GUI. This was with SDDM and KDE, which tend to matters in such cases (every GUI exercise the graphic stack slightly differently, so you may not see any problem with GNOME although I haven't tried yet).
I know it's not the best place to report this, but the linux kernel page on the Debian bug tracking system is down for me since yesterday. I get an internal server error on: https://bugs.debian.org/cgi-bi....
I'll post a real Debian bug report when this will get back to operational, but in the meantime here's a heads-up for people using Debian stable with KDE.

Even java code from capable sw engineers is close to c speed. See language shootout.

Did you mean this shootout where the C (gcc) benchmarks run on average 2x faster than Java?

Go read the Debian social contract to get an example on why that's not true. And there are many more.