Just look at the efforts the RedHat devs had to put into making OO2 run with a free java and you will know what I'm talking about.
Well, Mr. AC, there's concrete proof. Since you're so adept at this, would you please provide information on what troubles they had and how those troubles are Sun's fault. Last I heard, RedHat's version was working fine.
You present a false dichotomy, as if the only option is to either use Java, or not keep up with technological progress. That's of course simply bs.
Okay, show me a platform with as many high quality, cross platform database drivers as Java and I'll believe you. Hard evidence, son. That's what we need. In OOo's defense, I can find plenty:
1. Nearly every DB Engine has a Type IV JDBC driver. That includes Oracle, SQL Server, DB2, Sybase, Informix, Cloudscape, MySQL, PostgreSQL, HSQL, McKoi, Daffodil, etc.
2. Java has a wide variety of high quality, open source database engines. The choice to use HSQL was a no brainer based on the ease with which one can integrate it into a desktop product. MySQL and PostgreSQL don't compete in this area.
In short, Java was used because it's the only system that has the necessary technology to compete.
1. GNU's failure to deliver on hurd has nothing to do with the validity of Stallmans critic, nothing at all.
It does have something to do with it. It demonstrates that the GNU foundation does not currently have the resources to maintain something as complex as Java. Now if they were to hire high-quality, professional developers to do the work AS A JOB instead of in their free time, the GNU foundation probably *could* handle such a product. (And get HURD out the door while they're at it.)
Believe it or not, I'd happily donate to the GNU if this was their goal. I take no issue with the idea of having a GPLed JVM. I'd love the idea, actually, but someone has got to foot the bill for it to happen.
He didn't even start this discussion.
He didn't keep things civil either. "The Java Trap?" How nice of him to insult developers who have given him all the tools he needs to create his own Java.
b) As already stated, using a technology that will inevitably pose a problem for the FOSS community is a problem, no matter how often you deny it.
Why? Why does it pose a problem? Because the OSS community has failed to produce a GPLed JVM? How is that the problem of Sun or the OOo project?
They may be now, after people like the GNU volunteers (ever thought about how useful a Linux system would be without the GNU tools?) made Linux a viable option.
Umm, no. Linux was a non-comptitor in the industry. It was a cool hobby OS, but a non-competitor. Customers wanted Linux, though, so companies with deep pockets made it happen. That's not a bad thing, but it shows that the GNU is incapable of producing complex software on their own. They should NEVER be given Java until they can prove the opposite.
He's not allowed to complain about something he doesn't like, but you are?
What am I complaining about? Oh yes, that Stallman is being a hypocrit. How is that hypocritical?
Funny, but you said, "while simultanously showing that his foundation is incapable of managing anything as complex as Java". The FSF manages emacs, gcc and GNU (GNU is not a program, it's an OS).
Actually, I was pointing out how you were making my point. GCC gets massive amounts of help from corporations just like Linux and OOo do. Emacs got the same treatment in the past. Your use of the "GNU subsystem" (the proper name for the bundle) is nonsense. You're talking about a bundle of disparate products, none of which even comes close to the complexity of the Java platform.
Stop throwing up strawmen as a distraction. Stallman is upset because Java is cool and he doesn't have it. Microsoft tried to take it over in their own way, and now Stallman trying to take it over in his own way. The only difference is that Microsoft actually produced a reasonable and fully functional alternative.
Would you like to explain to me WHY THIS IS SUN'S PROBLEM? They have given everything away except for the actual rights to Java itself. If the GNU Foundation can't produce an Open JVM based on open specs and fully available source code, THAT IS THEIR PROBLEM.
If a malevolent entity bought Sun - with a depressed Sun stock, it's a real possibility - could that entity do damage? Oh boy, you bet.
If a malevolent entity hit Linus with a bus and acquired his Linux trademarks, and with the number of evil people out there it's a real possibility, could that entity do damange? Oh boy, you bet!
Come off this nonsense people. Sun is not losing money hand over fist (they're more or less breaking even right now), and they've made it perfectly possible for others to replicate their technology. Why is the OSS community blaming their failure to do so on Sun?
It's the reliance on problematic (to the FSF) technology that this issue (flamewar? WTF?) is about.
The FSF's failure to produce a JVM based on open specs is NOT everyone else's problem. If Mr. Stallman wants to fix the situation, he should be inciting his troops to fix their Open JVMs. Otherwise he can keep his trap shut, because he has no right to complain.
emacs, gcc, gnu...
Funny, it seems that EMacs and GCC have a lot of help from corporate entities. And what is "gnu"? I'm not familiar with that program.
The concern Stallman had was that OOo wouldn't be compatable with (real and hypothetical) Free Java implementations, a legitimate concern given the difficulty of restricting one's self to an "official" API.
Go program Java for a little while. The "hidden" APIs are not a necessary evil, or in any way desirable to use. The very design of the Java platform is so open that those APIs are almost impossible and completely unncessary to use. Pretty much all examples of this usage comes from the 1.1 days when a few APIs had yet to mature. Foolish developers went off and decompiled Java code to find "extra" features like they could in Microsoft software. Thus any occurances in OOo probably stem from StarDivision's work way back when.
What's frightening is how little people like you understand trust. No one can do anything without some degree of trust. Part of building a strong business is to get your customers to trust you. I generally trust Sun, because they've worked hard to earn that trust. You trust Stallman not to screw you because you feel that he holds to principles you agree with.
However, I don't trust him as far as I can kick him. He had proved to me that he will always overreact to every situation, and suggest solutions that he is incapable of executing himself. It's perfectly within his right to attempt to get companies to pick up the tab for his ideals, but it's not alright to then stick a knife between their shoulders at every opportunity. Ask the KDE project how much they appreciate his ideals. Also notice how far along the QT replacement project has gotten. Interesting, isn't it?
Oh, so this must be the reason why building OO2 with a free java has been such a pita and required so much work...
Such as? No one has come forward with any solid complaints against the 2.0 release. Almost all complaints (e.g. hidden APIs) are against the OLD version of OOo. If you have a solid argument then by all means, make it.
however that really doesn't mean that one shouldn't be able to critizise SUN when they do something bad and stupid
Except that they haven't managed to do anything stupid. They leveraged the Java platform with the full blessing of the OOo community to produce a quality product. That's smart. Rebuilding everything from scratch because you don't want to keep up with technological progress is stupid.
"BTW, Mr. Stallman. How's Hurd coming along?" And has got exactly what to do with the story? Oh nothing, you simply thought you could score a cheap shot and start a flamewar.
No, I couldn't resist that shot. Because Mr. Stallman has incited his own flamewar over absolutely nothing, while simultanously showing that his foundation is incapable of managing anything as complex as Java. Look at the Linux success and trace out which programmers are doing the most powerful work. You'll find that $$$ and hours are coming from IBM, Oracle, Sun, and other big names to make Linux useful. Same with OOo. It's not the GNU volunteers who are doing the bulk of the work.
Too bad they dont use something like TCL-TK or Ruby... but I kow why that is. There's a hell-uva lot of programs and libraries to use for free(as in gpl'ed).
There's a hell of a lot more for Java. For example, there's no other platform that has as many high quality, cross platform database drivers. And for that matter, Java has quite a few free database engines (HSQL, McKoi, Derby (Cloudscape, etc.) At the end of the day, there simply isn't any other solution that's as well supported and ubiquitous as Java.
At the risk of starting a flamewar, I have to say that I'm proud to have been a vocal early adopter that helped Java reach the status it has today. It's a good language, a good platform, hosted by a good company, and supported by many. Only the original Unix platform had such a profound effect on the industry.
This was already being done. There was a plugin interface that hooked into the AWT layer of the JVM, but that was something that was easily replacable by other VMs. Previous versions of OOo (probably from back when it was StarDivision property) used hidden APIs, but this was cleaned up in the 2.0 edition.
Java JRE interested parties provide the support code and take care of QA, bugs etc.
This sounds like they're moving the plugin code out of OpenOffice and into the JVM. Technically, this is where it belongs, but it's always nice to be able to support the largest number of VMs possible.
OOo Java implementations must be encapsulated with well specified APIs
This is just good engineering design. If you can't produce readable JavaDocs from it, it isn't a good API.
OOo Java implementations must not check against Java versions or vendors, with the only exception of workarounding bugs
Again, this is just common sense. Checking version numbers is a good way to nail yourself in the foot on future releases.
OOo Java implementations must not use swing, either because no free swing implemetation is available or because it makes the user interface inconsistent, this rule might be relativated in respect to 4
This is just common sense anyway. Using Swing would be detrimental to the GUI unless it was decided that the entire GUI framework would move at once. Such a decision would involve the entire OOo community.
the Java baseline is 1.3.1
This is the only concession I see being made. (1.4 & 1.5 have some *really* nice features.)
The amusing part about this is that the whole tirade against Java in OOo is nothing but a farce. A quick check of the 2.0 code finds almost nothing that violates these "concessions", and they amount to nothing more than diplomacy anyway. (i.e. The art of saying "nice doggy" until you can find a big stick.)
The truth is that Sun has bent over backwards for the OSS community, and all they get for their troubles are painful stabs in the back. Yeah, Sun's got some loud mouths working for them. But their actions have ALWAYS been honorable. Despite all the nonsense about "contamination", has anyone EVER had Sun sue them? I've certainly never heard of a case! And when Sun realized that the language was confusing, they updated future source releases with new language that EXPLICITY gives developers rights to whatever they remember. So no more excuses! If you want an OS Java platform, code it. Sun sure as hell isn't standing in your way.
As someone else pointed out, you really need to investigate On Demand solutions. Sun Microsystems will sell you a system with way more processors and memory than you need for a VERY low cost, but most of the extra hardware will be disabled. When you're expecting high volume (or even if it should suddenly happen upon you) you can call Sun and rent the extra hardware in a pinch.
This provides you with massive scalability, but without the nasty upfront cost. And if you outstrip the hardware you've been given, Sun can send a guy out to plug in another motherboard (4 processors + memory) while your server is still running!
GNU/Hurd has got to be the only non-released project that has taken longer than Duke Nukem Forever. They've been at that thing for well over a decade now, and recently switched microkernels (i.e. the L4 point you were making). I'm all for waiting until something is done, but can anyone give some visibility into what they've been actually DOING all this time?
Ever see how horribly Linux handles running out of memory?
A long time ago, yes. That's why I only trust Sun Machines for mission critical work.:-)
But if your primary reasoning for needing virtualization is to protect against OS failures, doesn't that suggest that you need a better OS instead? (Or wait until someone fixes the OS you're using?)
I still have to wonder what the real point of virtualizing is. Yes, Microsoft pulled an amazing coup by convincing sysadmins that they should have a separate box for every tiny little service they wanted to run. But Microsoft got away with it because of the crappy design of Windows as a server OS. (i.e. You have to plan for complete system wipes and upgrades, security is such that one service could compromise another, and system software components are such that they happily interfere with each other.)
Back in the land of all things sane (i.e. Unix style OSes), I see no reason why NOT to run a billion services on one machine. As long as you've got spare system resources, why shouldn't you make use of them? Why do I NEED the domain controller, file server, mail server, and ftp server to all be different machines? One big Unix box does the job better, and for a lower up front (and longterm!) cost than lots of tiny Windows boxes!
Granted, there are still some issues that can't be overcome. But which really makes more sense, spending millions of dollars on tons of machines and an army of support staff, or spending a few hundred thousand on a couple of redundant machines and an admin or two to maintain them?
Actually, the grandparent IS correct. I spent the last week studying the Mach and OS X designs, and I found the following things:
1. Mach is not a complete kernel. It requires someone to implement the areas which the Mach group were not researching. This has traditionally been done by compiling against BSD 4.3.
2. Mac OS X updated to the FreeBSD kernel instead of BSD 4.3 to gain a more modern kernel design with better hardware support.
3. OS 9 "Classic" is not a microkernel server, but rather a technology that Apple calls "Blue Box". Blue Box is a hardware virtualizer like VMWare that is capable of communicating directly with the OS X desktop. Using this communication, the OS 9 desktop is made to disappear, making the application appear to run on the OS X desktop.
4. The combination of Mach and FreeBSD is called "XNU" by Apple. The complete os is called Darwin, and the commercial variety with the Next and Mac APIs is called "Mac OS X".
I didn't see anywhere in that article linked where it said that the oxygen would be pulled from the atmosphere.
It's an engine, not a complete vessel. You'd need to add additional intakes to obtain the oxygen from the air, and then feed it to the afterburner.
Once you send air through a reactor the radiation released from the rocket will go up by orders of magnitude due to neutron activation of Ar-40 to Ar-41.
That's why I suggested that they could be switched around. Not only will fewer engine changes be required, but you avoid irradiating any materials contained within regular air.;)
This will not allow a significant amount of radiation released (nowhere near what a air cooled reactor would generate--around 2000 rem/hr on contact at full power not including radiation from the reactor), but it will be detectable.
The question is, is this sufficient to be concerned about? As long as we're not posing a threat to humans on the ground (or water more likely), I'm not concerned. If your only concern is that the craft can be detected, then I'm not all that worried. Although I wouldn't want to be standing directly behind a 33 REM/Minute engine, I assume that proper precautions would be taken to make sure that people are *not* standing directly behind the engines. (That would be bad for more reasons than just radiation.:)) A cement breakwall or a water filled tank might be a good way of shielding things beyond the runway from excessive exposure to the temporary radiation. On the ground, then engines could be capped.
His point is that more powerful engines built and launched in space would drive the price down while simultaneously decreasing travel time. And he's right. If we had probes coming off of a moon or asteroid-based assembly line with standard science packages and engines, they would be WAY cheaper to launch. Right now we're wasting some ungodly amount of money on fragile little devices that could be whipped together by any half-competent engineer for a few thousand bucks. But the fact that the probe *must* absolutely work right the first time and *must* meet very light weight specifications and *must* be designed by scientists (not engineers) drives the price astronomically high.
As someone pointed out, the primary issue to deal with on assembly line craft is the tremendous amount of customization done by scientists. What we need is a few crack engineers to talk with scientists and figure out a few expandable designs that can have all the necessary sensors mounted onto the post-assembly line vehicle. The only trick is that you MUST have powerful enough engines to accomidate the extra mass of the generic design. (A bit like how software had to be very streamlined back in the DOS days, but can be very generic and reusable on today's modern hardware.) The way I figure it, a 900+ Isp engine with a 1 G or greater thrust ability should do the job nicely.:)
We must proceed with caution by ceasing these speed-of-light simulations. The Chinese would surely use them to advance their space-weaponization program.
Why does this troll keep showing up? The Chinese don't have the resources to compete with the US. They've attempted manned space travel several times (even outright copying the Dynasoar design) and every time have had to cut it because of the cost. For now, I wouldn't worry too much about the Chinese one-upping the US on their own technology. Start worrying when they launch an Orion (not bloody likely).
Note that the Chinese space program is completely under the auspices of the Chinese department of war. By contrast, in the USA, NASA is an entirely civilian effort.
This is a GOOD thing. Remember what happened when the space program was under the United States department of war? (Specifically the Air Force?) That's right, some good engineering was done, but we didn't GET anywhere. It wasn't until NASA was formed that the US actually got into the race.
Forget the Ramjet, I think you meant Scramjet ala the X-43.
I'm still not so sure about the Scramjet. The engine itself is a great idea, but the structural requirements are terrible. Even a minor flaw in the surface of the vessel would lead to catastrophe.
The grandparent probably has it right. If you use Jet engines to get to a higher altitude, the efficiency of nuclear thermal engines can take you the rest of the distance without having to go hypersonic in thick atmosphere.
Interestingly, the "best" solution may even be a ramjet engine. Since a nuclear engine can run on any fluid, what more efficient method exists than pulling oxygen from the atomosphere? And if you afterburn with hydrogen, you're going to get one hellva kick in the pants. (Alternatively, you can turn it around and heat the hydrogen while "burning" the oxygen")
Amazingly, we already have the engine to do this. Pratt & Whitney's TRITON engine is the perfect solution. As a "tri-modal" engine, it's capable of three modes of operation:
1. Low atmosphere afterburning for high powered launches. 2. Upper atmosphere and orbital transfer propulsion using pure hydrogen fuel. 3. Low fission rate "idle" mode which produces ~200 kW of power. (More than enough for onboard systems.)
The implications of this engine are staggering. Thanks to the tungsten clad design, it can be used anywhere without polution. Which means that we can have a single engine type that can not only produce massive thrust on takeoff, perhaps even produce the much covettd and highly efficient ramjet. (Rocket scientists love the idea of taking oxygen from the atmosphere, but don't normally want their rockets spending enough time in the lower atmosphere to make it worthwhile). But also an engine type that is highly efficient in upper-atmosphere and "space" areas. Plus, the craft can ditch heavy batteries and fuel cells in favor of drawing all its power from the engines. That power would even be available for electrical manuvering thrusters so that the amount of propellant carried can be reduced. Thus some of the weight you pay for in heavier engines can be regained in reducing redudant systems.
If we're going to get a bird in the air in the near future that can get people to orbit cheaply and safely, nuclear is where my money is.
eh? How about just putting a cover over the radiation source?
A nuclear battery is always on. There's no way of stopping it from generating power, since the power is derived from the radiation itself. Even if you weren't generating electricity, the heat would build up quickly. (A 20W heating element could easily melt itself if the excess heat doesn't get vented. Not to mention how uncomfortable it would get on your lap.) Did you know that a small chunk of Pu-238 can easily boil a pot of water within a minute?
Correct. Sorry, I'm getting tired and called the control rods a moderator by accident. However, you'll note that the rest of my post jives with what you just said. (Other than the "control tods" that is. Whatever those are.;-))
AFAIK, the problem here is the heat from the decay of the short-lifetime isotopes left from the fission.
It's always possible that you're correct, but that doesn't sound right to me. Other than spontaneous fission, fission only occurs when slow moving neutrons are captured by heavy atoms. Those atoms become unstable and collapse, thus producing energy and more neutrons. Water or heavy water is often used to slow some of the fast neutrons produced in these reactions.
Reactors are usually controlled via two methods. The first method is the use of a moderator such as control rods. These rods can be inserted so that they block a given amount of neutron radiation, thus ensuring that the reaction doesn't run away. However, control tods can only react so fast, and would not have time if the reactor went supercritical (unlikely, but possible). To mitigate these effects, reactors further rely on delayed neutrons from previously fissiled material. These neutrons show up anywhere from a few seconds to a few minutes after the initial reaction, thus providing time for reactor controls to respond to any signs that the reactor is going to reach a supercritical state.
If things go really wrong, a reactor may end up in a prompt-critical state where prompt neutrons are feeding the reaction. At this point, reactor control may have been lost. The standard procedure is to attempt to scram the reactor before the reaction becomes supercritical.
No, the RTG applications on Voyager, Galileo, Cassini, Viking... are superb acheivements of engineering and perfect applications of nuclear fission.
They are? Wow, that's amazing. Here I thought they were Radioisotope Thermal Generators, not micro-fission reactors. You sound like an idiot. (Hint: You would have known better if you had actually *read* the Wikipedia article instead of insulting it. Or do you have an allergy to factually correct information?)
But sharing space with millions of Tritium batteries on Earth is another matter.
As opposed to sharing the space with all of those Tritum watches, gun scopes, and keychains? Lord Almighty, you are an idiot.
It can't work with plutonium for exactly the reason we're talking about: plutonium would fizzle before the assembly is complete.
You said Uranium; I quoted you on it. So speaking of plutonium is a disingenuous argument.
That's why most bombs use the much more complex implosion technique.
Most bombs use the implosion technique because it's safer and more economical. Gun devices are far too easy to set off accidentally, and require a LOT of nuclear material in comparison to an implosion device.
The argument "somebody could build a crappy bomb, therefore it's OK go spread around materials that can be used to make a good bomb" doesn't make sense.
I believe the point was that Tritium makes no difference to crappy bomb. If they have enough uranium, they have enough uranium. Plutonium does not occur naturally, so it's far less likely the "bad guys" would have any on hand. They'd have a far easier time first purifying the U235 sitting all around them.
If you're using uranium for the bomb, it's very difficult to assemble the core into a critical state without a premature chain reaction setting off a fizzle.
Rubish. A gun device detonator is so stupidly simple that just about anyone could make it with enough material. All you need is to take the critical amount and split it into two subcritical halves. Load one half into a stationary holder (this is the target), and the other into a powerful gun aimed at the target. When the gun is fired, the force of the impact will compress the materials into a super-critical mass that should produce a reasonably nice "BOOM". No booster required.
Thankfully, the "bad guys" haven't been able to get their hands on sufficient uranium.
Slashdot Mirror
Just look at the efforts the RedHat devs had to put into making OO2 run with a free java and you will know what I'm talking about.
Well, Mr. AC, there's concrete proof. Since you're so adept at this, would you please provide information on what troubles they had and how those troubles are Sun's fault. Last I heard, RedHat's version was working fine.
You present a false dichotomy, as if the only option is to either use Java, or not keep up with technological progress. That's of course simply bs.
Okay, show me a platform with as many high quality, cross platform database drivers as Java and I'll believe you. Hard evidence, son. That's what we need. In OOo's defense, I can find plenty:
1. Nearly every DB Engine has a Type IV JDBC driver. That includes Oracle, SQL Server, DB2, Sybase, Informix, Cloudscape, MySQL, PostgreSQL, HSQL, McKoi, Daffodil, etc.
2. Java has a wide variety of high quality, open source database engines. The choice to use HSQL was a no brainer based on the ease with which one can integrate it into a desktop product. MySQL and PostgreSQL don't compete in this area.
In short, Java was used because it's the only system that has the necessary technology to compete.
1. GNU's failure to deliver on hurd has nothing to do with the validity of Stallmans critic, nothing at all.
It does have something to do with it. It demonstrates that the GNU foundation does not currently have the resources to maintain something as complex as Java. Now if they were to hire high-quality, professional developers to do the work AS A JOB instead of in their free time, the GNU foundation probably *could* handle such a product. (And get HURD out the door while they're at it.)
Believe it or not, I'd happily donate to the GNU if this was their goal. I take no issue with the idea of having a GPLed JVM. I'd love the idea, actually, but someone has got to foot the bill for it to happen.
He didn't even start this discussion.
He didn't keep things civil either. "The Java Trap?" How nice of him to insult developers who have given him all the tools he needs to create his own Java.
b) As already stated, using a technology that will inevitably pose a problem for the FOSS community is a problem, no matter how often you deny it.
Why? Why does it pose a problem? Because the OSS community has failed to produce a GPLed JVM? How is that the problem of Sun or the OOo project?
They may be now, after people like the GNU volunteers (ever thought about how useful a Linux system would be without the GNU tools?) made Linux a viable option.
Umm, no. Linux was a non-comptitor in the industry. It was a cool hobby OS, but a non-competitor. Customers wanted Linux, though, so companies with deep pockets made it happen. That's not a bad thing, but it shows that the GNU is incapable of producing complex software on their own. They should NEVER be given Java until they can prove the opposite.
He's not allowed to complain about something he doesn't like, but you are?
What am I complaining about? Oh yes, that Stallman is being a hypocrit. How is that hypocritical?
Funny, but you said, "while simultanously showing that his foundation is incapable of managing anything as complex as Java". The FSF manages emacs, gcc and GNU (GNU is not a program, it's an OS).
Actually, I was pointing out how you were making my point. GCC gets massive amounts of help from corporations just like Linux and OOo do. Emacs got the same treatment in the past. Your use of the "GNU subsystem" (the proper name for the bundle) is nonsense. You're talking about a bundle of disparate products, none of which even comes close to the complexity of the Java platform.
Stop throwing up strawmen as a distraction. Stallman is upset because Java is cool and he doesn't have it. Microsoft tried to take it over in their own way, and now Stallman trying to take it over in his own way. The only difference is that Microsoft actually produced a reasonable and fully functional alternative.
Is Java Free Software? Nope. Not yet, it isn't.
Would you like to explain to me WHY THIS IS SUN'S PROBLEM? They have given everything away except for the actual rights to Java itself. If the GNU Foundation can't produce an Open JVM based on open specs and fully available source code, THAT IS THEIR PROBLEM.
If a malevolent entity bought Sun - with a depressed Sun stock, it's a real possibility - could that entity do damage? Oh boy, you bet.
If a malevolent entity hit Linus with a bus and acquired his Linux trademarks, and with the number of evil people out there it's a real possibility, could that entity do damange? Oh boy, you bet!
Come off this nonsense people. Sun is not losing money hand over fist (they're more or less breaking even right now), and they've made it perfectly possible for others to replicate their technology. Why is the OSS community blaming their failure to do so on Sun?
It's the reliance on problematic (to the FSF) technology that this issue (flamewar? WTF?) is about.
The FSF's failure to produce a JVM based on open specs is NOT everyone else's problem. If Mr. Stallman wants to fix the situation, he should be inciting his troops to fix their Open JVMs. Otherwise he can keep his trap shut, because he has no right to complain.
emacs, gcc, gnu...
Funny, it seems that EMacs and GCC have a lot of help from corporate entities. And what is "gnu"? I'm not familiar with that program.
The concern Stallman had was that OOo wouldn't be compatable with (real and hypothetical) Free Java implementations, a legitimate concern given the difficulty of restricting one's self to an "official" API.
Go program Java for a little while. The "hidden" APIs are not a necessary evil, or in any way desirable to use. The very design of the Java platform is so open that those APIs are almost impossible and completely unncessary to use. Pretty much all examples of this usage comes from the 1.1 days when a few APIs had yet to mature. Foolish developers went off and decompiled Java code to find "extra" features like they could in Microsoft software. Thus any occurances in OOo probably stem from StarDivision's work way back when.
What's frightening is how little people like you understand trust. No one can do anything without some degree of trust. Part of building a strong business is to get your customers to trust you. I generally trust Sun, because they've worked hard to earn that trust. You trust Stallman not to screw you because you feel that he holds to principles you agree with.
However, I don't trust him as far as I can kick him. He had proved to me that he will always overreact to every situation, and suggest solutions that he is incapable of executing himself. It's perfectly within his right to attempt to get companies to pick up the tab for his ideals, but it's not alright to then stick a knife between their shoulders at every opportunity. Ask the KDE project how much they appreciate his ideals. Also notice how far along the QT replacement project has gotten. Interesting, isn't it?
Oh, so this must be the reason why building OO2 with a free java has been such a pita and required so much work...
Such as? No one has come forward with any solid complaints against the 2.0 release. Almost all complaints (e.g. hidden APIs) are against the OLD version of OOo. If you have a solid argument then by all means, make it.
however that really doesn't mean that one shouldn't be able to critizise SUN when they do something bad and stupid
Except that they haven't managed to do anything stupid. They leveraged the Java platform with the full blessing of the OOo community to produce a quality product. That's smart. Rebuilding everything from scratch because you don't want to keep up with technological progress is stupid.
"BTW, Mr. Stallman. How's Hurd coming along?"
And has got exactly what to do with the story? Oh nothing, you simply thought you could score a cheap shot and start a flamewar.
No, I couldn't resist that shot. Because Mr. Stallman has incited his own flamewar over absolutely nothing, while simultanously showing that his foundation is incapable of managing anything as complex as Java. Look at the Linux success and trace out which programmers are doing the most powerful work. You'll find that $$$ and hours are coming from IBM, Oracle, Sun, and other big names to make Linux useful. Same with OOo. It's not the GNU volunteers who are doing the bulk of the work.
Too bad they dont use something like TCL-TK or Ruby... but I kow why that is. There's a hell-uva lot of programs and libraries to use for free(as in gpl'ed).
There's a hell of a lot more for Java. For example, there's no other platform that has as many high quality, cross platform database drivers. And for that matter, Java has quite a few free database engines (HSQL, McKoi, Derby (Cloudscape, etc.) At the end of the day, there simply isn't any other solution that's as well supported and ubiquitous as Java.
At the risk of starting a flamewar, I have to say that I'm proud to have been a vocal early adopter that helped Java reach the status it has today. It's a good language, a good platform, hosted by a good company, and supported by many. Only the original Unix platform had such a profound effect on the industry.
only official Java APIs are allowed to be used
This was already being done. There was a plugin interface that hooked into the AWT layer of the JVM, but that was something that was easily replacable by other VMs. Previous versions of OOo (probably from back when it was StarDivision property) used hidden APIs, but this was cleaned up in the 2.0 edition.
Java JRE interested parties provide the support code and take care
of QA, bugs etc.
This sounds like they're moving the plugin code out of OpenOffice and into the JVM. Technically, this is where it belongs, but it's always nice to be able to support the largest number of VMs possible.
OOo Java implementations must be encapsulated with well specified APIs
This is just good engineering design. If you can't produce readable JavaDocs from it, it isn't a good API.
OOo Java implementations must not check against Java versions or
vendors, with the only exception of workarounding bugs
Again, this is just common sense. Checking version numbers is a good way to nail yourself in the foot on future releases.
OOo Java implementations must not use swing, either because no free
swing implemetation is available or because it makes the user interface
inconsistent, this rule might be relativated in respect to 4
This is just common sense anyway. Using Swing would be detrimental to the GUI unless it was decided that the entire GUI framework would move at once. Such a decision would involve the entire OOo community.
the Java baseline is 1.3.1
This is the only concession I see being made. (1.4 & 1.5 have some *really* nice features.)
The amusing part about this is that the whole tirade against Java in OOo is nothing but a farce. A quick check of the 2.0 code finds almost nothing that violates these "concessions", and they amount to nothing more than diplomacy anyway. (i.e. The art of saying "nice doggy" until you can find a big stick.)
The truth is that Sun has bent over backwards for the OSS community, and all they get for their troubles are painful stabs in the back. Yeah, Sun's got some loud mouths working for them. But their actions have ALWAYS been honorable. Despite all the nonsense about "contamination", has anyone EVER had Sun sue them? I've certainly never heard of a case! And when Sun realized that the language was confusing, they updated future source releases with new language that EXPLICITY gives developers rights to whatever they remember. So no more excuses! If you want an OS Java platform, code it. Sun sure as hell isn't standing in your way.
BTW, Mr. Stallman. How's Hurd coming along?
As someone else pointed out, you really need to investigate On Demand solutions. Sun Microsystems will sell you a system with way more processors and memory than you need for a VERY low cost, but most of the extra hardware will be disabled. When you're expecting high volume (or even if it should suddenly happen upon you) you can call Sun and rent the extra hardware in a pinch.
This provides you with massive scalability, but without the nasty upfront cost. And if you outstrip the hardware you've been given, Sun can send a guy out to plug in another motherboard (4 processors + memory) while your server is still running!
GNU/Hurd has got to be the only non-released project that has taken longer than Duke Nukem Forever. They've been at that thing for well over a decade now, and recently switched microkernels (i.e. the L4 point you were making). I'm all for waiting until something is done, but can anyone give some visibility into what they've been actually DOING all this time?
Ever see how horribly Linux handles running out of memory?
:-)
A long time ago, yes. That's why I only trust Sun Machines for mission critical work.
But if your primary reasoning for needing virtualization is to protect against OS failures, doesn't that suggest that you need a better OS instead? (Or wait until someone fixes the OS you're using?)
I still have to wonder what the real point of virtualizing is. Yes, Microsoft pulled an amazing coup by convincing sysadmins that they should have a separate box for every tiny little service they wanted to run. But Microsoft got away with it because of the crappy design of Windows as a server OS. (i.e. You have to plan for complete system wipes and upgrades, security is such that one service could compromise another, and system software components are such that they happily interfere with each other.)
Back in the land of all things sane (i.e. Unix style OSes), I see no reason why NOT to run a billion services on one machine. As long as you've got spare system resources, why shouldn't you make use of them? Why do I NEED the domain controller, file server, mail server, and ftp server to all be different machines? One big Unix box does the job better, and for a lower up front (and longterm!) cost than lots of tiny Windows boxes!
Granted, there are still some issues that can't be overcome. But which really makes more sense, spending millions of dollars on tons of machines and an army of support staff, or spending a few hundred thousand on a couple of redundant machines and an admin or two to maintain them?
Actually, the grandparent IS correct. I spent the last week studying the Mach and OS X designs, and I found the following things:
1. Mach is not a complete kernel. It requires someone to implement the areas which the Mach group were not researching. This has traditionally been done by compiling against BSD 4.3.
2. Mac OS X updated to the FreeBSD kernel instead of BSD 4.3 to gain a more modern kernel design with better hardware support.
3. OS 9 "Classic" is not a microkernel server, but rather a technology that Apple calls "Blue Box". Blue Box is a hardware virtualizer like VMWare that is capable of communicating directly with the OS X desktop. Using this communication, the OS 9 desktop is made to disappear, making the application appear to run on the OS X desktop.
4. The combination of Mach and FreeBSD is called "XNU" by Apple. The complete os is called Darwin, and the commercial variety with the Next and Mac APIs is called "Mac OS X".
More Info:
Mach Kernel
Wikipedia: Mach
Wikipedia: XNU
Blue Box info
I didn't see anywhere in that article linked where it said that the oxygen would be pulled from the atmosphere.
;)
:)) A cement breakwall or a water filled tank might be a good way of shielding things beyond the runway from excessive exposure to the temporary radiation. On the ground, then engines could be capped.
It's an engine, not a complete vessel. You'd need to add additional intakes to obtain the oxygen from the air, and then feed it to the afterburner.
Once you send air through a reactor the radiation released from the rocket will go up by orders of magnitude due to neutron activation of Ar-40 to Ar-41.
That's why I suggested that they could be switched around. Not only will fewer engine changes be required, but you avoid irradiating any materials contained within regular air.
This will not allow a significant amount of radiation released (nowhere near what a air cooled reactor would generate--around 2000 rem/hr on contact at full power not including radiation from the reactor), but it will be detectable.
The question is, is this sufficient to be concerned about? As long as we're not posing a threat to humans on the ground (or water more likely), I'm not concerned. If your only concern is that the craft can be detected, then I'm not all that worried. Although I wouldn't want to be standing directly behind a 33 REM/Minute engine, I assume that proper precautions would be taken to make sure that people are *not* standing directly behind the engines. (That would be bad for more reasons than just radiation.
His point is that more powerful engines built and launched in space would drive the price down while simultaneously decreasing travel time. And he's right. If we had probes coming off of a moon or asteroid-based assembly line with standard science packages and engines, they would be WAY cheaper to launch. Right now we're wasting some ungodly amount of money on fragile little devices that could be whipped together by any half-competent engineer for a few thousand bucks. But the fact that the probe *must* absolutely work right the first time and *must* meet very light weight specifications and *must* be designed by scientists (not engineers) drives the price astronomically high.
:)
As someone pointed out, the primary issue to deal with on assembly line craft is the tremendous amount of customization done by scientists. What we need is a few crack engineers to talk with scientists and figure out a few expandable designs that can have all the necessary sensors mounted onto the post-assembly line vehicle. The only trick is that you MUST have powerful enough engines to accomidate the extra mass of the generic design. (A bit like how software had to be very streamlined back in the DOS days, but can be very generic and reusable on today's modern hardware.) The way I figure it, a 900+ Isp engine with a 1 G or greater thrust ability should do the job nicely.
We must proceed with caution by ceasing these speed-of-light simulations. The Chinese would surely use them to advance their space-weaponization program.
Why does this troll keep showing up? The Chinese don't have the resources to compete with the US. They've attempted manned space travel several times (even outright copying the Dynasoar design) and every time have had to cut it because of the cost. For now, I wouldn't worry too much about the Chinese one-upping the US on their own technology. Start worrying when they launch an Orion (not bloody likely).
Note that the Chinese space program is completely under the auspices of the Chinese department of war. By contrast, in the USA, NASA is an entirely civilian effort.
This is a GOOD thing. Remember what happened when the space program was under the United States department of war? (Specifically the Air Force?) That's right, some good engineering was done, but we didn't GET anywhere. It wasn't until NASA was formed that the US actually got into the race.
Forget the Ramjet, I think you meant Scramjet ala the X-43.
I'm still not so sure about the Scramjet. The engine itself is a great idea, but the structural requirements are terrible. Even a minor flaw in the surface of the vessel would lead to catastrophe.
The grandparent probably has it right. If you use Jet engines to get to a higher altitude, the efficiency of nuclear thermal engines can take you the rest of the distance without having to go hypersonic in thick atmosphere.
Interestingly, the "best" solution may even be a ramjet engine. Since a nuclear engine can run on any fluid, what more efficient method exists than pulling oxygen from the atomosphere? And if you afterburn with hydrogen, you're going to get one hellva kick in the pants. (Alternatively, you can turn it around and heat the hydrogen while "burning" the oxygen")
Amazingly, we already have the engine to do this. Pratt & Whitney's TRITON engine is the perfect solution. As a "tri-modal" engine, it's capable of three modes of operation:
1. Low atmosphere afterburning for high powered launches.
2. Upper atmosphere and orbital transfer propulsion using pure hydrogen fuel.
3. Low fission rate "idle" mode which produces ~200 kW of power. (More than enough for onboard systems.)
The implications of this engine are staggering. Thanks to the tungsten clad design, it can be used anywhere without polution. Which means that we can have a single engine type that can not only produce massive thrust on takeoff, perhaps even produce the much covettd and highly efficient ramjet. (Rocket scientists love the idea of taking oxygen from the atmosphere, but don't normally want their rockets spending enough time in the lower atmosphere to make it worthwhile). But also an engine type that is highly efficient in upper-atmosphere and "space" areas. Plus, the craft can ditch heavy batteries and fuel cells in favor of drawing all its power from the engines. That power would even be available for electrical manuvering thrusters so that the amount of propellant carried can be reduced. Thus some of the weight you pay for in heavier engines can be regained in reducing redudant systems.
If we're going to get a bird in the air in the near future that can get people to orbit cheaply and safely, nuclear is where my money is.
eh? How about just putting a cover over the radiation source?
A nuclear battery is always on. There's no way of stopping it from generating power, since the power is derived from the radiation itself. Even if you weren't generating electricity, the heat would build up quickly. (A 20W heating element could easily melt itself if the excess heat doesn't get vented. Not to mention how uncomfortable it would get on your lap.) Did you know that a small chunk of Pu-238 can easily boil a pot of water within a minute?
Correct. Sorry, I'm getting tired and called the control rods a moderator by accident. However, you'll note that the rest of my post jives with what you just said. (Other than the "control tods" that is. Whatever those are. ;-))
AFAIK, the problem here is the heat from the decay of the short-lifetime isotopes left from the fission.
It's always possible that you're correct, but that doesn't sound right to me. Other than spontaneous fission, fission only occurs when slow moving neutrons are captured by heavy atoms. Those atoms become unstable and collapse, thus producing energy and more neutrons. Water or heavy water is often used to slow some of the fast neutrons produced in these reactions.
Reactors are usually controlled via two methods. The first method is the use of a moderator such as control rods. These rods can be inserted so that they block a given amount of neutron radiation, thus ensuring that the reaction doesn't run away. However, control tods can only react so fast, and would not have time if the reactor went supercritical (unlikely, but possible). To mitigate these effects, reactors further rely on delayed neutrons from previously fissiled material. These neutrons show up anywhere from a few seconds to a few minutes after the initial reaction, thus providing time for reactor controls to respond to any signs that the reactor is going to reach a supercritical state.
If things go really wrong, a reactor may end up in a prompt-critical state where prompt neutrons are feeding the reaction. At this point, reactor control may have been lost. The standard procedure is to attempt to scram the reactor before the reaction becomes supercritical.
That's my understanding of it, anyway.
If they emitted radiation, what would they use for power? Think about that a bit. (And reread my original post.)
No, the RTG applications on Voyager, Galileo, Cassini, Viking... are superb acheivements of engineering and perfect applications of nuclear fission.
They are? Wow, that's amazing. Here I thought they were Radioisotope Thermal Generators, not micro-fission reactors. You sound like an idiot. (Hint: You would have known better if you had actually *read* the Wikipedia article instead of insulting it. Or do you have an allergy to factually correct information?)
But sharing space with millions of Tritium batteries on Earth is another matter.
As opposed to sharing the space with all of those Tritum watches, gun scopes, and keychains? Lord Almighty, you are an idiot.
It can't work with plutonium for exactly the reason we're talking about: plutonium would fizzle before the assembly is complete.
You said Uranium; I quoted you on it. So speaking of plutonium is a disingenuous argument.
That's why most bombs use the much more complex implosion technique.
Most bombs use the implosion technique because it's safer and more economical. Gun devices are far too easy to set off accidentally, and require a LOT of nuclear material in comparison to an implosion device.
The argument "somebody could build a crappy bomb, therefore it's OK go spread around materials that can be used to make a good bomb" doesn't make sense.
I believe the point was that Tritium makes no difference to crappy bomb. If they have enough uranium, they have enough uranium. Plutonium does not occur naturally, so it's far less likely the "bad guys" would have any on hand. They'd have a far easier time first purifying the U235 sitting all around them.
If you're using uranium for the bomb, it's very difficult to assemble the core into a critical state without a premature chain reaction setting off a fizzle.
Rubish. A gun device detonator is so stupidly simple that just about anyone could make it with enough material. All you need is to take the critical amount and split it into two subcritical halves. Load one half into a stationary holder (this is the target), and the other into a powerful gun aimed at the target. When the gun is fired, the force of the impact will compress the materials into a super-critical mass that should produce a reasonably nice "BOOM". No booster required.
Thankfully, the "bad guys" haven't been able to get their hands on sufficient uranium.