Slashdot Mirror

I would like plasmashell to not crash every time I turn on the screen (there's actually hope for this one), or at random when I open/close windows. If plasmashell/kwin could also refrain from crashing when I run WineTest that would be nice. Though lately WineTest has been crashing the all-open-source Intel graphics driver so hard that using the screen required a reboot (am I glad I'm not using an NVIDIA/AMD graphics card with their proprietary unreliable and impossible to debug drivers). Anyway hard to make sure that plasmashell/kwin survived right now.

I'd like to be able to sort the songs per artist, album, etc in JuK, and for it to have a working Manage Folder dialog. Adding support for PTP cameras (you know, most of them), that would really be great. Means I would no longer have to connect them to either my GNOME or LXDE laptop to then transfer the photos over the network.

Oh, and icing on the cake, fixing the bugs in the bug reporting applet?

I would like plasmashell to not crash every time I turn on the screen (there's actually hope for this one), or at random when I open/close windows. If plasmashell/kwin could also refrain from crashing when I run WineTest that would be nice. Though lately WineTest has been crashing the all-open-source Intel graphics driver so hard that using the screen required a reboot (am I glad I'm not using an NVIDIA/AMD graphics card with their proprietary unreliable and impossible to debug drivers). Anyway hard to make sure that plasmashell/kwin survived right now.

I'd like to be able to sort the songs per artist, album, etc in JuK, and for it to have a working Manage Folder dialog. Adding support for PTP cameras (you know, most of them), that would really be great. Means I would no longer have to connect them to either my GNOME or LXDE laptop to then transfer the photos over the network.

Oh, and icing on the cake, fixing the bugs in the bug reporting applet?

I would like plasmashell to not crash every time I turn on the screen (there's actually hope for this one), or at random when I open/close windows. If plasmashell/kwin could also refrain from crashing when I run WineTest that would be nice. Though lately WineTest has been crashing the all-open-source Intel graphics driver so hard that using the screen required a reboot (am I glad I'm not using an NVIDIA/AMD graphics card with their proprietary unreliable and impossible to debug drivers). Anyway hard to make sure that plasmashell/kwin survived right now.

I'd like to be able to sort the songs per artist, album, etc in JuK, and for it to have a working Manage Folder dialog. Adding support for PTP cameras (you know, most of them), that would really be great. Means I would no longer have to connect them to either my GNOME or LXDE laptop to then transfer the photos over the network.

Oh, and icing on the cake, fixing the bugs in the bug reporting applet?

I would like plasmashell to not crash every time I turn on the screen (there's actually hope for this one), or at random when I open/close windows. If plasmashell/kwin could also refrain from crashing when I run WineTest that would be nice. Though lately WineTest has been crashing the all-open-source Intel graphics driver so hard that using the screen required a reboot (am I glad I'm not using an NVIDIA/AMD graphics card with their proprietary unreliable and impossible to debug drivers). Anyway hard to make sure that plasmashell/kwin survived right now.

I'd like to be able to sort the songs per artist, album, etc in JuK, and for it to have a working Manage Folder dialog. Adding support for PTP cameras (you know, most of them), that would really be great. Means I would no longer have to connect them to either my GNOME or LXDE laptop to then transfer the photos over the network.

Oh, and icing on the cake, fixing the bugs in the bug reporting applet?

I would like plasmashell to not crash every time I turn on the screen (there's actually hope for this one), or at random when I open/close windows. If plasmashell/kwin could also refrain from crashing when I run WineTest that would be nice. Though lately WineTest has been crashing the all-open-source Intel graphics driver so hard that using the screen required a reboot (am I glad I'm not using an NVIDIA/AMD graphics card with their proprietary unreliable and impossible to debug drivers). Anyway hard to make sure that plasmashell/kwin survived right now.

I'd like to be able to sort the songs per artist, album, etc in JuK, and for it to have a working Manage Folder dialog. Adding support for PTP cameras (you know, most of them), that would really be great. Means I would no longer have to connect them to either my GNOME or LXDE laptop to then transfer the photos over the network.

Oh, and icing on the cake, fixing the bugs in the bug reporting applet?

