"Torvalds' likley ire"
Odd. Usually it's quite easy to tell if he's pissed off about something.
systemd
with faint praise Linux 4.13 is under way. Linus Torvalds pulled one of his semi-surprises by announcing release candidate one on Saturday, rather than issuing his usual Sunday evening missive. The headline features of the next kernel include support for Intel's forthcoming 10nm Cannonlake CPUs, due later this year, and the 14nm Coffeelake that …
"you're falling victim to sampling bias"
My tongue was so far in my cheek when I made that post that I looked like a hamster. I quite enjoy the times he tells like it is. If you consider that half the Reg readership moves to DEFCOM 2 at the first mention of systemd; I suspect that he is somewhat annoyed by it but either considers it outside his remit; or is tempered by the fact that he's currently got nothing to slide into it's place without messing up a lot of people, so "going Full Linus" at this stage wouldn't be that sensible.
Plus, from the sound of things, the systemd guy probably wouldn't take criticism well.
"My tongue was so far in my cheek when I made that post that I looked like a hamster. I quite enjoy the times he tells like it is."
OK, cheers, mate.
"Plus, from the sound of things, the systemd guy probably wouldn't take criticism well."
I'm not sure he sees it. I think he has a program to handle bug reports. It's called wontfixd.
"Plus, from the sound of things, the systemd guy probably wouldn't take criticism well."
Poor widdle snowflake! Is *THAT* why systend is still there? Because saying the TRUTH about systemd might HURT HIS WIDDLE FEELINGS?
OK that's just my 'over the top' reaction but I bet I wasn't the _ONLY_ one out there thinking that...
However, it could be that the systemd fans need to get out of their "safe spaces" and smell the sewage... as in, when you exist entirely in a bubble-world, and only hear from fanbois and sycophantic wannabes, you end up with gnome 3, systemd, and WIN-10-NIC. 'Nuff on that, yeah.
It took a while for Linus to blow up over gnome 3. Same kinds of people made systemd. It'll happen. This is like the rumbling before the volcano goes KABOOM.
If you consider that half the Reg readership moves to DEFCOM 2 at the first mention of systemd
There's a good reason for that. Systemd is a horrendous bit of code being foisted on us by a small group that refuses to take constructive criticism as a cue to improve their product. And, on top of that, some of their decisions are just stupid to begin with. For instance, what kind of fool thinks binary logs are a good idea? What are you supposed to do with those when you can't get into the system, the time you need the logs most? And that's just one of a dozen major design flaws with it. Forget the fact that the entire thing utterly fails the test of doing one thing well and instead is mediocre at a whole bunch of things. It's just got flawed premises at the foundations.
There's an axim that states that a complex system that's broken will be found to have either evolved from or replaced a simple system that worked just fine. This is absolutely the case with systemd. Fortunately, at least for the time being, most of us (sorry Gnome users) can switch to OpenRC instead.
I'm glad he's grown up. His swearing and tantrum throwing was embarrassing to read.
I guess he must have believed that he was a "God", until he realized he isn't. He's born the same way we are and he'll leave this world the same way we all will.
I felt the same kind of embarrassment for Steve Jobs when he believed he was a God and believed he could "will away" his cancer. Ultimately he was not a God, and he left this world the same way everyone else has and will.
This post has been deleted by its author
This post has been deleted by its author
ALL supposed $DEITYs are cordially invited to kiss my pasty white butt.
Why does it seem that folks around here seem absolutely rabid to take a poke at religion? You believe - or don't - whatever you want and let others do the same. Why is that so difficult? Why do we have to be uncivil to each other over the issue? This sort of thing annoys me greatly.
For the record, I'm not even sure what - or if - I believe concerning religion anymore. I've had a years long crisis of faith fueled by a combination of scientific knowledge and certain life changing events which, barring a visit from some celestial being, seems unlikely to be fully resolved till the day I die. But whatever I believe I'm perfectly happy with it.
This post has been deleted by its author
"Why does it seem that folks around here seem absolutely rabid to take a poke at religion?"
Symon's post pointing out Aynon Yuser's use of capitalisation was fine up to a point (although it didn't cover the -valid in my view- edge case of deliberately spelling what would normally be a proper noun without capitalisation as a political statement).
But then he finished it off with "and He'll know if you get it wrong." If you threaten someone -however implicitly- with an imaginary construct then be prepared to have your bluff called.
I poke at religion because I see it as a waste of human minds. Religions, by definition, teach the young that it's bad to learn to think for yourself. If by poking at archaic belief systems I can start even one kid thinking for him/erself instead of looking at the world by rote, I will have accomplished something useful.
Nope.
God is the proper name of the Judeo-Christian deity, so the name is capitalized, as Symon said. Not unlike the distinction done while talking about the Moon or Saturn's moons...
Also, all 3000+ deities out there are entitled to capital letters in their names, as do Santa Claus and the Tooth Fairy. Their existential status has nothing to do with the rules on proper nouns.
>In fact 'faint praise' is fairly standard English language idiom meaning the opposite of praise.
Aware of that but there was no praise at all in what Linus wrote.
I.e. had Linus written "we can rely on init to expose where the kernel needs to ignore it" that would have been *faint praise*. But he didn't. He said we can't trust it outright.
It might be my eyes but I can't see any praise at all.
You are correct.
To be able to describe a comment about something as being "faint praise", there needs to be some sort of explicit complement which, upon reflection, is notable for being deliberately inadequate to properly encompass all aspects of the subject of the conversation.
Describing a lady's hat as being "good at keeping the sun off" would imply that all its more important characteristics (style, elegance, etc) are not to one's own taste and are deeply underwhelming.
Linus could have said the "amusing features of init" were the reason for the patch. That would be faint praise; an init is not supposed to be amusing.
An init written in Brainfuck or Whitespace could be pleasantly described as amusing, because the author of such a thing would undoubtedly be doing it for the kicks and laughs, even if it did end up being better than systemd.
Wow, I am actually surprised he hasn't. I hit Reply planning to link to the rant in question; all I could find was an open letter from Poettering complaining about abuse from the Linux Community (not Linus per se, but he said Torvalds wasn't doing anything to stop it) and a "Full Linus" rant on Kay Sievers for issues in systemd.
I am now looking forward to a "Full Linus" on Poettering, as well.
"The first death rendered-into-obscurity knell for systemd has sounded. About bloody time."
I wish that were so, but Pottering and his paymasters Dead Rat seem to have a Jobs like reality distortion field around them that deflects and destroys any criticism of systemd while simultaniously brainwashing distro maintainers to embed this POS as soon as they can. The we-know-nest arrogance coming from these guys is really out of Apples playbook , chapter 1.
Only a problem if you are served them in the UK (I'll wait while the laughter subsides) where you don't own the food you just paid for.
In the US it is expected that if you are served a gigantic portion of food you will have the common sense to ask for a take-out box after eating half of ithe meal.
No more gourmand criticism from the land of the see-through luncheon meat slice and the deep-fried Mars bar.
I have a theory that all computer programs of any consequence that are "Made in the USA " must have a suitable portion of attack surface for the spooks to gnaw on.
This is, of course, only a theory, shakily based on the constant calls by politicians for backdoors in crypto and the search for, and hoarding of, zero days etc etc. True or false, if I wanted to do something naughty and talk about it there are probably ways to do it reasonably safely, reliably and efficiently. The glory days of reading everyone's cables and listening to everyone's wireless are over.
"Please explain. After paying for food here over rather more decades than I care to think about it comes as something of a surprise to find I never owned it."
Think about the old adage about bad beer; you don't BUY it, you just RENT it for a while. Similarly for food you eat; you don't buy some of it it because most it doesn't stay inside: leaving eventually one way or the other.
You obviously missed the 'old' USA vs UK joke !!!
In the US of A it is the norm to be able to request a 'Doggie Bag' to take the excess food you have purchased away.
In the UK it is not the norm, hence the food you have purchased, if not eaten, is taken back by the establishment (i.e. scraped !!! ) ........ hence 'not owning the food !!!' :)
I am aware that this has changed over the years but is not to my knowledge the norm yet in the UK.
Of course, until recently the food eaten out in most of the UK wasn't worth taking home to be enjoyed later. There is a reason that Blighty has an international culinary reputation as "The island where good ingredients go to die" ... although this is changing, and rather quickly.
As a side note, originally the food wasn't scrapped. Even as late as the early 1980s, larger hotels and restaurants put the scraps into the pig bins. Nice even trade, farmer takes away scraps & returns sausages, proper bacon, etc. Win-win. Why do I have an 'orrible feeling that this logical practice is illegal nowadays?
Why do I have an 'orrible feeling that this logical practice is illegal nowadays?
Because of BSE. Strangely enough, feeding animals on food made from other members of their species (including brains) is really, really, really not a good thing.
So - since it's pretty much impossible to know what's in any given bucket of leftovers, they were banned from being used in animal feeds in order to prevent BSE/scrapie/whateveritscalledinpigs.
This, of course, doesn't apply to food ingradients - so it's still perfectly legal to feed the leftover whisky/beer mash to cows.
Personally I like Ye Olde Oak tinned ham. Yuuuge chunks. The best kind of chunks.
Mostly water, allegedly.
Damned tasty water, though.
On the other hand, I'm reliably informed that 'Murcan "meat" (along with pretty much everything else that passes for "food" in America) is mostly high fructose corn syrup, made from genetically mutated corn that's grown in a Petri dish in a secret underground lab somewhere in Minnesota, so frankly I think we got the better deal.
Tinned meat, of any kind, is e-rations only. Tinned ham is worse than city ham, and city ham isn't worth eating.
Having eaten on 6 of the 7 continents, I can reliably inform you that North American meat is better than that in 90% of the world, and is easily the equal of the other 10%. It is certainly better than anything mass-market that I've ever purchased, cooked & consumed in Blighty.
North American food runs the gamut. Sure, you need to stay away from the processed stuff, but since Americans take pride in their beef, they can produce really good stuff: not quite Kobe quality but still good AND in quantity (so it's not too expensive). You just need to know where to do your shopping.
As for hams, yeah, stay away from the tinned hams, but there's benefit to a city ham if you don't want anything too robust (country hams can be considered over-cured by many).
Kobe is tasty, as are various other variations of Waygu, but it's not worth anywhere near what they charge for it. Me, I find the breed to be entirely too finicky, I'll stick to my Belted Galloways. (Although a friend in Nevada has shown interesting results crossing Waygu and Belties ...).
Yes, there are some bad country hams. In fact, some are downright awful. But there are many more that are wonderful ... which can't be said for any of the city hams. IMO, of course.
If you absolutely must liquid brine a pork hindquarter, PLEASE cook it in a smoker over apple wood at about 210-215F (100C) for around 18 hours ... but don't call it a ham. Because it ain't, and because soggy pig isn't good eats. (Don't get me started on that British abomination "watery bacon" ... )
"Is there a technical reason for the 'lake' part or does someone just like lakes?"
HTH.
You haven't noticed the pattern?
Sandy Bridge, Ivy Bridge;
Haswell, Broadwell;
Skylake, Kaby Lake, Coffee Lake
The first was the "tick" and the second was the "tock," but with the Lake series, Intel has abandoned tick-tock in favor of the more generic three-part process-architecture-optimization, leading to the three members of the Lake series.
I am sorry if this is off topic, but... since you brought up Emerson Lake and Palmer,
let me give you my "memory" version of the ending of the song "Lucky Man" circa 1970:
Lake: oooooooooooooooooooooh, what a luckkky maaaan, he waaaa-aaaas!
Emerson: ooooouuuuaaaaaiiiiiiiiiii badabad oooooeeee oooooeeeee
bididibaaaadaaaabooooodeeebaaadaaaa schawwwuuuuuooooowwwwongg...
Palmer: tit ka tit kat tit ka tit
Emerson: pscheeeooooo dscheeeiiooo booding ka tish ka tish badadada ting
pipipipiee didieieid badschuuung badschuioop tschhh bussschhh
Palmer: tit ka tit ka tit . . .
Emerson: dididi dididi bibaooobibaabaadschoooob oooooooeeeeee badschoooonnngg
ooooooohh waaaaaaaaay teep teep teip tip tip didl did did foooob
Palmer: tit ka tit ka tit dsch busch booof tsssooop
It sounded ok while it was in my head. It's hard to explain if you don't know the song.
If that doesn't make you happy, then I don't know what I am doing.
systemd was a good idea.
Well, part of it.
Replace the init system with something sane, that allows all kinds of extra features, automated startup dependencies, etc. Hell, even replacing scripts with a real program isn't actually that insane in the modern world.
But replacing it with a big, black box that basically replaces lots and lots of core functionality with its own ridiculous idea of a service in so many areas (DNS, etc.) just destroyed the concept for me.
Even the bits that people tout - cgroup isolation for services, etc. - could have been done with a bit of scripting with no extraneous dependencies. What people did was take a system with some small issues, replace the entire bootup sequence and all of ITS dependencies wholesale, and basically create "systemdOS" which does everything completely independently of both other programs and common sense in many instances.
It wasn't necessary to do that to fix the problem and now people are realising that. Funnily, part of the subconscious justification that people used with me was that "there have been no security problems with it, so it must be more secure". I always take that to mean that not enough people have dug into it, not that some programmer is magically capable of never making a mistake. Strangely, now that mistakes have been found (not made, that was inevitable), people are suddenly turning against it.
But I have problems with not just the execution but the whole design. As soon as we moved away from small, single-purpose, auditable bits of code (e.g. individual daemons, scripts, etc.) we moved towards the black-box model where even if there are people capable of tinkering with it, it's all far too large and ugly to play with and far too steep a learning curve, which leads to nobody playing with it, nobody trying to break it or do funny things with it (e.g. try a username with a number at the start) and hence everybody falling into a false sense of security over it "always working as intended".
Now that we're THIS far down the line, we suddenly discover that their assumptions are no longer true, but it's now a humongous mess of code that's integrated or taken over with everything it touches, and it becomes unauditable.
I'm not one to think that "the old ways are always the best". I resist change, until it's clearly for the better, which I think it quite sensible. But systemd was always a bad idea precisely because it took away the modularisation, reinvented the wheel, and had to do it in a way that's almost impossible for an ordinary "power user" to debug. At least with a script, you stood half a chance of working out what was going wrong (and, yes, I have had to hand edit boot-time scripts, especially when doing things like upgrading a distro).
Systemd was -and I speak in past tense optimistically - a heap of junk that nobody's ever really designed with a goal in mind, hence it rapidly expands to try to take over everything. There was no reason it couldn't be a bunch of scripts, a small collection of individual binaries with clearly defined purposes, or even still supported backwards compatibility with older init systems. If it had been, most of the objections to it would immediately be quelled.
But replacing nameservers, ntpd and even functionality like logins and filesystem mounts was never going to end well, and I doubt this will be the last problem we see with this software.
PoetteringOS needs to die. But that doesn't mean, by a long shot, that we should lose the purpose of why it was created or the things it *could* bring us. Init needed a reinvention, but systemd was never it for me.
systemd was a good idea.
Well, part of it.
I'm by no means qualified to comment on OS-level stuff like systemd, more of a slightly technically competent user, but the thing that has always bugged me about the systemd detractors is that if Poettering got it so obviously wrong, how come all the combined experience and wisdom of the contributors and developers of just about every major distribution out there went along with him?
I understand that once the "root" distribution (Debian, SuSE) has made the change, it's probably easier for derivatives to follow suit, but with all the hundreds or possibly thousands of highly intelligent people working on these things, why didn't one or two of them say "stuff it, it's not the right answer and until something better comes along we're sticking with the tried-and-tested way of doing things"?
Genuinely interested. From what I've read, I am not comfortable with the way systemd is going but it'd be a bit of an upheaval for me now to swap all my machines to the single distribution that's swimming against the tide; I mainly use OpenSuse on the desktop but also have a large number of RaspberryPis running Raspbian.
M.
Poettering works for RedHat.
Everyone followed suit despite protests. In fact, since day one people were saying it was a bad idea.
But it's hard to gain traction against a Red Hat pet project that's well-funded, that once it's your init system is hard to revert, especially when other core functionality begins to depend on it.
And alternatives were made, there were three or four at the time systemd came out, none of them ideal, most of them developed or sponsored by distros.
People did speak up, but I think they were hoping it would get supplanted before it took over the world. And, let's be honest, who knows enough to change their init system? Most people still think that distros only have one set window manager, because nobody gets the option any more.
To be precise, Red Hat has made systemd a hard dependency of Gnome (another fine RH project).
Attempts by others (in particular, Canonical), to create an alternative init system by "shimming" the initd protocols somehow got consistently broken since these protocols changed all the time (fancy that). In the end, the Ubuntu folks gave up and went with initd.
Consistently broken (with each new release upstream, in other words, not "broken at all times") is kind of the norm in the Linux world. While MS goes to great lengths to keep Windows backwards compatible every which way, the various Linux projects regularly break APIs and backwards compatibility.
Part of this is that they don't want the baggage of having to support APIs and code that are no longer current, and people have said that Windows' insistence on backwards compatibility has held it back. Often the "best" way of doing things in one release is discovered not to be that great by the next one; Windows would tend to extend and issue workarounds to preserve the backwards compatibility, and "Linux", as we call it, would usually not bother, opting to tolerate the short-term pain of breakage rather than the long-term pain of having to maintain the legacy code forever.
Of course, Windows is a single product, where the world of Linux is many, many different and independent projects that are all "Linux" in people's minds. If each Linux project were to say, "We've got to break this API to move forward. We haven't broken anything in years, but now it's time," you'd have many, many breakages in the end product, even though each project only decided to break one thing in their respective products. There's no centralized leader to tell them NO, go back to the drawing board and figure out a way to do this without breaking the old code... and few people would really want there to be.
Windows, being under centralized control, could just as easily receive requests from every department leader from various parts of Windows to allow breakage so that they can move forward, but the Windows leader is not likely to approve dozens upon dozens of breakages, even if the department leaders each see their proposed breakage as being the only one. What looks like a once-in-a-blue-moon to a leader of a project that is a small bit of the whole can be a near constant when the scope is the entire thing (Windows or a complete distro as offered).
It does increase the work load on downstream teams if the upstream stuff keeps changing, but if you want to go in a different direction, it's a necessary evil if you want to benefit from the other work put into a given project upstream. It's not just Linux that has this issue... I think of Pale Moon and Firefox, where much of the work in Pale Moon is just stripping out the dumb stuff Firefox decided on months or years ago. The farther FF gets from its roots, the harder this will become.
PM is committed to maintaining powerful XUL addons, but FF is set to abandon them in less than a year as part of their never-ending quest to become Chrome. I really hope it works out, but I am concerned that the workload may become too much to handle. There are a bunch of addons I simply will not live without... Firefox (or its derivatives), properly extended, is the only usable browser in existence, IMO.
I don't know if Ubuntu has completely jettisoned Upstart, as it has been a while since I used Ubuntu proper, but their downstream derivative Mint still comes with your choice of Upstart or SystemD (simply select which you want in GRUB at boot time; both are installed by default). Since MATE and Cinnamon are based on GNOME, I would assume that they have to have their support for Upstart backported with each upstream Ubuntu release too, which is probably one of a few reasons Mint has taken to only using Ubuntu LTS releases as their base.
A lot of work in Mint is about de-stupidizing what has been done upstream... the X project (not to be confused with X servers) is one such thing, which aims to take the various g* programs (like ged) and stripping out the hamburger menus and other such detritus, and restoring them to a desktop-appropriate UI. Each time an upstream version of ged or whatever else changes, the Mint devs have to backport the change into their own version (or decide it's not worth it).
De-stupidizing UIs is big these days... reminds me of how much work I had to do after installing Windows 8.1 to make it into a reasonable desktop OS. Windows 10... can't reasonably be done there; I've written it off as a lost cause.
Consistently broken (with each new release upstream, in other words, not "broken at all times") is kind of the norm in the Linux world. While MS goes to great lengths to keep Windows backwards compatible every which way, the various Linux projects regularly break APIs and backwards compatibility.
I don't think things are as bad as you say and certainly not as bad as they were; and I think it was libc6 that was responsible for a lot of problems about 2.x > 4.x times. There's also an issue with config files specifying a far newer version of library than is necessary - you can find a situation where config will throw out a number of complaints but the program's author has a downloadable binary that runs perfectly well on the same system that won't compile it from source.
What you miss is that a huge amount of stuff is packaged with the distro. You don't have to worry about applicationx from vendorx will fail because dependencyy has changed and vendorx, if they're at all bothered, will want ££s for an update - applicationx and dependancyy both come from the distro and if a dependency gets changed then the maintainers, at least for stable distros, recompile against it and fix breakages. If, however, you insist on running on the bleeding edge...
None of my comments apply to systemd-land, of course. That's just an attempt to bring the ?joys of Windows to Linux.
To be precise, Red Hat has made systemd a hard dependency of Gnome (another fine RH project).
Hmmm... that explains some. Another question then (why did I get a downvote simply for asking a question?) - my OpenSuse desktops run KDE but I have installed one or two applications that rely on GTK. Would those applications not work on a non-systemd installation?
M.
"Would those applications not work on a non-systemd installation?"
I run KDE on Debian LTS which is sysv. I have GTK2 and a number of GTX-based applications - gimp being one, of course. I see a few GTK3 libraries are also installed - gedit (3.4.2) needs at least one of them so they're quite happy without systemd. Would more recent GTK3 packages will work? Don't know.
> And, let's be honest, who knows enough to change their init system?
For Debian Stretch, here we go (works fine for me): Using sysvinit instead of systemd in Debian Stretch. It's very simple.
There is good news on the bottom of that page "...indicate that Debian developers are continuing to support sysvinit."
Now try that and see what happens. The first thing going out the door is KDE as k3b (the CD/DVD burning package) has been configured to depend on udisks2 which in turn depends on systemd. You can try and piece it all back together out of the individual packages, only to find that the root password is now needed every time a user wants to mount/umount removable media because the consolekit author is a Poettering acolyte and has abandoned the project. (There is an active fork, but no idea how close to functional it is.) And lastly, uncaught changes to udev in the run-up to Stretch cause mayhem with LUKS partitions when used under sysvinit.
About the only things possible to address the first two issues is to install systemd on top of sysvinit-core (i.e. its parts are present but systemd does not run as init) but the LUKS situation remains unresolved.
"uncaught changes to udev in the run-up to Stretch"
This is not looking good. I'm still on Debian 8 with sysvinit-core and haven't had too many problems (I don't use a heavyweight DE, and tend to use CLI programs for CD/DVD burning etc.). I've been putting off trying Debian 9 but depending on the outcome when I do get round to it, it could mean a parting of ways for Debian and me. A pity after 18 years.
There is a huge amount of hatred in the FOSS world for RedHat.
Pretty well anything originating in RH gets a lot of hate. That means triple hate for systemd
1) It was written by Pottering who has a track record with PulseAudio.
2) It came out of RedHat (how dare they make money from FOSS)
3) It is totally unlike the old init system. (don't like change)
Personally, I find this a bit of a shame but the haters are going to carry on hating.
IMHO, they will get as much success as getting Apple to re-introduce the 17in MacBook Pro... i.e. zilch.
"(how dare they make money from FOSS)"
That's a big problem. Everyone needs to make a living! It costs money to be alive. If you are a FOSS dev and you don't get that money from developing FOSS, it means you have to devote a good part of your life to some other thing, whatever it is that you do to make a living, instead. This is the priority; everything else is worked in around the edges. If a dev doesn't make money from his FOSS work, then his FOSS work is a hobby, and hobbies are something you do when you find the time. After work, the spouse, the kids, the rest of family and friends, the "honey do" list, etc., there's often not a lot of time for anything else.
If FOSS development is something that people have to find time for, it's at a serious disadvantage compared to software developed by people who always have time for it because it's their job (almost by definition the top priority when it comes to distributing their time). People who do hobbies do them (by definition) for reasons other than making money, and when you have limited time for such pursuits, the tendency will be to spend that time where the maximum realization of that non-monetary benefit will be seen.
Specifically, people will tend to work on what's the most fun if it's a hobby... which is certainly not the drudge work of finding and fixing bugs and other necessary but relatively unpleasant bits of software development. When you're not being paid to do something, no one can tell you that you need to go fix this bug or that bug; if you can write good code, they will be glad to have your contributions one way or another. If it's your job, you do it when the boss says so, because our jobs often involve things we don't want to do, but we do them because we all need to make a living. Even the drudge work within someone's own field (such as software development) is better than doing some other drudge work in an unrelated field that a person has to do just to be able to afford to have a hobby in the first place.
There's nothing wrong with profit. It's not the fact that MS is making money from Windows that makes me dislike them. There are so, so many reasons, but that's not one of them, even if for them it is the motivation for the other stuff I don't like.
When you learn to be a programmer there is a phase where you learn about all those cool things you could do. You learn about OOP, RPCs, functional programming and so on. As you usually only hear about them from the proponents, you think they are all great and the future, and they allow you to build wonderfull castles in the sky. You actually dream about complex data structures residing in cyberspace.
Now when you become more experienced you learn that coding is hard and that every line of code is like uncovering a tile in "Mine Sweeper". So you become more cautious and try to optimize not for complexity, but simplicity. Once you learn about the UNIX-Phlilosophy you will realize that this is one local optimum when it comes to simplicity.
In the past, young programmers used to learn either in BASIC or Pascal, and their first jobs were writing shitty software for Windows. That's where all that bad and never maintained shareware stuff for Windows in the 1990s came from, as well as some business critical applications from that time. So people could make their mistakes where it didn't hurt, and then maybe later learned about unixoid operating systems.
Today young programmers start with Linux right away, so naturally they make their mistakes on that platform. They also want to work on "Open Source" software, as that looks good in their resume. That's why those projects now get overrun by inexperienced programmers wanting to build complex castles in the sky. And this is how we get things like DBUS, ConsoleKit, PulseAudio and SystemD.
Upvote for mentioning ConsoleKit, installed by default in most distros. And what does it do? "Keeps track of 'seats'." apparently. I think by that they mean physical keyboard, mouse and screen positions.
It's my guess that the average number of 'seats' across all installed Linux systems is a bit less than one. Desktops and laptops have one; lights-out servers have zero.
"It's my guess that the average number of 'seats' across all installed Linux systems is a bit less than one. Desktops and laptops have one; lights-out servers have zero."
Well back in the early 2000s there was a phase when a multi-seated Linux computer made some sense. As a separate computer was more expensive as adding a graphics card to an existing one. Of course with things like the Raspberry PI, this is no longer the case. Even though it's slow by itself, it's a potent X-Terminal. Now if we had a decent "remote desktop" protocoll that supports audio as well as video, we'd have completely new capabilities.
Now if we had a decent "remote desktop" protocoll that supports audio as well as video, we'd have completely new capabilities.
I'd go for that at home - I already have the children on Raspberry Pis with a NAS-stored documents folder which means they can sit down at (almost) any screen and work, but the idea of having a proper multi-user system does appeal, and might help avoid queues at the x86 machine because the latest bit of homework has half a dozen high-resolution photographs thus causing LibreOffice Draw on the Pi to struggle.
I had sort of assumed it should be possible, but just hadn't got around to finding out what was involved other than playing with VNC. Not the first time I'd have been wrong :-)
M.
We could solve so many problems if, instead of using X11 or Wayland, we had added sound and graphics to the terminal specification.
As someone who has faced the impossibility of writing an even half-correct ANSI terminal emulator, I shudder at the idea of trying to do pixel graphics using escape sequences.
The best remote desktop solution available for Linux is a (now mostly abandoned by Oracle) SunRay Software, you don't need to use hardware clients to connect to server, although you can buy them really cheap on ebay and they're making task significantly simpler, there's perfectly working Windows and Linux clients written in pure Java, so they should work on pretty much anything.
> but the idea of having a proper multi-user system does appeal
LTSP is your friend. http://ltsp.org
Did this for a small rural school in the early 2000s using equipment no longer needed at work.. They never grasped the full opportunity because of their political masters believed computers==microsoft, but it worked well. With Pis as terminals these days, this must be a satisfying exercise to complete.
http://ltsp.org
Interesting... but the website doesn't appear to have been updated since 2013 and the server version available for OpenSuse (5.5.7) seems to have had very little activity in the last couple of years. Does this mean the thing is stable, reliable and secure... or just deceased?
The documentation concentrates on x86 machines as clients too, not much good for my Pis, but then the Pi wasn't designed to PXE...
M.
@Martin an gof
VNC is pretty hateful as an RDP protocol. RDP (if one can get over the microsoft connection) is much, much better - but getting xrdp to build under Linux is a bit of a bitch. You'll need to build X11Rdp too normally if you want decent performance (otherwise it uses a local VNC server for some reason giving you
RDP Client -> Xrdp -> VNC -> X Server
which does rather defeat the point of going to all the trouble to remove VNC from the loop.
VNC is pretty hateful as an RDP protocol. RDP (if one can get over the microsoft connection) is much, much better
I already use 'rdesktop' at work from my Linux workstation to Windows machines so I know the "client" part is possible. Might be worth investigating RDP servers I suppose. Thanks!
M.
Of course with things like the Raspberry PI, this is no longer the case. Even though it's slow by itself, it's a potent X-Terminal. Now if we had a decent "remote desktop" protocoll that supports audio as well as video, we'd have completely new capabilities.
We *used* to have XDMCP. While not readily supporting remote audio (ironically, Pottering's own PulseAudio project could have addressed that), that functionality could have been added (and might have been in the works). Sure, XDMCP had plenty of other problems, which could have been address with the will to do so. But the later "desktop/login managers" decided that app-level remote usage was verbotten, and the Wayland folks definitely killed it even further.
At one time I wanted to have a Netbook-like device I could use as an X-terminal to my server-grade PC in my home office. Would still be nice to have, but I don't see anyone picking up that project anytime in the next century.
"...why didn't one or two of them say "stuff it, it's not the right answer..."
Some did, Texstar and Patrick Volkerding to name two of the more enlightened ones.
The trouble is, so many distros are reformulations of Debian/Ubuntu and once they jumped on the systemd bandwagon it would have involved a huge amount of work to strip systemd out, and a lot of distros just don't have the resources to do that.
The trouble is, so many distros are reformulations of Debian/Ubuntu and once they jumped on the systemd bandwagon it would have involved a huge amount of work to strip systemd outAnd, if your system is based on Debian why would you bother to strip systemd out? It's trivial to use some other init system in place of systemd on Debian.
if Poettering got it so obviously wrong, how come all the combined experience and wisdom of the contributors and developers of just about every major distribution out there went along with him?
AIUI, with Debian there was a lot of "discussion", and eventually some committee decided to bring an end to the "discussions" by calling a vote. The vote was cleverly worded with more options than just "yes, go with systemd" and "no, don't go with systemd". In the end, by cleverly including other options, it was made to look like there was overwhelming support for systemd and so it came to pass that Debian put the nails in it's own coffin.
In reality, the votes FOR systemd were a minority - but by including votes for "I've had enough with the discussions" etc, the result was rigged.
Of course, there were also the outright lies that I suspect led to more people voting for it than would have been the case had there been any honesty. Lies like "it's only an init" and "you can still use sysv init" - the first being an outright lie as we've since seen how far and wide it's tentacles have gone, the second is a lie by omission because while you can still use sysv int, you can't get rid of systemd entirely.
But prior to this vote, the issue was "how much effort to put into de-systemdising Gnome 3" given that RH has been heavily infecting it and it was getting harder and harder to disinfect it. I think there were even suggestions at one point that "we'll allow it for Jessie, and by the next release we'll have figured out how to remove it" !
AIUI, with Debian there was a lot of "discussion", and eventually some committee decided to bring an end to the "discussions" by calling a vote. The vote was cleverly worded with more options than just "yes, go with systemd" and "no, don't go with systemd". In the end, by cleverly including other options, it was made to look like there was overwhelming support for systemd and so it came to pass that Debian put the nails in it's own coffin.I guess you don't know much about Debian.In reality, the votes FOR systemd were a minority - but by including votes for "I've had enough with the discussions" etc, the result was rigged.
Here's the vote:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6734
The final vote was:
D = systemd, U = upstart, O = openrc, V = sysvinit, F = further discussion
4x D U O V F (bdale, russ, keith, don)
F U D O V (steve)
U D O F V (colin)
F V O U D (ian)
U F D O V (andi)
It's pretty clear that everyone except Ian Jackson wants to get rid of sysvinit, most people are fed up of the yacking, more people want systemd as first choice than any other system (4xD,2xU,2xF).
Re: the so-called "vote"[0], please read this page:
http://forums.debian.net/viewtopic.php?f=20&t=120652&p=576562#p576502
Until then, kindly refrain from talking about matters you clearly know nothing about.
Note: I don't use SysV init, I use BSD init (albeit with a few of SysV's init ideas grafted on where it makes sense to the Slackware maintainers, and a few of my own tricks).
[0] More like railroading ...
It isn't written in nodejs, for instance.
*Shudder*.
Nephew has an account on one of my FreeBSD boxes. For some reason, between one day and the next, node.js stopped working (couldn't find an SQL component that most assuredly *was* installed).
The fix? Re-run the nodejs installer for that component, that finished by saying "already installed, nothing to see here, carry on". At which point his bot started working again.
Hates it we does. What *does* node.js has in it's pocketses? Lots of problems my precious, lots of problems..
systemd was a good idea.
Well, part of it.
Replace the init system with something sane, that allows all kinds of extra features, automated startup dependencies, etc. Hell, even replacing scripts with a real program isn't actually that insane in the modern world.
I would argue that it wasn't "init" that needed replacing, it was "rc".
init is supposed to be the initial launcher (a minor task IMHO, it's eons since we all used serial lines and needed respawning for our getty's) and then it is is the catcher for orphans. The kernel needs somewhere to put them and so the kernel is very attached to PID 1, this is init's job. Since the kernel needs PID 1 to be there it will panic if PID 1 dies.
This is where systemd is going wrong. It is placing something far to complicated inside this orphan catcher.
The other problem with systemd is that they've not define limits on what it is trying to achieve. So it grows off in all sorts of directions. Why does the launcher also want to be the logging system?
I would also argue that launching services at startup from scripts is a better way than launching from inside a "compiled" program. It encourages the developers to make sure everything can be done easily from the command line. It also makes it trivial for admins to see what is supposed to have happened, 30 years ago no one would have dreamt of trying to administer a Unix machine without being a C programmer, for the last 20+ years that's not been the case. But even if the admins can understand the C or other compiled language they can't just walk through the steps by hand.
As someone put in a message a short while back "Don't do anything in C that you could have done in a script".
Personally I'm really not convinced that for most users the boot up speed is a killer. I usually use Linux as a server OS, Red Hat 7 has systemd in "Enterprise" Linux which is mostly used as a server OS and here boot speed isn't a big issue, especially when the POST might take 20+minutes by the time you've got a sensible amount of RAM on board.
So regardless of what is driving the "rc" mechanism I want to see the services started from scripts please.
Strongly agree with everything you said. About
> ... not convinced that for most users the boot up speed is a killer.
see side by side comparison boot up Debian/Devuan (identical times, as also is my experience).
Boot-up speed is an issue in _some_ environments (possible launching and terminating Linux instances in VMs all the time). Now the right way to get fast startup is to (a) boot from an SSD and (b) just start the services you really(!) need. With my setup here, most time is spent with the BIOS's screen(s), after that most of the remaining time is the (short) wait for DHCP. So right here, for me, using a fixed IP would get the biggest speedup (not gonna happen because completely unimportant).
I get the very unscientific feeling that my newer systemd distro boots up just slightly slower than my older upstart distro. I guess that could be other factors at play but they all boot in <10sec now anyway with SSD drives.
I've also run into a seemingly random problem on a few systems where systemd halts for 90 seconds while booting, searching for btrfs file systems which it will never find because they don't exist. Extremely irritating.
"I would argue that it wasn't "init" that needed replacing, it was "rc"."
I was going to say, replacing the idea of fixed numeric runlevels with names (which can still be numeric) could at least be seen as a gradual progression (nothing too different from what's being used now, after all) and would allow the introduction of configurable flexibility (more than 5 runlevels if need be, or less if you want to KISS the system some).
"But replacing it with a big, black box that basically replaces lots and lots of core functionality with its own ridiculous idea of a service in so many areas (DNS, etc.) just destroyed the concept for me."
Indeed. Systemd is entirely Windowsesque. Here's a tiny example from this morning. The command to list services in Ubuntu 14 is "sudo systemctl list-unit-files". Having a long output, you can pipe that in to "more", "less" or your preferred pager, as is the unix norm.
However, like a suspicious friend, systemctl is unhappy that you might be using another tool without talking to it first. So it gets involved. It does the terminal paging. Yes, there is, right there at the bottom of the systemctl man page. Systemd actually contains code to page user terminals. Only by invoking a third party pager, mind you, but there it is nontheless, systemd sticking its nose into the shell's business, to no advantage whatsoever. An annoyance, but also a small demonstration of the design which so many object to, and for sound reasons.
"Init needed a reinvention, but systemd was never it for me."
I disagree. I think System V init works just fine. Sometimes, to get the job done, we can use a tool that was invented thousands of years ago [like a hammer]. Our hammers are about the same, something hard with a flat end that has a handle on it so you can improve the amount of force directed to the head. They're shaped better, maybe with a claw on one side, or for maximum force applied to a minimal area, or shaped for metal work vs carpentry, but they're still basically "hammers".
Init for 'busybox' was a re-invention, actually. It does pretty well at keeping things small for embedded systems.
The single biggest ADVANTAGE of System V style init is its overall simplicity [you can learn how it works from a simple man page], and the flexibility you can exercise in how you might modify it for your own use.
I like shell scripts. You can read them and modify them and clone them and see everything they do, plainly visible, nothing hidden. You don't have to go online and google Duck Duck Go for half an hour just to figure out how to make the system boot up into a CONSOLE instead of a GUI. You don't have to spend a shi boatload of time looking for complicated 'service' scripts to see WHY your version of Linux doesn't support TCP connect for X11 [which you've carefully firewalled for security reasons, but you NEED it] and you can't figure out how you can ENABLE IT, but it appears to already be enabled in the 2 versions that THIS release (say 'Mint') is derived from (say 'Ubuntu' and 'Debian'). I actually need this so I can do a sequence like this:
xhost +localhost
su - differentuser
export DISPLAY=localhost:0.0
some-GUI-program &
it seems that X11 and systemd "integration" has stepped on this ability, which is TRIVIAL if I'm running older versions of Linux (with no systemd) or FreeBSD. [Fortunately still worked in Debian 8, not sure about 9]
Now, about figuring out why I can't do that on the latest Mint... DAMN YOU SYSTEMD!!!
For the downvoters...
*Injects adrenaline and steroids*
Linux Lors, Linux Lord riding through the glen.
Linux Lord, Linux Lord released early to mortal men.
Patches to the left, headers to the right.
Linux Lord, Linux Lord, Linux Lord
Someones had his weetabix.
*looks at his watcb*
Oh shit im late.
*puts on fat suit and tuxedo and runs to his other job*
GO COMPARE, GO COMPARE...
@h4rm0ny
I'm not sure any single person can be "a women".
These days, it's perfectly possible. It's all to do with allowing people to choose which gender pronoun they wish to be referred by, and stuff like that. So a transsexual might choose "he," "she," "ze" or even "they." No, I'm not making this up.
Anyway, even without all that, a single person with multiple personality disorder could (presumably) be "a women."
Male terms can be generically applied to both men and women.
Example, a Naval officer might be referred to as 'Sir' or 'Mr. someone'. Women too. It avoids unnecessary confusion and uncertainty.
A 'Mailman' can be a woman. 'man' is generic for 'human' in this case.
I know the 'womyn' out there (the misandronists) will object, but TOO BAD. When I use a pronoun for an individual whose sex [not gender, that's wrong too] is uncertain, I use 'he'. Not "they". 'They' is BAD GRAMMAR. [see icon]
So 'Linux Lord' is perfectly correct, because 'Lord' can refer to a man, or a woman, using this basic rule of the language. Who gives a CRAP if it's not politically correct, or "offends" some snowflake with a ginormous chip on HIS shoulder?
^^^-- see I did that with the 'his' and did not use 'their'
Besides, I thought the Monty Python reference was pretty good. 'Linux Lord', heh.
This post has been deleted by its author
It is only a matter of time before systemd - and any OS that includes it - gets treated as legacy software
that would be nice, but a precondition here is either a) Gnome gets decoupled from systemd or b) Gnome gets replaced in its leading position and distributions no longer include it. Also, lets not forget udev which will have to be replaced with eudev through (not just in Gentoo )
b) Gnome gets replaced in its leading position and distributions no longer include it.
I don't think "Gnome (another fine RH project)" in an earlier comment was intended to be a compliment.
Also, lets not forget udev which will have to be replaced with eudev through
OK by me.
This post has been deleted by its author
"Gnome gets decoupled from systemd"
there's always 'Mate', and the guru that maintains the gnome 3 port on FreeBSD seems to have found a way [probably by patching heavily; I haven't tried gnome 3 on FBSD and probably won't]
/me running FreeBSD 11 with Mate at the moment. it has PulseAudio installed as well. No ill effects.
Now, a CentOS fork without systemd... Centuan?
And as long as the software you write for Linux does not require systemd, Gnome 3's internals, or some package that tries to depend on systemd, you should be fine. I suggest statically linking EVERYTHING, if you can't ship it as source to be built on the destination platform, or at least for the binary distribution [so it runs everywhere, doesn't require particular dependencies, etc.]
My home systems were Debian. I didn't do a clean install of Devuan, I just changed repositories, so that upgrades wouldn't include systemd dependencies. It's been completely painless.
I use GTK-based applications, mostly, and they all work fine.
I've pre-emptively removed udev as well, in case it is absorbed by systemd. I know it's a flagrant breach of the Unix philosophy of "do one thing and do it well", but I use mdev, one of the many faces of busybox, to handle hotplug events.
Well, if the UNIX philosophy is "Do one thing and do it well," two questions bug me. One, how can one be sure the one thing a program is doing is actually doing it RIGHT. Doing one thing but doing it WRONG presents weak links in a process chain. Second, explain busybox.
One, how can one be sure the one thing a program is doing is actually doing it RIGHT.
The modern answer would be unit tests, which are easier to do on modularized programs. However, the idea that if all the pieces are right, the whole will be bug free is wishful thinking. A lot of bugs creep in at the interfaces.
IOW, gestalt faults (or gestfaults, for short). Things that never show up individually but crop up when put together (the whole is worse than the sum of its parts). And that's another potential fault point for a process chain: "trusting the welds", so to speak, since you can't be sure the two programs were built by the same teams with the same goals and same philosophies and expectations. If they don't, and they don't explain everything, an edge case can hit where the sender sends something the receiver doesn't expect.
"The modern answer would be unit tests, which are easier to do on modularized programs."
Another is long experience observing the thing to work correctly (also easier if it only does one thing) coupled with if-it-isn't-broke-don't-fix-it. And throw in if-you-fixed-it-and-it-broke-everything-around-it-you-fixed-it-wrong-so-go-back-and-try-again-instead-of-trying-to-fix-everything-else.
My home systems were Debian. I didn't do a clean install of Devuan, I just changed repositories, so that upgrades wouldn't include systemd dependencies. It's been completely painless.
I didn't know you could do that, thanks for the info.
I'm still on Debian, but Jessie is the end of the line.
Last time Linus sounded a faint praise (of BitKeeper), git was born.
It is possible that Linus is one of those people who heaps insults and swearing upon those he thinks may be capable of improvement, whilst those who are beyond redemption are damned with faint praise.
I sure as hell hope so.
Those of us who were paying attention read that but could see the handwriting on the wall long before it was written. ;) Been working on Devuan since the fork was announced after the GR vote debacle. This link - Combatting revisionist history - explains how the vote went down in detail:
http://forums.debian.net/viewtopic.php?f=20&t=120652
I have a laptop running Slackware. It only gets rebooted when required due to a software upgrade (usually kernel related these days). The last time I rebooted the Wife's computer (for Slackware's June 30th Kernel upgrade) it had been running since mid December. I never did understand the supposed importance of faster boot times. Linux ain't Windows, it doesn't need rebooting regularly.
> I have thousands of servers running CentOS6 and CentOS7. The boot times are identical.
systemd is supposed to give faster boot times by allowing some start up operations to be performed in parallel. That's the theory.
But then they go an make RHEL7 do more at startup so they can loose the advantages that systemd was trying to achieve.
A great example of this is when you boot a server with several LAN cards in for installation. The new startup wants to DHCP each NIC but doesn't do it in parallel and has a hard codes 1 minute timeout. So if you got a server with a shed load of NICs which aren't on a network which offers DHCP then the boot takes bloody ages. Of course there is an option to say you only want to use a particular NIC and control how it will be configured, but it isn't always easy to determine what it will be called.
Anyway the theory is that systemd allows things like services to be started in parallel, but the practice and the theory are two very different things.