Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror

Comment Re:BDSM convention (Score 2) 238 238

It seems to me that a systemd conference wouldn't be much different from a BDSM convention.

The BDSM convention will have a higher percentage of protected sex, and nearly everyone getting screwed will be doing so consensually. Most of them will have a good sense of humor about what they are doing, heavy D/S tops aside.

Comment Re:Startup management subsystem (Score 1) 238 238

Did you ever think, perhaps, that the conference is a way to get commentary and feedback on a project that's thus far been fairly controversial

I think that's a great idea, but how many people do you think they're going to invite to speak who hail from the other camp? The "What the fuck are you doing to everything we love" camp? I'm betting it's going to be a big, fat goose egg. And even if not, we've seen how Lennart responds to critics, it's a big part of why so many of us dislike him so.

Comment Re:Startup management subsystem (Score 1) 238 238

If Poettering uses the same communication methods as everyone else for managing his highly used open source project, then systemd is doing this because it can only get ahead without feedback.

If, OTOH, Poettering goes so far as to organize a public conference on his project, then his project is "doing too much".

Did you ever think, perhaps, that the conference is a way to get commentary and feedback on a project that's thus far been fairly controversial (largely for ridiculous reasons by people who think sysv init is a good idea?)

Comment Re:Startup management subsystem (Score 1) 238 238

I think you need to read up about cgroups - https://en.wikipedia.org/wiki/... - or are you saying cgroups are a solution looking for a problem?

No, I'm saying and I have said before and I will say again that cgroups are simple, did not require a new init system, and can be manipulated from shell scripts.

"Most distributions use standard init script libraries where such initialization can take place." -not really, you can't always transfer a script from one distro to another and expect it to work without modification which is another problem systemd has addressed

That's a problem, but not an insurmountable one, and again, one which could have been solved with a unit script processor (which itself could be a shell script) rather than a whole new init system — I've pointed that out repeatedly, as well.

Comment wow (Score 1, Funny) 41 41

How much does it cost to get your slashvertisements accepted verbatim?

China's 33-petaflops Tianhe-2, currently the fastest supercomputer in the world, while still using Intel Xeon processors, takes use of the home-grown interconnect, arguably the most important component of modern supercomputers.

But where does it take it? To the movies? I hear you can get in for just fifty cents.

Comment Re:Startup management subsystem (Score 1) 238 238

You don't seem to realize that an init script is SUPPOSED to terminate...

I've written init scripts, I know how they work, thanks.

systemd cannot restart the init script.

An init daemon could re-run the init script with the "status" option, and if that exited non-true then it could re-run it with the "start" option, and if that exited non-true then it could give up and interrupt the boot process. That systemd can't do this is not my problem. That systemd won't do this has caused us all problems.

But systemd cannot use the init script OTHER THAN as a one-shot run.

That's because systemd is stupid.

Comment Re:Ah, Berlin (Score 2) 238 238

I really don't get the fetish for text file configuration that Linux has.

And that's why you, and people like you, persist in trying to ruin Linux. You don't understand why it's successful.

The ones I hated the most were init scripts that were common a few years ago which every source on the internet said "they're just like shell scripts," but they clearly weren't as there were commands in there about dependancies and somehow the same script managed starting a service and stopping it, but no one had documented the syntax anywhere because they thought it was too easy, and as a result, it was an init system I never used.

Just admit it: you don't understand shell scripts. Once you admit that, life will become a lot easier. You'll pick up a book on the subject, perhaps, or you'll read some websites. Then you'll learn how to read the scripts, and figure out where they're getting those "commands" that don't appear in the filesystem, not even when you use find instead of which. You'll see that they source a library at the top of the init script, and you'll follow up and read that library and you'll figure out how those variables at the top of the script which handle dependencies work. And then you'll see that there is really no need for systemd; cgroups support could have been added to those shell scripts, for example.

but nearly all text configurations suck, e.g. if you want to change a setting for which there isn't an example, you then have to spend hours reading the manual and testing ideas to figure out how to type something up which the software will parse as commands to make it do what you want. If the software had a GUI configuration tool like virtually every piece of modern software has, you could just look through a few logically-named tabs until you found the option you need, then just check the box beside it

