As someone else already said, "people seem to forget what the R in RAM stands for".
What kills RAM nowadays in common scenarios is latency. Whenever there's a cache miss, or a mis-prediction makes you flush the CPU's pipeline and start again, what causes the CPU to stall is latency. You get to wait until that request is processed by the RAM controller, is actually delivered by the RAM, makes its way back through the RAM controller, and only then you can finally resume computing. That's latency, in a nutshell.
And it's already _the_ problem, and it's gotten steadily worse. A modern CPU has to wait as many cycles for a word from RAM as an ancient 8086 would have if you ran it with a HDD instead of RAM. It's _that_ bad.
That's why everyone is putting a ton of cache and/or inventing work-arounds like HyperThreading. And even those only work so far.
And again, it's only going worse. DDR did increase bandwidth, but did buggerall for latency. Your average computer may well yet transfer two words per clock cycle with DDR, but still has 3 cycles CAS latency like SDR had. And DDR 2 has made it even worse.
So FBDIMM's great big advantage is that it lets you have _more_ latency? Well, gee. That's as much of a solution as a kick in the head as a cure for headache.
As I've said, "no, thanks." If Intel wants to go into fantasy land and add yet another abstraction layer just for the sake of extra latency, I'm starting to think Intel has plain old lost its marbles.
anything based on "I heard stories" is suspicious
on
New Standard Keyboard
·
· Score: 1, Insightful
Sorry, I'll call bull on any "proof" based on
(A) scare stories ("but it'll kill your wrists!"), and
(B) unverifiable "halelujah! The new Lord/Layout/Whatever healed me!" bullshit
I _am_ willing to accept that a layout causes more strain than the other, once I see an actual scientific study. But disparate "I heard stories about someone who knew someone who got divinely healed once they believed in the Holy Dvorak" are at best a crap cult, nothing more.
The fact remains that:
1. Last I've heard, RSI had _nothing_ to do with the distance travelled by your fingers, but with the position of your wrists on the table. Which is the same for any keyboard layout.
Here's a bit of a fun fact: the actual mechanical typewriter typists are the _least_ likely to get RSI problems in their wrists, even at actually higher finger movement. Because their wrists aren't touching the table.
So basically saying that DVORAK heals RSI is like saying that a new hat healed your knee. More of a question of belief than any scientific cause-effect link. It's also why you don't hear that someone's pain got worse: because it really has nothing to do with keyboard layout.
2. People believe in all sorts of miraculous healing all the time, because they want to. They want to see results, they want to be right, they want to feel good about having done/chosen the right thing.
So the selective confirmation kicks in. The brains automatically discards any data which would hurt your beliefs, and retains the one which seems to fit your dogma.
It doesn't even have anything to do with keyboards as such. Anything you really want to believe in will have the same effect. _Anything_ can be "proved" via selective confirmation.
For example a racist person who really wants to believe that RaceX is inferior, will remember all the times they've seen someone of that race do something stupid, or all the cases they've seen one accused of a crime on the news, but systematically not register anything good about that race. Or someone who wants to believe, say, that praying to the Lord makes their car go faster, will remember every single time where they got a good speed (down hill and with wind from the back), but conveniently forget every single time the prayer didn't help.
3. There's this fun medical fact that most diseases and injuries heal by themselves, given enough time. Even modern medicine most of the time doesn't outright kill the bacteria or viruses inside you (no medicine kills viruses), but just weakens them a bit so your own immune system has an edge.
That's what makes "faith healing" or "alternative healing" seem to work. At least 80% of their patients would have healed anyway. So, hey, you just need to pray to the Great Holy Banana too and you too have that probability to be healed! And the rest, hey, they probably didn't have enough faith in the Great Holy Banana.
And humans find ways to deal with harm. E.g., someone may eventually learn to position their arms so they hurt their wrists less. Or they might get a different desk and chair, so the wrist position is different. Etc.
There are a _lot_ of factors which can make or break that kind of an injury. Or any other kind of a injury. So I'd wait for a study that scientifically rules those out, before ascribing the miracle to the all-powerful cult of Dvorak.
Typing "TYPEWRITER" fast was simply a sales gimmick, so the salesmen could tell clueless PHBs "see! It doesn't slow typists down! I can type TYPEWRITER quickly!" And unsurprisingly, clueless PHBs existed in 1870 just as well, long before computers, and corporate purchases were made based on some rigged non-representative demo.
But there were real mechanical considerations there too.
Typewriters used to be purely mechanical things. Hitting a key physically pressed a lever, which swung a small hammer at the paper. Actually, at the ink ribbon. And on the hammer a letter or digit was embossed. (Actually, two. SHIFT would physically raise the carriage, so the second letter on the hammer hit.)
Because it was purely mechanical and involved densely packed thin levers, it was jam-prone. If you hit two keys at the same time, two hammers would try to occupy the same space at the same time. If they were coming from opposite ends, not much would happen: 99% of the time one would just hit on top of the other. But if they were adjacent (or almost adjacent) levers, the machine would jam.
That was the problem they tried to solve: keeping the machine from jamming. Which involved moving the hammers for most common letter combinations further apart from each other. Which, since it was a purely mechanical contraption, involved moving the keys too. (It wasn't as simple as defining a new mapping table, like on computers.)
And whatever effect it had on typists and typing speed, was side-effect rather than considered in the design. Whether it sped them up or slowed them down, it still ended up faster if it didn't require unjamming twice a minute.
However, here's another fun fact: the typewriter for which that layout was designed was very different even from typewriters manufactured after 1900. After 1900 the hammers were arranged in an arc in front of the paper. Before that, they were arranged in a circle or bucket shape.
That bucket shape is what the QWERTY layout was designed for. Which meant that moving the hammers had some weirder effects on where the keys moved. E.g., near the middle of rows, two adjacent keys would swing hammers from opposite sides of the bucket. Hence the "TY" in "TYPEWRITER" would not jam that machine, which is why they're still near each other.
It would, however jam a post-1900 typewriter.
So basically the short story is: QWERTY was never supposed to be ergonomic, it was supposed to just prevent jams. And even that was a quick mechanical hack, which missed a lot of fairly commong combinations. _And_ even for the purpose of preventing jams it wasn't that useful any more, for any post-1900 typewriter.
Yet, more than 100 years even after the new typewriter design, and half a century after keyboards being used in computers (which don't jam) we're still stuck with the QWERTY idiocy.
Its saving grace, though, is that basically on a computer keyboard _any_ layout works just as well. Neither jams nor alternating hands (which made sense back when you had to hit the keys HARD on a typewriter) are relevant any more. You just type faster on whatever layout you're the most used to. For most people that means QWERTY.
Which means there's little real incentive to switch to a new layout.
I'd challenge the idea that alternating hands has _any_ influence, good or bad, on a _computer_ keyboard. I keep hearing people repeating that myth, because it once used to be true on a mechanical keyboard, but never seen a study to show that it still applies to a computer one.
Have you ever used a mechanical typewriter? And I do mean the purely mechanical kind, for which QWERTY was made. Not the modern electrical ones.
It was a purely mechanical contraption, and you had to physically *HIT* the keys so the hammer would swing hard enough at the paper. To type anything in three copies via carbon paper, it was an exercise akin to hammering nails into a beam of wood. With your fingertips.
Even the position of the hands was different. Anyone who grew up on those won't get RSI (or not in the wrists) from a keyboard, because their wrists don't touch the table. The way to type on one of those was to have your hands hovering above the keyboard (a tiresome exercise in itself holding your arms like that), so you could launch your fingers downwards HARD at the keys.
So I can see how it was an advantage for those to distribute the effort more evenly and alternately between the two hands and arms.
But on a computer keyboard? Can't say I've noticed that typing, say, "SAD" would be any slower than "PAL". The pre-requisites to need to alternate hands just aren't there any more.
That said, I'm still not for DVORAK, because in the end what works faster is what you're used to. Someone used to QWERTY will type faster on QWERTY, and that's that. Including, yes, the imaginary monstrosity that you mention in the phrase: "If this were true, he would have located popular letters such as "A" and "S" at the far corners of the keyboard and located unpopular letters like "Q", "Z", and "X" under your fingertips, right where you don't need them." If you grew up on that, you'd type the fastest on that.
So I still see no reason to switch.
I'm just wondering about the whole alternating hands theory.
Actually, you know, I got used to the older shortcuts, which is to say CTRL-INS, SHIFT-INS and CTRL-DEL. And ALT-BACKSPACE for undo. They work just as well, if that's what you're used to. (Incidentally, they'd also be in the same position on a Dvorak keyboard)
Or I pretty much grew up on WordStar. To do the equivalent of the CTRL-C CTRL-V you mention, you'd have to use block commands, which were prefixed with CTRL-K. But an even more fun command group were those starting with CTRL-O. Don't even try doing that with the left hand only, it's not comfortable. Again, it worked well enough and people were typing whole books in WordStar. (And I stuck to Borland IDEs for programming until 2001 or so, because they let me use the WordStar key mappings.)
Or here's an bit of fun about German keyboards. The CUA Undo is CTRL-Z, and German keyboards are QWERTZ. I.e., CTRL-Z is where CTRL-Y would be on the USA keyboards. People use it with no problem, though. More fun for programming is that the square brackets have been moved on RIGHT_ALT-8 and RIGHT_ALT-9, instead of being a single keystroke, to make way for the national characters. And "@" (as used in emails) is RIGHT_ALT+Q. Again, seems to work OK, if that's what you got used to.
Basically as was said, _any_ keyboard arrangement works just as well, if that's what you're used to. Including, I'd add, any arrangement of the shortcuts on the keyboard.
However, the reverse is also true. Switching to a new arrangement just brings a long learning curve before you get back to speed. So buying Dvorak keyboards for the whole company to "improve their productivity" might have the opposite effect, as well as needlessly annoying everyone.
You see, real life monopolies are more complicated than the bakeries example. The price undercutting on individual items is the facet that the monopolist _likes_ you to see.
In reality, a workable monopoly is made of several interlocking parts. Where if anyone wants to compete with part A, they get part B and C brought against them. _That_ is what allows a monopoly to rise prices again, not the fact that the old bakeries closed down and new ones can appear back at any time.
E.g., let's say I'm a telecom monopoly, and control both the phone network _and_ the physical phone manufacturing. Let's say you're a bright young entrepreneur, you've invested a lot in R&D, and you try to challenge my handset business, by selling your own cheaper and better handsets. Because I also control the network, I can block your phones from connecting to it. Congrats. You have a ton of great phones to sell, except noone can use them. Sucks to be you. Your company dies.
That's the kind of interlocking combination that allows one to stay a monopoly even while offering less value for the money.
Or to give a MS example, consider the following classic example: in the days of NT4, Novell wanted to make their servers too able to act as an NT domain controller. Sure, you could go ahead and buy your workstation OS from MS, but you would also be able to keep your old Netware servers for the login.
Microsoft didn't even pretent to play fair. It simply informed Novell that if Novell ships such a product, Microsoft _will_ break it. And they did. They did every dirty trick to stop the clients from being able to use a Netware server for that. Novell eventually gave up.
This incidentally also shows why such an interlocking monopoly is bad for the consumers, even if they undercut some of the prices a little. It's used so that if you want product A, they can also use it to force you to use their products B and C and D too. Each part not only protects the others, but also serves to push the others down your throat.
If you want to use NT clients, hey, can we also interest you in an NT server to keep your network still running? You don't want NT clients? Well, then good luck with those Office docs you get as attachments from your business partners, 'cause we're not porting that to some other OS. Etc.
And such an interlocking nut is nigh impossible to crack without government intervention.
Even for a big corporation, the effort and cost to compete with that is entirely unreasonable. E.g., if you wanted to compete with Windows, you don't just need to write a good OS, you also need Office, you need server software, you need client software, etc. (Just think of all those people who asked "but will I still be able to run MS Word?" when you told them to switch to Linux. QED.) The entry barrier is lifted a helluva lot higher than just opening a new bakery.
1. First of all, seems to me like you didn't have much self-control to start with, if you ended up with a case of "hard to talk with those kind of images flooding your mind!" Not meant as an offense, just as a statement.
E.g., I'll go on record to say that I do look at porn, albeit in moderation. If nothing else, video games are still my first priority, so to speak. Can't say I've had anything even remotely similar to the experience you describe. If anything, I used to fantasize about my female schoolmates a lot more back in high school, _before_ I had any access to porn at all.
The fact is, some people just have a tendency to get obsessive-compulsive about something. In your case it happened to be about porn, but the phenomenon is more generic. It existed long before the Internet, and will exist if tomorrow the Internet disappeared. And it can be about anything else: e.g., workaholics can be a case of the same thing.
So to generalize that as either (A) a general effect of porn, or (B) as representative of 100% of the population's reaction to something, is just bull.
2. Again, because people can go obsessive-compulsive about _anything_, you can look at what happens when they do about anything else: not much other than the obssession itself, and its obvious effects. The "next best thing can only be real life" just doesn't happen almost at all.
E.g., video games are probably the most quoted example of stuff people going obsessive-compulsive about, some to the point of dropping out of school or work, getting divorced, etc.
By your logic "The more you get, the more you want... until the next best thing can only be real-life." We should see hordes of people running around with rifles shooting each other, to get the next best thing up from FPS games. Not to mention every 5th teenager would steal their parents' car and race it, because they've played Gran Turismo.
And, contrary to media bullshit, it just doesn't happen like that.
1. I don't think, say, the price of a Windows file server, any way you want to configure it, has yet come even close to what the price for a Novell server used to be. So the "but MS will raise its prices sky high and ruin us all!!!" scare scenario shows no sign of happening.
In fact, au contraire, some products are actually getting cheaper versions than before. E.g., XP Home Edition is cheaper than what you used to pay for Windows 2000. Yeah, it has some features cut out, but they're features 90% of the home users never needed. (And the other 10% can buy the Pro version at the same price as Windows 2000 used to cost.)
2. I know "TCO" is a swearword among us nerds, but that's a part of the price too. And with MS it's another reason why it's cheaper. You can use more common skills and need less work to use more than one program from them.
E.g., with Novell you pretty much got _only_ that: a file server. E.g., you used to get a bunch of disparate programs instead of Office, that didn't even have the same interface or talk to each other. (Good luck embedding a Lotus 1-2-3 table and chart in WordStar.)
3. "But IE doesn't innovate!" I keep hearing that, but it's the most piss-poor argument. First of all, IE is their free product. Second, it already works, and it has all the features that a browser needs.
You know, at some point it's time to stop bloating a progra. It's a browser, not some enterprise swiss-army-knife platform that does everything including version management, bug tracking, and is its own widget set too. It just has to be a window into the web, and let you see web pages. Much like a TV just has to let you watch TV programmes. No more.
4. You have a very warped idea of how a monopoly works. In your bakery example, there's nothing to keep a new bakery from opening once the "monopoly" raised its prices. The world isn't an immutable autistic nerd fantasy where nothing new normally happens, and nothing can be undone. IRL it's damn hard to actually get in a situation where you can rise the prices again sky-high with impunity.
5. Ah, but maybe the entry prices are too high? Not for another big corporation. A lot of other big corporations are busy trying to do the same price undercutting to MS.
E.g., OOo is mostly paid for by Sun. E.g., most of the work on Linux comes from people paid to do that, not from lonely bored nerds. Etc. They just pack it into a nice lie, instead of saying "we're undercutting MSs prices too". But it's the same thing. OOo is Sun's attack on Office in the _exact_ same "we'll give ours for free" way as MS killed Netscape.
6. And most importantly, as was said before, MS has to compete with itself all the time. Unlike, say, Coca-Cola (as another near-monopoly) which can sell the exact same product for eternity once it got the market, MS must give you enough reason to upgrade from your old Windows 98 SE to Windows XP, or from the old Office 97 we still use at work to Office 2005. That's what really keeps them maybe not "innovating" spectacularly, but trying to make a better product and keeeping the prices sane.
Heh. I must confess that I was actually waiting for someone to try to play the "but it says Instruction Set" joker, and shoot themselves in the foot in the process. Because, see, the instruction set is precisely what makes a G5 for example _not_ be RISC.
Ever programmed a true RISC? See, the matra "never do in hardware what the compiler can do for you", meant that their instruction sets were very basic by definition. The Reduced in RISC stands for an instruction set reduced to the bare minimum that could still work as a Turing Machine.
Among other things, RISC made famous the LOAD-EXECUTE-STORE sequence. Anything conceptual operation that involved more than one of those, _had_ to be broken into the individual steps. (As I've said before, its instruction set was very micro-code like.)
For example, let's take something like "ADD [EBX+1000], EAX" on a CISC. If the x86 were a RISC you'd _literally_ write it like:
Each and every single building block of the complex instruction, such as loading the data, adding it, and writing it back to RAM, _had_ to be a separate step.
And if your conceptual operation logically involved a loop, e.g., adding two vectors, you _had_ to write the incrementing, comparing and conditional jump explicitly. Because anything else would be implementing them in hardware, instead of letting the compiler do it for you.
What I'm getting at is that _any_ SIMD (single instruction multiple data) instruction set is by definition _not_ RISC.
Now kindly get yourself a copy of the G5's instruction set. And look at it. Especially look at AltiVec. It's SIMD, isn't it? Now how the heck does that count as RISC?
Well, bingo. If it wasn't CISC already, AltiVec did turn Macs into CISC.
So the true revisionists are the clueless marketroids at Apple, who still hang on that buzzword as some mystical quality that their product has. Never mind that the G4 was losing badly in all benchmarks, it's cool because it's RISC.
No, it no longer is. It's a good CISC design. It's good, yes. I wish Intel had an instruction set like that. But it's CISC nevertheless.
OK, duly noted. Let me rephras that: "RISC is dead on the _desktop_." Could be that some ancient true RISC design is still produced for washing machines or such:P
Pipelining was possible and used long before RISC CPUs. It was just called "micro-code" back then.
So at some point CPUs just had enough transistors to return to something that had been used on minis and mainframes long before RISC. RISC had _nothing_ to do with it. If anything, RISC was born from micro-coded designs, not the other way around.
In a way, though, unlike other marketting BS, this one isn't entirely inaccurate. That much I must admit. A RISC CPU isn't that different from a micro-code execution unit. RISC was if anything else simply exposing the micro-code to the outside world, and more or less just letting the compiler generate micro-code. So in a way, yes, they _are_ RISC inside. (Then again, so were the mainframes and minis in the 70s, then.)
However, the opposite is also true. The moment you wrap it inside a more complex design with a pipeline, out-of-order scheduler, and and a complex decoder, the whole design (as a whole) is no longer RISC. It may have a RISC core (actually an micro-code execution unit) burried deep inside it, but the whole design isn't RISC any more than a TV is a transistor.
That's what I meant by "RISC is dead". Yes, everyone may have one of them buried deep inside, if you really want to call it that way, but the whole design is wrapped up in other layers that make it really a CISC.
Well, then educate me. What does constitute a RISC computer? Take the block diagrams of a G5 and of, say, a Pentium 4 and educated me: exactly what's in a G5 that makes it a RISC, and obviously isn't there in a P4? No, seriously.
The _whole_ idea and advantage (for that time) of RISC was that it basically exposed its microcode to the outside world. (Well, not 100% accurate, but as a metaphor it will have to do.) Any instruction required only minimal decoding to directly drive the ALU and the rest of the CPU.
Exactly how does a G5 still fit that vision?
Except at some time, and after some Apple ads, it became _fashionable_ to use RISC as a buzzword. Everyone had to claim they too were fashionably RISC.
E.g., when the AMD K6 came and had a plain-old micro-coded architecture, they couldn't just call it "micro-coded". They just had to find idiotic marketting euphemisms that boiled down to "yeah, but internally it's RISC-like. Internally we decode those CISC instructions to RISC stuff, you know." (No, it isn't. It's what we've been calling "micro-code" for decades.)
And ever since every single CPU had to do that too. You no longer hear anyone just claiming "micro-code", they now "RISC-ify" the instructions or some other such crap euphemism that a marketroid pulled out of the butt. "RISC-ifying" stuff is obviously more fashionable than saying you use micro-code like in the 60s.
So, yeah, RISC is a paradox. For a dead technology, it sure became a big marketting buzzword.
But anyway, if any of the above is wrong, please do explain how.
Until then, yes, you just live up to your sig: "Fucking 13 year olds". Maybe next time you can read a technical manual first, instead of just throwing a tantrum when reality doesn't match Apple's ads.
A long time ago, in a galaxy far away, CPU transistor budgets were measured in tens of thousands. You had _barely_ enough of them for either more registers _or_ a more complex decoder, but never both.
This begat RISC. A CISC computer had a more complex in struction set, but that barely left it with enough transistors for a couple of general purpose registers. A RISC computer, on the other hand, went by the mantra "never do in software what the compiler can do for you", so it had an over-simplified instruction set, but then it had enough transistors left for more registers.
In a sense each of the two was too expensive for _someone_. For CISC, registers were too expensive. For RISC the decoder was too expensive. In truth, both were expensive, and the grand unified theory;) is simply that you just couldn't have _both_.
Fast-forward a bit, and registers are _not_ expensive for CISC any more. You do mention "what will prevent Intel/AMD to add a technology which could use multiple sets of registers", so the answer to that is: they already do. Both have huge register stacks they internally use for renaming. (E.g., when you swap EAX and EBX, the data isn't really copied, but the register from that huge stack which is currently EAX and the one which is currently EBX, get renamed to EBX and EAX respectively.)
Either way, they already have the Cell's 128 registers, and some even have 256 registers. You just don't see them from the outside. (Which is a pity, since compilers could really use them.)
Is there something to stop them from exposing more of those registers to the outside world? Nope. The AMD Athlon 64's (now also addopted by Intel) "64 bit extensions" already do just that: they double the number of general purpose registers visible to the program. That's largely what gives an Athlon 64 the speed boost when running 64 bit code: the extra registers.
Is there something to keep them from doubling or quadrupling them again? From a technical point of view, nothing whatsoever.
What's been keeping them so far is the software backward compatibility. A Pentium 4 still has to run code written for a 486. So whatever changes you do to their instruction set, they must leave the old pre-existing instructions unchanged. And there simply aren't bits left to add the new registers without changing the whole instruction set.
The migration to 64 bits has been such a good excuse to come up with a completely new instruction set, with more general-purpose registers. But such excuses are few and far between.
As for RISC... it died, it lost the battle. Yes, Apple and IBM still use it as a marketting buzzword, but that's it. There are _no_ RISC CPUs still being produced.
The G5 in Macs is simply a CISC with more registers and a better instruction set, but it's CISC nevertheless. It's internal structure is _not_ RISC, and AltiVec is _not_ RISC. They're in fact contrary to everything RISC stood for.
Ditto for Sun's UltraSparc.
(And everyone arguing that a G5 is RISC, has obviously never programmed a RISC CPU before. You had to take care of every single detail in software, because of the mantra "never do in hardware what the compiler can do for you." Even recovering from a pipeline overflow when an interrupt came, you had to do that in software.)
Hope this helps.
that's another thing I've been wondering about...
on
Is IRC All Bad?
·
· Score: 1
Well, it's probably off topic, but the bogus data and their use in auto-inflating statistics are one thing I've been wondering about too. Of course, I haven't done any study or anything, so it's only tinfoil hat hypothesis at most.
For example, I'm in a gaming channel and some allegedly 16 year old horny kid drops by and tries to score some "cybersex". Had to personally persuade one or two to get the heck out, because no op was around.
How many of those actually are actual kids and potential prey for pedophiles, and how many are actually some FBI agent? And I'm not against the FBI helping keep pedophiles out, but _if_ that's what it was, it was starting a pedophile conversation in a channel that didn't have any to start with. Worse yet, a sex-related conversation in a channel that _does_ have children in it. (You know, lots of games are only PG-13, or even less.)
I.e., it was doing more harm than good. Or arguably did only harm and no good.
And how many of those end up in some statistic to justify one's own budget?
Or someone drops by and starts asking for a crack for that game, or where he can download a warezed version. Or worse yet, advertising some warez site.
I have no doubt that most were truly clueless wannabe pirates, but... were any of them actually BSA/FBI/publisher/whatever drones trying to see who they can bait? Or deliberately polluting the channel to make pirates comfortable about talking about it?
The problem, again, is that _if_ that's what it was, it's pollution. A bunch of us have a hard enough time keeping the channel clean of that kinda stuff, and making the pirates _not_ comfortable about it.
And then someone comes and spends two hours (until an op finally drops by) spouting crap like "only idiots buy what they can download for free", and generally promoting piracy full time. _If_ they're from the BSA or the publisher, it makes me want to bash not only their head in, but also their boss's.
And again, how many of those end up in some self-justifying statistics? "Waah! Poor us! Piracy is rampant! Yesterday on IRC they were again talking about how only idiots buy our software instead of downloading it!" Right, except was it really a real pirate?
Oh well.. guess we'll never know. Makes for a good tinfoil hat theory, though.
Re:IRC analysis fatally flawed
on
Is IRC All Bad?
·
· Score: 2, Insightful
Actually, my whole point was that those are the _least_ representative of IRC as a _chat_ platform. We're talking about channels (A) not used to chat, (B) not usable for chat even if you wanted to, because as chat with 1000 people simultaneously would just scroll your screen faster than "ls -R/" (or "dir/s c:\" in Windows), and (C) mostly populated by bots anyway.
Now maybe they still would be somehow representative if it weren't for point C above. I don't know by what criterion a channel with 1000 bots is representative of (far more) people actually chatting in the normal channels. If anything, the bots are a creative (ab)use of the IRC protocol, rather than IRC as a _chat_ platform.
Re:IRC analysis fatally flawed
on
Is IRC All Bad?
·
· Score: 3, Insightful
Well, that's precisely why it's flawed.
Even if you assume that those 10 channels has 1000 users each, that's 10000 users doing illegal stuff. Well, that's a spit in the bucket. If you list the channels on, say, Quakenet, there are an order of magnitude more _channels_ than those 10000 users.
The study is also flawed from the start because any channel that big is mostly just populated by bots. How do those count as users, it's beyond me.
And it's useless for anything _but_ binary transfers. Try having a conversation with more than 100 people in a channel, and it already is impossible. With 1000 it's simply out of the question.
So such big channels are if anything the _least_ representative of IRC, _and_ a minority of users. A study based on them is plain old bogus.
No, it's more flawed than that
on
Is IRC All Bad?
·
· Score: 2, Insightful
So he goes into warez channels and concludes that they're used for illegal stuff. Well, gee, ain't that a surprise. (Sarcasm there.)
So it's not just like doing a crime-rate study on the 10 largest city. It's like doing a study on the 10 largest _prisons_ and concluding that 99.9% of them are criminals (or at least have commited at least one major crime in their lifetime), hence the whole country is a country of criminals.
Or it's like doing a web study based on Slashdot and concluding that world-wide 99% of the people are computer-savvy nerds, and that Linux is the most popular OS world-wide, more used than MS Windows and MacOS/X combined by an order of magnitude.
Honestly, 99% of the time XML is used as a buzzword, nothing more. And in a lot of cases, like this one, it just means "we had no actually useful ideas, so we're gonna give you some fashionable snake oil instead. And we hope that your PHB is stupid enough to buy it based on buzzwords alone."
Since we're talking programming languages, what's the big huge gigantic benefit of having the indentation and code handled through XSLT?
Any modern IDE does lexical and syntactic parsing on the fly. It doesn't need XML and XSLT for that.
E.g., I have Eclipse open right now. I can edit the indentation rules however I want to have them, and reformat. It didn't need some idiotic XML syntax for that. It doesn't need some stupid XML tags telling it "instruction starts here" and "instruction ends here": the language syntax already tells it that.
I can hear the over-used argument "but XML is a standard!" Well, C is an ISO standard too. "But XML has standard parsers!" YACC and LEX are even more standard nowadays.
Same for "extending" it. I don't need some idiotic XML file telling it the parameters to my methods, any modern IDE takes them directly from the headers (for C) or.class files (for Java).
I can just type "MyClass mc = new MyClass(); mc." and then hit CTRL+SPACE in Eclipse, and it will show me all the methods and public members I can use from an instance of that class. And the parameters and docs for those methods. Again, it didn't need some XML file for that: the standard language parser was enough.
And it seems to me like it's missing the whole point even of XML. The whole idea of XML (and SGML before it) was to have a humanly readable text format for data that was otherwise saved in proprietary binary files noone could read.
Well, program code was always text and humanly readable. So I'm at a loss as to what would XML bring.
To use the example in the text on/., take the two following representations:
1. record
2. myMethod(record)
Seems to me like number 2, the traditional way is actually more humanly readable.
1. The only way to get a better computer with than a Dell at the same 500$, is... to pirate Windows. Even an OEM or upgrade version of XP Pro or Windows 2000 Pro will put quite a dent in that 500$ budget.
Build _two_ computers at that price? Well, gee, just two OEM Windows licenses will take up most of that money. So if you're trying to tell me that you can build computers for less than 100$ each, I'm damn interested to see what goes into them. I want one of those too.
So the comparison is... what? "Stealing is cheaper than buying"? Well, gee, ain't that a surprise;)
And yeah, you could put Linux on them, but other than terminal nerds noone actually wants Linux on their computer. Joe Average will want Windows on their machine, one way or another, and Dell's price already includes that. (And Apple's includes MacOS/X.)
2. Plus, since I _do_ build my own computers, I can tell you that over the years it's been just a pain in the butt. I've had my CPU overheating and crashing due to a bad heatsink. I've had data loss, repeatedly, due to hard drives overheating in a bad case. I've had such duds as buying two different hard drives in a row that were dead on arrival and had to be RMA-ed. Or like a third-party 9800 XT which mysteriously died for no obvious reason after a couple of months. Etc.
Now for some people all this hassle counts as fun. You have to also realize that for most people it _isn't_. Anyone who isn't already into building their computers as a _hobby_, is very much better off paying to have it assembled by Dell.
3. Noise. By and large this is a sub-case of 2: crap components designed by the cheapest unqualified monkeys. Or by the marketting department.
Except in this case it's not a component that dies suddenly, it's one which works badly by design. And badly in an annoying way.
About 99% of the OEM computer cases are designed by clueless idiots, with _zero_ clue of or consideration for airflow or noise. They put a lot of fans, but have them sucking at sheet metal and not achieving anything except to make that metal vibrate. Or in other creative ways not being able to move more than 5-10% of the fan's rated airflow. They're just designed to make a lot of noise and look funky, nothing more.
(And a big "fuck you" goes to ThermalTake, while I'm at it. That's an elite among the elite, as retarded case design goes.)
By comparison, Dell's cases (and IBM's and Apple's too, and a few others) are actually designed by engineers, not by graphics designers. They actually achieve better cooling with _far_ less noise.
Etc.
Just a thought: Maybe that's why people buy from Dell or Apple? 'Cause that price includes a usable OS, and a warranty, and it's all put together and tested by someone else?
or you could get the RAM from another shop
on
Mac mini Dissection
·
· Score: 1
Just FYI: I hope you do know that there are a bunch of online shops which will let you configure the extra RAM far cheaper than Apple's web site. You know, Apple's own online store isn't the alpha and the omega.
So there you go. 1GB RAM without opening the case yourself, and without paying a ludicrious 500 bucks for it either.
The "dunno what all those buzzwords mean, but we must have as many of them as possible" kind of mentality. Or as I like to call it: BDA (Buzzword Driven Architecture.)
They don't know what EJBs are (as illustrated by your example where they didn't know the difference between EJB and J2EE as a whole), but they've read in some IT-for-retards magazine that Sun says EJBs are great. So they must have some.
And for that matter, XML. And XSLT. (Just writing the data or using a template is soo 1990. Nowadays you _must_ have a small XSLT program which produces the output.) And SOAP. (Every internal call must be SOAP, you know. Just plain-old calling a C++ or Java method is soo outdated.) And have a scalable enterprise messaging framework. (Why just read stuff from a database, when you could send a SOAP message to an MDB to read it, and wait for the asynchronous response?)
And I've seen more perverse use of buzzwords which aren't even technical terms, but end up being wanted in the project anyway. E.g., "scalable". So you get a client explicitly wanting EJBs in their small web-app, because Sun said it's a scalable architecture. Uh, as opposed to what? As opposed to just using a load-balancer and a cluster, which also scales linearly?
Don't get me wrong, I'm not against EJB, XML, XSLT, JMS or SOAP as such. They have their uses. But like any tool, they're good for one class of problems. Just like you've said, there are plenty of problems which don't need EJB.
That is, until the client comes with a long list of buzzwords they absolutely must have...
Though to be entirely honest, _both_ sides are equally guilty in this. There are clueless PHBs who demand buzzwords, yes, but equally there are dishonest programmers using real projects just as a playground to get new buzzwords for their resume. A lot of projects which are just a sad collection of buzzwords, not because the boss wanted to have them, but because someone wanted those buzzwords on his resume.
Nothing personal, but I hate the system that created you. More to the point, those idiots you "do lunch" with.
Business and technical decisions are taken by people _completely_ unqualified, based purely on "oh, I know that guy. We played golf. Let's buy whatever he's selling." Or on "but the nice salesperson said it would solve all the problems, including cancer, AIDS and world hunger." Or here _literally_, and in that manager's own words, a broken product got bought "because it had the nicer powerpoint presentation." (To make it even more surrealistic, a product noone needed.)
And I've been on the receiving end of that fuck-up entirely too often. Completely dysfunctional "solutions" are bought like that. And then we engineers and admins have to make a completely broken product work. And if it still doesn't, then it obviously has to be our fault. Because the nice salesperson told the PHB that it works, and surely the nice salesperson couldn't have possibly lied to the customer. It must be those mean engineers that sabotage it.
And even _if_ the problem does eventually get to be acknowledged by the PHB, the next result is more lunches done, more colourful powerpoint foils are presented, and the PHB buys an even more broken v2.0 of the same product. (Or, don't laugh, some PHBs here are looking forward to version 6.0 of a totally broken product.) Surely now all problems are fixed. Because the nice salesperson said so.
So I can't say I hate you, as such. Where there's a demand, someone creates the supply. I.e., if some PHBs actually want to be lied to and scammed, yep, the system also produced the marketting people who do that. Perfectly normal economics there.
What I would however like to see fixed is the system.
For starters, I'd like to see some serious liability in this industry. Because this hiding behind an EULA that says "whatever happened, it's your problem, not ours" is just legalizing bigger and bigger marketting frauds. So I'd like to see people and companies facing a billion sized lawsuit if they mis-represented a product as doing what it really doesn't.
Also, while I guess one can't outlaw bullshit buzzwords as such, I'd like to see it legally mandatory to clarify (A) exactly what it means, and (B) exactly on what case studies it had that effect.
E.g., "synergy"? Ok. Between what and what? On what cases did you notice that synergistic effect? And how big was it?
E.g., "lower TCO"? Fine. On what use case? Compared to what? (Most of this crap would only lower TCO compared to carving that data by hand on stone blocks, like in the Flintstones.) And how much lower was the TCO, then? Does that include the cost of the uber-expensive consultants to make it work, or?
E.g., "scalable"? Good. Scalable in which way? And in which way is that better than just the plain-old using a cluster and load-balancer?
Etc.
Then maybe we'll see _some_ (minimal) honesty in advertising in our lifetimes. And then we nerds wouldn't have to be disgusted by the whole marketting bullshit.
The second big problem I'm seeing is: how the heck did we get to the point where CEOs/CIOs buy bullshit that sounds cool without asking someone who knows?
I mean, for example, let's take everyone's favourite comparison between computers and cars. So let's say a company, (A) produces cars, and (B) wants to make its own brand-new intranet system.
And here's the funny part:
(A) to make cars they actually trust the engineers what should go into that car. If the engineers say they need this and that gear or screw, that's what the company buys. I should hope the CEO doesn't come and say "nope, we just got this cool deal on ship propellers, so you have to use that in the cars from now on."
(B) to make the software, they proceed to thoroughly ignore and avoid the engineers, buy some bullshit from the biggest liar, and then blame the engineers and admins if it doesn't work.
It's dunno, like they're affraid to ask. It's like they'd get "STUPID" tattooed on their forehead if they ever asked a technical question, or accepted a recommendation from their own IT department.
In practice, most of us would actually respect them more.
I mean, dunno about others, but I don't expect a manager to be a Ph.D. in computers. But I do expect him to be good at his job: management. Which also includes delegating. Whatever he doesn't personally know, or isn't in his job description, his job is to find someone else who knows or can do that. That's what management is all about.
By contrast someone who just buys crap based on bullshit buzzwords rather than ever asking, is for me a sad clown. He just showed that he's incompetent at doing his own job: management.
It sorta makes me wonder how did those upper management types start wanting buzzwords to start with. But more importantly, this hurts this industry in pretty perverse ways, not just in the obvious "so the biggest liar gets the sale."
For example time after time again, we run into the perverse problem that PHBs don't just prefer bullshit bingo to technical specs. They think that technical specs _are_ pretentious bullshit buzzwords.
For example, if I say that a program is based on MDB (Message Driven Beans) and SOAP, it really means "it complies with the EJB specs, the whole book that that spec is, especially the part about messaging. Which also tells you that you need a J2EE application server to run it. And you have this other SOAP spec that tells you _exactly_ the message format _and_ how to parse it, in case your engineers need it."
I.e., there's a lot of technical information condensed into those two words. (MDB and SOAP.) I _could_ copy and paste the whole specs, or just use those abbreviations to tell people where to look for all the technical details.
But try telling "based on EJB and SOAP" to a management or marketting PHB, and they won't even think "bah, I don't have time for technical details." They won't even hear that as technical detail. They'll hear "based on pretentious made-up buzzword 1 and pretentious made-up buzzword 2".
Somewhere deep down in their psyche, they just "know" that we do nothing all day long but think up buzzwords to intimidate them with.
As someone else already said, "people seem to forget what the R in RAM stands for".
What kills RAM nowadays in common scenarios is latency. Whenever there's a cache miss, or a mis-prediction makes you flush the CPU's pipeline and start again, what causes the CPU to stall is latency. You get to wait until that request is processed by the RAM controller, is actually delivered by the RAM, makes its way back through the RAM controller, and only then you can finally resume computing. That's latency, in a nutshell.
And it's already _the_ problem, and it's gotten steadily worse. A modern CPU has to wait as many cycles for a word from RAM as an ancient 8086 would have if you ran it with a HDD instead of RAM. It's _that_ bad.
That's why everyone is putting a ton of cache and/or inventing work-arounds like HyperThreading. And even those only work so far.
And again, it's only going worse. DDR did increase bandwidth, but did buggerall for latency. Your average computer may well yet transfer two words per clock cycle with DDR, but still has 3 cycles CAS latency like SDR had. And DDR 2 has made it even worse.
So FBDIMM's great big advantage is that it lets you have _more_ latency? Well, gee. That's as much of a solution as a kick in the head as a cure for headache.
As I've said, "no, thanks." If Intel wants to go into fantasy land and add yet another abstraction layer just for the sake of extra latency, I'm starting to think Intel has plain old lost its marbles.
Sorry, I'll call bull on any "proof" based on
(A) scare stories ("but it'll kill your wrists!"), and
(B) unverifiable "halelujah! The new Lord/Layout/Whatever healed me!" bullshit
I _am_ willing to accept that a layout causes more strain than the other, once I see an actual scientific study. But disparate "I heard stories about someone who knew someone who got divinely healed once they believed in the Holy Dvorak" are at best a crap cult, nothing more.
The fact remains that:
1. Last I've heard, RSI had _nothing_ to do with the distance travelled by your fingers, but with the position of your wrists on the table. Which is the same for any keyboard layout.
Here's a bit of a fun fact: the actual mechanical typewriter typists are the _least_ likely to get RSI problems in their wrists, even at actually higher finger movement. Because their wrists aren't touching the table.
So basically saying that DVORAK heals RSI is like saying that a new hat healed your knee. More of a question of belief than any scientific cause-effect link. It's also why you don't hear that someone's pain got worse: because it really has nothing to do with keyboard layout.
2. People believe in all sorts of miraculous healing all the time, because they want to. They want to see results, they want to be right, they want to feel good about having done/chosen the right thing.
So the selective confirmation kicks in. The brains automatically discards any data which would hurt your beliefs, and retains the one which seems to fit your dogma.
It doesn't even have anything to do with keyboards as such. Anything you really want to believe in will have the same effect. _Anything_ can be "proved" via selective confirmation.
For example a racist person who really wants to believe that RaceX is inferior, will remember all the times they've seen someone of that race do something stupid, or all the cases they've seen one accused of a crime on the news, but systematically not register anything good about that race. Or someone who wants to believe, say, that praying to the Lord makes their car go faster, will remember every single time where they got a good speed (down hill and with wind from the back), but conveniently forget every single time the prayer didn't help.
3. There's this fun medical fact that most diseases and injuries heal by themselves, given enough time. Even modern medicine most of the time doesn't outright kill the bacteria or viruses inside you (no medicine kills viruses), but just weakens them a bit so your own immune system has an edge.
That's what makes "faith healing" or "alternative healing" seem to work. At least 80% of their patients would have healed anyway. So, hey, you just need to pray to the Great Holy Banana too and you too have that probability to be healed! And the rest, hey, they probably didn't have enough faith in the Great Holy Banana.
And humans find ways to deal with harm. E.g., someone may eventually learn to position their arms so they hurt their wrists less. Or they might get a different desk and chair, so the wrist position is different. Etc.
There are a _lot_ of factors which can make or break that kind of an injury. Or any other kind of a injury. So I'd wait for a study that scientifically rules those out, before ascribing the miracle to the all-powerful cult of Dvorak.
Typing "TYPEWRITER" fast was simply a sales gimmick, so the salesmen could tell clueless PHBs "see! It doesn't slow typists down! I can type TYPEWRITER quickly!" And unsurprisingly, clueless PHBs existed in 1870 just as well, long before computers, and corporate purchases were made based on some rigged non-representative demo.
But there were real mechanical considerations there too.
Typewriters used to be purely mechanical things. Hitting a key physically pressed a lever, which swung a small hammer at the paper. Actually, at the ink ribbon. And on the hammer a letter or digit was embossed. (Actually, two. SHIFT would physically raise the carriage, so the second letter on the hammer hit.)
Because it was purely mechanical and involved densely packed thin levers, it was jam-prone. If you hit two keys at the same time, two hammers would try to occupy the same space at the same time. If they were coming from opposite ends, not much would happen: 99% of the time one would just hit on top of the other. But if they were adjacent (or almost adjacent) levers, the machine would jam.
That was the problem they tried to solve: keeping the machine from jamming. Which involved moving the hammers for most common letter combinations further apart from each other. Which, since it was a purely mechanical contraption, involved moving the keys too. (It wasn't as simple as defining a new mapping table, like on computers.)
And whatever effect it had on typists and typing speed, was side-effect rather than considered in the design. Whether it sped them up or slowed them down, it still ended up faster if it didn't require unjamming twice a minute.
However, here's another fun fact: the typewriter for which that layout was designed was very different even from typewriters manufactured after 1900. After 1900 the hammers were arranged in an arc in front of the paper. Before that, they were arranged in a circle or bucket shape.
That bucket shape is what the QWERTY layout was designed for. Which meant that moving the hammers had some weirder effects on where the keys moved. E.g., near the middle of rows, two adjacent keys would swing hammers from opposite sides of the bucket. Hence the "TY" in "TYPEWRITER" would not jam that machine, which is why they're still near each other.
It would, however jam a post-1900 typewriter.
So basically the short story is: QWERTY was never supposed to be ergonomic, it was supposed to just prevent jams. And even that was a quick mechanical hack, which missed a lot of fairly commong combinations. _And_ even for the purpose of preventing jams it wasn't that useful any more, for any post-1900 typewriter.
Yet, more than 100 years even after the new typewriter design, and half a century after keyboards being used in computers (which don't jam) we're still stuck with the QWERTY idiocy.
Its saving grace, though, is that basically on a computer keyboard _any_ layout works just as well. Neither jams nor alternating hands (which made sense back when you had to hit the keys HARD on a typewriter) are relevant any more. You just type faster on whatever layout you're the most used to. For most people that means QWERTY.
Which means there's little real incentive to switch to a new layout.
I'd challenge the idea that alternating hands has _any_ influence, good or bad, on a _computer_ keyboard. I keep hearing people repeating that myth, because it once used to be true on a mechanical keyboard, but never seen a study to show that it still applies to a computer one.
Have you ever used a mechanical typewriter? And I do mean the purely mechanical kind, for which QWERTY was made. Not the modern electrical ones.
It was a purely mechanical contraption, and you had to physically *HIT* the keys so the hammer would swing hard enough at the paper. To type anything in three copies via carbon paper, it was an exercise akin to hammering nails into a beam of wood. With your fingertips.
Even the position of the hands was different. Anyone who grew up on those won't get RSI (or not in the wrists) from a keyboard, because their wrists don't touch the table. The way to type on one of those was to have your hands hovering above the keyboard (a tiresome exercise in itself holding your arms like that), so you could launch your fingers downwards HARD at the keys.
So I can see how it was an advantage for those to distribute the effort more evenly and alternately between the two hands and arms.
But on a computer keyboard? Can't say I've noticed that typing, say, "SAD" would be any slower than "PAL". The pre-requisites to need to alternate hands just aren't there any more.
That said, I'm still not for DVORAK, because in the end what works faster is what you're used to. Someone used to QWERTY will type faster on QWERTY, and that's that. Including, yes, the imaginary monstrosity that you mention in the phrase: "If this were true, he would have located popular letters such as "A" and "S" at the far corners of the keyboard and located unpopular letters like "Q", "Z", and "X" under your fingertips, right where you don't need them." If you grew up on that, you'd type the fastest on that.
So I still see no reason to switch.
I'm just wondering about the whole alternating hands theory.
Actually, you know, I got used to the older shortcuts, which is to say CTRL-INS, SHIFT-INS and CTRL-DEL. And ALT-BACKSPACE for undo. They work just as well, if that's what you're used to. (Incidentally, they'd also be in the same position on a Dvorak keyboard)
Or I pretty much grew up on WordStar. To do the equivalent of the CTRL-C CTRL-V you mention, you'd have to use block commands, which were prefixed with CTRL-K. But an even more fun command group were those starting with CTRL-O. Don't even try doing that with the left hand only, it's not comfortable. Again, it worked well enough and people were typing whole books in WordStar. (And I stuck to Borland IDEs for programming until 2001 or so, because they let me use the WordStar key mappings.)
Or here's an bit of fun about German keyboards. The CUA Undo is CTRL-Z, and German keyboards are QWERTZ. I.e., CTRL-Z is where CTRL-Y would be on the USA keyboards. People use it with no problem, though. More fun for programming is that the square brackets have been moved on RIGHT_ALT-8 and RIGHT_ALT-9, instead of being a single keystroke, to make way for the national characters. And "@" (as used in emails) is RIGHT_ALT+Q. Again, seems to work OK, if that's what you got used to.
Basically as was said, _any_ keyboard arrangement works just as well, if that's what you're used to. Including, I'd add, any arrangement of the shortcuts on the keyboard.
However, the reverse is also true. Switching to a new arrangement just brings a long learning curve before you get back to speed. So buying Dvorak keyboards for the whole company to "improve their productivity" might have the opposite effect, as well as needlessly annoying everyone.
You see, real life monopolies are more complicated than the bakeries example. The price undercutting on individual items is the facet that the monopolist _likes_ you to see.
In reality, a workable monopoly is made of several interlocking parts. Where if anyone wants to compete with part A, they get part B and C brought against them. _That_ is what allows a monopoly to rise prices again, not the fact that the old bakeries closed down and new ones can appear back at any time.
E.g., let's say I'm a telecom monopoly, and control both the phone network _and_ the physical phone manufacturing. Let's say you're a bright young entrepreneur, you've invested a lot in R&D, and you try to challenge my handset business, by selling your own cheaper and better handsets. Because I also control the network, I can block your phones from connecting to it. Congrats. You have a ton of great phones to sell, except noone can use them. Sucks to be you. Your company dies.
That's the kind of interlocking combination that allows one to stay a monopoly even while offering less value for the money.
Or to give a MS example, consider the following classic example: in the days of NT4, Novell wanted to make their servers too able to act as an NT domain controller. Sure, you could go ahead and buy your workstation OS from MS, but you would also be able to keep your old Netware servers for the login.
Microsoft didn't even pretent to play fair. It simply informed Novell that if Novell ships such a product, Microsoft _will_ break it. And they did. They did every dirty trick to stop the clients from being able to use a Netware server for that. Novell eventually gave up.
This incidentally also shows why such an interlocking monopoly is bad for the consumers, even if they undercut some of the prices a little. It's used so that if you want product A, they can also use it to force you to use their products B and C and D too. Each part not only protects the others, but also serves to push the others down your throat.
If you want to use NT clients, hey, can we also interest you in an NT server to keep your network still running? You don't want NT clients? Well, then good luck with those Office docs you get as attachments from your business partners, 'cause we're not porting that to some other OS. Etc.
And such an interlocking nut is nigh impossible to crack without government intervention.
Even for a big corporation, the effort and cost to compete with that is entirely unreasonable. E.g., if you wanted to compete with Windows, you don't just need to write a good OS, you also need Office, you need server software, you need client software, etc. (Just think of all those people who asked "but will I still be able to run MS Word?" when you told them to switch to Linux. QED.) The entry barrier is lifted a helluva lot higher than just opening a new bakery.
1. First of all, seems to me like you didn't have much self-control to start with, if you ended up with a case of "hard to talk with those kind of images flooding your mind!" Not meant as an offense, just as a statement.
E.g., I'll go on record to say that I do look at porn, albeit in moderation. If nothing else, video games are still my first priority, so to speak. Can't say I've had anything even remotely similar to the experience you describe. If anything, I used to fantasize about my female schoolmates a lot more back in high school, _before_ I had any access to porn at all.
The fact is, some people just have a tendency to get obsessive-compulsive about something. In your case it happened to be about porn, but the phenomenon is more generic. It existed long before the Internet, and will exist if tomorrow the Internet disappeared. And it can be about anything else: e.g., workaholics can be a case of the same thing.
So to generalize that as either (A) a general effect of porn, or (B) as representative of 100% of the population's reaction to something, is just bull.
2. Again, because people can go obsessive-compulsive about _anything_, you can look at what happens when they do about anything else: not much other than the obssession itself, and its obvious effects. The "next best thing can only be real life" just doesn't happen almost at all.
E.g., video games are probably the most quoted example of stuff people going obsessive-compulsive about, some to the point of dropping out of school or work, getting divorced, etc.
By your logic "The more you get, the more you want... until the next best thing can only be real-life." We should see hordes of people running around with rifles shooting each other, to get the next best thing up from FPS games. Not to mention every 5th teenager would steal their parents' car and race it, because they've played Gran Turismo.
And, contrary to media bullshit, it just doesn't happen like that.
1. I don't think, say, the price of a Windows file server, any way you want to configure it, has yet come even close to what the price for a Novell server used to be. So the "but MS will raise its prices sky high and ruin us all!!!" scare scenario shows no sign of happening.
In fact, au contraire, some products are actually getting cheaper versions than before. E.g., XP Home Edition is cheaper than what you used to pay for Windows 2000. Yeah, it has some features cut out, but they're features 90% of the home users never needed. (And the other 10% can buy the Pro version at the same price as Windows 2000 used to cost.)
2. I know "TCO" is a swearword among us nerds, but that's a part of the price too. And with MS it's another reason why it's cheaper. You can use more common skills and need less work to use more than one program from them.
E.g., with Novell you pretty much got _only_ that: a file server. E.g., you used to get a bunch of disparate programs instead of Office, that didn't even have the same interface or talk to each other. (Good luck embedding a Lotus 1-2-3 table and chart in WordStar.)
3. "But IE doesn't innovate!" I keep hearing that, but it's the most piss-poor argument. First of all, IE is their free product. Second, it already works, and it has all the features that a browser needs.
You know, at some point it's time to stop bloating a progra. It's a browser, not some enterprise swiss-army-knife platform that does everything including version management, bug tracking, and is its own widget set too. It just has to be a window into the web, and let you see web pages. Much like a TV just has to let you watch TV programmes. No more.
4. You have a very warped idea of how a monopoly works. In your bakery example, there's nothing to keep a new bakery from opening once the "monopoly" raised its prices. The world isn't an immutable autistic nerd fantasy where nothing new normally happens, and nothing can be undone. IRL it's damn hard to actually get in a situation where you can rise the prices again sky-high with impunity.
5. Ah, but maybe the entry prices are too high? Not for another big corporation. A lot of other big corporations are busy trying to do the same price undercutting to MS.
E.g., OOo is mostly paid for by Sun. E.g., most of the work on Linux comes from people paid to do that, not from lonely bored nerds. Etc. They just pack it into a nice lie, instead of saying "we're undercutting MSs prices too". But it's the same thing. OOo is Sun's attack on Office in the _exact_ same "we'll give ours for free" way as MS killed Netscape.
6. And most importantly, as was said before, MS has to compete with itself all the time. Unlike, say, Coca-Cola (as another near-monopoly) which can sell the exact same product for eternity once it got the market, MS must give you enough reason to upgrade from your old Windows 98 SE to Windows XP, or from the old Office 97 we still use at work to Office 2005. That's what really keeps them maybe not "innovating" spectacularly, but trying to make a better product and keeeping the prices sane.
Heh. I must confess that I was actually waiting for someone to try to play the "but it says Instruction Set" joker, and shoot themselves in the foot in the process. Because, see, the instruction set is precisely what makes a G5 for example _not_ be RISC.
Ever programmed a true RISC? See, the matra "never do in hardware what the compiler can do for you", meant that their instruction sets were very basic by definition. The Reduced in RISC stands for an instruction set reduced to the bare minimum that could still work as a Turing Machine.
Among other things, RISC made famous the LOAD-EXECUTE-STORE sequence. Anything conceptual operation that involved more than one of those, _had_ to be broken into the individual steps. (As I've said before, its instruction set was very micro-code like.)
For example, let's take something like "ADD [EBX+1000], EAX" on a CISC. If the x86 were a RISC you'd _literally_ write it like:
MOV ECX, 1000
ADD ECX, ECX
MOV EDX, [ECX]
ADD EDX, EAX
MOV [ECX], EDX
Each and every single building block of the complex instruction, such as loading the data, adding it, and writing it back to RAM, _had_ to be a separate step.
And if your conceptual operation logically involved a loop, e.g., adding two vectors, you _had_ to write the incrementing, comparing and conditional jump explicitly. Because anything else would be implementing them in hardware, instead of letting the compiler do it for you.
What I'm getting at is that _any_ SIMD (single instruction multiple data) instruction set is by definition _not_ RISC.
Now kindly get yourself a copy of the G5's instruction set. And look at it. Especially look at AltiVec. It's SIMD, isn't it? Now how the heck does that count as RISC?
Well, bingo. If it wasn't CISC already, AltiVec did turn Macs into CISC.
So the true revisionists are the clueless marketroids at Apple, who still hang on that buzzword as some mystical quality that their product has. Never mind that the G4 was losing badly in all benchmarks, it's cool because it's RISC.
No, it no longer is. It's a good CISC design. It's good, yes. I wish Intel had an instruction set like that. But it's CISC nevertheless.
OK, duly noted. Let me rephras that: "RISC is dead on the _desktop_." Could be that some ancient true RISC design is still produced for washing machines or such :P
Pipelining was possible and used long before RISC CPUs. It was just called "micro-code" back then.
So at some point CPUs just had enough transistors to return to something that had been used on minis and mainframes long before RISC. RISC had _nothing_ to do with it. If anything, RISC was born from micro-coded designs, not the other way around.
In a way, though, unlike other marketting BS, this one isn't entirely inaccurate. That much I must admit. A RISC CPU isn't that different from a micro-code execution unit. RISC was if anything else simply exposing the micro-code to the outside world, and more or less just letting the compiler generate micro-code. So in a way, yes, they _are_ RISC inside. (Then again, so were the mainframes and minis in the 70s, then.)
However, the opposite is also true. The moment you wrap it inside a more complex design with a pipeline, out-of-order scheduler, and and a complex decoder, the whole design (as a whole) is no longer RISC. It may have a RISC core (actually an micro-code execution unit) burried deep inside it, but the whole design isn't RISC any more than a TV is a transistor.
That's what I meant by "RISC is dead". Yes, everyone may have one of them buried deep inside, if you really want to call it that way, but the whole design is wrapped up in other layers that make it really a CISC.
Well, then educate me. What does constitute a RISC computer? Take the block diagrams of a G5 and of, say, a Pentium 4 and educated me: exactly what's in a G5 that makes it a RISC, and obviously isn't there in a P4? No, seriously.
The _whole_ idea and advantage (for that time) of RISC was that it basically exposed its microcode to the outside world. (Well, not 100% accurate, but as a metaphor it will have to do.) Any instruction required only minimal decoding to directly drive the ALU and the rest of the CPU.
Exactly how does a G5 still fit that vision?
Except at some time, and after some Apple ads, it became _fashionable_ to use RISC as a buzzword. Everyone had to claim they too were fashionably RISC.
E.g., when the AMD K6 came and had a plain-old micro-coded architecture, they couldn't just call it "micro-coded". They just had to find idiotic marketting euphemisms that boiled down to "yeah, but internally it's RISC-like. Internally we decode those CISC instructions to RISC stuff, you know." (No, it isn't. It's what we've been calling "micro-code" for decades.)
And ever since every single CPU had to do that too. You no longer hear anyone just claiming "micro-code", they now "RISC-ify" the instructions or some other such crap euphemism that a marketroid pulled out of the butt. "RISC-ifying" stuff is obviously more fashionable than saying you use micro-code like in the 60s.
So, yeah, RISC is a paradox. For a dead technology, it sure became a big marketting buzzword.
But anyway, if any of the above is wrong, please do explain how.
Until then, yes, you just live up to your sig: "Fucking 13 year olds". Maybe next time you can read a technical manual first, instead of just throwing a tantrum when reality doesn't match Apple's ads.
A long time ago, in a galaxy far away, CPU transistor budgets were measured in tens of thousands. You had _barely_ enough of them for either more registers _or_ a more complex decoder, but never both.
;) is simply that you just couldn't have _both_.
This begat RISC. A CISC computer had a more complex in struction set, but that barely left it with enough transistors for a couple of general purpose registers. A RISC computer, on the other hand, went by the mantra "never do in software what the compiler can do for you", so it had an over-simplified instruction set, but then it had enough transistors left for more registers.
In a sense each of the two was too expensive for _someone_. For CISC, registers were too expensive. For RISC the decoder was too expensive. In truth, both were expensive, and the grand unified theory
Fast-forward a bit, and registers are _not_ expensive for CISC any more. You do mention "what will prevent Intel/AMD to add a technology which could use multiple sets of registers", so the answer to that is: they already do. Both have huge register stacks they internally use for renaming. (E.g., when you swap EAX and EBX, the data isn't really copied, but the register from that huge stack which is currently EAX and the one which is currently EBX, get renamed to EBX and EAX respectively.)
Either way, they already have the Cell's 128 registers, and some even have 256 registers. You just don't see them from the outside. (Which is a pity, since compilers could really use them.)
Is there something to stop them from exposing more of those registers to the outside world? Nope. The AMD Athlon 64's (now also addopted by Intel) "64 bit extensions" already do just that: they double the number of general purpose registers visible to the program. That's largely what gives an Athlon 64 the speed boost when running 64 bit code: the extra registers.
Is there something to keep them from doubling or quadrupling them again? From a technical point of view, nothing whatsoever.
What's been keeping them so far is the software backward compatibility. A Pentium 4 still has to run code written for a 486. So whatever changes you do to their instruction set, they must leave the old pre-existing instructions unchanged. And there simply aren't bits left to add the new registers without changing the whole instruction set.
The migration to 64 bits has been such a good excuse to come up with a completely new instruction set, with more general-purpose registers. But such excuses are few and far between.
As for RISC... it died, it lost the battle. Yes, Apple and IBM still use it as a marketting buzzword, but that's it. There are _no_ RISC CPUs still being produced.
The G5 in Macs is simply a CISC with more registers and a better instruction set, but it's CISC nevertheless. It's internal structure is _not_ RISC, and AltiVec is _not_ RISC. They're in fact contrary to everything RISC stood for.
Ditto for Sun's UltraSparc.
(And everyone arguing that a G5 is RISC, has obviously never programmed a RISC CPU before. You had to take care of every single detail in software, because of the mantra "never do in hardware what the compiler can do for you." Even recovering from a pipeline overflow when an interrupt came, you had to do that in software.)
Hope this helps.
Well, it's probably off topic, but the bogus data and their use in auto-inflating statistics are one thing I've been wondering about too. Of course, I haven't done any study or anything, so it's only tinfoil hat hypothesis at most.
For example, I'm in a gaming channel and some allegedly 16 year old horny kid drops by and tries to score some "cybersex". Had to personally persuade one or two to get the heck out, because no op was around.
How many of those actually are actual kids and potential prey for pedophiles, and how many are actually some FBI agent? And I'm not against the FBI helping keep pedophiles out, but _if_ that's what it was, it was starting a pedophile conversation in a channel that didn't have any to start with. Worse yet, a sex-related conversation in a channel that _does_ have children in it. (You know, lots of games are only PG-13, or even less.)
I.e., it was doing more harm than good. Or arguably did only harm and no good.
And how many of those end up in some statistic to justify one's own budget?
Or someone drops by and starts asking for a crack for that game, or where he can download a warezed version. Or worse yet, advertising some warez site.
I have no doubt that most were truly clueless wannabe pirates, but... were any of them actually BSA/FBI/publisher/whatever drones trying to see who they can bait? Or deliberately polluting the channel to make pirates comfortable about talking about it?
The problem, again, is that _if_ that's what it was, it's pollution. A bunch of us have a hard enough time keeping the channel clean of that kinda stuff, and making the pirates _not_ comfortable about it.
And then someone comes and spends two hours (until an op finally drops by) spouting crap like "only idiots buy what they can download for free", and generally promoting piracy full time. _If_ they're from the BSA or the publisher, it makes me want to bash not only their head in, but also their boss's.
And again, how many of those end up in some self-justifying statistics? "Waah! Poor us! Piracy is rampant! Yesterday on IRC they were again talking about how only idiots buy our software instead of downloading it!" Right, except was it really a real pirate?
Oh well.. guess we'll never know. Makes for a good tinfoil hat theory, though.
Actually, my whole point was that those are the _least_ representative of IRC as a _chat_ platform. We're talking about channels (A) not used to chat, (B) not usable for chat even if you wanted to, because as chat with 1000 people simultaneously would just scroll your screen faster than "ls -R /" (or "dir /s c:\" in Windows), and (C) mostly populated by bots anyway.
Now maybe they still would be somehow representative if it weren't for point C above. I don't know by what criterion a channel with 1000 bots is representative of (far more) people actually chatting in the normal channels. If anything, the bots are a creative (ab)use of the IRC protocol, rather than IRC as a _chat_ platform.
Well, that's precisely why it's flawed.
Even if you assume that those 10 channels has 1000 users each, that's 10000 users doing illegal stuff. Well, that's a spit in the bucket. If you list the channels on, say, Quakenet, there are an order of magnitude more _channels_ than those 10000 users.
The study is also flawed from the start because any channel that big is mostly just populated by bots. How do those count as users, it's beyond me.
And it's useless for anything _but_ binary transfers. Try having a conversation with more than 100 people in a channel, and it already is impossible. With 1000 it's simply out of the question.
So such big channels are if anything the _least_ representative of IRC, _and_ a minority of users. A study based on them is plain old bogus.
So he goes into warez channels and concludes that they're used for illegal stuff. Well, gee, ain't that a surprise. (Sarcasm there.)
So it's not just like doing a crime-rate study on the 10 largest city. It's like doing a study on the 10 largest _prisons_ and concluding that 99.9% of them are criminals (or at least have commited at least one major crime in their lifetime), hence the whole country is a country of criminals.
Or it's like doing a web study based on Slashdot and concluding that world-wide 99% of the people are computer-savvy nerds, and that Linux is the most popular OS world-wide, more used than MS Windows and MacOS/X combined by an order of magnitude.
I meant between these two:
v oke-expr>
1. <invoke-expr method="myMethod"><evaluate>record</evaluate></in
and the plain old
2. myMethod(record)
Honestly, 99% of the time XML is used as a buzzword, nothing more. And in a lot of cases, like this one, it just means "we had no actually useful ideas, so we're gonna give you some fashionable snake oil instead. And we hope that your PHB is stupid enough to buy it based on buzzwords alone."
.class files (for Java).
/., take the two following representations:
Since we're talking programming languages, what's the big huge gigantic benefit of having the indentation and code handled through XSLT?
Any modern IDE does lexical and syntactic parsing on the fly. It doesn't need XML and XSLT for that.
E.g., I have Eclipse open right now. I can edit the indentation rules however I want to have them, and reformat. It didn't need some idiotic XML syntax for that. It doesn't need some stupid XML tags telling it "instruction starts here" and "instruction ends here": the language syntax already tells it that.
I can hear the over-used argument "but XML is a standard!" Well, C is an ISO standard too. "But XML has standard parsers!" YACC and LEX are even more standard nowadays.
Same for "extending" it. I don't need some idiotic XML file telling it the parameters to my methods, any modern IDE takes them directly from the headers (for C) or
I can just type "MyClass mc = new MyClass(); mc." and then hit CTRL+SPACE in Eclipse, and it will show me all the methods and public members I can use from an instance of that class. And the parameters and docs for those methods. Again, it didn't need some XML file for that: the standard language parser was enough.
And it seems to me like it's missing the whole point even of XML. The whole idea of XML (and SGML before it) was to have a humanly readable text format for data that was otherwise saved in proprietary binary files noone could read.
Well, program code was always text and humanly readable. So I'm at a loss as to what would XML bring.
To use the example in the text on
1. record
2. myMethod(record)
Seems to me like number 2, the traditional way is actually more humanly readable.
1. The only way to get a better computer with than a Dell at the same 500$, is... to pirate Windows. Even an OEM or upgrade version of XP Pro or Windows 2000 Pro will put quite a dent in that 500$ budget.
;)
Build _two_ computers at that price? Well, gee, just two OEM Windows licenses will take up most of that money. So if you're trying to tell me that you can build computers for less than 100$ each, I'm damn interested to see what goes into them. I want one of those too.
So the comparison is... what? "Stealing is cheaper than buying"? Well, gee, ain't that a surprise
And yeah, you could put Linux on them, but other than terminal nerds noone actually wants Linux on their computer. Joe Average will want Windows on their machine, one way or another, and Dell's price already includes that. (And Apple's includes MacOS/X.)
2. Plus, since I _do_ build my own computers, I can tell you that over the years it's been just a pain in the butt. I've had my CPU overheating and crashing due to a bad heatsink. I've had data loss, repeatedly, due to hard drives overheating in a bad case. I've had such duds as buying two different hard drives in a row that were dead on arrival and had to be RMA-ed. Or like a third-party 9800 XT which mysteriously died for no obvious reason after a couple of months. Etc.
Now for some people all this hassle counts as fun. You have to also realize that for most people it _isn't_. Anyone who isn't already into building their computers as a _hobby_, is very much better off paying to have it assembled by Dell.
3. Noise. By and large this is a sub-case of 2: crap components designed by the cheapest unqualified monkeys. Or by the marketting department.
Except in this case it's not a component that dies suddenly, it's one which works badly by design. And badly in an annoying way.
About 99% of the OEM computer cases are designed by clueless idiots, with _zero_ clue of or consideration for airflow or noise. They put a lot of fans, but have them sucking at sheet metal and not achieving anything except to make that metal vibrate. Or in other creative ways not being able to move more than 5-10% of the fan's rated airflow. They're just designed to make a lot of noise and look funky, nothing more.
(And a big "fuck you" goes to ThermalTake, while I'm at it. That's an elite among the elite, as retarded case design goes.)
By comparison, Dell's cases (and IBM's and Apple's too, and a few others) are actually designed by engineers, not by graphics designers. They actually achieve better cooling with _far_ less noise.
Etc.
Just a thought: Maybe that's why people buy from Dell or Apple? 'Cause that price includes a usable OS, and a warranty, and it's all put together and tested by someone else?
Just FYI: I hope you do know that there are a bunch of online shops which will let you configure the extra RAM far cheaper than Apple's web site. You know, Apple's own online store isn't the alpha and the omega.
So there you go. 1GB RAM without opening the case yourself, and without paying a ludicrious 500 bucks for it either.
The "dunno what all those buzzwords mean, but we must have as many of them as possible" kind of mentality. Or as I like to call it: BDA (Buzzword Driven Architecture.)
They don't know what EJBs are (as illustrated by your example where they didn't know the difference between EJB and J2EE as a whole), but they've read in some IT-for-retards magazine that Sun says EJBs are great. So they must have some.
And for that matter, XML. And XSLT. (Just writing the data or using a template is soo 1990. Nowadays you _must_ have a small XSLT program which produces the output.) And SOAP. (Every internal call must be SOAP, you know. Just plain-old calling a C++ or Java method is soo outdated.) And have a scalable enterprise messaging framework. (Why just read stuff from a database, when you could send a SOAP message to an MDB to read it, and wait for the asynchronous response?)
And I've seen more perverse use of buzzwords which aren't even technical terms, but end up being wanted in the project anyway. E.g., "scalable". So you get a client explicitly wanting EJBs in their small web-app, because Sun said it's a scalable architecture. Uh, as opposed to what? As opposed to just using a load-balancer and a cluster, which also scales linearly?
Don't get me wrong, I'm not against EJB, XML, XSLT, JMS or SOAP as such. They have their uses. But like any tool, they're good for one class of problems. Just like you've said, there are plenty of problems which don't need EJB.
That is, until the client comes with a long list of buzzwords they absolutely must have...
Though to be entirely honest, _both_ sides are equally guilty in this. There are clueless PHBs who demand buzzwords, yes, but equally there are dishonest programmers using real projects just as a playground to get new buzzwords for their resume. A lot of projects which are just a sad collection of buzzwords, not because the boss wanted to have them, but because someone wanted those buzzwords on his resume.
Nothing personal, but I hate the system that created you. More to the point, those idiots you "do lunch" with.
Business and technical decisions are taken by people _completely_ unqualified, based purely on "oh, I know that guy. We played golf. Let's buy whatever he's selling." Or on "but the nice salesperson said it would solve all the problems, including cancer, AIDS and world hunger." Or here _literally_, and in that manager's own words, a broken product got bought "because it had the nicer powerpoint presentation." (To make it even more surrealistic, a product noone needed.)
And I've been on the receiving end of that fuck-up entirely too often. Completely dysfunctional "solutions" are bought like that. And then we engineers and admins have to make a completely broken product work. And if it still doesn't, then it obviously has to be our fault. Because the nice salesperson told the PHB that it works, and surely the nice salesperson couldn't have possibly lied to the customer. It must be those mean engineers that sabotage it.
And even _if_ the problem does eventually get to be acknowledged by the PHB, the next result is more lunches done, more colourful powerpoint foils are presented, and the PHB buys an even more broken v2.0 of the same product. (Or, don't laugh, some PHBs here are looking forward to version 6.0 of a totally broken product.) Surely now all problems are fixed. Because the nice salesperson said so.
So I can't say I hate you, as such. Where there's a demand, someone creates the supply. I.e., if some PHBs actually want to be lied to and scammed, yep, the system also produced the marketting people who do that. Perfectly normal economics there.
What I would however like to see fixed is the system.
For starters, I'd like to see some serious liability in this industry. Because this hiding behind an EULA that says "whatever happened, it's your problem, not ours" is just legalizing bigger and bigger marketting frauds. So I'd like to see people and companies facing a billion sized lawsuit if they mis-represented a product as doing what it really doesn't.
Also, while I guess one can't outlaw bullshit buzzwords as such, I'd like to see it legally mandatory to clarify (A) exactly what it means, and (B) exactly on what case studies it had that effect.
E.g., "synergy"? Ok. Between what and what? On what cases did you notice that synergistic effect? And how big was it?
E.g., "lower TCO"? Fine. On what use case? Compared to what? (Most of this crap would only lower TCO compared to carving that data by hand on stone blocks, like in the Flintstones.) And how much lower was the TCO, then? Does that include the cost of the uber-expensive consultants to make it work, or?
E.g., "scalable"? Good. Scalable in which way? And in which way is that better than just the plain-old using a cluster and load-balancer?
Etc.
Then maybe we'll see _some_ (minimal) honesty in advertising in our lifetimes. And then we nerds wouldn't have to be disgusted by the whole marketting bullshit.
The second big problem I'm seeing is: how the heck did we get to the point where CEOs/CIOs buy bullshit that sounds cool without asking someone who knows?
I mean, for example, let's take everyone's favourite comparison between computers and cars. So let's say a company, (A) produces cars, and (B) wants to make its own brand-new intranet system.
And here's the funny part:
(A) to make cars they actually trust the engineers what should go into that car. If the engineers say they need this and that gear or screw, that's what the company buys. I should hope the CEO doesn't come and say "nope, we just got this cool deal on ship propellers, so you have to use that in the cars from now on."
(B) to make the software, they proceed to thoroughly ignore and avoid the engineers, buy some bullshit from the biggest liar, and then blame the engineers and admins if it doesn't work.
It's dunno, like they're affraid to ask. It's like they'd get "STUPID" tattooed on their forehead if they ever asked a technical question, or accepted a recommendation from their own IT department.
In practice, most of us would actually respect them more.
I mean, dunno about others, but I don't expect a manager to be a Ph.D. in computers. But I do expect him to be good at his job: management. Which also includes delegating. Whatever he doesn't personally know, or isn't in his job description, his job is to find someone else who knows or can do that. That's what management is all about.
By contrast someone who just buys crap based on bullshit buzzwords rather than ever asking, is for me a sad clown. He just showed that he's incompetent at doing his own job: management.
It sorta makes me wonder how did those upper management types start wanting buzzwords to start with. But more importantly, this hurts this industry in pretty perverse ways, not just in the obvious "so the biggest liar gets the sale."
For example time after time again, we run into the perverse problem that PHBs don't just prefer bullshit bingo to technical specs. They think that technical specs _are_ pretentious bullshit buzzwords.
For example, if I say that a program is based on MDB (Message Driven Beans) and SOAP, it really means "it complies with the EJB specs, the whole book that that spec is, especially the part about messaging. Which also tells you that you need a J2EE application server to run it. And you have this other SOAP spec that tells you _exactly_ the message format _and_ how to parse it, in case your engineers need it."
I.e., there's a lot of technical information condensed into those two words. (MDB and SOAP.) I _could_ copy and paste the whole specs, or just use those abbreviations to tell people where to look for all the technical details.
But try telling "based on EJB and SOAP" to a management or marketting PHB, and they won't even think "bah, I don't have time for technical details." They won't even hear that as technical detail. They'll hear "based on pretentious made-up buzzword 1 and pretentious made-up buzzword 2".
Somewhere deep down in their psyche, they just "know" that we do nothing all day long but think up buzzwords to intimidate them with.