You want x32 for that. The actual speed benefit is hardly ever better than several percent, or none at all for many common tasks, though -- it's worth the hassle only for significant memory savings. Memory is cheap, though -- so you want to bother only if you run many containers per machine. Only then it is a big gain.

Indeed the strength of open source is that people can choose to fix it themselves, and overall I'm happy with the quality it brings.
I choose not to, because I prefer to spend my time and energy on other things.
Looking at the bug report, I don't see any signs it's deliberately crippled.
But the (technical and political) reasons don't matter anyway, the end result is simply that the AMD OSS driver had less problems for me as an end user.

You might be interested in the following resources:

• Debian ArmHardFloatPort
• Perl in Debian 8 (Jessie)

Cortex M4 is supported; hope this helps. -PCP

You might be interested in the following resources:

• Debian ArmHardFloatPort
• Perl in Debian 8 (Jessie)

Cortex M4 is supported; hope this helps. -PCP

there is always a choice. there is always a path to escape.

one of many. http://cdimage.debian.org/debi...

You can also try the stable releases of Fedora . You can even choose what GUI you would like as the default.

Of course, you can also try one of the many distributions as described here .

If you are an avid gamer then you basically have two choices. 1) Have a Microsoft Operating System or 2) Run a Linux distribution and run a Microsoft OS in a virtual machine if your PC has enough power. There is a third choice and that is to dual boot but IMHO this is rather pointless since most people will only stick with the OS that they play games on.

If you are not willing to switch to a Mac or a Linux distribution then just put up with Microsoft Windows.

https://www.debian.org/
https://devuan.org/
http://redhat.com/
http://www.ubuntu.com/
https://www.suse.com/
https://getfedora.org/

To list just a few...

MS is just making the choice more binary - either you choose to let them do anything they want with your computer, or you choose to let them do NOTHING.

there is always a choice. there is always a path to escape.

one of many.
http://cdimage.debian.org/debi...

I've not been able to test this myself as of yet, however there are multiple times in this very thread that state that this new change to the way systemd operates explicitly breaks tmux, screen, and nohup. I've done some cursory research on a google search and this does appear to be the case. Especially damning is this thread where it seems the workaround is to use a completely new command structure to create a long running process. If anything, the systemd team is breaking the old adage "If it ain't broke...".

Seriously; a change to the fundamental way a system handles user processes cannot be taken lightly. This new behavior is fine for a desktop machine where there'd only be a single user. For a server with multiple users that may rely on background processes to complete long running computations this very much breaks the expected behavior; and can quickly become a sysadmin's nightmare when users begin complaining that their processes are no longer staying active.

https://bugs.debian.org/cgi-bi...
says "The option has already be[en] reverted in the packaging git."

I think it's both. It's systemd for deciding that this is a sane default behavior and the debian guys for not having the balls to stand up to this bullshit. If you read the bug report linked in the summary, you'll see someone with an @debian.org address say what effectively amounts to, "This seems like a good idea for my laptop and, I can't imagine we have many users that are different from my laptop". Not even fucking kidding: https://bugs.debian.org/cgi-bi.... So, yes, debian is at fault for not having the fortitude to put this garbage in the bin. But, the filth didn't originate from debian.

"it should rather be disabled .. by setting KillUserProcesses=no in /etc/systemd/logind.conf ." ref

The issue is the violation of POLA (principle of least astonishment) given that Unix has allowed processes to run after user exit through nohup(1), which dates back to at least 1986:

* https://www.freebsd.org/cgi/man.cgi?query=nohup&manpath=2.10+BSD
* https://svnweb.freebsd.org/base/head/usr.bin/nohup/nohup.c?view=log

screen and tmux are only recent incarnations of the idea.

"it should rather be disabled .. by setting KillUserProcesses=no in /etc/systemd/logind.conf ." ref

I've had no problem getting Linux installed and ruuning on recent computers. Just have to enable "legacy boot". Most recent was a Acer Touch screen laptop that had W8.1 on it.

