patrick_g a écrit 6387 commentaires

Ben y'a seccomp quand même non ? D'ailleurs les mecs de Google disent l'utiliser dans Chrome : http://article.gmane.org/gmane.linux.ports.sparc/11622

je me fous bien pas mal de l'avis du redac chef....mais alors, completement.

L'intro était justement là pour indiquer aux lecteurs que la version originale allait être disponible pour ceux qui préfèrent (et qui peuvent) lire directement la prose de Linus.

Ce n'est pas la traduction que je critique....c'est l'ordre dans lequel c'est mis

Ben ici c'est LinuxFR donc bon....

a la rigueur en faire un lien vers l'original pour que ce soit 'clair'...

Un lien vers ou ? Vers ma boite mail perso ou Linus a répondu aux questions ? C'est bien plus logique de poster en commentaire.

LinuxFR : You've been doing Linux for about 20 years now and it's a hard job. Is it still fun ?

Linus Torvalds : Oh, absolutely. It's still fun. And partly exactly because I've been doing it for 20 years, I wouldn't call it "hard". It's still challenging and interesting, but I think I'm good at it.

LinuxFR : Why did you choose to switch the kernel from his original non-GPL copyright to the GPL licence ? Was it an ethical or a practical choice ?

Linus Torvalds : Practical. I think my original license contained the ethical parts I cared about, but it turns out that it was too strict about that whole "no money" thing, and it also wasn't well enough known. Moving to the GPL fixed the problems that people had with my original license, and had the advantage that it was a known entity and also a lot more likely to stand up in court than the short blurb I had written originally.

LinuxFR : I know that you consider yourself a very pragmatic person and not a prophet...but do you agree that there is an ethical content in the GPL license ?

Linus Torvalds : I'll answer this two very different ways, and try to explain why I answer it two ways.

So the first and the very negative answer is that I absolutely despise the people who try to push the GPL as being about "ethics".
I think that's absolute bullshit. Why? Because ethics are to me something private. Whenever you use it as an argument for why somebody_else should do something, you're no longer being ethical, you're just being a sanctimonious dick-head.

But the second answer is that I personally feel that the GPL (version 2) matches what I want to do. I really like doing programming, and I wanted to put my stuff out there for others to enjoy, but I felt that the whole "you can do with it as you wish, but your improvements need to be available the same way the original is available" is just very fair, and is a great way to do development.

So personally I think the GPLv2 matches quite closely what I think is "the right way to live my life". And by "right way" I don't think it's the only way. I've done commercial programming too, and I enjoyed that a lot, and I think that was fair and appropriate too (hey, they paid me for it).

So I think the GPLv2 is a great license, and I use it for my own personal reasons. I do think that's true of a lot of other people too, but I really want to point out that it's not that the license is somehow ethical per se. A lot of other people think that the BSD license with its even more freedoms is a better license for them. And others will prefer to use a license that leaves all the rights with the original copyright holder, and gives no rights to the sources at all to others. And for them, that is their answer. And it's fine. It's their choice.

Trying to push any particular license as "the ethical choice" just makes me mad. Really.

LinuxFR : Why is the desktop so special and so much harder than any other market ?

Linus Torvalds : Because it's so much more interesting. It's the market where people do so many different things.

Your average server does almost nothing. Sure, it may have a lot of CPU power, a fast network, and lots of IO, but it does the same thing over and over again, and that "same thing" is pretty limited. It's running a database, a mail or web server, various analytics etc. It may be important for the company, but it's not a very varied workload,
and it's not something people are attached to.

In contrast, your desktop is what you see every day, and you get attached to it. The attachment might be some kind of "stockholm syndrome" where you really don't necessarily like it (think of all the people who grew to know computers through DOS and Windows, and the three-finger ctrl-alt-del salute), but even then it becomes a kind of dependency where you get used to it and rely on it rather more intimately than you ever end up relying on the company mainframe.

And the desktop does so much more. You play games on it, you do word processing on it, you do development on it. It's not a single-trick pony. Of course, for some people it has also become "you use a web browser on it" and nothing much more, but even that single use tends to in many ways be a more complex workload than most server workloads.

