(In fact, with gcj you're able to write native-binary GNOME apps using Java and the above projects...
gcj implements most of the Java programming language, but it only has a tiny fraction of the Java libraries.
There is currently only one Java platform implementation, and it is proprietary and comes from Sun; several other companies have licensed it and are shipping modified versions.
CDE is an ugly pain in the ass, IMHO.
CDE is basically what was considered fashionable around the time of Windows 3.1 and OS/2. Also, while the bindings may seem strange to people who have grown up on Windows or WindowMaker or whatever, CDE is actually pretty consistent.
I'm kind of conflicted about CDE/Motif. The actual implementation of Motif sucks badly and is quite buggy. But Motif takes much better advantage of X11 than Gtk+, and technically, CDE does quite a number of things a lot better than Gnome.
There is a very simple solution to the spam problem: electronic cash. If random people want to send me a message, they should include five cents in electronic cash. For that amount of money, I'll be happy to procmail it out. That requires the least amount of changes to our infrastructure and it preserves whatever privacy and anonymity guarantees we already have.
Of course, that will never happen because the US government hates cash--that's why we haven't gotten the electronic variety, and it's why the physical variety keeps getting less and less useful. Instead, spam, like terrorism and anything else, will be used as an excuse to introduce ever more intrusive identification and tracking mechanisms into the Internet.
Sorry, but moving a few thousand spam E-mail messages per user per year shouldn't be a significant resource issue with current hardware prices; if it is, there is something wrong with your setup. Most people generate more traffic and transactions in popup ads in a few weeks of web browsing.
What you propose, trusted networks and directory servers, is a privacy nightmare. While I loathe spam, given the choice between giving up my privacy or receiving spam, I will receive and filter spam any day.
I think a much simpler solution would be to require any incoming message to contain an anonymous electronic cash stamp in the value of, say, five cents.
It seems like we agree completely: GPL/QPL works for Troll Tech, so they are not going to change it. And, given the choice, Sun and other UNIX vendors naturally prefer a C-based LGPL toolkit to a C++-based GPL/QPL toolkit.
That still leaves the question: what is the KDE project's response going to be, if any?
Not a troll, but does anyone else feel that strategically, TrollTech should have made QT LGPL?
Qt under the GPL has worked financially well for Troll Tech, and I see no reason why they would change. Before KDE, Troll Tech was just one of many toolkits.
The real question is whether it was smart for KDE to pick a GPL'ed toolkit. When it comes down to it, companies like Sun and IBM really just have no interest in picking a toolkit as the basis for their desktop standard that ties them in some way to a small company somewhere. They have been down that road before and they don't want to go through that again, and neither do commercial developers, for that matter (I have been there).
KDE might well want to consider reviving the Harmony project--an independent implementation of Qt under the LGPL. However, last they tried, Troll Tech supposedly threatened with lawsuits.
KDE is much more tightly done than GNOME and the overall effect is defnly smoother, kinda like Windows done right!
Maybe it's Windows "done right", but from a technical point of view, I can't get particularly excited about either Gtk+ or Qt. Neither of them are very well interfaced with X11 in my opinion, and the APIs are quite cumbersome, too. My view is that, since I think both are pretty mediocre, I might as well use the one that comes with fewer strings attached. In fact, I tend to use wxWindows and FLTK most these days--they are less political, tend to be simpler, have lots of language bindings, and have even fewer strings attached.
Scientists are trying to figure out how to visit other planets without accidentally carrying earth microbes, and this guy wants to dump them for fun.
For the sake of science and possibly other life forms, let's hope that that kind ecological terrorism won't be tolerated by governments. Bringing rabbits to Australia was bad enough.
Yes, and you know why MS got the opportunity to do this? Because IBM was subject to the same legal scrutiny as Microsoft is now. IBM outsourced the PC operating system to MS because IBM was afraid of more anti-trust action if they did both the PC hardware and software in-house. Note that influencing IBM in this area wasn't the result of an actual settlement, it was the consequence of on-going legal scrutiny and the threat of lawsuits.
Today, Microsoft is the monopoly that kills innovation and competitiveness. And we can apply the same strategy to Microsoft as we did to IBM decades ago: on-going legal scrutiny and on-going lawsuits. Discovery, legal proceedings, and the threat of legal judgements have the teeth that anti-trust settlements lack. This is what will keep Microsoft in check, just like it did IBM.
It's worth pointing out that even just the legal scrutiny often causes companies to change their business practices profoundly.
For example, there was never really a decisive victory against IBM, but the decade of ongoing legal scrutiny caused IBM to change their business practices greatly, in many areas. As a specific example, the fact that the PC is a fairly open architecture is a result of such legal efforts: IBM only outsourced the PC operating system to Microsoft because they were afraid that bundling hardware and software would get them dragged into court again.
While this created another monopoly in the form of Microsoft, the overall outcome was still better than the alternative, a closed, all-IBM solution. The fact that the PC software was separate from IBM hardware allowed a third party hardware market to flourish and indirectly made software like Linux possible.
So, nibbling away legally at monopolists like IBM and Microsoft does produce long-term benefits, even if such efforts fail to produce groundbreaking short-term victories. The efforts against IBM opened up the PC hardware/software platform, and similar long-term efforts against Microsoft may kill the Microsoft monopoly as well.
And there are indications that Microsoft is changing subtly under this pressure already. But the point is: the longer the legal pressure is on them, the more they will change. This is not the time to lean back and say "oh, we'll just stick with this little settlement". It is on-going lawsuits, not some signature under a settlement, that ultimately keeps companies like Microsoft in check.
It is quite clear that there will be no noteworthy changes to the original settlement, so any interested parties (mostly Microsoft's competitors) don't have anything to gain.
A loss doesn't look good; the attorneys general that are pursuing this case wouldn't waste time on if if they thought they didn't have a chance to win it.
The real question is why the other states aren't pursuing it further. I suspect that's because of heavy lobbying and "campaign donations" by Microsoft, convincing politicians that what's good for Microsoft is good for the country.
Other architectures support point to point busses and better cache handeling more memory chanels/controlers etc... you could probably scale to 100 or so processors with that type of architecture.
That's an illusion. If there is any significant per-processor caching going on, you basically have a distributed systems with a fast, non-standard network in between, and a costly, complex page fault handler hardwired in hardware.
You can achieve the same thing more cheaply with distributed shared memory and a standard fast network. That is, instead of building lots of expensive, inflexible, special-purpose hardware, you treat the main memory of each machine as the "per-processor cache" and you do the synchronization in software over the network using page fault handlers. It simply makes no economic sense to put something that complicated and costly in hardware, in particular if the market for it is so small.
Note that architectures like MIPS already do page fault handling in software, so those kinds of software-based approaches are competitive with hardware implementations.
Latency, Mosix is just too un-responsive compaired to an SMP option.
Latency depends on the problem and the design of the distributed system. For problems where Mosix is an alternative to SMP, latency doesn't enter into the picture at all because Mosix processes are usually only loosely coupled and because network and disk I/O migrates with the processes.
For problems where IPC latency is a performance concern, it can almost always be dealt with even in a distributed system through better design. The money you save on overpriced SMP designs more than lets you make up for any remaining performance losses from network latency (and I'm not convinced that with modern networking technologies, there are significant losses anyway).
The more people that buy SMP boxes the better they will get,
No, they won't. There is no magic tooth fairy of SMP, and you can't scale SMP indefinitely. If you put, say, 64 processors onto "the same memory", they aren't really on the same memory anymore--you are just paying for a very expensive box with a bunch of hamstrung processors inside that are essentially doing distributed shared memory over a special-purpose network.
EBay has them. I suspect that any mass produced computer or peripheral from the 1970s onward will usually be around for 30-40 years in attics and can be found if people need it desparately enough.
At 250mph, you could travel from L.A. to NYC in 12h (with stops); at 200mph, it would take 15h. That's still a little longer than air travel, but not all that much. And train travel is a lot less taxing. In fact, with sleepers, it's a lot nicer to leave in the evening, arrive in the morning for business, and return the same way, instead of a red eye and a late evening return flight.
Of course, given that the overhead of air travel (travel to/from the airport, security, luggage, etc.) is largely independent of distance, on most shorter routes, at 200-250mph, trains are already faster for city-to-city travel. And trains tend not to fly into buildings, no matter how much terrorists insist.
Any brand with a distinctive image will get a loyal following of a few percent of the customers in a market. Look at designer labels in clothing, or at different car companies.
Apple's market is the pretty, upscale market: people who want to project an image of creativity and non-geekdom, and who are willing to pay a little extra. It helps that Apple is pretty good technically and tends to select fairly new standards into their machines (although their claims of having invented it all are pretty annoying).
Re:soot is not a global warming threat
on
239 MPG Car
·
· Score: 2
Soot is NOT an organic matter. Soot is carbon with other chemicals in it.
What does that have to do with anything? Soot is particulate matter, and it disappears from the atmosphere quickly--that's all that matters as far as global warming is concerned. The fact that it sticks to your house is unfortunate, but it is irrelevant to global warming.
As I was also saying, widespread adoption of diesel wouldn't happen without soot filters on cars anyway because it's a health hazard.
soot is not a global warming threat
on
239 MPG Car
·
· Score: 2
The net effect is at no real change, and more likely it actually make global warming worse.
While soot contributes significantly to global warming, unlike CO2, its contribution is short-lived because the particulate matter is removed from the atmosphere quickly (of the order of 1y). From the point of view of global warming, switching to efficient diesel engines is a very good choice. Furthermore, for widespread adoption of diesel the soot would to get removed anyway because it would be unhealthy.
Oh, I forgot this is Slashdot, Europe is enlightened, the U.S. is the bumbling oaf.
Maybe that's because a larger fraction of the people on Slashdot actually have a basis for comparison, compared to your average American.
With Gigabit networks on the one hand, the cost of many-processor SMP systems, and cache effects, it isn't clear that there are any problems for which SMP is the most cost-effective choice to achieve a given level of performance.
Mosix, of course, is no substitute for the kinds of problems in which many processes share a lot of state, but other approaches are (including distributed shared memory and various other communications libraries).
Sorry, I didn't mean to imply that Sphere was an adaptation of Lem, merely that it had a related story line.
I'm afraid I consider Michael Crichton part of the Hollywood set: I hated pretty much every single movie based on one of his books, and I can't help but think that it's either something to do with his books, or that artistic integrity should have caused him to stop making movie adaptations at some point.
Yes, there is some market segment that really swears by SMP. But beyond dual processor machines, the hardware cost and engineering complexity grow disproportionately with the number of processors. Most of the SMP market is driven by companies facing excessive software license costs for multiple machines, or by companies that can't figure out how to get their current architecture ported to a cheaper distributed system.
When it comes down to it, you only get cost-effective scalability by using distributed systems or clustering. In fact, for really large systems, it's the only possible way at all.
Something like OpenMosix should really be a standard part of the Linux kernel already, as should other support for simplifying clustering, distributed computing, communications, and distributed shared memory. Distributed systems and clustering is the future, not SMP.
People don't just use Linux on desktops, they also use it on handhelds, wearables, and embedded systems. So, a 486 running at 12MHz isn't out of the question at all.
Look, there are plenty of Java-enabled phones. The question is: which US vendors support which phones, where do you get the necessary hardware to download software into them, and have the cellular providers altered them in some way that limits them to over-the-air programming only.
Now, if you could point to some Java-enabled phones, their end-user programming information, and a US cellular service that supports it, that would be great; only one or two of those alone aren't really interesting since you need all three.
In fact, I think in the long run, end-user Java programmable will make it even in the US, but so far, the only ones I have seen have been crippled (well, except for PalmOS and Symbian based PDA/phone combos that happen to run Java as well).
You then turn around and claim that because it doesn't work in your environment then the whole idea is dumb.
Huh? Why would I be asking for recommendations on Java-programmable phones if I thought the idea was dumb? I think Java-programmable phones would be great. Too bad nobody has yet identified one that's supported by a US provider.
If you can't program them, that's a problem with the vendor of the phone, and the service provider, not with the underlying handset.
Indeed. And it's the cell service providers that make this hard in the US. It's the attitude of the cellular companies that is the obstacle, not the handsets themselves. A programmable handset is no good if nobody supports it.
Slashdot Mirror
gcj implements most of the Java programming language, but it only has a tiny fraction of the Java libraries.
There is currently only one Java platform implementation, and it is proprietary and comes from Sun; several other companies have licensed it and are shipping modified versions.
CDE is an ugly pain in the ass, IMHO.
CDE is basically what was considered fashionable around the time of Windows 3.1 and OS/2. Also, while the bindings may seem strange to people who have grown up on Windows or WindowMaker or whatever, CDE is actually pretty consistent.
I'm kind of conflicted about CDE/Motif. The actual implementation of Motif sucks badly and is quite buggy. But Motif takes much better advantage of X11 than Gtk+, and technically, CDE does quite a number of things a lot better than Gnome.
Of course, that will never happen because the US government hates cash--that's why we haven't gotten the electronic variety, and it's why the physical variety keeps getting less and less useful. Instead, spam, like terrorism and anything else, will be used as an excuse to introduce ever more intrusive identification and tracking mechanisms into the Internet.
What you propose, trusted networks and directory servers, is a privacy nightmare. While I loathe spam, given the choice between giving up my privacy or receiving spam, I will receive and filter spam any day.
I think a much simpler solution would be to require any incoming message to contain an anonymous electronic cash stamp in the value of, say, five cents.
That still leaves the question: what is the KDE project's response going to be, if any?
Qt under the GPL has worked financially well for Troll Tech, and I see no reason why they would change. Before KDE, Troll Tech was just one of many toolkits.
The real question is whether it was smart for KDE to pick a GPL'ed toolkit. When it comes down to it, companies like Sun and IBM really just have no interest in picking a toolkit as the basis for their desktop standard that ties them in some way to a small company somewhere. They have been down that road before and they don't want to go through that again, and neither do commercial developers, for that matter (I have been there).
KDE might well want to consider reviving the Harmony project--an independent implementation of Qt under the LGPL. However, last they tried, Troll Tech supposedly threatened with lawsuits.
KDE is much more tightly done than GNOME and the overall effect is defnly smoother, kinda like Windows done right!
Maybe it's Windows "done right", but from a technical point of view, I can't get particularly excited about either Gtk+ or Qt. Neither of them are very well interfaced with X11 in my opinion, and the APIs are quite cumbersome, too. My view is that, since I think both are pretty mediocre, I might as well use the one that comes with fewer strings attached. In fact, I tend to use wxWindows and FLTK most these days--they are less political, tend to be simpler, have lots of language bindings, and have even fewer strings attached.
If Mono, Gtk#, and Gnome2 keep going the way they are going, Sun may be shipping a .NET-based desktop before Microsoft is :-)
For the sake of science and possibly other life forms, let's hope that that kind ecological terrorism won't be tolerated by governments. Bringing rabbits to Australia was bad enough.
Yes, and you know why MS got the opportunity to do this? Because IBM was subject to the same legal scrutiny as Microsoft is now. IBM outsourced the PC operating system to MS because IBM was afraid of more anti-trust action if they did both the PC hardware and software in-house. Note that influencing IBM in this area wasn't the result of an actual settlement, it was the consequence of on-going legal scrutiny and the threat of lawsuits.
Today, Microsoft is the monopoly that kills innovation and competitiveness. And we can apply the same strategy to Microsoft as we did to IBM decades ago: on-going legal scrutiny and on-going lawsuits. Discovery, legal proceedings, and the threat of legal judgements have the teeth that anti-trust settlements lack. This is what will keep Microsoft in check, just like it did IBM.
For example, there was never really a decisive victory against IBM, but the decade of ongoing legal scrutiny caused IBM to change their business practices greatly, in many areas. As a specific example, the fact that the PC is a fairly open architecture is a result of such legal efforts: IBM only outsourced the PC operating system to Microsoft because they were afraid that bundling hardware and software would get them dragged into court again.
While this created another monopoly in the form of Microsoft, the overall outcome was still better than the alternative, a closed, all-IBM solution. The fact that the PC software was separate from IBM hardware allowed a third party hardware market to flourish and indirectly made software like Linux possible.
So, nibbling away legally at monopolists like IBM and Microsoft does produce long-term benefits, even if such efforts fail to produce groundbreaking short-term victories. The efforts against IBM opened up the PC hardware/software platform, and similar long-term efforts against Microsoft may kill the Microsoft monopoly as well.
And there are indications that Microsoft is changing subtly under this pressure already. But the point is: the longer the legal pressure is on them, the more they will change. This is not the time to lean back and say "oh, we'll just stick with this little settlement". It is on-going lawsuits, not some signature under a settlement, that ultimately keeps companies like Microsoft in check.
A loss doesn't look good; the attorneys general that are pursuing this case wouldn't waste time on if if they thought they didn't have a chance to win it.
The real question is why the other states aren't pursuing it further. I suspect that's because of heavy lobbying and "campaign donations" by Microsoft, convincing politicians that what's good for Microsoft is good for the country.
That's an illusion. If there is any significant per-processor caching going on, you basically have a distributed systems with a fast, non-standard network in between, and a costly, complex page fault handler hardwired in hardware.
You can achieve the same thing more cheaply with distributed shared memory and a standard fast network. That is, instead of building lots of expensive, inflexible, special-purpose hardware, you treat the main memory of each machine as the "per-processor cache" and you do the synchronization in software over the network using page fault handlers. It simply makes no economic sense to put something that complicated and costly in hardware, in particular if the market for it is so small.
Note that architectures like MIPS already do page fault handling in software, so those kinds of software-based approaches are competitive with hardware implementations.
Latency depends on the problem and the design of the distributed system. For problems where Mosix is an alternative to SMP, latency doesn't enter into the picture at all because Mosix processes are usually only loosely coupled and because network and disk I/O migrates with the processes.
For problems where IPC latency is a performance concern, it can almost always be dealt with even in a distributed system through better design. The money you save on overpriced SMP designs more than lets you make up for any remaining performance losses from network latency (and I'm not convinced that with modern networking technologies, there are significant losses anyway).
The more people that buy SMP boxes the better they will get,
No, they won't. There is no magic tooth fairy of SMP, and you can't scale SMP indefinitely. If you put, say, 64 processors onto "the same memory", they aren't really on the same memory anymore--you are just paying for a very expensive box with a bunch of hamstrung processors inside that are essentially doing distributed shared memory over a special-purpose network.
EBay has them. I suspect that any mass produced computer or peripheral from the 1970s onward will usually be around for 30-40 years in attics and can be found if people need it desparately enough.
Of course, given that the overhead of air travel (travel to/from the airport, security, luggage, etc.) is largely independent of distance, on most shorter routes, at 200-250mph, trains are already faster for city-to-city travel. And trains tend not to fly into buildings, no matter how much terrorists insist.
Apple's market is the pretty, upscale market: people who want to project an image of creativity and non-geekdom, and who are willing to pay a little extra. It helps that Apple is pretty good technically and tends to select fairly new standards into their machines (although their claims of having invented it all are pretty annoying).
What does that have to do with anything? Soot is particulate matter, and it disappears from the atmosphere quickly--that's all that matters as far as global warming is concerned. The fact that it sticks to your house is unfortunate, but it is irrelevant to global warming.
As I was also saying, widespread adoption of diesel wouldn't happen without soot filters on cars anyway because it's a health hazard.
While soot contributes significantly to global warming, unlike CO2, its contribution is short-lived because the particulate matter is removed from the atmosphere quickly (of the order of 1y). From the point of view of global warming, switching to efficient diesel engines is a very good choice. Furthermore, for widespread adoption of diesel the soot would to get removed anyway because it would be unhealthy.
Oh, I forgot this is Slashdot, Europe is enlightened, the U.S. is the bumbling oaf.
Maybe that's because a larger fraction of the people on Slashdot actually have a basis for comparison, compared to your average American.
And if there is any particular political bias on Slashdot, it's libertarian.
Mosix, of course, is no substitute for the kinds of problems in which many processes share a lot of state, but other approaches are (including distributed shared memory and various other communications libraries).
Sorry, I didn't mean to imply that Sphere was an adaptation of Lem, merely that it had a related story line.
I'm afraid I consider Michael Crichton part of the Hollywood set: I hated pretty much every single movie based on one of his books, and I can't help but think that it's either something to do with his books, or that artistic integrity should have caused him to stop making movie adaptations at some point.
When it comes down to it, you only get cost-effective scalability by using distributed systems or clustering. In fact, for really large systems, it's the only possible way at all.
Something like OpenMosix should really be a standard part of the Linux kernel already, as should other support for simplifying clustering, distributed computing, communications, and distributed shared memory. Distributed systems and clustering is the future, not SMP.
People don't just use Linux on desktops, they also use it on handhelds, wearables, and embedded systems. So, a 486 running at 12MHz isn't out of the question at all.
Now, if you could point to some Java-enabled phones, their end-user programming information, and a US cellular service that supports it, that would be great; only one or two of those alone aren't really interesting since you need all three.
In fact, I think in the long run, end-user Java programmable will make it even in the US, but so far, the only ones I have seen have been crippled (well, except for PalmOS and Symbian based PDA/phone combos that happen to run Java as well).
Huh? Why would I be asking for recommendations on Java-programmable phones if I thought the idea was dumb? I think Java-programmable phones would be great. Too bad nobody has yet identified one that's supported by a US provider.
If you can't program them, that's a problem with the vendor of the phone, and the service provider, not with the underlying handset.
Indeed. And it's the cell service providers that make this hard in the US. It's the attitude of the cellular companies that is the obstacle, not the handsets themselves. A programmable handset is no good if nobody supports it.
Well, I tried AT&T and T-Mobile with several phones. GPRS access takes a long time to be established initially, sometimes as long as a minute.