Perhaps it depends on how big the laptops are. Laptops and convertibles with an Atom Bay Trail processor tend to fare poorly, such as the T100TA on which sleep, backlight brightness, camera, and Bluetooth are broken. Furthermore, you have to plan ahead and download firmware-brcm80211 before you wipe the drive so that you can set up Wi-Fi and audio.

https://security-tracker.debia... claims that graphicsmagick has the same problem (I can't be bothered to test it myself right now.) Got a citation on graphicsmagick not being affected by this?

Linux hasn't had trouble with peripherals for a long time.

Not even the webcam in a Transformer Book?

There is always the possibility that you may have an edge case with your hardware that may cause you issues.

The current batch of 10 inch laptops, which are really 10 inch tablets with an included keyboard dock, are more likely to be edge cases because Intel refuses to fix bugs related to their Atom Bay Trail CPUs. The ASUS Transformer Book T100TA has a bunch of stuff missing, broken, or needing a proprietary driver that the Debian project cannot distribute. As of today, this includes suspend (broken), hibernation (broken), backlight power level (no driver exists), Bluetooth (broken), Wi-Fi (no free firmware exists), sound (no free firmware exists; no firmware at all exists for Linux 4.5 and later), and camera (no driver exists).

Tab complete works for me sometimes? Looks like that is a known bug:

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

Already fixed upstream..

I actually didn't mind the old system - I do understand the 'whys' of changing - in the long run I think we will have a better system.

But really, I've been through much more troubling changes - just isn't a big deal for those that are still capable of change.

They don't drop support for OSes just because of them being "old". They drop for not being broken unstable bleeding edge.

They dropped support for Debian wheezy before jessie was even out. If they can't manage to build on the latest stable release of a major platform that's only 1.5 years old, you shouldn't consider using them for anything that needs to be reliable.

Chromium doesn't support "32-bit Linux". It supports i386 only. In total, it supports only 2 out of 22 Debian architectures.

g. RPM dependencies are calculated from files and SONAMEs, but can also be specified manually by the packager, including version inequalities of other packages.

Debian has this too, and I think it is actually a good deal more flexible than rpm, at least from what I remember from my brief stint with Red Hat back in the day. There's a reason Debian was able to have apt long before Red Hat/Fedora had yum.

https://www.debian.org/doc/man...

Well, then that's really a problem with the community not enforcing proper requirement standards that reflect reality on important packages.

This is the real problem. And I dare say it is 99% an Ubuntu problem because they really like to break everything with each subsequent release. Debian has been a rolling release distribution since forever and is renown for the incredible robustness with which packages can be shared between stable, testing, and even unstable, as well as the ease of transitioning from one to the other (ex: when testing becomes the new stable). And they have once or twice had to do some massive renaming of library dependencies, but managed without a hiccup, which is a testament to the quality of the deb system.

No, the problem is Ubuntu. Their versioning is a constant clusterfsck of broken, incompatible package naming. And they heavily abuse "virtual" packages for their own purposes which leads to the breakage in Samba like the GP described. It is horrible release management and is one of the many things wrong with Ubuntu. However, Ubuntu manages to stay more up-to-date, and has some pretty nifty userland tools, so I find myself using it much more than Debian. But I lament every time I have to upgrade, or if I want to move packages between versions.

Snap sounds like a system with some much-needed features, but what I would really like is for those features to be integrated into deb. Unfortunately, Ubuntu is following their usual pattern of aloofness. Both Debian and Ubuntu would benefit tremendously if they could work together to enhance deb. Transactional updates? Who doesn't want that? That is a great feature. But nope, that's not going to happen, apparently. We're going to end up with another Mir, or Upstart, or Compiz (shudder).

The xscreensaver message is a perfect example of a diva developer being an arsehole

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

It is old, but timebombing your code is astonishingly bad form.

This sounds a whole lot like the Debian GNU/kFreeBSD distro! It was the Debian userland running on top of the FreeBSD kernel.

For those who don't remember, it was yet another casualty of systemd being forced into Debian, which caused GNU/kFreeBSD to be effectively killed.

