Since I don't have any moderator points to mod you up, I'll point out that I agree with you and add a slightly longer post in the hope to catch a little more attention for an important subject;)
It's kind of sad that so many people rant on about problems of the Linux desktop without knowing about Freedesktop.
It's true: The biggest problem Linux has on the desktop is one of interoperability. There are still some applications that don't get Copy&Paste right (it's gotten a *lot* better though), and Drag&Drop across toolkits is mostly a disaster (but there are already numerous cases where it works).
Some people want to magically fix that by removing all toolkits except for one. Newsflash: This is never going to work. Even if you were to remove all toolkits except for one today, somebody would start writing a completely new one tomorrow. The real problem is that there were no (or unclear) inter-application communication standards. That's what the Freedesktop project tries to fix - and it does so successfully.
The nice thing is that Freedesktop works through evolution, rather than revolution.
Duffy said that both Linux and Max OS X versions of Doom III are moving in close development with the PC version and Hollenshead said that they will have Mac and Linux files available for download when Doom III is released for the PC for people who run those operating systems. An actual Mac retail box for Doom III is a possibility but a Linux retail release is unlikely.
This thing gets me every single time - why don't they just put the Mac and Linux binaries into the same box as the Windows binaries? It's not that difficult to realize that a standalone Linux retail box will likely flop (well, a game like Doom 3 might be the exception to prove the rule). Mac games are a slightly different beast, but a Mac retail box still isn't going to be significantly more successful.
So why not put everything into a single box? It's been successfully done with UT2003, and everything's there in the case of Doom 3. So what's the problem? I simply don't get it.
The point is that some people like to be visionary. Some people actually believe in clean, logical, scalable and powerful designs. Some people have dreams, and are actually working to realize them.
Apparently, you aren't like this (neither am I, or else I'd be actively participating in efforts like this; but I do at least understand these people at a certain level). That's fine; not everybody can (or wants to?) afford dreams. And granted, the stuff that is mentioned in the article is a lot less obvious than "enable long filenames instead of 8.3 limitations" [1].
Right now, there are compatibility issues etc. like you pointed out, so not everybody will be able to use the new features. Eventually, however, we (and this includes you, the parent poster) will all benefit from them once they become standard - and they will, at least in the Linux world. Lots of people are already using ReiserFS, and while that's not version 4, there won't be a large mental barrier for them to make the switch (and in the long term, mental barriers are always harder to overcome than technical barriers, but I digress).
Let me get to the actual point of this post. It's fair enough for you to *point out* the issues at hand. After all, you're right. However, you shouldn't *criticize* the people who work hard at improving our daily computing lives for what they do. Because in the long term, they're right, too.
[1] Please don't give me any "long filenames are less problematic than this" crap; people still joke about c:\progra~1
Actually, GConf was a particularly good example because it is possible to write new storage backends for GConf as plugins.
I'm sure that a GConf plugin that stores every key in its own file is extremely straightforward to write. Then the people who have "seen the light" will use that plugin, while the rest of the world is stuck with the (probably less efficient) XML files.
Keep in mind that implementing chmod() and the like efficiently without a chmod() syscall requires a new API for reading and writing files. A sequence of creat()/write()/close() requires going into the kernel three times, not to mention the allocation and deletion of a file descriptor.
Unless stuff like this can be combined into a single syscall, you have a problem. Not that that problem should be too hard to solve, it's just something to keep in mind...
I've been lurking on the AtheOS/Syllable mailing lists for a long time now. For a time I had the feeling that, given enough time, Syllable could really become a great operating system, because people were thinking in terms of clean design, looking at the big picture.
In the last few days, there has been an explosion of activity on the mailing list, and maybe it's just my pessimistic self, but I think the focus has shifted away from clean design to features. If this trend continues, and Syllable falls victim to featuritis and coding without the big picture in mind, it'll simply end up as yet another operating system.
Do you agree that this is a problem? If so, do you think it will be possible to keep this trend in check or even reverse it?
Okay, I seriously don't get this. It's the second time something like this has been posted on/., and there's _still_ no reference to Half-Life 2 in the article?
Re:what ?
on
Linus on DRM
·
· Score: 2, Informative
Some inherently flawed "security" mechanisms, such as DVD encryption, use private keys that are hidden in binaries. This security through obscurity thing obviously didn't work as we all know.
In fact, even the TCPA-style security uses hidden private keys and could be considered flawed. The difference is that with the TCPA, the private key is stored in a hardware device and not in the software, so it is much more difficult to retrieve.
Well, I'm not really sure about it, but if I read that law right, the copyright holders might be forced to give DeCSS to _you_.
Now this is obviously all in German, but have a look at the text, 95b. What it basically says (if I read the lawyerspeak correctly) is this: If a copyright holder uses technical protection measures to protect their work, they must provide certain people the means to circumvent this technical measure. This is the case in what you might call "fair use" situations such as: - translation into another form for physically challenged people - copying for educational purposes (i.e. teachers handing out copies to their class) - copying for personal use
In other words, I buy a "copy-protected" audio CD and the copyright holder has to provide me the means for ripping the tracks off the CD to add them to my Ogg collection. Sounds... interesting. I wonder what will happen when somebody goes to court over this.
This brings up an interesting issue. As far as I can tell, key signing is only useful for connecting an electronic identity (the PGP key) with a physical identity (the actual person involved).
When one's working a lot with people from all over the globe via the internet, and you're never going to meet most of them, you can't really make this connection. However, there could be other useful connections to make. For example, once I've emailed with the creator of software Foo a number of times, I do know that he really is the creator of that software, but I have no idea whether he's using his real name in the mail exchange. It would be useful if I could create a signature that says "yep, he created software Foo" without saying "yep, he's really ".
I do agree that GPU will eventually become more CPU-like, but...
"anything over 2 GTexel/s is really absurd for typical screen sizes"
Let's say the screen has 1 million pixels for simplicity (that's somewhere in between 1024x768 and 1280x1024). Let's say you really want smooth motion and target a framerate of 100fps. That means you need to produce 100 MPixels/s. At 2GTexel/s, that's 20 texels per resulting pixels. Now add a 2x overdraw (which is quite low I think) and you're left with 10 texels per resulting pixel. Many additional effects, esp. refraction and reflection need render to texture, i.e. you basically render (parts of) the scene twice, which obviously uses a lot of additional performance.
2GTexel/s doesn't sound so absurd anymore, does it?
It is harder to fool than an antivirus scanner because it is based on a whitelist (i.e. operating systems you trust) instead of a blacklist (i.e. list of [virus] signatures that you don't trust) like an antivirus scanner.
Anyway you're right, nothing is 100% secure. The sad thing is that operating systems could get a lot more secure in general without any change to the hardware - which is just more evidence that the TCPA is worried about a different kind of security than most normal people are worried about.
Please bear in mind that what follows is all hypothetical. It's an idea how a hardware-based "trust" platform can be used by "consumers" for their own good.
Imagine you want to go into an internet cafe to check out your mail. You have to enter your account information (username and password) using a computer that you do not control physically. This means - on current day platforms - that the computer might work against you without your knowledge - you can't really trust it. For all you know, there might be a keylogger on the computer, or some other software that could allow somebody to read your mail without you noticing it. This is a problem, and it could be solved with a hardware solution.
You need a small device that _you_ control physically (a smartcard?) that can connect to the computer and perform a trust handshake checking whether the computer runs an operating system that you trust (Windows, Linux, *BSD, it doesn't matter - you should get to decide). It'll give you an okay signal if the test passes. If it does, you can be very sure that the computer you are using doesn't work against you. IOW, you can be very sure no keylogger or similar is installed.
Obviously this is a hypothetical idea, and I'd be really surprised if that was what the big players of the TCPA had in mind. But it shows that the technology behind the TCPA isn't all evil, it's the people who use it. (Yes, that should have been a no-brainer)
I don't know about Russian, but the part about German is simply wrong.
The German word "Vaterland" (roughly fatherland) can be dated back to the 12th century (obviously in a slightly different form), according to a book on ethymology I've got here. So any connection with the nazis is pure imagination on your behalf. They may have invented the blitzkrieg, but the vaterland was already there. I could imagine that word gained a lot of importance during the 19th century when nationalism was strong throughout Europe.
Some interesting ideas, but there are problems. I'm in no way a HID designer or anything, but while reading your comment I tried to pay closer attention to the way I read it. Turns out that I (think I) try to get a hierarchical overview of the comment.
In other words, we don't read text in a linear fashion, letter by letter. Instead we first look at the general outline (paragraphs), then we begin at the first line, picking out individual words. Sometimes we might look back half a line to rescan a word and get the context right. Note that there _are_ scrolling displays, often seen in public places (and that tag). Now of course those are sub-optimal anyway because of their slow speed, but you should be able to observe how the eye jumps trying to obtain context on them. So I don't think moving the text on the display is a particularly good idea. There are related things one could try, though. For example text in smaller columns could make it easier to jump to the start of the next line.
Auto-compressing text to (selected) acrynoms is a very interesting It obviously needs to adapt to the user, but it's definitely worth a try. The more radical changes like gestures etc... could theoretically yield real efficiency gains, but they're all so difficult to learn...
When you're looking at it from a document-centric point of view, IDEs are in fact SDI applications.
Of course, the single document that is loaded is the _project_ you are working on. All those source files (or whatever) that are open within the IDE are only sub-parts of the actual "document" you are working on.
So conceptually, IDEs are SDI applications, even though they are usually implemented like MDI applications.
This is certainly true when migrating users don't have a knowledgable person guiding them. However, when they do have someone in the know to help them, it might be really different.
Yes, a Linux/KDE desktop isn't as radically different from Windows as what the article might suggest, but I might as well share a case I can directly experience...
After Windows completely messed up on my parents' computer, I decided to install Linux on it for them. Now my father still uses Windows at the office, so he can make objective comparisons.
So far, none of the complaints that I got have anything to do with the system simply being "different". They only had to do with situations where Linux obviously performs worse:
- printing is a nightmare because, with the exception of applications integrated into the desktop (KDE in this case), every single app has its own print dialog; functionality and settings vary greatly - OpenOffice 1.0 start up is horribly slow; this is partly to blame on low memory size, but StarOffice 5.1 on Win98 did load up considerably faster on the same hardware - OpenOffice isn't integrated into the desktop, i.e. its look and feel is completely different from all other programs - Konqueror is horribly slow/laggy as a file manager. Yes, there are probably faster file managing programs around, but then they wouldn't be as integrated...
On an interesting sidenote, my father (who is used to the likes of PhotoShop and Corel PhotoPaint) actually _likes_ TheGIMP since I gave him a short explanation of how it works! He very soon complained about the file open/save dialogs and printing, though - again, integration is the key.
Basically, there has been no fear or hostility towards anything being different. Many users are at least willing to give a new system a try. But they only want to try and learn things once. If they have to learn everything completely anew for every single application that they need to use, then they're just not going to switch to the new system.
This is something I've been thinking about lately. May sound weird by some, but it should be possible to find out whether you've been bugged (pardon the pun) by the police. Obviously, they won't tell you as long as the investigations are still going, but it would be _very_ interesting to know afterwards.
A good friend of my mother had been in regular contact with some RAF terrorists back in the '60s or '70s - AFAIK neither my mother nor said friend were actually involved in anything though. If I were in a situation like this I'd be curious to know how much the police has got in their archive about me. Anyway, I don't think many people on Slashdot know details about German law, so I guess I'll have to find out myself whether this is possible...
What you want to do _is_ possible on current hardware. A current-day operating system _could_ implement a signature on executables, and then only allow access to your bank account info to the signed banking program. You don't need special hardware to do this.
Now obviously, the signature (=trust) on the application is worth nothing if you don't trust the operating system.
Now let's assume that you trust the operating system in the form that it was installed on your computer. Let's further assume that the OS has means of protecting itself from running applications if the OS itself is loaded. Those are fairly safe assumptions to make, actually. So the only way that the OS could be turned malicious (trojaned, whatever) is by booting a different OS on the computer and manipulating the OS from there. However, that is only possible with physical access to the computer.
So what it boils down to: If your computer is reasonably physically secure - which is the case for virtually all home PCs at least - you can always trust your operating system. Even with current day hardware.
q.e.d, what you want to do is possible.
Now, the modified hardware changes one important thing. It can sign the operating system. We've just established that this isn't necessary for any reasonable security objectives, right? Then why do they want to implement a system which makes signing the OS possible? Well, it's quite simple I think. "They" want to be able to trust the operating system. But since "they" don't have physical access to your computer, "they" need a signature in order to be able to trust the OS. Once they have the signature for the OS, they can then trust the OS to establish trust of applications.
And the only reason I can think of that "they" would bother to trust your computer and the applications _you_ run is Digital Restrictions Management.
Sorry, I don't consider DRM a bad thing. A trusted PC interface means that those-that-publish will be able to do so electronically without knowing that it's going to be pirated the next day.
Guess what, I'd _love_ to see a DRM system that I can trust - both as a creator of "content" and as a consumer.
I would only be able to trust such a system if it were open, which implies that there could be a compatible, open-source implementation of the system. Now the obvious problem is that the kind of "security" that Digital Restrictions Management wants to provide can ultimately only work by security through obscurity. Kind of like what we saw with DVD encryption. And security through obscurity is obviously mutually exclusive with openness.
So it's just not going to happen.
I'd prefer to see an open, society-based solution to the "Intellectual Property" problems we're facing today, rather than a closed, locked down solution that gives tremendous power to the select few who built the solution.
Unix implemented on a microkernel?
on
The End Of Minix?
·
· Score: 3, Insightful
Hmm. I'm sure a microkernel system will work for a UN*X-like OS. However, I really doubt that it's a good idea to implement yet another Unix-alike on a microkernel - it won't really make use of the kernel.
Unix is built around the central idea of files (and the related pipes, sockets, etc...).
Microkernels, on the other hand, are built around the idea of IPC, or, to be more direct, function calls.
So if a microkernel is used only to exchange the function calls that are necessary to provide file system capabilities, then it is probably used very inefficiently.
I think microkernels are really the way to go for desktop systems, because desktop systems, while benefitting from the concept of files, have almost nothing to do with files. When you're working with a spreadsheet app, all that happens are function calls (or callbacks, which is really the same): you click the mouse, and the graphics/input systems calls a function in the spreadsheet app, which then performs some calculations. To display the changes, the spreadsheet app calls a series of functions in the graphics/input system. No files involved, are there?
Of course, the X client/server design uses a file (a socket) to communicate the function calls, but that's really just an unnecessary layer of complexity.
So yes, I'm calling for a paradigm shift. Implement a system on top of a microkernel that doesn't give a shit about Unix (if it can run most POSIX apps then great - but don't make it a priority). Make it a desktop system. Use C++ as the major language of the operating system, so that components that reside in a different address space can easily be accessed as native language objects - and applications won't have to bother whether those components are local, in a different address space or on a different computer. There are many things that need to be worked out, but it can result in a very sane and flexible design.
Maybe something like this has already been implemented (or started), but I haven't found anything - microkernel developers seem to be focussed extremely on theory instead of practice.
For all practical purposes, neither does the GPL. Companies built around linux solutions aren't making their money by selling licenses to the kernel.
Your definition of "practical purpose" seems a bit off. The initial license (if I understood correctly) wouldn't have allowed anyone to distribute the kernel and charge more than the cost of burning/pressing the CDs.
In other words, it would have prevented distributions from making any money - and distributions do make their money by selling the kernel (among other things, obviously).
Actually, the initial "license" of the Linux kernel was more restrictive than the GPL. For example, it didn't allow anyone to sell the kernel.
So yes, it was a pragmatic decision.
Slashdot Mirror
Since I don't have any moderator points to mod you up, I'll point out that I agree with you and add a slightly longer post in the hope to catch a little more attention for an important subject ;)
It's kind of sad that so many people rant on about problems of the Linux desktop without knowing about Freedesktop.
It's true: The biggest problem Linux has on the desktop is one of interoperability. There are still some applications that don't get Copy&Paste right (it's gotten a *lot* better though), and Drag&Drop across toolkits is mostly a disaster (but there are already numerous cases where it works).
Some people want to magically fix that by removing all toolkits except for one. Newsflash: This is never going to work. Even if you were to remove all toolkits except for one today, somebody would start writing a completely new one tomorrow.
The real problem is that there were no (or unclear) inter-application communication standards. That's what the Freedesktop project tries to fix - and it does so successfully.
The nice thing is that Freedesktop works through evolution, rather than revolution.
This thing gets me every single time - why don't they just put the Mac and Linux binaries into the same box as the Windows binaries?
It's not that difficult to realize that a standalone Linux retail box will likely flop (well, a game like Doom 3 might be the exception to prove the rule). Mac games are a slightly different beast, but a Mac retail box still isn't going to be significantly more successful.
So why not put everything into a single box? It's been successfully done with UT2003, and everything's there in the case of Doom 3. So what's the problem? I simply don't get it.
The point is that some people like to be visionary. Some people actually believe in clean, logical, scalable and powerful designs. Some people have dreams, and are actually working to realize them.
Apparently, you aren't like this (neither am I, or else I'd be actively participating in efforts like this; but I do at least understand these people at a certain level). That's fine; not everybody can (or wants to?) afford dreams.
And granted, the stuff that is mentioned in the article is a lot less obvious than "enable long filenames instead of 8.3 limitations" [1].
Right now, there are compatibility issues etc. like you pointed out, so not everybody will be able to use the new features. Eventually, however, we (and this includes you, the parent poster) will all benefit from them once they become standard - and they will, at least in the Linux world. Lots of people are already using ReiserFS, and while that's not version 4, there won't be a large mental barrier for them to make the switch (and in the long term, mental barriers are always harder to overcome than technical barriers, but I digress).
Let me get to the actual point of this post.
It's fair enough for you to *point out* the issues at hand. After all, you're right.
However, you shouldn't *criticize* the people who work hard at improving our daily computing lives for what they do. Because in the long term, they're right, too.
[1] Please don't give me any "long filenames are less problematic than this" crap; people still joke about c:\progra~1
Actually, GConf was a particularly good example because it is possible to write new storage backends for GConf as plugins.
I'm sure that a GConf plugin that stores every key in its own file is extremely straightforward to write. Then the people who have "seen the light" will use that plugin, while the rest of the world is stuck with the (probably less efficient) XML files.
Keep in mind that implementing chmod() and the like efficiently without a chmod() syscall requires a new API for reading and writing files. A sequence of creat()/write()/close() requires going into the kernel three times, not to mention the allocation and deletion of a file descriptor.
Unless stuff like this can be combined into a single syscall, you have a problem. Not that that problem should be too hard to solve, it's just something to keep in mind...
I've been lurking on the AtheOS/Syllable mailing lists for a long time now. For a time I had the feeling that, given enough time, Syllable could really become a great operating system, because people were thinking in terms of clean design, looking at the big picture.
In the last few days, there has been an explosion of activity on the mailing list, and maybe it's just my pessimistic self, but I think the focus has shifted away from clean design to features. If this trend continues, and Syllable falls victim to featuritis and coding without the big picture in mind, it'll simply end up as yet another operating system.
Do you agree that this is a problem? If so, do you think it will be possible to keep this trend in check or even reverse it?
Okay, I seriously don't get this. It's the second time something like this has been posted on /., and there's _still_ no reference to Half-Life 2 in the article?
Some inherently flawed "security" mechanisms, such as DVD encryption, use private keys that are hidden in binaries. This security through obscurity thing obviously didn't work as we all know.
In fact, even the TCPA-style security uses hidden private keys and could be considered flawed. The difference is that with the TCPA, the private key is stored in a hardware device and not in the software, so it is much more difficult to retrieve.
Well, I'm not really sure about it, but if I read that law right, the copyright holders might be forced to give DeCSS to _you_.
Now this is obviously all in German, but have a look at the text, 95b. What it basically says (if I read the lawyerspeak correctly) is this:
If a copyright holder uses technical protection measures to protect their work, they must provide certain people the means to circumvent this technical measure. This is the case in what you might call "fair use" situations such as:
- translation into another form for physically challenged people
- copying for educational purposes (i.e. teachers handing out copies to their class)
- copying for personal use
In other words, I buy a "copy-protected" audio CD and the copyright holder has to provide me the means for ripping the tracks off the CD to add them to my Ogg collection. Sounds... interesting. I wonder what will happen when somebody goes to court over this.
This brings up an interesting issue. As far as I can tell, key signing is only useful for connecting an electronic identity (the PGP key) with a physical identity (the actual person involved).
When one's working a lot with people from all over the globe via the internet, and you're never going to meet most of them, you can't really make this connection. However, there could be other useful connections to make.
For example, once I've emailed with the creator of software Foo a number of times, I do know that he really is the creator of that software, but I have no idea whether he's using his real name in the mail exchange.
It would be useful if I could create a signature that says "yep, he created software Foo" without saying "yep, he's really ".
I do agree that GPU will eventually become more CPU-like, but...
"anything over 2 GTexel/s is really absurd for
typical screen sizes"
Let's say the screen has 1 million pixels for simplicity (that's somewhere in between 1024x768 and 1280x1024). Let's say you really want smooth motion and target a framerate of 100fps. That means you need to produce 100 MPixels/s. At 2GTexel/s, that's 20 texels per resulting pixels. Now add a 2x overdraw (which is quite low I think) and you're left with 10 texels per resulting pixel.
Many additional effects, esp. refraction and reflection need render to texture, i.e. you basically render (parts of) the scene twice, which obviously uses a lot of additional performance.
2GTexel/s doesn't sound so absurd anymore, does it?
It is harder to fool than an antivirus scanner because it is based on a whitelist (i.e. operating systems you trust) instead of a blacklist (i.e. list of [virus] signatures that you don't trust) like an antivirus scanner.
Anyway you're right, nothing is 100% secure. The sad thing is that operating systems could get a lot more secure in general without any change to the hardware - which is just more evidence that the TCPA is worried about a different kind of security than most normal people are worried about.
You mean like http://www.linuxbios.org/? ;)
Please bear in mind that what follows is all hypothetical. It's an idea how a hardware-based "trust" platform can be used by "consumers" for their own good.
Imagine you want to go into an internet cafe to check out your mail. You have to enter your account information (username and password) using a computer that you do not control physically. This means - on current day platforms - that the computer might work against you without your knowledge - you can't really trust it. For all you know, there might be a keylogger on the computer, or some other software that could allow somebody to read your mail without you noticing it. This is a problem, and it could be solved with a hardware solution.
You need a small device that _you_ control physically (a smartcard?) that can connect to the computer and perform a trust handshake checking whether the computer runs an operating system that you trust (Windows, Linux, *BSD, it doesn't matter - you should get to decide). It'll give you an okay signal if the test passes. If it does, you can be very sure that the computer you are using doesn't work against you. IOW, you can be very sure no keylogger or similar is installed.
Obviously this is a hypothetical idea, and I'd be really surprised if that was what the big players of the TCPA had in mind. But it shows that the technology behind the TCPA isn't all evil, it's the people who use it. (Yes, that should have been a no-brainer)
I don't know about Russian, but the part about German is simply wrong.
The German word "Vaterland" (roughly fatherland) can be dated back to the 12th century (obviously in a slightly different form), according to a book on ethymology I've got here. So any connection with the nazis is pure imagination on your behalf. They may have invented the blitzkrieg, but the vaterland was already there. I could imagine that word gained a lot of importance during the 19th century when nationalism was strong throughout Europe.
Some interesting ideas, but there are problems.
I'm in no way a HID designer or anything, but while reading your comment I tried to pay closer attention to the way I read it. Turns out that I (think I) try to get a hierarchical overview of the comment.
In other words, we don't read text in a linear fashion, letter by letter. Instead we first look at the general outline (paragraphs), then we begin at the first line, picking out individual words. Sometimes we might look back half a line to rescan a word and get the context right.
Note that there _are_ scrolling displays, often seen in public places (and that tag). Now of course those are sub-optimal anyway because of their slow speed, but you should be able to observe how the eye jumps trying to obtain context on them.
So I don't think moving the text on the display is a particularly good idea. There are related things one could try, though. For example text in smaller columns could make it easier to jump to the start of the next line.
Auto-compressing text to (selected) acrynoms is a very interesting It obviously needs to adapt to the user, but it's definitely worth a try.
The more radical changes like gestures etc... could theoretically yield real efficiency gains, but they're all so difficult to learn...
I thought Freenet - http://www.freenetproject.org/ - is supposedly designed with DOS attacks etc... in mind.
/. effect after the 0.5 announce, but things are improving.
Yes, it apparently suffered from
When you're looking at it from a document-centric point of view, IDEs are in fact SDI applications.
Of course, the single document that is loaded is the _project_ you are working on. All those source files (or whatever) that are open within the IDE are only sub-parts of the actual "document" you are working on.
So conceptually, IDEs are SDI applications, even though they are usually implemented like MDI applications.
This is certainly true when migrating users don't have a knowledgable person guiding them. However, when they do have someone in the know to help them, it might be really different.
Yes, a Linux/KDE desktop isn't as radically different from Windows as what the article might suggest, but I might as well share a case I can directly experience...
After Windows completely messed up on my parents' computer, I decided to install Linux on it for them. Now my father still uses Windows at the office, so he can make objective comparisons.
So far, none of the complaints that I got have anything to do with the system simply being "different". They only had to do with situations where Linux obviously performs worse:
- printing is a nightmare because, with the exception of applications integrated into the desktop (KDE in this case), every single app has its own print dialog; functionality and settings vary greatly
- OpenOffice 1.0 start up is horribly slow; this is partly to blame on low memory size, but StarOffice 5.1 on Win98 did load up considerably faster on the same hardware
- OpenOffice isn't integrated into the desktop, i.e. its look and feel is completely different from all other programs
- Konqueror is horribly slow/laggy as a file manager. Yes, there are probably faster file managing programs around, but then they wouldn't be as integrated...
On an interesting sidenote, my father (who is used to the likes of PhotoShop and Corel PhotoPaint) actually _likes_ TheGIMP since I gave him a short explanation of how it works! He very soon complained about the file open/save dialogs and printing, though - again, integration is the key.
Basically, there has been no fear or hostility towards anything being different. Many users are at least willing to give a new system a try. But they only want to try and learn things once.
If they have to learn everything completely anew for every single application that they need to use, then they're just not going to switch to the new system.
This is something I've been thinking about lately. May sound weird by some, but it should be possible to find out whether you've been bugged (pardon the pun) by the police. Obviously, they won't tell you as long as the investigations are still going, but it would be _very_ interesting to know afterwards.
A good friend of my mother had been in regular contact with some RAF terrorists back in the '60s or '70s - AFAIK neither my mother nor said friend were actually involved in anything though. If I were in a situation like this I'd be curious to know how much the police has got in their archive about me.
Anyway, I don't think many people on Slashdot know details about German law, so I guess I'll have to find out myself whether this is possible...
*sigh*
What you want to do _is_ possible on current hardware. A current-day operating system _could_ implement a signature on executables, and then only allow access to your bank account info to the signed banking program. You don't need special hardware to do this.
Now obviously, the signature (=trust) on the application is worth nothing if you don't trust the operating system.
Now let's assume that you trust the operating system in the form that it was installed on your computer. Let's further assume that the OS has means of protecting itself from running applications if the OS itself is loaded. Those are fairly safe assumptions to make, actually.
So the only way that the OS could be turned malicious (trojaned, whatever) is by booting a different OS on the computer and manipulating the OS from there. However, that is only possible with physical access to the computer.
So what it boils down to: If your computer is reasonably physically secure - which is the case for virtually all home PCs at least - you can always trust your operating system. Even with current day hardware.
q.e.d, what you want to do is possible.
Now, the modified hardware changes one important thing. It can sign the operating system.
We've just established that this isn't necessary for any reasonable security objectives, right?
Then why do they want to implement a system which makes signing the OS possible? Well, it's quite simple I think. "They" want to be able to trust the operating system. But since "they" don't have physical access to your computer, "they" need a signature in order to be able to trust the OS. Once they have the signature for the OS, they can then trust the OS to establish trust of applications.
And the only reason I can think of that "they" would bother to trust your computer and the applications _you_ run is Digital Restrictions Management.
Sorry, I don't consider DRM a bad thing. A trusted PC interface means that those-that-publish will be able to do so electronically without knowing that it's going to be pirated the next day.
Guess what, I'd _love_ to see a DRM system that I can trust - both as a creator of "content" and as a consumer.
I would only be able to trust such a system if it were open, which implies that there could be a compatible, open-source implementation of the system.
Now the obvious problem is that the kind of "security" that Digital Restrictions Management wants to provide can ultimately only work by security through obscurity. Kind of like what we saw with DVD encryption. And security through obscurity is obviously mutually exclusive with openness.
So it's just not going to happen.
I'd prefer to see an open, society-based solution to the "Intellectual Property" problems we're facing today, rather than a closed, locked down solution that gives tremendous power to the select few who built the solution.
Hmm. I'm sure a microkernel system will work for a UN*X-like OS. However, I really doubt that it's a good idea to implement yet another Unix-alike on a microkernel - it won't really make use of the kernel.
Unix is built around the central idea of files (and the related pipes, sockets, etc...).
Microkernels, on the other hand, are built around the idea of IPC, or, to be more direct, function calls.
So if a microkernel is used only to exchange the function calls that are necessary to provide file system capabilities, then it is probably used very inefficiently.
I think microkernels are really the way to go for desktop systems, because desktop systems, while benefitting from the concept of files, have almost nothing to do with files. When you're working with a spreadsheet app, all that happens are function calls (or callbacks, which is really the same): you click the mouse, and the graphics/input systems calls a function in the spreadsheet app, which then performs some calculations. To display the changes, the spreadsheet app calls a series of functions in the graphics/input system.
No files involved, are there?
Of course, the X client/server design uses a file (a socket) to communicate the function calls, but that's really just an unnecessary layer of complexity.
So yes, I'm calling for a paradigm shift. Implement a system on top of a microkernel that doesn't give a shit about Unix (if it can run most POSIX apps then great - but don't make it a priority). Make it a desktop system. Use C++ as the major language of the operating system, so that components that reside in a different address space can easily be accessed as native language objects - and applications won't have to bother whether those components are local, in a different address space or on a different computer. There are many things that need to be worked out, but it can result in a very sane and flexible design.
Maybe something like this has already been implemented (or started), but I haven't found anything - microkernel developers seem to be focussed extremely on theory instead of practice.
For all practical purposes, neither does the GPL. Companies built around linux solutions aren't making their money by selling licenses to the kernel.
Your definition of "practical purpose" seems a bit off. The initial license (if I understood correctly) wouldn't have allowed anyone to distribute the kernel and charge more than the cost of burning/pressing the CDs.
In other words, it would have prevented distributions from making any money - and distributions do make their money by selling the kernel (among other things, obviously).
Actually, the initial "license" of the Linux kernel was more restrictive than the GPL. For example, it didn't allow anyone to sell the kernel. So yes, it was a pragmatic decision.