Every year or so, I get the urge to replace Xubuntu with Debian on my desktop and development systems. Sadly, it just doesn't make sense to do so. Ubuntu still has a few huge advantages over Debian. In particular:
Ubuntu's bug tracking system is far more convenient than Debian's, provides richer categorization and relation tools, and integrates with upstream trackers. I waste less time when I have to report problems, and since more people are sharing knowledge in launchpad, I also waste less time on diagnostics and fixes. Average users find it more approachable, too, and can often use it to find a workarounds for problems that they need solved before the next Debian release cycle crawls around.
Ubuntu's personal package archive system is both a public build farm and an open software repository. This means I can share custom software packages with others, with no bureaucratic overhead, on any release schedule I choose, through a channel that's extraordinarily easy for users to install, with integration into the standard system update process. Oh, and I don't have to set up build environments for multiple architectures (or in some cases, any build environment at all). Of course, all of this also benefits non-developers, by giving them access to a lot of software that isn't part of the Debian archive.
Last time I checked, Ubuntu still had far better support for certain important hardware components, like my graphics card. I'm an advanced user, so I could probably jump through the hoops to get proprietary drivers working in Debian, but most people don't have that kind of knowledge or the time/inclination to develop it. I wish there was a way around this by simply choosing different hardware, but there simply is no good substitute for certain proprietary devices. (Linux gamers can either use nVidia hardware with the closed driver, or be stuck with inferior performance.)
Despite Ubuntu making some dumb decisions and pissing me off at times, it honestly has done a lot to advance linux. I'd like to switch to Debian, but honestly, it would just make my life harder. I hope it catches up soon.
Git's user interface is the biggest counterproductive, nonintuitive, inconsistent, needlessly complex, user-hostile, pile of garbage that I can remember ever haunting my terminal, and I say this after having worked with sendmail config files. Sadly, Linus' name and GitHub's early momentum have propelled this blight on the face of modern software development into entrenchment.
Meanwhile, Mercurial has all the same power with practically none of the pain.
When I wondered how a tool as important as Git could go for so long with such glaring (but fixable) flaws, I found archived messages from Git maintainers who were not only too stubborn to learn from other projects, but also such obstructionists that they actually discouraged improvements. Nobody wants to donate their time in an environment like that. So much for, "it's open source; contribute a fix yourself." How very sad.
To expand on that, there are cases when a root exploit is preferable to a bootloader unlock. For example, when the official bootloader unlock procedure deletes all your applications and data, and permanently disables some of the features in your phone. (I'm looking at you, Sony.)
That bothers me too, but I'm starting to think that manufacturers are deliberately avoiding a read-only failure mode for security reasons: if your drive enters a permanent read-only state, how do you erase it before recycling? I imagine having used crypto from day 0 would be your only safeguard at that point, but even good crypto gets broken eventually, so how do you safeguard the data on that read-only drive in the long term? Is physical destruction the only answer?
On the other hand, maybe the total-failure mode that current SSDs enter is just a false sense of security. It's possible that the data on those chips is still available to someone who can bypass the controller. I don't have an easy way to check.
Thank goodness. It's embarrassing how long my desktop machines have had the habit of looking completely locked up whenever they're asked to copy a large file in the background. It's especially bad when a slow-ish NAS server is involved. I've tried the existing optional IO schedulers, and they don't fix the problem.
I self-host and encrypt where possible. For other things, I use providers as trustworthy as I can find.
Email privacy is a tough problem, but a solvable one. I'm working on a project that will give me gmail-like convenience without entrusting my data to Google, and might eventually grow automated/transparent encryption capabilities. It's going to be a while before it's usable, though; nobody is paying me to work on it, so it doesn't get enough of my time. (The mailpile project overlaps some of my goals in this area, and might be worth a look to anyone interested in the topic.)
A Facebook replacement is another tough one, perhaps even tougher than email, but I believe it's also solvable.
Please keep asking questions like this, and sharing what you discover. The more of us we have thinking about these problems, the more likely we are to work out their solutions.
The Commodore 64 had a nonstandard serial port, meaning that I couldn't connect my standard RS-232 modem directly to it. Being just a kid, I couldn't afford the $50 or so that an adapter would cost.
My solution: I borrowed a family friend's RS-232 adapter, opened it up, examined the components and circuit board traces, bought the parts from a local electronics shop, and built the same circuit with perfboard and wire wrap. I cut a slot in the back of my C64, mounted a DB-25 connector in it, wired it to my frankenboard, and stuffed the whole thing into the free space inside the computer.
It worked like a charm. I was the only kid I ever met whose C64 had a standard serial port on the back.
C++ gives a nice balance between high performance and relatively good safety.
Huh? Relative to what?
C++ was my primary language for quite a few years. I was very good at using it effectively while introducing far fewer bugs than most coders I encountered, but I would never call that language anything near safe.
Maybe you're talking about a subset of C++ that does not include things like pointers and arrays?
It looks too big and clunky to take significant market share
It's probably smaller than you think. It's shorter and narrower than all of the current "mini" and "compact" phones, and just slightly thicker than the tiniest qwerty smartphone I have ever seen. Here's a size comparison.
All it takes is the motivation, a group of likeminded individuals and the willpower to deliver a dist that does not use systemd. I expect most packages in the debian universe have no deps on systemd and therefore no work required to support those packages. So we're talking system packages, some daemons and maybe a few shims for edge cases.
You're implying that it would be easy. I'd like to think you're right. One group has already announced such a derivative. I'd love to see it succeed, but I'm not holding my breath. Maintaining a linux distribution as well as debian does, including timely security updates, package builds, downstream bug tracking, release management, and uniformity across so many installations as to form a vast support community, is a much bigger job than one might think. There's also the issue of various unrelated but popular packages developing dependencies on systemd, which means any such derivative distro would also be in the business of developing and maintaining forked versions of those packages; also not a trivial task. I guess we shall see.
As for why there are only 2 dists left not to have gone to systemd, perhaps that should serve as a clue in itself.
Many of them seem to be derivative distros that simply don't want to diverge from their upstream distribution's init system, so they have little choice. (Counting them as independent decision makers would be dishonest.) As for the upstream distros, I think it's more telling to note how very divided their communities were in the vote for/against systemd. A strong argument could be made that anything so integral to the core of an OS distribution should not be replaced with something so divisive to the community.
Speaking for myself, I'm a bit disappointed in the loudest factions of this disagreement. Most of what I see in these discussions is two mobs of people pushing for a decision *right now* (meaning this year, or next). The voices shouting "we need systemd!" or "we need nothing of the kind!" dominate the discussion, while a third option seems to have been forgotten: How about waiting until something can be developed that offers important core improvements over sysv init, but isn't as invasive as systemd? Most of us can obviously get by just fine with our existing init systems for a little longer; we've been doing it for years. The uproar over the topic is surely enough to motivate the development (or modification) of an init system that most of the community would find suitable. I'd love to see that happen.
In any case, I think the original question here has been answered.:)
This is where the exercise of free will kicks in. If you cannot contemplate learning something new, stick with what you have or choose a dist that chooses to do stuff the old way.
Thanks. You just provided yet another example of the same old fallacious argument. It completely ignores two important facts: The only alternative distributions left are either so anemic in their overall support that they would utterly fail as substitutes (debian's software archive is second to none) or are so different that a migration of any significant size would be unreasonably painful (let's see how long it takes you to migrate 50 machines to gentoo, let alone maintain it with 500 machines). Anyone who makes the argument you just made either has no grasp of the real-world issues, or is being disingenuous.
Re:Why do people dislike systemd so much?
on
GNU Hurd 0.6 Released
·
· Score: 3, Informative
The reasons for disliking it vary, but there is at least one common thread among those who are upset about it: Systemd is being shoved down their throats, in that several of the most widely used, widely loved, deeply entrenched linux distributions have announced that they are adopting it. Many people who use those distributions do so for very good reasons, and since there are no equivalent alternatives, these people are being forced to either accept systemd (which will cause them unwanted trouble) or migrate to an inferior distribution (which will also cause them unwanted trouble). That kind of thing is enough to piss anyone off.
Slashdot Mirror
Why the hell Californians keep electing her I'll never understand.
Do you think it might have something to do with the influence of money in US elections? ;)
I get the impression that you think iOS (or OSX for that matter) has more BSD inside than it actually has.
Every year or so, I get the urge to replace Xubuntu with Debian on my desktop and development systems. Sadly, it just doesn't make sense to do so. Ubuntu still has a few huge advantages over Debian. In particular:
Ubuntu's bug tracking system is far more convenient than Debian's, provides richer categorization and relation tools, and integrates with upstream trackers. I waste less time when I have to report problems, and since more people are sharing knowledge in launchpad, I also waste less time on diagnostics and fixes. Average users find it more approachable, too, and can often use it to find a workarounds for problems that they need solved before the next Debian release cycle crawls around.
Ubuntu's personal package archive system is both a public build farm and an open software repository. This means I can share custom software packages with others, with no bureaucratic overhead, on any release schedule I choose, through a channel that's extraordinarily easy for users to install, with integration into the standard system update process. Oh, and I don't have to set up build environments for multiple architectures (or in some cases, any build environment at all). Of course, all of this also benefits non-developers, by giving them access to a lot of software that isn't part of the Debian archive.
Last time I checked, Ubuntu still had far better support for certain important hardware components, like my graphics card. I'm an advanced user, so I could probably jump through the hoops to get proprietary drivers working in Debian, but most people don't have that kind of knowledge or the time/inclination to develop it. I wish there was a way around this by simply choosing different hardware, but there simply is no good substitute for certain proprietary devices. (Linux gamers can either use nVidia hardware with the closed driver, or be stuck with inferior performance.)
Despite Ubuntu making some dumb decisions and pissing me off at times, it honestly has done a lot to advance linux. I'd like to switch to Debian, but honestly, it would just make my life harder. I hope it catches up soon.
Obligatory link to the BadUSB project, including proof-of-concept:
https://srlabs.de/badusb/
Git's user interface is the biggest counterproductive, nonintuitive, inconsistent, needlessly complex, user-hostile, pile of garbage that I can remember ever haunting my terminal, and I say this after having worked with sendmail config files. Sadly, Linus' name and GitHub's early momentum have propelled this blight on the face of modern software development into entrenchment.
Meanwhile, Mercurial has all the same power with practically none of the pain.
When I wondered how a tool as important as Git could go for so long with such glaring (but fixable) flaws, I found archived messages from Git maintainers who were not only too stubborn to learn from other projects, but also such obstructionists that they actually discouraged improvements. Nobody wants to donate their time in an environment like that. So much for, "it's open source; contribute a fix yourself." How very sad.
Apparently, plan to release a linux port after they fix some things.
Reference:
https://steamcommunity.com/app...
To expand on that, there are cases when a root exploit is preferable to a bootloader unlock. For example, when the official bootloader unlock procedure deletes all your applications and data, and permanently disables some of the features in your phone. (I'm looking at you, Sony.)
That bothers me too, but I'm starting to think that manufacturers are deliberately avoiding a read-only failure mode for security reasons: if your drive enters a permanent read-only state, how do you erase it before recycling? I imagine having used crypto from day 0 would be your only safeguard at that point, but even good crypto gets broken eventually, so how do you safeguard the data on that read-only drive in the long term? Is physical destruction the only answer?
On the other hand, maybe the total-failure mode that current SSDs enter is just a false sense of security. It's possible that the data on those chips is still available to someone who can bypass the controller. I don't have an easy way to check.
Thank goodness. It's embarrassing how long my desktop machines have had the habit of looking completely locked up whenever they're asked to copy a large file in the background. It's especially bad when a slow-ish NAS server is involved. I've tried the existing optional IO schedulers, and they don't fix the problem.
I self-host and encrypt where possible. For other things, I use providers as trustworthy as I can find.
Email privacy is a tough problem, but a solvable one. I'm working on a project that will give me gmail-like convenience without entrusting my data to Google, and might eventually grow automated/transparent encryption capabilities. It's going to be a while before it's usable, though; nobody is paying me to work on it, so it doesn't get enough of my time. (The mailpile project overlaps some of my goals in this area, and might be worth a look to anyone interested in the topic.)
A Facebook replacement is another tough one, perhaps even tougher than email, but I believe it's also solvable.
Please keep asking questions like this, and sharing what you discover. The more of us we have thinking about these problems, the more likely we are to work out their solutions.
Have you tried AquaMail? I haven't used it on a tablet, but it's pretty nice on a phone.
I'm think you must mean Geany. It's one of the best lightweight programmer's editors I've ever used.
Does Audacious do what you need? That's what I used to replace foobar2000 when I dumped Windows.
You had me until you said you plan to use Google+. Bye bye.
As an adult, I don't know that I'd exactly call this a hardware hack, but teenage me definitely thought it was unusual. :P
The Commodore 64 had a nonstandard serial port, meaning that I couldn't connect my standard RS-232 modem directly to it. Being just a kid, I couldn't afford the $50 or so that an adapter would cost.
My solution: I borrowed a family friend's RS-232 adapter, opened it up, examined the components and circuit board traces, bought the parts from a local electronics shop, and built the same circuit with perfboard and wire wrap. I cut a slot in the back of my C64, mounted a DB-25 connector in it, wired it to my frankenboard, and stuffed the whole thing into the free space inside the computer.
It worked like a charm. I was the only kid I ever met whose C64 had a standard serial port on the back.
I see. You were indeed talking about a subset of C++. Thanks for clearing that up.
C++ gives a nice balance between high performance and relatively good safety.
Huh? Relative to what?
C++ was my primary language for quite a few years. I was very good at using it effectively while introducing far fewer bugs than most coders I encountered, but I would never call that language anything near safe.
Maybe you're talking about a subset of C++ that does not include things like pointers and arrays?
I've already dumped Adblock Plus and moved on to uBlock Origin, which I trust a bit more to do the right thing.
Thank you for that link. I love them already.
It looks too big and clunky to take significant market share
It's probably smaller than you think. It's shorter and narrower than all of the current "mini" and "compact" phones, and just slightly thicker than the tiniest qwerty smartphone I have ever seen. Here's a size comparison.
Thanks, Poettering. :(
All it takes is the motivation, a group of likeminded individuals and the willpower to deliver a dist that does not use systemd. I expect most packages in the debian universe have no deps on systemd and therefore no work required to support those packages. So we're talking system packages, some daemons and maybe a few shims for edge cases.
You're implying that it would be easy. I'd like to think you're right. One group has already announced such a derivative. I'd love to see it succeed, but I'm not holding my breath. Maintaining a linux distribution as well as debian does, including timely security updates, package builds, downstream bug tracking, release management, and uniformity across so many installations as to form a vast support community, is a much bigger job than one might think. There's also the issue of various unrelated but popular packages developing dependencies on systemd, which means any such derivative distro would also be in the business of developing and maintaining forked versions of those packages; also not a trivial task. I guess we shall see.
As for why there are only 2 dists left not to have gone to systemd, perhaps that should serve as a clue in itself.
Many of them seem to be derivative distros that simply don't want to diverge from their upstream distribution's init system, so they have little choice. (Counting them as independent decision makers would be dishonest.) As for the upstream distros, I think it's more telling to note how very divided their communities were in the vote for/against systemd. A strong argument could be made that anything so integral to the core of an OS distribution should not be replaced with something so divisive to the community.
Speaking for myself, I'm a bit disappointed in the loudest factions of this disagreement. Most of what I see in these discussions is two mobs of people pushing for a decision *right now* (meaning this year, or next). The voices shouting "we need systemd!" or "we need nothing of the kind!" dominate the discussion, while a third option seems to have been forgotten: How about waiting until something can be developed that offers important core improvements over sysv init, but isn't as invasive as systemd? Most of us can obviously get by just fine with our existing init systems for a little longer; we've been doing it for years. The uproar over the topic is surely enough to motivate the development (or modification) of an init system that most of the community would find suitable. I'd love to see that happen.
In any case, I think the original question here has been answered. :)
This is where the exercise of free will kicks in. If you cannot contemplate learning something new, stick with what you have or choose a dist that chooses to do stuff the old way.
Thanks. You just provided yet another example of the same old fallacious argument. It completely ignores two important facts: The only alternative distributions left are either so anemic in their overall support that they would utterly fail as substitutes (debian's software archive is second to none) or are so different that a migration of any significant size would be unreasonably painful (let's see how long it takes you to migrate 50 machines to gentoo, let alone maintain it with 500 machines). Anyone who makes the argument you just made either has no grasp of the real-world issues, or is being disingenuous.
The reasons for disliking it vary, but there is at least one common thread among those who are upset about it: Systemd is being shoved down their throats, in that several of the most widely used, widely loved, deeply entrenched linux distributions have announced that they are adopting it. Many people who use those distributions do so for very good reasons, and since there are no equivalent alternatives, these people are being forced to either accept systemd (which will cause them unwanted trouble) or migrate to an inferior distribution (which will also cause them unwanted trouble). That kind of thing is enough to piss anyone off.