Systemd is the worst thing that has happened to Debian. Not only did it cause great pain and upheaval for many long-time Debian users, especially those who need reliable and stable systems, but it also killed projects like Debian GNU/kFreeBSD, which had little to do with Linux to begin with.

It's kind of funny, in a sad way. The very action (using systemd) that killed the integration between the Debian userland and the FreeBSD kernel ended up rendering the Linux-based Debian distro unusable for many, forcing them to switch directly to FreeBSD itself!

Systemd is the worst thing to have happened to Linux, and the best thing to have happened to the BSDs!

And whipslash, if you're reading this, can you please get rid of the goddamn posting limits? I've posted maybe once or twice in the last 12 hours, if not longer, yet I kept get the fucking "You must wait a little bit before using this resource; please try again later." error message. Ditch the idiotic posting limits, please.

This sounds a whole lot like the Debian GNU/kFreeBSD distro! It was the Debian userland running on top of the FreeBSD kernel.

For those who don't remember, it was yet another casualty of systemd being forced into Debian, which caused GNU/kFreeBSD to be effectively killed.

Systemd is the worst thing that has happened to Debian. Not only did it cause great pain and upheaval for many long-time Debian users, especially those who need reliable and stable systems, but it also killed projects like Debian GNU/kFreeBSD, which had little to do with Linux to begin with.

It's kind of funny, in a sad way. The very action (using systemd) that killed the integration between the Debian userland and the FreeBSD kernel ended up rendering the Linux-based Debian distro unusable for many, forcing them to switch directly to FreeBSD itself!

Systemd is the worst thing to have happened to Linux, and the best thing to have happened to the BSDs!

And whipslash, if you're reading this, can you please get rid of the goddamn posting limits? I've posted maybe once or twice in the last 12 hours, if not longer, yet I kept get the fucking "You must wait a little bit before using this resource; please try again later." error message. Ditch the idiotic posting limits, please.

Upstart never had the contributors it needed. The Debian discussion/wiki I linked has a number of critiques. It solved little or no problems of sysvinit, introduced many of its own, and wasn't portable to other systems. Upstart had a head start on the other init replacements, and while social/political concerns may have contributed to its demise, its technical issues were what stood in the way of its success, and ultimately doomed it.

The mailing list is public, go and check it. Alternately, this site was put together as a summary of the various positions and options. If I can characterize it, there was a strong desire to move away from sysvinit due to lack of features, bugs, and difficulty of maintenance. Systemd at the time was seen as the best of the alternatives, offering more features and easier maintenance, at the cost of compatibility with non-Linux systems.

Not that I have any great insight into the minds of developers, but I suspect that the decision might have gone otherwise if it were re-held today. I think there would be a stronger consensus against sysvinit, as even fewer people are interested in maintaining those scripts. OpenRC has had more time to mature, and as far as I know Upstart development has basically ended. Interestingly, OpenRC and systemd share a number of features, particularly in their heavy use of C libraries, for which OpenRC receives no criticism and systemd no end to criticism. Either way it looks like that, dependency resolution, cgroup support, and parallel startup have made everybody's minimum feature list. I'm sure it would have been an even more different story if cgroups/process tracking had been a part of sysvinit/POSIX to begin with, but as I understand they were mostly codifying existing practices rather than trying to actually create a good standard.

In any case, Debian moving away from sysvinit wasn't any more influenced by Red Hat than it was by Canonical. All options were on the table, and each of them had their proponents. There was somewhat more backlash against systemd than other options, but I don't think politics played much of a hand in the decision -- politics didn't have to maintain the code afterwards. And despite the popular clamor for sysvinit, most everyone else seems to have dropped it happily, so ignoring the populace seems to have been the right decision in that respect.

>> 1) Javascript has awful performance ... perform many times faster than javascript.

Not true at all. SIMD does a provides performance advantage, but that is hardware optimzation.

It is more than that. Consider the following code fragment in javascript:

function sum(values) {
        var result = 0;
        for (let i=0; i < values.length; i++) {
                  result = result+values[i];
        }
        return result;
}

