Forgot your password?
typodupeerror

Comment: Re:Not a problem... (Score 1) 251

by swb (#47940805) Attached to: New Study Projects World Population of 11B by 2100

I thought the one with the population density of Houston was more interesting as it implies a more livable density than Manhattan. A slight reduction in density might allow for grow-local kind of agriculture, too.

There might be actual incentives to encouraging the development of a megacity. The energy savings in transportation would be huge and there's probably a lot of other economies of scale to be gained. If other populated areas became equally less dense the environment might improve.

The downside is that all big cities have a gross aspect to them, especially poorer ones.

Comment: Your DL and plates are fucked, but phone works? (Score 1) 433

by swb (#47939247) Attached to: Apple Will No Longer Unlock Most iPhones, iPads For Police

So the brick managed to destroy the license plates and your driver's license or other cards with your name on them in the car, but your fucking phone still works? And you happen to have a contact for your wife in your phone that says "WIFE" and not just her first name?

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

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) 350

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) 350

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) 350

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:well, duh? (Score 1) 283

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) 283

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:Must be an american thing ??? (Score 2) 46

by mcgrew (#47935755) Attached to: More unsurprisingly conservative ads on slashdot

You can get your old account back if you can remember what your email address was. Send a note to help@slashdot.org.

I'd lost my account and they were very helpful about it.

As to your surgery, LISTEN TO THE DOCTOR!!! Helping that one person could prevent you from helping others in the future. Oh, and I empathize; I had a vitrectomy in 2008. Not the least bit fun.

Comment: Re:Are you even aware of SystemD works? (Score 0) 350

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) 350

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:When doing anything involving the ocean (Score 4, Interesting) 190

by swb (#47930343) Attached to: Wave Power Fails To Live Up To Promise

The original screws were probably bronze, not brass. Bronze has no appreciable zinc while brass contains a lot of zinc. Immersed in sea water, brass will dezincify and corrode.

Most marine raw water systems use bronze fittings for this reason.

Stainless isn't suitable for below the waterline applications because the chromium can't form a protective oxidization layer due to the lack of oxygen exposure.

Your boat would have sunk with brass or stainless screws.

Comment: Re:Simple set of pipelined utilties! (Score 2, Informative) 350

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

Xorg, which on desktop is as critical as init to keep running, is not really simple.

Never go full retard. X is not even remotely as important as init. For one thing, if X dies, who will restart it? And do we really want computers that explode when the GUI dies? I, for one, would like network services to terminate gracefully. The whole idea of TCP/IP networks, the dominant network used with Unix, is peer-to-peer. I may well run both services and clients on my machine. If X dies, the clients may die (if they're not text and running in screen) but the servers won't.

kernel, which is also as critical as init to keep running, and it is *much* *much* more complex than systemd. systemd is not at the "bottom layer" of the system, there's the whole of kernel underneath still.

So the argument is that since the kernel is complex, we should add more complexity, or that more complexity won't matter? That's an ignorant, illogical argument.

And one common myth is that systemd has these so many features and systemd is pid 1 therefore pid 1 is this huge bloated monster that does udev, logging and NTP, right? Wrong; actually, just the core bits of systemd run in pid 1 and the rest is compartmentalized in a bunch of separate daemon processes.

Systemd still has to be more complicated so that it knows how to run these other processes, which wasn't even necessary. init was never meant to manage daemons. daemons were meant to manage themselves, or be run from inetd. If you want more complexity, inetd is the place to add it. And for handling daemons which don't adequately manage themselves, there's daemontools. There was simply no need whatsoever for this to happen.

So, this "increased complexity" issue is not really as bad as it sounds, realistically.

It is bad, because PID1 is now responsible for a bunch of things which could have existed in any other daemon. And rather than roll the things which actually make sense in together, everything is getting rolled together. So now not only do we depend on a complex kernel, but we depend on a needlessly complex init system. There was no good reason to put all of this stuff into the same daemon.

There are three kinds of people: men, women, and unix.

Working...