HTML is a bit limiting. Using tables to lay out widgets is Ok, but missing progress bars, and hot beng able to give user feedback except as the result of clicking a submit button is a big big disadvantage.
The only thing with a real GUI I have done in years is a MP3 jukebox player (streaming mp3's over HTML into mpg123). As it selects songs randomly (baised on user ratings) it needs to display the song title (and disc name, and the band, and the current rating, and blah blah). It also wants to display a progress bar. Oh, and of corse it wants to play the sound on the machine with the speakers, not the server in the machine room.
I did do a GUI mock-up in HTML, and that was pretty good. Actually a friend did a set in HTML after I did one or two in pencil. That was very helpful. Showing off the HTML one to a few potential users was much more useful then showing my cruddy pencil drawen one.
I imagine many other GUIs have similar problems. I expect alot of them would also be doable in HTML with varying degrees of suckage.
Choice seldom makes it worse for those doing the choosing (Linux folk in this case). Choice does make it worse for those being chosen. The PPC would be in much better shape if it were the only game in town.
In this case I think it is hard to not choose the alpha if you want maximum single CPU speed, or the x86 for minimum price.
I'm not sure what gets you the best bang for the buck. I expect the ARM gets the best bang per milliwatt (even the new 600Mhz intel ARMs run fairly cool).
I honestly don't have a clue what the PPC is best at other then running PPC code!
You're starting to sound like those Windows guys that espouse the superiority of MS because there are more games and it's a standard.
I don't see why you would think that. My original post disn't espouse anything (except maybe cheep SS7 motherboards). This post has a bit more espousing in it. However you should note I never espoused anything merely because it was popular. I did say PCs were cheep, and it would be hard to beat them on price. However that is (a) true, and (b) not a popularity argument.
You bring up a good point regarding portables though...
Thank you. I may, of corse, be over excited about the iBook merely because of my fondness for 802.11.
Frankly I don't see why a cheap PPC motherboard is going to make a huge diffrence. PC motherboards are quite cheep, under $100 for a Super7 motherboard. So if the PPC is going to compete in price it has a long road to hoe. A free design doesn't mean free motherboards, in fact the free design might not be as cheep to make as some of the more mature PC motherboards!
The fact that Linux is more or less processer agnostic just makes it worse, after all why go for a PPC rather then an alpha just because there are vague roumors that the Alpha will gasp it's last any year now? I mean if switching to a new CPU is so easy, why not use the Alpha until it actually gasps it's last? (assuming of corse that the Alpha is faster -- with the SPECmarks seem to say, and cheap enough)
The only real argument I could see for using the PPC is if it (the PPC) actually made it into nice cheep machines, like maybe the portables (they seem relitavly inexpensave for what you get -- but I havn't looked at PC portable prices, so i may be in for a shock). Actually that isn't the only argument. It would be intresting to see Linux on one of the big PowerAS machines...nicer still to see it hosted under VM on a 390 (but that's not a PowerPC).
People who learned programing with pencil and paper, and then after reviewing thier programs several times before submitting them to have punch cards made fully understand the value of writing efficent programs. People who use editors from the beginning and are just happy if things compile without errors are more likely to write bloat. I know a few people who worked with punchcards, and wrote programs by hand on paper first, and, as a "generalization" they write far less lines of code to do the exact same thing to this day, even when they are writing thousands and thousands of lines of code. In addition to being forced to do all the "extra" work was a step of "review" of thier code, because it helped to talk to others, look it over, and put a lot of thought into it BEFORE they tried to compile it. Even though they don't do that today, they benifited greatly from the experiance.
I think there is something else going on there. The folks who learned to program on punchcards (or even in batch mode with a "real" editor) by and large have a few diffrences from people who learned to program directly in an editor:
They have been programming longer, like since the late 70s
They stated working on very small machines, like smaller (in terms of memory and CPU speed) then a Palm Pilot, and frequently shared at that!
They have probbably solved a similiar problem before (20+ years of experiance will do that)
They have way way more debugging experiance
So do they write tighter code because they scetched it out in pencil n' paper first, or because they learned on a machine with a 5Mhz clock? Does it take them less time to debug because they flowcharted, or because they have had two decades experiance in hunting bugs?
Personally I'm in the intermediate range. I started programming at the head end of the '80s. I never did punchcards, and avoided batch untill collage (in '89 or so). I don't pencil schetch out code (except in Pascal class over 15 years ago). I do whiteboard out my data structures. I have imense respect for people more skilled at it then I, and I beleve they tend to be older then I am. I think I'm at least as good as my Dad was when he tought me, but he has gotten 18 years better at it, still leaving me a lot of room to catch up. Some folks who are younger them me just plain have more natural talent at it, and are also better then me.
However the thing I won't claim is that pencil programming will make you better, or that whiteboarding data structures will. Those help some people, and not others. If you havn't tryed it, give it a shot, maybe it will work for you. also try "writing one to throw away" (preferably in a language simmilar to, but not the same as the one you need to use of the actual implmentaiton, to avoid the chance of actually using the throw away). Find something that works good fir you, and every few years try something else for a project or two (havn't used hungarian notation? give it a shot -- it didn't help me, but maybe it'll give you an edge).
On the other hand, the FreeBSD kernel just isn't "fun" enough for the hard core hackers. It has too long a history and is too settled. All the neat research stuff, like logging filesystems, the "tree"-based file system, etc., is being done for Linux.
Careful, there is some rather intresting stuff going on in the FreeBSD kernel. Taking filesystems for example the new ffs soft update code is nearly as fast as going async (removes 99% of sync writes) but is as safe as a sync version of ffs. Runs quite fast as well, just be careful not to try to remove too many huge tress of files at once (that will tax kernel memory usage, for 30 seconds or so). With soft updates you can also skip the fsck on boot, schedule it for some other time (you still need to unmount the FS before fsck, but using it between a crash and fsck is safe!). More intresting yet is the snapshots for ffs code, which not only allows "NFS toaster like mid-day live backups", but also allows you to fsck the snapshot, and apply the changes to the live (mounted) filesystem safely.
There is a good chance it will run faster then the log structured filesystem, and it defintly can reboot faster!
There is a good paper about how it works in the most recent Freenix procedings, which you may be able to find at www.usenix.org
Real time OSes are a stupid way to do audio/video stuff on a commodity computer. The problem is that just having "Real Time" doesn't necessarily mean that your computer is fast enough-- and the tradeoffs are that your machine may become useless for anything else.
Yes, RT doesn't mean your computer is fast enough, but that doesn't make RT useless.
The right way to do A/V stuff is with special (intelligent) hardware that works in real time itself (under the control of the machine), and takes the load off your CPU (and operating system).
That makes sense when the A/V hardware is cheeper then a new CPU for the task (like MPEG2 decode use to be, and still is for some people). It is much less fun for things like MP3 decoders, who wants to pay $50 for MP3 decoder hardware rather then kiss off a few percent of their CPU?
If you have a nice fast CPU would you feel good at paying $100 for a MPEG2 decoder, or would you rather kiss off 40% of your CPU when you happen to watch a MPEG stream?
Intel, AMD, Sun, and Compaq spend megabucks on research for their nextgen chips. Should Creatave Labs try to compete?
Besides most A/V stuff needs relitavly little in the way of real-time garentees, for 30fps video it "only" needs to handle 30 "hard" real-time intrrupts (per second), allow dirrect screen I/O from the real-time task (or have a RT window system, which could be hard), to buffer enough data to smooth out the jitter for non-real-time I/O with a network or disk. Most A/V stuff can be converted to "easy" RT (not soft RT), and big buffers.
Note: "hard" Real Time has real garenttes on how long intrrupts take, and what can intrrupt a RT thread. For example "no more then 200ns from intrrupt to thread dispatch, no interrupts from lower pri until the thread releases the CPU", these limits are never ever violated, except in the event of a hardware failure. Sometimes valuable equiptment depends on it (computer controled milling machines, or chemical processors maybe), sometimes lives (flight control software in a inharently unstable airplane like the Stelth). "Soft" Real Time makes similar garentees, except they can break them once in a while (say when the disk decides to do a thermal recalabrate). These are industry standard terms. "Easy" real time is not a standard term, but i use it to talk about a system that allows only a subset of operations in a "real time thread", like adding things to a buffer, and taking them out of the buffer, and maybe some non-complex I/O (like looking at the current value of a DAC, or causing a pin to go high or low, NOT talking to a filesystem). It's no where as difficult to do an "easy" RT OS (or extention) because you only have to deal with the intrrupt handler and scheduler, and the small number of permited RT operations. You don't have to fix all the filesystems, all the device drivers, and all the anything else that has non-determinstic timing, or deterministic timing, but too long to make useful RT promises.
It uses two AAA's like a normal (non-V) Palm. The batt you see is the one for the wireless crud which gets charged from your AAA's automagically. Why? I donno, maybe it needs some odd voltage Palm couldn't get from the AAA's, or the wirelsss goop was from another compony and that was the way to tack it on with the fewest changes, and therefore the lowest time to market.
Yes, Token Ring has it's problems too, but the fundamental design is better. The Ethernet prinsciple of 'Shout until you can't be heard, then back off for a little while before shouiting again' is messy.
Ethernet is a pretty hacky design, and won because it was cheeper to build then TR. I'm not exactly in love with it as a way to talk over cables (or fiber), but it actually is a really spiffy way to do wireless (shout until you can't be heard...)
Passing tokens, OTOH, results in a network that is entirely capable of functioning well at 100% usage. Ethernet tends to hit trouble around 30%.
30%? You seem to be way off. 60% in general use seems to be a much better rule of thumb. If you have a switch (and they are so damm cheep these days) you can get far closer to 100%, well over 100% with some valid mesurements. As far as I know Ethernet plus a switch per port is cheeper then Token Ring by a fair margin.
While I think FDDI/CDDI (essensally Token Ring at 100Mbit/sec) is very nice, and doesn't take any effort to get it to run in the high 90% range, it costs more then 100Mbit ethernet plus a switch! It's so hard to argue for it that I have more or less given up on it except when I can make a case for the duel ring CDDI (that way even the network hub can be a redundant item). I'm totally unaware of any Token Ring like offering in the 1Gbit range either, so for the moment it appears to have no future. A pity because I have allways liked it.
If we're honest, ethernet won becase of market forces rather than technical superiority, making it a very odd analogy for a GNU/Linux advocate to use.
Many GNU/Linux/Open Source advocates do take a market tactic. They claim their way gets better product at a lower cost. Ethernet isn't better then TR at any given speed, but it's price/performance is definitly better.
Point made?
Only that you seem inexperianced with Ethernet. Or maybe that I'm in a contrary mood today.
So the K7 is faster then the Xeon at SPECint, and much faster for SPECfp. When multi-processor chipsets come out it will in all likelyhood be far faster then the MP Xeon (thanks to DECs point to point "bus" design). The K7 can eventually beat the Xeon's L2 cache size and match the speed (note that the SPEC numbers are better with a worse L2 cache, I assume due to the far better L1 cache, and a more agressave OOO engine).
So far things are better for AMD then I recall them ever being. However each time AMD had a CPU that could threaten Intel they have had problems making enough of them. Will things really be better this time?
From reading AMDs press release there are a few clues. They will not be selling their CPUs at a fixed discount from the similar Intel ones. They listed a bunch of reasons, but I susspect a big one is they will adjust price to reflect yeild. They also keep talking about the K7 gunning for the high-end market (after all the K6 will not be discontinued for quite some time!). The profit per chip is far higher there, fewer chips will have to be sold to earn the big bucks.
The downside of corse is many K7 systems won't be signifigantly cheeper then the Intel Xenon systems (or so I assume). We may even see the MP K7 systems costing more then the Xenon, after all it will in all likelyhood be a much faster beast.
The upside is Intel may be forced to cut Xenon prices, and in any even when Intel starts beating the K7 there will be more price cuts (and AMD's new fab plant may help them manage volume shipments for once)
2. Is a JVM system really fast enough now to work as a real OS or even application on its own?
On a PII-333 with the Symantec JVM a SSH client written in Java (no assembly assist for the Crypto) can scroll the screen far faster then I can read. I can tell when it GC'es (or maybe when the network loses a packet) because it pauses long enough to make out a few words (my "standard" test is to cat an ~500K/etc/termcap).
Disabling the SSH encryption it timed as faster then the Telnet that came with my Windows box (i.e. receving SSH packets in the clear, doing a CRC, and displaying them was faster in Java then doing even less work in C -- I assume they didn't feel a need to tune for speed, and I did).
On a PPro-180 under FreeBSD the Sun JDK limped along fairly painfully, I could guess how many lines were in eatch SSH "packet". (actually it was a Duel PPro-180, but I dout Java tryed to schedule diffrent threads on diffrent CPUs)
The JVM implmentation makes a huge diffrence, but I would say Java is fast enough for a lot more tasks then people tend to give it credit for.
Indeed, it's something like 180K lines of code. It has tons of things that are sometimes extreamly useful. Not just the guaranteed I/O rate stuff, but b-tree baised directory lookups (no more slow operations on bloated news directories). Adding more disks to an existing XFS filesystem is great. It's all great.
At a price. It's 180K lines of code after all! I don't see a 8M second hand 386SX running XFS. I think there is a future for EXTn. If EXT3 comes soon enough, it could have a long future. If it comes too late I'm not sure who will want to hack on it rather then XFS.
Linux does need a journaling FS and XFS may be the best bet, but it won't happen quickly unless SGI puts some serious resources behind it.
What does SGI have to do "quickly" other then actually release the code? You mean just because it's big Linux hackers can't get it to work on their own? Only "real" SGI programmers can do anything with it? If so SGI isn't getting much by giving it away! What happened to "with enough eyes all bugs are shallow"?
Also, just who has the resources to test large production systems (4+ CPUs) on an OS under test? Corporates, that's who. And they'll contribute their code to Open Source, right? Because...?
Well tons of 2CPU tests will be done becasue 2CPU machines are cheep enough to be affordable to hobbiests. The K7 may or may not make 4+CPU machines affordable as well. "Corporates" may well put some time into testing "Linux XFS" on big machines because they think it is a useable platform. Or they may not. It's not like they owe Linux anything. The bigger distribution componies (i.e. Red Hat) may well do testing, or donate test equiptment, they make their living off Linux after all, and many of them are gunning for the server market.
But does it matter if it gets 4+CPU testing? If Linux isn't commonally run on 4CPU systems then it won't see much 4CPU test, nor will it be easy to argue 4+CPU is important to it at that time. When 4+CPU becomes important it will see lots of testing there.
This *will* all happen, but I think some of these tougher OS issues will need corporate backing that may have a price current purists will not like but will have to accept (ie less than Open Source code licenses or maybe even (cringe!) binary drivers).
Linux only has to pay that price is it views corprate acceptance is a goal worthy of that price. If it holds it's ground either corprate acceptance will come anyway (that appears to be happening at the moment), or it won't, but Linux will still be "pure".
So before you accept a binary licence, or a single bit of software that is less open then you want, ask yourself how bad do you really want it? Is there another card you could buy that's maybe only a little slower (or more expensiave) that has a more open driver? Or is it something you can do without for a while?
You only have to give up what you are willing to give up.
P.S. this doens't mean you have to give nothing up. I have a copy of Civ call to power, and no source code. It's a deal I was willing to make. But I don't have a single card in my machine I don't have driver source for, even if that means I don't get anything like a SB Live for 18 months (my best guess on how long an open alternitave takes to arrive). Other people are free to make other choices.
[...] BSDI is doing the exact same thing with their operating system. But OS emulation on the UNIX side isn't anything new. BSDI also has SCO binary compatability, for example.
BSDI's Linux compatability is done diffrently from their SCO compatability (and diffrently from FreeBSD's as well). I don't know much about lxrun, from skiming the FAQ it looks like it works the same was as FreeBSD's Linux emulation.
The FreeBSD Linux compat stuff, and the BSD/OS SCO compatability stuff both hook into the syscall interface and do their emulation inside the kernel . Which makes it harder to modify, and fix, and bugs in it will cause the whole system to be less stable.
The BSD/OS linux emulator works entirely in userland. It is basically a diffrent ld.so (the runtime shared linker), which remaps calls to things like write(2), read(2), ioctl(2), and syscall(2). It works quite well for dyanmically linked ELF stuff. It doesn't work for statically linked code, nor for code like Netscape which has inline assembly for system calls (in their case select).
I don't think one system should be any faster then the other. So the only real issue would be whether the incresed ease of modification is worth giving up a.out support (YES), and static bin support (maybe).
Linus isn't out to make Linux perfect; he's trying to make it reasonably good. Given two ways of doing something, he is more likely to choose a simple, "obviously correct" way than he is to choose a more complex solution. Sounds a little like what my professors tell the classes--"make it work, then make it fast".
Thompson is trying for perfection. Perhaps he'll get closer to it than Linus, but he's obviously more likely to fail.
This makes it sould like Thompson will pick the "complex but perfect" choice. That appears to be very much not the case. Look at windowing systems for a moment, Linux seems to have chosen X11 as it's windowing system. A good choice, the code was available, many applications allready use it, while it has huge flaws it is gennerally beleved to be usable. Inferno's windowing system is 100% new. If you look at X's drawing primitaves there are tons of them, there are dozens of ways to manuplate a "Graphics Context", diffrent ways to draw text made of 8bit charactors or 16 bit charactors, a call to draw a line, a call to draw multiple lines at once, maybe as many as 150 diffrent X calls to "draw stuff". Then there are liberies built on top of X. Inferno's windowing system has exactly one drawing primitave "take rectangle A from this pixel source, and scale/rotate it to size B in that pixel sink". (In Inferno pixel sources/sinks all have alpha masks) Then liberies are built on top of that.
Which is better depeneds on how you judge. If I were making an OS and wanted to see 3rd party applications on within five years I would never make a new windowing system, not matter how cool. I would use X11, or Display PostScript (or both).
Linux is "behind" in terms of hardware support, application support, etc. because it is a redesign at least as much as it is a new design. Naturally it's quite boring to Ken Thompson, who participated in the original design. On the other hand, it's interesting to many free software developers since this is a chance to "do it the right way" instead of being chained to complex, overengineered implementations (not that we don't have any, but we're not chained to them).
Supports more hardware then what? Linux definitly supports more PC hardware then Plan 9, and almost defintily more hardware by count then Plan 9. Same for Inferno if you ignore Inferno running as a guest OS under Windows (and whichever IBM S/390 OS's they support). Inferno runs a few places Linux doesn't (like the Sony PlayStation), but I expect Linux runs places Inferno doesn't, and could probbably run on just as much bare metal as Inferno.
He didn't complain that Linux doesn't support lots of hardware. He complained about it's reliability. Which isn't something I can't comment (much) on, I havn't found Linux to be particurally unstable, nor have I heard creditable reports of it being unstable. As others have said maybe he tested an old version of Linux.
On the other hand, it's interesting to many free software developers since this is a chance to "do it the right way" instead of being chained to complex, overengineered implementations (not that we don't have any, but we're not chained to them).
Note: we still have the complex overengineered *interfaces*. Programmers please think of all the work you need to do to open a TCP socket, connect it to a remote host and port (three syscalls, plus a call to gethostbyname, and getprotobyname). Contract that to Plan9's: finger_fd = open("/net/inet/tcp/hostname.domain/finger", O_RDWR, 0);
I'm sure I didn't get the exact path, I'm not a Plan9 user, I just read all the White Papers I could find. Also note that this is so simple you can write a finger client as a tiny shell script.
Linux or *BSD could choose to implment this in addition to the normal interface (there are several *BSD implmentations of this sort of thing using portals), but they can't discard the overcomplex socket interface.
BTW, (Free|Net|Open)BSD are much different, as they share the BSD 4.4-Lite codebase. I wonder how much original UNIX code was left in 4.4-Lite.
As a matter of Law, no signifigant quantity of copyrighten material (which I think means cpio in it's entierity, some header files that really only have one strightforward representation, and nothing else). Go hunt up AT and T's lawsuit against BSDI.
Also, this article was pretty despressing in one respect: through AT&T, Ken Thompson has, in effect, tied up his entire life in the big red ribbon of intellectual property. I wonder what other amazing things he has produced that never saw the light of day.
I expect almost everything he ever produced that was intresting, and not turned into a product has a paper written about it. A paper that can located and read. It is depressing that so little of it has code you can get for free, or even for a "modest" fee (Lucent's Toolchest II CD is $500, more then I can afford at home, a pittace for my employer to buy).
The thing I find depressing is I'm sure there are flaws in Linux, and if he had pointed out a handful of them people would rush off and work on them, maybe even manage to fix them. Unfortunitly all his Linux comment will do is cause some to snicker, and other to get pissed off.
P.S. I think one big reason "Plan9 lost in the marketplace" is Plan9 was never really in the marketplace. You could get it for free (or cheep? Inferno was free), and do non-products with it for free. A product baised on it would cost $250,000 or call for pricing. Plan9 is cool, but i can't see it saving $250,000 over Linux or *BSD on very many projects.
[...]Why not use random noise as the pad[...]
Is this overly easy or am I missing something?
Random numbers are far better then known plaintext. Random numbers are also really hard to get on current machines. What we have is psudo-random (see the man page for random), and on some-OSes we-did-some-stuff-that-may-be-pretty-random (see/dev/random). Psudo-random isn't so much better then known plaintext, in part because sometimes it ends up being known plaintext (like if a program uses the "normal" method of seting the random number seed to the current time, you will amost know the random text). In part because the streams some RNGs make can be recognised.
Still psudo-random would be better then known-not-random.
Also the original message had a small flaw, eight times the current 2K *bit* key size is 2K *bytes*, which isn't way huger then many things you may want to protect. Still if we have to keep expanding the key space every few years it will become a real problem.
The plain truth is that there will always be would-be killers. The only way to reduce the number of people they actually kill is to take away the means of mass slaughter - ie guns. It's so simple. As a friend of mine put it, "if i feel like killing people and i have access to guns, it's easy. if i only have access to bananas, i might still be able to kill someone, but it's a lot more difficult".
But you wouldn't have access to only bananas. You would have everything you have today, except guns (or actually legal access to guns, making guns illegal will not make it impossable for someone who is willing to break the law once they get a gun to break a law by getting one!).
So you can cut down on shootings, but you would get more stabbings and more bombings. In fact if the disturbed killers from this most recent incident had skipped the guns entirely and just used the large bombs they got into the school kitchen they would have killed 100s of people. (they apparently set them to go off a few days later, I assume they thought people would have returned to classes by then).
Maybe you would reduce the killings that number in the tens, but would the killers (that you claim will allways be with us) start killing with crossbows and knives (which I assume would kill maybe half as many people), or would they use homemade bombs, fuel-air-munitions, or poison gas (ever wonder what you can buy for $100 at a pool supply store?), which may actually kill many many more then the guns we have now?
2. In most cases, selling stock is really selling equity, but this is a technology stock we're talking about. With these things, the price of the stock is several orders of magnitude times earnings. Usually you would be selling equity, but with high-tech stocks (especially now with e-trading), it really is like financing a loan.
I know you have recanted this, but for the benifit of people that don't know the diffrence but want to I still want to talk about it.
When you make a loan you secure a promise that you will be repayed the loan amount, and for your trubble intrest. Unless the loan-ee goes bankrupt (or is a theif) you get your money back, plus the profit. In other words the value of holding the loan is almost allways more then the amount it was made for, and less then a fixed value (ignoring adjustable rate loans, and high risk loans, and even the time value of money). Concrete example: I loan AT&T $100, they promise to pay me $105 at the end of 12 months. During that time I should be able to sell that loan to someone else for more then $100, but less then $105. At the end I'll get $105. I'll make up to $5, and have almost no chance of losing money. (If I made this loan to someone who has been in bisness less time then AT&T, or who is in trubble the risks would be diffrent, but so would the reward)
When you buy stock you secure a promise that the compony will try to make a profit, and that it will obey your will in proportion to your stock ownership (not very important for this discussion, so I won't comment on it farther). In other words you have no idea how much much it will be worth in the future. Concrete example: I buy a share of AT&T for $55. Baised on recent history I may be able to sell it for $65 next month (it was in the mid-$60s a month or two ago), I may also only be able to get $38 for it (it was in the high 30's last May). More potential for profit, more risk.
Owning someone else's debt (say AT&T debt bonds) is an OK way to make a little money fairly safely. It's gennerally a poor way to make fairly large amounts of money. Owning stock is an OK way to make lots of money with a high degree of risk.
Please don't rush out and start buying and selling stocks, or loan bonds (or making loans directly) baised on this advice. It is very genneral, and may even be wrong. I'm not a financial advisor. Please see one before you do anything like this.
My summery of EPIC vs. VLIW vs. SuperScaler (note I use the term "functional unit" to mean "thing that can execute some kind of instruction", more functional units means a faster CPU, it's an oversimplifaction, but useful in this context):
Super Scaler CPUs execute a stream of inctructions with no information about data dependencies or execution unit dependencies. They figure it out on the fly. You can change the latencey of functional units, or the number of functional units, and still run the same code. Many transistors are used to figure out the dependencies on the fly.
VLIW executes a stream of instructions marked to show data and functional unit dependencies. No changes to functinal unit latancies or number of functional units can be made without risking (almost 100% risk in fact) breaking old code. No transistors are used to figure dependencies on the fly, all are used to actually do work. For a given number of transistors a VLIW should have more execution units then a SuperScaler RISC or CISC, at the cost of having no binary upgrade path.
EPIC reads a stream with data dependencies marked, but no information about execution units. You can alter number of functional units, and their latency and still execute the same code. Many transistors are needed to figure out functional unit use on the fly, none to figure data dependencies on the fly. For a given number of transistors an EPIc should have more functional units then a SuperScaler RISC or CISC, but fewer then a VLIW. It pays a cost relitave to the VLIW for having an upgrade path. The compiler pays a cost relitave to SuperScaler designs for having to find data dependencies at compile time.
Now my reply to allen's post:
1. The compiler has to explicitly package instructions that have no dependences into parallel issue packets. This task is currently done by hardware in superscalars. [...]
Yes, however these packages need only be free of data use dependences not executions unit dependencies (this is the big diffrence between EPIC, and traditonal VLIW).
For this to work right, almost all instruction, pipeline and functional units characteristics have to be exposed. For example, for software pipelining (a technique to overlap instructions from different iterations of a loop) to work, pipeline latencies, and functional unit resource constraints at each time step has to be carefully considered.
To get maximum proformance this is correct. From a "normal" VLIW you need it to get a working program. This diffrence is important. If you own a Multiflow (one of the defunct comercial VLIWs) and you upgrade it's CPU all of your old programs are incorrect (diffrent load latencies), and if you managed to compile your code to work with both load latencies, you still can't use more adders per cycle because the exact instructions that are executed per cycle are set in the code.
If you upgrade from a Merced with three integer execution units and two load units to one with six integer units and one load unit your old programs continue to work. The may run faster, or slower, but they still work.
I don't think you need to know all the details of the Merced microarcheture to get decent proformance. Just move the loads as far from the uses as you can, and get as many instructions marked intependent of their neibors as possable. You may end up moving loads farther away then needed, or marking more things as "can run in the same cycle" then your Mercend can gobble up, but that's ok. It won't kill you. It might make a furure Merced faster even.
2. EPIC is basically VLIW, but don't say that because all VLIWs (except DSPs like TI's C6) have been commercial failures. Besides it's not as salesirific as VeeEllEyeDoubleU.
The EPIC is basically a VLIW, except it is a little slower (for a given transistor budget), and it has an upgrade path. I think the upgrade path makes it comercially diffrent from VLIW.
3. The compiler is crucial. So far, only Univ of Illinois IMPACT group and HP CAR group really really knows how to build one well. (My opinion of course)
Multiflow made a good one (well, it got good results most of the time, it was pig slow). DEC eventually bought it when Multiflow went under.
Also the compiler isn't as hard as it is for VLIW. With VLIW if you get the latency wrong you don't run. EPIC just stalls. Kind of like SuperScaler. Getting max speed requires tons of work, but the same work would speed up a SuperScaler (by exactly the same amount, if the SuperScaler has the same number of functional units). I think the big diffrence will merely be that EPIC CPUs will tend to have many more functional units so the bad-compiler vs. good-compiler will be more like a factor of 8 then a factor of 4 (or factor of 2 on a PII/PPro/PIII).
4. For more technical info, read comp.arch, look at proceedings such as MICRO. See also www.trimaran.org. Just don't listen to the clueless.
Indeed. And that's not a slam, your opnions were well thought out, I just happen to think that requireing explicit dataflow (EPIC) is very diffrent from explicit dataflow AND instruction scheduling (VLIW).
Before making comments about the students being stupid, one should consider that the article states that ALL 12 students failed. This is not normal. Can anybody out there recall a class in which all the students failed?
My STAT400 class at UofM. The Prof didn't speek english very well (not the normal "not very well", worse then that), and had a hard time explaining anything. He was russian, and I think he learned his english in France. I'm fairly sure this was his first class in the USA. It didn't help that STAT400 was a hard class to begin with.
The university promised he wouldn't teach undergrads again. No free retake. No lawsuit. A free retake would have been fair, I don't think a lawsuit would have been justifyed. For that one would have to prove that the University knew (or should have known) that the guy couldn't teach. I doubt they did.
As for this lawsuit? I donno, if the University said in some offical capacity that anyone who can point n' click passes, and they knew that wasn't even close to true (from previous semesters), then they really did falsely reprsent themselves. After all if you signed up for (say) STAT400 because the pre-req was CALC2, but it really required DiffEq (which you didn't have) is it really your responsability to find previous students and check to see if the printed PreReq is correct?
Should it be legal to rip people off just because they are dumb? Careful with your answer Marylon vonSavant may be the one defining dumb next year...
I am afraid Linus will hold back scaling Linux up. He even mentions that one will only be able to use a modified (non-standard) version of Linux if you want to run on 64 processors or more. It is true that in order to scale, you need to make things more complicated and possibly slow for single processor machines, but this should be done. I mean, how many 386's are there running Linux nowadays? How about in 5 years?
I would bet money that there will be many 64 processor machines out there in 5-10 years. Moore's Law is going to give out eventually on the single processor and the only where to move will be in the parallel direction. Linux should be prepared for this.
I think Linux will allways run quite well on machines in the $1000 to $3000 proce range. When such machines have 64 CPUs (or 64 hardware level threads, maybe not as many physical CPUs) then the base Linux will run quite well on it. After all that's what most Linux developers have, so thats what will get the most work. It will allways run somewhat less well (but still decently) on the cheaper and more expensave machines. At least if the future follows past trends.
However I don't see any signs pointing to cheep large scale multiprocessing. The prices on 2 CPU machiens have dropped dramatically over the last few years, but the price of 16CPU systems has been fairly stable compaired to single CPU systems. The Mediaprocesser (the only cheep general purpose multithread CPU that was aiming to go comercial) has sunk without a trace. The only two comercial multithreaded CPUs I know of are the Terra which is only being sold in really large machines (think bomb testing, and weather simulations, not kick ass raytracer), and um, that thing I just read about in EDN which is targeting 8bit and 16bit systems.
I would love a 64way machine. I do raytracings (when I'm not coding, sleeping, or watching TV, actually I frequently raytrace while sleeping, watching TV...), so lots of compute will do me good, even if I only have a one giant lock kernel.
That is your problem. You used SunOS 4 and actually liked it. No wonder you use FreeBSD instead of Linux: FreeBSD has the same flaws.
What was my choice pre-92ish? I think Linux existed then, but few had heard of it (I hadn't!). If I had I probbably would have run it. Besides I really liked it because of the OSes i had been payed to hack on at the time (pre-MacII MacOS, DOS, SunOS, Ultrix, AOS (IBM's BSD port, not AIX)) it seemed to be the best.
In case you hate GPL stuff:
I don't. I'm not overly fond of SysV flavored Unix, which Solaris is, and Lunix's userland tends to slanted towards. I don't have anything against Linux, I just happen to like FreeBSD better. I may even change my mind someday. It's a personal choice. I don't think your a moron for using Linux. I do think your a moron for expresing yourself that way.
Besides if I hated GPL, large parts FreeBSD would be unusable (like the C and C++ compilers).
Of course -- very useful to decrease the performance loss due to context switching. Completely pointless in tasking system with one application running, and doing large amount of display output through the driver in kernel, but things of that kind don't run on sparcs.
While they are sometimes useful for that, the only systems I have ever seen work that way are embeded applications with fewer important tasks then register windows, i.e. not Solaris, nor Linux, nor BSD/OS on the SPARC.
What they do get used for is local variables, arguments, and returns from functions on the call stack. As long as the call stack grows no deeper then the register window depth the first 8 "arguments", "returns" and "locals" are stored in the register windows*. As long as the call stack depth doesn't excede the number of windows none of that memory traffic hits the cache, or the memory bus. If it does excede the depth then you have the overhead of an interrupt, and all that memory I/O in one bundle. Genreally enough leaf functions are called to make this a win. Also there are more collesed writes this way then even with a good write buffer.
Unfortunitly it does have the negitave effect of making context switches more expensave (you have 100s of regesters to save rather then 32). It is also somewhat limiting on other parts of the design. If you force a pipeline stall when you switch register windows they have almost no effect on the design, but that would cost as many as 15 cycles on todays CPUs, almost as expensave as a cahe miss, far far more expensave then a cache hit. It also has a negitave impact if most of the function's stack frams that get written to (and read from) memory use signifigantly fewer then 8 inputs, output, or locals. (note some of these registers are tipically used to hold program counters of callers, memory addresses of stack frames, and other grot, you use more then it would appear just glancing at C source code)
If you still want to know more, pick up a good CPU design book (I recomend Hennsey & Patterson, but only because I used it at the UofM, there may be better).
* (actually the AMD 29K had variable sized windows, and other non-SPARc systems worked diffrent ways, but the SPARC is the only register windows system still in production that i know of, so I'm going to stick to talking about the SPARC's register windows, even where other implmentations may get around many or all of the problems the SPARC has.
I hate to disappoint you, but the Sparc chips SUCK. Can you say "Register Windows?" At least Intel chips seem to scale to faster clock speeds pretty well.
Register windows isn't why the SPARC is behind the PIII. Try compairing the research budgets for the Ultra2, and the PIII. Or go read a good CPU arch. book like Hennesey & Patterson. Register windows are no longer thought of as much of a win, but they don't suck nearly as badly as variable length instructions.
Variable length instruction make it much harder to decode multiple instructions per cycle. Here is a thought expariment. You have a decode unit for a "all instructions are 32 bits" machine. You want to decode two instructions per cycle (that is two instructions at the same time), so you use two decoders (one decodes the instruction ad PC, the other at PC+4). Let's say you have a decoder unit for a machine that has 16bit and 32bit instructions, and again you want to decode two instruction per cycle. You need one decoder for the instruction at the program counter, and another for the following instruction (just like the all32bit CPU), however since you don't know if the second instruction is at PC+2 or PC+4 you need three decoders!
Now I don't know the exact numbers, but I think the x86 has at least four instruction sizes (and if I'm wrong I'm probbably guessing low), so to decode two instructions per cycle you need five decoders. To decode 3 instructions per cycle you need twenty-five decoders!
Is it any wonder the as-yet-to-be-released AMD K7 is the first x86 that decodes 3instructions per cycle, while the TI SuperSPARC from ~94 was the first SPARC to do so?
For databases it sure is. There are still applications that run out of CPU. For some reason raytracing sems to be the only one I run into.
A lot of Sparcs these days have gigabit backplanes, so they don't spend 90% of their time waiting for the IO subsystem.
I use both UltraSPARCs and PCs (both running BSD/OS). The PCs arn't noticable behind in disk I/O. The PCI bus is quite fast. Fast enough that Sun (and many other Unix hardware venders) has switched to it on their "newer" systems. Even the big E10000s have "I/O" boards that plug into the FHB (fire hose bus?) that do PCI I/O. The SBus was very fast when it was introduced (~1991), but it isn't faster then the 33Mhz 32bit PCI bus.
SPARCs may well seem to have faster disk I/O then PCs, but I expect that is because most SPARCs have SCSI disks, and most PCs have IDE disks. For all the improvments in transfer rates IDE has seen over the years, I beleve it still can't queue many requests (so it can't usefully reorder reads, nor writes even if it has some sort of NVRAM), and I beleve it still interrupts you for every four (512 byte) blocks, that's 32 intrrupts for a 64K I/O which SCSI could easally do with one intrrupt. A smart SCSI controler (and they exist) could read commands from a list (that the CPU can expand while the controler is using it), and not gennerate intrrupts until the entire list is processed (or on commands that have an intrrupt on completion bit set). That reduces the CPU spent on intrrupt processing, which might be important, and definitly reduces the time the disk waits on the CPU!
I have seen PCs with SCSI disks turn in great I/O numbers. Even when you put a RAM disk on the SCSI bus, the PC wasn't signifigantly slower then the SPARC (and both used nearly the entire SCSI bus, but I can't remember if it was a 20MB/sec bus, or a 40MB/sec bus).
Where SPARCs beat PCs is backplane bandwidth, which matters if you have more then 132MB/sec of I/O going on, or tons of memory bandwidth you need to use. You can also get SPARCs with many more CPUs then I have seen PCs. On the other hand the single CPU proformance of the Intel CPUs is very hard to beat. Not because Intel has a better archature then the SPARC (variable length instructions make multiple instruction decoders a giant pain, which is why the PIII still only has two, and the K7 three vs. the Ultra2's five; register windows only cause minor pain for the SPARC, and the now-quaint beanch-delay slot isn't a huge problem). No, Intel is ahead because they sell so many CPUs that they can justify an unbelevable research budget. With enough thrust a barn can break the sound berrier.
That's fairly old news. They have a paper on it in trhe '98 Usenix procedings (at least the abstract of it is avail at www.usenix.org). It will run many Linux binaries. No recomplation needed, and I don't think they have a Linux complation enviroment. I have forgetten if they do it with syscall emulation (like FreeBSD), or with shared lib interposition (which would be 100% useland, but wouldn't run quite as many things).
See the paper if your intrested. Personally I was more intrested in how humbling it must be for SCO (and other comercial Unixes) to have to emulate the free ones to widen their software base!
Slashdot Mirror
HTML is a bit limiting. Using tables to lay out widgets is Ok, but missing progress bars, and hot beng able to give user feedback except as the result of clicking a submit button is a big big disadvantage.
The only thing with a real GUI I have done in years is a MP3 jukebox player (streaming mp3's over HTML into mpg123). As it selects songs randomly (baised on user ratings) it needs to display the song title (and disc name, and the band, and the current rating, and blah blah). It also wants to display a progress bar. Oh, and of corse it wants to play the sound on the machine with the speakers, not the server in the machine room.
I did do a GUI mock-up in HTML, and that was pretty good. Actually a friend did a set in HTML after I did one or two in pencil. That was very helpful. Showing off the HTML one to a few potential users was much more useful then showing my cruddy pencil drawen one.
I imagine many other GUIs have similar problems. I expect alot of them would also be doable in HTML with varying degrees of suckage.
Choice seldom makes it worse for those doing the choosing (Linux folk in this case). Choice does make it worse for those being chosen. The PPC would be in much better shape if it were the only game in town.
In this case I think it is hard to not choose the alpha if you want maximum single CPU speed, or the x86 for minimum price.
I'm not sure what gets you the best bang for the buck. I expect the ARM gets the best bang per milliwatt (even the new 600Mhz intel ARMs run fairly cool).
I honestly don't have a clue what the PPC is best at other then running PPC code!
I don't see why you would think that. My original post disn't espouse anything (except maybe cheep SS7 motherboards). This post has a bit more espousing in it. However you should note I never espoused anything merely because it was popular. I did say PCs were cheep, and it would be hard to beat them on price. However that is (a) true, and (b) not a popularity argument.
Thank you. I may, of corse, be over excited about the iBook merely because of my fondness for 802.11.
Frankly I don't see why a cheap PPC motherboard is going to make a huge diffrence. PC motherboards are quite cheep, under $100 for a Super7 motherboard. So if the PPC is going to compete in price it has a long road to hoe. A free design doesn't mean free motherboards, in fact the free design might not be as cheep to make as some of the more mature PC motherboards!
The fact that Linux is more or less processer agnostic just makes it worse, after all why go for a PPC rather then an alpha just because there are vague roumors that the Alpha will gasp it's last any year now? I mean if switching to a new CPU is so easy, why not use the Alpha until it actually gasps it's last? (assuming of corse that the Alpha is faster -- with the SPECmarks seem to say, and cheap enough)
The only real argument I could see for using the PPC is if it (the PPC) actually made it into nice cheep machines, like maybe the portables (they seem relitavly inexpensave for what you get -- but I havn't looked at PC portable prices, so i may be in for a shock). Actually that isn't the only argument. It would be intresting to see Linux on one of the big PowerAS machines...nicer still to see it hosted under VM on a 390 (but that's not a PowerPC).
I think there is something else going on there. The folks who learned to program on punchcards (or even in batch mode with a "real" editor) by and large have a few diffrences from people who learned to program directly in an editor:
So do they write tighter code because they scetched it out in pencil n' paper first, or because they learned on a machine with a 5Mhz clock? Does it take them less time to debug because they flowcharted, or because they have had two decades experiance in hunting bugs?
Personally I'm in the intermediate range. I started programming at the head end of the '80s. I never did punchcards, and avoided batch untill collage (in '89 or so). I don't pencil schetch out code (except in Pascal class over 15 years ago). I do whiteboard out my data structures. I have imense respect for people more skilled at it then I, and I beleve they tend to be older then I am. I think I'm at least as good as my Dad was when he tought me, but he has gotten 18 years better at it, still leaving me a lot of room to catch up. Some folks who are younger them me just plain have more natural talent at it, and are also better then me.
However the thing I won't claim is that pencil programming will make you better, or that whiteboarding data structures will. Those help some people, and not others. If you havn't tryed it, give it a shot, maybe it will work for you. also try "writing one to throw away" (preferably in a language simmilar to, but not the same as the one you need to use of the actual implmentaiton, to avoid the chance of actually using the throw away). Find something that works good fir you, and every few years try something else for a project or two (havn't used hungarian notation? give it a shot -- it didn't help me, but maybe it'll give you an edge).
Careful, there is some rather intresting stuff going on in the FreeBSD kernel. Taking filesystems for example the new ffs soft update code is nearly as fast as going async (removes 99% of sync writes) but is as safe as a sync version of ffs. Runs quite fast as well, just be careful not to try to remove too many huge tress of files at once (that will tax kernel memory usage, for 30 seconds or so). With soft updates you can also skip the fsck on boot, schedule it for some other time (you still need to unmount the FS before fsck, but using it between a crash and fsck is safe!). More intresting yet is the snapshots for ffs code, which not only allows "NFS toaster like mid-day live backups", but also allows you to fsck the snapshot, and apply the changes to the live (mounted) filesystem safely.
There is a good chance it will run faster then the log structured filesystem, and it defintly can reboot faster!
There is a good paper about how it works in the most recent Freenix procedings, which you may be able to find at www.usenix.org
Yes, RT doesn't mean your computer is fast enough, but that doesn't make RT useless.
That makes sense when the A/V hardware is cheeper then a new CPU for the task (like MPEG2 decode use to be, and still is for some people). It is much less fun for things like MP3 decoders, who wants to pay $50 for MP3 decoder hardware rather then kiss off a few percent of their CPU?
If you have a nice fast CPU would you feel good at paying $100 for a MPEG2 decoder, or would you rather kiss off 40% of your CPU when you happen to watch a MPEG stream?
Intel, AMD, Sun, and Compaq spend megabucks on research for their nextgen chips. Should Creatave Labs try to compete?
Besides most A/V stuff needs relitavly little in the way of real-time garentees, for 30fps video it "only" needs to handle 30 "hard" real-time intrrupts (per second), allow dirrect screen I/O from the real-time task (or have a RT window system, which could be hard), to buffer enough data to smooth out the jitter for non-real-time I/O with a network or disk. Most A/V stuff can be converted to "easy" RT (not soft RT), and big buffers.
Note: "hard" Real Time has real garenttes on how long intrrupts take, and what can intrrupt a RT thread. For example "no more then 200ns from intrrupt to thread dispatch, no interrupts from lower pri until the thread releases the CPU", these limits are never ever violated, except in the event of a hardware failure. Sometimes valuable equiptment depends on it (computer controled milling machines, or chemical processors maybe), sometimes lives (flight control software in a inharently unstable airplane like the Stelth). "Soft" Real Time makes similar garentees, except they can break them once in a while (say when the disk decides to do a thermal recalabrate). These are industry standard terms. "Easy" real time is not a standard term, but i use it to talk about a system that allows only a subset of operations in a "real time thread", like adding things to a buffer, and taking them out of the buffer, and maybe some non-complex I/O (like looking at the current value of a DAC, or causing a pin to go high or low, NOT talking to a filesystem). It's no where as difficult to do an "easy" RT OS (or extention) because you only have to deal with the intrrupt handler and scheduler, and the small number of permited RT operations. You don't have to fix all the filesystems, all the device drivers, and all the anything else that has non-determinstic timing, or deterministic timing, but too long to make useful RT promises.
It uses two AAA's like a normal (non-V) Palm. The batt you see is the one for the wireless crud which gets charged from your AAA's automagically. Why? I donno, maybe it needs some odd voltage Palm couldn't get from the AAA's, or the wirelsss goop was from another compony and that was the way to tack it on with the fewest changes, and therefore the lowest time to market.
It's a bit of a kludge.
Ethernet is a pretty hacky design, and won because it was cheeper to build then TR. I'm not exactly in love with it as a way to talk over cables (or fiber), but it actually is a really spiffy way to do wireless (shout until you can't be heard...)
30%? You seem to be way off. 60% in general use seems to be a much better rule of thumb. If you have a switch (and they are so damm cheep these days) you can get far closer to 100%, well over 100% with some valid mesurements. As far as I know Ethernet plus a switch per port is cheeper then Token Ring by a fair margin.
While I think FDDI/CDDI (essensally Token Ring at 100Mbit/sec) is very nice, and doesn't take any effort to get it to run in the high 90% range, it costs more then 100Mbit ethernet plus a switch! It's so hard to argue for it that I have more or less given up on it except when I can make a case for the duel ring CDDI (that way even the network hub can be a redundant item). I'm totally unaware of any Token Ring like offering in the 1Gbit range either, so for the moment it appears to have no future. A pity because I have allways liked it.
Many GNU/Linux/Open Source advocates do take a market tactic. They claim their way gets better product at a lower cost. Ethernet isn't better then TR at any given speed, but it's price/performance is definitly better.
Only that you seem inexperianced with Ethernet. Or maybe that I'm in a contrary mood today.
So the K7 is faster then the Xeon at SPECint, and much faster for SPECfp. When multi-processor chipsets come out it will in all likelyhood be far faster then the MP Xeon (thanks to DECs point to point "bus" design). The K7 can eventually beat the Xeon's L2 cache size and match the speed (note that the SPEC numbers are better with a worse L2 cache, I assume due to the far better L1 cache, and a more agressave OOO engine).
So far things are better for AMD then I recall them ever being. However each time AMD had a CPU that could threaten Intel they have had problems making enough of them. Will things really be better this time?
From reading AMDs press release there are a few clues. They will not be selling their CPUs at a fixed discount from the similar Intel ones. They listed a bunch of reasons, but I susspect a big one is they will adjust price to reflect yeild. They also keep talking about the K7 gunning for the high-end market (after all the K6 will not be discontinued for quite some time!). The profit per chip is far higher there, fewer chips will have to be sold to earn the big bucks.
The downside of corse is many K7 systems won't be signifigantly cheeper then the Intel Xenon systems (or so I assume). We may even see the MP K7 systems costing more then the Xenon, after all it will in all likelyhood be a much faster beast.
The upside is Intel may be forced to cut Xenon prices, and in any even when Intel starts beating the K7 there will be more price cuts (and AMD's new fab plant may help them manage volume shipments for once)
On a PII-333 with the Symantec JVM a SSH client written in Java (no assembly assist for the Crypto) can scroll the screen far faster then I can read. I can tell when it GC'es (or maybe when the network loses a packet) because it pauses long enough to make out a few words (my "standard" test is to cat an ~500K /etc/termcap).
Disabling the SSH encryption it timed as faster then the Telnet that came with my Windows box (i.e. receving SSH packets in the clear, doing a CRC, and displaying them was faster in Java then doing even less work in C -- I assume they didn't feel a need to tune for speed, and I did).
On a PPro-180 under FreeBSD the Sun JDK limped along fairly painfully, I could guess how many lines were in eatch SSH "packet". (actually it was a Duel PPro-180, but I dout Java tryed to schedule diffrent threads on diffrent CPUs)
The JVM implmentation makes a huge diffrence, but I would say Java is fast enough for a lot more tasks then people tend to give it credit for.
Indeed, it's something like 180K lines of code. It has tons of things that are sometimes extreamly useful. Not just the guaranteed I/O rate stuff, but b-tree baised directory lookups (no more slow operations on bloated news directories). Adding more disks to an existing XFS filesystem is great. It's all great.
At a price. It's 180K lines of code after all! I don't see a 8M second hand 386SX running XFS. I think there is a future for EXTn. If EXT3 comes soon enough, it could have a long future. If it comes too late I'm not sure who will want to hack on it rather then XFS.
What does SGI have to do "quickly" other then actually release the code? You mean just because it's big Linux hackers can't get it to work on their own? Only "real" SGI programmers can do anything with it? If so SGI isn't getting much by giving it away! What happened to "with enough eyes all bugs are shallow"?
Well tons of 2CPU tests will be done becasue 2CPU machines are cheep enough to be affordable to hobbiests. The K7 may or may not make 4+CPU machines affordable as well. "Corporates" may well put some time into testing "Linux XFS" on big machines because they think it is a useable platform. Or they may not. It's not like they owe Linux anything. The bigger distribution componies (i.e. Red Hat) may well do testing, or donate test equiptment, they make their living off Linux after all, and many of them are gunning for the server market.
But does it matter if it gets 4+CPU testing? If Linux isn't commonally run on 4CPU systems then it won't see much 4CPU test, nor will it be easy to argue 4+CPU is important to it at that time. When 4+CPU becomes important it will see lots of testing there.
Linux only has to pay that price is it views corprate acceptance is a goal worthy of that price. If it holds it's ground either corprate acceptance will come anyway (that appears to be happening at the moment), or it won't, but Linux will still be "pure".
So before you accept a binary licence, or a single bit of software that is less open then you want, ask yourself how bad do you really want it? Is there another card you could buy that's maybe only a little slower (or more expensiave) that has a more open driver? Or is it something you can do without for a while?
You only have to give up what you are willing to give up.
P.S. this doens't mean you have to give nothing up. I have a copy of Civ call to power, and no source code. It's a deal I was willing to make. But I don't have a single card in my machine I don't have driver source for, even if that means I don't get anything like a SB Live for 18 months (my best guess on how long an open alternitave takes to arrive). Other people are free to make other choices.
BSDI's Linux compatability is done diffrently from their SCO compatability (and diffrently from FreeBSD's as well). I don't know much about lxrun, from skiming the FAQ it looks like it works the same was as FreeBSD's Linux emulation.
The FreeBSD Linux compat stuff, and the BSD/OS SCO compatability stuff both hook into the syscall interface and do their emulation inside the kernel . Which makes it harder to modify, and fix, and bugs in it will cause the whole system to be less stable.
The BSD/OS linux emulator works entirely in userland. It is basically a diffrent ld.so (the runtime shared linker), which remaps calls to things like write(2), read(2), ioctl(2), and syscall(2). It works quite well for dyanmically linked ELF stuff. It doesn't work for statically linked code, nor for code like Netscape which has inline assembly for system calls (in their case select).
I don't think one system should be any faster then the other. So the only real issue would be whether the incresed ease of modification is worth giving up a.out support (YES), and static bin support (maybe).
This makes it sould like Thompson will pick the "complex but perfect" choice. That appears to be very much not the case. Look at windowing systems for a moment, Linux seems to have chosen X11 as it's windowing system. A good choice, the code was available, many applications allready use it, while it has huge flaws it is gennerally beleved to be usable. Inferno's windowing system is 100% new. If you look at X's drawing primitaves there are tons of them, there are dozens of ways to manuplate a "Graphics Context", diffrent ways to draw text made of 8bit charactors or 16 bit charactors, a call to draw a line, a call to draw multiple lines at once, maybe as many as 150 diffrent X calls to "draw stuff". Then there are liberies built on top of X. Inferno's windowing system has exactly one drawing primitave "take rectangle A from this pixel source, and scale/rotate it to size B in that pixel sink". (In Inferno pixel sources/sinks all have alpha masks) Then liberies are built on top of that.
Which is better depeneds on how you judge. If I were making an OS and wanted to see 3rd party applications on within five years I would never make a new windowing system, not matter how cool. I would use X11, or Display PostScript (or both).
Supports more hardware then what? Linux definitly supports more PC hardware then Plan 9, and almost defintily more hardware by count then Plan 9. Same for Inferno if you ignore Inferno running as a guest OS under Windows (and whichever IBM S/390 OS's they support). Inferno runs a few places Linux doesn't (like the Sony PlayStation), but I expect Linux runs places Inferno doesn't, and could probbably run on just as much bare metal as Inferno.
He didn't complain that Linux doesn't support lots of hardware. He complained about it's reliability. Which isn't something I can't comment (much) on, I havn't found Linux to be particurally unstable, nor have I heard creditable reports of it being unstable. As others have said maybe he tested an old version of Linux.
Note: we still have the complex overengineered *interfaces*. Programmers please think of all the work you need to do to open a TCP socket, connect it to a remote host and port (three syscalls, plus a call to gethostbyname, and getprotobyname). Contract that to Plan9's:
finger_fd = open("/net/inet/tcp/hostname.domain/finger", O_RDWR, 0);
I'm sure I didn't get the exact path, I'm not a Plan9 user, I just read all the White Papers I could find. Also note that this is so simple you can write a finger client as a tiny shell script.
Linux or *BSD could choose to implment this in addition to the normal interface (there are several *BSD implmentations of this sort of thing using portals), but they can't discard the overcomplex socket interface.
As a matter of Law, no signifigant quantity of copyrighten material (which I think means cpio in it's entierity, some header files that really only have one strightforward representation, and nothing else). Go hunt up AT and T's lawsuit against BSDI.
I expect almost everything he ever produced that was intresting, and not turned into a product has a paper written about it. A paper that can located and read. It is depressing that so little of it has code you can get for free, or even for a "modest" fee (Lucent's Toolchest II CD is $500, more then I can afford at home, a pittace for my employer to buy).
The thing I find depressing is I'm sure there are flaws in Linux, and if he had pointed out a handful of them people would rush off and work on them, maybe even manage to fix them. Unfortunitly all his Linux comment will do is cause some to snicker, and other to get pissed off.
P.S. I think one big reason "Plan9 lost in the marketplace" is Plan9 was never really in the marketplace. You could get it for free (or cheep? Inferno was free), and do non-products with it for free. A product baised on it would cost $250,000 or call for pricing. Plan9 is cool, but i can't see it saving $250,000 over Linux or *BSD on very many projects.
Random numbers are far better then known plaintext. Random numbers are also really hard to get on current machines. What we have is psudo-random (see the man page for random), and on some-OSes we-did-some-stuff-that-may-be-pretty-random (see /dev/random). Psudo-random isn't so much better then known plaintext, in part because sometimes it ends up being known plaintext (like if a program uses the "normal" method of seting the random number seed to the current time, you will amost know the random text). In part because the streams some RNGs make can be recognised.
Still psudo-random would be better then known-not-random.
Also the original message had a small flaw, eight times the current 2K *bit* key size is 2K *bytes*, which isn't way huger then many things you may want to protect. Still if we have to keep expanding the key space every few years it will become a real problem.
But you wouldn't have access to only bananas. You would have everything you have today, except guns (or actually legal access to guns, making guns illegal will not make it impossable for someone who is willing to break the law once they get a gun to break a law by getting one!).
So you can cut down on shootings, but you would get more stabbings and more bombings. In fact if the disturbed killers from this most recent incident had skipped the guns entirely and just used the large bombs they got into the school kitchen they would have killed 100s of people. (they apparently set them to go off a few days later, I assume they thought people would have returned to classes by then).
Maybe you would reduce the killings that number in the tens, but would the killers (that you claim will allways be with us) start killing with crossbows and knives (which I assume would kill maybe half as many people), or would they use homemade bombs, fuel-air-munitions, or poison gas (ever wonder what you can buy for $100 at a pool supply store?), which may actually kill many many more then the guns we have now?
I know you have recanted this, but for the benifit of people that don't know the diffrence but want to I still want to talk about it.
When you make a loan you secure a promise that you will be repayed the loan amount, and for your trubble intrest. Unless the loan-ee goes bankrupt (or is a theif) you get your money back, plus the profit. In other words the value of holding the loan is almost allways more then the amount it was made for, and less then a fixed value (ignoring adjustable rate loans, and high risk loans, and even the time value of money). Concrete example: I loan AT&T $100, they promise to pay me $105 at the end of 12 months. During that time I should be able to sell that loan to someone else for more then $100, but less then $105. At the end I'll get $105. I'll make up to $5, and have almost no chance of losing money. (If I made this loan to someone who has been in bisness less time then AT&T, or who is in trubble the risks would be diffrent, but so would the reward)
When you buy stock you secure a promise that the compony will try to make a profit, and that it will obey your will in proportion to your stock ownership (not very important for this discussion, so I won't comment on it farther). In other words you have no idea how much much it will be worth in the future. Concrete example: I buy a share of AT&T for $55. Baised on recent history I may be able to sell it for $65 next month (it was in the mid-$60s a month or two ago), I may also only be able to get $38 for it (it was in the high 30's last May). More potential for profit, more risk.
Owning someone else's debt (say AT&T debt bonds) is an OK way to make a little money fairly safely. It's gennerally a poor way to make fairly large amounts of money. Owning stock is an OK way to make lots of money with a high degree of risk.
Please don't rush out and start buying and selling stocks, or loan bonds (or making loans directly) baised on this advice. It is very genneral, and may even be wrong. I'm not a financial advisor. Please see one before you do anything like this.
As much as I enjoy using Perl to solve problems, I have to agree with Henry Spencer's description of the language: "AWK with skin cancer"
My summery of EPIC vs. VLIW vs. SuperScaler (note I use the term "functional unit" to mean "thing that can execute some kind of instruction", more functional units means a faster CPU, it's an oversimplifaction, but useful in this context):
Now my reply to allen's post:
Yes, however these packages need only be free of data use dependences not executions unit dependencies (this is the big diffrence between EPIC, and traditonal VLIW).
To get maximum proformance this is correct. From a "normal" VLIW you need it to get a working program. This diffrence is important. If you own a Multiflow (one of the defunct comercial VLIWs) and you upgrade it's CPU all of your old programs are incorrect (diffrent load latencies), and if you managed to compile your code to work with both load latencies, you still can't use more adders per cycle because the exact instructions that are executed per cycle are set in the code.
If you upgrade from a Merced with three integer execution units and two load units to one with six integer units and one load unit your old programs continue to work. The may run faster, or slower, but they still work.
I don't think you need to know all the details of the Merced microarcheture to get decent proformance. Just move the loads as far from the uses as you can, and get as many instructions marked intependent of their neibors as possable. You may end up moving loads farther away then needed, or marking more things as "can run in the same cycle" then your Mercend can gobble up, but that's ok. It won't kill you. It might make a furure Merced faster even.
The EPIC is basically a VLIW, except it is a little slower (for a given transistor budget), and it has an upgrade path. I think the upgrade path makes it comercially diffrent from VLIW.
Multiflow made a good one (well, it got good results most of the time, it was pig slow). DEC eventually bought it when Multiflow went under.
Also the compiler isn't as hard as it is for VLIW. With VLIW if you get the latency wrong you don't run. EPIC just stalls. Kind of like SuperScaler. Getting max speed requires tons of work, but the same work would speed up a SuperScaler (by exactly the same amount, if the SuperScaler has the same number of functional units). I think the big diffrence will merely be that EPIC CPUs will tend to have many more functional units so the bad-compiler vs. good-compiler will be more like a factor of 8 then a factor of 4 (or factor of 2 on a PII/PPro/PIII).
Indeed. And that's not a slam, your opnions were well thought out, I just happen to think that requireing explicit dataflow (EPIC) is very diffrent from explicit dataflow AND instruction scheduling (VLIW).
My STAT400 class at UofM. The Prof didn't speek english very well (not the normal "not very well", worse then that), and had a hard time explaining anything. He was russian, and I think he learned his english in France. I'm fairly sure this was his first class in the USA. It didn't help that STAT400 was a hard class to begin with.
The university promised he wouldn't teach undergrads again. No free retake. No lawsuit. A free retake would have been fair, I don't think a lawsuit would have been justifyed. For that one would have to prove that the University knew (or should have known) that the guy couldn't teach. I doubt they did.
As for this lawsuit? I donno, if the University said in some offical capacity that anyone who can point n' click passes, and they knew that wasn't even close to true (from previous semesters), then they really did falsely reprsent themselves. After all if you signed up for (say) STAT400 because the pre-req was CALC2, but it really required DiffEq (which you didn't have) is it really your responsability to find previous students and check to see if the printed PreReq is correct?
Should it be legal to rip people off just because they are dumb? Careful with your answer Marylon vonSavant may be the one defining dumb next year...
I think Linux will allways run quite well on machines in the $1000 to $3000 proce range. When such machines have 64 CPUs (or 64 hardware level threads, maybe not as many physical CPUs) then the base Linux will run quite well on it. After all that's what most Linux developers have, so thats what will get the most work. It will allways run somewhat less well (but still decently) on the cheaper and more expensave machines. At least if the future follows past trends.
However I don't see any signs pointing to cheep large scale multiprocessing. The prices on 2 CPU machiens have dropped dramatically over the last few years, but the price of 16CPU systems has been fairly stable compaired to single CPU systems. The Mediaprocesser (the only cheep general purpose multithread CPU that was aiming to go comercial) has sunk without a trace. The only two comercial multithreaded CPUs I know of are the Terra which is only being sold in really large machines (think bomb testing, and weather simulations, not kick ass raytracer), and um, that thing I just read about in EDN which is targeting 8bit and 16bit systems.
I would love a 64way machine. I do raytracings (when I'm not coding, sleeping, or watching TV, actually I frequently raytrace while sleeping, watching TV...), so lots of compute will do me good, even if I only have a one giant lock kernel.
What was my choice pre-92ish? I think Linux existed then, but few had heard of it (I hadn't!). If I had I probbably would have run it. Besides I really liked it because of the OSes i had been payed to hack on at the time (pre-MacII MacOS, DOS, SunOS, Ultrix, AOS (IBM's BSD port, not AIX)) it seemed to be the best.
I don't. I'm not overly fond of SysV flavored Unix, which Solaris is, and Lunix's userland tends to slanted towards. I don't have anything against Linux, I just happen to like FreeBSD better. I may even change my mind someday. It's a personal choice. I don't think your a moron for using Linux. I do think your a moron for expresing yourself that way.
Besides if I hated GPL, large parts FreeBSD would be unusable (like the C and C++ compilers).
While they are sometimes useful for that, the only systems I have ever seen work that way are embeded applications with fewer important tasks then register windows, i.e. not Solaris, nor Linux, nor BSD/OS on the SPARC.
What they do get used for is local variables, arguments, and returns from functions on the call stack. As long as the call stack grows no deeper then the register window depth the first 8 "arguments", "returns" and "locals" are stored in the register windows*. As long as the call stack depth doesn't excede the number of windows none of that memory traffic hits the cache, or the memory bus. If it does excede the depth then you have the overhead of an interrupt, and all that memory I/O in one bundle. Genreally enough leaf functions are called to make this a win. Also there are more collesed writes this way then even with a good write buffer.
Unfortunitly it does have the negitave effect of making context switches more expensave (you have 100s of regesters to save rather then 32). It is also somewhat limiting on other parts of the design. If you force a pipeline stall when you switch register windows they have almost no effect on the design, but that would cost as many as 15 cycles on todays CPUs, almost as expensave as a cahe miss, far far more expensave then a cache hit. It also has a negitave impact if most of the function's stack frams that get written to (and read from) memory use signifigantly fewer then 8 inputs, output, or locals. (note some of these registers are tipically used to hold program counters of callers, memory addresses of stack frames, and other grot, you use more then it would appear just glancing at C source code)
If you still want to know more, pick up a good CPU design book (I recomend Hennsey & Patterson, but only because I used it at the UofM, there may be better).
* (actually the AMD 29K had variable sized windows, and other non-SPARc systems worked diffrent ways, but the SPARC is the only register windows system still in production that i know of, so I'm going to stick to talking about the SPARC's register windows, even where other implmentations may get around many or all of the problems the SPARC has.
Register windows isn't why the SPARC is behind the PIII. Try compairing the research budgets for the Ultra2, and the PIII. Or go read a good CPU arch. book like Hennesey & Patterson. Register windows are no longer thought of as much of a win, but they don't suck nearly as badly as variable length instructions.
Variable length instruction make it much harder to decode multiple instructions per cycle. Here is a thought expariment. You have a decode unit for a "all instructions are 32 bits" machine. You want to decode two instructions per cycle (that is two instructions at the same time), so you use two decoders (one decodes the instruction ad PC, the other at PC+4). Let's say you have a decoder unit for a machine that has 16bit and 32bit instructions, and again you want to decode two instruction per cycle. You need one decoder for the instruction at the program counter, and another for the following instruction (just like the all32bit CPU), however since you don't know if the second instruction is at PC+2 or PC+4 you need three decoders!
Now I don't know the exact numbers, but I think the x86 has at least four instruction sizes (and if I'm wrong I'm probbably guessing low), so to decode two instructions per cycle you need five decoders. To decode 3 instructions per cycle you need twenty-five decoders!
Is it any wonder the as-yet-to-be-released AMD K7 is the first x86 that decodes 3instructions per cycle, while the TI SuperSPARC from ~94 was the first SPARC to do so?
For databases it sure is. There are still applications that run out of CPU. For some reason raytracing sems to be the only one I run into.
I use both UltraSPARCs and PCs (both running BSD/OS). The PCs arn't noticable behind in disk I/O. The PCI bus is quite fast. Fast enough that Sun (and many other Unix hardware venders) has switched to it on their "newer" systems. Even the big E10000s have "I/O" boards that plug into the FHB (fire hose bus?) that do PCI I/O. The SBus was very fast when it was introduced (~1991), but it isn't faster then the 33Mhz 32bit PCI bus.
SPARCs may well seem to have faster disk I/O then PCs, but I expect that is because most SPARCs have SCSI disks, and most PCs have IDE disks. For all the improvments in transfer rates IDE has seen over the years, I beleve it still can't queue many requests (so it can't usefully reorder reads, nor writes even if it has some sort of NVRAM), and I beleve it still interrupts you for every four (512 byte) blocks, that's 32 intrrupts for a 64K I/O which SCSI could easally do with one intrrupt. A smart SCSI controler (and they exist) could read commands from a list (that the CPU can expand while the controler is using it), and not gennerate intrrupts until the entire list is processed (or on commands that have an intrrupt on completion bit set). That reduces the CPU spent on intrrupt processing, which might be important, and definitly reduces the time the disk waits on the CPU!
I have seen PCs with SCSI disks turn in great I/O numbers. Even when you put a RAM disk on the SCSI bus, the PC wasn't signifigantly slower then the SPARC (and both used nearly the entire SCSI bus, but I can't remember if it was a 20MB/sec bus, or a 40MB/sec bus).
Where SPARCs beat PCs is backplane bandwidth, which matters if you have more then 132MB/sec of I/O going on, or tons of memory bandwidth you need to use. You can also get SPARCs with many more CPUs then I have seen PCs. On the other hand the single CPU proformance of the Intel CPUs is very hard to beat. Not because Intel has a better archature then the SPARC (variable length instructions make multiple instruction decoders a giant pain, which is why the PIII still only has two, and the K7 three vs. the Ultra2's five; register windows only cause minor pain for the SPARC, and the now-quaint beanch-delay slot isn't a huge problem). No, Intel is ahead because they sell so many CPUs that they can justify an unbelevable research budget. With enough thrust a barn can break the sound berrier.
That's what we have here, lots of thrust.
That's fairly old news. They have a paper on it in trhe '98 Usenix procedings (at least the abstract of it is avail at www.usenix.org). It will run many Linux binaries. No recomplation needed, and I don't think they have a Linux complation enviroment. I have forgetten if they do it with syscall emulation (like FreeBSD), or with shared lib interposition (which would be 100% useland, but wouldn't run quite as many things).
See the paper if your intrested. Personally I was more intrested in how humbling it must be for SCO (and other comercial Unixes) to have to emulate the free ones to widen their software base!