Forgot your password?
typodupeerror

Comment: Re:Simple set of pipelined utilties! (Score 1) 339

by drinkypoo (#47938907) Attached to: Torvalds: No Opinion On Systemd

They think it's about limiting yourself to pipelines, but it's not. It's about writing simple robust programs that interact through a common, relatively high level interface, such as a pipeline. But that interface doesn't have to be a pipeline. It could be HTTP Requests and Responses.

It's an ASCII pipeline any time that it's feasibly and meaningfully human-comprehensible; that is part of the Unix way. Any other time the format varies broadly, and has been all sorts of things including BDB — which has all the same problems as binary log formats ala systemd. Since the user-perceivable output of javascript in a browser is XML, you reasonably could use STDIO in a very normally Unix-y way.

Comment: Re:Yes, pipelined utilities, like the logs (Score 1) 339

by drinkypoo (#47938825) Attached to: Torvalds: No Opinion On Systemd

Sometimes new stuff is actually much better than then old stuff. I was skeptical about binary logs until I actually tried it. The advantages of a indexed journal is overwhelmingly positive. "journalctl" is an extremely powerful logfilter exactly because of the indexed and structured logs.

None of which requires that logging be moved into PID 1. Instead, all you need is the ability to support a new log format in some syslogd. Unless you were some kind of moron, you'd design the new program to be able to log to both text and binary formats at the same time so that you could enjoy the benefits of both formats. Systemd may or may not do this, I don't care; there's no reason whatsoever why logging should not be a separate daemon.

Comment: Re:Simple set of pipelined utilties! (Score 1) 339

by drinkypoo (#47938793) Attached to: Torvalds: No Opinion On Systemd

If PID2 is responsible for critical features like eg. cgroups which affects all running processes, including PID1, then it won't make a difference.

cgroups is a kernel feature. It doesn't stop working because whatever process you're using for cgroup management dies. The process comes back, reads the state from /sys/fs/cgroup, and resumes doing whatever kind of management you wanted. If PID2 only manages cgroups, and cgroups' state is maintained in the kernel (which is is) then it doesn't particularly matter if the daemon craters, so long as you can restart it. But absent many requests for cgroup management, it may not actually even need to be long-running.

The only reason that we even need a daemon for cgroup management is that we're making inadequate use of capabilities. When a user (or script) runs a tool which creates cgroups via a mount, they should not need to use any tool for privilege elevation because they should have the right to manipulate one or more cgroups in one or more approved ways — which can consist of a couple of lines in a file which is sourced by init scripts. In systems with init scripts of any complexity, all of which source external files, no changes need appear in them whatsoever.

Comment: Re:Simple set of pipelined utilties! (Score 1) 339

by drinkypoo (#47938645) Attached to: Torvalds: No Opinion On Systemd

Even with a[n old, slow] HDD it only takes about a minute to boot my Ubuntu PC, and that's with a stupid-long POST to deal with the second ATA controller's stupid-long POST added to the base machine's stupid-long POST.

With that said, I am not against improvements to boot speed. I simply question the need for a replacement for PID 1.

Comment: Re:what is this even talking about? (Score 1) 67

by MightyMartian (#47937617) Attached to: An Open Source Pitfall? Mozilla Labs Closed, Quietly

Indeed. And quite often even dead FOSS projects can be cannibalized. The difference between dead open source and dead closed source projects is that the bones of one sit in an open pit that anyone can pick at, and the other sits in a concrete bunker twenty miles underground.

Comment: Re:well, duh? (Score 1) 247

by drinkypoo (#47936885) Attached to: FCC Chairman: Americans Shouldn't Subsidize Internet Service Under 10Mbps

If you define "has" as "has within a mile," then you're absolutely correct. If you define it as "has passing the home," then definitely not.

I live on a paved road and I'm several miles (at least three) away from fiber. Literally the only company with fiber into my county is AT&T, and as you likely know, they are bastards of the first degree.

Comment: Re:10Mbps is still slow (Score 1) 247

by drinkypoo (#47936529) Attached to: FCC Chairman: Americans Shouldn't Subsidize Internet Service Under 10Mbps

Minimum standard for what? 2014? Per individual? Per family? Per household? Per block? Per neighborhood?

Please try to keep up.

1. Standards change. 10Mbps might be an acceptable minimum today, but it certainly won't be in 2024, let alone 2054.

1. Standards change.

The devil is in the details.

So is the wankery of your comment.

Comment: Re:Are you even aware of SystemD works? (Score 1) 339

by drinkypoo (#47934955) Attached to: Torvalds: No Opinion On Systemd

cgroups existed before systemd.

the cgroups functionnality existed in the kernel but wasn't really used that much before. [...] whereas current /etc/init.d/apache can't without fumbling of shell scripts.

Yes, my argument was that altering the init scripts would have solved most of what systemd solved. Thanks for confirming that.

each script end up fucking things up in its own original and different way.

The scripts are unified by maintainers. I've already made the proposal that you could actually interpret unit files as init scripts, with the right parser which basically stripped out the sections in brackets, dumped the rest of the content of the file into a series of variables by sourcing it, and then running a unified init script. This would work just fine for any daemons which are long-running, without any complex work. All you'd need is a hashbang at the top of the unit file.

proper handling of dependencies at runtime

Already handled by several init systems.

None of which are the original sysvinit.

Congratulations, you just hammered home the point that you don't understand Unix, while simultaneously proving that you don't understand sysvinit. Using fancy scripts with the original sysvinit is still using the original sysvinit. You are witnessing the awesome power of the Unix philosophy. Because sysvinit is small, simple, and completely modular, the scripts could be extended to provide functionality which sysvinit didn't try to claim for itself. Instead of moving more functionality into PID1, the functionality can be implemented at the script level.

Or cron if it's time-based activation. Or udev if it's hardware based activation. Etc.
Why do we need 83 different way to start some code ?!
Wasn't the whole point of Unix philosophy having one piece of software which concentrates into doing one thing and doing it well?

You failed to understand the Unix way. It's not to have one piece of software. That's the systemd way. It's to have many pieces of interoperable software which can be combined to perform complex tasks, and reconfigured to perform other complex tasks. So we have cron and at (which are often merged) and we have udev and inetd. And each of these things does one simple thing. It's not unusual to want to start processes in multiple ways, that is in fact common to all modern operating systems. You can start them from the command line, you can schedule them, you can start them from the GUI. Is that a problem for you?

Before, you'd have the same concept spread into a dozen of different systems, each only doing part of that functionnality.

And you still do. Only now, they're all managed by one process which, if it craters, will not just cause them all to fail, but which will cause a panic. Great idea!

if you don't like it, don't use it.

That's getting harder to do as people depend on it. I may finally have to go back to BSD.

Comment: Re:Simple set of pipelined utilties! (Score 1) 339

by drinkypoo (#47934933) Attached to: Torvalds: No Opinion On Systemd

It uses kernel namespaces and capabilities to protect the system; this is on top of SELinux etc.

Well then, I sit corrected on this one point. And finally, we have found something for systemd to do. I propose that we stop using it as init, strip out all the shit better done with a script, and use just that part. Perhaps it can be reworked into a replacement for daemontools. That would make a lot more sense than eating up all these daemons which work fine on their own.

Comment: Re:some renewable techs didn't pan out (Score 3, Informative) 182

by TapeCutter (#47932857) Attached to: Wave Power Fails To Live Up To Promise
South Australia is 30% renewable despite a current federal government that is openly hostile to clean energy. The reasoning behind that ideological hostility is not difficult to spot - coal is our #1 export. India has recently declared that large scale PV solar is cheaper than Australian imported brown coal and is switching 400M people to solar over the next decade or so. Prices for coal are way down and mines are currently being mothballed, even those mining the high quality coking coal used to make chinese steel have seen recent mine closures.

The anti-science luddites in charge of this country can see the writing on the wall for the global coal industry, the words "stranded assets" are scaring them shitless. They lack the wisdom and intellectual independence required to plan a smooth transition so they do what politicians do best, fight it tooth an nail with tabloid propaganda and rigged domestic markets.

Algol-60 surely must be regarded as the most important programming language yet developed. -- T. Cheatham

Working...