should be a straight forward function right? should perform the same in c++ right?, well, not so fast. I could pass an array of integers, an array of floats, an array of strings, or an array of any combination of them and the function would still be valid. So at runtime, the code would have to check the type of each individual entry in the array to figure out what the + operator really means, and in each pass, the + operator might be a completely different function. In other words, the best compiler ever would have to come up with assembly that follows this pattern:

function sum(values) {
        let result = 0;
        for (let i = 0; i < values.length; i++) {
                  tmp = values[i];
                  if (tmp instanceof int) {
                            result = addint(result, tmp);
                  } else if (tmp instanceof float) {
                            result = addfloat(result, tmp);
                  } else if (tmp instanceof string) {
                            result = concat(result, tmp);
                  } ...
                  else {
                            throw exception;
                  }
        }
        return result;
}

Actually that is an oversimplification, since the variable "result" would also be have to checked for type. It might have been turned into a string in the previous pass for example. You can see that is a lot of code that is generated to check the types if all I want is to sum up some numbers.

Now consider a similar code in C or java or any other statically typed language:

function sum(int values[], int length) {
        int result = 0;
        for (int i=0; i < length; i++) {
                  result = result+values[i];
        }
        return result;
}

The compiler knows that every single entry in values is an int, and no matter what "result" will remain an int. Therefore there is no need to check what type it is. The + operator can be simply replaced by an integer add instruction in assembly. And yes, a smart compiler could even use SIMD to optimize this code, but even without SIMD, any half brain compiler will do better than the best javascript compiler.

Now you can actually see some numbers. V8 is an amazing javascript engine, and all cases except one its an order of magnitude slower than equivalent code in C++.

That seems to be a fairly misleading statement

Windows 7 isn't just a "Kernel", it's an Operating System. Ditto for FreeBSD 7. While the kernel may be the core of an OS, userland certainly plays a significant part as well, particular for a desktop OS. For example, on a Win7 64-bit machine, the actual kernel would probably be something like "6.1.7601.17592"

So comparing those three, it would be more fair to use something like a Linux distribution/version from that era, such as
* "Ubuntu Jaunty Jackelope" (EOL Oct 2010)
* "Debian Lenny" (Archived Feb 2011)
* RHEL6 (Production good until 2020, extended life-support not listed yet).

but I can see from the other comments you've been shot down pretty well.

Indeed, I have.

Wireless works in Linux.

I believe you when you say it worked for you, but that does not generalize. We are in a rare scenario where anecdotal data actually applies. Assuming you believe me, of course.
Wireless did not work for me ~2 years ago in Debian. Honest. I spent quite a few hours googling things over a couple of days and trying what things Internet recommended, after which I moved on to another flavor of Linux (which had other issues).

There are more than a few webpages online dedicated specifically to helping choose the right chipset/WiFi card properly supported by Linux.
See Debian's Wiki on the topic. "Currently there are only a few modern wifi chipsets readily available that work with free software systems." Do you honestly think that to be equivalent to "Wireless works in Linux"?

Bullshit for very large values of bullshit. I haven't had wireless not work: on any installs I've done in the last 8-10 years now.

I think this is one rare example where anecdotal data counts. I am not saying it never works. It clearly worked for you. Perhaps you did your research in choosing the WiFi card first (I did not).
First Google page hit on debian wireless not working supports my claim. I am not saying it is Linux's fault, but there appears to be consensus on wiki.debian.org that "Wifi has always been a problem for free software users. USB Wifi cards are becoming less free."

The parent is probably referring to the fact that CDDL is NOT compatible with the GPL.

https://lists.debian.org/debia...

Unfortunately Sun then developed the CDDL[1] and JÃrg Schilling
released parts of recent versions of cdrtools under this license.
The CDDL is incompatible with the GPL. The FSF itself says that this
is the case as do people who helped draft the CDDL. One current and
one former Sun employee visited the annual Debian conference in Mexico
in 2006. Danese Cooper clearly stated there that the CDDL was
intentionally modelled on the MPL in order to make it GPL-
incompatible. For everyone who wants to hear this first-hand, we have
video from that talk available at [2].

