Your presentation assumes that the solar arrays would be launched from earth on current launch vehicles.
This means that either we need to build better launch vehicles so as to send up more cargo on a single launch or start building them in space.
The second one ought to work out quite well, considering that most metal refinery plants are build in close proximity to power plants for a good reason...
But the API for BeOS is C++, not C. So it doesn't matter that ELF hasn't changed... it matters if the C++ ABI changes. And it has... The C++ ABI changed between GCC 2.x and 3.x in such a way that you could still link C-language APIs OK, but you can't link against C++-language APIs.
So, sometime after BeOS R5, all of the BeOS developers would have needed to rebuild everything again.
Doing a totally binary-incompatable release every few years is not an effective business plan.
Well, the two that stick out the most to me are being unable to change compiler ABIs without forcing the whole world to rebuild and relying on the ability to reserve entries in the vtable as a route to future compatibility. Sure it saved them from having to write their own version of COM/SOM/CORBA/etc. but it also would have put them in a nasty situation down the road.
I love microkernels. I think they are the greatest thing ever. Especially microkernels like L4 that actually have fast IPC and work nicely in ways that Mach never did.
But, we've been "a few years away" from a good F/OSS microkernel ever since the Hurd announcement in *cough* 1990.
The problem is that most of the big advantages of a good microkernel have been hacked, often times in a fairly ugly fashion, into the Linux kernel. So the Linux kernel is multithreaded and has asynchronous interrupts and modules and everything else. And it's not as conceptually simple as a good microkernel OS, but it works well on a wide variety of hardware, is production-grade, etc.
So? When you are running an application that manages to max out your CPU, it doesn't matter that you have 10,000 threads running on your system, it matters how many threads are running in the application that's maxing your CPU at the moment.
I believe that's covered by "There were a few architectural decisions in BeOS that I felt would have resulted in great amounts of pain and suffering 10 years later."
Rewriting things from the ground up, without acceptable justification, has never been an effective strategy.
Sure, but most desktops don't run more than one or two apps at a time. So, 2-4 cores is all that you get "for free" without new apps. Sure, if I'm building a web server application, it'll scale much more gracefully, but it already scales rather gracefully.
The big problem is that most single threaded apps *can* be made multithreaded and *can* be optimized for a more "modern" architecture. In some cases, you can also work around various hidden latencies in modern hardware (like cutting the problem set into smaller chunks that can be split across multiple cores and also can fit better into the cache) at the same time.
The second implication of moving to many cores is that some level of NUMA is inevitable, and there are far fewer NUMA-cognizant coders than SMP-cognizant coders.
Given that most machines are already starting to come default with 2 cores, and you can fit 8 cores (2 CPUs) in a nice desktop package, it's pretty clear that it's going to be a requirement.
It's not entirely the operating system's fault. The biggest advance of BeOS wasn't necessarily just that the kernel was designed to multithread nicely, Be also did their best to force you to write multithreaded code when you wrote a Be application.
I suspect that the first thing that's going to become clearly a performance bottleneck is the applications. And that's not going to be fun, because there's a lot of applications out there and you can't just magically recompile them with threads turned on and see much difference. You need to synchronize the data structures for multiple threads touching them at the same time and split things up so that you can actually keep a decent number of cores busy. This is not trivial when you are talking about an app that somebody wrote single threaded in the mid 90s without any notion that threads might be useful later.
Sadly, the layers of patents, trade secrets, and other such fun bits make it that the only two companies able to make a film of the level of quality of Velvia 50 are Kodak and Fuji. If you want the silver film grains to be the correct shape, you need to accurately control the growth of silver halide crystals and that means custom, proprietary mixing machines.
Also, Fuji does not make every last bit of the film. Many of the chemicals and components involved have many uses besides making film... but they can be discontinued for a variety of reasons.
Finally, film recipes are not an exact science. If you change the mixing kettle, you need to adjust the recipe. They never figured out why, but if you change anything, you need to tweak the formula. It's more like making cheese than an exact product.
You forget that the dyes, gelatin, etc. all contain some percentage of radionucleides. So cosmic ray shielding (assuming that you don't end up with a radioactive cosmic ray shield) will help somewhat, but is only going to forestal the inevitable.
On the bright side, at least you get some number of years before it goes bad.
The part that I'm really pissed off about is that Koadk Ektachrome IR has been discontinued and there's nothing remotely like it... unlike with Velvia where Velvia 100 non-F is actually a quite decent film.
In the early days (Space Station Freedom) they figured that if anything bad happened, they'd just send up another shuttle to rescue them, so the nodes were designed as secure refuges for the several-day wait for the next shuttle to show up.
Eventually NASA realized that wouldn't work, so they went through a series of different designs. Initially, they were going to dust-off the Apollo Capsule design and use that. Then they got creative.
The design, as specced when they started launching, was to put a lifting body capsule specifically designed for the purpose. Until it was ready, they'd just use Soyuz capsules.
Then the special purpose vehicle became a general purpose vehicle, so that they didn't have to worry about the shuttle nearly as much.
Then the Columbia blew up and the general purpose vehicle became our last best hope for a space program, but as a dusted-off Apollo Capsule instead of a fancy lifting body.
Now, they just dock a single Soyuz capsule. Eventually they will have a pair of Soyuz capsules docked. Which is fine, it's just that the Russians have a habit of abusing their position whenever they are the only way up and down from the ISS.
Also, note that if the goal is to get somebody *down* from orbit, it isn't too hard. A heat-shield, a space-suit, a nitrogen-gas thruster, and a parachute. Maybe a cheezy visual alignment aid to get the thruster in the right point and a map to make sure you land on land. A few hundered pounds of hardware, per person. The problem has always been feature-creep more than anything else.
You only think that because BeOS didn't last long enough to get bitten in the ass by their decisions.
I'd love to write a new OS (in the large amounts of free time I have after job, artistic pursiuts, spending time with the wife, and having a living space that isn't disgusting) and I'd love to write it in C++. But writing an object-oriented API without a proper indirection layer to shield you from compiler ABI changes was just dumb. Haiku has to use old versions of gcc for that reason.
Partial pressure of oxygen determines combustability.
Amount of oxygen determines breathability.... which is how you can breathe astonishingly low pressures of pure oxygen in a space capsule.... till it catches on fire and makes a tasty dish of seared astronaut....
Well, that would be funny, given that most flourescent tubes have better color fidelity and, at least for white light, any LED lamps you can buy for a reasonable amount of money are going to be about as efficent as an incandescent.
So? A lot of people have been really excited about natural language interfaces to computers in general... well... starting from Turing..... and has it happened yet?
Passion does not imply breakthroughs. Breakthroughs usually imply passion, tho. Implication is not an associative operation.
Slashdot Mirror
Your presentation assumes that the solar arrays would be launched from earth on current launch vehicles.
This means that either we need to build better launch vehicles so as to send up more cargo on a single launch or start building them in space.
The second one ought to work out quite well, considering that most metal refinery plants are build in close proximity to power plants for a good reason...
But the API for BeOS is C++, not C. So it doesn't matter that ELF hasn't changed... it matters if the C++ ABI changes. And it has... The C++ ABI changed between GCC 2.x and 3.x in such a way that you could still link C-language APIs OK, but you can't link against C++-language APIs.
So, sometime after BeOS R5, all of the BeOS developers would have needed to rebuild everything again.
Doing a totally binary-incompatable release every few years is not an effective business plan.
Well, the two that stick out the most to me are being unable to change compiler ABIs without forcing the whole world to rebuild and relying on the ability to reserve entries in the vtable as a route to future compatibility. Sure it saved them from having to write their own version of COM/SOM/CORBA/etc. but it also would have put them in a nasty situation down the road.
By "acceptable justification" I mean things like "Oh, crap, we wrote our kernel in PL/I" or "This is littered with GOTO statements!"
I mean, look at Copland / Taligent / etc and how it almost did Apple in.
Too little, too late.
I love microkernels. I think they are the greatest thing ever. Especially microkernels like L4 that actually have fast IPC and work nicely in ways that Mach never did.
But, we've been "a few years away" from a good F/OSS microkernel ever since the Hurd announcement in *cough* 1990.
The problem is that most of the big advantages of a good microkernel have been hacked, often times in a fairly ugly fashion, into the Linux kernel. So the Linux kernel is multithreaded and has asynchronous interrupts and modules and everything else. And it's not as conceptually simple as a good microkernel OS, but it works well on a wide variety of hardware, is production-grade, etc.
So? When you are running an application that manages to max out your CPU, it doesn't matter that you have 10,000 threads running on your system, it matters how many threads are running in the application that's maxing your CPU at the moment.
Yes. A very grave mistake on your part. :P
I believe that's covered by "There were a few architectural decisions in BeOS that I felt would have resulted in great amounts of pain and suffering 10 years later."
Rewriting things from the ground up, without acceptable justification, has never been an effective strategy.
Sure, but most desktops don't run more than one or two apps at a time. So, 2-4 cores is all that you get "for free" without new apps. Sure, if I'm building a web server application, it'll scale much more gracefully, but it already scales rather gracefully.
The big problem is that most single threaded apps *can* be made multithreaded and *can* be optimized for a more "modern" architecture. In some cases, you can also work around various hidden latencies in modern hardware (like cutting the problem set into smaller chunks that can be split across multiple cores and also can fit better into the cache) at the same time.
The second implication of moving to many cores is that some level of NUMA is inevitable, and there are far fewer NUMA-cognizant coders than SMP-cognizant coders.
BeOS was like JFK.
The both got gunned down before we could possibly see any downsides to them.
There were a few architectural decisions in BeOS that I felt would have resulted in great amounts of pain and suffering 10 years later.
Given that most machines are already starting to come default with 2 cores, and you can fit 8 cores (2 CPUs) in a nice desktop package, it's pretty clear that it's going to be a requirement.
It's not entirely the operating system's fault. The biggest advance of BeOS wasn't necessarily just that the kernel was designed to multithread nicely, Be also did their best to force you to write multithreaded code when you wrote a Be application.
I suspect that the first thing that's going to become clearly a performance bottleneck is the applications. And that's not going to be fun, because there's a lot of applications out there and you can't just magically recompile them with threads turned on and see much difference. You need to synchronize the data structures for multiple threads touching them at the same time and split things up so that you can actually keep a decent number of cores busy. This is not trivial when you are talking about an app that somebody wrote single threaded in the mid 90s without any notion that threads might be useful later.
You'd like to think that.
Sadly, the layers of patents, trade secrets, and other such fun bits make it that the only two companies able to make a film of the level of quality of Velvia 50 are Kodak and Fuji. If you want the silver film grains to be the correct shape, you need to accurately control the growth of silver halide crystals and that means custom, proprietary mixing machines.
Also, Fuji does not make every last bit of the film. Many of the chemicals and components involved have many uses besides making film... but they can be discontinued for a variety of reasons.
Finally, film recipes are not an exact science. If you change the mixing kettle, you need to adjust the recipe. They never figured out why, but if you change anything, you need to tweak the formula. It's more like making cheese than an exact product.
You forget that the dyes, gelatin, etc. all contain some percentage of radionucleides. So cosmic ray shielding (assuming that you don't end up with a radioactive cosmic ray shield) will help somewhat, but is only going to forestal the inevitable.
On the bright side, at least you get some number of years before it goes bad.
The part that I'm really pissed off about is that Koadk Ektachrome IR has been discontinued and there's nothing remotely like it... unlike with Velvia where Velvia 100 non-F is actually a quite decent film.
In the early days (Space Station Freedom) they figured that if anything bad happened, they'd just send up another shuttle to rescue them, so the nodes were designed as secure refuges for the several-day wait for the next shuttle to show up.
Eventually NASA realized that wouldn't work, so they went through a series of different designs. Initially, they were going to dust-off the Apollo Capsule design and use that. Then they got creative.
The design, as specced when they started launching, was to put a lifting body capsule specifically designed for the purpose. Until it was ready, they'd just use Soyuz capsules.
Then the special purpose vehicle became a general purpose vehicle, so that they didn't have to worry about the shuttle nearly as much.
Then the Columbia blew up and the general purpose vehicle became our last best hope for a space program, but as a dusted-off Apollo Capsule instead of a fancy lifting body.
Now, they just dock a single Soyuz capsule. Eventually they will have a pair of Soyuz capsules docked. Which is fine, it's just that the Russians have a habit of abusing their position whenever they are the only way up and down from the ISS.
Also, note that if the goal is to get somebody *down* from orbit, it isn't too hard. A heat-shield, a space-suit, a nitrogen-gas thruster, and a parachute. Maybe a cheezy visual alignment aid to get the thruster in the right point and a map to make sure you land on land. A few hundered pounds of hardware, per person. The problem has always been feature-creep more than anything else.
You only think that because BeOS didn't last long enough to get bitten in the ass by their decisions.
I'd love to write a new OS (in the large amounts of free time I have after job, artistic pursiuts, spending time with the wife, and having a living space that isn't disgusting) and I'd love to write it in C++. But writing an object-oriented API without a proper indirection layer to shield you from compiler ABI changes was just dumb. Haiku has to use old versions of gcc for that reason.
The idea just occured to me that sending snapshots of your favorite pornographic shocking images would be damn funny.
The problem is that people learn to deal with that kind of stuff. Eventually one learns to block out Bob Goatse if you see it often enough.
If it doesn't blow up, it's two stages to orbit at a mere few million a launch.
Not big enough to launch people or anything, tho.
Oops. I stand corrected.
Well, also if it took you 10 blown up boosters before you got it right, I doubt you'd attract any customers. :P
IIRC, halon works not by displacing air, but by disrupting the combustion process mid-way so as to prevent it from maintaining combustion temperture.
Partial pressure of oxygen determines combustability.
Amount of oxygen determines breathability.... which is how you can breathe astonishingly low pressures of pure oxygen in a space capsule.... till it catches on fire and makes a tasty dish of seared astronaut....
I suspect that, thanks to Star Trek, most geeks are more familiar with naval ranks than ground-pounder ranks. :P
The Wii Zapper is almost enough to make me want to pick it up when it's on sale a few years from now for $69.
Till then, I'll stick with having no consoles whatsoever.
Well, that would be funny, given that most flourescent tubes have better color fidelity and, at least for white light, any LED lamps you can buy for a reasonable amount of money are going to be about as efficent as an incandescent.
So? A lot of people have been really excited about natural language interfaces to computers in general... well... starting from Turing..... and has it happened yet?
Passion does not imply breakthroughs. Breakthroughs usually imply passion, tho. Implication is not an associative operation.