Binary configuration files don't solve this problem! They don't magically make GUI configuration dialogs appear! Many Unix programs have complicated configuration files with no GUI to configure them because what they do is complicated, and a GUI capable of fully configuring them would also be very complicated. You're not going to automagically get GUI config tools for all those programs. If you outlawed ASCII, human-readable config files tomorrow, what you would actually have is a hodgepodge of different binary configuration file formats, each with their own inscrutable command-line tool for manipulating them.

It's also worth noting that many if not most windows programs have text configuration files! So, are you trolling, or do you really not understand that this is not the point of contention? It's over binary log files, not config files! Even systemd has ASCII configuration files! For now, anyway...

Comment Re:It was bound to happen. (Score 1) 156 156

all wealth is derived from the land

So nobody ever has created wealth without land?

There are no wealthy actors, musicians, authors, or anyone in the tech industry? Huh, guess I'll go buy me farm.

Are you really this dumb, or do you just want an argument? I've had this argument before, and it was dumb that time, too. The short, short form is "where do you think the electricity to run the internets comes from? Magic fairies?"

Comment Re:People who like systemd (Score 1) 238 238

The distros are using systemd because it makes writing startup scripts easier. They take up fewer lines. That's about it. It has nothing to do with DevOps." -

you mean configuration files, not startup scripts.

No, no he does not, and there is no obvious reason how you might come to that conclusion except deep ignorance. The configuration files for the programs differ little when systemd is involved. The startup scripts are intended to go away, and be replaced by unit files, which are indeed easier to write than init scripts as they are simply a collection of variables. They are organized into sections segregated by square brackets like a windows ini file, but AFAICT the names of the variables are all globally unique anyway (corrections welcome) so you could reasonably just stuff a unit file into a script that would suck it into the environment and then do stuff based on the unit file to implement a really dumb shell script that would be more difficult to customize than what we have now — init scripts which can implement as much functionality as desired.

I was suggesting the internet would have been ablaze with structured factual comments from these "devops", letters to Redhat etc. a bit like the Devuan guys who put their money where their mouth was and are making their own way without systemd.

DevOps doesn't mean much, I share your skepticism of overuse of the term. It's from Agile, and may or may not have useful meaning outside of Agile-land... which itself may or may not have useful meaning.

On the other hand, I keep hearing that systems administrators who use cloud services and are thus "administering" umpty-hojillions of "machines" enjoy systemd because reasons, but I never see a citation for that, either.

It should be a large movement capable of stopping systemd developing if they actually existed

You can't stop systemd from developing, especially since it had corporate backing. And for people who don't follow every distribution's MLs, systemd sort of snuck up on us. We didn't imagine that debian would convert to systemd, for fuck's sake. Statistically nobody even imagined that until it was happening. Who would have ever thought that the one time Debian moved quickly on something, it would be something contentious?

Comment Re:Startup management subsystem (Score 1) 238 238

it also solves the problem with fossilized development of subsystems like init and logging,

Not a problem, and also not actually a thing. Several competing init systems which didn't bring baggage with them already existed, but Lennart is a real NIH kind of guy so he didn't start with one of those. Stable init and log daemons are features, not bugs.

systemd, as init and process manager, actually takes on the coordination responsibility that lacked previously. It is way cool how "namespace" isolation and kernel Capabilities(7) are integrated

You do realize that cgroups is a thing you diddle with very small commandline programs, right? And by making directories? These are things which could be done in init scripts. Most distributions use standard init script libraries where such initialization can take place. It didn't require a whole new daemon; at most, some minor changes to again one of the existing competing init daemons would have been a fine place to start. Not tying it to a specific log daemon is the really important part, though! A whole new init system would be a whole lot less odious without a whole new log daemon with serious design deficiencies — especially breaking the human-readability component of the Unix Way that made Linux (as an imitation of Unix) successful to begin with.

y dismissing every systemd feature and everything systemd does as "bad"

No, what is being dismissed as bad is the NIH attitude, the proven lack of maturity (in all senses) of the primary developer and maintainer and his code, and the dismissing of what is tried, tested, and therefore true as old, outdated, and obsolete.

The cost of feathers has risen, even down is up!

Working...