Of course, what's interesting is how smartphones are slowly starting to share many of those desktop complexities. It may not be there yet (and maybe it never will be), but phones already have a fair amount of the same rich and complex media issues that desktops have, and are getting more varied uses.

LinuxFR : Why Linux desktop hasn’t been adopted by the mainstream users ? Is it possible for the kernel community to improve this situation or is it mostly a user space problem ?

Linus Torvalds : I don't think there's much we can do on the kernel side, except continue to improve in general, and make sure we remain the technically best choice.

And it's not really that we don't have mainstream users - Android is an example of lots of mainstream users for Linux. The problem is that the desktop is a difficult market to reach. There are huge amounts of "network effects" where having existing users is a big reason to retain them and get more new users. It's also that most people really
really don't want to change their environment, and if they do switch, they want help and support. Where "support" is not necessarily about commercial support, it's about knowing that you have people around you who know the system and can give you advice etc.

Getting past that hump is hard. And it's not something that happens by pointing at technical issues. It's often a social issue.

LinuxFR : I know it's a strange (and probably dumb) question but are you still able to fully understand all parts of Linux kernel or do you really need trusted maintainers ? For example concerning the complex pathname lookup patchs from Nick Piggin what was your process to choose between these patchs and the other solution from Dave Chinner ? Have you received some advices from Al Viro or was it your lone decision ?

Linus Torvalds : Oh, I absolutely don't claim to know and understand all of the kernel. I know a wider chunk of it than most kernel developers, but there are many areas where I almost entirely rely on the maintainers, because I just don't know (or necessarily even care - we all have our own areas of interests) enough about some subsystem.

That said, the example you picked wasn't one of those areas. The VFS layer and most of the VM layer I'm intimately familiar with, and so I had no problems feeling like I could make those decisions on my own, and support the end result even without further help. Of course, that's not to say that I didn't expect people like Al to help me, and
I didn't talk it over with them, but when it came to the new pathname lookup, I was much more personally involved than I am in most other areas.

Of course, usually I don't really want to feel like I need to be personally involved. The pathname patches had been around for most of a year, and weren't making much progress (there was a lot of discussion, but not as much forward progress as I wanted), so I ended up championing those patches a bit more than I would necessarily
otherwise have done. I'd have been perfectly happy having them go entirely through the normal submaintainer channels.

In some other cases, I can't do that kind of "I'll step in and make some executive decision", because I don't necessarily know the area well enough, or I don't feel like I can really end up maintaining the end result if I really piss off the maintainer too badly. So then I can prod and try to raise discussion about issues, but I'll just have
to trust that somebody gets up and makes the right decision.

(Btw, "right decision" is not necessarily the right word. Sometimes you just need to make a decision. It's not always clear what the "right" answer is, and sometimes it's fine to just say "we don't know" and not make a decision at all. But at other times you really do need to make some kind of technical choice. The good news is that most
technical choices can be reversed if they turn out to be wrong later on - it may be very painful, but sometimes it's better to just make a choice even if you can't know whether it's the right one. Even if there is a chance that you may have to reverse that choice later)

I should say that those kinds of situations are actually pretty rare. Most of the time the development process works without anybody having to make particularly difficult choices. Most of the time it's fairly clear that the forward direction is, and sometimes it's just hard to find people that actually write the code :)

LinuxFR : What do think about this citation from Lennart Poettering ? : "In fact, the way I see things the Linux API has been taking the role of the POSIX API and Linux is the focal point of all Free Software development. Due to that I can only recommend developers to try to hack with only Linux in mind and experience the freedom and the opportunities this offers you. So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It's quite relieving!"

Linus Torvalds : Well, I think it can be a reasonable way to simplify a very difficult problem (portability).

But one reason it's likely to be a good way is that we really don't try to extend too much - and not unnecessarily - on the standard interfaces, so even if you do end up deciding to just care about Linux, it's really hard to make the end result horribly unportable. Linux is a pretty middle-of-the-way UNIX in many respects, and even
outside of the unixes, most of the frameworks that you'd use on Linux are available on other platforms too (often because they are open source).

