I think this bit is wrong, Ultra 5s take 50ns 168-pin JEDEC DIMMs, ECC error-correction. In fact I'll stick my neck out and say all Sun machines take ECC RAM only... Perhaps what threw you was that they don't even take SDRAM (it's what I used to call EDO FPRAM I think).
I stand corrected. Clearly the sun boxen have ECC ram.
The TPC-C benchmark as a whole has problems as well. IBM's latest machines have kick-ass scores on TPC-C (200%+), but in deployment are only marginally faster than Sun's high-end hardware (30%, compared with the 900 MHz UltraSPARC III). (As a consultant I was involved in a performance comparison of the PeopleSoft Financials suite running on IBM vs Sun).
I see your point; 30% is not that major. But processor performance is not the largest factor in commercial workload performance. The memory subsystem and disk subsystem are each at least as important as the processor on commercial workloads. Witness that in the top tpc scores, the disk subsystems are far more expensive than the servers themselves, often with thousands of disks in parallel. Sun still has substantial experience in system-building and in this regard Sun is the equal of IBM or HP. Even if Sun's processors are less than 50% of the speed of IBM's this clearly would lead to far less than 50% overall performance degradation, perhaps less than 30%.
Regarding your 'throughput' computing remark, just think webservers and telcos, all they care about is throughput at minimum cost. Itaniums are a lot less efficient than Xeons if you are interested in throughput computing. If Sun has some in-house technology they can use for efficient throughput computing that WOULD be big.
"Throughput computing" refers to a specific Sun initiative by that name. Sun intends to design CPUs in a radically new way, by placing 16+ small processor cores on a single die, each of which can execute a separate thread or process. Each of these small cores is individually unimpressive but combined they will outrun any other CPU (supposedly). These 16+ cores are each extremely small and will all fit on a processor die the same size as a single itanium2. This offers several advantages. First, parallelism is mostly thread-level, therefore the logic for exploiting parallelism can be done by the compiler. Second, such a CPU is easier to design. Anyway, that's the idea; I hope it works out.
I find it strange that Red Hat's stock is higher than Sun's and yet Sun brings in billions every quarter and has 6.6 billion in the bank. I think it says a lot about the relavance of using stock prices as a note for discussion.
No offense, but from this I'd assume that you're not an expert at the Stock Market. Stock price is not comparable between companies unless both companies have the same number of outstanding shares. A theoretical company worth only $1 million would have a stock price of $333,333 if it had issued only 3 shares (of course this doesn't happen, it's an illustration).
"For years, Sun has hidden its performance-poor servers behind its Solaris operating system."
Please, tell us about your experience with Sun. Have you administered it and if so for how long? Are you a user and if so for how long?
I've been using Sun boxes for 7+ years. Their performance used to be slightly inferior but comparable. Now their performance is significantly worse. The UltraSparc III was a substantial design failure, with a 14-stage 4-issue IN-ORDER design at 1GHz, compared to competitors that have shorter pipelines, far higher clock frequencies, more units, more parallelism, and OUT-OF-ORDER designs. Sun's CPU is the last RISC CPU that's still an in-order design, something which by itself can affect commercial performance by more than 40%. Now, Sun's boxes are inferior in performance by a substantial margin.
Sun hasn't submitted a TPC-C benchmark since late 2001, and it was on old hardware. This may or may not be a good thing, but you cannot tell.
Sun withdrew from the TPC-C benchmark because they were trailing their competitors by a widening margin. They publically admitted as much.
Your post is nothing more than the often repeated "Sun is dying" chant that is not backed up by any relavant facts.
Sun is obviously not facing any kind of short-term crisis. But there's a growing consensus that Sun is becoming increasingly incapable of designing and manufacturing competitive high-end Sparc CPUs to power their servers. Intel and IBM are producing much better designs and have access to far better process technology, and there's the perception that this gap is likely to widen over time. Given this situation, Sun will gradually fade into oblivion, or at least that's what some people are assuming. Of course, Sun might pull a "rabbit out of the hat" with this throughput computing thing; we'll have to see.
One word: Quality Would you trust your mission critical application to some cheap Intel chip with bog standard non-parity DDRAM and low quality components?.. x86 might be cheap, but if you want hardware you can really rely on that's going to operate without problems for years, you buy a Sun box.
I've had sun boxes on my desk for years, and from what I've seen, this hasn't been true for quite some time. If you opened up a Sun Ultra5 you'd find that it was made almost entirely out of low-end commodity components. The drive was a Seagate IDE drive, the power supply was relatively cheap, the graphics chipset was ATI/rage, and although the RAM was nonstandard it wasn't ECC and it wasn't superior in quality. For a comparable price you could get an x86 box with far more reliable SCSI drives, and with redundant high-quality power supplies, and with ECC RAM. Such a box would be far more reliable (and far faster, incidentally) than the comparably priced Sun workstation.
Of course it's a different issue entirely when you enter the arena of servers, where Sun still has many reliability features not found on any x86 boxes. But in the server arena, Sun is competing against HP and IBM, both of which make sturdier equipment than Sun. Although all 3 unix makers offer vastly superior equipment to what you'd get from, say, Dell.
I HONESTLY want to know, what is the point now of buying a non-x86 and non-PowerPC workstation.
There's still a large body of software for engineering and scientific disciplines that runs only on Sparc/Solaris. This software and userbase are left over from the days when RISC machines were far faster than x86 machines.
Everyone is moving away from Sun workstations, but these migrations take time. Notice that Sun's hardware sales are down 20% year-on-year. Sun already realizes that its workstation business is doomed in the long run.
Sun is going to make a valiant attempt to rescue it's high-end server business by employing a radically different approach to MPU design -- "throughput computing." Sun hopes that this new approach will allow it to surpass the performance of Itanium or POWER boxes on commercial workloads. If "throughput computing" turns out not to be everything it's cracked up to be, then the Sun/Solaris platform is doomed and Sun will have to transition to a different business model, perhaps becoming an enterprise software company.
You claim that "mechanization does not permanently increase unemployment, because it creates new jobs at the same rate it destroys them." But what is your basis for this statement? It certainly isn't true for every innovation.
What is my basis for that statement? I adequately documented my basis in the post itself, with reasoning and historical examples. Also the same is said in any number of good economics books.
I'm not sure where you've been during the past three years, but things haven't been this bad in the USA since the Great Depression, and they're getting worse, not better.
The great depression was vastly worse than this. Various other recessions since then have been worse than this. Things have been staying about the same, not getting worse.
And this is largely due to increased productivity through automation of jobs.
The current recession has nothing to do with increased automation. Almost all jobs lost in the last few years have been due to overseas outsourcing and the current downturn is the result of a stock market bubble collapsing.
It all comes down to this - computers and robots are radically different from previous labor-saving inventions. Other types of machines don't double in power every 18 months, and they aren't nearly as adaptable and configurable.
Robots are fundamentally the same as previous labor-saving devices, from an economic perspective. 80% of the population in the 18th century used to be farmers. The tractor and improved agriculture ruled 79% of the entire population obsolete.
The extent to which computers have transformed society over the last 30 years is breathtaking and unprecedented in human history.
The first half of the 20th century was substantially more breathtaking than the latter half. Machine production and the assembly line created far more massive societal transformation ever than computers have thus far.
And with Moore's law in effect, the rate of job elimination will remain significantly higher, and you'll have a constantly deteriorating economy as more and more people become unemployed.
Moore's law does not say that job elimination will remain higher than job creation. Moore's law has been in effect for 30 years and thus far it hasn't destroyed employment; instead it's created vast new industries with millions of new employees and trillions of dollars in market capitaliztion. Improved technology helps the economy; it doesn't hurt it! If improved technology hurt the economy, we could easily remedy the problem by just destroying all technology and reverting back to hunter-gathering. You would find that this solution does not help the economy so much as anticipated.
Working conditions for those who remain employed will deteriorate as well, because most industries will be in a state of constant rounds of layoffs, so there will be a large group of qualified applicants for any given position. Employees will always have this hanging over their heads and employers will use the situation to their benefit.
All industries have always been in a constant state of layoffs followed by re-hirings of different people. Some industries lay off more than are hired, but other industries hire more than are laid off. This has not led to a deterioration of working conditions, but the opposite. Qualified people have always been scarce and there's every reason to believe that they will be scarcer still in the future, at least in most industries.
After many iterations of this process, here are two possible (albeit extreme) outcomes: 1) a socialized economy where the machines are collectively owned by the population and used for everyone's benefit or 2) a capitalist economy where the machines are owned by the wealthiest 1% and the remaining 99% are kept at subsistence level, or sent to kill each other in wars. Which one should be aiming for?
That is a ridiculous false dilemma, since neither of
N0 (R16K) was a big redesign, the begining of a new line, and N1 and N2 will be all new designs.
This is false. The r16k was not a fundamentally new design; it's based entirely on the r10k and is a 4-issue 5-unit design, just like the r10k. Here is a quote from the "SGIstuff" website, which is heavily biased in favor of MIPS: "Like the R12000 and R14000 the R16000 CPU is an enhanced version of the R10000 architecture." What you said about the N1 and N2 was also false; they're nothing more than minor tweaks of the current inadequate r10k core. The N1 is an r16k with a process shrink, an additional load/store unit, and the cache moved on-die. The N2 will likely be the same sort of thing (another process improvement?) but perhaps with 2 cores on die.
SGI bought and merged with MIPS in 1992. They then designed T5 (R10K) in 1994-5. They spun-off the embeded section of MIPS in 1998. SGI still retains their own MIPS development team and are actively working on several processors. Remember MIPS is an open platform, anyone can get a license and make chips.
This is true very misleading. SGI bought but did not merge with MIPS. The development of a modern CPU from scratch could cost hundreds of millions of dollars which is more than SGI is worth. Sun employs 4,000 on Sparc development which is as many as work at SGI altogether. It's extremely unlikely that SGI will ever again release a genuinely new core.
You've also skewed those SPECfp numbers.
I haven't skewed anything. I cut-and-pasted from the spec.org website.
R14K is supported in many systems and you chose to quote the slowest system.
Dude did you even go read the data before posting that? I absolutely did not quote the slowest system; I was being generous and quoted the very fastest MIPS system that SGI offers according to their posted SpecCPU scores. Not only was your pronouncement false, it was the diametric opposite of the truth.
Also the R14000A is an older CPU and the Itanium2 is just newly released. More fair would be to quote numbers for the new MIPS CPUs, unfortuneately they're unavailable.
The benchmark I quoted for the MIPS line had been conducted only ten months ago. Not to mention the r16k core is nearly identical to the r14k in many respects. Both Sun and SGI no longer post various benchmark scores because it's too embarrassing for them. Sun even admitted publically that such was the reason for no longer posting benchmark scores.
But then it would also pay to step back and realize that the current SPEC CPU benchmarks have several flaws, being most noteably used by SUN, which render them unreliable.
Sun has a compiler optimization that helps dramatically with one of the subtests of the SpecFP benchmark. Compiler optimizations are entirely legal since SpecCPU claims to benchmark the CPU/memory/compiler combination.
So you can quote SPEC left and right, the plain facts come back to applications performance. And for most of my apps the SGI systems are the fastest and most scaleable prepackaged computers you can buy.
In graphics apps SGI systems may have adequate performance but this hardly exonerates the MIPS processors, since most of graphics work is handled by the graphics subsystem. I had SGI workstations for years and even 4 years ago they were vastly outrun on everyday apps by commodity equipment at a fraction of the cost.
Increasing mechanization never increases unemployment. A simple example can illustrate why. Suppose you have a group of people who manually sew sweaters. A machine is introduced that can do the work of 3 sewers for less money, so all the sewers are replaced and thrown out of their jobs. Already we have 100% unemployment among sweater sewers. Supposedly, at this rate, soon nobody will have a job. But now two other things have happened. First, the sweater-sewing machine has to be manufactured and repaired, leading to new jobs that didn't exist before. Second, the cost of manufacturing a sweater has dropped by 2/3rds, so there are new dollars floating around in the economy that weren't there before because they would have otherwise been spent on sweaters. With the money saved from a 2/3rds drop in the prices of sweaters, people can now buy an additional television or visit a shrink twice as often. Thus the other markets (televisions or psychiatry) expand their employment precisely as much as sweater-making had declined. This is why 95% of jobs have been eliminated since the 18th century, but almost everyone is still employed.
Insofar as I can tell, the author of the article is unaware of this. Some interesting economic facts:
Mechanization does not permanently increase unemployment, because it creates new jobs at the same rate it destroys them.
Destruction of industries is necessary for economic advance, otherwise all the investment capital would be tied up in obselete industries. Suppose we prevented slide-rule manufacturers from going under and laying people off, and those people were still paid and factories for slide-rule-making were still constructed. We would be poorer not richer and the level of employment would be approximately the same.
The same argument against machines can be used against any form of productivity increase. Every increase in productivity temporarily throws someone out of a job. Even the invention (10,000 years ago) of the use of animal power to carry something threw out of a job the people who had carried it on their backs. Strangely, this productivity enhancement has been going on since the dawn of civilization, and still most people are employed.
The principle implied here is a fundamental principle of economic growth: productivity increase, followed by temporary unemployment, followed by re-employment and the general enrichment of the economy. This is the sole reason we make $30k/yr in this country (on average) rather than the $500/yr that was typical until the 18th century.
What's shocking to me is that the author of the article apparently doesn't have the slightest notion how capitalism works or how economic growth occurs. This despite the fact that he lives in a capitalist country and is apparently well-educated. Sometimes it amazes me that this country works as well as it does.
That is BS. Show me where at www.specbench.org there are results for a 2GHz PPC970 using an IBM compiler.
Not every benchmark result in the world can be found at specbench.org. Not even all SpecCPU benchmark results can be found at specbench.org. Preliminary results of various benchmarks (including SpecCPU) for the PPC970 using IBM's compiler were announced at a conference. Additionally I read about it (from someone else who attended) at realworldtech.com.
IBM already shoulders the enormous design costs of POWER4 for their high-end pSeries unix boxes. The tweaks necessary to make the PPC 970 for Apple have already been done at Apple's behest. It costs IBM very little additional R&D money to make low-end servers based on a chip they already design and manufacture for other reasons.
This makes PPC the only competitor to x86 in the commodity server space, except Sun, but Sun's product lineup grows more stale and outclassed by the day. Using IBM's compiler the 2GHz PPC970 performs approximately equivalently to a 2.8GHz p4 using icc, which is far beyond the performance offered by the in-order execution (!!) 1.05 GHz UltraSparc iii.
Having an alternative to x86 in the server space is desirable, because PPC will always have better heat dissipation and power consumption at a given level of performance. These are important considerations especially in the blade server market. In addition these are 64-bit boxes which will allow going beyond the 4GB memory barrier without using the "segmented memory" hack of the 36-bit memory addressed Xeons.
The R16K was NEVER intended for the embeded market. BUt of course you have no idea what you are talking about, the MIPS R14/16/18K come from the SGI MIPS side of things not the spun off MIPS Computer side of things those are the guys doing all the embeded stuff.
Fool, the R16k was based on the R10k core which was designed by MIPS not SGI; SGI doesn't even have a CPU development team any more and doesn't even own the trademark for r16k. The R16k was a "tweak" of the R10k core by _MIPS_.
But of course lack of knowledge never stopped you from posting arbitrary spec numbers pulled out of hte thing air...
Dude, you can check out the numbers on spec.org if you can figure out how to use a browser:
What a load of old twaddle. Most current embedded MIPs processors are based upon the R42XX architecture. They are fast enough for what you need them for (300 mips) and they don't cooked you hardware when not fitted with a fan.
The R16K is based on the R10K core, NOT the R4k core as you claim.
(It's difficult to believe that parent got modded up to 5. Time to start meta-moderating again...)
The cold, unpleasant truth here, is that 90% of IT isn't worth its salary.
Huh? Then why precisely do companies pay them that much in the first place if they aren't "worth" it and the company can't recoup the costs?
It takes time, but eventually, everyone gets paid what they're actually worth as opposed to what they think they're worth.
People used to get paid what they think they're worth? Did employment applications have a box saying "write what you think you should get paid here" and the employers would pay it?
The secret is to make yourself worth more.
Dude the difficulty is that they're exporting the jobs to economies where tech workers make $5/hr. It has nothing to do with acquiring some new skill; as long as an Indian or Chinese can acquire it, the job will still be moved overseas.
Probably a meaningless admonition to most slashdotters who think that the world owes them a living so they can spend all their time downloading files from Kazaa.
You are a slashdotter; you are insulting yourself.
...Salaries have never had anything to do with how much you're worth, unless "worth" is defined solely in terms of market forces like demand. As such you cannot control it. If your job suddenly is automatable then you are laid off regardless of how much you previously were worth.
I think it was spec.org who did some test a few years ago comparing the 400mhz MIPS and a 1GHz AMD/Intel and found that the MIPS had about 70% of the computing power to the AMD/Intel, but when You put this in a multiprocessor machine (4 I think) the MIPS was 120% to the AMD/Intel and when scaled up even further(16-32), AMD/Intel wasn't even on the charts.
This was probably due to a superior memory fabric in the SGI machine, since AMD/Intel SMP boxes were (back then) simple shared-bus devices. The AMD/Intel boxes were "not even on the charts" because there were no 16-32 way x86 boxes back then.
No, SGI has NOTHING to be ashamed of when it comes to their MIPS.
SGI has a GREAT DEAL to be ashamed of when it comes to MIPS. The R16k was designed for the embedded market and is not competitive in performance with other CPUs. It loses even to mass-market CPUs like Intel & AMD. It loses embarrassingly to its RISC competition, regularly posting SpecFP scores that are 1/4th or less that of POWER4 or Itanium2.
The biggest difficulty I can forsee is not the decline in programming jobs, but the decline in skilled careers altogether, because of losses to overseas. The prospect of re-training doesn't bother me so much. But re-train to do what? Accounting? Law? Engineering? DBA work? Manufacturing? Research? All of these careers will move to foreign shores. Graphic Design? Even graphic design is being shipped overseas -- "The Simpsons" is now drawn by people in Thailand for $1/hr!
Nothing remains! I have no idea what skill to acquire. The only career for which there's brisk demand is NURSING. That can't be shipped overseas, not even a portion of it. I have no desire -- NONE -- to be a nurse. I suppose I could sell clothes at the Gap to people who no longer can afford to shop there.
The state of Java now is pure and simply...just bloat... A simple C# hello world program uses 11 Meg!... I'm a systems programmer, I write applications that load, do what they need to do as fast as possible, then completely unload and get out of the way.
Java is used for writing large-scale backend enterprise applications, not small command-line utilities. Nobody is suggesting it as a replacement for perl. With the programs Java is used for, startup time is irrelevant (since it's only started once) and a 50 meg overhead is insignificant.
We had a great programming language called C, and C++ that got pushed to the back-burner because of some people who decided that garbage collection and VM's were a "good thing".
C++ wasn't a "great" programming language, it was a syntactic disaster. C is decent for systems programming but still has its defects.
Well, maybe they are, but at the expense of expertise in programming? I'm so tired of programming environments that keep people from shooting themselves in the foot, or coddle beginning coders.
This is one attitude that has to be guarded against. Unfortunately, there is a class of people who wrongly call themselves "real programmers." They try to prove their machismo by purposefully avoiding modern techniques, and by doing things in a primitive and difficult way. These programmers overestimate their skills, because they produce unreadable, unportable, bizarre, buggy code that has marginal or nonexistent performance benefits.
Manual manipulation of pointers causes a 50% increase in bug count, and that's when they're being used by experienced C programmers. When C programmers can write large-scale applications that have no pointer bugs at all, right from the start, then I'll favor letting the "real" programmers have free reign.
I mean come on, if you can't handle pointers, can you really call yourself a programmer?
Programming exists to accomplish real-world tasks while meeting abstract design criteria, like code readability. It doesn't exist to dereference pointers, twiddle bits, or shift things around in Unions.
At present, the principal performance bottleneck of a relational database is disk seek time. Since disks have disastrous seek times, database servers often have an incredible number of disks (hundreds or more), in order to have those disks seeking in parallel, thereby mitigating disastrous seek times of individual disks.
These hundreds of disks often have very little on them. The purpose of having lots of disks isn't for more storage, but for more drive heads, because lots of heads can be seeking in parallel. Oftentimes, OLTP databases aren't even that large, and most of the space on the disks is unused.
RAM has a seek time (latency) that is about 1/10,000th that of disk. Since latency is the primary bottleneck, this could vastly improve the speed of databases. And database servers could become cheaper, since all those unnecessary (and unfilled) disks, used just for parallel disk seeks, could be thrown away.
The difficulty with RAM is that it loses its data after you turn off the power. This is the reason disks are still used for databases. Losing any data because of power loss would not be acceptable to any financial institution. Battery backups etc would never be deemed sufficient.
The moment we have RAM that retains data despite power loss, disks will no longer be used in database servers. This will be true even if such RAM is vastly more expensive than the disks they replace, because the RAM would be 10,000x as fast and so would render unneccessary the huge number of "redundant" disks kept around simply so data can be read in parallel from multiple disks.
"Flash RAM" and other current nonvolatile memory technologies will not suffice, for several reasons. First, they can only be written a limited number of times before failure. Second, their write speeds are very low, and OLTP databases are write-intensive.
There are components of ACIDity that would be implmented very differently for RAM-persistent databases than for disk-persistent ones. Maintaining ACIDity on disk-persistent databases requires complicated algorithms to mitigate the disatrous disk seek times. These complicated algorithms would be rendered unnecessary if disks were no longer used.
For example, disks have incredibly slow seek times and much better bandwidth; therefore it's far cheaper to write things to disk in big chunks. The purpose of write-ahead logging (or "redo logging") is to mitigate the performance impact of slow seek times by blasting all the transactions to disk at once, in the redo log, thereby avoiding the slow seeks that would be required by putting each transaction in its proper place. Putting the transaction data in its proper place is deferred until after the load has died down somewhat. This could be seen as exchanging seek times for bandwidth.
This redo log mechanism would be unnecessary for ram-persistent databases. It's a significant source of complexity that would be obviated by the removal of disks. And that's just one example of complexity required to get adequate performance from disk, a medium that has disastrously slow seek times.
Screening for homosexuals -- already been done!
on
Brain Privacy
·
· Score: 3, Interesting
Strangely enough, something like this has already been done. The military investigated a series of devices that measure sexual attraction, in order to screen out homosexuals. The idea was that they could put new male recruits in front of mostly-undressed pictures of athletic young men, then measure the level of sexual excitation, and screen out the homosexuals.
By the way, one of the devices used to measure sexual excitation was called a "Penile Photoplathismograph". It measures blood flow to the sexual organ, and most youngish men can't help but get a little bit of an erection when exposed to a picture of a naked attractive potential sex object.
ANYWAY, the idea was abandoned, for two reasons. First, some of the extremely homophobic people could not pass the test themselves. This grants some credence to the notion that angrily homophobic people are sometimes having some kind of internal conflict. Second, people who are "bisexual" to some extent greatly outnumber people who are outright gay. Although men who are exclusively homosexual make up 1-2% of the population, people who will evince at least some attraction to members of the same sex make up 5-6% of the population. Kicking out 6% of the military would be a problem.
This actually has some research in psychology to support it.
Women consistently perform much better at certain verbal tasks. For example, when confronted with a question like "find ten synonyms for word x", women will be able to answer it in far less time than men on average.
Women consistenly perform much worse at visual-spatial tasks like rotating three-dimensional objects in their minds.
I took a test in a psych class which had both verbal and visual/spatial questions on it. It could determine your gender based on your scores on those two scales. It worked pretty well; it seemed that 90% of the people in the class had their gender accurately identified.
Of course, it is a statistical average only; some women are better than men at visual/spatial tasks. And, it's not known whether the difference is genetic or as a result of environmental influences (boys are given blocks to play with as children, after all).
There is no scientific support for statements like "this is because men were hunters in primitive societies." This may be true, but sociobiologists make tons of essentially random speculations and are able to prove almost none of it.
I read the post. Even when Oracle databases are fully cached in RAM, all transactions are still written to disk. Oracle never reports that a transaction has been committed until it has at least been entered into the redo logs. This is because Oracle is a durable data store."Cached in ram" applies to read queries, not insertions/modifications.
OK, I'll bite. Someone has claims of a durable data store that's 9000 times faster than Oracle, by using the equivalent of a "redo log."
That should immediately make everyone extremely skeptical! The redo log is hardware dependent: the limiting factor in performance is the bandwidth of disk! A redo log is already streaming; they've already factored out head seek time. It's impossible to get 9,000 times the performance with a durable data store! A 50% performance improvement would be difficult to believe.
The guy who wrote the article is 19 years old and claims "8 years programming experience" or something like that. HMMMM.... Getting a pc for your 11th birthday counts as programming experience.
So I figured: this guy thinks he's writing his redo log to disk, but actually the OS is caching it. When he thinks he's writing to disk, he actually writes to memory.
So I downloaded the source code and read through it. He tries to sync the disks by calling "outputStream.flush()". That method doesn't do what he thinks it does! It flushes the JAVA BUFFERS inside Java classes like BufferedOutputStream. It does NOT flush the data to disk. They think they're writing to disk, but they aren't. In short, this data store is not durable. The only reason they think it gets 9,000 times the performance of Oracle, is because they don't understand what their program is doing.
Moral of the story: be a bit skeptical when someone claims 9,000 times better performance than Oracle. 9,000 faster is approximately how much faster RAM is than disk (strange coincidence).
Back when I was a teenager, my friends and I got Commodore 128's. Those machines had these incredibly tiny "reset" buttons, which required a pencil or something to press, that way you couldn't accidentally hit 'reset.' Anyway a friend of mine was playing a video game and became very angry and wanted to reset the computer right then, but his finger wouldn't fit into the hole of the reset button. Out of anger, he took this modem card and jammed it into the port on the back of the machine (the "user bus"). This caused the machine to reset. Thereafter, this was his preferred method of resetting the machine. It never damaged the machine.
"You miss the point...Salon has new content pretty much *every day*....the mags. you cite come out just once per month. Apples and oranges here."
Salon releases a single new article every day, rather than a bunch of them all at once at the end of the month. Salon just staggers their content release. It's an advantage of online mags.
In all, it appears to me that Salon has about the same amount of content as any of the monthly magazines.
Slashdot Mirror
I think this bit is wrong, Ultra 5s take 50ns 168-pin JEDEC DIMMs, ECC error-correction. In fact I'll stick my neck out and say all Sun machines take ECC RAM only... Perhaps what threw you was that they don't even take SDRAM (it's what I used to call EDO FPRAM I think).
I stand corrected. Clearly the sun boxen have ECC ram.
I see your point; 30% is not that major. But processor performance is not the largest factor in commercial workload performance. The memory subsystem and disk subsystem are each at least as important as the processor on commercial workloads. Witness that in the top tpc scores, the disk subsystems are far more expensive than the servers themselves, often with thousands of disks in parallel. Sun still has substantial experience in system-building and in this regard Sun is the equal of IBM or HP. Even if Sun's processors are less than 50% of the speed of IBM's this clearly would lead to far less than 50% overall performance degradation, perhaps less than 30%.
Regarding your 'throughput' computing remark, just think webservers and telcos, all they care about is throughput at minimum cost. Itaniums are a lot less efficient than Xeons if you are interested in throughput computing. If Sun has some in-house technology they can use for efficient throughput computing that WOULD be big.
"Throughput computing" refers to a specific Sun initiative by that name. Sun intends to design CPUs in a radically new way, by placing 16+ small processor cores on a single die, each of which can execute a separate thread or process. Each of these small cores is individually unimpressive but combined they will outrun any other CPU (supposedly). These 16+ cores are each extremely small and will all fit on a processor die the same size as a single itanium2. This offers several advantages. First, parallelism is mostly thread-level, therefore the logic for exploiting parallelism can be done by the compiler. Second, such a CPU is easier to design. Anyway, that's the idea; I hope it works out.
No offense, but from this I'd assume that you're not an expert at the Stock Market. Stock price is not comparable between companies unless both companies have the same number of outstanding shares. A theoretical company worth only $1 million would have a stock price of $333,333 if it had issued only 3 shares (of course this doesn't happen, it's an illustration).
"For years, Sun has hidden its performance-poor servers behind its Solaris operating system."
Please, tell us about your experience with Sun. Have you administered it and if so for how long? Are you a user and if so for how long?
I've been using Sun boxes for 7+ years. Their performance used to be slightly inferior but comparable. Now their performance is significantly worse. The UltraSparc III was a substantial design failure, with a 14-stage 4-issue IN-ORDER design at 1GHz, compared to competitors that have shorter pipelines, far higher clock frequencies, more units, more parallelism, and OUT-OF-ORDER designs. Sun's CPU is the last RISC CPU that's still an in-order design, something which by itself can affect commercial performance by more than 40%. Now, Sun's boxes are inferior in performance by a substantial margin.
Sun hasn't submitted a TPC-C benchmark since late 2001, and it was on old hardware. This may or may not be a good thing, but you cannot tell.
Sun withdrew from the TPC-C benchmark because they were trailing their competitors by a widening margin. They publically admitted as much.
Your post is nothing more than the often repeated "Sun is dying" chant that is not backed up by any relavant facts.
Sun is obviously not facing any kind of short-term crisis. But there's a growing consensus that Sun is becoming increasingly incapable of designing and manufacturing competitive high-end Sparc CPUs to power their servers. Intel and IBM are producing much better designs and have access to far better process technology, and there's the perception that this gap is likely to widen over time. Given this situation, Sun will gradually fade into oblivion, or at least that's what some people are assuming. Of course, Sun might pull a "rabbit out of the hat" with this throughput computing thing; we'll have to see.
One word: Quality Would you trust your mission critical application to some cheap Intel chip with bog standard non-parity DDRAM and low quality components?.. x86 might be cheap, but if you want hardware you can really rely on that's going to operate without problems for years, you buy a Sun box.
I've had sun boxes on my desk for years, and from what I've seen, this hasn't been true for quite some time. If you opened up a Sun Ultra5 you'd find that it was made almost entirely out of low-end commodity components. The drive was a Seagate IDE drive, the power supply was relatively cheap, the graphics chipset was ATI/rage, and although the RAM was nonstandard it wasn't ECC and it wasn't superior in quality. For a comparable price you could get an x86 box with far more reliable SCSI drives, and with redundant high-quality power supplies, and with ECC RAM. Such a box would be far more reliable (and far faster, incidentally) than the comparably priced Sun workstation.
Of course it's a different issue entirely when you enter the arena of servers, where Sun still has many reliability features not found on any x86 boxes. But in the server arena, Sun is competing against HP and IBM, both of which make sturdier equipment than Sun. Although all 3 unix makers offer vastly superior equipment to what you'd get from, say, Dell.
There's still a large body of software for engineering and scientific disciplines that runs only on Sparc/Solaris. This software and userbase are left over from the days when RISC machines were far faster than x86 machines.
Everyone is moving away from Sun workstations, but these migrations take time. Notice that Sun's hardware sales are down 20% year-on-year. Sun already realizes that its workstation business is doomed in the long run.
Sun is going to make a valiant attempt to rescue it's high-end server business by employing a radically different approach to MPU design -- "throughput computing." Sun hopes that this new approach will allow it to surpass the performance of Itanium or POWER boxes on commercial workloads. If "throughput computing" turns out not to be everything it's cracked up to be, then the Sun/Solaris platform is doomed and Sun will have to transition to a different business model, perhaps becoming an enterprise software company.
You claim that "mechanization does not permanently increase unemployment, because it creates new jobs at the same rate it destroys them." But what is your basis for this statement? It certainly isn't true for every innovation.
What is my basis for that statement? I adequately documented my basis in the post itself, with reasoning and historical examples. Also the same is said in any number of good economics books.
I'm not sure where you've been during the past three years, but things haven't been this bad in the USA since the Great Depression, and they're getting worse, not better.
The great depression was vastly worse than this. Various other recessions since then have been worse than this. Things have been staying about the same, not getting worse.
And this is largely due to increased productivity through automation of jobs.
The current recession has nothing to do with increased automation. Almost all jobs lost in the last few years have been due to overseas outsourcing and the current downturn is the result of a stock market bubble collapsing.
It all comes down to this - computers and robots are radically different from previous labor-saving inventions. Other types of machines don't double in power every 18 months, and they aren't nearly as adaptable and configurable.
Robots are fundamentally the same as previous labor-saving devices, from an economic perspective. 80% of the population in the 18th century used to be farmers. The tractor and improved agriculture ruled 79% of the entire population obsolete.
The extent to which computers have transformed society over the last 30 years is breathtaking and unprecedented in human history.
The first half of the 20th century was substantially more breathtaking than the latter half. Machine production and the assembly line created far more massive societal transformation ever than computers have thus far.
And with Moore's law in effect, the rate of job elimination will remain significantly higher, and you'll have a constantly deteriorating economy as more and more people become unemployed.
Moore's law does not say that job elimination will remain higher than job creation. Moore's law has been in effect for 30 years and thus far it hasn't destroyed employment; instead it's created vast new industries with millions of new employees and trillions of dollars in market capitaliztion. Improved technology helps the economy; it doesn't hurt it! If improved technology hurt the economy, we could easily remedy the problem by just destroying all technology and reverting back to hunter-gathering. You would find that this solution does not help the economy so much as anticipated.
Working conditions for those who remain employed will deteriorate as well, because most industries will be in a state of constant rounds of layoffs, so there will be a large group of qualified applicants for any given position. Employees will always have this hanging over their heads and employers will use the situation to their benefit.
All industries have always been in a constant state of layoffs followed by re-hirings of different people. Some industries lay off more than are hired, but other industries hire more than are laid off. This has not led to a deterioration of working conditions, but the opposite. Qualified people have always been scarce and there's every reason to believe that they will be scarcer still in the future, at least in most industries.
After many iterations of this process, here are two possible (albeit extreme) outcomes: 1) a socialized economy where the machines are collectively owned by the population and used for everyone's benefit or 2) a capitalist economy where the machines are owned by the wealthiest 1% and the remaining 99% are kept at subsistence level, or sent to kill each other in wars. Which one should be aiming for?
That is a ridiculous false dilemma, since neither of
N0 (R16K) was a big redesign, the begining of a new line, and N1 and N2 will be all new designs.
This is false. The r16k was not a fundamentally new design; it's based entirely on the r10k and is a 4-issue 5-unit design, just like the r10k. Here is a quote from the "SGIstuff" website, which is heavily biased in favor of MIPS: "Like the R12000 and R14000 the R16000 CPU is an enhanced version of the R10000 architecture." What you said about the N1 and N2 was also false; they're nothing more than minor tweaks of the current inadequate r10k core. The N1 is an r16k with a process shrink, an additional load/store unit, and the cache moved on-die. The N2 will likely be the same sort of thing (another process improvement?) but perhaps with 2 cores on die.
SGI bought and merged with MIPS in 1992. They then designed T5 (R10K) in 1994-5. They spun-off the embeded section of MIPS in 1998. SGI still retains their own MIPS development team and are actively working on several processors. Remember MIPS is an open platform, anyone can get a license and make chips.
This is true very misleading. SGI bought but did not merge with MIPS. The development of a modern CPU from scratch could cost hundreds of millions of dollars which is more than SGI is worth. Sun employs 4,000 on Sparc development which is as many as work at SGI altogether. It's extremely unlikely that SGI will ever again release a genuinely new core.
You've also skewed those SPECfp numbers.
I haven't skewed anything. I cut-and-pasted from the spec.org website.
R14K is supported in many systems and you chose to quote the slowest system.
Dude did you even go read the data before posting that? I absolutely did not quote the slowest system; I was being generous and quoted the very fastest MIPS system that SGI offers according to their posted SpecCPU scores. Not only was your pronouncement false, it was the diametric opposite of the truth.
Also the R14000A is an older CPU and the Itanium2 is just newly released. More fair would be to quote numbers for the new MIPS CPUs, unfortuneately they're unavailable.
The benchmark I quoted for the MIPS line had been conducted only ten months ago. Not to mention the r16k core is nearly identical to the r14k in many respects. Both Sun and SGI no longer post various benchmark scores because it's too embarrassing for them. Sun even admitted publically that such was the reason for no longer posting benchmark scores.
But then it would also pay to step back and realize that the current SPEC CPU benchmarks have several flaws, being most noteably used by SUN, which render them unreliable.
Sun has a compiler optimization that helps dramatically with one of the subtests of the SpecFP benchmark. Compiler optimizations are entirely legal since SpecCPU claims to benchmark the CPU/memory/compiler combination.
So you can quote SPEC left and right, the plain facts come back to applications performance. And for most of my apps the SGI systems are the fastest and most scaleable prepackaged computers you can buy.
In graphics apps SGI systems may have adequate performance but this hardly exonerates the MIPS processors, since most of graphics work is handled by the graphics subsystem. I had SGI workstations for years and even 4 years ago they were vastly outrun on everyday apps by commodity equipment at a fraction of the cost.
Insofar as I can tell, the author of the article is unaware of this. Some interesting economic facts:
The principle implied here is a fundamental principle of economic growth: productivity increase, followed by temporary unemployment, followed by re-employment and the general enrichment of the economy. This is the sole reason we make $30k/yr in this country (on average) rather than the $500/yr that was typical until the 18th century.
What's shocking to me is that the author of the article apparently doesn't have the slightest notion how capitalism works or how economic growth occurs. This despite the fact that he lives in a capitalist country and is apparently well-educated. Sometimes it amazes me that this country works as well as it does.
That is BS. Show me where at www.specbench.org there are results for a 2GHz PPC970 using an IBM compiler.
Not every benchmark result in the world can be found at specbench.org. Not even all SpecCPU benchmark results can be found at specbench.org. Preliminary results of various benchmarks (including SpecCPU) for the PPC970 using IBM's compiler were announced at a conference. Additionally I read about it (from someone else who attended) at realworldtech.com.
IBM already shoulders the enormous design costs of POWER4 for their high-end pSeries unix boxes. The tweaks necessary to make the PPC 970 for Apple have already been done at Apple's behest. It costs IBM very little additional R&D money to make low-end servers based on a chip they already design and manufacture for other reasons.
This makes PPC the only competitor to x86 in the commodity server space, except Sun, but Sun's product lineup grows more stale and outclassed by the day. Using IBM's compiler the 2GHz PPC970 performs approximately equivalently to a 2.8GHz p4 using icc, which is far beyond the performance offered by the in-order execution (!!) 1.05 GHz UltraSparc iii.
Having an alternative to x86 in the server space is desirable, because PPC will always have better heat dissipation and power consumption at a given level of performance. These are important considerations especially in the blade server market. In addition these are 64-bit boxes which will allow going beyond the 4GB memory barrier without using the "segmented memory" hack of the 36-bit memory addressed Xeons.
In short, this could work.
The R16K was NEVER intended for the embeded market. BUt of course you have no idea what you are talking about, the MIPS R14/16/18K come from the SGI MIPS side of things not the spun off MIPS Computer side of things those are the guys doing all the embeded stuff.
Fool, the R16k was based on the R10k core which was designed by MIPS not SGI; SGI doesn't even have a CPU development team any more and doesn't even own the trademark for r16k. The R16k was a "tweak" of the R10k core by _MIPS_.
But of course lack of knowledge never stopped you from posting arbitrary spec numbers pulled out of hte thing air...
Dude, you can check out the numbers on spec.org if you can figure out how to use a browser:
SpecFP:
SGI Altix 3000 (1500MHz, Itanium 2): 2041
SGI Origin 300 (600MHz R14000A): 472
What a load of old twaddle. Most current embedded MIPs processors are based upon the R42XX architecture. They are fast enough for what you need them for (300 mips) and they don't cooked you hardware when not fitted with a fan.
The R16K is based on the R10K core, NOT the R4k core as you claim.
(It's difficult to believe that parent got modded up to 5. Time to start meta-moderating again...)
...Salaries have never had anything to do with how much you're worth, unless "worth" is defined solely in terms of market forces like demand. As such you cannot control it. If your job suddenly is automatable then you are laid off regardless of how much you previously were worth.
The cold, unpleasant truth here, is that 90% of IT isn't worth its salary.
Huh? Then why precisely do companies pay them that much in the first place if they aren't "worth" it and the company can't recoup the costs?
It takes time, but eventually, everyone gets paid what they're actually worth as opposed to what they think they're worth.
People used to get paid what they think they're worth? Did employment applications have a box saying "write what you think you should get paid here" and the employers would pay it?
The secret is to make yourself worth more.
Dude the difficulty is that they're exporting the jobs to economies where tech workers make $5/hr. It has nothing to do with acquiring some new skill; as long as an Indian or Chinese can acquire it, the job will still be moved overseas.
Probably a meaningless admonition to most slashdotters who think that the world owes them a living so they can spend all their time downloading files from Kazaa.
You are a slashdotter; you are insulting yourself.
I think it was spec.org who did some test a few years ago comparing the 400mhz MIPS and a 1GHz AMD/Intel and found that the MIPS had about 70% of the computing power to the AMD/Intel, but when You put this in a multiprocessor machine (4 I think) the MIPS was 120% to the AMD/Intel and when scaled up even further(16-32), AMD/Intel wasn't even on the charts.
This was probably due to a superior memory fabric in the SGI machine, since AMD/Intel SMP boxes were (back then) simple shared-bus devices. The AMD/Intel boxes were "not even on the charts" because there were no 16-32 way x86 boxes back then.
No, SGI has NOTHING to be ashamed of when it comes to their MIPS.
SGI has a GREAT DEAL to be ashamed of when it comes to MIPS. The R16k was designed for the embedded market and is not competitive in performance with other CPUs. It loses even to mass-market CPUs like Intel & AMD. It loses embarrassingly to its RISC competition, regularly posting SpecFP scores that are 1/4th or less that of POWER4 or Itanium2.
The biggest difficulty I can forsee is not the decline in programming jobs, but the decline in skilled careers altogether, because of losses to overseas. The prospect of re-training doesn't bother me so much. But re-train to do what? Accounting? Law? Engineering? DBA work? Manufacturing? Research? All of these careers will move to foreign shores. Graphic Design? Even graphic design is being shipped overseas -- "The Simpsons" is now drawn by people in Thailand for $1/hr!
Nothing remains! I have no idea what skill to acquire. The only career for which there's brisk demand is NURSING. That can't be shipped overseas, not even a portion of it. I have no desire -- NONE -- to be a nurse. I suppose I could sell clothes at the Gap to people who no longer can afford to shop there.
The state of Java now is pure and simply...just bloat... A simple C# hello world program uses 11 Meg! ... I'm a systems programmer, I write applications that load, do what they need to do as fast as possible, then completely unload and get out of the way.
Java is used for writing large-scale backend enterprise applications, not small command-line utilities. Nobody is suggesting it as a replacement for perl. With the programs Java is used for, startup time is irrelevant (since it's only started once) and a 50 meg overhead is insignificant.
We had a great programming language called C, and C++ that got pushed to the back-burner because of some people who decided that garbage collection and VM's were a "good thing".
C++ wasn't a "great" programming language, it was a syntactic disaster. C is decent for systems programming but still has its defects.
Well, maybe they are, but at the expense of expertise in programming? I'm so tired of programming environments that keep people from shooting themselves in the foot, or coddle beginning coders.
This is one attitude that has to be guarded against. Unfortunately, there is a class of people who wrongly call themselves "real programmers." They try to prove their machismo by purposefully avoiding modern techniques, and by doing things in a primitive and difficult way. These programmers overestimate their skills, because they produce unreadable, unportable, bizarre, buggy code that has marginal or nonexistent performance benefits.
Manual manipulation of pointers causes a 50% increase in bug count, and that's when they're being used by experienced C programmers. When C programmers can write large-scale applications that have no pointer bugs at all, right from the start, then I'll favor letting the "real" programmers have free reign.
I mean come on, if you can't handle pointers, can you really call yourself a programmer?
Programming exists to accomplish real-world tasks while meeting abstract design criteria, like code readability. It doesn't exist to dereference pointers, twiddle bits, or shift things around in Unions.
At present, the principal performance bottleneck of a relational database is disk seek time. Since disks have disastrous seek times, database servers often have an incredible number of disks (hundreds or more), in order to have those disks seeking in parallel, thereby mitigating disastrous seek times of individual disks.
These hundreds of disks often have very little on them. The purpose of having lots of disks isn't for more storage, but for more drive heads, because lots of heads can be seeking in parallel.
Oftentimes, OLTP databases aren't even that large, and most of the space on the disks is unused.
RAM has a seek time (latency) that is about 1/10,000th that of disk. Since latency is the primary bottleneck, this could vastly improve the speed of databases. And database servers could become cheaper, since all those unnecessary (and unfilled) disks, used just for parallel disk seeks, could be thrown away.
The difficulty with RAM is that it loses its data after you turn off the power. This is the reason disks are still used for databases. Losing any data because of power loss would not be acceptable to any financial institution. Battery backups etc would never be deemed sufficient.
The moment we have RAM that retains data despite power loss, disks will no longer be used in database servers. This will be true even if such RAM is vastly more expensive than the disks they replace, because the RAM would be 10,000x as fast and so would render unneccessary the huge number of "redundant" disks kept around simply so data can be read in parallel from multiple disks.
"Flash RAM" and other current nonvolatile memory technologies will not suffice, for several reasons. First, they can only be written a limited number of times before failure. Second, their write speeds are very low, and OLTP databases are write-intensive.
There are components of ACIDity that would be implmented very differently for RAM-persistent databases than for disk-persistent ones. Maintaining ACIDity on disk-persistent databases requires complicated algorithms to mitigate the disatrous disk seek times. These complicated algorithms would be rendered unnecessary if disks were no longer used.
For example, disks have incredibly slow seek times and much better bandwidth; therefore it's far cheaper to write things to disk in big chunks. The purpose of write-ahead logging (or "redo logging") is to mitigate the performance impact of slow seek times by blasting all the transactions to disk at once, in the redo log, thereby avoiding the slow seeks that would be required by putting each transaction in its proper place. Putting the transaction data in its proper place is deferred until after the load has died down somewhat. This could be seen as exchanging seek times for bandwidth.
This redo log mechanism would be unnecessary for ram-persistent databases. It's a significant source of complexity that would be obviated by the removal of disks. And that's just one example of complexity required to get adequate performance from disk, a medium that has disastrously slow seek times.
Strangely enough, something like this has already been done. The military investigated a series of devices that measure sexual attraction, in order to screen out homosexuals. The idea was that they could put new male recruits in front of mostly-undressed pictures of athletic young men, then measure the level of sexual excitation, and screen out the homosexuals.
By the way, one of the devices used to measure sexual excitation was called a "Penile Photoplathismograph". It measures blood flow to the sexual organ, and most youngish men can't help but get a little bit of an erection when exposed to a picture of a naked attractive potential sex object.
ANYWAY, the idea was abandoned, for two reasons. First, some of the extremely homophobic people could not pass the test themselves. This grants some credence to the notion that angrily homophobic people are sometimes having some kind of internal conflict. Second, people who are "bisexual" to some extent greatly outnumber people who are outright gay. Although men who are exclusively homosexual make up 1-2% of the population, people who will evince at least some attraction to members of the same sex make up 5-6% of the population. Kicking out 6% of the military would be a problem.
This actually has some research in psychology to support it.
Women consistently perform much better at certain verbal tasks. For example, when confronted with a question like "find ten synonyms for word x", women will be able to answer it in far less time than men on average.
Women consistenly perform much worse at visual-spatial tasks like rotating three-dimensional objects in their minds.
I took a test in a psych class which had both verbal and visual/spatial questions on it. It could determine your gender based on your scores on those two scales. It worked pretty well; it seemed that 90% of the people in the class had their gender accurately identified.
Of course, it is a statistical average only; some women are better than men at visual/spatial tasks. And, it's not known whether the difference is genetic or as a result of environmental influences (boys are given blocks to play with as children, after all).
There is no scientific support for statements like "this is because men were hunters in primitive societies." This may be true, but sociobiologists make tons of essentially random speculations and are able to prove almost none of it.
I read the post. Even when Oracle databases are fully cached in RAM, all transactions are still written to disk. Oracle never reports that a transaction has been committed until it has at least been entered into the redo logs. This is because Oracle is a durable data store."Cached in ram" applies to read queries, not insertions/modifications.
OK, I'll bite. Someone has claims of a durable data store that's 9000 times faster than Oracle, by using the equivalent of a "redo log."
That should immediately make everyone extremely skeptical! The redo log is hardware dependent: the limiting factor in performance is the bandwidth of disk! A redo log is already streaming; they've already factored out head seek time. It's impossible to get 9,000 times the performance with a durable data store! A 50% performance improvement would be difficult to believe.
The guy who wrote the article is 19 years old and claims "8 years programming experience" or something like that. HMMMM.... Getting a pc for your 11th birthday counts as programming experience.
So I figured: this guy thinks he's writing his redo log to disk, but actually the OS is caching it. When he thinks he's writing to disk, he actually writes to memory.
So I downloaded the source code and read through it. He tries to sync the disks by calling "outputStream.flush()". That method doesn't do what he thinks it does! It flushes the JAVA BUFFERS inside Java classes like BufferedOutputStream. It does NOT flush the data to disk. They think they're writing to disk, but they aren't. In short, this data store is not durable. The only reason they think it gets 9,000 times the performance of Oracle, is because they don't understand what their program is doing.
Moral of the story: be a bit skeptical when someone claims 9,000 times better performance than Oracle. 9,000 faster is approximately how much faster RAM is than disk (strange coincidence).
Back when I was a teenager, my friends and I got Commodore 128's. Those machines had these incredibly tiny "reset" buttons, which required a pencil or something to press, that way you couldn't accidentally hit 'reset.' Anyway a friend of mine was playing a video game and became very angry and wanted to reset the computer right then, but his finger wouldn't fit into the hole of the reset button. Out of anger, he took this modem card and jammed it into the port on the back of the machine (the "user bus"). This caused the machine to reset. Thereafter, this was his preferred method of resetting the machine. It never damaged the machine.
...I nailed FZero for SNES with a mallet, but the third hit shattered it.
"You miss the point...Salon has new content pretty much *every day*....the mags. you cite come out just once per month. Apples and oranges here."
Salon releases a single new article every day, rather than a bunch of them all at once at the end of the month. Salon just staggers their content release. It's an advantage of online mags.
In all, it appears to me that Salon has about the same amount of content as any of the monthly magazines.