I do disagree about the platform, unless you mean it's not a successful platform unless it features more than one vendor. While the average geek would love to piece together their own boxen - and this is what the clones promised - it doesn't matter a bit for the average consumer, graphic artist, web designer, or educational institution. For Apple's core audience, the Mac is quite a viable platform.
That's a true statment on the face of it. If they won't assmble their own, they won't care that they can't assemble their own. But it shouldn't be true. If Macs were tinkertoy computers like the PC then the little mom and pop shop down the street could undercut existing prices. Then the big stores would have tolower prices at least a little to not look like they are totally gouging, or a lot to match prices. Venders would spring up that have a good idea on how to make part X cheaper even if they can't build part Y to save their lives. System cost falls again.
PCs arn't cheap just because they have cloners. Look at portables, the no-can-do-it-yourself PC. Pretty costly, and an area where Apple is cost compettave too...
Roughly the same argument goes with Open Source Software. Joe Accountant doesn't care that he can modify a program, but he should care that he can hire anyone to do it, not just the place he bought it from. In thery that drives prices down and quality up.
In other words, they don't wanna waste address space building infrastructure.
While that is a feature, there are some other nice advantages. If you want to have more then one type of service on a single circuit (say best-effor 100x over subscribed AOL account for one PC, and a mere 4x oversubscribed small-bisness account for another -- or even the same PC depending on what you are using it for) you can do it with PPPOE, while that is hard to impossable with DHCP.
You can do a lot more configuration at a higher level. Tracking an account number is much simpler then tracking a set of MAC addresses (which will change if the consumer gets a new computer, or ethernet card - and may move from point to point on your network anyway!). Tracking an account number tends to be somewhat simpler then tracking a (Router,Card,Curcit-ID) tuple, and it simplifyes moves as well.
It also disrupts a home network far less. You don't have to configure your network aware printer NOT to ask for a DHCP address (which would end up putting it on the global net, and possably using your only address!). If you have multiple computers allready on a network, and you want to put one on the Internet, this won't force you to get another card for it, or to sever it's connection with the existing network. This may be a rare case, but I assure you it was one the authors of the RFC did have in mind. Rember if your ISP does DHCP for you, it is a lot harder for you to also do DHCP for your local network!
If the ISP allready has a RADIUS infrastructure set up for a large dial network, this allows them to reuse it for DSL. This is a fairly big deal because beleve it or not it is a pain integrate yet another database (DHCP's configuration) with allready existing order, payment, accounting, and other random systems at the ISP. A PPPOE baised DSL set up will look a whole lot like the existing dial set up (presumably with a higher monthly fee).
You are right - something related to the traffic thing was on Slashdot earlier.
And if you search in it for "waves" about the forth one has a link to the same page the quickies article talks about. I knew I had seen it on slashdot before:-)
11 or 15. Six for decode (FETCH, SCAN, ALIGN1/MECTL, ALIGN2/MEROM, EDEC, IDEC/Rename), or maybe five depending on how you feel about IDEC/Rename. For integer instructions (at least direct path ones) you then have SCHED (which can take multiple cycles, depending on how long it takes for all inputs and an appropriate functional unit to become available), EXEC, ADDGEN, DC-ACC, RESP (DC-ACC and RESP are cache accesses, I'm not sure where the write back is -- they may have left the retirement out of the document I'm looking at). The FP pipeline (FP instructions, MMX and 3D Now! instructions as well) is longer, 15 stages (including the first 7 above), more for FMUL.
Intel P4 (aka Willamette) has 20 stage pipeline, and it remains to be seen whether the high clock rates this enables makes up for the hits it'll take due to latency and branch mispredict penalty.
I thought the Willamette's was more like 25 pipestages for the integer unit, and an undisclosed (I assume higher) number for FP operations. The PPro's is pretty long allready, like 18 or so (that may be for the FP). I assume about the same length in the P-II and P-III since they are the same microarcheture.
Try putting in 8 slots of fully interleaved RDRAM vs SDRAM and you will find that the RDRAM has one hell of a better bandwidth.
If you fully interleve the SDRAM it has pretty impressave bandwidth numbers too. Of corse that takes (about) four times as many pins. In fact 8-way interleved PC100 SDRAM excedes the bandwidth the Intel and AMD can get off their CPUs, so the only thing that will matter is latency, which'll make the SDRAM a better choice...
If you can come up with all those pins. If.
Low pin count is one of RDRAMs few remaining advantages (RDRAM systems with no CPU L2 cache run about as well as systems with small L2 cache and a normal memory system -- but that's not a good deal with L2 caches so large these days...I can list other obsolete advantages if you like). You can four way interleve RDRAM with (about) the same number of pins you need to interface to stright (not interleved) SDRAM. So if IBMs high density packaging catches on, RDRAM loses that (as more pins will be cheep). If DDR SDRAM really uses a 16 bit interface RDRAM loses it's advantage.
Of corse I don't see many chipsets using this advantage. Where are the motherbord chipsets with four RDRAM controlers?
That being said, I also think that RDRAM may not be dead. Look at the celeron. The first celerons were crap. Now it is just about the most common low end processor out there. There may be a little more lag time since RDRAM isn't being developed directly by Intel, but I think that Rambus will do whatever Intel tells it to. (At least they better!)
RAMBus is over eight years old. This is something like the fourth major revision (in '92 it was a 400Mhz 8bit interface). This is not a repeat of the Celeron story.
As long as you don't have to code in assembler for it--and few code in assembler these days, anyway--there's nothing wrong with x86 since modern x86 CPUs are really a RISC core with an x86 decoder tacked on, which according to Ars Technica only adds about 1% penalty to the processor's speed.
I don't see how they came up with the 1% number. Here are a few counter arguments...
The x86 has reached some pretty impressave speeds. 1Ghz is shockingly fast. Even 800Mhz is quite speedy. Intel has done this by using extreamly long pipelines. Some 15-22 pipestages depending on the operation. AMD has done the same. A longer pipeline increses the latency of many operations, and makes sequential dependencies in code cost more and more. And branch penailties, and load cache misses. IBM has the PowerAS running at 600Mhz with a 5 pipestage machine (that is fewer pipe stages then the AMD uses to decode instructions!). It smashes the PPro-P-III and AMD in anything that has lots of poorly predicted branches. Like DB code. It does better on code that does lots of pointer chasing (like linked list walks).
(the PowerAS has a zero to one cycle peanilty for "misprecidted" branches (it's prediction method is "allways taken", or "never taken" I forget which); the Intel has a penality of more like 11 to 20 cycles, with a maximum peanilty of 44 or so cycles of work discarded from the ROB, the Intel has a very good branch prediction scheme, for predictable branching patterns, when it gets to bad to predict code it sucks big time)
The P-III and AMD managed to decode 3 instructions per cycle, quite an acomplishment with an irregular sized instruction set. They have finally gotten to this point. The SuperSPARC in 1992 or 1993ish decoded four instructions per cycle. That means the best the x86 can do over the long term is to execute three instructions per cycle (because even if they have spare functional units, they will run out of instructions in the reorder buffer if they manage to execute >3 instructions per cycle for long). RISCs have grown a few more decoders in the intervening 8 years. Some of them at least.
If the x86 is only one percent slower then RISCs, why is the anchent (2 year old?) Alpha 21264 at a mere 667Mhz still turning in better SPEC2000 FP numbers then the "shipping only to select OEMs, and not many units either" 1Ghz Intel part?
Try to get a stream benchmark number in the same ballpark as a real Alpha (not one baised on the PC chipsets), with a Xeon. Intel hasn't made a memory system that can compete. And the memory system is half the price of the damm Alphas.
RISC may have lost the comercial war to CISC, but there is no need to stomp on it's acomplishments. There are really impressave RISC CPUs for a fraction of the research dollar Intel (and AMD!) spend.
So, I never said Intel was evil for pushing x86 for so long, I said that it's dumb for people to hate x86 but not fault Intel for creating a better ISA long ago.
Oh, but they have. The i960 is a diffrent ISA, I never used it, but I'm sure it is quite diffrent from the x86. The i860 was also very diffrent. It had a pretty nice ISA as long as you didn't put it into streaming mode. The VLIW mode was a bit odd to me, but it wasn't a huge deal.
Peopel even used them. Just apparently not enough people used the i860. I donno what the deal was with the i960. It was extreamly popular 5 years ago, but doesn't seem to be now.
Hmm. Coming from a real embedded systems design point of view.. Why to people insist on calling handhelds 'embedded'?
They have some of the qualities of embeded systems (price is a huge factor, and compatability with desktop software is pretty much a non-issue). Moreover the CPUs in succesful PDAs (the Palm line for example) are CPUs that were designed and marketed for the embeded market. They also fit some people's definiton of "embeded", but I admit that is a big strech of the traditonal deinition.
Linux on a chip? fantastic. I can think of a great many uses for it. 'Embedded systems' isn't one of them.
It (or NetBSD) would cut devlopment time for say a car MP3 player that needed to use 802.11 to fetch new songs while parked in the garage... but I wouldn't be very tempted to use it for an anti-lock break system.
If HP had used it for their printers I don't know if the print engine would be worse (I don't know how much RT it needs), but the TCP stack would be marketdly better, as the exiting one screws up if the least bit of stress is put on it (say more then one TCP connection at once is sometimes enough!)
There is a snandard for DVD. Just some cheap DVD players that came out around last Christmas didn't bother to support dual-layer DVD's.
Lots of DVDs are duel layer. I can tell because my player has a super breif, but supper irratating pause when refocusing. Movies I was buying last summer, and before were duel layer.
The Matrix has some other problem. Like use of alternate angle, or a diffrent path through the movie or something. I'm not quite sure, beause my player didn't have problems with it. I think it has problems with the "white rabbit tour" which is the normal movie, but some scenes show a white rabbit, and if you hit enter then you get a "making of" for that scene. I'm not quite sure what DVD features are used to do that.
Now all we need is the average street price of all DVD's to come down to compete with VHS movies. I've been supporting DVD since late 1998, and so far, only good things have happened. (Special editions of movies, lower prices, better quality, no more flipper movies, etc...)
I havn't bought VHS movies for a long time (well, ever, but my wife use to buy them a lot). I seem to remember them costing more then I pay for DVDs after a quick trip through a price search engine. Are video tapes really cheaper still?
Yeah, the Athlon is a pretty nice chip, but nobody's getting the motherboard design right (yet), so all the 'benchmark' tests that use Quake are totally bogus. AGP 4x w/ superduper fastness option vs. AGP 1x w/ inadequate power is what's really being tested.
As far as I know the Asus K7V, and other KX133 chipset baised motherboards have AGP 4x support. And pricewatch looks like you can buy them now.
By the end of the year this should even out as the Athlon cranks up to 200Mhz bus (really 400, counts on the upswing and downswing of each cycle) and motherboard manufacturers get it right.
Intresting roumor, where did you here it? It definitly won't be needed until we get faster memory technology, or support for multiple SDRAM (or RDRAM, which I think might saturate a 200Mhz 32bit bus).
What I'm waiting for are the multi-way chipsets (well, not really waiting, looking forward to seeing market reaction too). It'll be intresting to see AMD chalange Intel in the high end PC server market in addition to the high end a nd low end desktop range.
Again, while I support the right of prople to voice their opinions, I do not understand the desire to remove from others the ability to do things you disagree with (this is in reference to the part about "if they actually want to get rid of the hated thing").
If I beleve going to McD's is moraly wrong for some reason, that the mere existance of McD's damages society, or mankind as a whole, that it is an evil empire that needs to be demolished before man can achieve utopia, well, then merely not going myself won't be enough will it?
I would need to convince other people not to go. (this is hypothtical, I personally don't find McD's to be all that evil, they just serve bland food, with relitavly little enjoyment value for the immense fat content -- so I don't eat there, I feel no real need to prevent others from it)
If you want to prevent me from going to McD's, you've crossed the line.
No I havn't. My mere want for you not to go to McD's doesn't cross any leagal line that I am aware of (in the USA at least). Nor any moral line. Actions that I take might cross a line, but mere desire does not. In the USA at least it doesn't cross any legal line for me to tell you (or at least talk near you) about how much I think McD's sucks (as long as I don't lapse into untruth, and risk slander, or libel, depending on wether I am talking or writing). It wouldn't cross a line for me to hold up pictures of what I imagine McD's offenses to be. At least so long as they are things McD's actually does.
It would cross a line if I actually physically bared you from going (I expect it would legaly be assult, or some other relitavly serious crime), or if I rendered the McD's inoperable (say by calling a bonb thret, or maybe burning it to the ground when nobody is around), which again would be illegal.
But merely exorting you not to go, well that's not illegal. Just look at all the people advocating a boycot on Microsoft, Amazon, or Wal-Mart. None have been sue'ed or charged with any crime for that.
. If you want to peacefully discourage others from eating at McD's, fine. If you want to prevent me from going to McD's, you've crossed the line
We seem to be in agreement on this point, so why do you assert a mere desire to prevent you from going is crossing a line?
You know, the real way to protest McDonalds opening in your neighbourhood is - don't eat there.
Picketing isn't a bad idea either. Nor is publising (perhaps on a web page, and in the local newspaper) the reasons other might want to also not go to McDonalds (or buy a particular shoe, or brekfast cerial).
One person alone skipping a product they dislike is a start, but if they actually want to get rid of the hated thing they need to convice others to skip the product as well. Fortunitly in this country there are plenty of protected free speach rights they can use to do so (well to attempt to do so, they have no right to actually convice anyone of anything, just the right to try). I expect france isn't exactly lacking either.
(and no, I doubt vandlising a construction site is protected free speach, but not being up on French custom, I don't know for sure)
Capitalism is funny that way.
It is funny in a lot of deeper ways then that, but it does seem to work better then the other known systems.
It takes no wizard to see that they will find out they're paying the price for every freeloader that you have on your product.
What makes you think there is a price to pay for the "freeloaders"? The non-payers won't be using valuable support time. There might be staff time spent looking over the "unsupported users mailing list" for real bug reports and fixes, but if you get any reports or fixes then that has more then payed for itself (for a low volume, this is a single intern's job, almost free by corprate standards). If you don't seem to get any reports or fixes, you don't pay anyone to do that job.
The other "freeloaders" frequently would not pay for your product anyway, they are poor studants, super cash straped start-ups, and places where you product is super-over-kill. Those cost you nothing, you wouldn't have lost the sale, but by giving away the software you get free training, free bug reports/fixes, and free advertising if any of those studants should graduate and go somewhere that needs your software, or if the cash-strapped startup gets a big contract and suddonally needs your product to be gaurenteed to keep their cash flow!
There are a vanishingly small number of customers for a corprate product that would choose to have no support. They buy Red Hat at $60 a box, not the identical CD from cheep bytes for $1.99 with no support.
My guess is that this vanishing small number will be ofset by the extra sales your "marketing" move of giving away free copies with source will bring in. Plus bug reports/fixes (if any).
. Now, if the bugs in your product gets fixed, they will have no incentive to further support you. Especially when they got all the features they need. The companies will review their budgets and find what to cut down, and believe me, they'll cut whatever they can in bad financial times. Regardless if they "support" the Open Source movement or not.
Depends strongly on the product's market. Componies will pay for support on mature products that havn't been observed to break if their breakage will cause a large loss of money, or if the support contract is quite cheep. How many places that have never had a disk failure buy RAID arrays? Or support contracts on new hardware? Support contracts on the RAIDs even?
Think of it as the software equivolent of an extended warrienty. They may normally be crap, but most people buy them. Componies arn't any smarter then people. In fact they are a lot lot dumber sometimes.
So, all in all, there is money in this. You just can't expect to live on it forever. There's also less money than if you make it big proprietary. On the other hand, you may get support from freelance coders, and you will get good PR through the geek community.
I don't see where there is clearly less money involved for a bisness targeted product. You are right that you can't count on getting free bug reports and fixes just by open sourcing something. But you definitly increse the chances from 0% to something possable (for bug fixes/free new features).
It doesn't make sense for some products. I don't see any way a OSS family tree product could make signinfigant money. That would have to be done to "scratch an itch", or for the "glory". But that doesn't mean all OSS trades dollars for glory.
2) On what grounds is the AMD chip better than anything Intel has? Most of the benchmarks I've seen have the high-MHz P III's handily defeating the Athlon in just about everything, especially games like Q3A. How is the AMD good enough for an unqualified "superior" to anything Intel has?
Depends on what you are mesuring. A stright per Mhz comparisin isn't really any more useful then a per transistor rating. Granted they are done all the time, and people fixate on them.
More useful are the per dollar rating (and you probbably need to include the cost fo the support chips at the very least, whole system is better). After all most people don't go to the store to pick which 800Mhz system is faster (or which 190HP car is faster), but to pick which $700 PC (or $18,000 car) is faster. (assuming faster is what they are after, as opposed to quieter, safer, less poluting, or a nicer color -- for the car or the PC!)
Useful for another set of people is "screw the money, of the systems I can lay hands on, which is faster". Maybe an expensave quad XENON with RDRAM, maybe a single fast AMD K7 (for non-multithreaded FP bound apps). Of corse an Alpha (lower clock speed and all) toasts 'em both (at least for SPEC like apps), if you can recompile the app. Or with the car analogy again, maybe a Ferari, maybe the Lotus, or maybe even something that isn't streat legal at all.
Useful for a far smaller set of people is the "which is faster per Mhz", and those are mostly people trying to figure out why a system is fast. Not people intrested in buying it for that reason.
Other people are intrested in waste heat given off, and power sucked up (people buying portables).
On all of those, diffrent applications may be more important. Quake III to you, POVRay for me, Kernel compiles to Linus, how fast AOL loads for my mom.
Others might be intrested in the politics of the company (do they donate money to polititions I hate?). Or how much the enviroment is hurt per CPU made. Or how the workers are treated.
Oh, and lastly, there have been benchmarks the AMD womps the Intel at, even the slow slow extrnal cache 1Ghz models. The "NT 3D content creation" ones, which seem to have lots of FP, and are too big to fit whole in either cache for example. The newer Thunderbirds (less cache, but at full speed, even with a relitavly narrow bus) do quite well. They are per clock competitave with the Intel's on many benchmarks, beating them on quite a few (quite a few being more then half I think, competatave is normally with in a few percent). More importantly they are per dollar competitave, beating them on almost evey single benchmark I have seen.
Go look at the Thunderbird benchmarks again, or point me at URLs of the P-III soundly beating the Thunderbird. (it could be, I only looked at a few benchmark pages, I can only look at so many 15 page long half bar graph articles before I've had enough!)
I don't know if the per dollar thing is enough to claim AMD is (unqualifyed) superior. In my mind the max speed you can actually buy, plus the per dollar, in the vast majority of benchmarks would at the very least rate a qualifyed superior, possably even unqualifyed. Possably. I would definilty give it a qualifyed, like "for POVRay, it kicks Intel's ass on uniprocessers", or "per dollar, it kicks everyone's ass, for POVRay at least".
Then again if nobody benchmarked your app, or if your value scheme is not even reprsented by a benchmark, all those things are worthless.
ObTopic: I am planning on buying a new motherboard+CPU soon, and am strongly considering an AMD Athlon- or Thunderbird-based system. Anyone have any comments on how well such systems work with VMware? I know VMware dislikes my current 400 MHz AMD K6-2.
I have a 600Mhz Athlon, and it ran the 30 day demo of VMware ok (under FreeBSD 4.0, which I think was more or less the Linux version, with some FreeBSD kernel loadable modlues/devices replacing the Linux KLM/Ds). Of corse all I ran under VMware was more Unixes, since I don't have a spare Windows licence (I do have a spare BSDI BSD/OS licence, and a "OS" I wrote in class in '92, and it is a great testbed for PicoBSD).
Do you really want it too?
on
Movies Online?
·
· Score: 2
I have a fairly nice TV, and very nice sound. The theateres I go to have a even nicer display, and while I can't tell if the sound is nicer, I expect some people could. My living room seats about six if everyone wants a nice view of the TV. The theteres I go to seat a whole lot more. My house is pretty messy, and I'm fairly embarassed by it when I have folks over. The therteres are in pretty good shape, and it's not something I feel embarassed by when they arn't. So it is definitly nicer for me, to got out to a thetere with friends, especally if there are more then five of them.
Not that I am aginst having good AV gear at home, or being able to see nice movies at home (after all look at my TV and stereo...and DVD collection). I just think the social benifits of going to a thetere are pretty large.
Most people have good stoves, a cutting board, and a fridge, and many folks can make pretty good food. But there are still resturants, and I expect they will continue on as well.
We never really even explored the moon. We have maps of it out the wazoo thanks to the fact that you can take a map-quality picture of it with a backyard telescope (albeit and expensive backyard telescope), but we've only been up there the one time
One?
Apollo 11 was our first manned landing, but it sure as shit wasn't our last.
Besides this is "just" a probe, I beleve we have done that quite a bit (including the "manned probe" -- the Apollo 10 mission....)
I know U.S. schools suck (witness my spelling), but maybe you should go rent HBO's "from the earth to the moon", the drama has been punched up a bit, and the stories compressed, but it's basically true, and entertaining.
A pity India won't get as much spin-off tech, they could use it. Regretably most of the problems have been solved. At least there are still intresting moon questions to answer, I hope they try too rather then just going for the orbiting flag.
Take a Pentium Pro 200 and a Coppermine and do the following
...
Traditionally, a chip attains a new architecture identifier (ie, 486, 586) when the actual processing path changes. The Athlon was considered 786 material simply because they made massive improvements to the floating point unit, and because it utilized a completely new bus protocol (EV6 vs. GTL+). All of Intel's processors starting with the Pentium Pro up through the Pentium III Coppermine are considered 'P6' or '686' by many simply because it hasn't changed.
The PPro would stall if you mixed 8bit/16bit/32bit register uses inside it's rename engine. The P-II and on didn't (well, not just because they are mixed size uses at least). That may seem minor, but it makes a huge diffrence to Win95 and Win98 (and maybe WinME).
The P-III has 3 decoders, rather then the two the P-I, P-II, and PPro had.
The cache archatecture, and interfaces to the cache have changed a lot. Don't under estimate this, cache control logic is a very big part of modern CPUs (not to be confused with cache memory, which is almost all of the CPU by transistor count!).
Somewhere between the PPro and the P-III some really close to non-deterministic functional unit allocation went away (so code doesn't get faster by putting NOPs in hard to guess places...only in easy to guess places like aligning loops to cache lines).
Oh, and of corse pipestages have been added, work has been juggled between them, and things have been re-layed out to allow process shrinks and clock speed bumps.
The changes between the PPro, P-II, and P-III are at least as big as between the 68000 and 68010. That is to say, not huge, but not trivial things an intern could have done.
Find a compiler writer (a good one) and ask them the diffrences. They are pretty sizable.
Of corse they arn't as big as the diffrence between the AMD K6 and the K7, but, well, that's another story.
If you wanna look at uptimes for most NOS's check out Uptimes Project. Look at the all-time Top 10. The leader is an old NetBSD 1.1B box with about 1,500 days which is a runaway lead over the next box which just happens to a Linux one.
At that level it isn't a useful number (I admit it is still an intresting one). At 1500 days any box not doing really restricted duty is going to be dieing for an upgrade (software or hardware). If it is doing restricted duty it isn't really testing the whole OS. Even NT could run for a month or so if you only run solatare:-)
The one who dominates the top 20 is FreeBSD though and the rest of the pack is just overflowing with the sheer quantity of everybody and their grandma's Linux box. Which then brings up the Quality vs. Quantity debate:)
Yep. A more useful mesure would be uptime per boot (with 1st, 5th, 25th, 50th, 75th, 95th, and 99th percentiles), and %controled stop vs. %panic. The number would be arder to influance merely by having a large installed base. It would also be more useful to know that on avrage 50% of OSfoo's boxes run six months without panics then that someone running OSfoo ran it for 3 years in a row...
You also say that "there are thousands of incredibly serious users of the 3.x branch that have no desire to break their scripts". So the newer versions lack functionality that the older ones have? Gee, this is mighty illogical, and only gets more confusing...
Going from 2.x to 3.x a.out stopped being the executable format, and ELF started. 3.x could be compiled to run a.out files, but by default it wasn't. The shared libs for new things were also made as ELF by default, and if you wanted a.out shared libs you had to thwack it yourself. In the short run, it's a big pain. In the long run ELF is much better (better debugging support, better shared loader support for example).
Going from 3.x to 4.x (or maybe this was 2.x to 3.x again) the low level SCSI stuff changed. If you had a program that did raw SCSI it had to be "updated", the new interface is much nicer, so programmers in the future will be far happyer with the system, then the old one.
Going from 3.x to 4.x some of the sound and interrupt things changed (interrupt for better SMP I think, sound for supporting modern PCI sound cards better). The one-two-punch finally took out the old PAS-16 driver (the cards were state of the art nine years ago, and the compony that makes them defunct for 5 years)./it still compiled, but had config and boot time warnings and lost interrupts. I might have been able to fix it, but decided to buy a better audio card for $30.
All of these changes are nice in the long run. Any of them could be a short term show stopper. It's nice that the "old" branch still gets important patches. It's nice that things can be changed in incompatable ways when that will be better in the long run. That way we only have four async I/O systems, not 28:-)
Please enlighten me on this one if I'm wrong. Sure, FreeBSD has a simple package management system, but does it come anywhere near to the sophistication of Debian's apt?
I don't know. What does apt do? The ports stuff handles fetching a tarball, or using one you have allready fetched, applying "local" patches, building all dependent packages, some crud to handle fetching crypto from the "right" country, installs, uninstalls, and some other stuff I don't use, so I don't recall.
It is a little weak on "tell me what is installed", "tell me what depends on FOO", and "I was looking for that thing that displays GIFs and makes usic, what's it called?". Weak doesn't mean it won't help, but that the interface is clunky.
I'd also like to point out having a Linux kernel for BSD defeats the purpose of using BSD. BSD is inherently stable due to the maturity of its kernel.
Some of the satability is from the kernel, some is from the userland. There was a BSD/Linux effort at one point started by tchrist shortly after the whole GNU/Linux thing came to a head, but I donno if it ever went anywhere.
I would guess more of OpenBSD's security is from the userland then kernel (skiping over encrypted swap/FS, and IPsec for the moment).
Of corse the uptimes I have heard from Linux users isn't far diffrent from FreeBSD users, probbably both have weakspots. I'm sure both have strengths.
The big advantage is that your code will run under Linux (and other Unixish systems if you do your job right). That's a big deal, because you won't get bug reports about other programs crashing yours...and there are way fewer pain in the ass liberery bugs...and when there are it is far easyer to find them with the source to libc (or libcurses, or libfoo) and either fix them, or code around them. Way way way nicer. At least IMHO.
Interesting point, but since the DC uses an SH/4 CPU, not MIPS...
Don't forget the DreamCast also has an ARM7 part (the sound ASIC has an ARM7 core), which NetBSD and Linux can both run on. It can probbably only use the 4M of "audio memory", but that's enough to run a really tight config in, isn't it?
If I can get a genuine Athlon 700 for ~$150 now, why would I want to buy a Duron? Not a winner on performance; not a winner on price; not a winner, period. Pity.
You are compairing list price vs. street price. Price Watch has them listed at $89 (600Mhz) and $159 (700Mhz). I expect the prices will be lower when the get released for real.
Slashdot Mirror
That's a true statment on the face of it. If they won't assmble their own, they won't care that they can't assemble their own. But it shouldn't be true. If Macs were tinkertoy computers like the PC then the little mom and pop shop down the street could undercut existing prices. Then the big stores would have tolower prices at least a little to not look like they are totally gouging, or a lot to match prices. Venders would spring up that have a good idea on how to make part X cheaper even if they can't build part Y to save their lives. System cost falls again.
PCs arn't cheap just because they have cloners. Look at portables, the no-can-do-it-yourself PC. Pretty costly, and an area where Apple is cost compettave too...
Roughly the same argument goes with Open Source Software. Joe Accountant doesn't care that he can modify a program, but he should care that he can hire anyone to do it, not just the place he bought it from. In thery that drives prices down and quality up.
While that is a feature, there are some other nice advantages. If you want to have more then one type of service on a single circuit (say best-effor 100x over subscribed AOL account for one PC, and a mere 4x oversubscribed small-bisness account for another -- or even the same PC depending on what you are using it for) you can do it with PPPOE, while that is hard to impossable with DHCP.
You can do a lot more configuration at a higher level. Tracking an account number is much simpler then tracking a set of MAC addresses (which will change if the consumer gets a new computer, or ethernet card - and may move from point to point on your network anyway!). Tracking an account number tends to be somewhat simpler then tracking a (Router,Card,Curcit-ID) tuple, and it simplifyes moves as well.
It also disrupts a home network far less. You don't have to configure your network aware printer NOT to ask for a DHCP address (which would end up putting it on the global net, and possably using your only address!). If you have multiple computers allready on a network, and you want to put one on the Internet, this won't force you to get another card for it, or to sever it's connection with the existing network. This may be a rare case, but I assure you it was one the authors of the RFC did have in mind. Rember if your ISP does DHCP for you, it is a lot harder for you to also do DHCP for your local network!
If the ISP allready has a RADIUS infrastructure set up for a large dial network, this allows them to reuse it for DSL. This is a fairly big deal because beleve it or not it is a pain integrate yet another database (DHCP's configuration) with allready existing order, payment, accounting, and other random systems at the ISP. A PPPOE baised DSL set up will look a whole lot like the existing dial set up (presumably with a higher monthly fee).
And if you search in it for "waves" about the forth one has a link to the same page the quickies article talks about. I knew I had seen it on slashdot before :-)
11 or 15. Six for decode (FETCH, SCAN, ALIGN1/MECTL, ALIGN2/MEROM, EDEC, IDEC/Rename), or maybe five depending on how you feel about IDEC/Rename. For integer instructions (at least direct path ones) you then have SCHED (which can take multiple cycles, depending on how long it takes for all inputs and an appropriate functional unit to become available), EXEC, ADDGEN, DC-ACC, RESP (DC-ACC and RESP are cache accesses, I'm not sure where the write back is -- they may have left the retirement out of the document I'm looking at). The FP pipeline (FP instructions, MMX and 3D Now! instructions as well) is longer, 15 stages (including the first 7 above), more for FMUL.
That's all taken from Appendix B (page 191) of the AMD Athlon Processor x86 Code Optimzation Guide (it's a PDF).
I thought the Willamette's was more like 25 pipestages for the integer unit, and an undisclosed (I assume higher) number for FP operations. The PPro's is pretty long allready, like 18 or so (that may be for the FP). I assume about the same length in the P-II and P-III since they are the same microarcheture.
If you fully interleve the SDRAM it has pretty impressave bandwidth numbers too. Of corse that takes (about) four times as many pins. In fact 8-way interleved PC100 SDRAM excedes the bandwidth the Intel and AMD can get off their CPUs, so the only thing that will matter is latency, which'll make the SDRAM a better choice...
If you can come up with all those pins. If.
Low pin count is one of RDRAMs few remaining advantages (RDRAM systems with no CPU L2 cache run about as well as systems with small L2 cache and a normal memory system -- but that's not a good deal with L2 caches so large these days...I can list other obsolete advantages if you like). You can four way interleve RDRAM with (about) the same number of pins you need to interface to stright (not interleved) SDRAM. So if IBMs high density packaging catches on, RDRAM loses that (as more pins will be cheep). If DDR SDRAM really uses a 16 bit interface RDRAM loses it's advantage.
Of corse I don't see many chipsets using this advantage. Where are the motherbord chipsets with four RDRAM controlers?
RAMBus is over eight years old. This is something like the fourth major revision (in '92 it was a 400Mhz 8bit interface). This is not a repeat of the Celeron story.
I don't see how they came up with the 1% number. Here are a few counter arguments...
The x86 has reached some pretty impressave speeds. 1Ghz is shockingly fast. Even 800Mhz is quite speedy. Intel has done this by using extreamly long pipelines. Some 15-22 pipestages depending on the operation. AMD has done the same. A longer pipeline increses the latency of many operations, and makes sequential dependencies in code cost more and more. And branch penailties, and load cache misses. IBM has the PowerAS running at 600Mhz with a 5 pipestage machine (that is fewer pipe stages then the AMD uses to decode instructions!). It smashes the PPro-P-III and AMD in anything that has lots of poorly predicted branches. Like DB code. It does better on code that does lots of pointer chasing (like linked list walks).
(the PowerAS has a zero to one cycle peanilty for "misprecidted" branches (it's prediction method is "allways taken", or "never taken" I forget which); the Intel has a penality of more like 11 to 20 cycles, with a maximum peanilty of 44 or so cycles of work discarded from the ROB, the Intel has a very good branch prediction scheme, for predictable branching patterns, when it gets to bad to predict code it sucks big time)
The P-III and AMD managed to decode 3 instructions per cycle, quite an acomplishment with an irregular sized instruction set. They have finally gotten to this point. The SuperSPARC in 1992 or 1993ish decoded four instructions per cycle. That means the best the x86 can do over the long term is to execute three instructions per cycle (because even if they have spare functional units, they will run out of instructions in the reorder buffer if they manage to execute >3 instructions per cycle for long). RISCs have grown a few more decoders in the intervening 8 years. Some of them at least.
If the x86 is only one percent slower then RISCs, why is the anchent (2 year old?) Alpha 21264 at a mere 667Mhz still turning in better SPEC2000 FP numbers then the "shipping only to select OEMs, and not many units either" 1Ghz Intel part?
Try to get a stream benchmark number in the same ballpark as a real Alpha (not one baised on the PC chipsets), with a Xeon. Intel hasn't made a memory system that can compete. And the memory system is half the price of the damm Alphas.
RISC may have lost the comercial war to CISC, but there is no need to stomp on it's acomplishments. There are really impressave RISC CPUs for a fraction of the research dollar Intel (and AMD!) spend.
Oh, but they have. The i960 is a diffrent ISA, I never used it, but I'm sure it is quite diffrent from the x86. The i860 was also very diffrent. It had a pretty nice ISA as long as you didn't put it into streaming mode. The VLIW mode was a bit odd to me, but it wasn't a huge deal.
Peopel even used them. Just apparently not enough people used the i860. I donno what the deal was with the i960. It was extreamly popular 5 years ago, but doesn't seem to be now.
They have some of the qualities of embeded systems (price is a huge factor, and compatability with desktop software is pretty much a non-issue). Moreover the CPUs in succesful PDAs (the Palm line for example) are CPUs that were designed and marketed for the embeded market. They also fit some people's definiton of "embeded", but I admit that is a big strech of the traditonal deinition.
It (or NetBSD) would cut devlopment time for say a car MP3 player that needed to use 802.11 to fetch new songs while parked in the garage... but I wouldn't be very tempted to use it for an anti-lock break system.
If HP had used it for their printers I don't know if the print engine would be worse (I don't know how much RT it needs), but the TCP stack would be marketdly better, as the exiting one screws up if the least bit of stress is put on it (say more then one TCP connection at once is sometimes enough!)
Lots of DVDs are duel layer. I can tell because my player has a super breif, but supper irratating pause when refocusing. Movies I was buying last summer, and before were duel layer.
The Matrix has some other problem. Like use of alternate angle, or a diffrent path through the movie or something. I'm not quite sure, beause my player didn't have problems with it. I think it has problems with the "white rabbit tour" which is the normal movie, but some scenes show a white rabbit, and if you hit enter then you get a "making of" for that scene. I'm not quite sure what DVD features are used to do that.
I havn't bought VHS movies for a long time (well, ever, but my wife use to buy them a lot). I seem to remember them costing more then I pay for DVDs after a quick trip through a price search engine. Are video tapes really cheaper still?
As far as I know the Asus K7V, and other KX133 chipset baised motherboards have AGP 4x support. And pricewatch looks like you can buy them now.
Intresting roumor, where did you here it? It definitly won't be needed until we get faster memory technology, or support for multiple SDRAM (or RDRAM, which I think might saturate a 200Mhz 32bit bus).
What I'm waiting for are the multi-way chipsets (well, not really waiting, looking forward to seeing market reaction too). It'll be intresting to see AMD chalange Intel in the high end PC server market in addition to the high end a nd low end desktop range.
If I beleve going to McD's is moraly wrong for some reason, that the mere existance of McD's damages society, or mankind as a whole, that it is an evil empire that needs to be demolished before man can achieve utopia, well, then merely not going myself won't be enough will it?
I would need to convince other people not to go. (this is hypothtical, I personally don't find McD's to be all that evil, they just serve bland food, with relitavly little enjoyment value for the immense fat content -- so I don't eat there, I feel no real need to prevent others from it)
No I havn't. My mere want for you not to go to McD's doesn't cross any leagal line that I am aware of (in the USA at least). Nor any moral line. Actions that I take might cross a line, but mere desire does not. In the USA at least it doesn't cross any legal line for me to tell you (or at least talk near you) about how much I think McD's sucks (as long as I don't lapse into untruth, and risk slander, or libel, depending on wether I am talking or writing). It wouldn't cross a line for me to hold up pictures of what I imagine McD's offenses to be. At least so long as they are things McD's actually does.
It would cross a line if I actually physically bared you from going (I expect it would legaly be assult, or some other relitavly serious crime), or if I rendered the McD's inoperable (say by calling a bonb thret, or maybe burning it to the ground when nobody is around), which again would be illegal.
But merely exorting you not to go, well that's not illegal. Just look at all the people advocating a boycot on Microsoft, Amazon, or Wal-Mart. None have been sue'ed or charged with any crime for that.
We seem to be in agreement on this point, so why do you assert a mere desire to prevent you from going is crossing a line?
Picketing isn't a bad idea either. Nor is publising (perhaps on a web page, and in the local newspaper) the reasons other might want to also not go to McDonalds (or buy a particular shoe, or brekfast cerial).
One person alone skipping a product they dislike is a start, but if they actually want to get rid of the hated thing they need to convice others to skip the product as well. Fortunitly in this country there are plenty of protected free speach rights they can use to do so (well to attempt to do so, they have no right to actually convice anyone of anything, just the right to try). I expect france isn't exactly lacking either.
(and no, I doubt vandlising a construction site is protected free speach, but not being up on French custom, I don't know for sure)
It is funny in a lot of deeper ways then that, but it does seem to work better then the other known systems.
What makes you think there is a price to pay for the "freeloaders"? The non-payers won't be using valuable support time. There might be staff time spent looking over the "unsupported users mailing list" for real bug reports and fixes, but if you get any reports or fixes then that has more then payed for itself (for a low volume, this is a single intern's job, almost free by corprate standards). If you don't seem to get any reports or fixes, you don't pay anyone to do that job.
The other "freeloaders" frequently would not pay for your product anyway, they are poor studants, super cash straped start-ups, and places where you product is super-over-kill. Those cost you nothing, you wouldn't have lost the sale, but by giving away the software you get free training, free bug reports/fixes, and free advertising if any of those studants should graduate and go somewhere that needs your software, or if the cash-strapped startup gets a big contract and suddonally needs your product to be gaurenteed to keep their cash flow!
There are a vanishingly small number of customers for a corprate product that would choose to have no support. They buy Red Hat at $60 a box, not the identical CD from cheep bytes for $1.99 with no support.
My guess is that this vanishing small number will be ofset by the extra sales your "marketing" move of giving away free copies with source will bring in. Plus bug reports/fixes (if any).
Depends strongly on the product's market. Componies will pay for support on mature products that havn't been observed to break if their breakage will cause a large loss of money, or if the support contract is quite cheep. How many places that have never had a disk failure buy RAID arrays? Or support contracts on new hardware? Support contracts on the RAIDs even?
Think of it as the software equivolent of an extended warrienty. They may normally be crap, but most people buy them. Componies arn't any smarter then people. In fact they are a lot lot dumber sometimes.
I don't see where there is clearly less money involved for a bisness targeted product. You are right that you can't count on getting free bug reports and fixes just by open sourcing something. But you definitly increse the chances from 0% to something possable (for bug fixes/free new features).
It doesn't make sense for some products. I don't see any way a OSS family tree product could make signinfigant money. That would have to be done to "scratch an itch", or for the "glory". But that doesn't mean all OSS trades dollars for glory.
Depends on what you are mesuring. A stright per Mhz comparisin isn't really any more useful then a per transistor rating. Granted they are done all the time, and people fixate on them.
More useful are the per dollar rating (and you probbably need to include the cost fo the support chips at the very least, whole system is better). After all most people don't go to the store to pick which 800Mhz system is faster (or which 190HP car is faster), but to pick which $700 PC (or $18,000 car) is faster. (assuming faster is what they are after, as opposed to quieter, safer, less poluting, or a nicer color -- for the car or the PC!)
Useful for another set of people is "screw the money, of the systems I can lay hands on, which is faster". Maybe an expensave quad XENON with RDRAM, maybe a single fast AMD K7 (for non-multithreaded FP bound apps). Of corse an Alpha (lower clock speed and all) toasts 'em both (at least for SPEC like apps), if you can recompile the app. Or with the car analogy again, maybe a Ferari, maybe the Lotus, or maybe even something that isn't streat legal at all.
Useful for a far smaller set of people is the "which is faster per Mhz", and those are mostly people trying to figure out why a system is fast. Not people intrested in buying it for that reason.
Other people are intrested in waste heat given off, and power sucked up (people buying portables).
On all of those, diffrent applications may be more important. Quake III to you, POVRay for me, Kernel compiles to Linus, how fast AOL loads for my mom.
Others might be intrested in the politics of the company (do they donate money to polititions I hate?). Or how much the enviroment is hurt per CPU made. Or how the workers are treated.
Oh, and lastly, there have been benchmarks the AMD womps the Intel at, even the slow slow extrnal cache 1Ghz models. The "NT 3D content creation" ones, which seem to have lots of FP, and are too big to fit whole in either cache for example. The newer Thunderbirds (less cache, but at full speed, even with a relitavly narrow bus) do quite well. They are per clock competitave with the Intel's on many benchmarks, beating them on quite a few (quite a few being more then half I think, competatave is normally with in a few percent). More importantly they are per dollar competitave, beating them on almost evey single benchmark I have seen.
Go look at the Thunderbird benchmarks again, or point me at URLs of the P-III soundly beating the Thunderbird. (it could be, I only looked at a few benchmark pages, I can only look at so many 15 page long half bar graph articles before I've had enough!)
I don't know if the per dollar thing is enough to claim AMD is (unqualifyed) superior. In my mind the max speed you can actually buy, plus the per dollar, in the vast majority of benchmarks would at the very least rate a qualifyed superior, possably even unqualifyed. Possably. I would definilty give it a qualifyed, like "for POVRay, it kicks Intel's ass on uniprocessers", or "per dollar, it kicks everyone's ass, for POVRay at least".
Then again if nobody benchmarked your app, or if your value scheme is not even reprsented by a benchmark, all those things are worthless.
I have a 600Mhz Athlon, and it ran the 30 day demo of VMware ok (under FreeBSD 4.0, which I think was more or less the Linux version, with some FreeBSD kernel loadable modlues/devices replacing the Linux KLM/Ds). Of corse all I ran under VMware was more Unixes, since I don't have a spare Windows licence (I do have a spare BSDI BSD/OS licence, and a "OS" I wrote in class in '92, and it is a great testbed for PicoBSD).
I have a fairly nice TV, and very nice sound. The theateres I go to have a even nicer display, and while I can't tell if the sound is nicer, I expect some people could. My living room seats about six if everyone wants a nice view of the TV. The theteres I go to seat a whole lot more. My house is pretty messy, and I'm fairly embarassed by it when I have folks over. The therteres are in pretty good shape, and it's not something I feel embarassed by when they arn't. So it is definitly nicer for me, to got out to a thetere with friends, especally if there are more then five of them.
Not that I am aginst having good AV gear at home, or being able to see nice movies at home (after all look at my TV and stereo...and DVD collection). I just think the social benifits of going to a thetere are pretty large.
Most people have good stoves, a cutting board, and a fridge, and many folks can make pretty good food. But there are still resturants, and I expect they will continue on as well.
One?
Apollo 11 was our first manned landing, but it sure as shit wasn't our last.
Besides this is "just" a probe, I beleve we have done that quite a bit (including the "manned probe" -- the Apollo 10 mission....)
I know U.S. schools suck (witness my spelling), but maybe you should go rent HBO's "from the earth to the moon", the drama has been punched up a bit, and the stories compressed, but it's basically true, and entertaining.
A pity India won't get as much spin-off tech, they could use it. Regretably most of the problems have been solved. At least there are still intresting moon questions to answer, I hope they try too rather then just going for the orbiting flag.
"non-support"? You mean the one-week (one month?) stonewall, followed by the biggest CPU recall program in history?
So, ok, it was a crappy thing for them to do, but you make it sound like they didn't come through at all. Which is pretty far from what happened.
I have a K7 too, but more because it was a better bang for my buck then because of a PR disasater half a decade ago!
...
The PPro would stall if you mixed 8bit/16bit/32bit register uses inside it's rename engine. The P-II and on didn't (well, not just because they are mixed size uses at least). That may seem minor, but it makes a huge diffrence to Win95 and Win98 (and maybe WinME).
The P-III has 3 decoders, rather then the two the P-I, P-II, and PPro had.
The cache archatecture, and interfaces to the cache have changed a lot. Don't under estimate this, cache control logic is a very big part of modern CPUs (not to be confused with cache memory, which is almost all of the CPU by transistor count!).
Somewhere between the PPro and the P-III some really close to non-deterministic functional unit allocation went away (so code doesn't get faster by putting NOPs in hard to guess places...only in easy to guess places like aligning loops to cache lines).
Oh, and of corse pipestages have been added, work has been juggled between them, and things have been re-layed out to allow process shrinks and clock speed bumps.
The changes between the PPro, P-II, and P-III are at least as big as between the 68000 and 68010. That is to say, not huge, but not trivial things an intern could have done.
Find a compiler writer (a good one) and ask them the diffrences. They are pretty sizable.
Of corse they arn't as big as the diffrence between the AMD K6 and the K7, but, well, that's another story.
At that level it isn't a useful number (I admit it is still an intresting one). At 1500 days any box not doing really restricted duty is going to be dieing for an upgrade (software or hardware). If it is doing restricted duty it isn't really testing the whole OS. Even NT could run for a month or so if you only run solatare :-)
Yep. A more useful mesure would be uptime per boot (with 1st, 5th, 25th, 50th, 75th, 95th, and 99th percentiles), and %controled stop vs. %panic. The number would be arder to influance merely by having a large installed base. It would also be more useful to know that on avrage 50% of OSfoo's boxes run six months without panics then that someone running OSfoo ran it for 3 years in a row...
Going from 2.x to 3.x a.out stopped being the executable format, and ELF started. 3.x could be compiled to run a.out files, but by default it wasn't. The shared libs for new things were also made as ELF by default, and if you wanted a.out shared libs you had to thwack it yourself. In the short run, it's a big pain. In the long run ELF is much better (better debugging support, better shared loader support for example).
Going from 3.x to 4.x (or maybe this was 2.x to 3.x again) the low level SCSI stuff changed. If you had a program that did raw SCSI it had to be "updated", the new interface is much nicer, so programmers in the future will be far happyer with the system, then the old one.
Going from 3.x to 4.x some of the sound and interrupt things changed (interrupt for better SMP I think, sound for supporting modern PCI sound cards better). The one-two-punch finally took out the old PAS-16 driver (the cards were state of the art nine years ago, and the compony that makes them defunct for 5 years). /it still compiled, but had config and boot time warnings and lost interrupts. I might have been able to fix it, but decided to buy a better audio card for $30.
All of these changes are nice in the long run. Any of them could be a short term show stopper. It's nice that the "old" branch still gets important patches. It's nice that things can be changed in incompatable ways when that will be better in the long run. That way we only have four async I/O systems, not 28 :-)
I don't know. What does apt do? The ports stuff handles fetching a tarball, or using one you have allready fetched, applying "local" patches, building all dependent packages, some crud to handle fetching crypto from the "right" country, installs, uninstalls, and some other stuff I don't use, so I don't recall.
It is a little weak on "tell me what is installed", "tell me what depends on FOO", and "I was looking for that thing that displays GIFs and makes usic, what's it called?". Weak doesn't mean it won't help, but that the interface is clunky.
Some of the satability is from the kernel, some is from the userland. There was a BSD/Linux effort at one point started by tchrist shortly after the whole GNU/Linux thing came to a head, but I donno if it ever went anywhere.
I would guess more of OpenBSD's security is from the userland then kernel (skiping over encrypted swap/FS, and IPsec for the moment).
Of corse the uptimes I have heard from Linux users isn't far diffrent from FreeBSD users, probbably both have weakspots. I'm sure both have strengths.
The big advantage is that your code will run under Linux (and other Unixish systems if you do your job right). That's a big deal, because you won't get bug reports about other programs crashing yours...and there are way fewer pain in the ass liberery bugs...and when there are it is far easyer to find them with the source to libc (or libcurses, or libfoo) and either fix them, or code around them. Way way way nicer. At least IMHO.
Don't forget the DreamCast also has an ARM7 part (the sound ASIC has an ARM7 core), which NetBSD and Linux can both run on. It can probbably only use the 4M of "audio memory", but that's enough to run a really tight config in, isn't it?
Duel CPU DC :-)
You are compairing list price vs. street price. Price Watch has them listed at $89 (600Mhz) and $159 (700Mhz). I expect the prices will be lower when the get released for real.