So even if you later decide that you do want to be portable after all, going with Linux to begin with was probably not a bad idea, and it may have simplified the early decision process in a project.

LinuxFR : Do you think systemd is a huge improvement in comparison to SysV init ? Is it a game changing technology ?

Linus Torvalds : I also will take a somewhat wait-and-see approach, it's not widely enough used yet. I do think bootup performance is important, and anything that helps that, and helps make it more flexible is a good thing. Would I call it "game changing"? Probably not.

LinuxFR : Do you use btrfs ? When do you think it will be ready to replace ext4 as the default recommended file system ?

Linus Torvalds : I've used btrfs on a couple of the laptops I have, but honestly, when it comes to filesystem usage, the big factor is distribution support. Almost nothing else matters, as long as the core capability is there. So getting a distribution to pick a filesystem by default is the way it ends up being the commonly recommended one, simply because what most people care about in filesystems is neither features nor performance, but stability.

And me personally, I don't worry about it any more. I had some issues with ext3 (horrible fsync performance in particular), but most of what I do is actually totally dominated by the VFS layer, because it caches so well (ie I have the kernel sources in memory pretty much all the time, and the filesystem doesn't matter because all the caching is
done by generic routines).

LinuxFR : With Linux and Git you've done two softwares that changed the computer world. How is it possible to have two gigantic success like these ? What is the difference between you and mere mortals ?

Linus Torvalds : I think a lot of it is just stubborn persistence. Especially Linux - I was in the right place at the right time, but others could have done their own operating system. And others did. But very few people ended up just doing it as much as I did. I've been at it for twenty years. Most developers doing some random private project for their own enjoyment don't stay with it long enough for it to ever be even release ready. Much less for decades.

With git, things were a bit different. Partly because I had a use case that was big enough (the kernel) that I could jump-start it, but partly because I really came at an old problem from a new angle, and I do think I did a good job as "architect" for the project. I really think that git has a fundamentally good design (in the case of Linux I
could just build on top of the design of Unix that had already been done), and I could push it through because Linux needed more than the existing SCM projects could offer.

But with git, a lot of the credit really does go to Junio Hamano. He's really been a great maintainer. People like that are important. Yes, open source programming is a team sport, but finding the right people is really the killer feature (the same is obviously true in the kernel too - I really do think we have a great set of maintainers. I may
complain about them and I'm somewhat infamous for my flames when things don't work, but at the same time I'm convinced there's some of the best people out there working on maintaining the kernel).

LinuxFR : I've seen that you read a lot about biology and evolution theory (for example Richard Dawkins). Is that knowledge useful for Linux process developpement ? Is it mostly a darwinian competitive model or a cooperative one ?

Linus Torvalds : I don't think it's useful for the kernel, but it does happen to be a subject I'm interested in. Biology, evolution, human behavior - they are all fascinating subjects. And I think there are parallels between technological development and evolution. I obviously do not believe in Intelligent Design when it comes to biology (and I think anybody who does is woefully badly educated), but after all, I often think that "intelligent design" is much overrated in technology too. Many technical improvements really do seem to be about more "organic" developments, and very few are fully designed ahead of time. In fact, I think most interesting technical problems are too complicated to "design" for - the way you get to a solution is very much through incremental improvements and trial and error.

LinuxFR : You are now an american citizen. What do you think about software patent law in USA ? Is your voice strong enough to help fight this law in this country ?

Linus Torvalds : I have to admit that while I don't like patents, I also tend to try to stay away from getting too involved in issues like those. I'm good at what I do, I think there are people who are better at fighting the patent mess. And I think you need to do so from within the system - so I'd expect that any solution will actually largely come from all the companies who are being hurt by the mess that it is.

LinuxFR : You often wrote detailled posts on realworldtech.com but I've never seen a post from you on lwn.net. Why ? Do you read lwn.net regularly ?

Linus Torvalds : Heh. rwt is where I go to flame people and argue about computer architecture. I like people who argue back, and I also like how it's not Linux people, or even about Linux. So I can spout my opinions and see what arguments I can get to happen.

