Systemd-Free Devuan Announces Its First Stable Release Candidate 'Jessie' 1.0.0 (devuan.org) 372
Long-time reader jaromil writes: Devuan 1.0.0-RC is announced, following its beta 2 release last year. The Debian fork that spawned over systemd controversy is reaching stability and plans long-term support. Devuan deploys an innovative continuous integration setup: with fallback on Debian packages, it overlays its own modifications and then uses the merged source repository to ship images for 11 ARM targets, a desktop and minimal live, vagrant and qemu virtual machines and the classic installer isos. The release announcement contains several links to projects that have already adopted this distribution as a base OS.
"Dear Init Freedom Lovers," begins the announcement, "Once again the Veteran Unix Admins salute you!" It points out that Devuan "can be adopted as a flawless upgrade path from both Debian Wheezy and Jessie. This is a main goal for the Devuan Jessie stable release and has proven to be a very stable operation every time it has been performed. "
"Dear Init Freedom Lovers," begins the announcement, "Once again the Veteran Unix Admins salute you!" It points out that Devuan "can be adopted as a flawless upgrade path from both Debian Wheezy and Jessie. This is a main goal for the Devuan Jessie stable release and has proven to be a very stable operation every time it has been performed. "
Systemd! (Score:5, Insightful)
There are people who write startup scripts for Linux, and they tend to have a stronger opinion, because it affects them more directly. Some really like systemd, some really don't. Some (like Patrick Volkerding) are fairly neutral about the whole thing but see no pressing need to switch.
Then there are people who are system designers, who are ok with systemd as an init system, but see it as horrid when it's a platform for building an entire OS. As long as it stays as an init program, it's fine because it can be swapped out easily. But if it starts becoming a required component for turning up the volume, that is clearly a sign of poor design.
Re:Systemd! (Score:5, Interesting)
I only care when I have to debug my more custom setups. Then I really hate systemd, as well as dbus. I would be surprised if anyone "really liked" it, except the original author. Most people are like "whatever, I just want X and pulseaudio to start". I, as a system developer, have built products around systemd because the product architect insisted on it. I was like "whatever, your funeral".
All my authoritative DNS servers are running custom builds (not BIND) and require custom start-up scripts for the chroot and health monitoring.
Re: (Score:3, Insightful)
Re: (Score:3)
Sounds great. I did manage to trim 200K of ram usage in an embedded system (no swap!) by tearing systemd out.
Systemd is way more modular though, and it has a lot of benefits for a desktop environment and for distro maintainers. But if you system doesn't want dbus, pulseaudio and those sort of things, it probably also doesn't want systemd. And if you are using pulseaudio and dbus, then the framework that Systemd presents might be something you want. I don't have any use for Systemd or dbus or other desktop o
Re: (Score:2)
Surprisingly, servers are a good fit for systemd - a lot of modern devices and services come and go asynchronously, so writing reliable initscripts without something like systemd is not easy.
Re:Systemd! (Score:5, Insightful)
No, he is not. Of course, to systemd-apologists it will look at it that way, because they do not think users have the right to do their own simple init-scripts. But to actual UNIX users writing their own init-scripts is nothing special.
Re: (Score:3)
If you think that then you've never used systemd and not read the manual either
I didn't want to read your damn manual. I had a init system-- it never gave lip and I could customize it when I wanted to. Now my Debian systems have systemd and I've spent too much time reading the damn manual for a program that ostensibly solves problems I never had. I for one welcome our new Devuan overlords.
Re: (Score:2)
I've written 3 init systems in my career, including one in awk (!). But in this particular case I'm using a modified version of sysvinit and the custom bits are the scripts and directory structure for them.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
All I know is on a completely idle box systemd is the top resource hog. Why is this "startup shceduler" even consuming resources?
Re: (Score:2)
Re:Systemd! (Score:5, Interesting)
Most Linux users don't have a strong opinion on systemd either way,
Maybe not on slashdot, but you will probably find that people over at soylentnews [soylentnews.org] have a different opinion. The systemd issue was a contributing factor to the creation of soylentnews.
Re: (Score:2, Insightful)
Wow, just checked an idle CentoOS 7 server we have that we aren't using yet:
/usr/lib/systemd/systemd --switched-root --system --deserialize 20
root 1 0.0 0.0 46168 4940 ? Ss Mar14 254:19
How has it used over four hours of CPU time in less than eight days? It's has a Xeon E5-2689 CPU, so it's one of the fastest Intel CPUs available.
Extra text to get rid of the ridiculous "Filter error: Please use less whitespace." I still need to add more text. This filter is a pain. I know what I'm talking about. Please
Re: (Score:2)
As long as it stays as an init program, it's fine because it can be swapped out easily. But if it starts becoming a required component for turning up the volume, that is clearly a sign of poor design.
Well it has to talk to something. I mean we had applications that used to talk directly to the hardware back in the DOS days, this application can talk to Soundblaster and Gravis Ultrasound, I don't want to go back there. So you want to fix it a bit on the hardware side so all the apps can talk to one interface and it'll play on all sound cards. And you want to fix it on the software side so more than one application can play sound at the same time.
And then the ball starts rolling, does it have a hardware m
Re:Systemd! (Score:5, Insightful)
Re:Systemd! (Score:4, Insightful)
In Linux, that's called ALSA.
Re:Systemd! (Score:5, Insightful)
The problem here is that the systemd-people are trying an MS-like strategy to make it impossible to swap it out: They try to replace everything else they can get their hands on and they try to sabotage whatever else they can so it does not run without systemd anymore. If these were decent people and they were just providing an alternate init-system, I would have absolutely not problem with this and just ignore it. But this embrace-extend-extinguish approach is utterly evil and marks this as a hostile takeover that will benefit nobody. There are not even any good technical reasons for this. I can only guess that they want their stuff to be the one true "does everything" because of pure ego.
Re:Systemd! (Score:4, Interesting)
Comment removed (Score:5, Interesting)
Re: (Score:2)
Like PulseAudio and NetworkManager there's places where it makes sense and others where it should just be torn out.
Re: (Score:2)
Here's a nickel kid. Go buy yourself a real server
He doesn't. Stop drinking the Kool-Aid and depending on secondary sources. Go read the actual bugreports and discussion.
Re: (Score:3)
He doesn't care if he breaks stuff in server space and RedHat are not reining him in as much as they should.
Re: (Score:2)
Re:Systemd! (Score:4, Informative)
Yes ... but systemd is a 'happy path' only. .. CD drive died (no big, wasn't being used for anything) but systemd managed to fubar the whole f'ing system. Fallback to upstart worked fine.
When something goes wrong then the thing just shits all over itself. Just like everything else pottering has ever touched,
Just went through the shit this weekend
Other stuff that is a major PITA with systemd: OpenVPN. Whenever I change my .conf file I have to update systemd with some whacky config because it 'caches' my config file in it's own little world. WTF is that about? Dunno but it's enough of a pain that I'll be jumping to the debian boxen to devuan and tossing the ubuntu for the same reason.
Let CentOS / RHEL 7 deal with all the SystemD crap .. when it's actually decent (after pottering gets bored and real developer fixes all his shit) then maybe it will be the init system that it is being touted as.
Re: Systemd! (Score:5, Interesting)
Re: (Score:3)
I just installed a couple of days ago and have been tracking updates and I don't see why it wouldn't be a suitable replacement for Debian. The only thing I've had a problem with so far was getting nvidia drivers working, that was a bit of work and then they didn't work correctly. However I'm using a picopsu kind of near to its design specs, and I might be overloading its 12v or 5v output.
Re: (Score:2)
AMD driver support is and always has been a PITA. This continues to be true, although many people say that it is becoming less true. Meanwhile, nVidia Linux driver support is more of a PITA than it was back in the olden days, so there's really nothing to be happy about unless you're an intel fan.
Re: (Score:3, Insightful)
Why? When you can use an init that is not created by an asses/dummies. You just create more work when you have that attitude. Many people can fix anything; but why when they can get something that's functional and proven out-of-the-box.
I'm not a programmer; just a user. But I can see when my system/demon goes down because of sysd.
Turn sysd over to someone whom can write/think/implement good/safe/stable code. Someone without a power ego. Then I might take it as an alt Init. Someone who can show good reasons
Re: (Score:3)
Oddly enough, yes in a sense. Every refusal to acknowledge a shortcoming, every NIH, every not-a-bug is reflected in the source.
Re: (Score:2)
Since not-a-bug means you don't even work on it how is it reflected in the source?
By that logic SIDS is also reflected in your code, since generally you can't write code if you're dead.
Re: (Score:2)
Because it IS a bug, but by stamping it not-a-bug, it remains in the source.
Re: (Score:2)
Says who?
Re: (Score:2)
That's being a crap coder. It's nothing directly related to attitude. I've met developers who were helpful to the point of obsequiousness but who couldn't code for shit.
Fucking hell, don't they teach ignoratio elenchi these days?
Re: (Score:2)
Yeah, you really are a fucking coward, aren't you? Quickly checking that box so you can sockpuppet your own thread.
As has been pointed out to you multiple times: Lennart was right, and Linus agrees. Using the overall debug variable was the correct way to go about it, and the real bug in systemd (overly verbose assertions) was acknowledged and fixed.
Re: (Score:2)
I'm surprised anyone with any experience of reading would question whether a person's attitudes are embedded in their handwriting: of course they are! It's impossible to escape this.
Re: Systemd! (Score:4, Insightful)
Writing code is a creative process. Obviously creator's attitudes infuse the creations.
Comparison to handwriting is a poor one, if somewhat evocative. It's more like writer's style.
Some creators adopt YAGNI [wikipedia.org] philosophy, writing code that is simple, easy to understand, but doesn't suggest any expansion paths, and can turn to spaghetti if the expansions are managed. Some reinvent every wheel, writing every function themselves, others take the "golden hammer" to the extreme and create a dependency hell, trying to create a small centralized core that does everything using library functions. Some create rigid user interface following optimal use cases (actual or mistakenly imagined), others take customizability to the extreme, making the interface unusable mess until you take half an hour to configure it and remove all the crap you don't need. Some make programs that do only what says on the box and nothing more, others create APIs or operating systems disguised as applications.
Systemd started as a very simple, neat idea:
- create an alternative for initV that parallelizes startup of services;
- to speed up startup more, not to delay startup of services waiting until other services initialized, provide socket management, creating sockets "customer" programs would wait for, then bind them to their standard "providers" once they started up.
- do away with rigid sequence, instead manage startup as a set of dependencies to reach a certain state.
The idea was very sound and nice. Except it didn't end there.
- Some services needed these sockets actually working and not just present. So let's replace the provider and create own replacement as a part of systemd! And screw well established strategy, we're rewriting it our way! Here, take the binary log files!
- Some services didn't really work with the "dependency tree" strategy, since ancient times written as sequences of operations. These couldn't be easily parallelized. So screw your firewall, have ours!
- Some services used alternate communication methods that sockets. Kill them off, replace with systemd functions!
- Some of them would centralize startup of other services as needed. But that's our job! Die, inetd with your easy config!
And even if each "motion" by itself had a valid justification, the replacements offered by systemd are sub-par. Primarily because systemd developers don't believe in simple, straightforward, easy configurations. It's their attitude rubbing off.
A decent system does offer a lot of flexibility, with all kinds of obscure options, but it primarily offers sensible defaults for every obscure option, so you can get your basic work done in 2-3 lines, and if that's not sufficient, you will find what more can and needs to be done, never forcing you to state the obvious. Systemd though doesn't. You need to alliterate every little thing you want it to do, because the defaults just aren't there. And with some of its demands being quite obscure, it's often hard to find *what* the defaults should be. "Why should we make it easy if we can make it hard? If nobody ever has to write all these little details, they'll never know we had to work to implement handling them!"
Re: (Score:2)
History repeats itself. FDR once said that you can't code your way out of a problem you designed yourself into. Churchill replied that he didn't design it, that kraut bastard did.
Re: (Score:3)
Re:Systemd! (Score:4, Interesting)
Actually, Linux does reflect the personality of Linus. It's a precisionist and a correction freak. And the error messages can be a bit abusive. Fortunately, few people directly interact with the kernel, and for the kernel those are benefits. Even the error messages, because they are short, pithy, and relatively predictable.
The problem is when you say "asshole" you are painting with a broad brush that includes many different characteristics, some of which would be damaging and others of which are beneficial. Linux happens to be generally beneficial in his position. I wouldn't want him writing user interfaces. And I'd be dubious about him writing end-user documentation.
Re: (Score:3)
Most people think Linus Torvalds is an A-hole. Should we be wary of Linux now?
He is just less of an A-hole than Gates or Jobs was.
Re: Systemd! (Score:2)
Re: (Score:2)
Unfortunately Ian Murdock has departed this life.
Re: (Score:2)
Re: (Score:3)
A better name (Score:2)
Feduan? (Score:2)
Why am I denied choice ? (Score:2)
Wasn't Open/Free/whatever software about choice ?
I can understand that systemd brings some improvements.
In specific contexts.
For example, when your profession is sysadmin, when you have more than, let's say 4 or 5 servers to administrate, OK, may be systemd brings improvements over scripts. Real sysadmins are responsible of dozens, hundreds of servers.
What about other people like me ? I'm in computer programming since 1982, very well, but I'm no sysadmin.
A very kind friend told me once that, as a programmer
Re: (Score:3, Insightful)
"If it is not broken, do not fix it." That and KISS is something the systemd-team is too stupid, too inexperienced and too arrogant to understand. Or they are just riding over it because they believe they are god's gift to Linux. They are not. They are a force of destruction, exactly because they fight choice, compatibility, simplicity and reliability. Sure, in some situations their approach may make sense, but that means systemd should be a specialized init-system (and nothing else) for specific situations
Jessie + Wheezy (Score:2)
Jessie + Wheezy = Jizzy.
What about Stretch and Performance? (Score:2)
Re:Finally (Score:5, Insightful)
"This was the whole point of open source. If something is wanted then it is usually developed. If it doesn't work for some reason, support the guys who are trying to make it work rather than bitching that someone moved your cheese."
Except it wasn't wanted, and many people feel like it was rammed down their throats. It's not that it does or doesn't work (sometimes it does, sometimes it causes trouble). It's that open source is not about 'supporting the guys' who are making something you don't want, and who are making it more and more difficult to opt out.
Re:Finally (Score:5, Informative)
Personally, I am still trying to figure out what real problem it solves.
Every claim for systemd seems to be that it solves things that are simply not real issues.
Anyone?
The one real problem it seems to solve is: how does RedHat become the company that controls the architecture of all Linux distros.
Re:Finally (Score:5, Interesting)
Real world example:
https://www.digitalocean.com/c... [digitalocean.com]
This howto tells you to disable firewalld and enable the iptables service because it is easier to set up.
Re: (Score:2, Interesting)
Nice example, but I've noticed the guys working for me just can't grasp the concept of this:
systemctl start openvpn@server.service
The @ sign? server? .service? You can't use tab completion to find the name of the service like you can with /etc/init.d/something. Plus, it's confusing that Poettering decided to call the system systemd while the command name is systemctl. We use four different Linux distributions and six other UNIXes, so that small inconsistency turns into a big thing.
Re: (Score:2)
machine:/home/sd # systemctl start openvpn-hit tab-
openvpn@ openvpn.target
machine:/home/sd # systemctl start openvpn
Re: (Score:2)
Wow, your "real world example" for "what does systemd solve" is literally a webpage that shows you how to disable the systemd built in firewalld and use the old iptables way of doing things. I think you might have given an ideal example of how most people deal with systemd and its ever growing host of half-baked replacements for established tools: Route around it whenever possible.
Re:Finally (Score:5, Interesting)
> solves things that are simply not real issues.
I've managed UNIX servers for over thirty years, and systemd config files are a hell of a lot easier to manage than complicated shell scripts. I now manage servers with Puppet scripts, and the first time I added a custom systemd start-up daemon, I thought I was doing something wrong since it was so simple. It just worked.
The real problem with systemd is that Poettering has no experience managing servers so he just doesn't grok the importance of logging. Several times most months, I have a problem that would be trivial to fix if systemd didn't swallow the log message. We leave SELinux enabled on servers so we often make mistakes that break things, and systemd makes it hard as hell sometimes to troubleshoot. We often have to resort to using strace and looking through thousands and thousands of lines of output to try to find the problem that would have only taken a simple "tail /var/log/messages" pre-systemd.
Re: (Score:2)
Re: (Score:2)
If systemd is eating your log outputs maybe you should configure systemd properly. One thing systemd provides is more logging earlier and more consistently than the previous methods. But if you really need the old syslog, well systemd can output to that too.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Badly-written code is badly-written code.
Yes, the service files may be easier to write, but how many people actually write init scripts?
Re: (Score:2)
And by the way, your argument is self-defeating. If you don't need to write init scripts then why do you care about systemd?
Re: (Score:2, Informative)
Re: (Score:3)
It wasn't a free choice. The fact that Gnome3 requires systemd was a significant influence.
Re:Finally (Score:5, Informative)
It wasn't a free choice. The fact that Gnome3 requires systemd was a significant influence.
The choice was made long before any mention of the fictitious Gnome dependency on systemd. It IS ficticious by the way. Gnome has a dependency on one thing: something that provides a DBUS API. systemd-logind is now shipping on many systems so it made sense for Gnome to use it. Notice however Gnome is still available for all non-systemd systems, and BSD, and simply reverts to using gnome-session instead of systemd-logind. The whole dependency thing was just another out of control rage induced verbal vomit out of the echo chamber.
Re: (Score:2)
Re: (Score:2, Insightful)
Personally, I am still trying to figure out what real problem it solves.
Here's one: sysvinit is unable to manage services.
You don't see the short comings of sysvinit? The people who work with linux do. The people who create distributions do. Upstart, openrc, smf, ... systemd is just the latest and most successful in a long history of the attempts to address the many shortcomings of sysvinit. Hell Apple decided to use Unix as the core basis for their OS, what's the first thing they do? Launchd, a replacement for the dumb init system, and dumb is the only way to describe sysvinit
Re:Finally (Score:5, Insightful)
Many of those issues did not require something so intrusive as systemd to solve. OpenRC solves most of them.
Yes, the init.d files are long, but so what? Most users never look at these files, let alone edit them and even for the creators of the files, they are rarely changed.
Most of the int.d scripts on my Gentoo system are less than 100 lines, with a lot of them 20-30 lines.
Re: (Score:2, Informative)
Many of those issues did not require something so intrusive as systemd to solve.
I only gave you one example. systemd is intrusive due to the very large scope of it's functionality and what it provides. This is also why it won technical challenges when various distributions adopted it.
Yes, the init.d files are long, but so what? Most users never look at these files
Users? It wasn't the users crying. Except for when it didn't work and you had to pour through 100 lines trying to figure out why you can run Apache on the command line but it fails to start by script (about the typical problem users experience). No what systemd provides is a far simpler interface for devel
Re: (Score:2)
Personally, I am still trying to figure out what real problem it solves.
I see systemd as the perfect compliment to Linux cgroups. It makes managing containers a lot better than how say docker does things. But if you like docker or systemd, I think we can all agree that the way containers are done now, versus sysvinit + chroot methods, is vastly better. However, if sticking with the old sysv stuff helps anyone sleep, then go for it. However, I remember doing the whole httpd inside a chroot and remember the headache it caused if one of your boxes out of a 100 was hung up and
Re: (Score:2)
Re: (Score:2)
so yes that is one of the points of open source, if you don't like it, fork it and/or make your own.
Re: (Score:3, Insightful)
What technical ground? Was there a vote or consensus reached? Redhat switched because they are Redhat and everyone else said sure whatever. If anyone wanted a new feature for systemd Poettering shit out some code overnight and they were happy. This is like claiming McDonald's is the best restaurant because they sold the most hamburgers last year. What is the deal with binary logs? I know AIX has them but why Linux? What's next, all the config files are stored in a flat binary database? Brilliant!
Re:Finally (Score:5, Informative)
Oh, and had there ever been a vote for sysv-init?
Re: (Score:3)
Which organisation is the 400 lb gorilla when it comes to Linux development?
You can follow them and have an easy life. Or you can spend it on the treadmill constantly trying to peel out the shit you don't want, while they're adding it ten times as fast.
Re:Finally (Score:5, Insightful)
I don't know about the other distros, but it's almost silly to call what Debian did a "vote." It was a 2-2 tie and was over-ruled to force a pro systemd outcome. Considering how many people develop for and use Debian and that systemd was decided based on 2 or 3 people, it's hardly worth calling it a vote.
I've used systemd about 4 years or so now (mostly from Arch). It definitely has some pros, but the thing I don't like is Pottering himself. You should see some of the YouTube videos of him where he was pointed out to be wrong and instead of talking about the technical merits of the suggestion, he attacks the man. I've read a decent amount of his writing segments on posts and things and I will admit, he is smart, but he is seriously incapable of admitting when he is wrong.
When systemd was first being developed a lot of the bug reports were around problems with system crashes that resulted in corrupted and unreadable binary logs. They were all closed as WON'T FIX and some basically said "it's your problem."
systemd unit files, I will admit, are nice and clean. But if you actually look into the code and the systemd-itself unit files and dependencies it's really a nightmare waiting to happen. I think that's one of the biggest problems. A lot of the people commenting about systemd have only used it at the surface level. It would be like buying a used car that looks nice on the outside but never looking at the engine and realizing it's all duct-taped together.
Re: (Score:2)
What technical ground?
The discussion and the reasons for making the change were made public. Go read up on them.
Was there a vote or consensus reached?
Yes there was.
This is like claiming McDonald's is the best restaurant because they sold the most hamburgers last year.
Actually it's more like claiming McDonalds is the most suitable restaurant to feed people because it's the most convienient and fastest way to get food. They are called technical benefits. Systemd has many numerous of them. As does upstart, openrc, launchd, SMF, and all those other projects all launched to address the many short comings of sysvinit.
What is the deal with binary logs?
What's not the deal with them? It's a design choice. You
Re: (Score:2)
You failed to tell us that reason.
IMHO it's fine for desktops where fuckups only result in one person being unable to work but it's still very problematic for servers. I've still go a pile of stuff on CentOS6 because some commercial software vendors haven't figured out how to get their stuff to work reliably with Poettering's stuff.
Re: (Score:2)
You failed to tell us that reason.
I am not your mother. The justification for the use of systemd in Debian was published by the core dev team and was many pages long. Go look it up yourself.
But you won't.
but it's still very problematic for servers
Half the justification came from servers. Something about actually being able to monitor the status of processes rather than blindly firing off one and never knowing if it continues to run. Heck many of the design features of systemd was built with servers in mind, such as reporting process failure combined with an adjustable attempted rest
Re: (Score:3)
There are still a lot of servers around the world stuck on RHEL6 and CentOS6 - the slow software vendor that is messing me about is not alone. People are having trouble with the change, you may dismiss them as idiots but
Re: (Score:2)
You'll feel better when you find the reasons rather than rely on ignorant crap from trolls
Re: (Score:3)
I've got it on a few desktop systems, test machines and my home PC. I've seen it hang when it shouldn't (one USB mouse stopped it dead half way every time - so much for parallel init) and had all kinds of trouble trying to work out what is wrong on others due to the very poor logging behavior (which may get fixed some time, but not yet). I've been though plenty of documentation, bug reports and Lennart's smug blog about linux do
Re: (Score:2)
Re:Finally (Score:5, Insightful)
What is the deal with binary logs? I know AIX has them but why Linux? What's next, all the config files are stored in a flat binary database? Brilliant!
This sounds like a great idea. I propose we call it The Registry. We can even make tools to convert the binary into an almost-human-readable format. It will be glorious.
Re: (Score:2)
Re: (Score:2)
Re:Finally (Score:5, Insightful)
If it was designed properly we wouldn't have to go to another distro.
It's like saying if you don't like the radio go buy a different car.
Re: (Score:2)
The radio is one of the things I look at when choosing a car, and I have decided not to buy a car based on the features and functionality provided by the radio.
You can usually install another radio into a car, FWIW. You don't need to get a completely new car.
Re: (Score:2)
You can usually install another radio into a car, FWIW. You don't need to get a completely new car.
You can always install another radio into a car. But it might not integrate with any of the things in the car, and it might not even fit into the dash these days.
Re: (Score:2)
You can usually install another radio into a car, FWIW. You don't need to get a completely new car.
You can always install another radio into a car. But it might not integrate with any of the things in the car, and it might not even fit into the dash these days.
There are adapters for all that fancy shiz that you'd probably actually care about. Just go to crutchfield and check for yourself. All those stereos integrate with the CANBUS these days (which is really stupid to do from a security standpoint, BTW), and there are adapters which allow after market devices to communicate on the bus.
Re: (Score:2)
You can usually install another radio into a car, FWIW. You don't need to get a completely new car.
Do you still drive a car from the 90s? You would lose a lot of functionality in a modern car by attempting to replace the radio system. Shit my car is 14 years old and the radio is a headless box that provides power in, audio out, and a wiring loom to the CANbus that integrates with the dash, steering buttons, console display, central buttons, GPS system, etc.
Re: (Score:2)
Do you still drive a car from the 90s? You would lose a lot of functionality in a modern car by attempting to replace the radio system.
haha yeah, actually. I should get my knowledge updated.
Re: (Score:2)
You can usually install another radio into a car, FWIW. You don't need to get a completely new car.
Do you still drive a car from the 90s? You would lose a lot of functionality in a modern car by attempting to replace the radio system. Shit my car is 14 years old and the radio is a headless box that provides power in, audio out, and a wiring loom to the CANbus that integrates with the dash, steering buttons, console display, central buttons, GPS system, etc.
You do realize that there are CANBUS adapters for every single car on the market, right? At least, the ones in the US market. Plus who the hell wants their car stereo communicating with the other devices on the CANBUS? That's just poor security right there just so that you can do things like turn the stereo off when the car is off and the door opens.
Re: (Score:2)
Have you been to any car dealers in the last 10 years?
No actually haha. I should update my knowledge.
Re: (Score:2)
These kids need to miss a few meals in their life and then maybe they will get some perspective.
No they won't, they'll protest until they get their meals.
Re: Finally (Score:2)
LOL
Re: (Score:2, Informative)
apt-get install upstart-sysv; update-initramfs -u
upstart-sys is not available anymore (*buntu 17.04)
Re:Excellent (Score:4, Insightful)
You can choose your own web server ; nobody forces Apache upon you ; likewise you can choose your DHCP software, or your DNS server ; in pretty much any solution you can choose alternatives; gosh nowadays you can even chose in Debian between Linux and a FreeBSD kernel....so why not an easy choice between systemd and other competing systems that were already implemented for decades.
As I said, the indignation of most people is that Debian and developers went out of their way to impose systemd to everybody, as if there is some ulterior motive for it. (NSA backdoors is an interesting conspiration theory).
The fact that most of the systemd proponents seem to inconveniently ignore that nobody likes to be sodomized, it yet another monumental damning thing. Why for instance, why in a thread about Devuan, about choice, there will be idiots whining that they do not understand the systemd "hate"...the fact is they do not accept nor phantom that in open source there can be a choice.
The choice for me is clearly *BSD...thanks for all those years and for betraying us, Debian.
So long, and good luck.