Well...
The author has me dead to rights. If there's a complaint here, it's that Unix has only two rings (user and kernel), not that setuid is inflexible.
I don't have any complaint, by the way, with the X86 system. My only point was that a significantly simpler system (e.g. that on Multics) is all you need burned into the chip.
I hope not to get trolled for posting a reference that is probably not too hard to find on search engines. However, if any of the readers of this would like to see a much broader range of information on Multics, I can recommend:
The reference web site for Multics history
This poster is completely correct. There's nothing magic about hardware. It's particularly hard to tamper with, and that's it.
If someone wanted to relaunch the Multics gate/ring inter-domain call mechanism on X86, (say, to give a meaningful alternative to setuid) I'd recommend against using the incredible hair-ball for the purpose built into the X86 architecture. You can't 'read the source' and it would take an immense amount of testing.
Instead, I'd suggest isolating a very carefully written and reviewed microkernel to take responsibility for validating inter-protection-domain calls and copying parameters.
Multics had significant commercial success, both in secure timesharing applications in the US and in Europe. In the end, Honeywell placed its bets elsewhere, and Multics withered away.
To those of us who worked in it, the sneering comments about 'top down debacle' are an ongoing demonstration of Gresham's law as it applies to information on the Internet. Ignorance is never, seemingly, an impediment to a smart-ass comment.
Try using, perchance, a system in which all the command line arguments were consistent and predictable, and the command names were meaningful.
Or, for that matter, a system in which the fundamental data access model was mapping into memory.
Or in which there are more security domains than 'all-powerful-root' and 'everyone else'.
Unix was born as an effort to get some approximation of Multics onto minicomputer hardware. It worked pretty well. The authors of Unix weren't too fond of our rather structured development process. They didn't need the security and reliability that we did all that work to try to get, and they did want heaps of functionality from unpaid grad students in no time flat.
Over the years, many of Multics' ideas have slowly leaked back into Unix: dynamic linking, memory mapping, command args with names and not just letters, etc. No surprise: they were good ideas, and Unix has absorbed them as processor power, memory prices, and the slow pace of rediscovery of the wheel has allowed.
There's quite a platoon of Multics alumni in the industry, applying the lessons we learned, good and bad, wherever we go.
This being slashdot, I (mis)read the headline as 'geeks stick to walls'. I was disappointed. I was expecting a discussion of the most effective way to stick an geek to the ceiling, like praising Microsoft.
Developers are annoying. They Do Stuff. They don't just stick with the superficial, obvious, ways of using your product. When they do, they get into trouble. Things break. Or they get confused.
And they call support.
And when I call support for a product for a developer, I expect to communicate with a person who has a clue. All too often, I find myself attempting to explain programming 101 to some reverse-telemarketer trained to look for my issue on a list and compensated for making me go away as soon as possible.
Of course, best is if your product has really been tested in the corners, and just works. Next to that, your only hope is if the first line support people have the qualifications that consumer software companies reserve for third-line -- if they have them at all. That means people with the training and experience to have actually used your stuff.
In other words, your developers. Make your developers work the support line in rotation, and watch your bug-counts drop as they get personal experience in the value of fixing it before they ship it.
Most development environments seem to be designed, tested, documented, and marketed by people who never think of trying out an application with more than four source files and 100 lines of code. They look cute in a demo, and are completely frustrating and unproductive for volume. In fact, usually they crash and burn. When they don't, they subject you to 'death by 100 dialog boxes.' Like, for example, a debugger which always pops up a query when a particular condition is detected, and no way to tell it to ignore the condition the first 100 times it occurs.
Source control systems are particularly prone to this evil. They present very cute GUIs. Then you try to organize a merge of 100 files with them. One file at a time. Hours later...
I'm not a great fan of Microsoft, but I have to say that, after all these years, Visual Studio very nearly manages to combine a convenient GUI with the gestures requires to productively work on a large scale. Various attempts at GUI-ified debuggers from Sun and HP never made it nearly as far.
All of which adds up to: if you build something that us really useful to pros, pros will use it. Regardless of the volume of attractive nuisance you put on the web or on tradeshows.
The most important characteristic of development tools is that they don't last very long. Those of us who have been around for a while are very leery of closed environments, however convenient.
Build your (e.g.) Java application in Magic Environment X, wait 4 months, and you are high and dry. Even if Magic Environment X comes from IBM or Oracle. The big players change strategy about as often as some people change their underwear, and for the same reasons. The smaller players die. Sure, I use things from the IBM site, but you won't catch me committing a development product to Visual Age, sticking me with a ton of proprietary metadata which will break next month. If I can't edit all of it in emacs (in a pinch), I look for some other way.
So, if you'd like us to use your stuff, don't play the game of trying to lure us in and trap us. We've been fooled before. Au Contraire, make it really clear just how much effort we are committing in buying into your tool, and just how much trouble we might be in if we need to get back out. The lower those barriers, the likelier that we'll play.
Slashdot Mirror
Paul had a platoon of fellow Multicians at Stratus. For that matter, THVanVleck was a major force at Tandem.
Well ...
The author has me dead to rights. If there's a complaint here, it's that Unix has only two rings (user and kernel), not that setuid is inflexible.
I don't have any complaint, by the way, with the X86 system. My only point was that a significantly simpler system (e.g. that on Multics) is all you need burned into the chip.
I hope not to get trolled for posting a reference that is probably not too hard to find on search engines. However, if any of the readers of this would like to see a much broader range of information on Multics, I can recommend:
The reference web site for Multics history
This poster is completely correct. There's nothing magic about hardware. It's particularly hard to tamper with, and that's it.
If someone wanted to relaunch the Multics gate/ring inter-domain call mechanism on X86, (say, to give a meaningful alternative to setuid) I'd recommend against using the incredible hair-ball for the purpose built into the X86 architecture. You can't 'read the source' and it would take an immense amount of testing.
Instead, I'd suggest isolating a very carefully written and reviewed microkernel to take responsibility for validating inter-protection-domain calls and copying parameters.
Multics had significant commercial success, both in secure timesharing applications in the US and in Europe. In the end, Honeywell placed its bets elsewhere, and Multics withered away. To those of us who worked in it, the sneering comments about 'top down debacle' are an ongoing demonstration of Gresham's law as it applies to information on the Internet. Ignorance is never, seemingly, an impediment to a smart-ass comment. Try using, perchance, a system in which all the command line arguments were consistent and predictable, and the command names were meaningful. Or, for that matter, a system in which the fundamental data access model was mapping into memory. Or in which there are more security domains than 'all-powerful-root' and 'everyone else'. Unix was born as an effort to get some approximation of Multics onto minicomputer hardware. It worked pretty well. The authors of Unix weren't too fond of our rather structured development process. They didn't need the security and reliability that we did all that work to try to get, and they did want heaps of functionality from unpaid grad students in no time flat. Over the years, many of Multics' ideas have slowly leaked back into Unix: dynamic linking, memory mapping, command args with names and not just letters, etc. No surprise: they were good ideas, and Unix has absorbed them as processor power, memory prices, and the slow pace of rediscovery of the wheel has allowed. There's quite a platoon of Multics alumni in the industry, applying the lessons we learned, good and bad, wherever we go.
This being slashdot, I (mis)read the headline as 'geeks stick to walls'. I was disappointed. I was expecting a discussion of the most effective way to stick an geek to the ceiling, like praising Microsoft.
Developers are annoying. They Do Stuff. They don't just stick with the superficial, obvious, ways of using your product. When they do, they get into trouble. Things break. Or they get confused. And they call support. And when I call support for a product for a developer, I expect to communicate with a person who has a clue. All too often, I find myself attempting to explain programming 101 to some reverse-telemarketer trained to look for my issue on a list and compensated for making me go away as soon as possible. Of course, best is if your product has really been tested in the corners, and just works. Next to that, your only hope is if the first line support people have the qualifications that consumer software companies reserve for third-line -- if they have them at all. That means people with the training and experience to have actually used your stuff. In other words, your developers. Make your developers work the support line in rotation, and watch your bug-counts drop as they get personal experience in the value of fixing it before they ship it.
Most development environments seem to be designed, tested, documented, and marketed by people who never think of trying out an application with more than four source files and 100 lines of code. They look cute in a demo, and are completely frustrating and unproductive for volume. In fact, usually they crash and burn. When they don't, they subject you to 'death by 100 dialog boxes.' Like, for example, a debugger which always pops up a query when a particular condition is detected, and no way to tell it to ignore the condition the first 100 times it occurs. Source control systems are particularly prone to this evil. They present very cute GUIs. Then you try to organize a merge of 100 files with them. One file at a time. Hours later ...
I'm not a great fan of Microsoft, but I have to say that, after all these years, Visual Studio very nearly manages to combine a convenient GUI with the gestures requires to productively work on a large scale. Various attempts at GUI-ified debuggers from Sun and HP never made it nearly as far.
All of which adds up to: if you build something that us really useful to pros, pros will use it. Regardless of the volume of attractive nuisance you put on the web or on tradeshows.
The most important characteristic of development tools is that they don't last very long. Those of us who have been around for a while are very leery of closed environments, however convenient. Build your (e.g.) Java application in Magic Environment X, wait 4 months, and you are high and dry. Even if Magic Environment X comes from IBM or Oracle. The big players change strategy about as often as some people change their underwear, and for the same reasons. The smaller players die. Sure, I use things from the IBM site, but you won't catch me committing a development product to Visual Age, sticking me with a ton of proprietary metadata which will break next month. If I can't edit all of it in emacs (in a pinch), I look for some other way. So, if you'd like us to use your stuff, don't play the game of trying to lure us in and trap us. We've been fooled before. Au Contraire, make it really clear just how much effort we are committing in buying into your tool, and just how much trouble we might be in if we need to get back out. The lower those barriers, the likelier that we'll play.