lwn? That would be an entirely different kettle of fish.

LinuxFR : Various people criticized kernel security. Do you think kernel devs put enough work on kernel security mechanisms and code review ? Do you think some parts of GRSecurity should be imported in mainline ?

Linus Torvalds : I think we've done a pretty good job, but one of the problems with the security world is that it's so black-and-white. To some security people, even me just saying "pretty good job" is like a red flag. They don't think "pretty good" is good enough, they think security is somehow everything.

And I disagree. Most security problems are just bugs. We need to try to avoid bugs, but bugs happen. That's a truism, but I think it's what it all boils down to. Are we better at avoiding bugs than other projects? I think we're doing pretty well, especially considering just the insane amount of code we write and change every single day. I really don't think it's useful to try to separate "security bugs" from other bugs. They're all just bugs, and almost any bug could be a security bug under the right circumstances.

As to grsecurity, I think we've taken the important things, and left the extreme things (the ones that actually hinder usability or are otherwise extremely intrusive) behind.

In general, the best way to security tends to be to have many different layers of security. You can never be entirely bug-free in any half-way interesting program, but with multiple layers of security, one layer will hopefully end up protecting against the possibility of a bug at another layer that might otherwise have resulted in an exploit.

So in the kernel, we tend to try to have the generic layers already have security checks early, so even if there's a bug in a filesystem or a driver, it's harder to cause that bug to be exploitable. And when we do find some overflow, we tend to fix both the immediate overflow itself as well as (when possible) add checks at higher levels so that the overflow couldn't have happened in the first place. So in many cases we actually end up with several fixes to the same problem - each of which would have fixed things on its own, but together they end up hopefully being more resistant to a similar problem happening somewhere else (or later be re-introduced in the same place - it's embarrassing when it happens, but that has happened too).

LinuxFR : Do you think security experts and exploits creator have a different mindset compared to other kernel developpers ?

Linus Torvalds : Oh yes. Some of the more interesting exploits in particular have made me go "that needs a really twisted mind to come up with" and being quite impressed.

But it's not always about being impressed. Quite often I get rather depressed by all the sleaze in security circles. It really is a circus. A lot of it is all about posturing and PR (on all sides:vendors, security people, exploiters etc).

LinuxFR : I've done a interview with Brad Spengler (GRSecurity) and asked a question about his opinion on you and kernel security. Brad's answer was: "He at times can understand security better than some of the other developers, but security isn't one of his main goals (...) His ideas regarding security that have formed the official policy of kernel developers to omit security-relevant information in changelogs and treat all bugs the same are destructive".
Do you think all bugs should be treated the same ? And why ?

Linus Torvalds : I tend to think that all bugs should be treated the same, and I neither want to point out, nor particularly hide our security issues.

The thing is, even security people cannot agree. Many of them want full disclosure. Others want very limited disclosure (vendors and big financial institutions). Others want just total secrecy, both to avoid embarrassment, but also at least to some degree to avoid the issue leaking to the "black hat" people who write exploits.

And then there's the fights about leaks - everybody knows that there are different classes of "bad guys", ranging from just regular good people who want to try things out (hey, university kids who hear about a new exploit, and decide that they want to test whether the big university machines really do crash) to script kiddies who like being annoying but don't necessarily have all that impressive technical background and understanding, to people who are really smart and may well be doing things for serious criminal gain.

How the hell do you resolve those discussions? I claim that you can't. There is no "right way", and the people who push their way of doing disclosure (or not) are demonstrably doing bad things.

So my personal opinion is that the only sane approach is to just realize that it's not a solvable issue, and just treat bugs as bugs. We try to avoid having them in the first place, but when they do happen, we fix them. And we fix them without shouting from the rooftops about the details about how to exploit the issue, and without even trying to make it easy for the people who might want to try to exploit things to find them. And yes, that can very much involve not saying everything we know about how to exploit the bug in the changelog, or even necessarily pointing out that there is an advisory about it.

Do security people always agree with me? Hell no. But they don't agree amongst themselves either, so what does that prove?

LinuxFR : Do you have an opinion on OpenBSD quality ? They put strong emphasis on security. Is there some lessons to learn from this project ?

