Slashdot Mirror
SCO vs. IBM Battle Over Linux May Finally Be Over (networkworld.com)
JG0LD writes with this news from Network World: A breach-of-contract and copyright lawsuit filed nearly 13 years ago by a successor company to business Linux vendor Caldera International against IBM may be drawing to a close at last, after a U.S. District Court judge issued an order in favor of the latter company earlier this week.
Here's the decision itself (PDF). Also at The Register.
Here's the decision itself (PDF). Also at The Register.
Burn the remnants of SCO and then stir the ashes.
Somewhere buried in all of this was an opportunity for Netcraft to finally be right about something. Maybe that story has yet to surface, and will appear all in due course in tomorrow's feed bag.
PJ is toasting yet again.
Maybe in another couple years' time, she'll have another decision to toast some more!
Chas - The one, the only.
THANK GOD!!!
But he did open up 32v, giving us all the 3 and 4 BSD as truly open source.
SYS V needs to go open next, not that overloaded slowlaris, but lean mean SYS V
SCO is never going away. Fifty billion years from now, long after the last human is dead, alien successors-in-interest will still be suing each other over it.
This battle has gone on so long I was still a Notes developer when it started!
Nothing is over! Nothing! You just don't turn it off!
“He’s not deformed, he’s just drunk!”
The groklaw coverage was so good. I know that PJ closed the site down. Did anything ever spring up in its place?
Boy, do I feel like an idiot for paying my $699 License Fee to SCO.
Have you ever used SCO?
I have. It wasn't a bad system. I didn't like it as well as Solaris, but it was stable and reliable and pretty well documented. For a long time, they had a good product and supported it pretty well.
Yeah, the company sucked, but all that work, good programming, is now going to waste. What I'd like to see is IBM take ownership and open source all of it, have it relicensed under GPL and MIT licenses. Ultimately, I'd like to see a lot of that code legally incorporated into Linux.
Why? Just to make the people responsible for the fiasco the lawyers and executives of the company SCO weep.
I don't pay for love. But the boot is $512 in my city.
Out of curiosity I clicked on the tag, and two thirds of the other stories that showed up were also about SCO.
So maybe this isn't over after all.
File under 'M' for 'Manic ranting'
...a 13 years old joke: http://imgur.com/iEy7v7O
No, it's not over, not by a long shot. The SCO owners, and who ever is funding them and their lawyers will continue this nonsense so long as they have money to do so.
There are only 2 ways to stop them you have to either cut off their source of money to pay lawyers or get a federal court order the to stop this nonsense.
IBM and SCO have been doomed to eternally fight each other, we will see another legal battle every 4-5 years for the rest of eternity.
Nothing is over until we decide it is! Was it over when the Germans bombed Pearl Harbor? Hell, no!
PJ and Groklaw would be a huge boon for slashdot if you could somehow reach out to her and bring her back.
IBM, Novell, and several others had countersuits against SCO, just because SCO's claims were thrown out doesn't mean that the case is over yet.
Yes, the company is essentially gone, but there are still possible reasons go keep going (to bury the company, and make it toxic for anyone to try and buy the basis for their claims)
And... Emacs Wins, Vi loses!!!!
Oops, sorry... wrong battle.
Sadly this case is not over yet, reading the summary of the order there are still outstanding counts, this order only addresses Counts VII and IX. Furthermore SCO still has appeal rights. That said, looking through the summary, it's pretty safe to say that SCO will loose the whole case.
Still pursuing his millions, at least in 2013:
http://archive.sltrib.com/stor...
I didn't think I'd live to see the end of that legal battle.
Because of course VMS crushes all competition from inferior OSs like UNIX, EDT is the real winner!
SysV and the flusterfuck dyslexic script hackery behind SysV was a constant nightmare with a mountain hardware complaints leading back to it. Sorry kids SysV like the cart and buggy has had its day and we need to move on. Yes things will break but just like when the car replaced the horse and buggy that scared children with its noise and smoke we will realise the streets are no longer filled with horse shit.
Many of my customers are still using SCO Open Desktop. For new licenses and users I now deal with XINUOS http://www.xinuos.com/ . They acquired the assets of SCO from the bankruptcy proceedings. They are pretty good people to deal with. The best part is that I can use the same platform that I have used since 1981 when I was supporting AT&T 3B2 computers (with technical upgrades, of course). Open Desktop is the name of the System V 3.2 architecture. It is now time to stop denigrating SCO (the OS) and see it as a viable commercial alternative to Linux or xxxBSD, and is a stable, strongly usable platform for getting actual work done.
"The mind works quicker than you think!"
Darl McBride drove the public company that he'd been allowed to run into the brick wall that is IBM and took it to his brother's panel shop (legal firm). Both made a fortune out of the destruction. Massive legal fees and a golden parachute draining all value out of the company before bankruptcy.
Linux was just the distraction for an old fashioned two man scam.
systemd has done far more harm to Linux than SCO could have ever managed to do.
It shall be forked when the time comes.
Only true because SCO had nothing but lies and used the "but Amityville horror is true" journalist as a PR hack - thus just about anything else was more of a danger.
Still, Lennart's latest attempt at linux domination is flawed in many ways and still not ready for release yet but we are stuck with either using it or using old distros. Notice how many commercial operations are doing the latter and still stuck on RHEL6 to avoid systemd? Doing anything with Fedora outside of the norm (eg. running ZFS or using odd bits of hardware) means a risk of the thing just not starting - what an utter failure of something that began as an init system!
Yeah, it has been very bad for Linux. Slashing startup times, managed service recovery, modern APIs, ... Really really damaging stuff.
Seriously talking, most of the people are really enjoying systemd, it has benefits that are visible even to the end users. The change resistance and will to stay in the 80s is just strong with some people.
However the difference between the "flusterfuck dyslexic script hackery" and the new thing is if portions failed to work the old way the system would still come up with whatever it has.
This shit of hanging with no log available and then finding that just unplugging an RF mouse dongle is the secret to the booting or not is not what we are looking for in a modern system. Lots of things writing in parallel to a binary log? The 1960s called and said something about obvious failures wait to happen due to race conditions that Lennart has somehow not heard about.
I used to think you guys had a point, and I was actually afraid of systemd, even though I've been using Linux as my desktop OS for over 5 years.
But then four months ago I needed to upgrade, and my chosen distro had switched to systemd. I hesitated, but then I gave it a shot, and I have not had a single problem in the past 4 months. My dev PC currently has 77 days of uptime. The last time I rebooted was for a video driver update.
Systemd really isn't as bad as you scaremongers make it out to be.
SysV and the flusterfuck dyslexic script hackery behind SysV was a constant nightmare with a mountain hardware complaints leading back to it.
Even so the clusterfuck of rc scripts in most redhat derivatives was Red-Hat's creation. People aren't using init, via inittab, properly and now the reason cited to replace init is because the rc system, and the script hackery behind it created by red-hat is disliked. Keh?
Wouldn't a better rc system work better?
Here is a thought, why not learn how to use the shell properly so that shell hackery is not required. Or another idea, learn how to implement design patterns in bash/sh/ksh/zsh. Init is a simple elegant idea, people are arguing for it's removal because they aren't skilled enough writing *shell scripts*. It seems a bit silly to me that people who can't write something so simple have any business modifying the way the OS initializes.
It would be great to get Ken Thopson's opinion on the situation.
However, since we have the attention of many systemd advocates, can someone please throw a use case at me that init doesn't satisfy that systemd does? I'm really trying to understand why it is supposed to be better than something that is as tested as init. I don't mind using it, but why it is supposed to be so compelling?
My ism, it's full of beliefs.
Slashdot headline: "May Finally Be Over"
Referenced source: The Register.
from The Register article: "the case isn't over"
Comment removed based on user account deletion
Comment removed based on user account deletion
Where are my damn mod points? Mod this cynic up, he's absolutely ontopic and his comment insightful.
I'm really confused as to why people hate systemd so much. Based on the negative reactions on Slashdot, I expected systemd to be unstable and bloated, and was thinking about perhaps migrating back to Gentoo or FreeBSD if the rumors were true. However, during the past year I've tested systemd with first Kubuntu 15.10 and then Arch Linux, I've had no trouble with it at all. On the contrary: the bootup was lightning-fast compared to previous systems, and everything just worked out of the box. Taking a look "under the hood", everything looked neat and clean as well: system services are configured through readable config files, that are much shorter and tidier than the typical SysV init scripts I've gotten used to. Most of the design choices make sense as well: I see no reason to keep daemons like e.g. initd and inetd separate on a modern system.
I've also read that systemd apparently saves a lot of work for e.g. the distribution maintainers and desktop environment programmers, in the first case since it is much easier to maintain a systemd service file than a SysV init script, and in the latter case because a lot of work that previously had to be redone for every Linux distribution can now be easily shared or ported between distributions. I don't think some homogeneity among base systems are a bad thing if it makes it much easier to make software work across distributions. For instance, almost nobody's complaining that using the Linux system with the GNU base system and X11 display server is bad because it makes the Linux ecosystem too homogeneous. Sure, you do have legitimate usecases for the BusyBox base system and framebuffer applications, but that's not the majority of Linux desktop systems. There will of course be legitimate usecases for other things than systemd, but I don't believe that holds for the majority of Linux desktop systems either.
The only criticism of systemd that I agree with, is that plaintext log files are a good thing. I think I understand the reason for having binary logs (making it easier to parse for programs and scripts without a making a regex-hell), but in that case it would be much saner if journald automatically transcribed the logs it generated to plaintext files as well. Apparently it is not too difficult to set this up yourself, but I still think human-readable logs should be default.
Systemd is only of any real use to lazy-assed developers that have to reboot their fucked-up VMs every ten minutes.
Take a server that is up all the time, and what does systemd bring to the table? NOTHING.
Is SysVinit messed up and in need to be fixed or replaced? Sure. It just doesn't need to be replaced by a half-assed monstrosity that has its fingers in far more than init.
I hesitated, but then I gave it a shot, and I have not had a single problem in the past 4 months. ...
Systemd really isn't as bad as you scaremongers make it out to be.
The flaw in your reasoning is a fallacy known as argumentum ad novitatem, or an appeal to novelty. Your argument is invalid because you overestimate systemd, prematurely and without sufficient investigation assuming it to be best-case over the far longer vetted init system.
e.g. of the same form of invalid argument:
> Ken Thompson's opinion
Doubt that'd help - he'd be flagged as old school, once relevant etc. It'd just add fuel.
> People aren't using init, via inittab, properly
Totally agree! I always thought inittab was one of the most ridiculously underused features of init - I never understood why it wasn't used to actually launch real services intead of just the launch script launchers. Might have taken some work to define a service process more closely, but I feel like there's been a whole nuclear navy deployed to crack this nut.
My systems all have systemd, and it's been no problem for me. But the attitude of the systemd devs absolutely stinks, and gives me no faith that they can do a good job - given the extent to which software development is a people skill. They sound like people of poor judgement. And it all sounds like an incredible amount of NIH and scope creep.
It's actually not that that pisses me off. It's the attitude of the devs and the sense of scope creep. If Microsoft had decided to "improve" linux, they would have done it this way.
When I write software, it's rarely a question of "does it work" - I can make most things work that I start, given a little peace and quiet. It's far more often "is this the way we want to do this?" that's the problem ... all the things I've done badly in the past were down to approach, not execution. Feels the same way here: should have executed a series of measured improvements.
SysV and the flusterfuck dyslexic script hackery behind SysV was a constant nightmare with a mountain hardware complaints leading back to it.
Even so the clusterfuck of rc scripts in most redhat derivatives was Red-Hat's creation. People aren't using init, via inittab, properly and now the reason cited to replace init is because the rc system, and the script hackery behind it created by red-hat is disliked. Keh?
Wouldn't a better rc system work better?
Here is a thought, why not learn how to use the shell properly so that shell hackery is not required. Or another idea, learn how to implement design patterns in bash/sh/ksh/zsh. Init is a simple elegant idea, people are arguing for it's removal because they aren't skilled enough writing *shell scripts*. It seems a bit silly to me that people who can't write something so simple have any business modifying the way the OS initializes.
It would be great to get Ken Thopson's opinion on the situation.
However, since we have the attention of many systemd advocates, can someone please throw a use case at me that init doesn't satisfy that systemd does? I'm really trying to understand why it is supposed to be better than something that is as tested as init. I don't mind using it, but why it is supposed to be so compelling?
I miss the simplicity of the bsd-like init config scripts sitting on top of SysV in Arch, before they adopted systemd. So much could be configured from rc.conf, the daemon commands were simple, and I never had problems booting.
gah
Don't forget to pay your $699 licensing fee, you cock-smoking teabaggers!
1. You don't know what you are talking about.
2. If you're opposed to systemd (I am, BTW) -- what are you doing about it? I mean, instead of boring people with repetitions.
...is much more concise than "the latter company". Former and latter should be used when they are the simplest solution.
Can I start the flame war now please?
Will it be systemE
or does everyone prefer systemd++
Disclaimer: I use OpenBSD
Sent from my ASR33 using ASCII
I've already burned my mod points so I can post normally. It doesn't matter if you agree with it, it's off-topic and just looking to start a fight. -1 is where it belongs.
"Be particularly skeptical when presented with evidence confirming what you already believe." -
SystemD can really work fine until it doesn't. And when that happens, you have no way of debugging and finding out where it went wrong.
So basically, you're saying you like the way the old system failed instead of how the new system fails. Gotcha. How about something more productive than whining about the change? Help out and push for better output, error control and reporting in the new system. It's new and needs the rough edges worked out, help out if you don't like it as is.
"Be particularly skeptical when presented with evidence confirming what you already believe." -
Yes things will break but just like when the car replaced the horse and buggy that scared children with its noise and smoke we will realise the streets are no longer filled with horse shit.
Yeah, because camel shit is such a fucking upgrade.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
If you don't have problems with systemd you by definition don't have problems with it.
The concern is that when it doesn't work, you're helpless as it's near impossible to fix/work around. If a line in a init script causes you trouble you can just comment it out. It doesn't matter if the reason it causes trouble is because your hardware is failing. If that same line is in a binary, you won't find it without a debugger and you won't be able to remove it without re-compiling, and if you were to send a patch "remove this line because it causes issues when the hardware is failing" you'd justifiably be sent away (and probably considered crazy).
And there are a lot of things that are just broken. There is for example that feature that when during shutdown you press CTRL+ALT+DEL real often real quick it says "rebooting immediately". Unfortunately every single time I tried it that it just hanged afterwards. The kernel magic sysreq always still worked.
Especially for an init system it's not enough to just have great ideas. You also need a near-flawless execution. And like me, a lot of people believe at least SystemD developers, but probably any human, incapable of that for such a complex system. Though with a few decades of work it will get there. Just that by then the people behind it probably already designed 3 new init systems if they get their way.
They will soon have 100% free time, after everything they work on is also absorbed into systemd, Borg-style.
"You've been systemd!!"
Red Hat will go down in F/OSS history as their Benedict Arnold.
> I think I understand the reason for having binary logs (making it easier to parse for programs and scripts without a making a regex-hell)
Also detecting corruption.
Well, R.J. Reynolds Tobacco makes cigarettes out of it.
"It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
I guess that philosophical question is finally settled.
It doesn't need its edges smoothed out, it needs to be re-written. It is fundamentally flawed and there is no way to fix SystemD without breaking compatibility. They used thick screws when they should have used fine nails. Not only do the screws not properly work, but they ruined the wood.
You got it all wrong, SystemD works great when it's working. It's when it has issues that it has horrible issues. They never planned out the failure cases, which are THE MOST IMPORTANT PART of any system. Almost any idiot can get a system to work, but getting it to work correctly for the right reasons and to fail in predictable and graceful ways is the hard part.
I forgot to also mention, making a system that fails early instead of chugging along like nothing is wrong all the while it's messing your crap up.
The only problem I really have is that it tries to do everything. I don't have a strong opinion. OpenRC on Slackware is working well for me though. Linus doesn't have a strong opinion, just a problem with the developers. And IMO that's a good reason to be wary. I mean, forcing the KERNEL to work around the problems your code causes? That doesn't seem like good coding practice.
Sweet!
(Metaphorically speaking, you understand...)
ogods my captcha is "phoenix" - its a warning from Slashdot!!!
I once sat down to fix the problems with init and the rc system. After considering how important init is to the system, I realized that the critical design principle to follow was KISS. From that it didn't take me too long to figure out I simply couldn't do better than init and it should be left alone.
The rc system is a bit crufty, but that's not because of init, it's just showing it's age and the fact that people keep bolting things onto it. It could be cleaned up quite a bit, but a complete redesign is not the answer.
I miss the simplicity of the bsd-like init config scripts sitting on top of SysV in Arch, before they adopted systemd. So much could be configured from rc.conf, the daemon commands were simple, and I never had problems booting. gah
Yielding the power of UNIX has always laid in creating your systems inittab file, I thought everyone did that. I used to look upon rc scripts as an unnecessary complication of the system and wondered why they were there. If a service needs to be up, init makes sure it's up. If you want to take the service down, tell init to take it down. vim /etc/inittab && kill -1 1 then get on with the rest of your day.
Network services, is good example, a shell script handled by rc, is a prime candidate for an init controlled service. Getting init to kick of printer services after a short delay so that CPU time is focus on providing a GUI to a user could be another. Messaging system is a perfect example.
What about using runlevel 4 for your customised system state, 3 for shell level maintenance, 5 for GUI level maintenance? How about an ondemand runlevel?
Just learn how to use init *actions*, which is a lot simpler than systemd. Simple, scarily powerful and totally under utilised in Linux.
After spending some time with systemd writing unit files and playing around with jounalctl my sense is that this entire situation would be resolved with a set of small tools that manipulate inittab files properly that could support a GUI based inittab editor, thus complementing/completing the original design philosophy with a small maintainable set of tools that rpm, yast, apt-get could utilize. I wonder if people would be interested in such a thing? Perhaps it's time to contact the Devuan people.
I can agree with systemd supporters that the rc system is crap, however that still isn't init and systemd is as monolithic as the rc system, except it's compiled. I think the main objection to the idea of systemd is init is a core idea of the UNIX Operating System that is powerful. I've never seen a Linux distribution that uses init properly and essentially the argument is to replace a core idea of a stable operating system platform because people just don't understand how to use UNIX's most powerful concept one step removed from the kernel. Fast and lean!
The funny thing is, after all these years, I still haven't got everything I can get out of init. Do you understand what you are destroying systemd guys?
Has anyone got a use case yet?
My ism, it's full of beliefs.
PJ, if you are reading this we all miss you! Come back, the tech intelligent blogosphere is almost empty without you!
It seems a bit silly to me that people who can't write something so simple have any business modifying the way the OS initializes.
Write scripts? OS initializes? What are you talking about man all I want it my program to start on boot. Why is it that I can do that for Apache with one click in window's service manager, but not on its native platform?
Why is it that when I download a program and compile it from source I need to trawl through the documentation page to be presented with 10 different scripts for 10 different distributions to get the program to start .... or one systemd unit file?
As for use cases I noticed you said init. You didn't include init + 50 bolt on applications that handle various cases all part of systemd, and given that systemd is fundamentally event driven while init is fundamentally script driven the differences in use cases are myriad (mind you not all in favour of systemd IMO).
It is nice to see scox lose, even if it is over a decade after it has any relevance.
As I have been saying for a long time, this is much more a msft scam, than scox scam. For msft, $100 million to stomp (if not eliminate) a competitor is money well spent.
Let's not forget that some scox insiders, like Riamondi, were selling their shares when scox was at $16. None of the guilty have been really punished, and they never will be.
As to insiders losing everything, and scox becoming worthless: scox lasted a lot longer, and scox's shares went up a lot higher, than would have happened without the scox scam.
Msft is still doing the same IP scamming. Only now it may be more effective. Msft and redhat have partnered. This makes redhat - and only redhat - immune from patent infringement lawsuits from msft. Sound familiar? It should. It is the scox extortion racket all over again - only this time with more credibility.
> "Only Days After Red Hat Legitimised Microsoft’s Patents Against Linux Another Linux-Using Company Falls Victim to Microsoft’s Patent Extortion"
http://techrights.org/2015/11/10/star-micronics-and-patents/
Of course, msft rarely sues in court, they don't have to. You either quietly settle, or get sued out of existence.
Once non-redhat distros become irrelevant, msft may turn on redhat. Or, maybe not. I think msft is okay with competitors, as long as those competitors can be dealt with, and are not too threatening. In 1998, Apple seemed to be okay as a competitor.
The only criticism of systemd that I agree with, is that plaintext log files are a good thing. I think I understand the reason for having binary logs (making it easier to parse for programs and scripts without a making a regex-hell), but in that case it would be much saner if journald automatically transcribed the logs it generated to plaintext files as well. Apparently it is not too difficult to set this up yourself, but I still think human-readable logs should be default.
Not too difficult?
rsyslog and syslog-ng are able to natively get the logs directly from the journal via /dev/log. You literally only need to install a syslog daemon to get your classic logging back.
But if you're using a logging daemon that can't read from /dev/log you can have journald output the logs to a socket for syslog to read with by changing one line in journald.conf : ForwardToSyslog=no to yes.
This is about the easiest change you can make on a Linux system which is why it angers me that people bitch about it.
Don't mistake me for an advocate - I'm more or less just someone who has it, doesn't have time or inclination to rip it out, and I'm not to be confused with a professional admin. (While I do admin quite a heap of hardware, I do not actually do so professionally - I'm just an idiot who likes to tinker and make his own stuff.)
That said, I've found the startup analytics handy - especially blame. I find journalctl (w/grep too) handy as all hell. And that's about it. I'm sure I've bumped into it a few other ways but that's really about it. I learned a few new commands. I learned a bit about what it was doing. I don't actively dislike it. Some of the complaints levied against it do make sense to me but, again, I'm not an admin or anything.
My biggest complaint is that those who do not like it are really being left without much choice. I am *not* a member of that group but I'd probably throw a fairly regular donations at a project that was working to make an Ubuntu-esque distro and had a sufficient level of dedication and support. I'm disturbed that there are few viable options and the future is bleak - and money alone won't solve that.
And no, I'd not throw a donation at them because I'm altruistic. I'd do it because I'm a firm believer that competition makes things stronger and better. There is some idealism in that as much choice as possible is good but that's not my only motivation. If there's a viable alternative them things must get better or wither away and die. I'd likely continue to do what I'm already doing, which is using systemd, instead of switching to an alternative. I'd not say I'm a systemd fan so much as I am both pragmatic and lazy. I've read some of the tutorials on how to get a variety of distros to run without it and the compromises that would have to be made (along with on-going effort and attention) and simply realized that I'm way too lazy for that.
"So long and thanks for all the fish."
The concern is that when it doesn't work, you're helpless as it's near impossible to fix/work around.
Yes I've heard this repeated often but somehow the world didn't end. Seems strange to me.
If a line in a init script causes you trouble you can just comment it out.
It's almost like you can disable a unit file from the "safe mode" that systemd boots in just as easily. But that's not an issue since unit files mean that a dodgy line of code in the thousands that are used to get a typical system up and running don't ungracefully hold up the system during boot.
Unfortunately every single time I tried it that it just hanged afterwards.
Do you reach target reboot? If so you have a power management issue. I had a similar bug in Ubuntu that got fixed recently by an update. Anyway once you reach that target you don't need some sysrq magic. Just hit the reset button.
And like me, a lot of people believe at least SystemD developers, but probably any human, incapable of that for such a complex system.
Funny you mention this since actual completely broken systems are few and far between in the grand scheme of things. Right now I'm had more unbootable systems due to misconfigured sysvinit systems. But then many complaints about systemd breaking are due to dodgy configurations in the first place.
My main criticism about systemd is that it is not optional. I hate stuff forced down my throat, regardless of it's nutritional value. Just put in on my plate and give me the option to eat it or not. Systemd is like tobasco-sauce; By itself there's nothing wrong with it. But you wouldn't force people to eat literally everything they choose to eat with a sprinkle of tobasco. Yet this is exactly what systemd does. So fuck systemd.
There isn't one. SystemD supporters default to comparing SystemD to ancient (and as you point out) mostly wrong sysv/rc style init. Any of the "problems" it fixes have already been fixed in any number of modern stabs on init like OpenRC et al. (if you need event based system start your doing it wrong anyway.)
The conclusion is that systemd is a trojan horse designed by Redhat and Co. There is simply no other viable explanation for its rapid adoption by coup and force in most distros, coupled with it's utterly insane scope creep. Even stupidity isn't THAT stupid.
Were Scientologist involved in this. It sounds like a page out of their play book. Shuddddder!
As I recall, prior to SCO, every Unix system ran on some kind of proprietary (aka not cheap) hardware. SCO became popular around the time that relatively inexpensive servers started being built with 80286 or 80386 processors. The ability to run Unix on commodity hardware was a great combination. (It would be a while before Linux became a widely accepted alternative).
Now we gotta get Oracle to stop saying APIs are patentable.
It's not just systemd that is destroying SysV. It's also Solaris, OS X, PC-BSD, and FreeBSD -- we can probably say well over 90% of the major Unix platforms. For better or worse, OpenRC is also making many of the same choices as systemd, including heavy dependence on C libraries, dependency resolution, parallel startup, and cgroup support. The critical failure of SysV init is the pidfile. It was always a bad hack — perhaps necessary for cross-platform support in a world without real process tracking, but now there isn't a hell of a lot of competition in any given market segment, and cross-platform support is being seen as less important than being able to accurately manage services. Yes, pidfiles almost always match the service they are supposed to, but this is not something that should ever have been left to userland. Similarly, daemonizing a process should never have been left up to script writers, given that glibc doesn't even do it correctly.
So now we're putting process tracking back into the kernel and it's a breaking change. If cgroups had been part of the POSIX standard years ago, systemd would have attracted no more attention than upstart when it was released. It *is* init, it has a superset of the same features, only with an event-driven model, and a slightly more sensible approach to dependency resolution than upstart. You may not have reached the limits of inittab, but other people with different use-cases have, and there's nothing in particular wrong with either case. The argument with systemd isn't an argument about how best to manage services, it's about technical debt so entrenched that people think that's the way it's supposed to be.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
We need a new 'Law of systemd', similar to Godwin's law.
Something like 'When systemd is mentioned in a Linux thread which does not relate to systemd, the thread is finished'.
Either that, or the assholes like you who bring it up on every single thread no matter how irrelevant it is need to die in a fire.
I have a system which may or may not have sound on boot. Read that again. A computer which may or may not have sound on boot. Booting should result in a known state. Booting with systemd is a crap shoot. I am so angry, I regularly step away from my computer while bug hunting. I'll be switching my media server over to FreeBSD once Haswell support gets added, and that will be the last of my computers that I switch over.
From bootup (7):
"The boot-up process is highly parallelized so that the order in which specific target units are reached is not deterministic, but still adheres to a limited amount of ordering structure."
Fuck that. Impossible to debug.
Systemd sucks ... by design.
PulseAudio is similar. Either works like a charm or it's a POS that randomly stops and won't work till you reboot.
Now that's an annoyance, for sure. But if that was to do with the system actually starting it'd be a major hindrance.
In case anyone doesn't know, it's another of Lennart's creations.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
I do not comment anything about the technical side of the SystemD, as I think it does work, as I don't know how it really works but on my system it does work so I don't need to be "Fixing it" out of the box. But I have been required to touch it. To problesolve couple of the odd things, last time when I bought Steam Controller and it doesn't recognize itself as should, because there is something to cause conflict with the Microsoft Keyboard and mouse receiver (Sculpt Ergonomics combo, hey, it is excellent keyboard and mouse!) as it is recognized as Joystick or something.
But back to the point.
I do not know, who did choose the commands, the syntax or what ever, that the user needs to use when handling the Systemd?
And I mean commands like how to get to system level 3, get system rebooted, get system back to graphical state or shutdown the system.
"systemctl isolate multi-user.target"
Seriously? Even when that is one of the three ways, it is still like "Who was not thinking!?".
I need to check something like below to get remember that!
https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet
How about would have been a command something more on the earth:
"system multi-user"
The old "Init 5" was like very direct and clear.
rm foo.txt
That is very simple.
mv foo.txt bar.txt
Very clear as well.
But then comes systemd and the logic has escaped!
I find it a bit silly that people who thinks that INIT or any equal (systemd) has anything to do with how OS initialize. As INIT or systemd are the first programs that the operating system starts. The operating system being in this case the Linux Kernel.
Even a bootloader, that isn't part of the OS either, does only one task and it is to start the OS (in this case again the Linux Kernel) that then takes control of everything, checks itself and hardware and then starts the first non-OS software, in this case INIT or Systemd.
And I do agree totally with you, that the systemd advocates should start writing very good examples why the systemd command was better than the INIT. Or why the systemd really does things better way than INIT.
As everytime when I need to troubleshoot systemd, I need to start looking answers from web. Even for the very basic and simple things, even after using years the systemd.
The whole systemd is like "You need to hack the system to work". Like what? It isn't simpler and as robust as the INIT was. It isn't clear or easy to learn or master.
>Why is it that when I download a program and compile it from source I need to trawl through the documentation page to be presented with 10 different scripts for 10 different distributions to get the program to start .... or one systemd unit file?
ITYM "10 different scripts for 10 different distributions, and a systemd unit file (which isn't even a shell script, because the functionality is hidden away in a C program)" HTH HAND
Thanks for the comment. I just installed syslog-ng on my Arch Linux system, and indeed got back my text logs without any extra configuration. It just took: /var/log/ directory was immediately repopulated with all the logfiles I'm used to. That was even easier than expected :).
sudo pacman -S syslog-ng
sudo systemctl enable syslog-ng
sudo systemctl start syslog-ng
and then my
What a good thing that only one process, journald, writes to the log file then.
What is one supposed to think about criticism from people who can't even get the most basic details of the way systemd works right?
Watch this Heartland Institute video
Even so the clusterfuck of rc scripts in most redhat derivatives was Red-Hat's creation.
Nope. AT&T. Specifically AT&T system-V. Hence the name, sysvinit.
Debian is not a "redhat derivative".
Watch this Heartland Institute video
The court has already decided many of the claims against SCO including copyrights and ownership. The claim in this order was about tortious interference: Did IBM, by hardening Linux and porting code over to Linux, maliciously interfere with SCO's customers and business relationships?
Like many of SCO claims, the tortious interference were ambiguous and ever changing and lacked any detail. The number of parties that SCO alleged that IBM had caused interference changed by the month despite IBM asking repeatedly (and the court ordering SCO to respond repeatedly) to name the parties and the detail the interference. It was as low as 3 and as high as 150 with 150 being a number that SCO only claimed because one IBM email mentioned that it had 150 new customers on Linux.
Similarily to other claims, SCO brought almost no evidence to the case despite years of discovery. In fact it was often contradicted by indisputable evidence that IBM brought. For example, SCO claims that IBM damaged SCO's Unix by communicating to their third parties like their investor, Baystar, that IBM was supporting Linux and that the third parties should abandon Unix. Almost all customers third parties swore to the court that they never had communications with IBM on the topic. The only party that acknowledged it had any discussions with IBM was Hewlett-Packard and they testified that the discussion did not change their relationship with SCO so there was no damage.
The theory that SCO offered as motivation was that IBM wanted to damage SCO by hardening Linux and porting Unix code. Former SCO employees testified against SCO in that they did not believe damaging SCO was ever the motivation for supporting Linux. Their analysis was that IBM was competing against the likes of Sun and Microsoft by offering a cheaper Unix-like OS on cheaper Intel hardware that was nearly as good or better than Unix.
There are still a few claims left but at this point the pattern keeps repeating: SCO loses on summary judgements because they never had a case.
Well, there's spam egg sausage and spam, that's not got much spam in it.
Why doesn't it do this by default? The fact that it swallows all errors and sends them to /Dev/null by default is a fucking problem. I shouldn't have to install another package to get the same functionality I already should have had.
You Systemd people are ass backwards, but hey, you got faster boot times. Fucking hipsters.
Why doesn't it do this by default? [...] I shouldn't have to install another package to get the same functionality I already should have had.
I agree, which is precisely why I commented that "it would be much saner if journald automatically transcribed the logs it generated to plaintext files as well" in my first post. However, as thegarbz brought up in a comment above, it is easy to go around these defaults by installing syslog-ng. But I agree that distributions ought to do that by default.
Another thing to keep in mind is that Maureen O'Gara made her name with a series of "but Amityville Horror is real" stories. I'm not sure if it was "National Enquirer" or something else she published her "journalism" about ghosts in, but that's where her reputation came from.
Thus she exhibited close to zero scruples some years before getting mixed up with SCO and "doxxing" PJ.
Yes.
Systemd is incredibly fucking fragile and it should not be.
As for your last point - the systemd stuff is mostly done internally at RedHat because Lennart does not play well with others, but outsiders can send in bug reports. Your suggestion "push for better output, error control and reporting in the new system" has resulted in a lot of people getting flamed when they tried. It's not going to stop me sending in very polite bug reports (have to be careful not to upset the egos) - I'm already doing what you suggest despite running systemd on very few systems.
Look one more step up the tree for the race condition and understand the journald just takes what it is fed before throwing stones.
How about we have a rule instead about people reading enough before they post to understand that different usernames mean different people are posting?
Accusing the person that replied of bringing something up shows a distinct lack of awareness - saying you hope the person who replied should die for bringing something up shows a lack of a lot of other things. It's like a toddler's tantrum and amusingly cute in a slightly disturbing sort of way.
Huh? The most frequent complaint about systemd is that it "fails early instead of chugging along like nothing is wrong all the while it's messing your crap up", i.e. it won't boot if there's crud in fstab.
Watch this Heartland Institute video
My main criticism about systemd is that it is not optional.
Then you have no criticism of systemd. In any sane distribution (e.g. Debian) systemd is optional.
Watch this Heartland Institute video
What are you blathering on about? One process writes the log file. There is no race condition.
Watch this Heartland Institute video
The judge released another summary judgement in IBM's favor a few days earlier to this one. This is about the unfair competition claim (Count VI) by SCO against IBM. Specifically this involved Project Monterrey.
Back in the day, IBM and SCO both jointly worked on Project Monterrey which would put SCO's Unixware and IBM's AIX on Itanium. The project was doomed by Intel's delays in launching the new chip architecture as well as the poor performance of it. Both parties put out products but IBM eventually threw their support behind Linux instead.
SCO claims unfair competition in that IBM took code from Project Monterrey to put into Linux and that IBM undermined Monterrey by secretly developing Linux and put out "sham" Itanium products without support. The judge ruled in IBM's favor because the Joint Development Agreement (JDA) signed by both parties clearly allowed IBM to use any code as it saw fit. Secondly if IBM violated the JDA it would be considered a breach of contract and not unfair competition. Lastly the JDA also clearly stated that IBM had no obligations to do more than release their Itanium product.
Well, there's spam egg sausage and spam, that's not got much spam in it.
You're talking about common issues. I'm talking about corner cases, like when something actually goes wrong and you need to figure out what and why.
I'm happily running Gentoo, as I have been for years. OpenRC continues to be developed, and I continue to run it, along with with an actively maintained KDEPIM 4.4 which includes my KMail 1.2 (the last one that lacks a requirement to have an enterprise database installed as a backend.)
Gentoo isn't for everyone, but it has served and will continue to serve me just fine.
Oddly enough, I moved to Gentoo FROM FreeBSD as a desktop, because FreeBSD was flaky as fuck when it came to properly supporting things like cameras and smartphones being plugged in via USB. It still wins (although not hands down anymore since the maturity of ZoL became a thing) as a file server, but it is no longer my desktop.
Bottom line: you only need to switch distributions and not the kernel if you want to tell the systemd Nazis to eat a dick.
UGH PulseAudio. Thankfully it's just a bad memory for me now.
There was a brief time when it was tightly bound with KDE. Fortunately the KDE developers had a rare moment of clarity and tossed it into the trash bin where it belongs. PulseAudio is a fucking horror show created by people who clearly don't understand the most basic fundamentals of how to write software.
Only 13 years! Now the costs battles. [eom]
Like, for example?
Watch this Heartland Institute video