This doesn't surprise me. Some of the HFA people I've known take naturally to this kind of detail-oriented work that might seem tedious to other people.

I wonder how much of a market there is for high quality software testers. Based on what I've seen, software vendors care a lot about time-to-market, but not so much about software quality.

The ones that do care about quality don't test much beyond functional tests, and the QA folks they pay to break their software are marginalized.

Ok so reading the slides they're planning on doing network management (byebye NetworkManager), Local DNS cache (yes please), mDNS responder, LLMNR responder, DNSSEC verification, NTP, sandboxing services and applications, OS/App/Container image formats, stateless systems, atomic node initialisations and updates and more. That is freaking awesome. Not only does it bring Linux distributions closer together.. it also takes the distributions as a whole to a new level. Instead of a kernel + some packages the future will bring us a true (GNU/)Linux/systemd operating system. I can understand this may seem scary to some but personally I really think this is awesome.

Why do they need to reimplement all these things?

I use unbound for DNS, and it's great. It provides caching, DNSSEC, and more. It's a mature, stable project. Why rewrite it?

Same with NTP. Why do they need to sprinkle SysD dust on it? We already have NTP.

I hate NetworkManager, and I'm sure I'll hate whatever SysD project rewrites it. My desktop has a static place in the network. I don't need some bloatware screwing with all my network settings and crashing all the time.

This is one thing I don't like about systemd. All the selling points (e.g. almost everything at http://0pointer.de/blog/projects/why.html) seem to be either:

• Things I do not want or need, or
• Things I already have, that are reimplemented "the systemd way."

Another troubling thing is that I've never seen a good description of what "the systemd way" is, or what the grand vision is. It seems to be nebulous, constantly shifting, and constantly expanding with no clear boundaries.

I remember Fyodor of nmap claimed that any software that parsed the output from nmap was a derived work.

It sure seems like a stretch, but until there is some case law around this issue, nobody can say for sure.

Yeah, sorry, I thought you were responding to a different post.

I agree - I'm inclined against systemd, but really just want to see the strongest arguments from both sides so I can make up my mind.

From the first paragraph on Jude's blog listing fallacious arguments used to support systemd:

This blog post is meant to serve as a repository of common but invalid arguments for using systemd that I and others have had to refute multiple times.

And from the second paragraph:

Please be informed that this post is not meant to be a criticism of systemd or its authors.

The gist is not that systemd is bad, it's that proponents need to develop other arguments. Personally, I think Jude's blog is the most incisive at cutting through emotions and using reason to dissect the systemd controversy.

If Rightscorp has "overwhelming evidence" of repeat infringers (or really, any infringers), they need to sue the offender directly or f**k off. If they don't actually have evidence, then they need to f**k off, then die in a fire, then go f**k off again.

It's not Cox's job to enforce Rightscorp's allegations as if they were court orders.

Judging from the complaint, Cox must feel like it has staked out a secure legal position:

Cox's Privacy Counsel advised Plaintiffs' agent that it has implemented a "policy not to accept or to forward notices such as those sent to us by your firm."

Sounds like Rightscorp didn't like getting the finger, and now they've asked for a *jury* trial. LOL good luck with that, assholes.

NO HE DID NOT. Sorry for yelling, but it's an important point.

Yep, I didn't see the NextWeb response until after my post.

I capitalized that phrase because the poster I was responding to (like many other posters) was confusing accessing data with sending data back to Uber servers. I wanted to draw attention to that distinction.

Go back and read the original GironSec blog post where he even acknowledges explicitly what he (inexcusably, IMHO) failed to do -- that others did after him and surprise! found nothing especially amiss -- before he wrote an inflammatory blog post based on supposition, conjecture and ignorance of context.

I re-read the blog post. I guess you mean in the comments section, where someone posts a link to the NextWeb article, GironSec responds:

I found code that might be used to spy. I didn't say they did. Hidden features. Thanks for linking.

I don't see that GironSec supposed or assumed anything. The Gizmag blog post did, though.

GironSec did establish that:

• The Uber app includes a roottools library that can detect and use root access.
• The Uber app includes an semi-weaponized library that is marketed as anti-fraud protection for mobile banking

The next step would be to look through Uber's code and see where it calls these libraries and what triggers the calls. Regardless, this is worthy of security news (and is legitimate research). Uber is not marketed as an anti-fraud, anti-malware tool, and AFAIK it does not advertise extra features on rooted phones.

Those are legitimate explanations for the app to need said access, but that's not what the article is about. The researcher found Uber was SENDING ALL OF THIS BACK TO UBER'S SERVERS.

Sorry for yelling, but it's an important point.

Also, there is no good reason to report back your data pertaining to malware.

Product liability law says that manufacturers should be aware of the most current science related to manufacture of their product. They are on the hook for all manufacturing defects. Congress doesn't have to codify the state of the art.

The problem is that the law hasn't decided how software fits in to product liability law, so vendors can argue security defects are not manufacturing defects, but *design* flaws, and they have much less liability for design flaws.

Congress could fix this easily, but legislators are almost entirely hillbillies, low-tech businessmen, amd low-tech lawyers. This is why the USA has one foot firmly in the 20th century.

Product liability for software is in a weird limbo where vendors effectively have no liability. So they don't have much reason to care, beyond damage to their brand.

If you read the EULA that comes with software you purchase, it disclaims ALL warranty, and the vendor is not guaranteeing the software will do anything, not even what it says on the box.

I wonder if automotive software might be on different legal ground, since nobody accepts a software license when they buy a car.

You sure seem to have missed the point. The AC poster (you?) already lost the argument, whether he responds or not.

I made my point with questions, and the point was that none of the Ubuntu security notices were anywhere near as serious as Microsoft's schannel or OLE vulns.

Unless I missed something in the Ubuntu bulletins, none of those vulns were even suspected of being remote code execution vulns. The AC poster was flat-out wrong in his assessment that the Ubuntu notice had more vulns, and especially wrong that it had more remotely exploitable vulns. I called him out on his bullshit, but at the same time threw him a softball so he could respond if he cared to actually read up and have a reasonable reply.

Sometimes there are people on Slashdot who do seek out intelligent discourse. I was leaving that possibility open, but certainly not holding my breath for it.

Zuck: Yeah so if you ever need info about anyone at Harvard
Zuck: Just ask
Zuck: I have over 4,000 emails, pictures, addresses, SNS
[Redacted Friend's Name]: What? How'd you manage that one?
Zuck: People just submitted it.
Zuck: I don't know why.
Zuck: They "trust me"
Zuck: Dumb fucks

If I had points, I would mod this up. I'd also highly recommend Descartes' Error by Damasio.

He makes a strong case for his somatic marker hypothesis, which in a nutshell says the body participates in decision making, not just the brain.

Damasio should be required reading for anyone who wants to understand human intelligence.