Linus Torvalds : I think that any single-purpose OS project is a failure, and it doesn't matter what the purpose is. Security on its own is not a worthy goal - you need to have users for security to even matter in the first place.

So I think the single-mindedness about security in OpenBSD just makes the whole project less interesting and relevant in the end.

But again, that's just my general "bugs are bugs" thinking. I think security is important, but so is performance, and so are features. The world just isn't black-and-white. There is no one single thing that matters more than other things.

LinuxFR : LLVM compiler is making huge progress. What do you think about this project ? Is LLVM architecture better than GCC and do you think it will replace GCC in the long run ?

Linus Torvalds : Replace? Might happen, but I don't think it's particularly likely. I do find compilers interesting, and I think it's good to have some competition in that area, and so I like seeing LLVM make the effort.

LinuxFR : There is a Linux kernel on my ADSL box sent by my Internet service provider. There is also a Linux kernel on my Sony TV and on my printer. However I'm not free to hack on my ADSL box, my TV or my printer (due to legal reasons or due to tivoization). What do you think about this situation ?

Linus Torvalds : I personally think flexible hardware is more interesting than locked down hardware, but at the same time, to me the "fair exchange" was always about the software and the ideas, not about hardware.

So my whole issue with Tivo and company has always been "hey, they designed and built the hardware, the fact that they used my software doesn't give me any special rights to the hardware".

Since they are using Linux, I do expect them to make their changes to Linux source code available to people as the license requires. There obviously have been cases of companies not doing even that, but that's the exception rather than the rule.

So you can take that Linux source code with their modifications, and design and build your own ADSL box or TV or whatever and use whatever improvements to Linux that they did. Or more relevantly, you can use their Linux improvements EVEN IF YOU DON'T make an ADSL box - you can do it on your desktop, or on some totally unrelated computer, and that's when the improvements become rally interesting - when you use them for something else than they were originally meant for.

Now, of course, most Linux users in that space don't actually need to make all that many changes to the kernel, so there may not be any improvements. That's fair too. If Linux worked for them without modifications, then that's fine. Again, it will work for you without modifications if you want to do some similar hardware.

So I always thought the whole "Tivoization" thing was silly thing. If you want to make your own Tivo, just do it. Don't think that just because it runs open source you should control the hardware. It's open source. If you want to make open hardware, make open hardware.

Now, that said, I do think that there are serious problems in the content industry, where content providers are using laws and technical measures to basically try to lock people in and create more of a monopoly situation. I don't like DRM. But I think that's a different issue from the software license, and I also think that it was seriously wrong of the FSF to try to use the GPLv3 as a way to make other peoples software projects into weapons in their fight against DRM. And I'm very happy that I had made it clear that Linux was a GPLv2-only project many years before that all happened.

LinuxFR : What is your opinion about Android ? Are you mostly happy they made cellphones very usable or sad because it's really a kernel fork ?

Linus Torvalds : I think forks are good things, they don't make me sad. A lot of Linux development has come out of forks, and it's the only way to keep developers honest - the threat that somebody else can do a better job and satisfy the market better by being different. The whole point of open source to me is really the very real ability to fork (but also the ability for all sides to then merge the forked content back, if it turns out that the fork was doing the right things!)

So I think the android fork forced the mainline developers to seriously look at some of the issues that android had. I think we've solved them in mainline, and I hope (and do think) that android will eventually end up merging to mainline. But it will probably take time and further effort.

I think the more serious long-term issue we have in the kernel is the wild and crazy embedded platform code (and mostly ARM - not because ARM is in any way fundamentally crazier, but because ARM is clearly the most successful embedded platform by far). The embedded world has always tended to eschew standardized platforms: they've been resource constrained etc, so they've done very tailored chip and board solutions, and felt that they couldn't afford a lot of platform abstraction.

That causes a big maintenance headache, because then all those crazy platforms look slightly different to the kernel, and we have all that silly code just to support all those variations of what is really just the same thing deep down, just differently hooked up and with often arbitrary small differences.

But that's something that happens both within and outside of Android, it's in no way android-specific.

