xine/mplayer are hardly illegal. They are indeed covered by mpeg4 patents (which only apply if you sell a certain number of units), and furthermore it is illegal (DMCA...) to distribute them with libdvdread.
While I agree with the atomicity part, it's all great provided that the code is bug-free. IIRC reiserfs bugfixes where quite frequent in kernel changelog a couple years ago.
Filesystems are so crucial to OS stability, that I'd say it's worth formally-verifying them to a certain extent (i.e. prove that the algorithms/code work, instead of just observing that they work in normal conditions).
P.S. The whole thing - filesystem as a DB - is complete crap. You can't do a bunch of fs operations in a single transaction and have ACID semantics on the transaction as a whole. Sure - searching is great. But database means much more than just a searching interface.
IANAL, but: Pretty much every license has a "gray area". IMHO two such problems with GPL are: 1. What constitutes derived work off the source code 2. How much it is reasonable to charge for distribution of source code.
It's quite conceivable that one judge would rule "against" one of the provisions of GPL for a very specific case, without invalidating the whole license. For instance: what if NVidia gets sued for not publishing their drivers under the GPL, and the judge does not consider their kernel module to be derived off the kernel ? Does that mean the GPL is invalid/unenforceable and NVidia used the linux kernel without a license? Hardly.
A life cycle based on "rotten egg gas", or H2S, was found in Romania, 1986. Water was an essential part of the environment, but light was not, and oxygen was at a very low level (~2%).
The weirdest thing is that these lifeforms evolved from "normal" terestrial life, and aparently within a couple thousand years. The majority of the species found there lost vision and skin pigments.
So why not something similar on Mars ? If water was flowing on Mars (and that implies some temperature ranges), there's a good posibility for life. At some point a planet-wide cataclism changes everything - surface water is completely lost - but in some places water, along with its inhabitans, is trapped underground. Evolution takes care of the details.
Sun processors execute server workloads (database, app server) very well, but that's pretty much it. The emphasis with such workloads is on the memory system. Boatloads of caches do the job. It's also more effective to have tons of processors that are very simple, than just a couple of them that are complex and powerful.
Scientific computing means data crunching (floating point). Complex, powerful processors are needed. The "stupider, but more" tradeoff doesn't work anymore. Sun processors have fallen behind in this respect.
... the US accounts for roughly 30% of the worlds economic output. It's no wonder that English is the most spoken second language, the lingua franca of these times.
BTW, I'm not American, English is my 2nd language.
Analogies don't prove anything
on
TMBG on DRM
·
· Score: 1
Sorry, you're not actually employed by RIAA. And they're not being mean to you - they just have crappy and overpriced products. Don't like it ? Buy something else. There are a few good indies.
itunes is DRM-ed. And it's sold 100 million tunes.
DRM, if kept to a minimum, isn't so bad - it merely prevents people from filesharing the music they just bought. The fact that RIAA is evil doesn't justify IP theft (which filesharing pretty much is).
Computer AI is simply incapable of extrapolating - i.e. thinking outside the box. It can work well for things it's programmed to, but it won't work outside it's designed context. Even a dog can do that.
In other words, it's more A than I. There are quite a few people who believe that AI, in its current form, is missing something fundamental, and not necessarily computing power.
As far as bugs are concerned - although it is extremely expensive, it is possible to prove that a program works right through formal analysis.
Fact 1. There are about ~900miles of electric cable on a regular Boeing.
Fact 2. Cell phones (esp. GSM) are some of the noisiest devices. If you don't believe me listen to radio and start dialing a number. Although they don't work on the same band, the distortion will be pretty obvious.
Fact 3. The vast majority of planes still use analog signaling between sensors and board (as opposed to digital), which is particularly susceptible to noise.
I'm just wondering - if a crash happens because of electromagnetic interference, how many useful clues would the black box give ?
Do you really think that Iraqi people would give a sh*t about legality of pirating software? C'mon, they don't do it in Eastern Europe, China, Russia, India, countries that are much stabler and healthier than Iraq.
That said, it's probably good for them to use open-source, because there's no danger of backdoors planted in their software.
The main difference between Sony and Microsoft is that Microsoft doesn't make its crucial components of the hardware.
This is, I believe, the main reason for Microsoft's eventual failure in this market. They're very successful with "we do the software, let others do the hardware" model in both the PC and mobile (pocket pc). The rules of the game change considerably in the console market.
Compatibility was not a problem for Sony, for instance. They just put the old chip on PS2 and also gave it a side function in non-emulation mode.
Microsoft, OTOH, can either be incompatible between releases or find itself at the mercy of CPU/video card manufacturers. They opted for the former, but it might just as well be a bad idea in the long run.
The interesting thing about the sulfur-based ecosystem discovered in Romania is that it was formed apparently with mutations that ocured quite fast on an evolutionary scale (thousands of years as opposed to millions).
We will obviously see a lot of mutations if we send life on an alien world. So my question is - are we gonna repeat the Australian eco-fiasco at a planetary scale ?
The only procs that treats x86 as a bytecode are perhaps Transmeta's. All other processors simply decompose complex instructions into simpler ones, without doing any post-optimization.
You might say that that's what JVMs do. But... you're wrong. Simply translating java bytecode into machine code doesn't get you much - i.e. you're only marginally faster than interpretation (that's a research result from IBM). What you have to do is to reconstruct the data and control flow from the bytecode, and only then do the actual compilation.
The same is pretty much true about x86, if you want to get good performance out of it. That's mainly the reason for x86-64 and Itanium - both actually clean up the instruction set.
Re:He used g++ to compare C++ with Java...
on
Java Faster Than C++?
·
· Score: 2, Informative
Try inter-procedural optimizations. For that you have to give icc/icpc the -ipo flag, and furthermore use xiar instead of ar and xild instead of ld.
The server one is optimized for throughput and concurrency, whereas the client one for latency.
You might think that the two are the same, but the two settings actually make a visible impact if you're running on a multi-processor system. Most notably, the garbage collector and locking primitives are implemented differently.
GCJ is actually worse than standard (Sun/IBM) VMs. The reason - gcc optimization "stack" isn't doing that great for a language like java. It's actually not so good for C++ either, and that's why Intel C Compiler beats the crap out of g++ (20->30% perf. improvement is hardly uncommon).
First of all, g++ actually sucks big time in terms of performance. Intel C Compiler, with inter-procedural optimizations enabled, produces code that's almost always 20->30% faster than g++. I've actually once compiled C code with g++ and it was visibly slower than the same code compiled with gcc... oh well.
Now, regarding java performance... Java isn't slow per se, JVMs and some apis (most notably swing) are. Furthermore, JVMs usually have a slow startup, which gave java a bad name (for desktop apps startup matters a lot, for servers it's hardly a big deal). Java can be interpreted, but it doesn't have to be so (all "modern" JVMs compile to binary code on the fly)
Bytecode-based environments will, IMNSHO, eventually lead to faster execution than with pre-compilation. The reason is profiling and specialized code generation. With today's processors, profiling can lead sometimes to spectacular improvements - as much as 30% performance improvements on Itanium for instance. Although Itanium is arguably dead, other future architectures will likely rely on profiling as well. If you don't believe me, check the research in processor architecture and compiling.
The big issue with profiling is that the developper has to do it, and on a dataset that's not necessarily similar to the user's input data. Bytecode environments can do this on-the-fly, and with very accurate data.
In certain cases, yes, I agree with you. However, if you have a DB, you usually can fit the entire DB in RAM, but you still need to write "something" on the disk for each transaction (the D requirement from ACID).
So you do RAID 0+1 - one for safety, zero for speed.
Slashdot Mirror
That's all.
... both "The Bald Prima Donna" by Ionescu and "Waiting for Godot" by Beckett.
Horrific, deplorable violence is OK as long as people don't say any naughty words
Filesystems are so crucial to OS stability, that I'd say it's worth formally-verifying them to a certain extent (i.e. prove that the algorithms/code work, instead of just observing that they work in normal conditions).
P.S. The whole thing - filesystem as a DB - is complete crap. You can't do a bunch of fs operations in a single transaction and have ACID semantics on the transaction as a whole. Sure - searching is great. But database means much more than just a searching interface.
It's quite conceivable that one judge would rule "against" one of the provisions of GPL for a very specific case, without invalidating the whole license. For instance: what if NVidia gets sued for not publishing their drivers under the GPL, and the judge does not consider their kernel module to be derived off the kernel ? Does that mean the GPL is invalid/unenforceable and NVidia used the linux kernel without a license? Hardly.
The weirdest thing is that these lifeforms evolved from "normal" terestrial life, and aparently within a couple thousand years. The majority of the species found there lost vision and skin pigments.
So why not something similar on Mars ? If water was flowing on Mars (and that implies some temperature ranges), there's a good posibility for life. At some point a planet-wide cataclism changes everything - surface water is completely lost - but in some places water, along with its inhabitans, is trapped underground. Evolution takes care of the details.
A long stretch, of course, but not unlikely.
Scientific computing means data crunching (floating point). Complex, powerful processors are needed. The "stupider, but more" tradeoff doesn't work anymore. Sun processors have fallen behind in this respect.
BTW, I'm not American, English is my 2nd language.
Sorry, you're not actually employed by RIAA. And they're not being mean to you - they just have crappy and overpriced products. Don't like it ? Buy something else. There are a few good indies.
DRM, if kept to a minimum, isn't so bad - it merely prevents people from filesharing the music they just bought. The fact that RIAA is evil doesn't justify IP theft (which filesharing pretty much is).
In other words, it's more A than I. There are quite a few people who believe that AI, in its current form, is missing something fundamental, and not necessarily computing power.
As far as bugs are concerned - although it is extremely expensive, it is possible to prove that a program works right through formal analysis.
Fact 2. Cell phones (esp. GSM) are some of the noisiest devices. If you don't believe me listen to radio and start dialing a number. Although they don't work on the same band, the distortion will be pretty obvious.
Fact 3. The vast majority of planes still use analog signaling between sensors and board (as opposed to digital), which is particularly susceptible to noise.
I'm just wondering - if a crash happens because of electromagnetic interference, how many useful clues would the black box give ?
A Martian day is not much longer than an Earth day - 24 hours, 37 minutes as opposed to 23h, 56m.
Need I say more :) ?
It's against everything the Internet stands for.
... your sexy sister with you.
That said, it's probably good for them to use open-source, because there's no danger of backdoors planted in their software.
The main difference between Sony and Microsoft is that Microsoft doesn't make its crucial components of the hardware.
This is, I believe, the main reason for Microsoft's eventual failure in this market. They're very successful with "we do the software, let others do the hardware" model in both the PC and mobile (pocket pc). The rules of the game change considerably in the console market.
Compatibility was not a problem for Sony, for instance. They just put the old chip on PS2 and also gave it a side function in non-emulation mode.
Microsoft, OTOH, can either be incompatible between releases or find itself at the mercy of CPU/video card manufacturers. They opted for the former, but it might just as well be a bad idea in the long run.
The interesting thing about the sulfur-based ecosystem discovered in Romania is that it was formed apparently with mutations that ocured quite fast on an evolutionary scale (thousands of years as opposed to millions).
We will obviously see a lot of mutations if we send life on an alien world. So my question is - are we gonna repeat the Australian eco-fiasco at a planetary scale ?
You might say that that's what JVMs do. But ... you're wrong. Simply translating java bytecode into machine code doesn't get you much - i.e. you're only marginally faster than interpretation (that's a research result from IBM). What you have to do is to reconstruct the data and control flow from the bytecode, and only then do the actual compilation.
The same is pretty much true about x86, if you want to get good performance out of it. That's mainly the reason for x86-64 and Itanium - both actually clean up the instruction set.
The results might shock you.
You might think that the two are the same, but the two settings actually make a visible impact if you're running on a multi-processor system. Most notably, the garbage collector and locking primitives are implemented differently.
GCJ is actually worse than standard (Sun/IBM) VMs. The reason - gcc optimization "stack" isn't doing that great for a language like java. It's actually not so good for C++ either, and that's why Intel C Compiler beats the crap out of g++ (20->30% perf. improvement is hardly uncommon).
Now, regarding java performance ... Java isn't slow per se, JVMs and some apis (most notably swing) are. Furthermore, JVMs usually have a slow startup, which gave java a bad name (for desktop apps startup matters a lot, for servers it's hardly a big deal). Java can be interpreted, but it doesn't have to be so (all "modern" JVMs compile to binary code on the fly)
Bytecode-based environments will, IMNSHO, eventually lead to faster execution than with pre-compilation. The reason is profiling and specialized code generation. With today's processors, profiling can lead sometimes to spectacular improvements - as much as 30% performance improvements on Itanium for instance. Although Itanium is arguably dead, other future architectures will likely rely on profiling as well. If you don't believe me, check the research in processor architecture and compiling.
The big issue with profiling is that the developper has to do it, and on a dataset that's not necessarily similar to the user's input data. Bytecode environments can do this on-the-fly, and with very accurate data.
So you do RAID 0+1 - one for safety, zero for speed.