IBM's S/390 is. absolutely. there's more than UNIX out there
Don't forget, the S/390 runs at least three Unix like OSes -- AIX, UTS, and Linux (and I expect there is an AOS for it as well).
Plus the S/390 can run more then one OS at once (one of the more popular OSes for it is/was the single user CMS, just run one per user). That is because the S/390 runs a very low level OS (VM/SP) which offers virtual disk controlers and virtual timers, and the like (including a virtual MMU) to the host OS.
As for reliable, sure. There were S/370s with multi-year uptimes. I would expect the same from the S/390.
Sure most people don't know what to do with source code, but that doesn't mean having it isn't good for them.
Let's say you contract to have me build you a spiffy program that, um, helps draw stuff. Later you realise you forgot to ask me for a spraypaint widget. by that time I'm off doing some other project and my free time has became rare, and I don't really feel like doing a spray paint widget, so I name a really high price. If you don't have the source code you are now out of luck, you either pay me big money for the spray paint widget, or do without one. If you do have the source code you can get another person to add the spray paint widget for you.
Another example. You buy an OS off the shelf. It comes with a free 90-day support contract. You do the install, you need a little help, the help line is slow, or not so helpful, or something. 92 days later you need some more help. If your product was closed source (say MS-Windows, or Solaris) you have to go to the people who made it for support. After all if there is a bug that needs fixing only they can fix it. If your product was open source (say Red Hat Linux) then you can choose to go to Red Hat, or you can go to LinuxCare, or other places. After all any of them could fix the bug.
and then you go to jail for a VERY long time for trial tampering.
Aranging to have a licence broken, and then having the violator's lawyers put on a less then steller defence isn't trial tampering if it is your friend the violator that is having his lawyers put on the less then steller defense. If you do it, it may be trial tampering, and it is a definate no-no for the lawyers who will be disbared if discovered.
That is not to say a staged trial (where plantif and defendent are relly on the same side) is legal. It might be an abuse of process or something. I expect it carries a smaller fine, and shorter jail time then trial tampering. But I don't really know. After all I'm not a lawyer.
P.S. anyone who trusts legal advice from slashdot is pretty dim -- that's my disclaimer and I'm sticking too it.
Re:What happened to JonKatz's other article?
on
LonelyNet (Part Two)
·
· Score: 1
It looks like it has been moved to the 23rd. Maybe Rob doesn't want him publishing in slashdot too offen (or maybe Katz doens't want to publish here too offen -- lord knows he must get a ton of mail each time).
I would guess he decided he wants this one published in a more timely manner, and the other will wait until Wensday.
Science does not really find truth. Now that's a philosophical discussion, but it's an important idea to get your head around when you look at studies like this. Every scientist colors their research with their own ideas. Every bit of science has a bit of social phenomena and 'buzz'.
Wrong.
And right. A scientest doens't find the truth. A study doesn't find it either. They mearly say "when I did this, that happened, so this other thing may be true". The scientific community is fairly untrusting (for good reasons), so before they start beleving it, they read the paper very carefully, and "do this" to find out if "that happens". Then they will try "almost this" and see if "almost that happens". They will think of other reasons why X may cause Y. Eventually they might start beleving that X really does cause Y. Then again they might not.
A single study is the begining of a process. It is almost the same as "Some guy named Bob thinks The Internet sucks", it's almost worthless in and of itself. Only after other people have repeated the study and verifyed the results can it even start being useful. They also have to see if there are other explnations.
For this study, I expect the results will be repatable, but the "only 24 hours in a day" thery might win out over "people that use the Internet are mean" thery.
One question is this: Is it guaranteed that a pointer to item zero in a vector is in fact a pointer to a contiguous block of memory holding an array of foo?
No, that isn't guaranteed. On the other hand, I can't see how to implment it with the time-complexity requiremnts demanded without it being an array (plus a little bookkeeping). I definitly havn't seen it done any other way.
If it is something you need (and I can definitly see the need), why don't you take the SGI STL vector class, rename it, and use it.
For the first five years I used C++ I allways thought of it as C with a little bit of OO stuff slapped on it. After I started using the STL C++ started feeling like a very diffrent (and more usable) language then C.
Is the STL really that much diffrent from other parts of C++? Or is it just me?
Print ads tend to have diffrent 800 numbers for diffrent versions of the ads, or in diffrent placments of the ads when the marketing department is trying to mesure their success. Sometimes they will tack an advert code onto the end of URLs too (I expect not so many people type those in).
When people fill out product reg cards one of the items is almost allways "how did you find out about us".
Sometimes a fraction of the buyers are randomly polled.
When you spend millions on an ad, you will spend a few thousands finding out how well it worked. When you spend thousands on the ad, you may spend almost as much finding out how to mkae the next one better.
Granted, this kind of thing is far easyer with web ads. One of hte tings I remember marketing folks saying they really liked is they could get response data on a change in hours rather then months.
Yes, as far as I recall the Crousoe is a VLIW, with 128bit "instructions" (I think Transmeta calls them "molicules", but almost every other VLIW calls them instructions -- the IA64/Merceed/Itanum calls them "bundles", sort of -- it isn't really a VLIW)
Means the registers are 128 bit each.
No. It doesn't say anything about the register width at all. Nor do the Crousoe whitepapers. I expect that the integer registers are 32 bits, because they have to be to effecently emulate a 32bit x86 CPU. I don't expect they are any bigger because that would consume more power, and more transistors that could better be doing something else if your goal is to emulate a x86. I expect the FP registers to be 80 bits, but they could be a somewhat diffrent size.
There are many diffrent bit widths in most CPUs, make sure you know which one is being talked about. For example, The PPro has a 128bit interface from the L1 cache to the L2 cache, but only has 32bit GP registers. The IA64 has 128bit wide "instruction bundles", but only 64 bit wide GP registers.
I think they combine several x86 instructions in one crusoe 128 bit "instruction" (when they emulate x86 that is).
Pretty close. A traditonal VLIW (like, say, the MultiFlow) has several "functional units", and each "instruction" tells every functional unit what to do. Sometimes you have to tell some of them to do nothing (nop - no-operation).
For example, imagine a VLIW that has one load/store unit, two math units, and a branch unit... If you want it to do a load, an add, a multiply, and a branch you stick that all in one VLIW instruction. If you want to do two loads, a store, an add and a multiply you need three VLIW instructions, the load/nop/nop/nop, the store/add/multiply/nop, store/nop/nop/nop (you don't get to stick it in two just because you have nops -- you are out of the right flavor of instruction slots).
I think the Crosue is one branch unit, and either two ALUs and one LOAD/STORE or two LOAD/STORE and one ALU. I forget exactly which.
Many x86 instructions can be made into one or two slots of a VLIW instruction. Some others will take more then one VLIW instruction, but leave some slots open for parts of other instructions. For example the x86 'ADD m32,imm32' instruction (add 32bit constant to a location in memory) will take a LOAD slot (to get the memory value), then in another bundle (so the LOAD has time to complete) the ALU slot (to do the add), and then in another bundle the STORE slot (to write the results back) -- leaving 3 open branch slots, some open LOAD/STORE slots, and a few ALU slots as well. The code morpher may be able to fill the other slots. It may not be able to fill them all. Some x86 instructions may take multiple full VLIW instructions to carry out (like FSINCOS).
The transmeta white papers have some really good examples of what their code morpher can do. But remember it isn't magic. The PPro, P-II, and P-III, K6, and K7 can all execute two x86 instructions per cycle. The K7 can execute three. Actually in rare cases many of them can execute more then two, but other then the K7 they can only decode two per cycle, so only the K7 has a hope of keeping it going. The Crosoe can't get ahead of the "normal" x86 CPUs just by doing two instructions per cycle sometimes, or three, or even rarely four, if it spends too much time doing one or less. Or even if it spends lots of time doing two on code that the P-II could also do two!
VLIW isn't magic. There is a reason every single VLIW to date has been a comercial failure. Transmeta may have hit on a way to make it not flop. This definatly addresses several shortcomings VLIW has had in the past.
The Transmeta CEO said something like that on that webcast Stanford EE380 lecture. URL is http://stanford-online.stanford.edu/courses/ee380/ main.html if you want a streaming version of the webcast.
I'm sure he said the Crosue was a 128bit VLIW. I can't beleve the Crosue has 128 bit GP registers though. Sorry. Remember there are lots of diffrent bit widths in CPUs. Size of the integer/address registers is only one of them.
My info comes from Transmeta's white papers (on theur web site). Hennesey and Patterson's Computer Archicture textbook (I got mine form the University bookstore in '92, there are probbably better books to read about VLIW from, but i don't know any). And last, but not least common sense.
The thing that we need to know is whether or not Transmeta is going to implement an emulator for MMIX.
I can't imaging that the current Transmeta chips would be good at it. While they are not x86's they are designed to be good at emulating x86 code, not MMIX code. The underling needs are pretty diffrent. Even though the Transmeta chips are designed to be fairly efficent emulators of x86 code, and I doubt they have been designed to be poor emulators of other things, they will have a hard time emulating things sufficently diffrent from the x86. For example:
The Crousoe emulates the 32bit x86, so it almost certinly has only a 32bit ALU, so the 64bit adds on the MMIX (or Alpha, or V9 SPARC, or...) will require a 32bit add, a carry check, and another 32bit add. Multiplys are much worse.
The Crousoe emulates a machine with almost no registers. Internally it has about 40 (from the white paper) so it can do static renaming. It won't emulate the MMIX (64, or 256 registers, I forget which) very effecently that way. Nor the SPARC (~32 visable registers, but easy access to many more, plus modern implmentations do renaming with many more then 40 registers internally), nor the Alpha (32 int registers, plus 32 FP, and via renaming way more then 40).
The Crousoe does the Intel style psudo-IEEE (which Intel chose because (I think) the IEEE spec was incomplete), MMIX (I think) uses real IEEE, and SPARC and Alpha definitly both do.
The Crosue's MMU page table is exactly like the x86 page table (I don't know if MMIX actually has one, but the Alpha, and SPARC both do)
The "intresting" MMIX instructions that treat registers as a vector of 64 bit values and do linear algrbra style dot and cross product type things won't have an underliening implmentation, so they will need to be emulates the S-L-O-W way.
That said the Crouse could probbably emulate the MMIX better then most other 32bit CPUs, but an Alpha, or V9 SPARC would do better. Maybe even the IA64.
the Lisa (aren't there thousands of these buried in a landfill somewhere?)
As far as I know most of the Lisa systems were later turned into the "Mac XL". It was out before the MacII, and was the first Mac that came with a hard drive (~10M). It had a somewhat bigger screen then the normal Mac, and amazingly every Mac program I tryed ran on it without problem. Of corse the finder took forever to do stuff after you had tons of docs all over the drive -- the Mac filesystem didn't support folders at that time, it was done in the Finder, but that ment it had to read directory entries for thousands and thousands of files and sort them into in-memory folders using inefficent algorithms tuned for what you would expect on a 400K floppy (i.e. maybe 100 files tops).
Most of the Lisa functionality was lost, but for a while it was the studliest Mac available.
I do expect they are mostly in landfills now. The harddrive on that one gave out not long after the MacII came to market. I would guess most of the others have stopped working as well.
P.S. I think the 68000 port of DR-DOS which became GEMDOS/TOS in the Atari ST was done on the Lisa first.
I get pretty tired of the tripe which is spoken about computer hardware on this site. The PCI bus does NOT max out at 133 MB/s. The current fastest PCI implementation is 533 MB/s with 64-bit/66-MHz PCI, which is not all that exotic.
It is true that the 33Mhz 32bit PCI bus maxes out at ~132Mbytes/sec (33 mil 4 byte transfers per second, or 132 mil bytes transfered per second). It is also true that many devices don't handle one transfer per cycle, esp at the begining of a burst. It is also true that burst sizes are quite limited. Lastly it is also true that almost all PC machines with PCI buses have the 33Mhz 32bit PCI busses (plus the AGP "bus" which is pretty similar to the PCI bus).
There are 64bit PCI buses. Lots of current generation SPARCs have them. Some of the older Alphas (and the newr ones) have them. There is a 66Mhz PCI bus. In fact most PCI buses that arn't 33Mhz 32bit PCI busses are both 66Mhz and 64bits wide. It's not hard to buy them. I think some of the high-end very expensave "server class" PC machines even have them. But it ain't common. (and yes a 66Mhz 64bit PCI bus should move something like 533Mbytes/sec66 times eight is 528 after all).
Still if you pick a PCI bus at random from the world odds are better then 1000 to one that it is a 33Mhz 32bit PCI bus.
It is a bit like saying SCSI maxes out at 10 MB/s. It is not generally true.
Indeed it is. But it is also unlike it. A LVD-SCSI disk seems to cost pretty much the same as a non-LVD SCSI disk. A LVD-SCSI controler (~40Mbytes/sec...or is it 80? I think 40 "narrow", and 80 "wide") costs maybe four times as much as a plain old "Fast SCSI" controler (~10Mbytes/sec). A "plain old" PCI motherboard costs almost nothing. Under $100 easy. I doubt you could find a motherboard that does 64bit 66Mhz PCI for $400, or even $1000.
In short I agree that there is a faster PCI. I agree that that makes it clear what the migration path is. I disagree that it is very relivant in a discussion about a $90 consumer PCI card, at least not this year.
For example: Under tradiational X-Windows you have a shared server - so while applications can get guarentees, the moment they start using the X-Server you lose all your benefits - your subject to a shared resource. Nemesis, on the other hand, is vertically structured so that almost all work it done in the client's process. Thus your use of the X-Server is subject to your scheduling parameters - thus no one can steal your time!.
How do they prevent priority inversion? For example a process I have granted unlimited (or very large) amounts of service too, and a process I have granted only tiny bits of service too, and another in between. The "unlimited" one waits for a disk I/O to complete. The "tiny" one starts an extreamly slow X operation (like fetching the glyphs for a all 64K chars in a 16bit true type font at some huge scale...or a mouse grab...or a PEX operation). The disk I/O completes, and the large one wants to display something, but it can't as the tiny one is doing something. The "in between" process wakes now, and starts doing a non-X thing (say five hours of ray tracing). It has more resources allocated to it then the "tiny" process so I assume it gets to suck them up, but less then the "large" one, which won't matter until the "tiny" one gets enough slop from the middle one to continue.
Is this handled somehow or can mid-pri processes starve out high-pri ones in the presense of low-pri ones?
however, it seems to me that generally you want to provide the best QOS you can.
Well since that is the default, everyone gets as much disk bandwidth as they ask for (until it runs out), ditto for net bandwidth, ditto for CPU (but with a fair share scheduler with weak volentary QOS -- the nice value)... well there wouldn't be much to release for that would there be?
It looks like this QOS allows hieractical queueing, so you can set up a policy like "everyone gets as much disk bandwidth as they want, unless we run out, in which cases SETTI at Home gets screwed, and everyone else gets what they want". In other words you can choose to control only what happens if you have run out of disk/network/CPU.
I know this reply is too late to catch the moderators eye, but I hope Mr. Hard_Code at least notices it.
I mean, most commodity chips heretofore are locked down to one clock. That means the tiniest circuit still has to wait for clock to compute another value.
Most commodity CPUs (and many other chips) are actually pipelined. They do some amount of work on the first clock tick, and send the results to another part of the chip, next tick they do the same amount of work on the new data, and another part of the chip works on the results of the the last cycle. A "modern" x86 CPU does that 8 to 18 times to handle each instruction. There are other wrinkles to it too.
When you design a CPU (in my case a "play" CPU much like the really old PDP-8) you use software that does a layout and tells you the critical path (most any VHDL synt tool will do). That's the slowest part which forces the rest of the circut to be clocked slower. When you find it there are three choices:
The clock met your target speed, and you are tired of working on the project. Your done.
Clock too slow. Find a faster circuit (replace a ripple carry adder with something that propigates the cary bits faster), these normally need more transistors, or wires, or something that is in short supply, like brain sweat.
Clock too slow. Split the job into two parts and pipeline it (or lengthen the pipeline). This will help throughput, but not latency. It will also make anything that needs to flush the pipeline cost more.
I don't know if the 68000 was pipelined. The 68010 was, I think it had three pipe stages (and no cache, although the loop-mode was a lot like a 3 instruction I-cache). Some RISC CPUs have pretty long pipelines, but the moderen Intels tend to be longer, in part because decode takes as many as three pipe stages (it does on the K7, not sure if the PII/PIII does it in two or three). A RISC decode is only one pipe-stage, and frequently other crap is thrown in too (like branch prediciton forwarding logic). By way of contrast the IBM PowerAS (a PowerPC like CPU) has a very short pipeline, I think about 6 stages (and thanks to the branch forwarding logic, branch mis-predict penalitys are something like only 2 to 4 cycles).
P.S. I'm not a hardware guy. I'm a software guy, and a harware wannabe.
I do know that there's a pretty fierce tradeoff between complexity and speed, though, and sometimes you get more milage out of keeping it simple but screaming fast.
That was HP's feelings through most of the '90s. They used only a L1 cache, and it was off-chip. It was huge for the time, and very fast for an off-chip cache. I think the last design they did that way had 2ns SRAM (500Mhz if you ignore overhead). In the last year and a half they have moved to an on-chip cache, sometimes with an off chip L2 cache. They have fought the good fight against the Alpha for the number one SPECfloat spot for years, sometimes winning, sometimes coming in second.
On the other hand the Alpha has almost allways had a small on-chip cache and a larger off chip one. Recent designs (21266) include a tiny "L0" cache (8K or 4K I think) and a larger L1 cache both on chip with a larger L2 off-chip cache. I expect your stament about having little predicability left by the time you get to a L3 cache really has less to do with the number of levels, but the size of each.
I expect these tradeoffs change as the cost of on-die transistors changes, and even the speed of them. Back when 100Mhz (10ns cycle time) was fast, taking a 1ns trip across wires off the die was cheap. Now it is still the same cost to go off the die (say 1ns), but we want to run at 500Mhz or 1000Mhz (2ns to 1ns cycle times!), so that off the chip cost is now huge compaired to doing it on-chip.
See, it's a bit more than that. This is, like, running the ALU at a different clock rate from the instruction decode unit and dispatch unit and the like, and having the register-rename circuitry at yet another speed, and so forth. In most modern CPU architectures, most everything is running much faster than it needs to be, or much slower than it can be.
It's got to be more then that. The TI SuperSPARC did that in '95 or so. Most of the CPU ran at (I think) 50Mhz, but the register file at 100Mhz. In that case (and all similar cases I know of) all the clocks are multiples of each other (no relitavly prime clock rates).
More over if the decode unit runs faster then the dispatch unit there is no useful gain. The dispatch unit has to be fed decoded instructions. The same is true for many (but not all) other parts of the CPU.
I think (with no proof, and no help from that watered-down article) that most of the parts in this chip run at the same speed (say 1Ghz). They each have their own 1Ghz clock distribution net, and they are not sync'ed with each other (so the ALU could see start of clock while the decoder is half way through a clock, and the renamer has just seen the end of a clock pulse). The boundry between each clocked unit must have a small async buffer.
That would trade the pain of clock distribution for the pain of having a bunch of async buffering all over the place adding to latency. Given how painful clock distrubution is in really big chips this is probbably a positave tradeoff. At least for latency intolerent workloads.
The AMD-750 chipset doesn't do SMP, and neither does Via's new KX133 chipset -- the chip itself is ready for multiprocessor configurations, but nobody's made it feasible yet, and don't expect it for a while.
I think it will be this year.
Neither AMD nor VIA have announced a SMP chipset (AMD has stated the 750 is the only one they intend to do, they want other compines to to the "real" chipsets). I'm supprised VIA hasn't announced since they have done SMP PPro and other chipsets in the past.
That doesn't mean nobody is making them. Both Hotrail, and API (URL unknown) have announced SMP chipsets. They have given no firm dates that I know of. Hotrail initally said "in 2000", now they are saying in the second half, I think. They havn't blown a promised date yet, but they havn't made any strong promises.
Again I know nothing about API, but Hotrail has made noide about 2-way, 4-way, 8-way, and "more". Also there is the dark horse of Compaq, after all they have SMP (and much bigger then 8-way!) systems using the same bus, but with a diffrent form factor, and possably diffrent speed and voltage.
I don't know if it was a mistake for AMD not to do a sample multi-CPU chipset. Having a SMP chipset would let them sell more CPUs, and high-margin ones if they convince motherboard makers that it is too much trubble to get the non-Ultra Athalons to run more then two-way (they are claiming it is possable, but eletrical tolerences will be very tight, and for some reason it is easier with the Ultras).
Actaully, the presence of additional C compilers on Linux and the other Freenixes might force the GCC people to start actually following standards, rather than engaging in their embrace-and-extend adventures.
Actually as far as C goes GCC is really quite standards conforming. It supports tri-graphs, and lots of icky things that not all C compilers do. It has a lot of extensions, but all of them can be disabled by passing "-ansi -pendantic".
Of corse some of those disbleable extensions are now part of the recently-approved C99 standard, but GCC has more work to go on that front.
If you want to talk about C++ then that's another matter. A pretty mixed bag in fact. For example it was the first known C++ compiler to have exception support. It was also almost the last to enable that support by default (only turning it on within the last year!!).
Again it has a pile of extensions, again you can disable them all with the flick of a switch or two.
I don't see that adding more compilers to the mix will make GCC ditch any extensions, in fact I expect it will grab a few from the other compilers (some mix of the "best", most useful, most popular, and easyest to re-implment). It can't halp the "standardness" of the C implmentation, but it might give the C++ front-end a boost.
P.S. alot of the C++ extensions were added after much discussion in comp.lang.c++ about new pontental features. Some became standard, others, like typeof() should have, yet others have languished as they deserve.
They don't come right out and say it, but no it doesn't. It integrates the RAM and (3.3V) PCI controlers onto the CPU, which makes multiprocessor support basically impossable. (in thery each CPU could cntrol it's own PCI bus, but with DRAM controlers rateher then an SMP-orianted cache snooping bus, you are SOL)
The closest the existing Transmeta chips are gonna get to a MP system, is a cluster in a box (beowolf), which they would be decently suited to given their low power draw and low tempatures.
This is not to say that Transmeta doesn't have a MP chip ready for their next product line, but they would have to target a market segment other then moble computing. Which is possable if you read their white papers they hint that they have some non-low-performance/low-temp ideas...
I find it really irritating when a UI element does some kind of fancy cakewalk to try to grab my attention for 400-500 msecs, especially when I have a long sequence of operations to perform. Too much of this kind of thing and a user interface feel slow and clunky.
On the other hand a "zoom" from iconifyed to full window helps remind a user what they did, and where the icon they just clicked has gone. Same for mimimising it. Lots of novice users "lose" tiehr windows. This sort of visual cue gives them hints as to what happened.
I'm pretty much with you on the menus, it is obvois where they came form when you pop them open. I think most users know when they have picked something form the menu. then again i havn't done any usablility tests in this area.
It is, I believe, the one algorithm proven mathematically to be perfect -- you *cannot* find the data without the key. (Of course, it has other problems -- you need a secure place to store the key, and if you have that, why don't you just store the data there?)
FYI there is another algo Applyed Crypto. (Schnier) claims is proveably secure. It's drawback is it takes forever to transmit messages (like thousands of years).
One-time pads have some other nasty side effects. Like if you forget which one-time-pad you have allready used and re-use one it is trivial child's play to retreve the key and both messages (XOR the two encrypted messages, you'll get the key back). You also have to have a really random keystream. "Mostly random" won't do (actually "really really close to random, as close as we can get" is how stream cypehrs like RC4 and RC6 work...)
One-time pads are terrable for storing data (like you said the key is as large as the data), but it is not bad for transmiting data.
I don't, but if I could pay $10/month and only get Fox (for The Simpsons and Futurama), Discovery, History, Bravo, AMC, Comedy and the Learning Channel, I'd be a happy bastard.
A bit off-topic. But I couldn't find an email address for you. Dish Networks sells their non-premimum stations unbundled for $1.50 each, minimum order of 10 unless you allready buy some other package. So for $15 a month you can have what you wanted for $10 plus 2 or so extras. I suggest A and E (for the Biography show).
Back on-topic, I want the same thing. Why should I have a whole wall of ER tapes when I could pay roughtly the same to get random access to any past show? That would kick.
But I'm not sure i would be as intrested if I couldn't FF over the comercials, nor would NBC be as happy cutting the deal if they figure 80% of hte comercials will be FFed over. Plus this is a lot of bandwidth to carry. Not just over the last mile, but from whatever regonal server. Far worse then 100 cable channels. And if the movies live on a disk we are screwed, the bandwidth may be tere to feed 100 diffrent video streams off of one RAID, but the seaks will kill it. And you don't need 100s, but 100,000s or more.
I don't think the problem is just political. The technology isn't there yet. and may not be for a decade or more.
What the Phoenix BIOS developers had to do was work from an external specification to reimplement the BIOS for 'clone' hardware. This is different from the agressive walking through the code that most people think of when they hear about "reverse engineering."
No, Phoenix had one set of developers read the BIOS listings and existing external specifications and make a comprehensave set of specifications descibing what the IBM BIOS actually did, including important corner cases. This included dissasembly of hte BIOS as shipped to inspect for diffrences between it and the listing IBM provided. This activity is more or less known as reverse engenering -- creating specs from an existing product (sometimes with the aid of existing incomplete specs).
Then Phenox had a second set of devlopers who hadn't seen the IBM BIOS code read the specs from the first set (they may not have been allowed to communicate directly even), and write code to implment the spec. This would be commonaly known as "clean room" code. The whole process is sometimes refered to as a chineese wall.
This DVD cracking activity** is completely different from what was done to produce the Phoenix BIOS.
It definitly doesn't have the clean room part. Only a description and sample code (possably tainted). However this is all that has been needed for other projects, like Mattels "System Charger" which was composed of all the parts the Atari 2600 had, connected the same way. They did no clean room as far as I know. I don't think that kind of hardware really can have any (the spec is "connect pin X of standard part Y to pin Z os standard part A...").
I don't know if DeCSS is legal the same way Phenox BIOS is. However I do know Phenox took extream precautions because they knew they would be sued by IBMs entire legal army. Much like you might drive 35MPH in a 45MPH zone if you know a cop is there. DeCSS may have cut corners, but I don't know if that ammounted to 45MPH in a 45 zone, or 30MPH, or 47MPH, or 55MPH, or 103MPH. Nor do you.
More over the reverse engering process is legal in most places. There may be restrictins on what can be done with the result, but frenquently there arn't.
I beleve the LGPL (or maybe even stright GPL) works, as long as you don't mind shipping source to all your "binary customers" (or shipping it on request). Of corse it won't prevent other people from doing the same thing, but Red Hat seems to be making enough money even with SuSE, Caldera, Slackware, et. al. in the ring.
However I think you may want to look at the MPL (Mozilla Public Licence) as well. It has a few advantages to people who want a shrinkwrap and free reslease:
If someone modifys your MPLed source to use a Patented algo, they also assign the rights to use the patent (for at least the MPLed program) to anyone else who has the MPLed program. I assume this only works if they have the right to assign rights (i.e. if Lucent added an XOR cursor to Mozilla the right would assign, but if I did it, it wouldn't assign because I don't hold a patent on XOR cursors, Lucent does). This is applicable even to software where you are not intrested in doing a shrinkwrap release. It is a large part of why I picked it for w3juke.
You (the original author) are granted the special right to make your own modifications to the code without releasing them. In the long run it will be simpler to release them and get the benifit of more coders debugging, but it might be helpful to add a few features to a shrinkwrap version and fold them into the real release later (something like what Aladin does with Ghostscript).
It is far better to use a licence people accept as Open Source allready (after all people accept Mozilla as OSS, even if there is debate on how successful it has been). If you end up with the LGPL or BSDL and need to add/change it a little then you could be in for a bumpy ride, both in getting it accepted, and later in finding out if it does what you want if it gets chalanged.
Lastly I think you might want to look at Setting Up Shop: The Business of Open-Source Software which has a discussion of some of hte licences, and some bisness models to make money useing them (I havn't read this yet, just skimed it, so I appolgise if it isn't as good as I hope).
Slashdot Mirror
Don't forget, the S/390 runs at least three Unix like OSes -- AIX, UTS, and Linux (and I expect there is an AOS for it as well).
Plus the S/390 can run more then one OS at once (one of the more popular OSes for it is/was the single user CMS, just run one per user). That is because the S/390 runs a very low level OS (VM/SP) which offers virtual disk controlers and virtual timers, and the like (including a virtual MMU) to the host OS.
As for reliable, sure. There were S/370s with multi-year uptimes. I would expect the same from the S/390.
Sure most people don't know what to do with source code, but that doesn't mean having it isn't good for them.
Let's say you contract to have me build you a spiffy program that, um, helps draw stuff. Later you realise you forgot to ask me for a spraypaint widget. by that time I'm off doing some other project and my free time has became rare, and I don't really feel like doing a spray paint widget, so I name a really high price. If you don't have the source code you are now out of luck, you either pay me big money for the spray paint widget, or do without one. If you do have the source code you can get another person to add the spray paint widget for you.
Another example. You buy an OS off the shelf. It comes with a free 90-day support contract. You do the install, you need a little help, the help line is slow, or not so helpful, or something. 92 days later you need some more help. If your product was closed source (say MS-Windows, or Solaris) you have to go to the people who made it for support. After all if there is a bug that needs fixing only they can fix it. If your product was open source (say Red Hat Linux) then you can choose to go to Red Hat, or you can go to LinuxCare, or other places. After all any of them could fix the bug.
I can come up with other examples as well.
Aranging to have a licence broken, and then having the violator's lawyers put on a less then steller defence isn't trial tampering if it is your friend the violator that is having his lawyers put on the less then steller defense. If you do it, it may be trial tampering, and it is a definate no-no for the lawyers who will be disbared if discovered.
That is not to say a staged trial (where plantif and defendent are relly on the same side) is legal. It might be an abuse of process or something. I expect it carries a smaller fine, and shorter jail time then trial tampering. But I don't really know. After all I'm not a lawyer.
P.S. anyone who trusts legal advice from slashdot is pretty dim -- that's my disclaimer and I'm sticking too it.
What happened to http://slashdot.org /article.pl?sid=00/02/21/1125208&mode=thread?
It looks like it has been moved to the 23rd. Maybe Rob doesn't want him publishing in slashdot too offen (or maybe Katz doens't want to publish here too offen -- lord knows he must get a ton of mail each time).
I would guess he decided he wants this one published in a more timely manner, and the other will wait until Wensday.
Wrong.
And right. A scientest doens't find the truth. A study doesn't find it either. They mearly say "when I did this, that happened, so this other thing may be true". The scientific community is fairly untrusting (for good reasons), so before they start beleving it, they read the paper very carefully, and "do this" to find out if "that happens". Then they will try "almost this" and see if "almost that happens". They will think of other reasons why X may cause Y. Eventually they might start beleving that X really does cause Y. Then again they might not.
A single study is the begining of a process. It is almost the same as "Some guy named Bob thinks The Internet sucks", it's almost worthless in and of itself. Only after other people have repeated the study and verifyed the results can it even start being useful. They also have to see if there are other explnations.
For this study, I expect the results will be repatable, but the "only 24 hours in a day" thery might win out over "people that use the Internet are mean" thery.
No, that isn't guaranteed. On the other hand, I can't see how to implment it with the time-complexity requiremnts demanded without it being an array (plus a little bookkeeping). I definitly havn't seen it done any other way.
If it is something you need (and I can definitly see the need), why don't you take the SGI STL vector class, rename it, and use it.
For the first five years I used C++ I allways thought of it as C with a little bit of OO stuff slapped on it. After I started using the STL C++ started feeling like a very diffrent (and more usable) language then C.
Is the STL really that much diffrent from other parts of C++? Or is it just me?
Print ads tend to have diffrent 800 numbers for diffrent versions of the ads, or in diffrent placments of the ads when the marketing department is trying to mesure their success. Sometimes they will tack an advert code onto the end of URLs too (I expect not so many people type those in).
When people fill out product reg cards one of the items is almost allways "how did you find out about us".
Sometimes a fraction of the buyers are randomly polled.
When you spend millions on an ad, you will spend a few thousands finding out how well it worked. When you spend thousands on the ad, you may spend almost as much finding out how to mkae the next one better.
Granted, this kind of thing is far easyer with web ads. One of hte tings I remember marketing folks saying they really liked is they could get response data on a change in hours rather then months.
Yes, as far as I recall the Crousoe is a VLIW, with 128bit "instructions" (I think Transmeta calls them "molicules", but almost every other VLIW calls them instructions -- the IA64/Merceed/Itanum calls them "bundles", sort of -- it isn't really a VLIW)
No. It doesn't say anything about the register width at all. Nor do the Crousoe whitepapers. I expect that the integer registers are 32 bits, because they have to be to effecently emulate a 32bit x86 CPU. I don't expect they are any bigger because that would consume more power, and more transistors that could better be doing something else if your goal is to emulate a x86. I expect the FP registers to be 80 bits, but they could be a somewhat diffrent size.
There are many diffrent bit widths in most CPUs, make sure you know which one is being talked about. For example, The PPro has a 128bit interface from the L1 cache to the L2 cache, but only has 32bit GP registers. The IA64 has 128bit wide "instruction bundles", but only 64 bit wide GP registers.
Pretty close. A traditonal VLIW (like, say, the MultiFlow) has several "functional units", and each "instruction" tells every functional unit what to do. Sometimes you have to tell some of them to do nothing (nop - no-operation).
For example, imagine a VLIW that has one load/store unit, two math units, and a branch unit... If you want it to do a load, an add, a multiply, and a branch you stick that all in one VLIW instruction. If you want to do two loads, a store, an add and a multiply you need three VLIW instructions, the load/nop/nop/nop, the store/add/multiply/nop, store/nop/nop/nop (you don't get to stick it in two just because you have nops -- you are out of the right flavor of instruction slots).
I think the Crosue is one branch unit, and either two ALUs and one LOAD/STORE or two LOAD/STORE and one ALU. I forget exactly which.
Many x86 instructions can be made into one or two slots of a VLIW instruction. Some others will take more then one VLIW instruction, but leave some slots open for parts of other instructions. For example the x86 'ADD m32,imm32' instruction (add 32bit constant to a location in memory) will take a LOAD slot (to get the memory value), then in another bundle (so the LOAD has time to complete) the ALU slot (to do the add), and then in another bundle the STORE slot (to write the results back) -- leaving 3 open branch slots, some open LOAD/STORE slots, and a few ALU slots as well. The code morpher may be able to fill the other slots. It may not be able to fill them all. Some x86 instructions may take multiple full VLIW instructions to carry out (like FSINCOS).
The transmeta white papers have some really good examples of what their code morpher can do. But remember it isn't magic. The PPro, P-II, and P-III, K6, and K7 can all execute two x86 instructions per cycle. The K7 can execute three. Actually in rare cases many of them can execute more then two, but other then the K7 they can only decode two per cycle, so only the K7 has a hope of keeping it going. The Crosoe can't get ahead of the "normal" x86 CPUs just by doing two instructions per cycle sometimes, or three, or even rarely four, if it spends too much time doing one or less. Or even if it spends lots of time doing two on code that the P-II could also do two!
VLIW isn't magic. There is a reason every single VLIW to date has been a comercial failure. Transmeta may have hit on a way to make it not flop. This definatly addresses several shortcomings VLIW has had in the past.
I'm sure he said the Crosue was a 128bit VLIW. I can't beleve the Crosue has 128 bit GP registers though. Sorry. Remember there are lots of diffrent bit widths in CPUs. Size of the integer/address registers is only one of them.
My info comes from Transmeta's white papers (on theur web site). Hennesey and Patterson's Computer Archicture textbook (I got mine form the University bookstore in '92, there are probbably better books to read about VLIW from, but i don't know any). And last, but not least common sense.
I can't imaging that the current Transmeta chips would be good at it. While they are not x86's they are designed to be good at emulating x86 code, not MMIX code. The underling needs are pretty diffrent. Even though the Transmeta chips are designed to be fairly efficent emulators of x86 code, and I doubt they have been designed to be poor emulators of other things, they will have a hard time emulating things sufficently diffrent from the x86. For example:
That said the Crouse could probbably emulate the MMIX better then most other 32bit CPUs, but an Alpha, or V9 SPARC would do better. Maybe even the IA64.
As far as I know most of the Lisa systems were later turned into the "Mac XL". It was out before the MacII, and was the first Mac that came with a hard drive (~10M). It had a somewhat bigger screen then the normal Mac, and amazingly every Mac program I tryed ran on it without problem. Of corse the finder took forever to do stuff after you had tons of docs all over the drive -- the Mac filesystem didn't support folders at that time, it was done in the Finder, but that ment it had to read directory entries for thousands and thousands of files and sort them into in-memory folders using inefficent algorithms tuned for what you would expect on a 400K floppy (i.e. maybe 100 files tops).
Most of the Lisa functionality was lost, but for a while it was the studliest Mac available.
I do expect they are mostly in landfills now. The harddrive on that one gave out not long after the MacII came to market. I would guess most of the others have stopped working as well.
P.S. I think the 68000 port of DR-DOS which became GEMDOS/TOS in the Atari ST was done on the Lisa first.
It is true that the 33Mhz 32bit PCI bus maxes out at ~132Mbytes/sec (33 mil 4 byte transfers per second, or 132 mil bytes transfered per second). It is also true that many devices don't handle one transfer per cycle, esp at the begining of a burst. It is also true that burst sizes are quite limited. Lastly it is also true that almost all PC machines with PCI buses have the 33Mhz 32bit PCI busses (plus the AGP "bus" which is pretty similar to the PCI bus).
There are 64bit PCI buses. Lots of current generation SPARCs have them. Some of the older Alphas (and the newr ones) have them. There is a 66Mhz PCI bus. In fact most PCI buses that arn't 33Mhz 32bit PCI busses are both 66Mhz and 64bits wide. It's not hard to buy them. I think some of the high-end very expensave "server class" PC machines even have them. But it ain't common. (and yes a 66Mhz 64bit PCI bus should move something like 533Mbytes/sec66 times eight is 528 after all).
Still if you pick a PCI bus at random from the world odds are better then 1000 to one that it is a 33Mhz 32bit PCI bus.
Indeed it is. But it is also unlike it. A LVD-SCSI disk seems to cost pretty much the same as a non-LVD SCSI disk. A LVD-SCSI controler (~40Mbytes/sec...or is it 80? I think 40 "narrow", and 80 "wide") costs maybe four times as much as a plain old "Fast SCSI" controler (~10Mbytes/sec). A "plain old" PCI motherboard costs almost nothing. Under $100 easy. I doubt you could find a motherboard that does 64bit 66Mhz PCI for $400, or even $1000.
In short I agree that there is a faster PCI. I agree that that makes it clear what the migration path is. I disagree that it is very relivant in a discussion about a $90 consumer PCI card, at least not this year.
How do they prevent priority inversion? For example a process I have granted unlimited (or very large) amounts of service too, and a process I have granted only tiny bits of service too, and another in between. The "unlimited" one waits for a disk I/O to complete. The "tiny" one starts an extreamly slow X operation (like fetching the glyphs for a all 64K chars in a 16bit true type font at some huge scale...or a mouse grab...or a PEX operation). The disk I/O completes, and the large one wants to display something, but it can't as the tiny one is doing something. The "in between" process wakes now, and starts doing a non-X thing (say five hours of ray tracing). It has more resources allocated to it then the "tiny" process so I assume it gets to suck them up, but less then the "large" one, which won't matter until the "tiny" one gets enough slop from the middle one to continue.
Is this handled somehow or can mid-pri processes starve out high-pri ones in the presense of low-pri ones?
Well since that is the default, everyone gets as much disk bandwidth as they ask for (until it runs out), ditto for net bandwidth, ditto for CPU (but with a fair share scheduler with weak volentary QOS -- the nice value)... well there wouldn't be much to release for that would there be?
It looks like this QOS allows hieractical queueing, so you can set up a policy like "everyone gets as much disk bandwidth as they want, unless we run out, in which cases SETTI at Home gets screwed, and everyone else gets what they want". In other words you can choose to control only what happens if you have run out of disk/network/CPU.
I know this reply is too late to catch the moderators eye, but I hope Mr. Hard_Code at least notices it.
Most commodity CPUs (and many other chips) are actually pipelined. They do some amount of work on the first clock tick, and send the results to another part of the chip, next tick they do the same amount of work on the new data, and another part of the chip works on the results of the the last cycle. A "modern" x86 CPU does that 8 to 18 times to handle each instruction. There are other wrinkles to it too.
When you design a CPU (in my case a "play" CPU much like the really old PDP-8) you use software that does a layout and tells you the critical path (most any VHDL synt tool will do). That's the slowest part which forces the rest of the circut to be clocked slower. When you find it there are three choices:
I don't know if the 68000 was pipelined. The 68010 was, I think it had three pipe stages (and no cache, although the loop-mode was a lot like a 3 instruction I-cache). Some RISC CPUs have pretty long pipelines, but the moderen Intels tend to be longer, in part because decode takes as many as three pipe stages (it does on the K7, not sure if the PII/PIII does it in two or three). A RISC decode is only one pipe-stage, and frequently other crap is thrown in too (like branch prediciton forwarding logic). By way of contrast the IBM PowerAS (a PowerPC like CPU) has a very short pipeline, I think about 6 stages (and thanks to the branch forwarding logic, branch mis-predict penalitys are something like only 2 to 4 cycles).
P.S. I'm not a hardware guy. I'm a software guy, and a harware wannabe.
That was HP's feelings through most of the '90s. They used only a L1 cache, and it was off-chip. It was huge for the time, and very fast for an off-chip cache. I think the last design they did that way had 2ns SRAM (500Mhz if you ignore overhead). In the last year and a half they have moved to an on-chip cache, sometimes with an off chip L2 cache. They have fought the good fight against the Alpha for the number one SPECfloat spot for years, sometimes winning, sometimes coming in second.
On the other hand the Alpha has almost allways had a small on-chip cache and a larger off chip one. Recent designs (21266) include a tiny "L0" cache (8K or 4K I think) and a larger L1 cache both on chip with a larger L2 off-chip cache. I expect your stament about having little predicability left by the time you get to a L3 cache really has less to do with the number of levels, but the size of each.
I expect these tradeoffs change as the cost of on-die transistors changes, and even the speed of them. Back when 100Mhz (10ns cycle time) was fast, taking a 1ns trip across wires off the die was cheap. Now it is still the same cost to go off the die (say 1ns), but we want to run at 500Mhz or 1000Mhz (2ns to 1ns cycle times!), so that off the chip cost is now huge compaired to doing it on-chip.
It's got to be more then that. The TI SuperSPARC did that in '95 or so. Most of the CPU ran at (I think) 50Mhz, but the register file at 100Mhz. In that case (and all similar cases I know of) all the clocks are multiples of each other (no relitavly prime clock rates).
More over if the decode unit runs faster then the dispatch unit there is no useful gain. The dispatch unit has to be fed decoded instructions. The same is true for many (but not all) other parts of the CPU.
I think (with no proof, and no help from that watered-down article) that most of the parts in this chip run at the same speed (say 1Ghz). They each have their own 1Ghz clock distribution net, and they are not sync'ed with each other (so the ALU could see start of clock while the decoder is half way through a clock, and the renamer has just seen the end of a clock pulse). The boundry between each clocked unit must have a small async buffer.
That would trade the pain of clock distribution for the pain of having a bunch of async buffering all over the place adding to latency. Given how painful clock distrubution is in really big chips this is probbably a positave tradeoff. At least for latency intolerent workloads.
I think it will be this year.
Neither AMD nor VIA have announced a SMP chipset (AMD has stated the 750 is the only one they intend to do, they want other compines to to the "real" chipsets). I'm supprised VIA hasn't announced since they have done SMP PPro and other chipsets in the past.
That doesn't mean nobody is making them. Both Hotrail, and API (URL unknown) have announced SMP chipsets. They have given no firm dates that I know of. Hotrail initally said "in 2000", now they are saying in the second half, I think. They havn't blown a promised date yet, but they havn't made any strong promises.
Again I know nothing about API, but Hotrail has made noide about 2-way, 4-way, 8-way, and "more". Also there is the dark horse of Compaq, after all they have SMP (and much bigger then 8-way!) systems using the same bus, but with a diffrent form factor, and possably diffrent speed and voltage.
I don't know if it was a mistake for AMD not to do a sample multi-CPU chipset. Having a SMP chipset would let them sell more CPUs, and high-margin ones if they convince motherboard makers that it is too much trubble to get the non-Ultra Athalons to run more then two-way (they are claiming it is possable, but eletrical tolerences will be very tight, and for some reason it is easier with the Ultras).
Actually as far as C goes GCC is really quite standards conforming. It supports tri-graphs, and lots of icky things that not all C compilers do. It has a lot of extensions, but all of them can be disabled by passing "-ansi -pendantic".
Of corse some of those disbleable extensions are now part of the recently-approved C99 standard, but GCC has more work to go on that front.
If you want to talk about C++ then that's another matter. A pretty mixed bag in fact. For example it was the first known C++ compiler to have exception support. It was also almost the last to enable that support by default (only turning it on within the last year!!).
Again it has a pile of extensions, again you can disable them all with the flick of a switch or two.
I don't see that adding more compilers to the mix will make GCC ditch any extensions, in fact I expect it will grab a few from the other compilers (some mix of the "best", most useful, most popular, and easyest to re-implment). It can't halp the "standardness" of the C implmentation, but it might give the C++ front-end a boost.
P.S. alot of the C++ extensions were added after much discussion in comp.lang.c++ about new pontental features. Some became standard, others, like typeof() should have, yet others have languished as they deserve.
They don't come right out and say it, but no it doesn't. It integrates the RAM and (3.3V) PCI controlers onto the CPU, which makes multiprocessor support basically impossable. (in thery each CPU could cntrol it's own PCI bus, but with DRAM controlers rateher then an SMP-orianted cache snooping bus, you are SOL)
The closest the existing Transmeta chips are gonna get to a MP system, is a cluster in a box (beowolf), which they would be decently suited to given their low power draw and low tempatures.
This is not to say that Transmeta doesn't have a MP chip ready for their next product line, but they would have to target a market segment other then moble computing. Which is possable if you read their white papers they hint that they have some non-low-performance/low-temp ideas...
On the other hand a "zoom" from iconifyed to full window helps remind a user what they did, and where the icon they just clicked has gone. Same for mimimising it. Lots of novice users "lose" tiehr windows. This sort of visual cue gives them hints as to what happened.
I'm pretty much with you on the menus, it is obvois where they came form when you pop them open. I think most users know when they have picked something form the menu. then again i havn't done any usablility tests in this area.
FYI there is another algo Applyed Crypto. (Schnier) claims is proveably secure. It's drawback is it takes forever to transmit messages (like thousands of years).
One-time pads have some other nasty side effects. Like if you forget which one-time-pad you have allready used and re-use one it is trivial child's play to retreve the key and both messages (XOR the two encrypted messages, you'll get the key back). You also have to have a really random keystream. "Mostly random" won't do (actually "really really close to random, as close as we can get" is how stream cypehrs like RC4 and RC6 work...)
One-time pads are terrable for storing data (like you said the key is as large as the data), but it is not bad for transmiting data.
A bit off-topic. But I couldn't find an email address for you. Dish Networks sells their non-premimum stations unbundled for $1.50 each, minimum order of 10 unless you allready buy some other package. So for $15 a month you can have what you wanted for $10 plus 2 or so extras. I suggest A and E (for the Biography show).
Back on-topic, I want the same thing. Why should I have a whole wall of ER tapes when I could pay roughtly the same to get random access to any past show? That would kick.
But I'm not sure i would be as intrested if I couldn't FF over the comercials, nor would NBC be as happy cutting the deal if they figure 80% of hte comercials will be FFed over. Plus this is a lot of bandwidth to carry. Not just over the last mile, but from whatever regonal server. Far worse then 100 cable channels. And if the movies live on a disk we are screwed, the bandwidth may be tere to feed 100 diffrent video streams off of one RAID, but the seaks will kill it. And you don't need 100s, but 100,000s or more.
I don't think the problem is just political. The technology isn't there yet. and may not be for a decade or more.
No, Phoenix had one set of developers read the BIOS listings and existing external specifications and make a comprehensave set of specifications descibing what the IBM BIOS actually did, including important corner cases. This included dissasembly of hte BIOS as shipped to inspect for diffrences between it and the listing IBM provided. This activity is more or less known as reverse engenering -- creating specs from an existing product (sometimes with the aid of existing incomplete specs).
Then Phenox had a second set of devlopers who hadn't seen the IBM BIOS code read the specs from the first set (they may not have been allowed to communicate directly even), and write code to implment the spec. This would be commonaly known as "clean room" code. The whole process is sometimes refered to as a chineese wall.
It definitly doesn't have the clean room part. Only a description and sample code (possably tainted). However this is all that has been needed for other projects, like Mattels "System Charger" which was composed of all the parts the Atari 2600 had, connected the same way. They did no clean room as far as I know. I don't think that kind of hardware really can have any (the spec is "connect pin X of standard part Y to pin Z os standard part A...").
I don't know if DeCSS is legal the same way Phenox BIOS is. However I do know Phenox took extream precautions because they knew they would be sued by IBMs entire legal army. Much like you might drive 35MPH in a 45MPH zone if you know a cop is there. DeCSS may have cut corners, but I don't know if that ammounted to 45MPH in a 45 zone, or 30MPH, or 47MPH, or 55MPH, or 103MPH. Nor do you.
More over the reverse engering process is legal in most places. There may be restrictins on what can be done with the result, but frenquently there arn't.
I beleve the LGPL (or maybe even stright GPL) works, as long as you don't mind shipping source to all your "binary customers" (or shipping it on request). Of corse it won't prevent other people from doing the same thing, but Red Hat seems to be making enough money even with SuSE, Caldera, Slackware, et. al. in the ring.
However I think you may want to look at the MPL (Mozilla Public Licence) as well. It has a few advantages to people who want a shrinkwrap and free reslease:
You might want to look at The Open Source website, expecally their short approved licences list.
Lastly I think you might want to look at Setting Up Shop: The Business of Open-Source Software which has a discussion of some of hte licences, and some bisness models to make money useing them (I havn't read this yet, just skimed it, so I appolgise if it isn't as good as I hope).