LinuxFR : What about the technical differences between Android and mainline ? Do you think the "wakelock" controversy is solvable ?

Linus Torvalds : I think it is technically largely solved (ie "details to be fixed, but nothing fundamentally scary"), but practically once you have an interface and existing code, it just is a fair amount of work to change. And there perhaps isn't quite enough motivation to make those changes very quickly. So it will take time, and probably several releases (both mainline and adroid) to actually happen.

LinuxFR : Windows 8 will run on ARM. Is this a real threat to Linux dominance on embedded market?

Linus Torvalds : It's not how I think, or care. Linux competes with itself, not with Windows. IOW, at least as far as I'm concerned, the thing I want to make sure is that Linux just improves.

If anything, I suspect that in order to support ARM, MS will end up forcing some platform standardization on the ARM setups they support, and will make our job easier. I won't mind that at all.

LinuxFR : Can you explain why you're not happy with the ARM patches sent to you during merge windows ? Is there an obvious solution for this fragmentation problem ?

Linus Torvalds : Obvious solution? No. The problem is the wild variety of hardware, and then in many cases the Linux ARM platform code (not the ARM CPU support, but the support for certain chips with all the glue issues around the CPU core) has been mostly ugly "copy-and-paste" from some previous ARM platform support file, with some minimal editing to make it match the new one.

And it just results in this unmaintainable mess. It becomes painful when somebody then fixes some core infrastructure, and you end up with a hundred different ARM files all using that infrastructure. That happened with the IRQ chip driver cleanups Thomas did recently (well, has been doing over along time, the recent part is really just the final removal of some nasty old interfaces).

It results in other maintainability issues too - patches being big just means that people won't look at them as carefully etc etc. So it's just a bad situation. Many of the cases should be solvable by having better generic solutions and then plugging in just some per-platform numbers for those solutions.

LinuxFR : What is your opinion about microkernels ? Do you still think it's a technical failure ?

Linus Torvalds : Yes, I'm still convinced that it's one of those ideas that sounds nice on paper, but ends up being a failure in practice, because in real life the real complexity is in the interactions, not in the individual modules.

And microkernels strive to make the modules more independent, making the interactions more indirect and complicated. The separation essentially ends up also cutting a lot of obvious and direct communication channels.

LinuxFR : What about managed OS like Singularity ? Is it research only or do you think it can work ?

Linus Torvalds : I'm a rather harsh and pragmatic person. Right now it looks like research only. The devil really is in the details, and a lot of these nice theoretical frameworks talk about the big issues, but not about all the details that you hit when you have all those crazy users that do odd (and wonderful) things.

And the thing is, I really don't see the point. Operating systems aren't that complicated. There's nothing wrong with the UNIX model. Sure, we have a lot of code, and I'm not claiming it's simple code, but it's quite manageable. The biggest problems we tend to have in Linux is driver and platform support - not things that are fixed with some new programming model. Microkernels or managed code? They really solve none of the big problems I see.

LinuxFR : Imagine we're in 2031 and the Linux kernel is now forty years old. Are you still the project leader ? Do you think the kernel is more or less the same than in 2011 or do you think there are new radical innovations included ?
/troll mode: Was it rewritten in C++ ?

Linus Torvalds : I really really hope that by 2031, we'll have moved past the OS as a place for radical ideas. Sure, it will run some OS, and I hope it will be Linux, but all the radical and interesting work had better be done in user space and in giving us more exciting interfaces to the computing power.

So I personally do think that the kernel approach will still be valid and that the changes will be at a different level.

After all, we've had forty years of Unix, and that whole "monolithic kernel in C" hasn't become invalid in those forty years. Sure, the details have changed, the language has evolved, and we have way more complex interfaces, but the basic design is still quite recognizable. And I don't think another 20 years will necessarily change that at all.

LinuxFR : Thanks a lot for your answers...and happy birthday for the kernel :-)

Ben la vente des CDs est une source de revenu pour le projet alors ce serait un peu bête de miner ainsi la (sans doute faible) rentrée d'argent que cela génère.

Corrigé.

