A recent email thread on the cap-talk maling list (set up by Jonathan Shapiro, the author of the linked article) recently discussed Singularity as a capability system . Summary: it is a capability system but does not take advantage of the fact very well.
As others have pointed out, "managed" code refers to the use of automatically managed memory allocation rather than manual use of malloc/free. By combining that with type safety and array bounds checking, many classes of C/C++ bugs are eliminated or reduced. The penalty of course is that you need to run a garbage collector.
Assert() is a big assest to program maintanence and debugging.
Bad uses of assert() are like bad comments: they do nothing to help you. Good uses of assert() serve two purposes: (1) to document assumptions made by the code, and invariants that must be maintained, and (2) to make debugging easier when and assumption/invariant is violated.
When reading code, you know there are probably some corner cases that don't work correctly. There are going to be assumptions embedded in the code. Future maintainers of the code need to know these assumptions; they can either find it by violating them and then tripping over the resulting bugs, or else by reading comments.
/* foo is less than the # of columns, and bar is a hashtable which contains a value for the key foo */
to the same effect, except that the assert() statments are machine-checkable.
Assert() follows the principle of "fail fast": when something goes wrong, you want the program to stop right away, before it starts corrupting things. When you get a backtrace at (or soon after) the problem occurred, it is much easier to track down what's gone wrong, than if the program crashes from a null pointer exception a few million instructions later. Or worse, the corrupt data might not be noticed for a long time; at that point you can all you know is that _some_ piece of code corrupted data. An assert() can significantly narrow the search for the offending line(s).
Yes, a pure capability system is the state-of-the-art in computer security (assuming you have an intelligent way of handing out capabilities -- a problem I have not seen the solution to yet).
But, you should note that if you can run a per-system call check (which Subterfuge seems to let you), you can implement a capability system on top of UNIX! The whole point of Subterfuge is that you can insert your own algorithm for deciding if process P can perform action A. This allows you to implement ACL's, capabilities, or whatever you can think up! The speeed will be underwhelming (though much optimization is possible), but it will work, right now, with all of your existing programs.
Show me a pure capability system that does this, and I will eat my hat (and then run said system). Bonus points if it supports all the hardware Linux runs on.
ps, for a good introduction to capabilities the state of such operating systems research visit the EROS website and visit the "introductory essays" section.
I disagree. Corel may tell you that there was "no demand". But, I think a better way to put it would be:
There was enough less demand for their Linux products that Corel would not have made $135 million on profit on them.
Risky projects like Corel's Linux initiatives are the first to go when lean times come. But saying that Microsoft's investment wasn't involved is silly -- if the investment came without strings attached, they would have been able to continue their Linux operations. Or, at least they would still have some support for those products! I used WordPerfect 5.1 for DOS well after the release of Win95, and still got fantastic support for it. But just try and get support for one of their less-than 2 year old Linux products!
> Linux users just don't by(sic) software (except me...
Actually, very few people buy all the software they use. I also bought WordPerfect for Linux, and would have bought Corel Draw! for Linux except that I didn't hear about it until it had already been discontinued. I know about 10 people who used Corel's Linux products, and at least 8 of them paid for legal licenses.
IIRC, a similar thing happend a few years back when Apple was still early in the process of incorporating the NeXT tree into what would become OS X. At that time, Apple was talking about the possibility of selling "Rhapsody" (sp?) for x86 hardware in addition to Macintoshes. Some money was transfered (I don't know the specifics) from Microsoft to Apple, and all talk of MacOS running on x86 PCs vanished.
Yes, UltraSPARC's run significantly slower in 64 bit mode. IIRC, this is because it takes more instructions to load 64 bit constants and access 64 bit pointers. This is not true of all 64 bit processors -- and it is not true of x86-64.
The x86-64 architecture allows 64 bit programs to take advantage of the extra precision (and doubles the number of general-purpose registers, which x86 desperately needs), without forcing them to take the performance hit of using the full 64 bit addressing. It also adds a new, IP-relative addressing, which makes position-independant code (ie, shared libraries) much more efficient. There will be an increase in code size (and possibly a performance drop, but this depends on how AMD implements the 'movabs' instruction) when you start using more than 4GB of data. And, when you start using >4GB of code, things get yucky (requiring indirect jumps).
But, the point is, x86-64 will run all your 32 bit x86 code at full speed, and if you're able to re-compile your programs for 64 bit mode, you should get a performance boost, if only from getting 9 more registers (8 + no longer need to keep a pointer to the GOT).
Actually, having read the license, I found the following loophole:
. . . if you buy the compiler, you are allowed to distribute code that you compile with icc;) Find someone who has paid for icc, and ask them nicely if they would compile something for you. No, it's not open-source, but you can distribute source code along with an optimized binary if you're so inclined.
I bought a Lian-Li case because I was building a computer as a gift, and I thought it looked really slick. When it arrived, though I was shocked by how light it was -- just under 6 Kg without mobo/powersupply/etc. I've since bought 3 more for computers that I frequently move, and it really makes a difference. I am not uncomfortable carrying 2 or even all 3 of them at once (comfort including fear of dropping, that is).
Yes, they cost significantly more. They are also significantly more convienient if you have to open them up frequently. Are they better a cooling? I suspect that, for the difference in price between a "standard" case and a Lian-Li AL case, you could buy fans, etc. that would make more of a difference. Even their large server cases are refreshingly light. These cases are definitely not for everyone, but if you need a large, light, accessible, and sturdy case, I don't know of anything better.
(and if you know of anything better, I'd like to hear about it... these are awfully expensive;)
> . ..or get some other designed bus to support the much higher throughputs.
This is exactly what AGP was designed for -- high-bandwidth I/O to main memory, without blocking the PCI bus. Plus, the AGP GART can do most of the address translation you would need.
All modern PC (and even Apple) chipsets have an AGP interface, which is wasted on a headless server. . . until now. AGP even provdes extra power (even the obscene AGP PRO), so that an onboard battery/HDD could be used to backup.
> To take advantage of RAMdisks, you pretty much need to have your computer on all the time, or in standby mode when you're not using it.
This is true. *or* you could have your computer net-boot from a a server with one of these. Even 100megabit transferring from memory will feel faster than a local hard disk. And gigabit over copper is becoming very affordabl these days.
Slashdot Mirror
A recent email thread on the cap-talk maling list (set up by Jonathan Shapiro, the author of the linked article) recently discussed Singularity as a capability system . Summary: it is a capability system but does not take advantage of the fact very well.
As others have pointed out, "managed" code refers to the use of automatically managed memory allocation rather than manual use of malloc/free. By combining that with type safety and array bounds checking, many classes of C/C++ bugs are eliminated or reduced. The penalty of course is that you need to run a garbage collector.
Assert() is a big assest to program maintanence and debugging.
Bad uses of assert() are like bad comments: they do nothing to help you. Good uses of assert() serve two purposes: (1) to document assumptions made by the code, and invariants that must be maintained, and (2) to make debugging easier when and assumption/invariant is violated.
When reading code, you know there are probably some corner cases that don't work correctly. There are going to be assumptions embedded in the code. Future maintainers of the code need to know these assumptions; they can either find it by violating them and then tripping over the resulting bugs, or else by reading comments.
is as readable as a
to the same effect, except that the assert() statments are machine-checkable.Assert() follows the principle of "fail fast": when something goes wrong, you want the program to stop right away, before it starts corrupting things. When you get a backtrace at (or soon after) the problem occurred, it is much easier to track down what's gone wrong, than if the program crashes from a null pointer exception a few million instructions later. Or worse, the corrupt data might not be noticed for a long time; at that point you can all you know is that _some_ piece of code corrupted data. An assert() can significantly narrow the search for the offending line(s).
Yes, a pure capability system is the state-of-the-art in computer security (assuming you have an intelligent way of handing out capabilities -- a problem I have not seen the solution to yet).
But, you should note that if you can run a per-system call check (which Subterfuge seems to let you), you can implement a capability system on top of UNIX! The whole point of Subterfuge is that you can insert your own algorithm for deciding if process P can perform action A. This allows you to implement ACL's, capabilities, or whatever you can think up! The speeed will be underwhelming (though much optimization is possible), but it will work, right now, with all of your existing programs.
Show me a pure capability system that does this, and I will eat my hat (and then run said system). Bonus points if it supports all the hardware Linux runs on.
ps, for a good introduction to capabilities the state of such operating systems research visit the EROS website and visit the "introductory essays" section.
I disagree. Corel may tell you that there was "no demand". But, I think a better way to put it would be:
There was enough less demand for their Linux products that Corel would not have made $135 million on profit on them.
Risky projects like Corel's Linux initiatives are the first to go when lean times come. But saying that Microsoft's investment wasn't involved is silly -- if the investment came without strings attached, they would have been able to continue their Linux operations. Or, at least they would still have some support for those products! I used WordPerfect 5.1 for DOS well after the release of Win95, and still got fantastic support for it. But just try and get support for one of their less-than 2 year old Linux products!
> Linux users just don't by(sic) software (except me ...
Actually, very few people buy all the software they use. I also bought WordPerfect for Linux, and would have bought Corel Draw! for Linux except that I didn't hear about it until it had already been discontinued. I know about 10 people who used Corel's Linux products, and at least 8 of them paid for legal licenses.
IIRC, a similar thing happend a few years back when Apple was still early in the process of incorporating the NeXT tree into what would become OS X. At that time, Apple was talking about the possibility of selling "Rhapsody" (sp?) for x86 hardware in addition to Macintoshes. Some money was transfered (I don't know the specifics) from Microsoft to Apple, and all talk of MacOS running on x86 PCs vanished.
Yes, UltraSPARC's run significantly slower in 64 bit mode. IIRC, this is because it takes more instructions to load 64 bit constants and access 64 bit pointers. This is not true of all 64 bit processors -- and it is not true of x86-64.
The x86-64 architecture allows 64 bit programs to take advantage of the extra precision (and doubles the number of general-purpose registers, which x86 desperately needs), without forcing them to take the performance hit of using the full 64 bit addressing. It also adds a new, IP-relative addressing, which makes position-independant code (ie, shared libraries) much more efficient. There will be an increase in code size (and possibly a performance drop, but this depends on how AMD implements the 'movabs' instruction) when you start using more than 4GB of data. And, when you start using >4GB of code, things get yucky (requiring indirect jumps).
But, the point is, x86-64 will run all your 32 bit x86 code at full speed, and if you're able to re-compile your programs for 64 bit mode, you should get a performance boost, if only from getting 9 more registers (8 + no longer need to keep a pointer to the GOT).
Actually, having read the license, I found the following loophole:
. . . if you buy the compiler, you are allowed to distribute code that you compile with icc ;) Find someone who has paid for icc, and ask them nicely if they would compile something for you. No, it's not open-source, but you can distribute source code along with an optimized binary if you're so inclined.
I bought a Lian-Li case because I was building a computer as a gift, and I thought it looked really slick. When it arrived, though I was shocked by how light it was -- just under 6 Kg without mobo/powersupply/etc. I've since bought 3 more for computers that I frequently move, and it really makes a difference. I am not uncomfortable carrying 2 or even all 3 of them at once (comfort including fear of dropping, that is).
Yes, they cost significantly more. They are also significantly more convienient if you have to open them up frequently. Are they better a cooling? I suspect that, for the difference in price between a "standard" case and a Lian-Li AL case, you could buy fans, etc. that would make more of a difference. Even their large server cases are refreshingly light. These cases are definitely not for everyone, but if you need a large, light, accessible, and sturdy case, I don't know of anything better.
(and if you know of anything better, I'd like to hear about it... these are awfully expensiveThis is exactly what AGP was designed for -- high-bandwidth I/O to main memory, without blocking the PCI bus. Plus, the AGP GART can do most of the address translation you would need. All modern PC (and even Apple) chipsets have an AGP interface, which is wasted on a headless server. . . until now. AGP even provdes extra power (even the obscene AGP PRO), so that an onboard battery/HDD could be used to backup.
> To take advantage of RAMdisks, you pretty much need to have your computer on all the time, or in standby mode when you're not using it.
This is true. *or* you could have your computer net-boot from a a server with one of these. Even 100megabit transferring from memory will feel faster than a local hard disk. And gigabit over copper is becoming very affordabl these days.