Buh? Of course. Why are you lecturing me on the obvious. I said Itanium II is in some of the fastest machines, you lecture me about CS 101.
Do you have trouble putting two simple sentences together? You said the Itanium is not a dud because it's fast. I'm saying, fast isn't the primary reason why 64 bit is needed.
2G? Where are you from? "people" need more than 2G? No they don't. Even most businesses don't need more.
The ability to memory-map entire files alone is sufficient reason to go to 64 bits, even if the machine doesn't take as much memory. Of course, many web applications, databases, and video editing applications achieve an entirely new level of performance and simplicity if everything can just get loaded into RAM.
And you can access more than 2G from the P4, depending on your OS configuration.
Don't make me laugh. If you think that's a real option for addressing mroe than 2G from a single process, maybe you just program in VisualBasic (if you aren't just an Intel marketing droid).
AMD is doing exactly what people used to bitch about Intel about - they're extending an ancient ISA with all its cruft and legacy crap. But now that it's AMD it's A-OK with all the nerds. Bah!
The complaint about x86 chips was that their segmentation made writing compilers for it really hard and that they performed poorly. Once Intel started delivering decent performance at a decent price and had filled in the gaps in the instruction set and architecture, most rational people stopped complaining. Nobody cares what the registers are called or how the instructions are numbered as long as compilers can deal with it. And people became even happier when AMD delivered comparable performance at a lower price.
Now, Intel is doing the same thing all over again: they are delivering a crappy VLIW architecture that makes generating good code really hard, and their price/performance ratio is probably the poorest in the industry.
AMD, on the other hand, looks like they are going to deliver a fast chip at a great price, a chip that it is easy to generate code for, that is backwards compatible, and that even has 64 bit addressing.
But it begs the question: Does putting more and more app-level services (i.e. NFS servers, etc.) into the kernel go against that philosophy? It seems to me that it does.
Yes, it does go against that philosophy. Still, UNIX developers are pragmatic--that sort of thing may be OK for a few key services.
However, in Plan 9, the original UNIX developers have been trying to address this issue better.
Reply pages are dynamically generated (as are many other pages on Slashdot). News content on a site like Aceshardware would be static.
Even for dynamic content, it seems any reasonable web server should easily be able to generate half a dozen pages per second. Of course, it won't be able to if you do something stupid like put all your content into a database.
If they up the requirements too early, the SATA prices will be too high and people won't buy. That's why they start off with cheap specs that are barely faster and increase them later.
Effectively, the same happened with USB1 and USB2: it moved in because it was cheap and they later upped the performance.
Serial-ATA is transparent to existing operating system software expecting Parallel-ATA devices. It can also be retrofit easily into motherboards and drives. None of those applies to FireWire.
FireWire has the same problem relative to USB2. It may or may not be better than USB2, but USB1 is ubiquitous and USB2 is mostly transparent to software--it's just faster.
UNIX had it right: put all the isolation stuff into the kernel, and put all the programming outside of it. It's called "modularity". Yes, you do pay a performance cost for it in some cases, but the benefits in terms of simplicity of design are tremendous. Determining what a process can do in UNIX is a fairly simple affair, as is limiting what it can do.
The best attempt at isolation at the language level is probably Java. The internal security architecture is rather complicated. And even after half a dozen years, Java still does not provide anything like "ulimit" and I wouldn't trust it to isolate arbitrary code within the same VM.
intellectual property/privacy most intersting part
on
Kiln People
·
· Score: 1
The most important part of that book, to me, was how that future society dealt with intellectual property and privacy.
Currently, IP is often a criminal matter, and we tie up police and attorneys general with it. In Brin's world, IP claims get enforced through private investigation (not necessarily by the IP owner), civil actions and (possibly stiff) financial penalties. The whole system pays for itself. The same technique can also be applied to computer hacking: private enforcement and civil action, as opposed to the criminal approach we take today.
In terms of privacy, in Brin's world, there is a huge number of networked webcams and people trade in their content. As far as I can tell, that would even be legal today. And using such information, you can reconstruct what people are doing, where they are going, who they are meeting with. That pretty much seems inevitable.
Furthermore, most information that is exchanged between people in a non-personal way is public: business agreements, inventions, contracts, etc. (Presumably, your pillow talk and recorded personal journal would remain private, at least until your death.) You have the option of buying secrecy for a limited term, but you must put the information in escrow with a company that ensures that the information does become public after the agreed term. I think this is what we should do for computer software source code, trade secrets, tax returns, and a lot of other information.
The Itanium II is certainly not a dud - it's in some of the highest performing systems money can buy.
First of all, 64 bits isn't about speed, it's about address space.
Furthermore, even if speed is the issue, many of the people (like myself) who care most about it build compute clusters. The calculation is simple: (1) does it do 64 bit, and (2) how many FLOPs do $70000 buy me. The Itanium doesn't do very well on that metric.
Of course it's expensive, it's not for Joe Buck or Tim Small Business.
It is: the prices of memory have come down, and it makes sense for people to be able to use more than 2G in each process. It's great for databases, web server, video editing, and games, to name just a few mainstream applications.
x86 compatibility is worthless in a high end 64-bit machine, somethin AMD doesn't seem to grasp.
Quite to the contrary: x86 compatibility greatly reduces the risk of migration. I know that all my applications will continue to work as they do now, with no recompilation or bugs, but in addition, I can migrate individual apps to the 64 bit architecture. That's much better than what Itanium gives me.
They're marketing a high end technology (consumers and normal business users don't need 64-bit technology and won't for a while) to the mainstream market. Morons.
Yeah, right. You sound like a marketing guy. Oh, wait, you probably are a marketing guy. The only reason to buy 64 bit chips from Intel is that they are from Intel, and that Intel will probably manage to kill off the competition again, no matter how awful their chip is. But with AMD's backwards compatibility, that doesn't matter: AMD doesn't need to take over the 64 bit market to win, all they need to do is deliver good performance and value in their 32 bit mode and 64 bit functionality for a handful of custom applications.
what if scientists create an amount of matter and anti-matter, and using very sensitive equipment measure the gravity effect it has on say a hanging weight
The mass doesn't disappear when you bring matter and antimatter together. All you are doing is taking two chunks of mass an make them accelerate in opposite directions at light speed. There are cheaper and easier ways of doing that, like a battery-operated lightbulb.
Unfortunately, the notion of energy (and indirectly, matter) moving at infinite velocity seems to violate the entire theory of relativity.
Yes, it does. But the justification for the theory of relativity is based on not having observed anything that violates it. If we see superluminal communications, then we have. Logically, there is no intrinsic problem with sending information faster than light.
In other words, orbits won't be stable if gravity has a speed.
No; it just means that they won't be stable in the way you describe. What actually happens is that in the steady state, there are dynamic forces that cause the orbiting body to see a central force corresonding to the unretarded position of the central body, but there is no need for gravity to propagate faster than the speed of light.
The Gravitational pull of the Sun preceeds the source of light by 8 minutes.
It does, but that doesn't mean that gravity propagates instantaneously. Many theories of gravity get that effect with finite propagation velocities. There are analogous effects in electrodynamics.
In fact, even pretty much every remotely plausible "alternative" theory of gravity assumes propagation at the speed of light.
What that really means is that this experiment doesn't tell you much of anything--the outcome is as expected, and it doesn't discriminate among plausible alternative theories.
Hyperthreading and other tinkering isn't going to help Intel. The Itanium is a dud: systems based on it are hugely expensive, have iffy performance, and are not usefully x86 compatible.
If AMD manages to stick to their schedule on the 64bit chips, they are going to have a big winner on their hands: systems that can address more than 4G in a single process and yet are backwards compatible.
That's not a Java implementation, it's a source-to-byte-code compiler.
And GNU classpath? And japhar.org? And transvirtuals Kafee?
Those are not fully compatible (no Swing, many APIs missing).
And JRocket? And meanwhile forgotten Supercede/Asymetrix?
Supercede has a Sun license (at least they told me they had one when I asked them). JRocket is a compiler and relies on Sun code for things like Swing.
And KAWA? And SableVM?
Kawa is a Scheme-to-JVM compiler. SableVM is a JVM implementation, not a complete Java implementation.
Bottomline: there are at least 20 Java implementations out there. And more than 100 compilers for the Java platform.
Bottomline: there is not a single open source Java implementation out there. There are some open source compilers, some bits and pieces of libraries, etc., but no Java implementations. If you put all the open source Java stuff together, you still get something that is less compatible with Sun Java than even Microsoft Java was.
Or, to put it more simply: Swing and Java2D are essential parts of Java; where can I find any open source implementations?
Java published the specs to that, and Microsoft, having identified this as a great danger to its OS monopoly
Sun has never published specs sufficient for compatible third party Java implementations. And, in fact, Microsoft's implementation is a derivative of Sun's.
In the end, Java fails to deliver an open platform and write-once-run-anywhere functionality--its just another big, proprietary system that happens to run on top of multiple operating systems. If Java did deliver on its promise of an open platform and cross-platform system, Sun didn't have to resort to legal means to get it onto Windows.
What the judge should have ordered is for Microsoft to stop shipping their broken version of Java. Anything else is Sun's responsibility.
Microsoft behaved badly. They deserve to be punished. The problem with this order is not that it forces Microsoft to do something, it's that it gives Sun an unfair advantage relative to others.
Microsoft should have been ordered to stop distributing their own VM--they are violating Sun's trademark and engaging in deceptive business practices. But I think the punishment beyond that should have been monetary.
The point remains: Microsoft has much less of a history than Apple (or Sun) of using lawsuits to get their way. Just because someone beats their wife, that doesn't mean that you can also accuse them of killing babies.
Microsoft has a long history of using underhanded business tactics (e.g. punative lawsuits,
Underhanded business tactics, yes. But what big abuses of the legal system by Microsoft can you think of?
Apple, on the other hand, started the infamous look-and-feel lawsuits and tried to enforce some of the first software patents (on QuickDraw bitmap code).
In any case, the notion that you can "trust" a big business is stupid. If Apple/Jobs were in Microsoft's place, they'd behave the same way. And if Microsoft didn't have 90% of the market, they'd rely more on lawsuits.
It's OK to do those things when you have 3% of the market. It's not OK to do those things when you have 90% of the market.
If you want "nice", use open source. While companies have profit motives that get in the way of quality and features, the interests of most open source developers are aligned with those of users because they are users.
Erasing your disks before selling your PC is easy:
Get out your favorite Linux installer CD or download a copy of Tom's RTBT and write it to floppy or CD-R.
Boot from the floppy or CD.
Log in as root.
Run dd if=/dev/zero of=/dev/hda to erase the master drive on the primary IDE controller (/dev/hdb etc. for the remaining disks)
That's all. It erases all the blocks normally accessible by the disk controller and is probably safe enough for most people. Bad blocks that have been replaced may still contain a little bit of data, and inter-track data may be recoverable by analog means.
There are many approaches to text filtering and classification. Bayesian methods are just one of them. Latent Semantic Analysis and related techniques, for example, are not directly motivated by Bayesian considerations. Seems like this guy has heard a big-sounding buzzword once and is now parading it around as the solution to all our woes.
For the kind of "raw sewage" Kling produces, we don't need a Bayesian filter to detect it--it stinks enough without it.
Sorry, but that won't do. It's fine for governments to buy products where they can switch vendors fairly easily. It's also fine for governments to use software that's open source.
But when governments start using Windows, they are tied to the business decisions and future of a single company: they can't buy any substitutes and the license doesn't permit them to hire others to modify the code and redistribute the modifications. Even if Microsoft published the complete source code on the Internet, customers would still be completely at the mercy of Microsoft's business decisions because of the license. Incidentally, it's not just Microsoft: Sun is trying to navigate itself into the same position with Java, because, ultimately, all usable Java2 implementations have large chunks of code licensed from them.
Unless there are exceptional circumstances, the only systems governments should rely on are systems with open, non-proprietary standards. They don't have to be open source if there are multiple, reasonably interchangeable implementations. If they are open source, even better. Becoming dependent on a single vendor for anything is bad enough for a business, but for a government, it is really dangerous.
Slashdot Mirror
Do you have trouble putting two simple sentences together? You said the Itanium is not a dud because it's fast. I'm saying, fast isn't the primary reason why 64 bit is needed.
2G? Where are you from? "people" need more than 2G? No they don't. Even most businesses don't need more.
The ability to memory-map entire files alone is sufficient reason to go to 64 bits, even if the machine doesn't take as much memory. Of course, many web applications, databases, and video editing applications achieve an entirely new level of performance and simplicity if everything can just get loaded into RAM.
And you can access more than 2G from the P4, depending on your OS configuration.
Don't make me laugh. If you think that's a real option for addressing mroe than 2G from a single process, maybe you just program in VisualBasic (if you aren't just an Intel marketing droid).
AMD is doing exactly what people used to bitch about Intel about - they're extending an ancient ISA with all its cruft and legacy crap. But now that it's AMD it's A-OK with all the nerds. Bah!
The complaint about x86 chips was that their segmentation made writing compilers for it really hard and that they performed poorly. Once Intel started delivering decent performance at a decent price and had filled in the gaps in the instruction set and architecture, most rational people stopped complaining. Nobody cares what the registers are called or how the instructions are numbered as long as compilers can deal with it. And people became even happier when AMD delivered comparable performance at a lower price.
Now, Intel is doing the same thing all over again: they are delivering a crappy VLIW architecture that makes generating good code really hard, and their price/performance ratio is probably the poorest in the industry.
AMD, on the other hand, looks like they are going to deliver a fast chip at a great price, a chip that it is easy to generate code for, that is backwards compatible, and that even has 64 bit addressing.
Yes, it does go against that philosophy. Still, UNIX developers are pragmatic--that sort of thing may be OK for a few key services.
However, in Plan 9, the original UNIX developers have been trying to address this issue better.
Even for dynamic content, it seems any reasonable web server should easily be able to generate half a dozen pages per second. Of course, it won't be able to if you do something stupid like put all your content into a database.
Effectively, the same happened with USB1 and USB2: it moved in because it was cheap and they later upped the performance.
FireWire has the same problem relative to USB2. It may or may not be better than USB2, but USB1 is ubiquitous and USB2 is mostly transparent to software--it's just faster.
The best attempt at isolation at the language level is probably Java. The internal security architecture is rather complicated. And even after half a dozen years, Java still does not provide anything like "ulimit" and I wouldn't trust it to isolate arbitrary code within the same VM.
Currently, IP is often a criminal matter, and we tie up police and attorneys general with it. In Brin's world, IP claims get enforced through private investigation (not necessarily by the IP owner), civil actions and (possibly stiff) financial penalties. The whole system pays for itself. The same technique can also be applied to computer hacking: private enforcement and civil action, as opposed to the criminal approach we take today.
In terms of privacy, in Brin's world, there is a huge number of networked webcams and people trade in their content. As far as I can tell, that would even be legal today. And using such information, you can reconstruct what people are doing, where they are going, who they are meeting with. That pretty much seems inevitable.
Furthermore, most information that is exchanged between people in a non-personal way is public: business agreements, inventions, contracts, etc. (Presumably, your pillow talk and recorded personal journal would remain private, at least until your death.) You have the option of buying secrecy for a limited term, but you must put the information in escrow with a company that ensures that the information does become public after the agreed term. I think this is what we should do for computer software source code, trade secrets, tax returns, and a lot of other information.
First of all, 64 bits isn't about speed, it's about address space.
Furthermore, even if speed is the issue, many of the people (like myself) who care most about it build compute clusters. The calculation is simple: (1) does it do 64 bit, and (2) how many FLOPs do $70000 buy me. The Itanium doesn't do very well on that metric.
Of course it's expensive, it's not for Joe Buck or Tim Small Business.
It is: the prices of memory have come down, and it makes sense for people to be able to use more than 2G in each process. It's great for databases, web server, video editing, and games, to name just a few mainstream applications.
x86 compatibility is worthless in a high end 64-bit machine, somethin AMD doesn't seem to grasp.
Quite to the contrary: x86 compatibility greatly reduces the risk of migration. I know that all my applications will continue to work as they do now, with no recompilation or bugs, but in addition, I can migrate individual apps to the 64 bit architecture. That's much better than what Itanium gives me.
They're marketing a high end technology (consumers and normal business users don't need 64-bit technology and won't for a while) to the mainstream market. Morons.
Yeah, right. You sound like a marketing guy. Oh, wait, you probably are a marketing guy. The only reason to buy 64 bit chips from Intel is that they are from Intel, and that Intel will probably manage to kill off the competition again, no matter how awful their chip is. But with AMD's backwards compatibility, that doesn't matter: AMD doesn't need to take over the 64 bit market to win, all they need to do is deliver good performance and value in their 32 bit mode and 64 bit functionality for a handful of custom applications.
The mass doesn't disappear when you bring matter and antimatter together. All you are doing is taking two chunks of mass an make them accelerate in opposite directions at light speed. There are cheaper and easier ways of doing that, like a battery-operated lightbulb.
Yes, it does. But the justification for the theory of relativity is based on not having observed anything that violates it. If we see superluminal communications, then we have. Logically, there is no intrinsic problem with sending information faster than light.
No; it just means that they won't be stable in the way you describe. What actually happens is that in the steady state, there are dynamic forces that cause the orbiting body to see a central force corresonding to the unretarded position of the central body, but there is no need for gravity to propagate faster than the speed of light.
It does, but that doesn't mean that gravity propagates instantaneously. Many theories of gravity get that effect with finite propagation velocities. There are analogous effects in electrodynamics.
Search for "kopeikin" on arxiv.org; he has several papers there explaining what the idea is behind the experiment.
What that really means is that this experiment doesn't tell you much of anything--the outcome is as expected, and it doesn't discriminate among plausible alternative theories.
If AMD manages to stick to their schedule on the 64bit chips, they are going to have a big winner on their hands: systems that can address more than 4G in a single process and yet are backwards compatible.
Exactly: that's because the developers are the users.
Based on code licensed from Sun.
And the jikes compiler?
That's not a Java implementation, it's a source-to-byte-code compiler.
And GNU classpath? And japhar.org? And transvirtuals Kafee?
Those are not fully compatible (no Swing, many APIs missing).
And JRocket? And meanwhile forgotten Supercede/Asymetrix?
Supercede has a Sun license (at least they told me they had one when I asked them). JRocket is a compiler and relies on Sun code for things like Swing.
And KAWA? And SableVM?
Kawa is a Scheme-to-JVM compiler. SableVM is a JVM implementation, not a complete Java implementation.
Bottomline: there are at least 20 Java implementations out there. And more than 100 compilers for the Java platform.
Bottomline: there is not a single open source Java implementation out there. There are some open source compilers, some bits and pieces of libraries, etc., but no Java implementations. If you put all the open source Java stuff together, you still get something that is less compatible with Sun Java than even Microsoft Java was.
Or, to put it more simply: Swing and Java2D are essential parts of Java; where can I find any open source implementations?
Sun has never published specs sufficient for compatible third party Java implementations. And, in fact, Microsoft's implementation is a derivative of Sun's.
In the end, Java fails to deliver an open platform and write-once-run-anywhere functionality--its just another big, proprietary system that happens to run on top of multiple operating systems. If Java did deliver on its promise of an open platform and cross-platform system, Sun didn't have to resort to legal means to get it onto Windows.
What the judge should have ordered is for Microsoft to stop shipping their broken version of Java. Anything else is Sun's responsibility.
Microsoft should have been ordered to stop distributing their own VM--they are violating Sun's trademark and engaging in deceptive business practices. But I think the punishment beyond that should have been monetary.
The point remains: Microsoft has much less of a history than Apple (or Sun) of using lawsuits to get their way. Just because someone beats their wife, that doesn't mean that you can also accuse them of killing babies.
Underhanded business tactics, yes. But what big abuses of the legal system by Microsoft can you think of?
Apple, on the other hand, started the infamous look-and-feel lawsuits and tried to enforce some of the first software patents (on QuickDraw bitmap code).
In any case, the notion that you can "trust" a big business is stupid. If Apple/Jobs were in Microsoft's place, they'd behave the same way. And if Microsoft didn't have 90% of the market, they'd rely more on lawsuits.
If you want "nice", use open source. While companies have profit motives that get in the way of quality and features, the interests of most open source developers are aligned with those of users because they are users.
- Get out your favorite Linux installer CD or download a copy of Tom's RTBT and write it to floppy or CD-R.
- Boot from the floppy or CD.
- Log in as root.
- Run dd if=/dev/zero of=/dev/hda to erase the master drive on the primary IDE controller (/dev/hdb etc. for the remaining disks)
That's all. It erases all the blocks normally accessible by the disk controller and is probably safe enough for most people. Bad blocks that have been replaced may still contain a little bit of data, and inter-track data may be recoverable by analog means.For the kind of "raw sewage" Kling produces, we don't need a Bayesian filter to detect it--it stinks enough without it.
But when governments start using Windows, they are tied to the business decisions and future of a single company: they can't buy any substitutes and the license doesn't permit them to hire others to modify the code and redistribute the modifications. Even if Microsoft published the complete source code on the Internet, customers would still be completely at the mercy of Microsoft's business decisions because of the license. Incidentally, it's not just Microsoft: Sun is trying to navigate itself into the same position with Java, because, ultimately, all usable Java2 implementations have large chunks of code licensed from them.
Unless there are exceptional circumstances, the only systems governments should rely on are systems with open, non-proprietary standards. They don't have to be open source if there are multiple, reasonably interchangeable implementations. If they are open source, even better. Becoming dependent on a single vendor for anything is bad enough for a business, but for a government, it is really dangerous.