2008/12/8 Arne Babenhauserheide <[EMAIL PROTECTED]>: > Am Freitag 05 Dezember 2008 12:40:32 schrieb Michal Suchanek: [...] >> For me firefox can cause my media player to skip. This is because >> firefox eats all available CPU time from time to time, and the only >> way to prevent it from interfering with the player would be to elevate >> the player's sheduling priority. This can be done only as root, and >> would prove disastrous if there was a bug in the player which caused >> it to run in a tight loop. >> >> It's not like I have an ancient system or Firefox really needs all the >> system resources to run - there just isn't any reasonable CPU time >> accounting in Linux. > > Please don't jump from "it can be done without needing a DRM capable > structure" towards Linux bashing.
I am not bashing Linux specifically here. The same can be said about Windows (probably even worse), and most likely about BSD. Some less well known systems might actually have useful schedulers. > > I know I'm also prone to jumping, but let's try to avoid it for this > discussion. > > Firefox' resource usage can be controlled without the user having to give up > access to its memory, and system servers started and controlled by root could > just police themselves. Sure, and you might also want control its memory usage, and that it cannot access the memory of other processes (because it is no debugger it has no business doing so). And once you have access control that actually works you can turn it into DRM by giving up some rights so some system service that implements DRM. > >> > The admin gives the user a pool of system memory he can use for any task. >> >> So this is like DRM except you cannot turn DRM memory into non-DRM >> memory and the other way around. >> You just get a piece of plain memory and a piece of DRM memory. > > No. > > It isn't DRM memory, because the admin always has access to it. If you replace the admin with a system service it is DRM. [...] >> > So the level of security is useless for most users, but the danger is >> > furthering a DRM ridden society. >> > >> > (sorry if that sounds too hard - it's the trade I currently see). >> >> You are mixing up things. To make society DRM ridden you must >> implement the verification that is required for adding "trust" to >> otherwise untrusted relationships between computer systems. > > If you facilitate implementing that verification, you further a DRM ridden > society. Then you are just facilitating it. Since the Hurd is microkernel based it has less code that is crucial for its security and if somebody wanted to implement verification they would have an easier job on the Hurd. > > That's called the "invisible hand". Many do small things, and since noone had > the foresight to see where he was heading, there was Hiroshima in the end. > > DIfferent from those nuclear physics scientists, we see the thread today, and > acting or not acting upon that knowledge is our responsibility. > [DRM] >> useless until somebody shows an example where it adds any value but >> that does not discard the utility of security. > > Value to whom? To the user of such system. Either single user system or shared (school, company, institution, etc) system. > >> > And why should I allow such a component in my free system. >> >> Then run Windows 95. They do not have any security whatsoever so they >> will fulfill this desire of yours. > > You really suggest to me using Windows 95? > > I said "free system", and free is not proprietary and definitely not WIndows. Then you are out of luck actually. Because "secure enough to implement DRM" is less than "secure enough to prevent as many breakins as possible". In the DRM case you have to add an extension that does care about securing only single part of the system - the DRM protected data. In the later case you want any security that could be useful for the user which is certainly a superset. If they wanted to build DRM on top of Linux (perhaps with some extension like SELinux) and hired a team of experts it might be doable. It would be hard and the result somewhat uncertain because an error in any part of the kernel might compromise the protection but it might still be impenetrable for all practical purposes. > >> some security, and a third party that the DRM content provider trusts > > That's exactly what you say: You want others to be able to trust my computer. > But then I can't trust my computer anymore to do what I tell it. I do not want others to be able to trust your computer. But there are people who would like to trust it not to allow you access to their protected content unless they allow it, and yes you could not really trust your computer in that case anymore. I cannot force you to choose either way. But they might say "Unless we can trust your computer you cannot access this." And either you find "this" important enough and give up your computer or you do not. > > I want to trust it, I don't want others to be able to trust it if they don't > trust me. > >> > And once programmers start using that convenience layer, you're in the >> > same position again, but now with a layer which is incompatible to most >> > applications. >> >> So if something can be entered by the user it is a compatibility layer? > > As soon as you have to design a simplification layer, you have a kind of > compatibility layer - only with the disadvantage that there aren't any > compatible applications, yet. So if the system can communicate with the user it's a simplification layer? > > Do you trust the designers of that system so much as to think that their > design will do better than POSIX on the long run? > "Better than POSIX" is actually very low standard in my view. POSIX is just a collection of things that just happen to be similar on most UNIXes. >> > I'm sure that POSIX has weaknesses. But how do you make sure that your >> > convenience layer wouldn't have just as many weaknesses which only show >> > later on? >> >> Then it can be changed. It's only an interface for the user to enter >> something in a terminal. >> You are speaking as if there was only single shell used throughout all >> UNIX systems. > > No. I just take into account that many scripts will use your simplification > layer,so it will become a kind of API, and more and more applications will > depend on a certain version of it. If those applications are written in shell scripting it is the choice of the author. Such applications always depend on having the right version of the right shell. > >> Not using separate processes gives very poor reliability. Never had >> your browser crash because of a plugin? > > So we are now talking redesigning most applications. Yes, most applications are unreliable, insecure, miss important functionality, and have poor UI. That's true whatever system they run on. > >> > But I do think that porting to the Hurd should prove quite a bit easier >> > than porting to a system without POSIX layer. >> >> Why so? There's nothing stopping you from adding libposix into the >> system that implements the posix interfaces commonly used by >> applications that would be missing otherwise. > > Will you supply the libposix, or do I have to write it myself? Of course, a system that wants non-trivial number of applications has to include it. > > And if it's there, how many programs will just use that? I do not care. For most applications it is good enough that they use it. They will just get the impression that they run on an empty POSIX system. >> No, it's not easier. It's just reinventing the wheel, all the way >> from square wheel to semi-rounded one. > > Then why do so many people do it? I have no idea. Perhaps they want their own special wheel shape with their name written on it, or there is no usable library that implements what they want. >> > So what keeps him from just modifying that first process to give him >> > power again? >> >> Nothing. However, if particular version of the system were verified >> for use with DRM protected content modifying that process would void >> that verification. > > And who keeps me from modifying the routinee h uses for checking the > verification? Put simply you cannot modify that, it's part of the platform hardware. For more elaborate answer search for TPM discussions here or elsewhere. [...] >> > But for me it seems that the patching and porting would be far more work >> > on a system without POSIX layer. >> >> Where does KDE deal with POSIX? > > To take the simplest example: User management. I never used KDE for user management. Still you can just say that part does not work, or port that single part if you are concerned. It would not work perfectly on the Hurd either. > >> > The translators are transparent to the mail client, so I can still change >> > my system layout with them even though the Mail program doesn't see them. >> > >> > So they still offer an advantage. >> >> There is no reason why the situation with capabilities should be different. >> >> However, from your answers it looks like you know little about >> software and system management, let alone writing software so I >> suggest you look into that before we continue the debate about >> feasibility of porting software to one kind of system or another. > > I know less about coding than an experienced programmer (I only write programs > for a bit more than a year now), and my system management is limited to about > 5 years of experience with Gentoo and university courses which sum up to about > 2/3rd of a bachlor in informatics (I'm studying physics, and I learned stuff > like high performance cluster file systems simply because it interested me, > not because I needed it). > > (there's a reason why I do web editing for the Hurd and not lowlevel > programming) > > But I know that just the changes Gentoo ebuilds make to get programs running > in the environment they are designed for can become quite mmuch work, and I > get the impression of quite much pain when I think about porting nontrivial > stuff to a pure capabilities system. You experience pretty much the same pain porting stuff to the Hurd which takes POSIX to the letter and does not implement certain optional aids on which many POSIX programmers like to rely. Thanks Michal