Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×

Comment Re:Why? (Score 1) 232

Linus has already stated, and I've provided the very message, where he has point blank told Greg that this needs to be tested in distribution kernels before it ever gets anywhere near mainline.

If you're choosing not to see that then there's not much we can do here.

Comment Re:KDBus - another systemd brick on the wall (Score 1) 232

Rather typical LKML discussion in my opinion, but blown out in all proportions by the systemd-haters because they wrongly think that Linus don't like systemd nor its programmers because of this.

No it wasn't. Linus made his views on when this stuff will get merged, if ever, abundantly clear. It's not blown out of all proportion. That's what was written.

Comment Re:KDBus - another systemd brick on the wall (Score 2) 232

What he and Linus disagreed upon was whether you should fix broken kernel features or not. Kay thought you should, Linus disagreed.

I don't know whether you're being this fucking stupid on purpose, but this shit needs shooting down and it currently is on the Linux kernel developer's mailing list. Existing and expected behaviour from the kernel does not get altered. EVER. Userspace does not get something different. That was made abundantly clear.

Who the fuck are you or Kay Sievers to tell kernel developers what flags they will now suddenly pass as debug that have been used forever? I'm afraid this attitude problem is going to get shot down in a very public way, as it is currently doing, by the kernel developers.

Comment Re:KDBus - another systemd brick on the wall (Score 2, Informative) 232

Sure, many systemd-opponents harbour fantasies like that.

Many systemd proponents harbour fantasies of it being the one true way of doing......anything and want to wave away the problems.

This, by the way, is Linus's take on kdbus and why it won't be seen in the kernel for some time to come, if ever:

http://lkml.iu.edu//hypermail/...

Greg - just for your information, I will *not* be merging any code from Kay into the kernel until this constant pattern is fixed.

This has been going on for *years*, and doesn't seem to be getting any better. This is relevant to you because I have seen you talk about the kdbus patches, and this is a heads-up that you need to keep them separate from other work. Let distributions merge it as they need to and maybe we can merge it once it has been proven to be stable by whatever distro that was willing to play games with the developers.

Regardless of any other bullshit and hearsay, that is the policy of the kernel. When he says 'Kay', read any systemd developer. Oh, and no, it's not a joke and no he doesn't write the e-mails on the kernel mailing list for the goodness of his health.

Comment Re:And what good would it do? (Score 1) 447

However, you are forgetting another crucial piece of evidence, the descent rate, which we have from radar data.

It means absolutely nothing until you look at the aircraft, it's data and ultimately why that actually happened.

It seems to be consensus on every source I read, that the very smooth descend rate must be autopilot controlled, and setting the autopilot's target altitude is pretty involved, and must be done intentionally.

Consensus and 'I read that' has no place in air crash investigation. Many puzzling voice recordings have been taken from crashes until the data recorder was found and the plane wreckage examined.

That said, yes, they were very fast with laying the blame on the co-pilot. Disturbingly so. Let's hope the investigation will actually continue, though the plane was disintegrated, and the they're even publicly saying that the second recorder might never be found.

One can only hope that the data recorder is recovered and the plane can be pieced back together by some competent investigators. However, I have an awful feeling that won't be found and that won't happen.

Comment Re:And what good would it do? (Score 1) 447

If you hear sounds of the captain banging on the door, it certainly tells you he was locked out.

Without data it tells you nothing. Many crashes have been a complete mystery from a cockpit recording point-of-view until the data recorder has been found, which in this case, it doesn't look like we're going to get.

Doesn't explain the constant breathing, reprogramming of the flight system to descend, and the captain being locked out. Even if the co-pilot was unconscious, the captain should be able to unlock the door. And if there was a fire and noxious fumes, the co-pilot would put on his oxygen mask.

Ahhh, yes, the calm breathing. Headsets give clarity to voices, not background noises. If you can hear breathing.....it isn't calm.

It's kinda hard to extrapolate a note from a doctor if it wasn't there, unless you want to accuse the investigators of fabricating evidence.

You're just continually shooting around in the dark with nothing to say.

Many people have doctor's notes of all kinds. Proves zilch.

Comment Re:And what good would it do? (Score 1) 447

Never let bothersome facts or evidence get in the way of a good conspiracy theory. After all, if you dig down a few layers of turtles, you can convince yourself that any of these "facts" are simply manufactured, and therefore are evidence of the conspiracy themselves.

Yes, you can convince yourself of anything if you start looking into the private lives of anyone.

Of course, it's totally implausible to think that this investigation would be conducted in anything like a standard fashion.

Slashdot Top Deals

Any circuit design must contain at least one part which is obsolete, two parts which are unobtainable, and three parts which are still under development.

Working...