Looking at the history of moderation to my own posts, it is becoming clear that there are only two moderation options, though their names might be obfuscated through the use of other words.
-1, I'm offended +1, I like to play with my poopie
I don't know much about the x86 architecture, but given that it's CISC I bet it's likely that these 3 instructions could be replaced with a string of different instructions.
Then it could be used for any binary, not just Win2k =D
If they keep it lightweight and user-mode like they say they will, and Plex86 won't allow 2 or 3 instructions to execute, then running binary-only OSes might be a problem. A linux kernel can always be compiled to not use these instructions - they aren't necessary.
If Win uses these instructions, then Plex86 won't work, but maybe the Plex86/Bochs solution that's mentioned on the site will.
Species change in relation to their environment for reasons other than evolution. It's a fairly standard survival adaptation, but it can make for changes in species that people often think are best attributed to evoltion.
In general, someone whose parents are both Pygmies but who grows up in Spain is going to end up being average height. Turns out a large portion of the reason why pygmies tend to be so short is their diet.
First of all, why a robot head? All you need is a camera.
Because mounting the camera in a huge ball makes it more attractive to people who think on the kinds of wavelengths that would make them inclined to be interested in this kind of thing.
I don't think the issue being raised about Moore's law threatens big iron because companies that produce massive mainframes and supercomputers have been doing what Google just opted to do for years now.
What they seem to be talking about is that Google has realized that Moore's law doesn't just mean that you can get twice as much for the same price in 18 months. It also means you can get the same amount for an ever-decreasing price.
This is a big deal. As IT departments start realizing that if they already have a job that's being handled well by a cluster of, say, two servers that cost $10,000 apiece a year and a half ago but now need an upgrade, they have a few options.
First, they can spend $10,000 on the latest computer that is twice as fast, add it to the cluster, and keep doing that every so often. This is going to start causing some TCO problems with mixed hardware and all that.
Second, they can spend $20,000 on a pair of the latest thing. That might mean siphoning off cash by getting rid of the old machines.
Third, they can buy another of the original machine for $5,000 (probably less). They got what they need, they spent less money than they would with the other two options, and don't have to deal with mixed hardware headaches and all of that. Yeah, the old computers are going to die before the new one does, but by the time that happens it will be even more dirt cheap to replace them with identical machines. Only loss is that as this keeps happening the maintenance costs involved in managing an ever increasing number of machines start to go up.
But Google seems to be handling that problem well, so it may well prove to be not so much of a problem after all.
Google is taking the third option. If other companies take Google's lead, the semiconductor industry, with its rabid policy of pushing forward as quickly as possible and spending enough money to buy Tibet from China each year, it's going to be fucked.
Really, when you think about it, companies that sell Big Iron machines have known this for a long time. Have they been making their computers so damn powerful by fitting them with CPU's the size of floppy disks? No, they've been designing excellent backplanes and buses that allow for the creation of machines with thousands of processors that all access the same memory pool with high bandwidth and low latency.
The decision seems to be working extremely well for Big Iron. It looks like the right option for Google. Now we just have to wait for the rest of the IT industry to catch up.
And see python isnt weakly typed, its strongly typed, eg: when you need to know the type of a variable, you call type(var_name) and u know exactly what type it is, so during the bug hunting process you can get the exact same information regardless of whether its typed by value (of variable) (eg python, eg 'implicitly') or whether its type by variable (eg java, eg 'explicitly').
That's what I meant by "predicates were invented for a reason." The only weakly typed language I am familiar with that doesn't provide a mechanism for checking a variable's type (to ensure you don't misuse it) is FORTH
It seems like the nature of peer-to-peer can be exploited here. Does the protocol Kazaa uses provide some way to locate hosts on its networks? From there you chould just grep for IP's that belong to you and trace from there to a physical computer.
From there, all you need is a good application of some LART to the user of said p2p software, preferably in the form of disciplinary (read: vigilante) action.
Of course, everyone will probably think you're an asshole. This is best mitigated by having an official policy behind you. That, or you can just LART everyone into submission.
Either I don't understand what's so special about the.NET framework, or it seems safe to assume that this issue will be a moot point until CORBA is wiped from the earth.
If you have unit tests where a variable is a integral/scalar value, and then somehow at runtime it has a string value (cause someone called your function incorrectly), you're screwed because you didn't test that.
I know I spent hours chasing bugs that wouldn't have been possible in Java.
Wise man says, "If you shoot yourself in the foot, it's easier to solve the problem by being careful not to aim the gun at your foot than it is to make guns that don't point down."
Weak typing can be incredibly useful for those cases where you'd really like to write some routines or data structures that can ignore type.
I find myself getting around typing issues in languages like C by using pointers, which I think is a much worse kettle of fish than weak typing, especially when you throw programmers who handle warnings about undefined pointer types by casting the pointer to J. Random Type into the mix.
If you look at it one way, strong and weak typing are different tools for different jobs, and you should use whichever one is appropriate for the task at hand.
If you look at it another way, who cares? The problems raised in the strong vs. weak typing argument are better solved with taking the time to design the damn program correctly in the first place, before you start cutting code, anyway.
Since the universe will homogenize asymptotically, you'd have to come up with some sort of life that can do the same work on an infinitely decreasing energy gradient.
Nope, not even life can escape the laws of thermodynamics.
It takes time to accept other people's work, but not as much time as writing the code yourself, assuming the patch submissions are well-documented.
Of course, due to the nature of OSS, I think that smart maintainers will immediately reject any and all patch submissions that are not well commented.
Really, I think this is the reason why the Linux kernel and similarly maintained projects seem to mature so quickly compared to oh, say, gcc (pre-egcs) or the HURD might be because people like RMS honestly seem to think that merging other peoples' patches isn't worth their time.
Lastly I'm really surprised that Pixar didn't go for a server farm of OS X boxen, just goes to show ya, right tool for the job. Maybe they'll throw darwin on their at least.
Ok. Darwin makes some sense, but OS X? Why the heck would you want to be running a full GUI plus Aqua plus all the other tings that consume great heaping molten piles of memory that make up OS X on a render farm? On a render farm, you want each machine image running the absolute minimum for kernel and applications to keep everything else free for doing lots and lots and lots of floating point calculations.
For that kind of task, G4's just can't compete with Xeons on price/performance, especially when you count in the difference in cache size.
Although these mainly exist for ps/2 keyboards, there are hardware keystroke loggers that plug in between the keyboard and the USB port and are designed to look nonconspicuous.
Slashdot Mirror
Looking at the history of moderation to my own posts, it is becoming clear that there are only two moderation options, though their names might be obfuscated through the use of other words.
-1, I'm offended
+1, I like to play with my poopie
That would be neat in a general sense.
I don't know much about the x86 architecture, but given that it's CISC I bet it's likely that these 3 instructions could be replaced with a string of different instructions.
Then it could be used for any binary, not just Win2k =D
There's a huge difference between can and should.
Anyone can use a computer.
Some people shouldn't.
If they keep it lightweight and user-mode like they say they will, and Plex86 won't allow 2 or 3 instructions to execute, then running binary-only OSes might be a problem. A linux kernel can always be compiled to not use these instructions - they aren't necessary.
If Win uses these instructions, then Plex86 won't work, but maybe the Plex86/Bochs solution that's mentioned on the site will.
Species change in relation to their environment for reasons other than evolution. It's a fairly standard survival adaptation, but it can make for changes in species that people often think are best attributed to evoltion.
In general, someone whose parents are both Pygmies but who grows up in Spain is going to end up being average height. Turns out a large portion of the reason why pygmies tend to be so short is their diet.
Microsoft gets away with it because most governments are M$ software junkies, too.
I know there's a retort relating this comment to the penis size debate somewhere in here.
I'm not touching it, though.
First of all, why a robot head? All you need is a camera.
Because mounting the camera in a huge ball makes it more attractive to people who think on the kinds of wavelengths that would make them inclined to be interested in this kind of thing.
I don't think the issue being raised about Moore's law threatens big iron because companies that produce massive mainframes and supercomputers have been doing what Google just opted to do for years now.
What they seem to be talking about is that Google has realized that Moore's law doesn't just mean that you can get twice as much for the same price in 18 months. It also means you can get the same amount for an ever-decreasing price.
This is a big deal. As IT departments start realizing that if they already have a job that's being handled well by a cluster of, say, two servers that cost $10,000 apiece a year and a half ago but now need an upgrade, they have a few options.
First, they can spend $10,000 on the latest computer that is twice as fast, add it to the cluster, and keep doing that every so often. This is going to start causing some TCO problems with mixed hardware and all that.
Second, they can spend $20,000 on a pair of the latest thing. That might mean siphoning off cash by getting rid of the old machines.
Third, they can buy another of the original machine for $5,000 (probably less). They got what they need, they spent less money than they would with the other two options, and don't have to deal with mixed hardware headaches and all of that. Yeah, the old computers are going to die before the new one does, but by the time that happens it will be even more dirt cheap to replace them with identical machines. Only loss is that as this keeps happening the maintenance costs involved in managing an ever increasing number of machines start to go up.
But Google seems to be handling that problem well, so it may well prove to be not so much of a problem after all.
Google is taking the third option. If other companies take Google's lead, the semiconductor industry, with its rabid policy of pushing forward as quickly as possible and spending enough money to buy Tibet from China each year, it's going to be fucked.
Really, when you think about it, companies that sell Big Iron machines have known this for a long time. Have they been making their computers so damn powerful by fitting them with CPU's the size of floppy disks? No, they've been designing excellent backplanes and buses that allow for the creation of machines with thousands of processors that all access the same memory pool with high bandwidth and low latency.
The decision seems to be working extremely well for Big Iron. It looks like the right option for Google. Now we just have to wait for the rest of the IT industry to catch up.
Could this mean an increased problem with airport security guards hassling passengers with strip searches?
And see python isnt weakly typed, its strongly typed, eg: when you need to know the type of a variable, you call type(var_name) and u know exactly what type it is, so during the bug hunting process you can get the exact same information regardless of whether its typed by value (of variable) (eg python, eg 'implicitly') or whether its type by variable (eg java, eg 'explicitly').
That's what I meant by "predicates were invented for a reason." The only weakly typed language I am familiar with that doesn't provide a mechanism for checking a variable's type (to ensure you don't misuse it) is FORTH
It seems like the nature of peer-to-peer can be exploited here. Does the protocol Kazaa uses provide some way to locate hosts on its networks? From there you chould just grep for IP's that belong to you and trace from there to a physical computer.
From there, all you need is a good application of some LART to the user of said p2p software, preferably in the form of disciplinary (read: vigilante) action.
Of course, everyone will probably think you're an asshole. This is best mitigated by having an official policy behind you. That, or you can just LART everyone into submission.
Either I don't understand what's so special about the .NET framework, or it seems safe to assume that this issue will be a moot point until CORBA is wiped from the earth.
If you have unit tests where a variable is a integral/scalar value, and then somehow at runtime it has a string value (cause someone called your function incorrectly), you're screwed because you didn't test that.
And whose fault is it that you didn't test that?
The predicate was invented for a reason.
I know I spent hours chasing bugs that wouldn't have been possible in Java.
Wise man says, "If you shoot yourself in the foot, it's easier to solve the problem by being careful not to aim the gun at your foot than it is to make guns that don't point down."
I'm not sure I'd agree with your analogies.
Weak typing can be incredibly useful for those cases where you'd really like to write some routines or data structures that can ignore type.
I find myself getting around typing issues in languages like C by using pointers, which I think is a much worse kettle of fish than weak typing, especially when you throw programmers who handle warnings about undefined pointer types by casting the pointer to J. Random Type into the mix.
If you look at it one way, strong and weak typing are different tools for different jobs, and you should use whichever one is appropriate for the task at hand.
If you look at it another way, who cares? The problems raised in the strong vs. weak typing argument are better solved with taking the time to design the damn program correctly in the first place, before you start cutting code, anyway.
Since the universe will homogenize asymptotically, you'd have to come up with some sort of life that can do the same work on an infinitely decreasing energy gradient.
Nope, not even life can escape the laws of thermodynamics.
It would be intra-solarsystemic war.
It takes time to accept other people's work, but not as much time as writing the code yourself, assuming the patch submissions are well-documented.
Of course, due to the nature of OSS, I think that smart maintainers will immediately reject any and all patch submissions that are not well commented.
Really, I think this is the reason why the Linux kernel and similarly maintained projects seem to mature so quickly compared to oh, say, gcc (pre-egcs) or the HURD might be because people like RMS honestly seem to think that merging other peoples' patches isn't worth their time.
I would suggest that replacing a PIII with a VT220 can be reasonably considered a hardware based solution.
Don't forget PostScript and LaTeX.
And if that's still too expensive, you can forgo the technical talent, too, and make the sequel to Gladiator!
Lastly I'm really surprised that Pixar didn't go for a server farm of OS X boxen, just goes to show ya, right tool for the job. Maybe they'll throw darwin on their at least.
Ok. Darwin makes some sense, but OS X? Why the heck would you want to be running a full GUI plus Aqua plus all the other tings that consume great heaping molten piles of memory that make up OS X on a render farm? On a render farm, you want each machine image running the absolute minimum for kernel and applications to keep everything else free for doing lots and lots and lots of floating point calculations.
For that kind of task, G4's just can't compete with Xeons on price/performance, especially when you count in the difference in cache size.
Add built-in keyboards to the mix.
Although these mainly exist for ps/2 keyboards, there are hardware keystroke loggers that plug in between the keyboard and the USB port and are designed to look nonconspicuous.
There's the added bonus of getting to drink non-pasteurised beer.
Pasteurisation really does make a world of difference, and not in a good way.