You can read the FSF position about the CDDL at [3]. The thread behind
[4] contains statements on the issue made by Debian people; for more
context also see the other mails in that thread.
In short - the CDDL has extra restrictions, which the GPL does not
allow. JÃrg has a different opinion about this and has repeatedly
stated that the CDDL is not incompatible, interpreting a facial
expression in the above-mentioned video, calling us liars and generally
appearing unwilling to consider our concerns (he never replied to the
parts where we explained why it is incompatible). As he has basically
ignored what we have said, we have no choice but to fork. While the CDDL
*may* be a free license, we never questioned if it is free or not, as it
is not our place to decide this as the Debian cdrtools
maintainers. However, having been approved by OSI doesn't mean it's ok
for any usage, as JÃrg unfortunately seems to assume. There are several
OSI-approved licenses that are GPL-incompatible and CDDL is one of
them. That is and always was our point.

[1] http://www.opensource.org/lice...
[2] http://meetings-archive.debian...
[3] http://www.gnu.org/licenses/li...
[4] http://lists.debian.org/debian...

The parent is probably referring to the fact that CDDL is NOT compatible with the GPL.

https://lists.debian.org/debia...

Unfortunately Sun then developed the CDDL[1] and JÃrg Schilling
released parts of recent versions of cdrtools under this license.
The CDDL is incompatible with the GPL. The FSF itself says that this
is the case as do people who helped draft the CDDL. One current and
one former Sun employee visited the annual Debian conference in Mexico
in 2006. Danese Cooper clearly stated there that the CDDL was
intentionally modelled on the MPL in order to make it GPL-
incompatible. For everyone who wants to hear this first-hand, we have
video from that talk available at [2].

You can read the FSF position about the CDDL at [3]. The thread behind
[4] contains statements on the issue made by Debian people; for more
context also see the other mails in that thread.
In short - the CDDL has extra restrictions, which the GPL does not
allow. JÃrg has a different opinion about this and has repeatedly
stated that the CDDL is not incompatible, interpreting a facial
expression in the above-mentioned video, calling us liars and generally
appearing unwilling to consider our concerns (he never replied to the
parts where we explained why it is incompatible). As he has basically
ignored what we have said, we have no choice but to fork. While the CDDL
*may* be a free license, we never questioned if it is free or not, as it
is not our place to decide this as the Debian cdrtools
maintainers. However, having been approved by OSI doesn't mean it's ok
for any usage, as JÃrg unfortunately seems to assume. There are several
OSI-approved licenses that are GPL-incompatible and CDDL is one of
them. That is and always was our point.

[1] http://www.opensource.org/lice...
[2] http://meetings-archive.debian...
[3] http://www.gnu.org/licenses/li...
[4] http://lists.debian.org/debian...

FYI Windows 10... won't be bad... You're going to use it eventually whether you like it or not.

On the contrary, I did try Windows 10 and it finally convinced me to just use Debian* on everything. Admittedly, I only have five computers, not a datacenter full, but after giving Windows 10 what I consider a very fair shot, I then took Windows off every machine using a Debian install disc/USB stick. My only (admittedly distasteful) concession to windows is that I have Vista in a VM for running Turbotax, and by the time Turbotax starts to require Windows 10 or later, I'll be on some other solution. So, no, I won't be using it eventually. As GP wisely replied to you,

I don't like Win10 because of the big brother issues with it, not because it's unstable.

* I know Debian's not for everyone, but there are many alternatives.

LLVM is pretty smart, it will probably be able to remove dead stores most of the time. Using iterators in Rust will avoid bounds checks. I think the benchmarks game shows that Rust need not be slower than C or C++.

Let's put it this way: do you know that they do? If they did, why not create your own mirror?

The difference here is, as I outlined in the earlier post, that in Windows' case we know that it's phoning home despite explicit user disapproval. You're comparing facts to subjective speculation. We can speculate about anything and everything, but it doesn't mean everything that is possible is being done. And an important point with Debian is that even if it was being done, you have a legitimate and easy way of circumventing it.

That feature is not enabled by default. When you install Debian, you have to specifically select that you *want* to enable that particular functionality.

Debian with this: https://wiki.debian.org/Fonts#... fonts.conf looks great IMHO. I wish I knew why this configuration is not the default...

