Follow Slashdot stories on Twitter


Forgot your password?
What's the story with these ads on Slashdot? Check out our new blog post to find out. ×

Comment Re:It's idiots like this... (Score 2, Insightful) 155

I hate the idea of an R/C license... but if it keeps the selfish idiots grounded then it's probably the way to go. Unfortunately.

Is this like how we keep drugs off the streets, guns out of the hands of criminals, and unlicensed drivers off the road?

How many times...

Comment Re:Toilet paper and timber? (Score 2, Informative) 244

With paper, the tree is crushed. Why would you need a large straight tree for that? Economics re-enforces this. You're not going to pay extra for a large tree just to crush it

What? Have you even been to an active paper company forest?

This reminds me of the Mike Rowe's TED talk about how a lot of people talk about things they think they know.


Comment Re: hacking (Score 1) 107

I've actually been thinking of changing my open "Guest" SSID to "Password is guestaccess" and put WPA2 PSK on it, for better guest privacy. I wouldn't consider it hacking for somebody to use it. Just be careful with terminology and specificity before somebody carelessly outlaws more useful things (like the firmware that letd me do those useful things).

Comment Works better w/multiple "friendly" test subjects (Score 1) 155

Doesn't sound like a fun process to go through by yourself, could be interesting, in a large enough space, with other participants.

Otherwise, lots of books on tape. And whatever sort of setup they use when teaching braille, might as well come out with a new skill.

Comment Re: Short answer? (Score 1, Troll) 182

don't abuse Shannon's Law like that. There are ways of rotating and polarizing the waves to get thousands of times more information out of every frequency range. Shannon's Law only applies to each specific modulation. There was an article here on work in the lab to commercialize this in the past year or two. Most FTTH use cases could be replaced with this, although FTTH can roll tomorrow and this is still vaporware - 15 years is a lot of productivity.

Comment Netflix is Tanking Hard (Score 2) 293

Look at the new and leaving content for this month - it's almost all junk (with slightly more quality stuff leaving than coming).

Netflix is still showing me "New Episodes" for stuff I watched 6 months ago. A friend of mine said recently, "I spend more time looking for something to watch on Netflix than I do watching Netflix".

I just started requesting DVD's again from Netflix (send back the first one in two years yesterday) and my kids watch YouTube all the time anyway - I'm pretty sure there's no reason for me to keep the streaming service at this point. I wonder if I can cancel that separately. I still have 300 discs in my DVD queue and feel silly for trying to use the Internet instead of USPS for digital content.

Comment Re:Bullshit (Score 1) 744

I don't agree that was the situation by 2014 and earlier this year. I think by then the chain of dependencies was starting to form that was making things increasingly nasty.

a) There were loud objections to systemd which would normally cause Debian to back off
b) The dependencies were making it clear that Jessie was the last Debian distribution that not tying onself to systemd and remaining a mainstream distribution would be viable for. So the question was really switch now or switch in 2.5 years when the switch would be even more painful.

I do agree with you on the interfaces last longer than cold post BTW. I think that while systemd is a huge plus. Replacing systemd say 20 years from now will be very difficult. Essentially the modules will each need to be reimplemented in a way that's backwards compatible, offers what the future features are and allows partial implementation. The kinds of problems say Microsoft, Apple, DEC or Sun had in pushing forward. I'm a fan of tight vertical integration but there certainly are counter arguments against it and for loose coupling.

Comment Re:BSD is looking better all the time (Score 1) 744

.I worked with Linux-HA before systemd, and I of all the problems, I don't recall init scripts being one of them.

The problem isn't init scripts it is what to do with chains of dependencies on high availability. If you worked in Linux-HA think about the application specific restart code that each application had to do and how fragile it all was.

That's an interesting thought.......have you ever supported Oracle Financials or similar? Do you have experiences you can share?

I help people migrate to cloud. IaaS/PaaS is a godsend in getting complex application stacks working. I can offer experience there that what I'm finding is not that people want a lighter thinner init-system but they want an process manager which is capable of intelligently handling

resource orchestration, resource monitoring, resource provision and resource balancing
virtual machines: backup, restart, status...
storage virtualization: especially backup
network virtualization
continuous test
continuous delivery especially decommissioning a
security validation
database monitoring ....

They all want an much richer environment of management tools. In real life I've never met anyone who thinks systemd is too thick, they all argue it is too thin. The amount of time IT people spend worrying about basic things like messaging across security zones is infuriating to management. Mostly now that Linux is taking on the workloads of mainframes I'm finding most companies want Linux to offer the kinds of services you would find on mainframes (but more modern).

Comment Re:Ever stop and ask why? (Score 1) 744

It was "just an init system" when it was made the init system in Debian "jessie", the most recent release.

No it wasn't. There was certainly an earlier debate about which init system which ended with Debian not having to make a choice. But the debate for Jessie was about systemd dependencies most of which were not tied to init.

Please justify your version of historical determinism.

Saying X happened for reason Y isn't historical determinism it is just an assertion about historical fact. This particular fact isn't even contested the people who did POSIX were quite openly doing it to advance open systems.

We know from innumerable examples that it isn't true; and we also know that since POSIX, the open system specification, won the war against vendorized UNIX

POSIX was for vendorized UNIX. POSIX advanced the proprietary Unixes. What killed them was NT and Linux, the advantages of x86 hardware mostly.

since POSIX there haven't been any successful closed systems

NT was after POSIX. OSX is a UNIX that came after POSIX.

That is very much an ad-hominem attack.

An ad-hominem attack is saying argument X is wrong because Y is a bad person. Saying Y gets treated badly because he's a bad person is not an ad-hominem attack. So saying that the anti-systemd people being jerks proves that systemd is a good idea would be ad-hominem saying the anti-systemd get ad-hominem attacks for lying and ignorance is not ad-hominem though it is not polite.

Besides, if they're such ignorant liars, couldn't you just point them at a FAQ and be done with it,

I've done so. I try that too when their are factual claims.

Comment Re: There's an easy solution to this problem...Tru (Score 1) 214

That's retarded. I'm sending my Auto to go get the kids and/or the groceries.

Let's just go back to the pre-Industrial age when everybody was "safer". OR - we could stop supporting corrupt, murderous regimes that piss everybody off. The Future or the Past - one will win.

Comment Re:Best coverage (Score 1) 142

European carriers are often subsidized more heavily (like USA land carriers). The bigger problem is that Europe even sparse countries have more uniform density. America has a lot of suburbs and x-burbs where a huge percentage of the population live in moderate densities. Rural highway is easy (though expensive). The problem is what to do in lightly populated areas.

Comment Re:Strange path he is taking (Score 1) 744

The OS kernel really do much to manage process and threads. Consider this example: A is a daemon which depends on B which depends on C. C encounters a problem and needs to restart. What should the system do about A? Linux prior to systemd lacked any standards for this and every daemon had to handle this sort of thing on its own on top of init.

Let's make it worse. Assume A is going to follow process B's lead and process B needs to know why C crashed to decide what to do.
a) How does process B find out what happened to C?
b) How does B find out whether C was able to resolve the problem on restart?
c) How does A find out given that A and C don't directly touch?

It's time to boot, do your boot ROMs know where your disk controllers are?