If you're after arcade shooters, there are some good ones in shareware-land. Some are even worth the $5-10 contribution asked for, and have received mine.
There are also the occasional simplified arcade-style shooters like MDK2 or Tsunami 2265 that come out. Unfortunately, they get roasted royally in the reviews for their simplistic play style, plummet down the sales charts, and are lucky to break even on the development costs. (OTOH, some like Tsunami 2265 deserve a good roasting for stupid things like not allowing mouse inversion. Idiots!)
The parent post discussed the stability of beta OS releases. All software is in a perpetual state of beta as new features are added -- a "release" is just a sometimes-more-stable snapshot.
Mandrake's cooker was more stable than my WinNT or Win2K boxen when I was keeping in sync with the dev trees.
Even the older libraries I rely on like libwww are under constant development, with bug fixes and enhancements showing up regularly.
The question is not whether an OS needs to be patched, but whether you're willing to wait for the patches and want to pay another 50% to get them with the "upgrade".
So far SCO's claims have proven irrelevant and completely unfounded. It's very likely they'll not only lose, but end up under some serious investigations for their activity. What little value they had will have been totally destroyed by SCO's "management".
As it was clearly done with his approval, the CEO's only hope of avoiding jail time for such abhorrantly greedy, manipulative behavior is an insanity plea. This "paranoia" just lays the groundwork for his defense...
Every WinXX release since 3.1 has been incremental improvements under the hood, with a lot of eye-candy changes to make it look like more has changed.
The default XP UI is still clunky for non-tech users, and some of the glitz to Longhorn might be good for them. They've almost reached the simplicity of the old mainframe fill-out-form and submit interfaces that IBM had by the mid-late '80s -- the rest is all eye candy and gloss.
Maybe this time they won't force me to spend hours figuring out how to shut off all the eye candy so I can get some work done instead of spinning cycles on feedback that just annoys the cubemates and strains my eyes. Maybe I won't need to upgrade the CPU just to maintain UI responsiveness.
Then again, it took how many years for Longhorn to reach the point where they'd leak screenshots? Any bets on whether the "hurd" beats this latest Microsoft cash grab out the door?
Compare the cost of a few extra case fans, a couple power barnacles, a honkin' big air cooler, and toss it in a nice sturdy case and you end up within about $50 of something like a Koolance case with built-in radiator/pump and an appropriate water block.
It's actually the fact that I could get the Koolance mid-tower for so little more than a "normal" performance cooling setup that convinced me to give it a shot. (Not that I recommend the mid-tower case -- it's too cramped. Getting a 425W PS in place was absolutely brutal, and I only had about 1/8" clearance along one edge of the mobo. Go with the full-size case instead.)
The only thing I'm thinking about doing with the system yet is replacing the stock fans with Pabst. It's not "noisy" by normal standards, but not quite as quiet as it will be when I'm done.
Water cooling is all about increasing the radiant surface for dissipating the exceess heat. Even the relatively basic Koolance water cooling systems have several times the surface area that even my Zalman coolers have.
More surface means better heat transfer, which means you can either crank your system's thermal load by overclocking harder than usual, or reduce your fan noise by using larger slower fans instead of 5000+ RPM screamers.
Original AT PC.
Generic AT form factors.
Funky vendor-specific layouts from Compaq, Packard-Bell, etc.
ATX layout
mini/micro/??? ATC layouts
Quick -- which is the standard? The only one that even comes close is the ATX, and even that isn't 100% "standard" now that so many boards have hole-through CPU cooler mounts that require additional clearance.
Some of the micro-ATX shoebox systems out there use some of the passive case cooling ideas, with heat-pipes transmitting the excess from CPU contact to the case itself.
The point of the whole discussion was abstract code theory, not to write tests for specific CPUs and compilers and see what happens.
It's people who can't have an abstract discussion that are killing this business and turning it into an inefficient assembly line. If you don't enjoy thinking and discussing the abstract, programming is the wrong industry for you.
With one minor change: You don't want the actual outside of the case to be cooling material in direct contact with the case. Never mind frustrated developers smacking the box, what happens to that CPU core when you knock the box over on the wrong side, or your grounded-forever kids whack the side with some hurtling toy?
LOD R1,__MAX JZ:END_LOOP :BODY_LOOP DEC R1 -- blah blah blah TST R1 JNZ:BODY_LOOP :END_LOOP DEC R1
Previously the decrement didn't occur if the condition failed on the first pass.
Don't most CISC CPUs have test-Rn-and-branch opcodes that pipeline down to 1-2 cycles nowadays? IIRC even the M68K had such opcodes, though they took a few cycles on the old microcode-driven CPUs (minimal pipelining, if any.)
LOD R1,__MAX JZ:END_LOOP :BODY_LOOP DEC R1 -- blah blah blah TST R1 JNZ:BODY_LOOP DEC R1 :END_LOOP
OTOH that is no longer a trivial parse-tree conversion, but now requires a bit of intelligence in the code generator to add the extra "DEC R1" on the way out of the loop.
No performance change, but the code has grown by an op.
Your first example produce raw pseudo-machine code like:
LOD R1,__MAX JZ:END_LOOP DEC R1 :BODY_LOOP -- blah blah blah DEC R1 JNZ:BODY_LOOP :END_LOOP
The second will produce something like:
LOD R1,__MAX DEC R1 JLZ:END_LOOP :BODY_LOOP -- blah blah blah DEC R1 JGT:BODY_LOOP :END_LOOP
Even the 8-bit 6502 and Z-80 CPUs set flags based on the Z/NZ/Sign status of the incremented/decremented register, and had the requisite conditional branch operations.
If you think there is a performance difference between the different conditional branches, you need to check your manuals again.
Slightly newer CPUs such as PDP, VAX, and M68K had instructions which did an increment/decrement and a conditional jump on Z/NZ in a single opcode. The VAX even had a horribly inefficient instruction that would even let you specify a loop increment/decrement other than 1.
Heavily pipelined RISC code looks worse, but should be effectively performance-neutral as well.
(Yes the "sample" code is just a dredging up of old keywords from a decade or two ago. It's not "real" assembly for any CPU.)
Unless you count the "MSN 8" nagware email as spam, my most recent hotmail account was spam free for almost an hour. Of course by the end of the third day it was back to 20-60 spams/day, same as every other account I've had on hotmail.
I have other "regular" addresses which get less than 20% of the spam flood the hotmail account does, despite having been used for domain registration, software download registrations, and other such "spam prone" activities.
I don't think they're selling addresses to the spammers, I think they're selling broadcast accounts for sending the spam to the suckers^?^?^?^?^?^?^?users.
Monopoly doesn't take any great effort to make things "difficult" to replace or install as Microsoft often has. All it takes is "typical" consumers who are afraid to touch anything.
Just over 8 months with his new computer, and last night my dad finally decided to watch what I did to download and install some packages for the neices and nephews.
Three months ago my mom just realized you could move windows by dragging the title bar.
"Replace" their Netscape mail client? What email client is so much better that "typical" consumers like my parents need to spend another three months just figuring out how to find the inbox/queued/sent emails? They still curse that the computer "lost" the mail because it got moved from to-be-sent queue to the sent history, until you remind them again.
I installed Eudora, Mozilla, etc. to show them "better" and "safer" tools. But they'll have none of that -- the Netscape 4.79 email client and the IE browser that were there when their internet connection was first set up is all they want.
The issue is that Sequent developed the RCU code
for Dynix/ptx (their SVR4/BSD personality hybrid) after publishing papers and submitting for patents on the related algorithms. The RCU code in Dynix/ptx is only an implementation of the IP, not a transfer of the IP itself.
All SCO has acquired is the right to use and distribute the RCU implementation Sequent deployed as part of Dynix. It does not transfer ownership of the RCU algorithms and patents to SCO, though it probably implies SCO has a perpetual right-to-use the RCU algorithms as implemented in Dynix.
SCO needs to prove that IBM used the Dynix implementation verbatim for AIX or Linux, rather than using code developed from the research papers and patents they acquired via Sequent. Further, they'll need to show that the Dynix code was not actually ported from a generic multi-OS code base (i.e. a generic OS sample implementation, such as you find in some textbooks.)
As multi-processor AIX was scaling quite nicely before IBM acquired Sequent, I don't think they're going to have any difficulty proving that AIX is not encumbered by Dynix code. Further, as Dynix was only running on x86 hardware while AIX runs on Power RISC cores, I really don't see how the core RCU code could even have made it's way from Dynix into AIX -- wouldn't the core RCU routines be hand-tweaked assembly rather than C code?
Client sites I've worked at didn't roll Novell servers because it's Novell, but because it's a stable directory management/resource sharing appliance. They could care less what kernel us under the hood, as long as it remains easy to administer and stable.
As Novell was rather pro-active in favour of defending Linux, I think it's rather rude to associate them as being behind the SCO crap.
Novell is just showing they are still a company that "gets it" technically. Why pay some obscene amount to support and develop a proprietary file sharing OS when the main thing customers buy their products for is directory management?
Sure people use Novell file/print sharing servers as well, but that's mainly because it's an appliance OS that integrates well with the directory management they want. They could care less about the underpinnings of that appliance OS as long as it does the job with reasonable performance.
When is the last time you've seen any applications built for the Novell OS core? That being the case, why would you care what OS API they have under the hood?
I always thought that people gullible/uneducated enough to fall for spam would also be too uneducated to run a computer well enough to handle the email in the first place.
Guess we've done too good a job of making them easy to use...
So you're saying that because lawyers are overpaid, they are justified in overcharging their clients? No wonder the RIAA and MPAA like you guys so much.
Slashdot Mirror
If you're after arcade shooters, there are some good ones in shareware-land. Some are even worth the $5-10 contribution asked for, and have received mine.
There are also the occasional simplified arcade-style shooters like MDK2 or Tsunami 2265 that come out. Unfortunately, they get roasted royally in the reviews for their simplistic play style, plummet down the sales charts, and are lucky to break even on the development costs. (OTOH, some like Tsunami 2265 deserve a good roasting for stupid things like not allowing mouse inversion. Idiots!)
The parent post discussed the stability of beta OS releases. All software is in a perpetual state of beta as new features are added -- a "release" is just a sometimes-more-stable snapshot.
Mandrake's cooker was more stable than my WinNT or Win2K boxen when I was keeping in sync with the dev trees.
Even the older libraries I rely on like libwww are under constant development, with bug fixes and enhancements showing up regularly.
The question is not whether an OS needs to be patched, but whether you're willing to wait for the patches and want to pay another 50% to get them with the "upgrade".
Federal Copyright guarantees the client/purchaser/licensee the right to make a backup of the software involved. Design requirement:
The GPL guarantees that you can make as many copies as you desire. In effect:
SCO just can't grasp the basic numeric theory needed to understand that all federal law makes illegal is:
So far SCO's claims have proven irrelevant and completely unfounded. It's very likely they'll not only lose, but end up under some serious investigations for their activity. What little value they had will have been totally destroyed by SCO's "management".
As it was clearly done with his approval, the CEO's only hope of avoiding jail time for such abhorrantly greedy, manipulative behavior is an insanity plea. This "paranoia" just lays the groundwork for his defense...
Every WinXX release since 3.1 has been incremental improvements under the hood, with a lot of eye-candy changes to make it look like more has changed.
The default XP UI is still clunky for non-tech users, and some of the glitz to Longhorn might be good for them. They've almost reached the simplicity of the old mainframe fill-out-form and submit interfaces that IBM had by the mid-late '80s -- the rest is all eye candy and gloss.
Maybe this time they won't force me to spend hours figuring out how to shut off all the eye candy so I can get some work done instead of spinning cycles on feedback that just annoys the cubemates and strains my eyes. Maybe I won't need to upgrade the CPU just to maintain UI responsiveness.
Then again, it took how many years for Longhorn to reach the point where they'd leak screenshots? Any bets on whether the "hurd" beats this latest Microsoft cash grab out the door?
Compare the cost of a few extra case fans, a couple power barnacles, a honkin' big air cooler, and toss it in a nice sturdy case and you end up within about $50 of something like a Koolance case with built-in radiator/pump and an appropriate water block.
It's actually the fact that I could get the Koolance mid-tower for so little more than a "normal" performance cooling setup that convinced me to give it a shot. (Not that I recommend the mid-tower case -- it's too cramped. Getting a 425W PS in place was absolutely brutal, and I only had about 1/8" clearance along one edge of the mobo. Go with the full-size case instead.)
The only thing I'm thinking about doing with the system yet is replacing the stock fans with Pabst. It's not "noisy" by normal standards, but not quite as quiet as it will be when I'm done.
Water cooling is all about increasing the radiant surface for dissipating the exceess heat. Even the relatively basic Koolance water cooling systems have several times the surface area that even my Zalman coolers have.
More surface means better heat transfer, which means you can either crank your system's thermal load by overclocking harder than usual, or reduce your fan noise by using larger slower fans instead of 5000+ RPM screamers.
Original AT PC.
Generic AT form factors.
Funky vendor-specific layouts from Compaq, Packard-Bell, etc.
ATX layout
mini/micro/??? ATC layouts
Quick -- which is the standard? The only one that even comes close is the ATX, and even that isn't 100% "standard" now that so many boards have hole-through CPU cooler mounts that require additional clearance.
Some of the micro-ATX shoebox systems out there use some of the passive case cooling ideas, with heat-pipes transmitting the excess from CPU contact to the case itself.
The point of the whole discussion was abstract code theory, not to write tests for specific CPUs and compilers and see what happens.
It's people who can't have an abstract discussion that are killing this business and turning it into an inefficient assembly line. If you don't enjoy thinking and discussing the abstract, programming is the wrong industry for you.
With one minor change: You don't want the actual outside of the case to be cooling material in direct contact with the case. Never mind frustrated developers smacking the box, what happens to that CPU core when you knock the box over on the wrong side, or your grounded-forever kids whack the side with some hurtling toy?
Previously the decrement didn't occur if the condition failed on the first pass.
Don't most CISC CPUs have test-Rn-and-branch opcodes that pipeline down to 1-2 cycles nowadays? IIRC even the M68K had such opcodes, though they took a few cycles on the old microcode-driven CPUs (minimal pipelining, if any.)
Correcting the "bugs" in part one... *g*
OTOH that is no longer a trivial parse-tree conversion, but now requires a bit of intelligence in the code generator to add the extra "DEC R1" on the way out of the loop.
No performance change, but the code has grown by an op.
Your first example produce raw pseudo-machine code like:
The second will produce something like:
Even the 8-bit 6502 and Z-80 CPUs set flags based on the Z/NZ/Sign status of the incremented/decremented register, and had the requisite conditional branch operations.
If you think there is a performance difference between the different conditional branches, you need to check your manuals again.
Slightly newer CPUs such as PDP, VAX, and M68K had instructions which did an increment/decrement and a conditional jump on Z/NZ in a single opcode. The VAX even had a horribly inefficient instruction that would even let you specify a loop increment/decrement other than 1.
Heavily pipelined RISC code looks worse, but should be effectively performance-neutral as well.
(Yes the "sample" code is just a dredging up of old keywords from a decade or two ago. It's not "real" assembly for any CPU.)
Unless you count the "MSN 8" nagware email as spam, my most recent hotmail account was spam free for almost an hour. Of course by the end of the third day it was back to 20-60 spams/day, same as every other account I've had on hotmail.
I have other "regular" addresses which get less than 20% of the spam flood the hotmail account does, despite having been used for domain registration, software download registrations, and other such "spam prone" activities.
I don't think they're selling addresses to the spammers, I think they're selling broadcast accounts for sending the spam to the suckers^?^?^?^?^?^?^?users.
Monopoly doesn't take any great effort to make things "difficult" to replace or install as Microsoft often has. All it takes is "typical" consumers who are afraid to touch anything.
Just over 8 months with his new computer, and last night my dad finally decided to watch what I did to download and install some packages for the neices and nephews.
Three months ago my mom just realized you could move windows by dragging the title bar.
"Replace" their Netscape mail client? What email client is so much better that "typical" consumers like my parents need to spend another three months just figuring out how to find the inbox/queued/sent emails? They still curse that the computer "lost" the mail because it got moved from to-be-sent queue to the sent history, until you remind them again.
I installed Eudora, Mozilla, etc. to show them "better" and "safer" tools. But they'll have none of that -- the Netscape 4.79 email client and the IE browser that were there when their internet connection was first set up is all they want.
The issue is that Sequent developed the RCU code for Dynix/ptx (their SVR4/BSD personality hybrid) after publishing papers and submitting for patents on the related algorithms. The RCU code in Dynix/ptx is only an implementation of the IP, not a transfer of the IP itself.
All SCO has acquired is the right to use and distribute the RCU implementation Sequent deployed as part of Dynix. It does not transfer ownership of the RCU algorithms and patents to SCO, though it probably implies SCO has a perpetual right-to-use the RCU algorithms as implemented in Dynix.
SCO needs to prove that IBM used the Dynix implementation verbatim for AIX or Linux, rather than using code developed from the research papers and patents they acquired via Sequent. Further, they'll need to show that the Dynix code was not actually ported from a generic multi-OS code base (i.e. a generic OS sample implementation, such as you find in some textbooks.)
As multi-processor AIX was scaling quite nicely before IBM acquired Sequent, I don't think they're going to have any difficulty proving that AIX is not encumbered by Dynix code. Further, as Dynix was only running on x86 hardware while AIX runs on Power RISC cores, I really don't see how the core RCU code could even have made it's way from Dynix into AIX -- wouldn't the core RCU routines be hand-tweaked assembly rather than C code?
Client sites I've worked at didn't roll Novell servers because it's Novell, but because it's a stable directory management/resource sharing appliance. They could care less what kernel us under the hood, as long as it remains easy to administer and stable.
As Novell was rather pro-active in favour of defending Linux, I think it's rather rude to associate them as being behind the SCO crap.
Novell is just showing they are still a company that "gets it" technically. Why pay some obscene amount to support and develop a proprietary file sharing OS when the main thing customers buy their products for is directory management?
Sure people use Novell file/print sharing servers as well, but that's mainly because it's an appliance OS that integrates well with the directory management they want. They could care less about the underpinnings of that appliance OS as long as it does the job with reasonable performance.
When is the last time you've seen any applications built for the Novell OS core? That being the case, why would you care what OS API they have under the hood?
I always thought that people gullible/uneducated enough to fall for spam would also be too uneducated to run a computer well enough to handle the email in the first place.
Guess we've done too good a job of making them easy to use...
So you're saying that because lawyers are overpaid, they are justified in overcharging their clients? No wonder the RIAA and MPAA like you guys so much.
SCO's latest "threats" to RedHat and Linux are nothing more than the continuation of unsupported, undocumented, unproven FUD.
Time for them to get off the pot and present the evidence, and face the inevitable stock-manipulation and insider-trading charges.
In the unlikely chance that SCO wins before I win the lottery or am struck by lightning, I'll just be redeploying with a BSD instead of SCO.
And if they go after BSD, I'll shift to Plan9 or QNX rather than giving one thin dime to the leeches running SCO.
Should those get nailed, GNU should finally have a decent "Hurd" kernel running by then (15-20 years of lawsuits.)
Not a 20 lawyer firm, a 20 person firm.
If you need 20 lawyers, you're all freakin' incompentant.
Maybe that was a G- or H-series AIX box. It was brand spankin' new about 4 years ago, one of the first from the factory.