I'd install http://wiki.debian.org/iptable...

It's creeping to the Linux distros as well. Ubuntu had the Amazon shopping lens. Now Fedora also asks during setup if you want apps to share your location and whether full system reports are sent to Red Hat. There might be more happening. Have you ever checked what your machine sends?

Debian has had popcon for a really long time.

Thu 14 Jan 2016 :: 16:59:07 EST (-0500)

# apt-get install openssh-client ...
Get:3 http://security.debian.org/ jessie/updates/main openssh-client amd64 1:6.7p1-5+deb8u1 [691 kB]

this is not 7.1p2 needed to mitigate this bug.

Reposted non-anon to bump bonus

Open source software is not always free software.

I'm aware of philosophical differences between users of the two terms. But I wonder what substantial difference you're seeing between the terms with respect to the software itself, as the Open Source Definition published by Open Source Initiative is nearly word-for-word identical to the Debian Free Software Guidelines.

And indeed because Java demands ever more resources just to let you do what you want to do.

Im still not sure if this continual FUD is spread by old people who haven't been able to keep up with the times or by newbies desperate to blame anybody but themselves for their poor code. We already know that by and large your assertion is not true, plenty of resources already disprove it.

Because your PC was given to you for free by Microsoft?

Almost yes. An entry-level Windows PC with an OEM copy of Windows isn't much more expensive than the retail copy of Windows and Parallels required to run Windows-exclusive apps in OS X. So it's like buying a PC and getting a copy of Windows at next to no additional charge.

Or I bought a used ThinkPad without an OS license on eBay for $101 shipped and installed Debian GNU/Linux. That's cheaper than a retail copy of Windows, and I'm guessing that a used Mac for the same price would likely be far too old to run Xcode 7. Like Windows, Debian can run the tools to develop and sideload Android applications (source: AndroidTools).

Or I repurposed the PC that had previously been used for tasks other than mobile app development. In order to similarly repurpose a Mac, I would have had to build a time machine and given myself the money to cover the price difference between the Windows or GNU/Linux PC and a Mac with Windows. (And no, the Time Machine that comes with OS X doesn't count.)

The real sin is the decision of the foss community to pick a side, and in so doing, remove that choice from other people, by choosing to make systemd a hard requirement, solely for their own convenience.

Did you just try to make writing software to scratch your own itch sound like a bad thing? If Poettering wants to write systemd-only software, nobody's going to stop him. Nobody should be able to stop him. Nobody's going to force him to create or maintain SysV init scripts either. And if other projects find that depending on systemd is convenient, so can they. Open source is not a democracy. Developers do what developers want, regardless of what their users think and by users I mean everybody from other projects to distro packagers to system administrators to end users. The conflict was lost when systemd was voted in as the default, trying to bend the Debian system to force developers to preserve the old ways was a fool's errand. If it had passed, all that would have happened is that Debian would have lost them. Nobody can make that kind of committee decision stick.

I am a little suprised that someone with your UUID would have such a philosophy about the Debian project, but fair enough. I'd like to refer you to the Debian Manifesto, a document that was written when the Debian project was first founded. In particular, I'd like to refer you to section A.3:

thus, a distribution is created based on the needs and wants of the users rather than the needs and wants of the constructor.

, with "constructor" referring to the creator.

To be very clear, I am not advocating that Poettering shouldn't be programming what he pleases, nor that all work should be productive. However, I am saying that at least for the Debian project, the focus (used to be) on the users, and making a solid operating system useful to everyone. There's been a large resurgence in the "developers first" attitude the last couple years, and while it lends itself well to hobbyists, these kinds of people should not be working on a large and collaborative project with the goal of being useful to everyone - because, as you've made very clear, the center of that philosophy is all about your wants and needs, something which is directly contrary to the main goal of the Debian Project (and really, any large open source project whose goal is to be useful to more than the developers).

I'd install http://wiki.debian.org/iptable...

The "open source" drivers depend on nonfree binary blobs https://wiki.debian.org/AtiHow... and hence are not "free software" despite their code being free.