Forgot your password?
typodupeerror

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

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

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:More importantly (Score 5, Insightful) 333

by bmo (#47930159) Attached to: Is the Tesla Model 3 Actually Going To Cost $50,000?

That battery will NOT last forever,

And neither does an internal combustion engine, either. Your point?

and when it needs a new one you'd be better off scrapping the entire car and buying a new one.

Citation needed. Seriously.

How good is that for the environment?

Awesome, actually. The battery can be recycled, and there aren't any heavy metals to deal with either.

--
BMO

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

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.

Comment: Re:Simple set of pipelined utilties! (Score 3, Informative) 327

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

You can't seriously claim that systemd provides nothing that can't be done by script based init systems, shell scripts and existing daemons

Yes, yes I can. And I did.

logind is just one example

Does nothing a script can't do

But it would be an interesting project to make a Linux SysVinit distro that tried get feature parity with systemd, so that daemons could utilize the kernel "namespaces" and "capabilities"

Systemd doesn't even fucking use capabilities, just cgroups. Which we could use before systemd. Systemd manages permissions in lieu of using capabilities, e.g. apparmor or selinux.

Isn't that argument just trying to make a virtue out of the fact, that SysVinit and the like, are totally crude and primitive init systems that are unable to anything much of interest?

No. That is the virtue. They are simple. Simplicity is still a virtue.

All the analyses I have seen shows that moving crucial processes into PID2, just makes everything more fragile and opens up security holes.

Making PID1 more complex makes everything more fragile and opens up security holes.

I think that there are actually very good design reasons for why systemd is designed like it is.

NIH

It only runs one process as PID1, the daemon "systemd" which is rather small. This daemon however, is capable of "talking" with with several other processes, which gives it many advantages,

This is making init do stuff it doesn't need to do, which makes it more complex, which makes it more fragile. You should not need a detailed explanation to understand why this is a bad thing.

Comment: Re:Are you even aware of SystemD works? (Score 4, Informative) 327

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

You don't seem to understand how SystemD actually works. The PID 1 is relatively simple -- it uses all sorts of separate (i.e. non-PID 1) helper processes to do all the heavy and complicated lifting.

Lifting which should not be done by PID 1. And PID 1 has to be more complex than it should be just to handle those external programs.

SystemD currently does a fuckton of stuff no other currently usable init system on Linux does.

It does a lot of stuff the init system shouldn't do.

(Reliable process supervision which cannot be evaded,

cgroups existed before systemd.

sane handling of process stdout/stderr

Up to the init script.

proper handling of dependencies at runtime

Already handled by several init systems.

socket activation

We call it inetd.

I don't particularly care which init system my system runs, but I want those features and currently only SystemD can deliver them.

That is ignorance at best, or perhaps a lie.

Please stop spreading FUD about things you know next to nothing about.

You have no idea about anything, that didn't stop you. I see why you didn't log in.

Comment: Re:Simple set of pipelined utilties! (Score 5, Insightful) 327

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

If you really buy that principle and want to enforce it religiously,

It's not a religion, it's a principle. When it makes sense, you put it aside and get work done. The argument against systemd is that it doesn't make sense. systemd is a simple case of NIH because it provides absolutely nothing which could not be implemented with the existing daemons and some small shell scripts.

That't the issue: Every single person who hates SystemD because "UNIX PHILOSOPHY!!" has no problem violating that philosophy to actually get things done in a whole bunch of other areas.

That's right.

That's not even bringing up the fact that SystemD is.. wait for it... built from a bunch of individual utilities that can actually be used by non-systemd programs.

That's not the complaint. The complaint is that the process at PID 1 should be simple. You people running around screaming about a bunch of different processes are only compounding the proof that you do not understand Unix. It's not a problem to have many processes.

Comment: Re:Carpooling should be as free as speech (Score 1) 288

by drinkypoo (#47925191) Attached to: California Declares Carpooling Via Ride-Share Services Illegal

Of course it's who they approve of - because the point of carpool lanes is to effectively remove significant traffic and air pollution, and they felt that Uber doesn't qualify.

Bullshit, they're still letting licensed commercial vehicles use the HOV lane. The fact is that HOV lanes are shit. They're a waste of space which accomplishes none of the stated goals. Simply adding another general lane does more to reduce emissions, because it does more to reduce congestion, and thus reduces idling — where vehicles without start-stop systems get 0 MPG and thus are producing pure pollution. They're always trying to justify the existence of HOV lanes with bullshit like this, but they still are unjustifiable.

Comment: Farmers != Farm Workers (Score 0, Troll) 113

The headline says farmers. The text says farm workers. Very much not the same thing. A farmer is the owner of the farm. A farm worker is generally a hired hand, often (though not always) a migrant, and if so typically from Mexico or farther south.

The story suggests that the multi-drug-resistant bacteria are the result of antibiotic treatment of the animals at the farm. This misses another possibility:

In Mexico, most antibiotics are over-the-counter, much like asprin here in the US. People who feel ill or have some infection often buy and take them. Typically they use them until they no longer show symptoms - then stop, rather than taking a full regimin and killing off all the bacteria. (Why take more of the non-free drug once the symptoms are gone? Waste of money, right?) This is a recipe for creating drug-resistant bacteria.

Of course if an infection is resistant to one antibiotic, a paitent is likely to try another, and another, and so on until they find one that works. THAT's a recipe for maintaining and improving the bug's resistance to the front line antibiotics while breeding resistance to others.

As a result, a substantial fraction of the workers arriving from south of the Mexican border are carriers of multi-drug-resistant baceria.

Meanwhile, a farming operation is likely to give a limited number of antibiotics continuously, so non-resistant infections are wiped out before they can develop resistance, and if they do develop resistance it will be to the particular drugs used, rather than the universe of antibiotics.

Of course, infected workers can infect livestock, just as livestock can infect workers. And infected workers can trade infections around, just as livestock can. (More so, since the livestock tends to be kept separated, to reduce both disease spread and breeding by unintended pairings, limitations that farmers can't impose on their workers - and would be unlikely to try even if they could.)

So it seems to me that responsible researchers would go a bit farther before reporting: Like by doing genetic testing on the strains of bug in the various workers and the livestock, and running models on the results to try to identfy whether the bugs are from the herd or the workers.

I don't see any such work alluded to in this popularized reporting. It seems to just assume that the bugs were developed on the farm and spread to the workers. I hope this is a disconnect between the actual research and the report, rather than an accurate characterization of the research.

Comment: Re:Silly design decision (Score 1) 407

by drinkypoo (#47922187) Attached to: Apple Edits iPhone 6's Protruding Camera Out of Official Photos

Phones have big screens now, so they need armor anyway. So since you're going to put armor on the phone, you want the phone to get thinner, so that the phone with a case on it is still thin. Just making the phone thin allows the user to put whichever case on it they like, so they get to personalize their phone and you don't have to try to anticipate their needs, instead letting the whole world do that. And that's why having the camera really doesn't matter. In fact, having the bezel around it protrude from the camera probably helps protect that side from scratches. What's the problem, planned to slot-load the phone?

Comment: Re:Carpooling should be as free as speech (Score 1) 288

by drinkypoo (#47917535) Attached to: California Declares Carpooling Via Ride-Share Services Illegal

Even with the new rules that for-profit "ridesharing" (i.e. independent taxi service) can't use the carpool lane, ANYONE with more than one person in a car not charging the passenger gets to use the lane,

Right. Because someone is charging for something, they're not permitted to use the lane. That's prejudicial, since both people who are not charging and people who are charging but have a license to do so are able to use the lane. So it's not ANYONE, it's ANYONE YOU APPROVE OF.

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (8) I'm on the committee and I *still* don't know what the hell #pragma is for.

Working...