Ruby's syntax is not better than smalltalk - it's more complicated. the only thing "better" about it, is that it sometimes vaguely resembles C syntax. Smalltalk's syntax is not complicated enough. Algol syntax has dominated for 60 years. If you think having a C-like syntax is a flaw then you are not thinking rationally.
"precedence" is not sane - it's a complicated set of exceptions that make a programing language more complicated to implement, but don't really gain anything. So they teach math using hungarian notation in schools... where exactly? Our natural languages contain precedence and all sorts of complicated syntax that we are hardwired to understand. Smalltalk fails because it wants to be 'pure' and 'simple' in places where that is not an advantage.
The news of the conference says they have 36 of 43(?) tests 'running significantly faster'. Ruby 1.9 has 38 tests running 'significantly faster'. So some guys' blog about results he didn't even see is pretty doubtful.
An 8x-60x faster is probably a few numerical benchmarks or possibly something like a regex implementation, and even if true won't have much impact on Ruby overall performance (since you don't use Ruby or Smalltalk for numerical work anyway).
Still, Smalltalk VMs are very advanced and the added competition will be very good for Ruby. My personal bet though is that Ruby completely kills Smalltalk soon, since they are so similar but Ruby has advantages like sane precedence and better syntax.
The MagLev VM, although only partially implemented, so far outperforms MRI 1.8. Being 'faster than 1.8' is a pretty weak claim compared to the competition:
What is cool is how well the Java-based Ruby implementations do: JRuby and XRuby. JRuby was the only Ruby implementation that did not have any tests error. For a VM that is supposedly so hostile to dynamic languages, those implementations were faster and more reliable than the actual Ruby VM and cleaned the floor with the CLR/.NET implementation. And the next version of Java should have stack allocations and invokedynamic bytecode and other optimizations.
What this shows to me is, first do one thing well (Java), then figure out how to grow it. In contrast to.NET/CLR which started out trying to do everything and ended up doing few things well.
They suggested I answer twenty more to remove the penalty. IN 60 SECONDS!!! It's actually an IO test. How fast can you punch the monkey? The test authors were hunting and pecking and found the "Q" first.
A skinny person with a really high metabolism can eat far more in a day than a fat person with a slow one. Plus, you only need to eat a lot to *get* fat - maintaining your weight doesn't require eating extra. SUVs exist because fat people want to feel normal in a car. Airplanes have fewer seats because of fat people. Houses have to be larger because of fat people, so two can pass in a hall without squishing. Public bathrooms need more ventilation because of fat people.
And so on. The extra food a skinny person eats to stay warm is nothing compared to these things. Fat people use a lot more resources, period.
Learn a little erlang, or Haskel to see how easy writing massively parallel programs can be. p.--MarkusQ Massively parallel programs are not very relevant, since the vast majority of programs that people actually use cannot be massively parallel because they generally have a lot of dependencies and sequences.
Erlang and haskel have not caught on precisely because they are not suited well for the kind of programs people generally write or use. So while they may make parallel programming easy for programs that are easy to parallelize, this doesn't really help that much.
Making a program parallel will always be too hard for most programmers. But that's exactly why you don't have normal programmers do it... have the libraries do it automatically. Functions like qsort(2) are already black boxes, so they can be made to always run in parallel when the input is large enough. Other functions like say Ruby's.collect can run in parallel. For things like.each there can be a parallel and a sequential version that the programmer can pick which is appropriate.
But to do this we need operating systems that can efficiently and reliably schedule code across cores. Add an ability to 'bind' threads together, so that they schedule always at the same time but on separate real processors. This gives the program the ability know when running an operation split between these threads will always complete faster than sequentially, without vagaries of scheduling possibly starving one thread and making it run much slower.
Once you have this then you can automatically get some speedups from multiple cores on programs that are designed to only run sequentially, and more speedup on programs with just minor tweaks. You aren't going to get perfect scaling this way, but you will get substantial improvements at virtually no cost to the programmer.
Banning? Get real. That will never work since they've already achieved their goal of getting spam out.
What's needed is revocations. When google determines an account is spamming, they can send messages out to cancel every spam message sent. This gives the user control over how much spam they see... the more often they check their mail the more spam they see, since some of it hasn't been canceled yet.
Fortunately we believe those crazy atom smashing mad scientists don't have the power to do that. Someone hears the term mini-black hole and everyone freaks out since they are quantum entangled with that person. The artificial kind blinks out almost immediately according to our theories. We just can't, as far as we know, generate a sustainable singularity. Fixed.
Yes, Java is pretty fast these days. That's because Sun welded the virtual machine from another 30-year-old language, Smalltalk, onto their Java implementation. But is there any way that Java is better than straight up Smalltalk? Smalltalk is as fast, and simultaneously simpler and more powerful. And not just more powerful than Java today (with the abomination that is Generics), but more powerful than Java with the BGGA Closure proposal [parleys.com], which threatens to make Java even more confusing than C++. A) the hotspot vm was inspired from Sun's work on Self, which has more in common with JavaScript really than Smalltalk. The hotspot-like vm in smalltalk was a one small step between Self and Java.
B) Even the fastest smalltalks like cincom's can't even get method calls as fast as Java's. When I last benchmarked them they were 4 times slower. And math is typically 20 times slower than Java, or more.
C) Assembly is simpler and more powerful and faster than Java. That doesn't mean jack about whether it is a good application programming language. A language where you can change any part of it can't be used in a secure way and isn't forward compatible. ie it's for scripting.
If I sound bitter, it's because I was in college right when the Java Hype Bomb hit, and so I spent about 2 years writing Java code, continuously waiting for Java version N+1 to actually have some features we were begging for. I'm glad I had the sense to get out when I did, because if I was waiting for language features as basic as closures (which are far older than 30 years, gramps), I'd still be waiting, 10 years later. What's funny is that Java's inner classes are almost a direct mapping from the common ancestor of all successful object oriented languages, Simula 67. In another ten years maybe you'll have the context to know that it isn't Java that's making you bitter.
The media was playing it up as Clinton's "last chance", so naturally that will energize people who are emotionally involved with that candidate and get them out to vote... just like in New Hampshire, where women came out strong for their candidate.
Personally, I find the level of racism and sexism involved in propping up Clinton's campaign disgusting. I'd like to think of Democrats as above and beyond that. If you look at the facts, Obama is a better speaker, more motivational, more liked overseas, less divisive. Obama has more experience in public service, he's made better decisions, and he's more likely to win against McCain. He's run a more organized and effective campaign. So given that he pretty much outclasses her in every way as a candidate, you have to ask yourself why people are voting for Clinton, and is it right.
Some people say that Obama is benefiting from being half-black by winning the black vote 10:1. I don't think that's really true, I think he'd be winning the other groups that much if not for the factors working against him. For instance, the Hispanic community has historically been at odds with African Americans. And whites and women, obviously, have a bias for a white woman. It seems to me that by merit he should be winning close to that ratio among most groups.
So many uncreative people here so sure of themselves. A watermark can be anything, and it does not need to change with every copy. For instance, a watermark can change by day or week, allowing the correlation of purchase records over a set of files to uniquely identify the person. They can change in batches, for instance ever 10k sold get a different watermark. They can change by purchase IP or geo-located IP.
Or they can change by all of the above and more, making it pretty much impossible to know if you have removed all the watermarks. Many methods can survive recoding. Thankfully, it should only take a few court cases and a few sacrificial lambs to find out what most of the watermarks are.
That's all true, but hardly severe except for the VERY VERY slow package system. What really kills me is that it's only slow because there are 200k files scattered everywhere. All it really needs is to put these in a.zip (yes, zip) file. An uncompressed zip can still be sent as a delta with rsync, even a compressed one can with a little work on the adding/removing/updating code. But most importantly it can be randomly accessed unlike a.tar.gz file, and it's easy to access in python.
Just making this one change would improve the gentoo experience a LOT and not really make it feel inaccessibly like an actual db would, wouldn't need any 'db update protocol' or loopback filesystems or anything complicated like other suggested fixes.
The operating system does not run finalizers on parts of memory, because it can't, because all it knows about are pages. That's the malloc/free world.
It also differs by the part you cut out with [...]. Imagine that.
Comparing a memory leak with manual memory in C/C++ with a 'leak' in Java/C# is like saying *(char*)0 and ((Object)null)->method are both memory faults. In some sense, technically, the latter is generally the processor hitting page 0 and faulting. But in practice it is so different that it is not helpful to call it or think about it the same way.
As a matter of fact, some people will probably still claim that it's technically not a memory leak, but instead an object life-span issue. That's because it's not a memory leak, it's just memory not being released at the moment. A classical leak is never released and can't be accessed on purpose. In Java or other garbage collected languages your code may hold onto references when it does not need to, but these will eventually be reclaimed... when the function is finished, when the next 'page' is rendered, when the race is completed, or finally when the program is terminated if finalizers are run on exit.
What surprises me is that outspoken proponents of managed languages use the garbage collection so often as a good thing, as if now you can be a sloppier programmer and get away with it. Garbage collection makes a lot of memory management easier, not 'sloppier'. Take for instance in C releasing an object from a callback issued by that object. You can't just 'free' the object since you are in a call stack within the object's own functions... maybe the object can guarantee not accessing itself after your callback completes but this is not always possible and always complicated. Instead, you often have to 'schedule' your object to be actually freed at some later time. With GC you typically just unreference the object.
So in straczinsky's star trek: rebooted, the three main characters all know the 'secret' that there is some mystical race out there in the stars that left clues about what when and how that they will find out more about this over the 5 years story 'arc'. And there are some 'dark evil forces' lurking out there plotting against them.
No!
The ST:TOS was so awesome because each episode was a completely self-contained short story. There was no 'story arc' to follow and no grand design behind it -- that stuff is why voyager, ds9, babylon 5, enterprise, and the bad episodes of st:tng sucked so badly. The old series was so great because it wasn't a soap opera, they were just independent stories set in a future. Sure there were common stuff like klingons and romulans, but only as plot devices to tell that particular story.
So who said geeks didn't buy them out? I almost bought one myself since before this you could even hardly get a C7 motherboard for $200. Average price on newegg is like ~180 now.
and partly because fp seems like a paradigm that is likely to get more and more useful as we get machines with more and more cores. Well a functional language is just a declarative language where you explicitly state what parts can be run in parallel -- these choice points are called functions and the parallel parts are called parameters. An example:
Iterative:
## BEGIN ANY ORDER
tmpA = calculateA();
tmpB = calculateB();
## END
return add(A, B);
What's really needed is an iterative language that can easily express these points where operations can happen in any order. For instance, something like:
where you are saying that the iterative process calculateA and calculateB can be done in parallel, but cannot affect each other (raise an error, or they get a 'lightweight' copy of anything they use, state is only read-only, etc).
The problem with functional language that the majority of code is not functional, but they make you put everything in terms of that with 'exceptions' for sequential code and states. If you have "a*b+c" you cannot do "b+c" before "a*b". And high-level code is not usually functional either... you have to confirm the order before you bill the credit card, and so on.
and it works only against programs that wrap system calls to add additional system protection. So it does not pierce through standard OS security, and you already need to have execution privileges. Or one could look at it as standard OS security not being flexible or modifiable enough for the real world. The reason why these syscall intercepts in-process or in another process are used is because the system security doesn't do what is needed and can't be modified dynamically. The reason these things exist is because it is far easier to do these checks in user-space. I would certainly say it is a technical weakness that one has to be a skilled kernel developer and create a patch for the kernel and recompile the kernel in order to reasonably change the security policy -- because the security policy is defined by the administrator who is as a rule not a kernel developer.
Compare this to for instance Java where if you want to run code with a different policy you define an object with a set of methods that gets called with the parameters anytime a secure operation is attempted. This works and is secure even in a multicore/multithreaded system because the parameters are immutable and Java is a typesafe language. Something like this could be done with an unsafe kernel / unsafe userspace system like linux, for instance by copying all the parameters into a separate memory segment and making that segment read-only to the process until the syscall completes. But it's slow and complicated to do this.
it's a privilege which we the people grant to copyright holders Well no really it's a privilege we grant to authors and inventors:
"the Congress shall have power to promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries"
"the exclusive right": nobody else has a right to your invention. A contract that gives somebody else exclusive rights to it is unconstitutional (you can always resell use of your work to somebody else for more money).
"their respective writings": you can't be secured rights to other people's works. ie you can't buy copyright from an author.
The problem is that companies are illegally "buying" copyright rather than buying non-exclusive licenses for it. Making this small change back to the original intent of copyright would create an actual incentive for individual people to invent, reward them for doing so, and prevent most of the negative aspects such as 'patent trolls' that hoard patents they bought from others or media conglomerates that lock artists into their rackets.
Your faith in the timestamp counter is disturbing. People don't generally program in assembly and they don't measure time using a counter or run programs on very old systems. On every machine I have tried this on, doing millions of sys_getpid calls (non-cached) measuring in real wallclock time on Athlon, Pentium 4, single core, dual core, etc it generally comes out to ~1200 cycles... to read a single int from the kernel.
I suggest that if you retest this system using a much larger number of calls and measuring in real time you'll see a dramatically different result.
Linux should absolutely never become a microkernel. Message-passing as a methodology is barely adequate for networks - RPC and CORBA are hardly famed for their elegance or performance, and when was the last time you saw Globus or MPI being used to link machines in a LAN gaming session? Uh you realize that anything object oriented is basically equivalent to microkernel? Each object is a separate 'memory space' that only it can affect, and all interaction is through 'messages' aka method invoke + wait.
An operating system would be so much better running a safe language. I program in C every day because of some requirements, and it is so much not a good language for operating systems. Most of what an OS does is manage lots of information and access to it. C is really, really bad at both of those... what it is is fast, but so much time in a system like Linux is wasted doing context switches and from overhead of using really really simplistic interfaces.
Just look at all the contortions libc does to make bare system calls more usable to applications -- and what the OS does to make information available as simple system calls. sys_getpid takes maybe 5 instructions in a 'message passing' safe os, but takes 1500 cycles in linux. Try to find the parent folders given just a file's fd or inode for instance... it's really annoying for no reason other than the system is designed in C and had to be made ridiculously simple because of that.
I mean here we're talking about people writing user-space drivers and filesystems and such for a systems with really really slow context switches -- compared to a kernel running typesafe code. People are doing this thing which is hundreds of times slower than a microkernel that runs a safe os, but speed is so important eigh? Come on.
Yeah that might be true, but it sure seems convenient to me that there's this SDI to blame the fall of the soviet union on and make Reagan a hero. I mean come on, the Soviets were failing to keep up for a long time and if it was so obvious that it was bogus then they could have done a bogus copy that didn't work. So how would it bankrupt them again? Because they were too stupid to put on a dog and pony show instead of actually trying to build it? I mean do you really think the Soviets are so stupid.
Maybe if somebody could post some actual evidence that this was the goal of it and that it was actually the reason the ussr fell, say quotes from the national archives and some reports with numbers.
Time and isolation caught up with them. Reagan killing communism is just a wet dream some people have.
Slashdot Mirror
The news of the conference says they have 36 of 43(?) tests 'running significantly faster'. Ruby 1.9 has 38 tests running 'significantly faster'. So some guys' blog about results he didn't even see is pretty doubtful.
An 8x-60x faster is probably a few numerical benchmarks or possibly something like a regex implementation, and even if true won't have much impact on Ruby overall performance (since you don't use Ruby or Smalltalk for numerical work anyway).
Still, Smalltalk VMs are very advanced and the added competition will be very good for Ruby. My personal bet though is that Ruby completely kills Smalltalk soon, since they are so similar but Ruby has advantages like sane precedence and better syntax.
Ruby 1.9: 3.32x
XRuby: 1.43x
JRuby: 1.32x
Ruby 1.8: 1.0x
Rubinius: 0.73x
Ruby.NET: 0.56x
What is cool is how well the Java-based Ruby implementations do: JRuby and XRuby. JRuby was the only Ruby implementation that did not have any tests error. For a VM that is supposedly so hostile to dynamic languages, those implementations were faster and more reliable than the actual Ruby VM and cleaned the floor with the CLR/.NET implementation. And the next version of Java should have stack allocations and invokedynamic bytecode and other optimizations.
What this shows to me is, first do one thing well (Java), then figure out how to grow it. In contrast to
And so on. The extra food a skinny person eats to stay warm is nothing compared to these things. Fat people use a lot more resources, period.
Erlang and haskel have not caught on precisely because they are not suited well for the kind of programs people generally write or use. So while they may make parallel programming easy for programs that are easy to parallelize, this doesn't really help that much.
Making a program parallel will always be too hard for most programmers. But that's exactly why you don't have normal programmers do it... have the libraries do it automatically. Functions like qsort(2) are already black boxes, so they can be made to always run in parallel when the input is large enough. Other functions like say Ruby's .collect can run in parallel. For things like .each there can be a parallel and a sequential version that the programmer can pick which is appropriate.
But to do this we need operating systems that can efficiently and reliably schedule code across cores. Add an ability to 'bind' threads together, so that they schedule always at the same time but on separate real processors. This gives the program the ability know when running an operation split between these threads will always complete faster than sequentially, without vagaries of scheduling possibly starving one thread and making it run much slower.
Once you have this then you can automatically get some speedups from multiple cores on programs that are designed to only run sequentially, and more speedup on programs with just minor tweaks. You aren't going to get perfect scaling this way, but you will get substantial improvements at virtually no cost to the programmer.
Banning? Get real. That will never work since they've already achieved their goal of getting spam out.
... the more often they check their mail the more spam they see, since some of it hasn't been canceled yet.
What's needed is revocations. When google determines an account is spamming, they can send messages out to cancel every spam message sent. This gives the user control over how much spam they see
I see we weren't the first to build a large hadron collider.
B) Even the fastest smalltalks like cincom's can't even get method calls as fast as Java's. When I last benchmarked them they were 4 times slower. And math is typically 20 times slower than Java, or more.
C) Assembly is simpler and more powerful and faster than Java. That doesn't mean jack about whether it is a good application programming language. A language where you can change any part of it can't be used in a secure way and isn't forward compatible. ie it's for scripting. If I sound bitter, it's because I was in college right when the Java Hype Bomb hit, and so I spent about 2 years writing Java code, continuously waiting for Java version N+1 to actually have some features we were begging for. I'm glad I had the sense to get out when I did, because if I was waiting for language features as basic as closures (which are far older than 30 years, gramps), I'd still be waiting, 10 years later. What's funny is that Java's inner classes are almost a direct mapping from the common ancestor of all successful object oriented languages, Simula 67. In another ten years maybe you'll have the context to know that it isn't Java that's making you bitter.
The media was playing it up as Clinton's "last chance", so naturally that will energize people who are emotionally involved with that candidate and get them out to vote... just like in New Hampshire, where women came out strong for their candidate.
Personally, I find the level of racism and sexism involved in propping up Clinton's campaign disgusting. I'd like to think of Democrats as above and beyond that. If you look at the facts, Obama is a better speaker, more motivational, more liked overseas, less divisive. Obama has more experience in public service, he's made better decisions, and he's more likely to win against McCain. He's run a more organized and effective campaign. So given that he pretty much outclasses her in every way as a candidate, you have to ask yourself why people are voting for Clinton, and is it right.
Some people say that Obama is benefiting from being half-black by winning the black vote 10:1. I don't think that's really true, I think he'd be winning the other groups that much if not for the factors working against him. For instance, the Hispanic community has historically been at odds with African Americans. And whites and women, obviously, have a bias for a white woman. It seems to me that by merit he should be winning close to that ratio among most groups.
So many uncreative people here so sure of themselves. A watermark can be anything, and it does not need to change with every copy. For instance, a watermark can change by day or week, allowing the correlation of purchase records over a set of files to uniquely identify the person. They can change in batches, for instance ever 10k sold get a different watermark. They can change by purchase IP or geo-located IP.
Or they can change by all of the above and more, making it pretty much impossible to know if you have removed all the watermarks. Many methods can survive recoding. Thankfully, it should only take a few court cases and a few sacrificial lambs to find out what most of the watermarks are.
That's all true, but hardly severe except for the VERY VERY slow package system. What really kills me is that it's only slow because there are 200k files scattered everywhere. All it really needs is to put these in a .zip (yes, zip) file. An uncompressed zip can still be sent as a delta with rsync, even a compressed one can with a little work on the adding/removing/updating code. But most importantly it can be randomly accessed unlike a .tar.gz file, and it's easy to access in python.
Just making this one change would improve the gentoo experience a LOT and not really make it feel inaccessibly like an actual db would, wouldn't need any 'db update protocol' or loopback filesystems or anything complicated like other suggested fixes.
Waveform collapse is also called lazy evaluation. We're running in a simulation, get over it.
The operating system does not run finalizers on parts of memory, because it can't, because all it knows about are pages. That's the malloc/free world.
It also differs by the part you cut out with [...]. Imagine that.
Comparing a memory leak with manual memory in C/C++ with a 'leak' in Java/C# is like saying *(char*)0 and ((Object)null)->method are both memory faults. In some sense, technically, the latter is generally the processor hitting page 0 and faulting. But in practice it is so different that it is not helpful to call it or think about it the same way.
So in straczinsky's star trek: rebooted, the three main characters all know the 'secret' that there is some mystical race out there in the stars that left clues about what when and how that they will find out more about this over the 5 years story 'arc'. And there are some 'dark evil forces' lurking out there plotting against them.
No!
The ST:TOS was so awesome because each episode was a completely self-contained short story. There was no 'story arc' to follow and no grand design behind it -- that stuff is why voyager, ds9, babylon 5, enterprise, and the bad episodes of st:tng sucked so badly. The old series was so great because it wasn't a soap opera, they were just independent stories set in a future. Sure there were common stuff like klingons and romulans, but only as plot devices to tell that particular story.
So who said geeks didn't buy them out? I almost bought one myself since before this you could even hardly get a C7 motherboard for $200. Average price on newegg is like ~180 now.
Functional:
return add(calculateA(), calculateB());
Iterative:
## BEGIN ANY ORDER
tmpA = calculateA();
tmpB = calculateB();
## END
return add(A, B);
What's really needed is an iterative language that can easily express these points where operations can happen in any order. For instance, something like:
return add(fork(calculateA()), fork(calculateB()))
where you are saying that the iterative process calculateA and calculateB can be done in parallel, but cannot affect each other (raise an error, or they get a 'lightweight' copy of anything they use, state is only read-only, etc).
The problem with functional language that the majority of code is not functional, but they make you put everything in terms of that with 'exceptions' for sequential code and states. If you have "a*b+c" you cannot do "b+c" before "a*b". And high-level code is not usually functional either... you have to confirm the order before you bill the credit card, and so on.
Compare this to for instance Java where if you want to run code with a different policy you define an object with a set of methods that gets called with the parameters anytime a secure operation is attempted. This works and is secure even in a multicore/multithreaded system because the parameters are immutable and Java is a typesafe language. Something like this could be done with an unsafe kernel / unsafe userspace system like linux, for instance by copying all the parameters into a separate memory segment and making that segment read-only to the process until the syscall completes. But it's slow and complicated to do this.
"the Congress shall have power to promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries"
"the exclusive right": nobody else has a right to your invention. A contract that gives somebody else exclusive rights to it is unconstitutional (you can always resell use of your work to somebody else for more money).
"their respective writings": you can't be secured rights to other people's works. ie you can't buy copyright from an author.
The problem is that companies are illegally "buying" copyright rather than buying non-exclusive licenses for it. Making this small change back to the original intent of copyright would create an actual incentive for individual people to invent, reward them for doing so, and prevent most of the negative aspects such as 'patent trolls' that hoard patents they bought from others or media conglomerates that lock artists into their rackets.
Your faith in the timestamp counter is disturbing. People don't generally program in assembly and they don't measure time using a counter or run programs on very old systems. On every machine I have tried this on, doing millions of sys_getpid calls (non-cached) measuring in real wallclock time on Athlon, Pentium 4, single core, dual core, etc it generally comes out to ~1200 cycles ... to read a single int from the kernel.
I suggest that if you retest this system using a much larger number of calls and measuring in real time you'll see a dramatically different result.
An operating system would be so much better running a safe language. I program in C every day because of some requirements, and it is so much not a good language for operating systems. Most of what an OS does is manage lots of information and access to it. C is really, really bad at both of those... what it is is fast, but so much time in a system like Linux is wasted doing context switches and from overhead of using really really simplistic interfaces.
Just look at all the contortions libc does to make bare system calls more usable to applications -- and what the OS does to make information available as simple system calls. sys_getpid takes maybe 5 instructions in a 'message passing' safe os, but takes 1500 cycles in linux. Try to find the parent folders given just a file's fd or inode for instance... it's really annoying for no reason other than the system is designed in C and had to be made ridiculously simple because of that.
I mean here we're talking about people writing user-space drivers and filesystems and such for a systems with really really slow context switches -- compared to a kernel running typesafe code. People are doing this thing which is hundreds of times slower than a microkernel that runs a safe os, but speed is so important eigh? Come on.
Yeah that might be true, but it sure seems convenient to me that there's this SDI to blame the fall of the soviet union on and make Reagan a hero. I mean come on, the Soviets were failing to keep up for a long time and if it was so obvious that it was bogus then they could have done a bogus copy that didn't work. So how would it bankrupt them again? Because they were too stupid to put on a dog and pony show instead of actually trying to build it? I mean do you really think the Soviets are so stupid.
Maybe if somebody could post some actual evidence that this was the goal of it and that it was actually the reason the ussr fell, say quotes from the national archives and some reports with numbers.
Time and isolation caught up with them. Reagan killing communism is just a wet dream some people have.