On doit donc s'interdire d'écrire des programmes pour l'API linux parce que Debian a décidé que deux noyaux totalement différents devaient booter avec le même système d'init ?

Pour rajouter de l'huile sur le feu j'aimerais bien savoir combien de gens utilisent vraiment Debian GNU/kFreeBSD.
Je n'ai aucune donnée mais je suis prêt à parier ma chemise que ce nombre est infinitésimal. Refuser une belle avancée technologique comme systemd juste parce que ce n'est pas compatible avec Debian GNU/kFreeBSD ce serait, amha, une monumentale connerie.

L'ennui c'est que personne n'est d'accord sur "ce qui est juste". Plutôt que les gens ne s'étripent au nom de leur vision personnelle de "ce qui est juste" on a donc choisi la moins mauvaise solution qui est de définir démocratiquement une procédure judiciaire et d'essayer autant que possible de s'y tenir.
C'est loin d'être parfait, il peut y avoir des erreurs et des scandales, mais on n'a pas trouvé mieux pour l'instant.

Bien entendu et on est tous d'accords là-dessus. Mais ça n'est pas le point discuté.

Il n'y a peut-être plus de présomption d'innocence (ce dont je doute), mais cela n'enlève rien à la nécessité d'un procès.

Ah mais je n'ai jamais discuté ce point. Je pense juste que Ben Laden, en revendiquant les attentats, a volontairement abandonné son droit à la présomption d’innocence. Il aurait quand même du avoir droit à un procès en bonne et due forme.
Mais bon ce n'est pas toujours possible et parfois on doit tirer pour neutraliser le type d'en face qui vous tire dessus.

Tu en es certain ? Je suis dubitatif. J'ai cherché rapidement sur le net mais je n'ai rien trouvé de probant.
Juste ici une phrase qui semble accréditer ma thèse :

on ne doit pas obliger un suspect sous le poids du serment à s’accuser lui-même ou à commettre un parjure en se trouvant obligé de raconter des mensonges. Ce qui entraîne dans la première hypothèse un renversement de la charge de la preuve en faveur de l’accusation

Si il y a renversement de la charge de la preuve cela implique bien que suspect est maintenant présumé coupable et qu'il doit se disculper non ?

Toute personne accusée d'un acte délictueux est présumée innocente jusqu'à ce que sa culpabilité ait été légalement établie

Cette présomption d'innocence n'est valable que si tu ne revendiques pas le crime !
Si tu reconnais ta culpabilité, par exemple et au hasard dans d'un message vidéo enregistré ou tu affirmes avoir organisé le crime, ben évidemment il n'y a plus de présomption d'innocence qui tienne.

Mais bon au moins toute cette histoire c'est excellent pour la réélection d'Obama. Après le harcèlement de ces connards du Tea Party et de Donald Trump sur son certificat de naissance il a une excellente réponse à leur renvoyer dans les gencives : http://images2.dailykos.com/i/user/8411/Obama_got_bin_Laden.jpg

L'avantage de LWN c'est que tous les articles sont libérés au bout d'une semaine. Cela permet de les lires sans débourser un centime et ainsi d'évaluer leur intérêt.
Inutile de dire que pas mal de gens profitent ainsi des infos apportées par LWN sans avoir à s'abonner et en ayant comme seul inconvénient de lire les articles 7 jours après les abonnés. J'ai fait ça pendant des années avant de sauter le pas en 2006.
Donc dire que LWN fait ce que font les autres sites de manière traditionnelle c'est, je crois, assez trompeur.

Un bon article LWN qui explique les détails techniques d'Android : https://lwn.net/Articles/440246/

On voit bien qu'il s'agit toujours d'un noyau Linux à la base mais que tout le reste (tout ce qui gravite autour) est spécifique. Y'a d'ailleurs la phrase humoristique de rigueur :

A slide showing Kirk and Spock from the original Star Trek, and the line "it's Linux, Jim, but not as we know it"

N'ayant pas vu le documentaire, je ne saurais pas forcément commenter de manière pertinente son contenu.

L'article d'Econoclaste est particulièrement intéressant (et cinglant) au sujet de ce documentaire. Je recommande chaudement sa lecture.

