Stallman has a special place in the book "Hackers" by Stephen Levy. The is the book that dubbed him the "last true hacker". Incidentally, many, such as ESR, believe that Linus was the man to disprove that title.
The book focuses on the history of computing in three phases, the infamous TMRC / AI Lab at MIT, the Homebrew Computer Club, and the early days of video game software for Apples. However, there's a small section at the end about RMS and GNU where Stallman gets to air some of his ideas. It's a nice way to close the book, because it connects back to the tradition that started at MIT, and was almost destroyed after the days of the Altair. And I, for one, have always found RMS's mission interesting.
Anyway, whether or not you like Stallman, Levy's book is a good read for any geek. It's a great way to connect with hackerdom's roots.
--Lenny
PS- I also recommend "The Soul of a New Machine" by Tracy Kidder. It's a good look at the hardware side of things, and though it was written in the 70's, much of the book is still relevent today.
A lot of the discrepancy between GHz and performance seen in P4 chips is explainable by Intel's choice of pipeline design. Intel chose to make extraordinarily deep pipelines on the P4 chips, which allows them to crank the clock speed up up up. Sounds great, huh?
The problem is that it's a bit of a false gain. Most of the performance gained in clock speed is lost again to the serious hit you take at each branch misprediction. If you could keep your ultra-long pipe full, you'd be cruising, but you can't. Occasionally you will mispredict, and have to flush that pipe. One your pipe becomes as deep at the P4, that performance hit starts eating your lunch. Suddenly, most of your processor is sitting empty most of the time.
So, clock-for-clock P4's get slaughtered by Athlons or PIII's. But Intel doesn't care. They know that the majority of consumers buy based solely on that magical MHz/GHz number. Most consumers are not sophisticated enough to realize that there is more to performance to clock rate.
This move on Intel's part was motivated by marketing rather than management. They are playing on the uneducated masses. It is all but directly deceptive, and I hope they get their clock cleaned by the press for it.
without a corresponding "standard" to describe the structure the file should have. If you want regularity, we need a well-accepted consensus on the different styles of options that can be used, and syntax for representing them.
If you had standard meanings for different kinds of config options and a standard format, you could get your wish of a single tool (be it command-line, slang, or X) being used to parse and modify all compliant config files. I've considered implementing something like this, myself. The problem, of course, is less in implementing it than in getting all of the disparate projects to accept it.
The only groups that might have the power to start this change are the distros. Red Hat seems reluctant to define standards, as they don't want to be seen as "pushy". Mandrake doesn't have the clout. To me, that leaves Debian and possibly Suse. If Debian came out with a standard, started using it for their tools, and developed a nice, simple interface, I think they could start persuading others to follow suit. It's a good idea, but it will take a great deal of persuasion.
But back to my earlier point point: simply moving to XML buys you nothing but complexity. What you really want is a common ordering and syntax to the different files such that they can be edited by a common tool. That's all well and good, but that can be achieved *without* XML just as easily as it can with. I see no inherit advantage in using XML, except the gain in "buzzword compliance".
You bought the car, and you own it. Increasingly with digital (or old analog) media, the notion is one of licensing, rather than ownership. Sorry, you can't play that DVD on your Linux box because that would break your *license*. You own the disk, but that's not what you care about. You care about the content it stores, which is intellectual property that is licensed to you.
The point of the article is that if the Powers That Be want to move to a licensing model (and they do), it seems fair that we should only have to license a product once. This *is* reasonable, but RIAA et al don't want to be reasonable. They want to limit you as much as possible, and drain as much money from you as possible.
My answer to the poster about his tape is that fair use allows personal copying, so he should feel no remorse about getting an mp3 of a song he already has. It is only questionably legal, but it is spiritually similar to making an archival back up at purchase time. Archival backups are perfectly legal.
In my case, I have no problem burning a copy of a CD that I already own. All too often CD's (even new ones) are improperly pressed and start skipping horribly on me. It's ridiculous that the CD companies' QA isn't better. They are selling inferior goods. But since I've already licensed the music, I just press my *own* damn CD and use that. The music companies don't like it, but it's legal.
How is this mocking KDE? When I saw the name "KDE League", that's the exact joke *I* thought of too, and I'm a KDE supporter. (If any one cares, I've been using KDE since KDE 1.0beta2) "League" is just so superhero-esque, the joke springs to the American mind.
As for spelling, it's tue tat Slshdot is bade abut typoes, but this has been pointed out quite enough by now.
Your post is just flamebait. However, the blind RMS and open source bashing on Slashdot has gotten way out of hand, so I feel obligated to respond.
> they're all hardcore Stallmanists
Not true at all. Debian is an Open Source movement, not a specifically Free Software movement. There are plenty of packages in Debian that are non-GPL. But *all* of them must conform to Debian's guidelines, which basically coincide with the Open Source definition. I would say that Debian, as a whole, shares more ideology with ESR than with RMS. How does this make them "Stallmanists"?
> who believe that communism onlt failed because of the oppression of evil American capitalism.
Blatent troll here. I follow Debian, and I have never seen any discussion that smacks of Communism, just solid software design and openness. Sharing source code is not at all the same thing as sharing material items, let alone *enforced* sharing of material items. If you honestly believe the sharing nature of free software is fundamentally evil, then there is really nothing I can do to reason with you. If you don't want to share your software, don't contribute to open source projects like Debian. But don't deride them for having beliefs.
> Unfortunately this is spoilt by its overeager adherents who are all too willing to bash other distributions for not being as "pure" (a term that brings to mind connotations of eugenics and ethnic cleansing) as they are.
Who are you arguing with? I haven't seen any such comments around here. Debian wants to ensure that their distro is completely open. That does *not* mean that they are attacking anyone else. Does their mere existence threaten you?
And the last point, RMS himself has no problem with businesses. His problem is with closed software. If a business (such as Red Hat) produces and uses Free Software, there is nothing for "Stallmanists" to get upset with. I am on Debian-devel, and I see plenty of support expressed for the Debian spin-offs. I have *yet* to see an attack on corporations basing their distros on Debian.
Itanium (code named "Merced") is the first implementation of Intel's new architecture dubbed IA-64. IA-64 is the long-awaited replacement for the geriatric x86 architecture. Intel developed this new architecture jointly with HP. (actually, truth told, what is now IA-64 was originally HP's internal project to replace their PA-RISC architecture. Intel hopped on board sometime later)
Itanium has been in development for quite a while, but has been delayed time and time again. The project has hit all sorts of roadblocks, one of the most fundamental of which has been the lack of efficient compilers. The IA-64 is radically different than x86 chips or even RISC-style chips. Architecturally, it is a VLIW (Very Long Instruction Word)-style processor. This type of architecture simplifies the construction of wide superscalar designs (that is, processors that are capable of issuing multiple instructions in a single cycle). It has good theoretical performance, but is considerably more dependent on compiler technology than more traditional designs.
Very few processors have been designed in this style, and the corresponding compiler technology is still rather primitive. This, along with internal problems at Intel have greatly delayed the first implementation.
Infact, the part was supposed to be out right now. Obviously it isn't, and Intel, realizing it wasn't going to have Itanium in time to compete with suddenly-relevent AMD's K8 product, panicked and had to put Itanium on the backburner to piece together another x86 to have something to pit against AMD. Hence, the Pentium IV was designed. Intel wanted to be beyond x86 processors by now, but the delays in design of Itanium forced them to squeeze out one more x86 to feed the market.
Comically, the second generation of IA-64 (code named McKinley) is being designed at HP and has been progressing quite nicely. So much so, that some people fear McKinley will actually beat the older project, Itanium, out the door. With this as a possibility, the question of whether Itanium won't be scrapped altogether arises.
The Pentium-IV is no more RISC-ish than the Pentium Pro / Pentium II / Pentium III chips were.
Modern AMD and Intel chips both implement RISC-style cores with x86 translators on the front end. So, the instruction set has not changed. Changing to a program-visible RISC instruction set would mean losing support for legacy applications (read: everything) and starting over. x86 could be implemented in a compatibility mode (as is being done in IA-64, Intel's new architecture that was supposed to have replaced x86 by now), but it almost certainly take a performance hit.
There are probably some nuances to the Pentium IV that compilers could take into account for small speed ups, but they won't make a dramatic difference. Compiler support is really not the problem with this part.
The *real* problem is that, in a purely marketing-motivated effort to inflate clock speeds, Intel designed the Pentium IV with a suicidally long instruction pipeline. This allows them to jack the GHz rating up up up, but it does *not* result in greater performance. The reason? When you get into extremely long pipelines, branch mispredictions start eating your lunch. Sure you have an extremely high theoretical performance, and if you could keep the pipeline full of instructions (that is: all of the processor busy at once), you would be flying like a bat out of hell. But you *can't* do that. You will mispredict periodically, and everytime that happens, you have to flush the pipeline and start over. The longer the pipeline, the bigger a hit this is. This part will realize drastically less of it's theoretical performance than the Pentium III or Athlon parts.
So the Pentium IV is destined to sell in a GHz rating far above the comparable AMD offerings. Yet, it's actual performance will be pitiful stacked up clock-for-clock with AMD parts or with the Pentium III. Intel knows this, but they also know that the average consumer buys a computer based *solely* on that magical GHz rating, never understanding the other factors that contribute to actual performance.
I sure hope their is a consumer backlash when people start figuring out that their Pentium IV's aren't as fast as they think they should be. This move on Intel's is quite deceptive.
> Obviously, the pentium 4's performance lags (or will) behind Thunderbirds of similar clock speeds. But this thing is also a.18 die process.
You are being a bit loose with terms. The Pentium 4 is fabricated with a.18 micron process. This means that an individual gate measures 0.18 micron wide (or is it long? Damn...where's my VLSI text). Now, the smaller you make each individual gate, the more gates you can pack into the same square area of silicon. Or, if you keep the same design with the same number of transistors and "shrink" it to a smaller process, the same part can be manufactured in a smaller die size (square chunk of silicon).
Cost for semiconductor manufacturing is primarily a factor of silicon area, so reducing the die size is a big cost-savings per part. Also, smaller die sizes increase yields. Defects are inevitable, but with careful fab management, you reduce defects to a certain number per wafer. Each one of those will (likely) ruin a die. But if the dies are smaller, less of the overall wafer's area is lost to that particular defect. Thus, the smaller your die size, the less any given defect will cost you.
But there's another very important advantage you get from a smaller process. A smaller process generally translates to a higher clock speed. Why? Gate capacitance. Each gate is essentially a capacitor that has to be charged or discharged to switch the gate on->off or off->on. A larger device has a greater capacitance and hence takes a longer time to charge/discharge. So, larger devices take longer to change state, and hence can not be clocked as fast.
So, in summary, a process-shrink should improve yield for Intel, which means lower cost per part. It should also help their engineers up clock speeds on the component. However, at any *particular* clock speed, performance will not be affected. Heat dissipation / power consumption should be reduced, but otherwise, clock for clock the consumer will not notice a difference between processes.
...anyway, that's some of the engineering behind this. In terms of forecasts, I think Intel has been caught with it's pants down. They have an inferior product, and, if the world is sane, AMD will clean their clock in the coming year.
> there's a very good defense of the electoral college system available on the washingtonpost.com site. you can find it here.
Your statement intrigued me, because I have yet to find a decent defense of the system.
...this was not a decent defense. The only point that made any sense at all was that the electoral college encourages candidates to campaign in *all* states. Given it's all or nothing nature, the college pushes the candidates to focus on issues directed at a particular state, which might go neglected otherwise. I'm not sure this is a very good argument, but atleast it *is* one.
The rest of the article bashed opponents of the college by dismissing them as "majoritists". Not much of an argument there...they are majoritists by definition. That does nothing to detract from the argument itself.
Then he seems to propose that, while the electoral college *does* dilute representation in larger states, it is a similar institution to the Senate, and hence legitimate. This, of course, assumes that the Senate is legitimate. This is ridiculous: the simple fact that it exists does not make it right. Presumably, to demonstrate the legitimacy of the Senate, George Will would compare it again to the electoral college.
No, *both* of these entities were created to appease state's rights advocates at the time the constitution was drafted. The smaller states feared giving up too much control to the larger states, and thus this compromise was needed to forge the union. That is the historical motivation behind *both* institutions.
In today's America, I hardly see the need to continue this anachronism. It's not as if Delaware will secede out of fears that the US government would have too much control over them. Today, citizens, in general, consider themselves Americans before they consider themselves a citizen of their particular state. In light of the changed face of America, what purpose can the college hold?
One answer George Will gives is the perpetuation of the two party system. As mentioned, Perot pulled in 19% of the popular vote, but 0% of the electoral vote. The "legitimate" candidates were nicely shielded from that upstart. But who says the two party system is worth perpetuating? Certainly, many here on Slashdot are critical of it. In general, why should we enforce the limiting of our choices?
Anyway...I think you see my problems with the article. I remain unconvinced that the electoral college exists as anything but an anachronism. Arguing that it hasn't caused much harm does not lessen it's obsolescence.
You do understand that software controls the hardware, not the other way round, right? It's not like this was made incompatible with Linux, it's that Linux hasn't been made compatible with this yet.
It's understandable that AMD's first priority would be to get Windows up and running. That's where the big money is (for now). You'd better believe that they'll make sure Linux runs on it as well, though. They are quite interested in providing a solid platform for Linux.
> we are talking about the die that passed the initial wafer probe and then were packaged and then fail somehow at or after the packaging or even shipping stages.
Yes, we definitely are. I only brought up the fact that the industry already routes around process errors in DRAM's to demonstrate a point. He seemed frightened by the possibility that future DRAM's we buy might not be 100% "clean". I wanted to demonstrate that 100% clean isn't necessary, and infact isn't produced now, by and large. What *is* necessary is 100% functional parts. DRAM manufacturers know this, and use it to improve yields, thus driving down cost. No foul play there.
> So in conclusion, I think there are plenty of us at./ that have a clue about memories, memory protection architecture, fabrication, production, and testing techniques.
I expect there are, but none of them were posting. Instead, most of the posts demonstrated a clear lack of understanding of the process. The consequences of techniques like Linux's remapping seemed to worry the original poster, and I wanted to explain why it wasn't something to worry about since a similar process is already performed quite successfully. Further, I wanted to emphasize that this is a perfectly valid technique for increasing yield, and is transparent to the user. It isn't like the manufacturers are trying to rip people off.
> Why don't you just allow us to think that is't really cool to use software to lock out blocks of RAM?
I'm not saying it isn't cool. Some seemed weary of the idea, though, and I wanted to point out that their present DIMM's use something very much like this. As long as the software can do this transparently (as the hardware does), what does it matter to the user?
> but I seriously doubt that they are applicable to such dense cells as memories
Believe me: they are. Think of it: a massive die area that will be completely destroyed by a single speck. Wouldn't you prefer an ever so slightly (say 5-10%) larger die that can withstand one or two specks? The redundency is very easy to use in a homogenous structure like DRAM (millions of identical cells). All that has to be done to "swap in" the replacement RAM block is to modify some address lines. That can be done by electrically blowing fuses on die, or through laser modification. One of my former employers was *most* found of the laser approach. It added quite a bit of flexibility to their designs.
I'm amazed by how little this crowd know about details of semiconductor manufacturing. Defects are unavoidable! There, I said it. With the transistor sizes that we are pushing today, a speck of dust ruins an entire blcok. All you can do is *limit* the extent to which this happens by being as strict as possible with your clean room. But *some* contaminents will always get through. Perfection is unachievable. You have to accept this.
Alright, so we've accepted that some dies are necessarily going to be damaged. Why not make the hardware such that it can resist imperfections? Well, actually we do. RAM being as simple and homogenous as it is, lends itself well to this approach. Here's the idea: you add extra "blocks" of memory to a decode line. Then, if one of the "regular" blocks is destroyed by a process imperfection, the post-fab die can be modified with laser to reroute data to the extra backup block. So you invest some die room in backup structures, so that a die with only a few errors can be "corrected" and will still function as intended. This is basically like keeping a spare tire. If you get one blowout, you're still in business, but two and you are in trouble. Of course, you can package as many extras as necessary, but it may not make economic sense. Here you calculate the appropriate trade off between die size and yield to make the decision.
Anyway, long story short: your DRAM is already "bad". Quite a few RAM chips contain process errors that are rerouted around in hardware so that you, the consumer, need never know. To you, the process is transparent. All you should care about is that you get your *functional* RAM cheaper, because the manufacturer would have had to scrap that die otherwise.
This post discusses software "rerouting" around blocks that had more errors than could be corrected in hardware, but somehow still made it out the door. What's wrong with that?
Will semiconductor manufacturers suddenly think "Gee...let's not worry about yield anymore?" You'd better bet they won't. And even if they did, if the software rerouting is so clean as to not be noticeable (which is the only way it would fly), what do you care? You'd get your RAM cheaper.
Designing an ASIC to run Java byte code native might sound appealing at first, but it is ultimately a losing proposition. General purpose hardware (in this case, commodity microprocessors) ramp so incredibly quickly that investing in a special purpose "accelerator" is almost always the less cost-effective approach.
Obviously, graphics cards are the exception today. The reason? Graphics processing is incredibly hungry, and parallel by nature. Rendering and texture mapping can be parallelized far more easily than other desktop-style applications.
It is less clear that an ASIC JVM would make sense. Recall the early days of software mp3 players. When you were running an inefficient software decoder on a P100, you could notice the performance loss. Many people talked about how cool it would be to have a special ASIC run the algorithm in hardware on your sound card. Well, ramping up a project to design, market and sell such a device would have taken so long that by the time it hit shelves, everyone would be P200's with better optimized players and no longer care.
As long as CPU cost / performance keeps ramping like it is, hardware accelerators for special functions are not going to be attractive. I just can't see the demand for such a device. Besides, how much speed improvement could the device really buy you without being a fairly advanced processor itself?
> Looks like it - has someone cut and paste straight out of Emacs by any chance? Looks like the over-length line indicator.
FYI- Pico uses "$" as the out of space character. Emacs uses "\" and then continues on the next "line".
...these can no doubt be changed, but I'm pretty sure those are the defaults.
Back to GIMP. I've never used it much, but the folks I know who do a lot of image manipulation (web site design, free style art, whatever) are pretty down on GIMP's abilities. I should corner them and ask them why they feel GIMP is so far behind Photoshop. Myself, I don't really know enough to judge.
One thing I *have* heard is that GIMP is poorly equipped for print media. This has to do with the GIMP's limited support for non-RGB color palettes. My understanding is that virtually no one in the print world uses RGB palettes. Also, I expect that GIMP is behind in plugins, atleast in quantity, if not in quality. There are several companies who make their money off of writing plugins for Adobe software. Talk about a niche app, but they're still kicking, so I'm not going to knock it...
Any graphic designers in the audience care to say on what grounds Photoshop or some other proprietary package might still be superior to our beloved GIMP?
> The very fact that Geeks prefer to use such an arcane operating system as UNIX proves my point further.
"Your" point has been made time, and time again. Indeed, it's true that many do get off on communicating with their system through arcane symbols. As we all know, Unix is *chock full* of the arcane. Personally, I've been typing garbage like this all day:
% yes | rm -R *; cp/tmp/logs/* .
% zgrep `ls`/err_log.Z ERR > isTemp
% p | g `which fvwm`
It's only years of experience that makes me comfortable throwing around this kind of syntax. And that "mastery" does periodically give me a little thrill. What geek doesn't want to be a wizard? Mythical wizards weave intricate and arcane commands to coaxe demons to do their bidding. Unix wizards weave intricate and arcane commands to coaxe daemons to do their bidding. The analogy is so tight that "Unix wizard" is a term used even outside of geek circles.
...but feeling like a wizard doesn't completely overcome the frustration of a poorly designed interface. Daily, I curse tcsh command syntax. It's overly complicated, inconsistent and kludgey. I yearn for something better. Just this afternoon I downloaded and compiled rc. For those who don't know, rc is the shell used in the Plan/9 operating system that Bell Labs created to replace Unix. The shell is an attempt to "clean up" bourne, and make it more consistent. Great idea...now if only people would use it...
Taking this from rambling to a point... I think that while most all geeks *do* enjoy complexity, far from all enjoy *senseless* complexity. Complexity in a tool is only acceptable if it allows for more complete control of the problem. It is a rush to understand the full power of an intricate tool. It is at best a relief when you uncover the pointless and silly incompatibilities that have been causing you headaches.
I, for one, believe that Unix userland could use a serious overhaul at the command line level. 'find' is an extremely nasty program (it attempts to solve too many problems at once, if you ask me), and I think 'grep' could be made a lot friendlier without losing any power. The shells could have simpler and more consistent syntax for backquoting, and creating lists...
Anyway...not *all* of us are content with the complexity of Unix. Even wizards get sick of niggly details...
Seriously, the "old" Aibo isn't that old. I still remember Rob drooling over them before the Andover acquisition (read: when Rob got The Money). I didn't really pay that much attention to the original specs: how much is this model "improved"?
To me, the idea of a pet obsoleting at the same rate as my computer is frightening...
"Sorry, spot, we had some good times together but...well the new models are out now, and this year they're *translucent blue*. I just really can't be held back by old technology anymore. You understand, don't you, boy? Maybe Mom and Dad will find a home for you with some needy children who can't afford the latest model..."
Actually, having a robotic pet at all strikes me as a bit cold, so I guess this product isn't aimed at people like me. Live and learn.
Yes, this is based on the AMD chipset. AMD makes reference chipsets, and others (presently VIA) will make derivatives to supply the market. This is a sort of division of labor: AMD does (most) of the design, and VIA does (most) of the production.
It's not like VIA is competing with AMD. AMD designs reference chipsets because their processors (which are what they are really interested in selling) are unusable without. AMD can't make much money on selling chipsets, so they'd just as soon that somebody else take up that business. But somebody has to design the thing before it can be produced, and AMD foots the bill for that.
About an hour ago, the press release cleared that AMD demonstrated a dual Athlon workstation at Microprocessor Forum. Everyone knows they've been planning it, but now it's official.
Of course, it doesn't matter much until you can buy one in stores. Volume SMP-capable MB's should be available Q1 2001 -- not that far away.
And, the Athlon's chipsets have been SMP-capable for a while (they *are* based on DEC Alpha's interconnect), it's just that no one has put the denergy behind it to build SMP motherboards from them until now.
But the iMac certainly was a "cultural phenomenon". Now you can get translucent fruity routers and mice, and chairs. Heck, it's even spread to other devices, such as phones. What else in the computer world has been so imitated, even *outside* the computer world?
Plus, for many people, the iMac actually became their first computer. These are largely people that were intimidated by computers before, but that saw the iMac as "friendly" enough, and thus it was their introduction to computing. No doubt the iMac will have a special place in those people's lives.
The iMac will definitely go down as a cultural icon. In 30 years, directors will throw iMacs into movies to get people all sentimental about the past. Just watch and see...
Oh, calm down. The Republicans chose Bush because, despite his lineage, he is a Washington outsider. They thought that Americans were sufficiently upset about the scandals surrounding the Clinton / Gore years as to mistrust traditional politicians. Bush is new to the game, and his hands aren't stained with the mess of recent years.
They thought that Bush could provide solid, unsullied character to stand up next to Gore and his association with Clinton. Unfortunately for the Republicans, Americans don't really care if their politicians are slime balls.
I really do think that Bush dwarfs Gore on the integrity scale, but we are finding out just how little that means to America.
Compaq made the first 100% compatible PC clones. There were three essential items that had to be reproduced to make a true clone:
1) The processor -- no problem, IBM used a standard, off the shelf Intel Chip
2) The OS -- no problem, IBM contracted MS-DOS, but neglected to acquire an *exclusive* contract with MS. Boy how it came back to bite them.
3) The BIOS, used for booting and low level disk access. This was IBM's proprietary chip, and thus a problem.
Compaq could buy the OS and processor, but not the BIOS. So, they reverse engineered it. Compaq brought in a team of engineers, handed them an IBM BIOS and told them "document every single thing this chip does". The engineers did their work and came up with a very thick document which provided a full functional description of the part. Compaq paid them, and sent them on their way. Then a second group was brought in, who had never met the first group and never seen the part. They were handed the functional description and told "build me a chip that does exactly this", and they did. Thus the Compaq BIOS was born.
With the BIOS they had all the parts they needed to build clones, and that they did. IBM took them to court, but the courts ruled that Compaq's implementation was built in a completely "clean room" fashion, and was thus perfectly legal. Woe to IBM. This, of course, threw the doors wide open and other clone makers started in. Soon, IBM lost the PC market to smaller, faster companies, and that brings us to today.
Ah...PC history. Historically, Compaq has been a rather important company (first clone, first portable PC clone, first 386-based PC). It's too bad their modern machines are so terrible.
> RISC doesn't mean fewer instructions it mostly implies the instructions are simpler
Actually, that's precisely what "RISC" means, which is why it's a bad term. You are correct that the instructions are "simpler" in the sense that operations are *only* allowed on values already in registers, and memory references are confined to simple "load" and "store" instructions. Thus, memory access and computation are seperated, simplifying the internal implementation. The move to a load / store architecture is atleast as important as the focus on having a small, highly orthoganol instruction set. I guess we call it "RISC" as opposed to "load/store architecture" because it's sounds cooler.
> Also RISC processor are more register based than memory based; in other words operations happen on registers on the CPU and the result go back into registers on the CPU.
You are being a bit loose with your description. *All* modern processors pull their arguments into registers from memory, then operate, and then move them back out. In the CISC world that sequence could all be represented by a single op code, but internally it still executes those tasks in that order.
When papers started coming out on RISC, a lot of designers realized that their machines were already load / store architectures *internally*. Whenever a Cray got an opcode to add two different memory addresses, it would internally break that into four seperate micro-ops. Two to load the operands from memory into registers, one to execute the ALU operation, and one to store the result back to memory. So, at the microcode level, the machine actually operated as a load/store architecture, it's just that the ISA (instruction set) (which was inherited from the earlier PDP machines) was conventional CISC style.
With the rise of decent compilers and the fall in RAM prices (which made increased executable size less of a sin), it made sense to have the instruction set itself be based on load / store, thus moving all that decode logic that used to be in hardware out to the compiler. Bam: less hardware. Lean and mean.
Unfortunately, the x86 world never did move that logic out into the compiler which means they have massive decode units on their front ends to this day. Incidentally, Intel's IA-64 is a VLIW-style architecture which can be seen as the next step in hardware removal. In a VLIW system (or EPIC, as Intel calls it), instructions are issued in "packages" that are guaranteed to be independent. Thus, the processor knows that they can all be dispatched simultaneously without even checking. In present superscalar architectures, multiple instructions can be dispatched in parallel, but the CPU has to have a lot of logic to check and ensure that instructions are independent before they can be dispatched. You see, VLIW moves the independence-checking logic out into the compiler much as RISC moved instruction-decode logic out into the compiler.
Those poor compiler writers. Oh well, I guess it keeps them in business:)
...that Intel chips are RISC on the inside as well. No one has built a truly CISC chip in years and years. RISC won the architecture war, but not the ISA (instruction set) war. x86 was too firmly entrenched. Thus we are left with modern architectures that emulate old, crufty ones. Not conceptually lovely, but functional enough.
In practice even chips like the PowerPC aren't really RISC processors in the classical sense -- they implement too many instructions. (Altivec, anyone?) They merely hold onto the Load / Store memory model and the general feeling that instructions should be short and sweet. But they are far more complex than the RISC designs that academics came up with.
A lot of students will take an undergrad computer architecture class and come away with a RISC chip on their shoulder. Plus, it's fashionable to hate Intel, and to rag on x86. So you hear a lot of "RISC rules, dude!". However, it's all a little silly. Internally, modern x86's have benefitted from all the advances of RISC design. All we are left with is the external interface from the old days. But how much does that really matter? Virtually no one writes inline ASM these days. If your only interface to the processer is through a C compiler, then you're never dealing with the ISA anyway.
The story of x86's life: not lovely, but quite functional.
Real Time Linux is a real-time kernel that runs a standard Linux kernel as a pseudo-userland thread. It is essentially a hack to run standard Linux binaries on an otherwise real-time system.
Whenever an interrupt is issued, the RTLinux handler is run, and if necessary the RTLinux scheduler. The standard Linux kernel scheduler only runs during idle time. And RTLinux can pre-empt the standard Linux kernel, because Linux is run essentially as a process of the RTLinux kernel.
So my point is that the latency of the Linux kernel as we know it has no real bearing on the performance of RTLinux. RTLinux is it's own kernel, designed from the ground up for real time. To my knowledge, it shares no code with Linux. Linux is run "on top" of RTLinux, and thus stays out of the way of the ultra-important real-time scheduler.
Slashdot Mirror
Stallman has a special place in the book "Hackers" by Stephen Levy. The is the book that dubbed him the "last true hacker". Incidentally, many, such as ESR, believe that Linus was the man to disprove that title.
The book focuses on the history of computing in three phases, the infamous TMRC / AI Lab at MIT, the Homebrew Computer Club, and the early days of video game software for Apples. However, there's a small section at the end about RMS and GNU where Stallman gets to air some of his ideas. It's a nice way to close the book, because it connects back to the tradition that started at MIT, and was almost destroyed after the days of the Altair. And I, for one, have always found RMS's mission interesting.
Anyway, whether or not you like Stallman, Levy's book is a good read for any geek. It's a great way to connect with hackerdom's roots.
--Lenny
PS- I also recommend "The Soul of a New Machine" by Tracy Kidder. It's a good look at the hardware side of things, and though it was written in the 70's, much of the book is still relevent today.
A lot of the discrepancy between GHz and performance seen in P4 chips is explainable by Intel's choice of pipeline design. Intel chose to make extraordinarily deep pipelines on the P4 chips, which allows them to crank the clock speed up up up. Sounds great, huh?
The problem is that it's a bit of a false gain. Most of the performance gained in clock speed is lost again to the serious hit you take at each branch misprediction. If you could keep your ultra-long pipe full, you'd be cruising, but you can't. Occasionally you will mispredict, and have to flush that pipe. One your pipe becomes as deep at the P4, that performance hit starts eating your lunch. Suddenly, most of your processor is sitting empty most of the time.
So, clock-for-clock P4's get slaughtered by Athlons or PIII's. But Intel doesn't care. They know that the majority of consumers buy based solely on that magical MHz/GHz number. Most consumers are not sophisticated enough to realize that there is more to performance to clock rate.
This move on Intel's part was motivated by marketing rather than management. They are playing on the uneducated masses. It is all but directly deceptive, and I hope they get their clock cleaned by the press for it.
Buyer beware.
--Lenny
without a corresponding "standard" to describe the structure the file should have. If you want regularity, we need a well-accepted consensus on the different styles of options that can be used, and syntax for representing them.
If you had standard meanings for different kinds of config options and a standard format, you could get your wish of a single tool (be it command-line, slang, or X) being used to parse and modify all compliant config files. I've considered implementing something like this, myself. The problem, of course, is less in implementing it than in getting all of the disparate projects to accept it.
The only groups that might have the power to start this change are the distros. Red Hat seems reluctant to define standards, as they don't want to be seen as "pushy". Mandrake doesn't have the clout. To me, that leaves Debian and possibly Suse. If Debian came out with a standard, started using it for their tools, and developed a nice, simple interface, I think they could start persuading others to follow suit. It's a good idea, but it will take a great deal of persuasion.
But back to my earlier point point: simply moving to XML buys you nothing but complexity. What you really want is a common ordering and syntax to the different files such that they can be edited by a common tool. That's all well and good, but that can be achieved *without* XML just as easily as it can with. I see no inherit advantage in using XML, except the gain in "buzzword compliance".
--Lenny
You bought the car, and you own it. Increasingly with digital (or old analog) media, the notion is one of licensing, rather than ownership. Sorry, you can't play that DVD on your Linux box because that would break your *license*. You own the disk, but that's not what you care about. You care about the content it stores, which is intellectual property that is licensed to you.
The point of the article is that if the Powers That Be want to move to a licensing model (and they do), it seems fair that we should only have to license a product once. This *is* reasonable, but RIAA et al don't want to be reasonable. They want to limit you as much as possible, and drain as much money from you as possible.
My answer to the poster about his tape is that fair use allows personal copying, so he should feel no remorse about getting an mp3 of a song he already has. It is only questionably legal, but it is spiritually similar to making an archival back up at purchase time. Archival backups are perfectly legal.
In my case, I have no problem burning a copy of a CD that I already own. All too often CD's (even new ones) are improperly pressed and start skipping horribly on me. It's ridiculous that the CD companies' QA isn't better. They are selling inferior goods. But since I've already licensed the music, I just press my *own* damn CD and use that. The music companies don't like it, but it's legal.
--Lenny
How is this mocking KDE? When I saw the name "KDE League", that's the exact joke *I* thought of too, and I'm a KDE supporter. (If any one cares, I've been using KDE since KDE 1.0beta2) "League" is just so superhero-esque, the joke springs to the American mind.
As for spelling, it's tue tat Slshdot is bade abut typoes, but this has been pointed out quite enough by now.
--Lenny
Your post is just flamebait. However, the blind RMS and open source bashing on Slashdot has gotten way out of hand, so I feel obligated to respond.
> they're all hardcore Stallmanists
Not true at all. Debian is an Open Source movement, not a specifically Free Software movement. There are plenty of packages in Debian that are non-GPL. But *all* of them must conform to Debian's guidelines, which basically coincide with the Open Source definition. I would say that Debian, as a whole, shares more ideology with ESR than with RMS. How does this make them "Stallmanists"?
> who believe that communism onlt failed because of the oppression of evil American capitalism.
Blatent troll here. I follow Debian, and I have never seen any discussion that smacks of Communism, just solid software design and openness. Sharing source code is not at all the same thing as sharing material items, let alone *enforced* sharing of material items. If you honestly believe the sharing nature of free software is fundamentally evil, then there is really nothing I can do to reason with you. If you don't want to share your software, don't contribute to open source projects like Debian. But don't deride them for having beliefs.
> Unfortunately this is spoilt by its overeager adherents who are all too willing to bash other distributions for not being as "pure" (a term that brings to mind connotations of eugenics and ethnic cleansing) as they are.
Who are you arguing with? I haven't seen any such comments around here. Debian wants to ensure that their distro is completely open. That does *not* mean that they are attacking anyone else. Does their mere existence threaten you?
And the last point, RMS himself has no problem with businesses. His problem is with closed software. If a business (such as Red Hat) produces and uses Free Software, there is nothing for "Stallmanists" to get upset with. I am on Debian-devel, and I see plenty of support expressed for the Debian spin-offs. I have *yet* to see an attack on corporations basing their distros on Debian.
--Lenny
Itanium (code named "Merced") is the first implementation of Intel's new architecture dubbed IA-64. IA-64 is the long-awaited replacement for the geriatric x86 architecture. Intel developed this new architecture jointly with HP. (actually, truth told, what is now IA-64 was originally HP's internal project to replace their PA-RISC architecture. Intel hopped on board sometime later)
Itanium has been in development for quite a while, but has been delayed time and time again. The project has hit all sorts of roadblocks, one of the most fundamental of which has been the lack of efficient compilers. The IA-64 is radically different than x86 chips or even RISC-style chips. Architecturally, it is a VLIW (Very Long Instruction Word)-style processor. This type of architecture simplifies the construction of wide superscalar designs (that is, processors that are capable of issuing multiple instructions in a single cycle). It has good theoretical performance, but is considerably more dependent on compiler technology than more traditional designs.
Very few processors have been designed in this style, and the corresponding compiler technology is still rather primitive. This, along with internal problems at Intel have greatly delayed the first implementation.
Infact, the part was supposed to be out right now. Obviously it isn't, and Intel, realizing it wasn't going to have Itanium in time to compete with suddenly-relevent AMD's K8 product, panicked and had to put Itanium on the backburner to piece together another x86 to have something to pit against AMD. Hence, the Pentium IV was designed. Intel wanted to be beyond x86 processors by now, but the delays in design of Itanium forced them to squeeze out one more x86 to feed the market.
Comically, the second generation of IA-64 (code named McKinley) is being designed at HP and has been progressing quite nicely. So much so, that some people fear McKinley will actually beat the older project, Itanium, out the door. With this as a possibility, the question of whether Itanium won't be scrapped altogether arises.
--Lenny
The Pentium-IV is no more RISC-ish than the Pentium Pro / Pentium II / Pentium III chips were.
Modern AMD and Intel chips both implement RISC-style cores with x86 translators on the front end. So, the instruction set has not changed. Changing to a program-visible RISC instruction set would mean losing support for legacy applications (read: everything) and starting over. x86 could be implemented in a compatibility mode (as is being done in IA-64, Intel's new architecture that was supposed to have replaced x86 by now), but it almost certainly take a performance hit.
There are probably some nuances to the Pentium IV that compilers could take into account for small speed ups, but they won't make a dramatic difference. Compiler support is really not the problem with this part.
The *real* problem is that, in a purely marketing-motivated effort to inflate clock speeds, Intel designed the Pentium IV with a suicidally long instruction pipeline. This allows them to jack the GHz rating up up up, but it does *not* result in greater performance. The reason? When you get into extremely long pipelines, branch mispredictions start eating your lunch. Sure you have an extremely high theoretical performance, and if you could keep the pipeline full of instructions (that is: all of the processor busy at once), you would be flying like a bat out of hell. But you *can't* do that. You will mispredict periodically, and everytime that happens, you have to flush the pipeline and start over. The longer the pipeline, the bigger a hit this is. This part will realize drastically less of it's theoretical performance than the Pentium III or Athlon parts.
So the Pentium IV is destined to sell in a GHz rating far above the comparable AMD offerings. Yet, it's actual performance will be pitiful stacked up clock-for-clock with AMD parts or with the Pentium III. Intel knows this, but they also know that the average consumer buys a computer based *solely* on that magical GHz rating, never understanding the other factors that contribute to actual performance.
I sure hope their is a consumer backlash when people start figuring out that their Pentium IV's aren't as fast as they think they should be. This move on Intel's is quite deceptive.
--Lenny
> Obviously, the pentium 4's performance lags (or will) behind Thunderbirds of similar clock speeds. But this thing is also a .18 die process.
.18 micron process. This means that an individual gate measures 0.18 micron wide (or is it long? Damn...where's my VLSI text). Now, the smaller you make each individual gate, the more gates you can pack into the same square area of silicon. Or, if you keep the same design with the same number of transistors and "shrink" it to a smaller process, the same part can be manufactured in a smaller die size (square chunk of silicon).
You are being a bit loose with terms. The Pentium 4 is fabricated with a
Cost for semiconductor manufacturing is primarily a factor of silicon area, so reducing the die size is a big cost-savings per part. Also, smaller die sizes increase yields. Defects are inevitable, but with careful fab management, you reduce defects to a certain number per wafer. Each one of those will (likely) ruin a die. But if the dies are smaller, less of the overall wafer's area is lost to that particular defect. Thus, the smaller your die size, the less any given defect will cost you.
But there's another very important advantage you get from a smaller process. A smaller process generally translates to a higher clock speed. Why? Gate capacitance. Each gate is essentially a capacitor that has to be charged or discharged to switch the gate on->off or off->on. A larger device has a greater capacitance and hence takes a longer time to charge/discharge. So, larger devices take longer to change state, and hence can not be clocked as fast.
So, in summary, a process-shrink should improve yield for Intel, which means lower cost per part. It should also help their engineers up clock speeds on the component. However, at any *particular* clock speed, performance will not be affected. Heat dissipation / power consumption should be reduced, but otherwise, clock for clock the consumer will not notice a difference between processes.
...anyway, that's some of the engineering behind this. In terms of forecasts, I think Intel has been caught with it's pants down. They have an inferior product, and, if the world is sane, AMD will clean their clock in the coming year.
--Lenny
> there's a very good defense of the electoral college system available on the washingtonpost.com site. you can find it here.
Your statement intrigued me, because I have yet to find a decent defense of the system.
...this was not a decent defense. The only point that made any sense at all was that the electoral college encourages candidates to campaign in *all* states. Given it's all or nothing nature, the college pushes the candidates to focus on issues directed at a particular state, which might go neglected otherwise. I'm not sure this is a very good argument, but atleast it *is* one.
The rest of the article bashed opponents of the college by dismissing them as "majoritists". Not much of an argument there...they are majoritists by definition. That does nothing to detract from the argument itself.
Then he seems to propose that, while the electoral college *does* dilute representation in larger states, it is a similar institution to the Senate, and hence legitimate. This, of course, assumes that the Senate is legitimate. This is ridiculous: the simple fact that it exists does not make it right. Presumably, to demonstrate the legitimacy of the Senate, George Will would compare it again to the electoral college.
No, *both* of these entities were created to appease state's rights advocates at the time the constitution was drafted. The smaller states feared giving up too much control to the larger states, and thus this compromise was needed to forge the union. That is the historical motivation behind *both* institutions.
In today's America, I hardly see the need to continue this anachronism. It's not as if Delaware will secede out of fears that the US government would have too much control over them. Today, citizens, in general, consider themselves Americans before they consider themselves a citizen of their particular state. In light of the changed face of America, what purpose can the college hold?
One answer George Will gives is the perpetuation of the two party system. As mentioned, Perot pulled in 19% of the popular vote, but 0% of the electoral vote. The "legitimate" candidates were nicely shielded from that upstart. But who says the two party system is worth perpetuating? Certainly, many here on Slashdot are critical of it. In general, why should we enforce the limiting of our choices?
Anyway...I think you see my problems with the article. I remain unconvinced that the electoral college exists as anything but an anachronism. Arguing that it hasn't caused much harm does not lessen it's obsolescence.
--Lenny
You do understand that software controls the hardware, not the other way round, right? It's not like this was made incompatible with Linux, it's that Linux hasn't been made compatible with this yet.
It's understandable that AMD's first priority would be to get Windows up and running. That's where the big money is (for now). You'd better believe that they'll make sure Linux runs on it as well, though. They are quite interested in providing a solid platform for Linux.
--Lenny
No flame here, just clarification...
./ that have a clue about memories, memory protection architecture, fabrication, production, and testing techniques.
> we are talking about the die that passed the initial wafer probe and then were packaged and then fail somehow at or after the packaging or even shipping stages.
Yes, we definitely are. I only brought up the fact that the industry already routes around process errors in DRAM's to demonstrate a point. He seemed frightened by the possibility that future DRAM's we buy might not be 100% "clean". I wanted to demonstrate that 100% clean isn't necessary, and infact isn't produced now, by and large. What *is* necessary is 100% functional parts. DRAM manufacturers know this, and use it to improve yields, thus driving down cost. No foul play there.
> So in conclusion, I think there are plenty of us at
I expect there are, but none of them were posting. Instead, most of the posts demonstrated a clear lack of understanding of the process. The consequences of techniques like Linux's remapping seemed to worry the original poster, and I wanted to explain why it wasn't something to worry about since a similar process is already performed quite successfully. Further, I wanted to emphasize that this is a perfectly valid technique for increasing yield, and is transparent to the user. It isn't like the manufacturers are trying to rip people off.
> Why don't you just allow us to think that is't really cool to use software to lock out blocks of RAM?
I'm not saying it isn't cool. Some seemed weary of the idea, though, and I wanted to point out that their present DIMM's use something very much like this. As long as the software can do this transparently (as the hardware does), what does it matter to the user?
> but I seriously doubt that they are applicable to such dense cells as memories
Believe me: they are. Think of it: a massive die area that will be completely destroyed by a single speck. Wouldn't you prefer an ever so slightly (say 5-10%) larger die that can withstand one or two specks? The redundency is very easy to use in a homogenous structure like DRAM (millions of identical cells). All that has to be done to "swap in" the replacement RAM block is to modify some address lines. That can be done by electrically blowing fuses on die, or through laser modification. One of my former employers was *most* found of the laser approach. It added quite a bit of flexibility to their designs.
--Lenny
I'm amazed by how little this crowd know about details of semiconductor manufacturing. Defects are unavoidable! There, I said it. With the transistor sizes that we are pushing today, a speck of dust ruins an entire blcok. All you can do is *limit* the extent to which this happens by being as strict as possible with your clean room. But *some* contaminents will always get through. Perfection is unachievable. You have to accept this.
Alright, so we've accepted that some dies are necessarily going to be damaged. Why not make the hardware such that it can resist imperfections? Well, actually we do. RAM being as simple and homogenous as it is, lends itself well to this approach. Here's the idea: you add extra "blocks" of memory to a decode line. Then, if one of the "regular" blocks is destroyed by a process imperfection, the post-fab die can be modified with laser to reroute data to the extra backup block. So you invest some die room in backup structures, so that a die with only a few errors can be "corrected" and will still function as intended. This is basically like keeping a spare tire. If you get one blowout, you're still in business, but two and you are in trouble. Of course, you can package as many extras as necessary, but it may not make economic sense. Here you calculate the appropriate trade off between die size and yield to make the decision.
Anyway, long story short: your DRAM is already "bad". Quite a few RAM chips contain process errors that are rerouted around in hardware so that you, the consumer, need never know. To you, the process is transparent. All you should care about is that you get your *functional* RAM cheaper, because the manufacturer would have had to scrap that die otherwise.
This post discusses software "rerouting" around blocks that had more errors than could be corrected in hardware, but somehow still made it out the door. What's wrong with that?
Will semiconductor manufacturers suddenly think "Gee...let's not worry about yield anymore?" You'd better bet they won't. And even if they did, if the software rerouting is so clean as to not be noticeable (which is the only way it would fly), what do you care? You'd get your RAM cheaper.
--Lenny
Designing an ASIC to run Java byte code native might sound appealing at first, but it is ultimately a losing proposition. General purpose hardware (in this case, commodity microprocessors) ramp so incredibly quickly that investing in a special purpose "accelerator" is almost always the less cost-effective approach.
Obviously, graphics cards are the exception today. The reason? Graphics processing is incredibly hungry, and parallel by nature. Rendering and texture mapping can be parallelized far more easily than other desktop-style applications.
It is less clear that an ASIC JVM would make sense. Recall the early days of software mp3 players. When you were running an inefficient software decoder on a P100, you could notice the performance loss. Many people talked about how cool it would be to have a special ASIC run the algorithm in hardware on your sound card. Well, ramping up a project to design, market and sell such a device would have taken so long that by the time it hit shelves, everyone would be P200's with better optimized players and no longer care.
As long as CPU cost / performance keeps ramping like it is, hardware accelerators for special functions are not going to be attractive. I just can't see the demand for such a device. Besides, how much speed improvement could the device really buy you without being a fairly advanced processor itself?
rambling on a Wednesday,
Lenny
> Looks like it - has someone cut and paste straight out of Emacs by any chance? Looks like the over-length line indicator.
FYI- Pico uses "$" as the out of space character. Emacs uses "\" and then continues on the next "line".
...these can no doubt be changed, but I'm pretty sure those are the defaults.
Back to GIMP. I've never used it much, but the folks I know who do a lot of image manipulation (web site design, free style art, whatever) are pretty down on GIMP's abilities. I should corner them and ask them why they feel GIMP is so far behind Photoshop. Myself, I don't really know enough to judge.
One thing I *have* heard is that GIMP is poorly equipped for print media. This has to do with the GIMP's limited support for non-RGB color palettes. My understanding is that virtually no one in the print world uses RGB palettes. Also, I expect that GIMP is behind in plugins, atleast in quantity, if not in quality. There are several companies who make their money off of writing plugins for Adobe software. Talk about a niche app, but they're still kicking, so I'm not going to knock it...
Any graphic designers in the audience care to say on what grounds Photoshop or some other proprietary package might still be superior to our beloved GIMP?
--Lenny
> The very fact that Geeks prefer to use such an arcane operating system as UNIX proves my point further.
/tmp/logs/* .
... I think that while most all geeks *do* enjoy complexity, far from all enjoy *senseless* complexity. Complexity in a tool is only acceptable if it allows for more complete control of the problem. It is a rush to understand the full power of an intricate tool. It is at best a relief when you uncover the pointless and silly incompatibilities that have been causing you headaches.
"Your" point has been made time, and time again. Indeed, it's true that many do get off on communicating with their system through arcane symbols. As we all know, Unix is *chock full* of the arcane. Personally, I've been typing garbage like this all day:
% yes | rm -R *; cp
% zgrep `ls`/err_log.Z ERR > isTemp
% p | g `which fvwm`
It's only years of experience that makes me comfortable throwing around this kind of syntax. And that "mastery" does periodically give me a little thrill. What geek doesn't want to be a wizard? Mythical wizards weave intricate and arcane commands to coaxe demons to do their bidding. Unix wizards weave intricate and arcane commands to coaxe daemons to do their bidding. The analogy is so tight that "Unix wizard" is a term used even outside of geek circles.
...but feeling like a wizard doesn't completely overcome the frustration of a poorly designed interface. Daily, I curse tcsh command syntax. It's overly complicated, inconsistent and kludgey. I yearn for something better. Just this afternoon I downloaded and compiled rc. For those who don't know, rc is the shell used in the Plan/9 operating system that Bell Labs created to replace Unix. The shell is an attempt to "clean up" bourne, and make it more consistent. Great idea...now if only people would use it...
Taking this from rambling to a point
I, for one, believe that Unix userland could use a serious overhaul at the command line level. 'find' is an extremely nasty program (it attempts to solve too many problems at once, if you ask me), and I think 'grep' could be made a lot friendlier without losing any power. The shells could have simpler and more consistent syntax for backquoting, and creating lists...
Anyway...not *all* of us are content with the complexity of Unix. Even wizards get sick of niggly details...
--Lenny
Seriously, the "old" Aibo isn't that old. I still remember Rob drooling over them before the Andover acquisition (read: when Rob got The Money). I didn't really pay that much attention to the original specs: how much is this model "improved"?
To me, the idea of a pet obsoleting at the same rate as my computer is frightening...
"Sorry, spot, we had some good times together but...well the new models are out now, and this year they're *translucent blue*. I just really can't be held back by old technology anymore. You understand, don't you, boy? Maybe Mom and Dad will find a home for you with some needy children who can't afford the latest model..."
Actually, having a robotic pet at all strikes me as a bit cold, so I guess this product isn't aimed at people like me. Live and learn.
--Lenny
Yes, this is based on the AMD chipset. AMD makes reference chipsets, and others (presently VIA) will make derivatives to supply the market. This is a sort of division of labor: AMD does (most) of the design, and VIA does (most) of the production.
It's not like VIA is competing with AMD. AMD designs reference chipsets because their processors (which are what they are really interested in selling) are unusable without. AMD can't make much money on selling chipsets, so they'd just as soon that somebody else take up that business. But somebody has to design the thing before it can be produced, and AMD foots the bill for that.
--Lenny
About an hour ago, the press release cleared that AMD demonstrated a dual Athlon workstation at Microprocessor Forum. Everyone knows they've been planning it, but now it's official.
Of course, it doesn't matter much until you can buy one in stores. Volume SMP-capable MB's should be available Q1 2001 -- not that far away.
And, the Athlon's chipsets have been SMP-capable for a while (they *are* based on DEC Alpha's interconnect), it's just that no one has put the denergy behind it to build SMP motherboards from them until now.
Happy day!
--Lenny
But the iMac certainly was a "cultural phenomenon". Now you can get translucent fruity routers and mice, and chairs. Heck, it's even spread to other devices, such as phones. What else in the computer world has been so imitated, even *outside* the computer world?
Plus, for many people, the iMac actually became their first computer. These are largely people that were intimidated by computers before, but that saw the iMac as "friendly" enough, and thus it was their introduction to computing. No doubt the iMac will have a special place in those people's lives.
The iMac will definitely go down as a cultural icon. In 30 years, directors will throw iMacs into movies to get people all sentimental about the past. Just watch and see...
--Lenny
> Why isn't ANYONE talking about G.W.'s CIA ties?
Oh, calm down. The Republicans chose Bush because, despite his lineage, he is a Washington outsider. They thought that Americans were sufficiently upset about the scandals surrounding the Clinton / Gore years as to mistrust traditional politicians. Bush is new to the game, and his hands aren't stained with the mess of recent years.
They thought that Bush could provide solid, unsullied character to stand up next to Gore and his association with Clinton. Unfortunately for the Republicans, Americans don't really care if their politicians are slime balls.
I really do think that Bush dwarfs Gore on the integrity scale, but we are finding out just how little that means to America.
Whatever...I'm voting Nader.
--Lenny
Compaq made the first 100% compatible PC clones. There were three essential items that had to be reproduced to make a true clone:
1) The processor -- no problem, IBM used a standard, off the shelf Intel Chip
2) The OS -- no problem, IBM contracted MS-DOS, but neglected to acquire an *exclusive* contract with MS. Boy how it came back to bite them.
3) The BIOS, used for booting and low level disk access. This was IBM's proprietary chip, and thus a problem.
Compaq could buy the OS and processor, but not the BIOS. So, they reverse engineered it. Compaq brought in a team of engineers, handed them an IBM BIOS and told them "document every single thing this chip does". The engineers did their work and came up with a very thick document which provided a full functional description of the part. Compaq paid them, and sent them on their way. Then a second group was brought in, who had never met the first group and never seen the part. They were handed the functional description and told "build me a chip that does exactly this", and they did. Thus the Compaq BIOS was born.
With the BIOS they had all the parts they needed to build clones, and that they did. IBM took them to court, but the courts ruled that Compaq's implementation was built in a completely "clean room" fashion, and was thus perfectly legal. Woe to IBM. This, of course, threw the doors wide open and other clone makers started in. Soon, IBM lost the PC market to smaller, faster companies, and that brings us to today.
Ah...PC history. Historically, Compaq has been a rather important company (first clone, first portable PC clone, first 386-based PC). It's too bad their modern machines are so terrible.
--Lenny
> RISC doesn't mean fewer instructions it mostly implies the instructions are simpler
:)
Actually, that's precisely what "RISC" means, which is why it's a bad term. You are correct that the instructions are "simpler" in the sense that operations are *only* allowed on values already in registers, and memory references are confined to simple "load" and "store" instructions. Thus, memory access and computation are seperated, simplifying the internal implementation. The move to a load / store architecture is atleast as important as the focus on having a small, highly orthoganol instruction set. I guess we call it "RISC" as opposed to "load/store architecture" because it's sounds cooler.
> Also RISC processor are more register based than memory based; in other words operations happen on registers on the CPU and the result go back into registers on the CPU.
You are being a bit loose with your description. *All* modern processors pull their arguments into registers from memory, then operate, and then move them back out. In the CISC world that sequence could all be represented by a single op code, but internally it still executes those tasks in that order.
When papers started coming out on RISC, a lot of designers realized that their machines were already load / store architectures *internally*. Whenever a Cray got an opcode to add two different memory addresses, it would internally break that into four seperate micro-ops. Two to load the operands from memory into registers, one to execute the ALU operation, and one to store the result back to memory. So, at the microcode level, the machine actually operated as a load/store architecture, it's just that the ISA (instruction set) (which was inherited from the earlier PDP machines) was conventional CISC style.
With the rise of decent compilers and the fall in RAM prices (which made increased executable size less of a sin), it made sense to have the instruction set itself be based on load / store, thus moving all that decode logic that used to be in hardware out to the compiler. Bam: less hardware. Lean and mean.
Unfortunately, the x86 world never did move that logic out into the compiler which means they have massive decode units on their front ends to this day. Incidentally, Intel's IA-64 is a VLIW-style architecture which can be seen as the next step in hardware removal. In a VLIW system (or EPIC, as Intel calls it), instructions are issued in "packages" that are guaranteed to be independent. Thus, the processor knows that they can all be dispatched simultaneously without even checking. In present superscalar architectures, multiple instructions can be dispatched in parallel, but the CPU has to have a lot of logic to check and ensure that instructions are independent before they can be dispatched. You see, VLIW moves the independence-checking logic out into the compiler much as RISC moved instruction-decode logic out into the compiler.
Those poor compiler writers. Oh well, I guess it keeps them in business
--Lenny
...that Intel chips are RISC on the inside as well. No one has built a truly CISC chip in years and years. RISC won the architecture war, but not the ISA (instruction set) war. x86 was too firmly entrenched. Thus we are left with modern architectures that emulate old, crufty ones. Not conceptually lovely, but functional enough.
In practice even chips like the PowerPC aren't really RISC processors in the classical sense -- they implement too many instructions. (Altivec, anyone?) They merely hold onto the Load / Store memory model and the general feeling that instructions should be short and sweet. But they are far more complex than the RISC designs that academics came up with.
A lot of students will take an undergrad computer architecture class and come away with a RISC chip on their shoulder. Plus, it's fashionable to hate Intel, and to rag on x86. So you hear a lot of "RISC rules, dude!". However, it's all a little silly. Internally, modern x86's have benefitted from all the advances of RISC design. All we are left with is the external interface from the old days. But how much does that really matter? Virtually no one writes inline ASM these days. If your only interface to the processer is through a C compiler, then you're never dealing with the ISA anyway.
The story of x86's life: not lovely, but quite functional.
just a few thoughts...
--Lenny
Real Time Linux is a real-time kernel that runs a standard Linux kernel as a pseudo-userland thread. It is essentially a hack to run standard Linux binaries on an otherwise real-time system.
Whenever an interrupt is issued, the RTLinux handler is run, and if necessary the RTLinux scheduler. The standard Linux kernel scheduler only runs during idle time. And RTLinux can pre-empt the standard Linux kernel, because Linux is run essentially as a process of the RTLinux kernel.
So my point is that the latency of the Linux kernel as we know it has no real bearing on the performance of RTLinux. RTLinux is it's own kernel, designed from the ground up for real time. To my knowledge, it shares no code with Linux. Linux is run "on top" of RTLinux, and thus stays out of the way of the ultra-important real-time scheduler.
Check out their site for more info...
--Lenny