If there's one thing Slashdot has taught me over and over and over and over and over again, it's that it is completely impossible for an x86 to emulate the glorious power of a PPC processor!
Now, I used to be one of those losers who believed the church-turing theorem, and thought that any CPU could emulate any other CPU. But Slashdot showed me the light! I now know that it's completely un-possible!
Nuclear reactors themselves are sealed. The water that runs the turbines never comes in contact with the reactor core. Rather, there's a closed system of pipes circulating over the reactor, and a completely different system of pipes that run alongside to exchange heat and drive the turbines.
Therefore, there isn't all that much contaminated water, and as far as I know, treating contaminated water isn't terribly hard, since all you really need to do is remove the contaminants from the water.
Overall, nuclear power is quite safe (well, possibly not in Russia, where they aren't so hot on safety features like everyone else is), and environmentally friendly. It would be nice if we had something even better, but it's vastly preferable to coal, oil, and natural gas.
the much vaunted vaporware hydrogen promise: where do hydrogen proponents think the hydrogen comes from? i don't know why people don't understand such a simple concept: you need to spend more energy freeing hydrogen from water or hydrocarbons than anything you gain from using it as an energy medium
While it's true that the system is of limited efficiency, you can certainly obtain more energy out of a hydrocarbon to hydrogen extraction than you put in - essentially, you power it by burning hydrocarbons.
If you do this in a large, efficient facility, the total life cycle efficiency may be higher than burning hydrocarbons at the end user point, because what you gain from doing it in a centralized place can pay for the other costs.
This is why everyone I know absolutely despises GNOME now. Because it's this retarded childish thing that can't even be configured properly (people expect apps to have moronic configuration out of the box, but usually at least it can be fixed.)
Case in point: Spacial Nautilus. It's a moronic idea. Just plain idiotic. Everyone absolutely despises it. It's a retarded throwback to file managers in 1985, which, you guessed it, sucked. This is why every major GUI switched over to a browser/tree based file manager years ago and dumped the new-window-for-everything idiocy. In fact, way back in... 1985, I seem to recall that everyone went and found replacement file managers which didn't do that, too. The two-pane ones seemed popular.
What did gnome do? "Wow! We INVENTED a new paradigm! We're going to make it like a Mac in 1985!"
Umm, no, they copied an old paradigm that everyone hates.
And worse? There's no button to turn it off. You have to actually hunt through undocumented keys in the windows^H^H^H^H^H^H^Hgnome registry trying to find the button to put the file manager into the unsupported normal mode.
W.T.F.?!
The gnome project these days is a good example of the horrors that happen if you, as a developer, are actually dumb enough to listen to human interface design people. Usually, these types are overblown nitwits who've never used a computer in their life, and base all their design decisions (if they even make decisions, instead of making gobble gobble sounds and talking about paradigms) on some focus group that was trying to discover whether computer illiterates can bungle their way through an interface quickly.
Generally, the only people really qualified to make good computer interfaces are software developers. The problem is, they're just too lazy to do it because UIs are boring. so, people do stupid things like put graphic artists in charge, when what they should be doing is offering free beer and unnecessary nudity as an incentive for quality coding.
Debuggers are useless for this, since they permute the execution order of a program. Only some hardware-level debuggers running on external machines are any use here.
The normal way to find these is print statements and thinking.
2) A deadlock.
Debuggers are useful here. But you can debug a deadlock with print statements by putting a timeout in your lock primitives that dumps the call stack. That's useful if you don't have a debugger, for example if your software is deployed somewhere and you need to debug the production system.
3) A performance anomaly in I/O bound code.
Debuggers are essentially useless here. Since it's IO bound, you probably want to use logging and possibly some sort of profiler code if you don't think it's a network issue.
4) A stack-smasher.
Debuggers tend to be useless here since the stack gets shredded before the program trips an exception. You might be able to find some stack information with a lot of effort, but it's sketchy.
Try logging instead - you'll hopefully be able to localize where the error comes from. At that point, maybe the debugger can help, but usually you can just look at the code and see the error.
5) Heap corruption.
Debuggers are mostly useless here. What you want to use is a heap debugging library. Usually writing your own is best, since you usually need to write your own hacks to only track the source of the problem if possible.
6) The, uh, printf family of functions.
Heh. write(2)
I program for a living, and I hardly ever use a debugger. For that matter, I hardly ever *have* a debugger. I do recognize that this is somewhat unusual though - most programmers do more apps work, where debuggers are common.
The ironic thing is, in systems level work, I really need to understand assembly.;-)
While the general idea you're expressing - that people should understand how computers work to program them - is a good one, I think you're missing the point to a large degree.
The things that are most important in performance are, generally speaking, algorithms. It's important to understand things like:
Cache - the computer operates faster on small working sets.
Algorithm efficiency - O(nlogn) is better than O(n^2) for most problems.
Latency - network or disk round trips are bad.
Etc. The sort of thing you're proposing, with stuff like function call arguments, loop conditionals, etc. are micro-optimizations, and are very seldom worthwhile for programmers. Micro-optimizations are almost always best left to the compiler writers, who can, in effect, program them once and let everyone reap the benefits.
Consider your example in particular: A function with 2 arguments instead of 10 isn't really faster. First off, it's only slower on an x86 - many architectures have these things called registers, which you can use for things like function arguments. Second, those function arguments are spilled to the stack just before the function call jump. This means they're extremely hot in the D$, and will hardly even be any more expensive than a register to reload at all. Third, if you break the big function into a lot of little ones, you're incurring more call overhead and more pressure on the I$. Fourth, breaking the function up causes multiple copies of the function prologues and epilogues, which will easily overwhelm the register spilling cost. Etc. etc. etc.
In other words, those 10 arguments are only microscopically slower, and may even be faster!
In this case, the student should avoid writing a function with 10 arguments if it makes the code clearer. The value of this sort of incredibly trivial micro-optimization is fundamentally dwarfed by the value of readable code - if the student can read her code, that means she'll have fewer bugs and can spend more time optimizing it. And that's what'll really make the program faster.
You should only consider worrying about optimizations at this level if you've already optimized your program at an algorithm level fully, have profiled it, and determined some particular pieces are extremely dense hot-spots that need to be improved by hand. But if you're doing that, you may want to consider recoding the hot-spots in assembly anyway.
These days, these sorts of hot spots tend to be media codecs, and the way to speed those up is to use SIMD instructions - which can only be used properly from asm. So even before worrying about these sorts of extremely tight micro-optimizations, you'd want to recode in assembly just to use the special vector instructions! And in asm, readability is even harder to obtain, so you'll probably avoid a lot of the sort of micro-optimizations a crazy compiler will do just so you can make sure the code works right.
Add QNX to that. It doesn't get much more microkernel than that, and I think noone would argue that QNX is slow.
QNX is slow.
We had to deal with it a bit at my last job, and while it's nicely suited for realtime programming, it was horribly inefficient at things where throughput matters. The filesystem, for instance, was amazingly slow.
This isn't to say that's necessarily a problem - for some applications, only latency matters. But most people would like their work to get done fast, too.
That said, most of the reason QNX is slow probably has to do with it being realtime, not with it being a microkernel. These things are always tradeoffs - realtime performance implies you've sacrificed efficiency for determinism.
A microkernel is an attempt to sacrifice efficiency for stability and/or maintainability - but to a very large degree that's an illusion, since the hardware doesn't allow you to truly isolate device drivers, and that's where most instability comes from.
Re:Don't ticket me - control my car's max speed
on
Road Marker Marks You
·
· Score: 1
The RCW only states that you can exceed the posted speed limit, up to the state speed limit, which is 60.
So eg., if the speed limit on your road is 35, you can go 60 when you pass.
If the speed limit is 60, you can go... 60. This is because the speed limit in Washington is 60.
(On some of the main highways, it's raised to 70. But those are divided roads where passing in the oncoming lane is illegal)
Wine also has to suppose the actual encoded binary formats of windows. For example, it has to deal with functions the same way windows compilers do, it has to have a compatible memory model, it has to support the executable file formats, etc.
Nice feature comparison, except for the fact that it's wrong. Perhaps the authors of D would do better if they actually learned C++ first? Designing a new language when you're clueless is the first sign of disaster. Look at Java.
Resizeable arrays: D Yes, C++ No
BZZT.
Arrays of bits: D Yes, C++ No
BZZT.
Built-in strings: D Yes, C++ No
BZZT.
Array slicing: D Yes, C++ No
BZZT.
Array bounds checking: D Yes, C++ No
BZZT.
Associative arrays: D Yes, C++ No
It's called a map.
Inner classes: D Yes, C++ No
BZZT (perhaps they meant specifically the automatic parent resolution?)
typeof: D Yes, C++ No
BZZT.
foreach: D Yes, C++ No
BZZT.
Complex and Imaginary: D Yes, C++ No
BZZT.
Struct member alignment control: D Yes, C++ No
Give me a break, every C++ compiler supports this. It's just implementation defined.
Now go look at D's page on Design By Contract in C++: here
Notice that any C++ programmer can come up with a far better implementation than theirs using child class destructors and inlining. In fact, Stroustrup even put one in his book in case you're having trouble getting the brain in gear.
The comparison list combines cluelessness and sophistry ("C++ doesn't have this feature! It's in the STL, not the language" - oh please) to try to promote their own half-baked language.
The selection buffer and the copy buffer are separate. If you select and then middle click, you paste out of the selection buffer. If you select, copy (ctrl-c or a menu etc.) and then paste (ctrl-v or a menu, etc.) you paste out of the copy buffer. The copy buffer will not be cleared when you select the url.
In other words, it's exactly like Windows or the Mac, except, you can use the middle button too. Wow, cool!
Yowch. The sad thing is, that actually looks like it's easily within the C64's capabilities, if you edit the design of the game engine a bit. You can modify part of the color palette for every 8x8 character on the screen, and redefine the character set, so with the right amount of blood it probably would have looked pretty decent.
Of course, that would require some actual redesign, something that most port jobs aren't budgeted for. Which is why most ports tended to be of varying degrees of awful. For instance, look at the port of Wing Commander to the Amiga. Ow!!
The sort of funky multifaceted paletting required to really make use of a machine like a C64 (or an Amiga for that matter - look at HAM mode!) made things that much worse, since moving from one whole paradigm to another tends to be too hard. For example, doing some nice smooth full-screen scrolling is pretty easy on a C64 (just fiddle with the offset register and rewrite the characters at the edges every 8 pixels), but you need to use character mode to really do it. So a chunky graphics-based PC game might not port well, even if the C64 could do very impressive games that looked similar.
2) The anti-Mhz myth. That Mhz don't mean anything. This is just FALSE. When you compare a single architecture (meaning one kind of one brand of processor) mhz give a VERY good idea of how performance will scale. If something gets X on a processor at 500mhz, you can with confidence say it will get nearly 2*X with the same kind of processor at 1000mhz. That doesn't mean it's the be-all, end-all benchmark, just a useful (and truthful) was of evaluating chip performance within a line.
Except, of course, that this isn't true either. True, mhz means something, but it's not even a good indicator within a processor line.
A 1000mhz processor will only be twice as fast as a 500mhz processor if the ram and the peripherals are ALSO twice as fast. Otherwise, it depends entirely in the workload whether the processor is faster. If your computer is basically just loading data from disk, copying it from one place to another with a simple transform, and sending it to the network or something similar, the 1000mhz processor may not be faster at all with the same ram! In fact, it could even be slower, if to get the right multiplier for the CPU, the front side bus speed was actually reduced (that does happen quite often) and hence the ram runs slower!
On the other hand, if your computer simply runs a tiny program (a few k) that fits entirely in the L1 cache, and almost never talks to main ram or the peripherals, then it may in fact run twice as fast when you double the clock speed.
In reality, real programs are somewhere in between, so to figure out whether it's worth it to get a faster processor or eg. buy more ram instead, or faster ram, or a 15krpm SCSI disk, or whatnot, you have to figure out what your computer is going to be doing and estimate accordingly. Or even better, test the actual machine out to see how fast it is before you buy a lot of them.
Working for a living, even with those annoying advanced degrees, costs a significant amount of time and effort. I've seen claims that acquiring a single job through direct application costs close to $100. And that's not considering the 40 hours a week one must spend at the job. Doing a job that pays poorly is inefficient, so workers limit the number of jobs they do to the highest paying they can find.
But suppose it costs you essentially nothing to make a buck through mugging. Then your best strategy to maximize profits is to mug as many people as you can find. After all, if you're mugging mortgage financiers, there might actually be some money in their pockets. You would miss those potential money sources if you trimmed your list. Perhaps some folks who have expressed interest in designer beer mugs are also walking in your area. If you did the "rational" thing you and didn't hit them over the head with a sand-filled sock, you would miss them, and it costs you nothing, right?
The sad point of all of this is that I'm going to (sort of) defend the muggers and point out that they are responding to basic economic forces that we all respond to at one level or another. As long as muggers can take in more money than it costs them, they will continue to beat people senseless and take their money. This is "rational" behavior in the economic sense.
This is just plain ridiculous. If anything, emulating a PPC on another platform is easier than emulating an x86. Why? Because the x86 instruction set is psychopathic. It's like it was designed by sadists. Ugh.
The PPC instruction set it pretty simple in comparison. It's easy to understand. It's easy to emulate.
Saying it's "hard" because it might be slow is all nice and good, but that's not hard. That's just slow. Actually writing a functional emulator is not (in comparison) hard. It's just kind of unrewarding, with the lack of demand and all.
All this blah blah blah about the register sets is absurd. Here, watch me emulate the PPC register set on a Commodore 64:
long reg[32]; long altivec[32][4];
OMFG! I am teh hax0r god of the universe! *rolls eyes*
Say they donate copy of Visual Studio Craptastica at $1000 retail price. They now have $1000 less in taxable income, so at a 10% tax rate they pay $100 less to the government than they would have if they'd done nothing.
If the marginal cost of producing a box containing some Visual Studio Craptastica CD's is less than $100, they've just made money on the deal.
In fact, the way they operate, the marginal cost of producing a box containing Visual Studio Craptastica CD's is probably about $5. Thus, as long as they have taxable income, they're accepting a $95 gift from the taxpayers every time they donate a box.
However, in the past, this wasn't really true, since Microsoft's stock options plan allowed them to never pay a thin dime in income taxes in the first place. Thus, they would actually be donating $5 to charity as their ability to squeeze tax money out of the government was already maxed out. I'm not sure what the current state of their taxes is, considering their new stock grant plan. Plus, in the past these deals usually imply some sort of vendor lock-in in the long term, meaning that $5 donation may make them $25 back once their target ends up buying all the software and upgrades that go along with it.
I should note in case anyone missed it, that these numbers are made up and are used to demonstrate a point, not that these are actually the real numbers involved. For instance, Visual Studio Craptastica probably actually sells for $1399.95, and the CD's probably really cost them $1.99.
Normally, the government subsidizes charitable donations by reducing the pain they cause through the tax burden. However, if the donations are of the form of a product with astronomical markup such as Microsoft's, it may actually be subsidizing them directly and paying the company a bonus in the deal.
MIPS "branch likely" instructions don't really have anything to do with branches being likely. They're a weird hack which basically instructs the CPU that it can ignore an instruction in the branch delay slot if a branch is taken (normally, the instruction must be executed).
This was deprecated because... well... It's almost entirely useless. It's essentially there just to simplify things for the compiler and allow it to make a few micro-optimizations.
Actual "branch likely" instructions that mean what they say are available on modern CPU's and are used extensively, for example in the Linux Kernel.
Slashdot Mirror
"The driver" for a Radeon 9500?
The driver for a Radeon 9500 is a closed source binary module, just like NVidia's is. ATI won't release any specs either on cards newer than the 8500.
This is clearly un-possible!
If there's one thing Slashdot has taught me over and over and over and over and over again, it's that it is completely impossible for an x86 to emulate the glorious power of a PPC processor!
Now, I used to be one of those losers who believed the church-turing theorem, and thought that any CPU could emulate any other CPU. But Slashdot showed me the light! I now know that it's completely un-possible!
This whole story must be a hoax!
Nuclear reactors themselves are sealed. The water that runs the turbines never comes in contact with the reactor core. Rather, there's a closed system of pipes circulating over the reactor, and a completely different system of pipes that run alongside to exchange heat and drive the turbines.
Therefore, there isn't all that much contaminated water, and as far as I know, treating contaminated water isn't terribly hard, since all you really need to do is remove the contaminants from the water.
Overall, nuclear power is quite safe (well, possibly not in Russia, where they aren't so hot on safety features like everyone else is), and environmentally friendly. It would be nice if we had something even better, but it's vastly preferable to coal, oil, and natural gas.
While it's true that the system is of limited efficiency, you can certainly obtain more energy out of a hydrocarbon to hydrogen extraction than you put in - essentially, you power it by burning hydrocarbons.
If you do this in a large, efficient facility, the total life cycle efficiency may be higher than burning hydrocarbons at the end user point, because what you gain from doing it in a centralized place can pay for the other costs.
This is somewhat speculative though.
"Proposed"
That is all.
... and gnome's response?
Force everyone to beginner mode.
This is why everyone I know absolutely despises GNOME now. Because it's this retarded childish thing that can't even be configured properly (people expect apps to have moronic configuration out of the box, but usually at least it can be fixed.)
Case in point: Spacial Nautilus. It's a moronic idea. Just plain idiotic. Everyone absolutely despises it. It's a retarded throwback to file managers in 1985, which, you guessed it, sucked. This is why every major GUI switched over to a browser/tree based file manager years ago and dumped the new-window-for-everything idiocy. In fact, way back in... 1985, I seem to recall that everyone went and found replacement file managers which didn't do that, too. The two-pane ones seemed popular.
What did gnome do? "Wow! We INVENTED a new paradigm! We're going to make it like a Mac in 1985!"
Umm, no, they copied an old paradigm that everyone hates.
And worse? There's no button to turn it off. You have to actually hunt through undocumented keys in the windows^H^H^H^H^H^H^Hgnome registry trying to find the button to put the file manager into the unsupported normal mode.
W.T.F.?!
The gnome project these days is a good example of the horrors that happen if you, as a developer, are actually dumb enough to listen to human interface design people. Usually, these types are overblown nitwits who've never used a computer in their life, and base all their design decisions (if they even make decisions, instead of making gobble gobble sounds and talking about paradigms) on some focus group that was trying to discover whether computer illiterates can bungle their way through an interface quickly.
Generally, the only people really qualified to make good computer interfaces are software developers. The problem is, they're just too lazy to do it because UIs are boring. so, people do stupid things like put graphic artists in charge, when what they should be doing is offering free beer and unnecessary nudity as an incentive for quality coding.
1) A race condition.
;-)
Debuggers are useless for this, since they permute the execution order of a program. Only some hardware-level debuggers running on external machines are any use here.
The normal way to find these is print statements and thinking.
2) A deadlock.
Debuggers are useful here. But you can debug a deadlock with print statements by putting a timeout in your lock primitives that dumps the call stack. That's useful if you don't have a debugger, for example if your software is deployed somewhere and you need to debug the production system.
3) A performance anomaly in I/O bound code.
Debuggers are essentially useless here. Since it's IO bound, you probably want to use logging and possibly some sort of profiler code if you don't think it's a network issue.
4) A stack-smasher.
Debuggers tend to be useless here since the stack gets shredded before the program trips an exception. You might be able to find some stack information with a lot of effort, but it's sketchy.
Try logging instead - you'll hopefully be able to localize where the error comes from. At that point, maybe the debugger can help, but usually you can just look at the code and see the error.
5) Heap corruption.
Debuggers are mostly useless here. What you want to use is a heap debugging library. Usually writing your own is best, since you usually need to write your own hacks to only track the source of the problem if possible.
6) The, uh, printf family of functions.
Heh. write(2)
I program for a living, and I hardly ever use a debugger. For that matter, I hardly ever *have* a debugger. I do recognize that this is somewhat unusual though - most programmers do more apps work, where debuggers are common.
The ironic thing is, in systems level work, I really need to understand assembly.
The things that are most important in performance are, generally speaking, algorithms. It's important to understand things like:
Etc. The sort of thing you're proposing, with stuff like function call arguments, loop conditionals, etc. are micro-optimizations, and are very seldom worthwhile for programmers. Micro-optimizations are almost always best left to the compiler writers, who can, in effect, program them once and let everyone reap the benefits.
Consider your example in particular: A function with 2 arguments instead of 10 isn't really faster. First off, it's only slower on an x86 - many architectures have these things called registers, which you can use for things like function arguments. Second, those function arguments are spilled to the stack just before the function call jump. This means they're extremely hot in the D$, and will hardly even be any more expensive than a register to reload at all. Third, if you break the big function into a lot of little ones, you're incurring more call overhead and more pressure on the I$. Fourth, breaking the function up causes multiple copies of the function prologues and epilogues, which will easily overwhelm the register spilling cost. Etc. etc. etc.
In other words, those 10 arguments are only microscopically slower, and may even be faster!
In this case, the student should avoid writing a function with 10 arguments if it makes the code clearer. The value of this sort of incredibly trivial micro-optimization is fundamentally dwarfed by the value of readable code - if the student can read her code, that means she'll have fewer bugs and can spend more time optimizing it. And that's what'll really make the program faster.
You should only consider worrying about optimizations at this level if you've already optimized your program at an algorithm level fully, have profiled it, and determined some particular pieces are extremely dense hot-spots that need to be improved by hand. But if you're doing that, you may want to consider recoding the hot-spots in assembly anyway.
These days, these sorts of hot spots tend to be media codecs, and the way to speed those up is to use SIMD instructions - which can only be used properly from asm. So even before worrying about these sorts of extremely tight micro-optimizations, you'd want to recode in assembly just to use the special vector instructions! And in asm, readability is even harder to obtain, so you'll probably avoid a lot of the sort of micro-optimizations a crazy compiler will do just so you can make sure the code works right.
Furthermore, if you have more than one disk, multiple swap partitions are a good idea. The kernel will stripe between them, so swap will go faster.
If your disks aren't all the same speed, you can even specify priorities for which one(s) to use first.
QNX is slow.
We had to deal with it a bit at my last job, and while it's nicely suited for realtime programming, it was horribly inefficient at things where throughput matters. The filesystem, for instance, was amazingly slow.
This isn't to say that's necessarily a problem - for some applications, only latency matters. But most people would like their work to get done fast, too.
That said, most of the reason QNX is slow probably has to do with it being realtime, not with it being a microkernel. These things are always tradeoffs - realtime performance implies you've sacrificed efficiency for determinism.
A microkernel is an attempt to sacrifice efficiency for stability and/or maintainability - but to a very large degree that's an illusion, since the hardware doesn't allow you to truly isolate device drivers, and that's where most instability comes from.
The RCW only states that you can exceed the posted speed limit, up to the state speed limit, which is 60.
So eg., if the speed limit on your road is 35, you can go 60 when you pass.
If the speed limit is 60, you can go... 60. This is because the speed limit in Washington is 60.
(On some of the main highways, it's raised to 70. But those are divided roads where passing in the oncoming lane is illegal)
Wine also has to suppose the actual encoded binary formats of windows. For example, it has to deal with functions the same way windows compilers do, it has to have a compatible memory model, it has to support the executable file formats, etc.
Apparently, the page was just edited today. That bit wasn't there earlier this morning.
And furthermore... C has nested classes?
Heh.
Nice feature comparison, except for the fact that it's wrong. Perhaps the authors of D would do better if they actually learned C++ first? Designing a new language when you're clueless is the first sign of disaster. Look at Java.
Resizeable arrays: D Yes, C++ No
BZZT.
Arrays of bits: D Yes, C++ No
BZZT.
Built-in strings: D Yes, C++ No
BZZT.
Array slicing: D Yes, C++ No
BZZT.
Array bounds checking: D Yes, C++ No
BZZT.
Associative arrays: D Yes, C++ No
It's called a map.
Inner classes: D Yes, C++ No
BZZT (perhaps they meant specifically the automatic parent resolution?)
typeof: D Yes, C++ No
BZZT.
foreach: D Yes, C++ No
BZZT.
Complex and Imaginary: D Yes, C++ No
BZZT.
Struct member alignment control: D Yes, C++ No
Give me a break, every C++ compiler supports this. It's just implementation defined.
Now go look at D's page on Design By Contract in C++: here
Notice that any C++ programmer can come up with a far better implementation than theirs using child class destructors and inlining. In fact, Stroustrup even put one in his book in case you're having trouble getting the brain in gear.
The comparison list combines cluelessness and sophistry ("C++ doesn't have this feature! It's in the STL, not the language" - oh please) to try to promote their own half-baked language.
Conclusion:
Yet another half-baked useless language.
No it doesn't.
The selection buffer and the copy buffer are separate. If you select and then middle click, you paste out of the selection buffer. If you select, copy (ctrl-c or a menu etc.) and then paste (ctrl-v or a menu, etc.) you paste out of the copy buffer. The copy buffer will not be cleared when you select the url.
In other words, it's exactly like Windows or the Mac, except, you can use the middle button too. Wow, cool!
Yowch. The sad thing is, that actually looks like it's easily within the C64's capabilities, if you edit the design of the game engine a bit. You can modify part of the color palette for every 8x8 character on the screen, and redefine the character set, so with the right amount of blood it probably would have looked pretty decent.
Of course, that would require some actual redesign, something that most port jobs aren't budgeted for. Which is why most ports tended to be of varying degrees of awful. For instance, look at the port of Wing Commander to the Amiga. Ow!!
The sort of funky multifaceted paletting required to really make use of a machine like a C64 (or an Amiga for that matter - look at HAM mode!) made things that much worse, since moving from one whole paradigm to another tends to be too hard. For example, doing some nice smooth full-screen scrolling is pretty easy on a C64 (just fiddle with the offset register and rewrite the characters at the edges every 8 pixels), but you need to use character mode to really do it. So a chunky graphics-based PC game might not port well, even if the C64 could do very impressive games that looked similar.
Except, of course, that this isn't true either. True, mhz means something, but it's not even a good indicator within a processor line.
A 1000mhz processor will only be twice as fast as a 500mhz processor if the ram and the peripherals are ALSO twice as fast. Otherwise, it depends entirely in the workload whether the processor is faster. If your computer is basically just loading data from disk, copying it from one place to another with a simple transform, and sending it to the network or something similar, the 1000mhz processor may not be faster at all with the same ram! In fact, it could even be slower, if to get the right multiplier for the CPU, the front side bus speed was actually reduced (that does happen quite often) and hence the ram runs slower!
On the other hand, if your computer simply runs a tiny program (a few k) that fits entirely in the L1 cache, and almost never talks to main ram or the peripherals, then it may in fact run twice as fast when you double the clock speed.
In reality, real programs are somewhere in between, so to figure out whether it's worth it to get a faster processor or eg. buy more ram instead, or faster ram, or a 15krpm SCSI disk, or whatnot, you have to figure out what your computer is going to be doing and estimate accordingly. Or even better, test the actual machine out to see how fast it is before you buy a lot of them.
Working for a living, even with those annoying advanced degrees, costs a significant amount of time and effort. I've seen claims that acquiring a single job through direct application costs close to $100. And that's not considering the 40 hours a week one must spend at the job. Doing a job that pays poorly is inefficient, so workers limit the number of jobs they do to the highest paying they can find.
But suppose it costs you essentially nothing to make a buck through mugging. Then your best strategy to maximize profits is to mug as many people as you can find. After all, if you're mugging mortgage financiers, there might actually be some money in their pockets. You would miss those potential money sources if you trimmed your list. Perhaps some folks who have expressed interest in designer beer mugs are also walking in your area. If you did the "rational" thing you and didn't hit them over the head with a sand-filled sock, you would miss them, and it costs you nothing, right?
The sad point of all of this is that I'm going to (sort of) defend the muggers and point out that they are responding to basic economic forces that we all respond to at one level or another. As long as muggers can take in more money than it costs them, they will continue to beat people senseless and take their money. This is "rational" behavior in the economic sense.
This is just plain ridiculous. If anything, emulating a PPC on another platform is easier than emulating an x86. Why? Because the x86 instruction set is psychopathic. It's like it was designed by sadists. Ugh.
The PPC instruction set it pretty simple in comparison. It's easy to understand. It's easy to emulate.
Saying it's "hard" because it might be slow is all nice and good, but that's not hard. That's just slow. Actually writing a functional emulator is not (in comparison) hard. It's just kind of unrewarding, with the lack of demand and all.
All this blah blah blah about the register sets is absurd. Here, watch me emulate the PPC register set on a Commodore 64:
long reg[32];
long altivec[32][4];
OMFG! I am teh hax0r god of the universe! *rolls eyes*
Let's say their tax rate is 10% for simplicity.
Say they donate copy of Visual Studio Craptastica at $1000 retail price. They now have $1000 less in taxable income, so at a 10% tax rate they pay $100 less to the government than they would have if they'd done nothing.
If the marginal cost of producing a box containing some Visual Studio Craptastica CD's is less than $100, they've just made money on the deal.
In fact, the way they operate, the marginal cost of producing a box containing Visual Studio Craptastica CD's is probably about $5. Thus, as long as they have taxable income, they're accepting a $95 gift from the taxpayers every time they donate a box.
However, in the past, this wasn't really true, since Microsoft's stock options plan allowed them to never pay a thin dime in income taxes in the first place. Thus, they would actually be donating $5 to charity as their ability to squeeze tax money out of the government was already maxed out. I'm not sure what the current state of their taxes is, considering their new stock grant plan. Plus, in the past these deals usually imply some sort of vendor lock-in in the long term, meaning that $5 donation may make them $25 back once their target ends up buying all the software and upgrades that go along with it.
I should note in case anyone missed it, that these numbers are made up and are used to demonstrate a point, not that these are actually the real numbers involved. For instance, Visual Studio Craptastica probably actually sells for $1399.95, and the CD's probably really cost them $1.99.
Normally, the government subsidizes charitable donations by reducing the pain they cause through the tax burden. However, if the donations are of the form of a product with astronomical markup such as Microsoft's, it may actually be subsidizing them directly and paying the company a bonus in the deal.
MIPS "branch likely" instructions don't really have anything to do with branches being likely. They're a weird hack which basically instructs the CPU that it can ignore an instruction in the branch delay slot if a branch is taken (normally, the instruction must be executed).
This was deprecated because... well... It's almost entirely useless. It's essentially there just to simplify things for the compiler and allow it to make a few micro-optimizations.
Actual "branch likely" instructions that mean what they say are available on modern CPU's and are used extensively, for example in the Linux Kernel.
Ah, indeed! The resemblance is clear!
Slashdot wins again!
But, I am a geek, and thus am more interested in techical things than supple pink female flesh.
Plus, I can't see the logo very well. It looks like the logo to a Kawasaki Vulcan, but it's possible it could be something else!
One of the pictures says it's her on a Harley. But actually, that looks like a Kawasaki to me. Can anyone tell for sure?
Most X based systems will allow you to set the interface language from the login screen.
You don't even need to do that. You can select a different language for each program just by changing an environment variable.
This is nice since you don't have to log out.