Cf: https://linuxfr.org/nodes/22712/comments/896797

Il a pas changé en trois ans le Jeff Johnson. Toujours aussi...mmm..."spécial" on va dire.
Quand un mec lui demande ce qui se passe il répond:

Bugger off: I ain't yer bitch and your confidence isn't an RPM problem.

Je crois qu'au log dans GDM tu peux indiquer que tu veux ton bureau classique comma avant.

Je ne vois pas l'avantage de ces barres de défilement. J'ai essayé un live-USB d'Ubuntu et franchement quel est l'apport de ces barres invisibles qui apparaissent quand on va mettre son pointeur de souris à l'endroit qui va bien ?
Il doit y avoir une raison (ils ne se sont pas tapé ce boulot pour rien) mais franchement je ne vois pas.

Ce test me semble bien plus précis et révélateur que celui de theadvocates.
Normal en même temps puisqu'il est fait par des français donc le résultat obtenu est bien plus proche de mes positions politiques réelles.

Quel est le but d'un questionnaire politique pour placer les gens sur une droite/un espace/un volume ?
Le but c'est d'essayer de réduire tout le spectre des opinions possibles à une représentation simplifiée. Pour jauger de la qualité de cette réduction un bon critère c'est d'essayer de voir si on peut distinguer entre des politiciens réels.
Par exemple comment placer JP Chevènement ou JL Mélanchon si tu n'as pas le critère de l'intégration et du fédéralisme européen ? Ces hommes politiques ne se distinguent pas vraiment au plan économique (Mélanchon c'est l'extrême gauche économique classique, d'ailleurs le PC c'est rallié à lui. Chevènement c'est le PS classique) donc si tu n'as pas le critère européen tu perd trop d'information.

Sans l'axe de la construction européenne tu ne peux pas vraiment distinguer entre Chevènement et Aubry par exemple. Ou entre les positions des souverainistes de l'UMP et des fédéralistes classiques comme JL Bourlanges.

Là encore, comme pour le diagramme de Nolan, c'est beaucoup trop simpliste. En plus c'est très orienté politique américaine et donc les thématiques ne correspondent pas vraiment quand on est un européen.

On est d'accord que tout ça c'est mieux qu'une échelle droite-gauche habituelle mais c'est pas top. Moi je milite pour un cube avec trois axes principaux ou placer le curseur politique :

• L'axe économique (c'est sur cet axe qu'on décide si on veut plus ou moins d’État, plus ou moins de redistribution, c'est là qu'on règle le curseur des impôts, etc)
• L'axe des questions de société (c'est sur cet axe qu'on règle le niveau d'intervention de l’État dans les questions qui touchent l'individu: Les lois relatives à l'avortement, à l'usage des drogues, le statut et les droits des homosexuels, le droit à une vie privée, etc etc).
• L'axe de l'Union européenne (ici on regarde ou se situent les préférences entre d'un côté le fédéralisme européen et de l'autre l'indépendance nationale. On jauge la volonté de partage des compétences étatiques, etc).

Je pense qu'un tel positionnement dans le cube marcherait bien mieux si on veut évaluer les tendances politiques d'un européen.

les posts de description du kernel de Patrice

C'est qui lui ?

Je ne sais pas comparer ZFS et btrfs mais je sais juste que la déduplication arrive dans btrfs. Les patchs datent de janvier : http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg07720.html

A noter qu'il s'agit d'une déduplication offline (parce que l'auteur, Josef Bacik, pense que la dedup online ne sert strictement à rien).

Fait.

je me pose aussi la question, seulement je n'ai vu aucune étude là dessus

Étude de référence ici : http://www.irsn.fr/FR/base_de_connaissances/librairie/Documents/documents_reference/IRSN_reference_les_accidents_dus_aux_rayonnements_ionisants.pdf

Article wikipédia ici qui donne tous les points de vues et les liens vers les documents: http://fr.wikipedia.org/wiki/Cons%C3%A9quences_sanitaires_de_la_catastrophe_de_Tchernobyl

D’où le "à priori et sous réserve de confirmation".