Well, there's a simple solution to this. Don't upgrade to ME. Problem solved.
Cute. Course, MS will make sure that none of the drivers for the latest and greatest hardware works with win 9x two years from now. Sure companies will make strives to maintain support, but it'll eventually fall off. Especially if the drivers are easier to develop under win >= 1000. Just think of all the win-modems that have minimal R&D put into them. (Not that I'd ever buy one of those)
Then, of course, as a developer for a windows market, you'd be crazy to not develop _for_ the new platform. Meaning, you're going to have to have at least some win-me machines. Then, as we typically do, once we start using the newer interface, it'll be hard to go back to the older one ( Just like win95 -> win3.1, or even win98 -> win95 ).
As a disclaimer, I'm biased towards all my OSes. (because they each give me something the others do not).
>So instead my program runs fine then randomly crashes at the aforementioned line on code on some machines. >Since then I have promised myself never to do any serious development in C if I can help it.
That is why you modularize your code and perform unit testing.. This sort of error will prevail in any sort of language. For a given language, there will always be problems that have complex solutions. At this point, you have to apply good programming practices and a bit of software engineering. That a language such as Java or Pascal alleviates many types of programming errors is good, but there are just as many minuses to these languages. It's an engineering decision as to which language is best suited for a given set of problems and developers.
Personally I use Perl, but that's even more error-prone than C (with the exception of core dumps). Good coding practices are essential for this. (The benifit, of course, is rapid development time)
I am going to assume that you've dealt with the perl core code, so I'm not going to debate with you. But to defend myself to others, let me say this: Scalars are a dynamic type which encompases integers ( in optimized cases ), floating point, strings and references ( which are the basis of most perl complex datatypes, including objects ). When in doubt, perl makes something a string. To my knowledge, DBI reads come in as strings ( I could do a test, but frankly I don't care enough ). Flags in the scalar object specify if it is currently in int/float/string/pointer form, and it's possible to flip flop around in most directions ( even from a pointer ). Because of this, you can always treat the scalar as a string. Hense my comment.
I think your biggest reaction had to deal with the defamation of perl sophistication, perhaps likening it onto something like COBOL, which uses pseudo-ASCII numbers ( 4 bit digits, if I recall ).
I guess I should really qualify these things. Every other person asks me this. Yes I've used mod_perl, and I've even found better solutions ( such as FastCGI ). This was really the type of general purpose solution I was talking about. The PHP comment had to do with how quickly you get get a dynamic web site up. A Cold Fusion engine referred to a potentially higher throughput engine.
Don't see how it's misleading since the nature of perl is to make everything a string unless otherwise specified. DBI and JDBC are similar from what I understand. The argument isn't for a better DB interface but how to handle arbitrary data-types. A good reasoning for this is that I might not care how the database was designed. Was it a 32bit int or 64bit ( possibly 32/64 bit date stamp, etc ). Changing the database means changing the Java / C code. In Perl, I don't think I've ever had to change a line of code because I've redefined types for table columns. This allows me to quickly get a proto-type database up ( possibly with all text fields ), then later optimize the row lengths. More importantly, if the DBA needs to lengthen a VARCHAR, he can do so without risk of affecting the perl code. The only issue that should ever come up is the formatting of the resultant HTML.
Arguably, you could create a Java DB interface that returned everything as a pointer to type "Object", then use to_string for display purposes. I think that we'd all agree, however, that this would be undermining Java and bad programming practice.
Hehe.. Isn't this why all database fields should be declared as text? Laugh.. All kidding aside. I've rarely ever had fields in a DB that perl cared about. It was almost always a medium to read from a CGI form and write to a DB ( validating fields there ) or reading from the DB and displaying on the screen. I'm sure there are cases that the information is more sensative, but I've never encountered one.
Another point of view is that because strings are so versitle in perl. It wouldn't matter if you read it in as a string, float or int, since it could easily internally type-cast to the appropriate type when used. The worst that would happen is that you'd convert a string to a zero, which should signal a warning somewhere.
As for initialization.. YOU MAKE BAD PERL JUJU, since you obviously don't use -w. If you did, then you'd know that it's impossible to use a variable without first initializing it. Perl allows you to make the command line -e '...' without any type checking, but allows you to be anal man with -w and "use strict". Trust me, when I started using -w, I'd get really pissy because I loved the default case of undef becomming an empty string. Now I have to $str ||= ""; everything that I know is printable even when null.
Theoretically, you could link to the perl reg-ex library. You could also use it's kick-ass memory manager ( due to double indirection ) to help prevent massive memory cluttering due to allocs and frees for all the tiny strings. But at that point, you'd be using perl. And what's the point, since it's quicker to code and debug a perl program than a C one. Dynamic systems, such as web pages require a development environment with a fast turn-around time.
My point is that perl had a nich back in it's day, and that way string parsing. It's libraries were optimized to do so. Many of the types of optimizations ( such as self modifying code, in the case of variable substitutions for reg-ex's or even the eval '' statement ) are hard to do in a low level language. Not that it isn't possible, but just that to do so would take an enormous amount development effort, which doesn't fit into the web-model.
Perl isn't really the best web-model for most situations either. A heavily loaded web site would be better used by a massive C-engine with customizable pages. Or a PHP/ASP setup might get pages out the door faster ( especially with new developers ). But Perl is a very good general purpose tool for text processing ( as well as other fields ).
Actually, Perl 5.005 allows typed variables. I tried designing with it, and it really gets combersome.
# Class A; Class B inherits Class A
my A $obj1 = new B; my B $obj2 = $obj1;
I liked it because of the supposed optimization of the pseudo hashes, but I found myself typing 3 times as much to do incredibly simple tasks. Personally I like building OO libraries ( makes my work easier down the road ), but the "bolted on" perl OO model takes a lot more work when an attempt is made to be clean and concise, which you need to do every now and again.
That said, I definately agree with you about how powerful perl is when it comes to data manipulation such as in databases. I can throw together a complete CGI/DBI web site in minutes, for prototyping, then go back later and structure all the function calls when there's time.
Most likely there will be pragmas that turn on the new syntax.
For example.. The new regular expression package can only be used by typing use re;
Most likely there will be a requirement to say use 6.0; To make sure of the new engine. The older engine will probably be linked out for use in compatibility scripts. For example. the use of '&' in a reg ex makes the entire perl engine react differently; Likewise, finding a module that makes use of the new syntax would affect which interpreter / library is loaded in memory.
I hope that they find a clean way of doing this. A rewrite really should not feel like bolted on code.
It isn't really that VB is to blame, or even that OE has a bad security model ( though that does contribute ). It's that Users are allowed to execute foreign code. It wouldn't matter if IE had a really good security model, and the viruses were written in assembly. So long as the User could activate foreign code that could get to local resources, the virus could probagate.
The simplest security measure is to not run untrusted code. The next level is to have an isolated environment in which the code can run ( a la protected login accounts in UNIX, and to a tiny degree; in NT ). The next level would be to limit the resources that trusted code can access ( e.g. Java security box, or tainted mode in perl, etc, but more directly, preventing access to OE material ).
The fact that VB or VP are scripting languages is really irrelevant. The only time that it is a serious issue is when you can pass code as a parameter; unchecked parameters can break out as new compiled code and do virtually anything that the interpreter will let them ( which typically includes access to files and the internet ). But a good programmer runs tainted mode, etc. Thus, scripting languages are merely more suseptible to bad programming. A common error would be inserting data into a database through a web form. I could close off the SQL statement, put a semi-colon, then begin a new SQL query which could create a new account ( assuming I knew enough about the target database ).. So on and so forth.
I agree that the addition of too many powerful widget APIs opens up a user for security risks. But so long as we don't give important access to users, we should be fine at level 2. In fact, if you were really paranoid about such things, you could create an account for all your important activities. Your development could be done as a seperate user, your financial data would definately run as a seperate user, your browser would probably be it's own user ( since it's the most suseptible to attacks ), etc. This of course, assumes that you have a box at home where you can create an unlimited number of accounts. Course, most of us are too lazy; We'd probably set up.rhost files so that we could have our desktop icons rexec to the proper user names... thereby leaving the Xserver account as a dangerous point of virus-infestation.
Essentially, a good security model would have a permission tree. User can login. Login users can start X. X-users can spawn netscape. Netscape users can run a limited set of programs ( such as Java ). Course, you'd have to make heavy use of group execute permissiosn, and major apps, like netscape java, etc could not be world executable. Therefore, I believe it's definately possible to secure Linux against API attacks, but it's definately not convenient.
All of this security would be necessary if the API is to be opened up so widely. But, I am much more afraid of another daunting issue; That of stability. Windows is unstable, in part, because there are so many interfaces that there are too many resource dependancies. A component can open up a resource channel, then fail.. The the resource could block indefinately, thereby tying up other components. I believe that UNIX does a good job of releasing a resource when a process fails; the idea that a process should be completely killable. However, with a GUI, it's entirely possible that a connection is so complex that programmers will get lazy and not take care of failed connections at random points.
The only solution to this latter matter is one of foundation building. Meaning, always building application components on top of concrete models that take care of all conditions. This has both the advantages of preventing the developer from making stupid mistakes, and the reduction in code for each component.
The article says that they were part of an open standards group named JEDEC. They secretly produced several patents that partained to the results of the standards group. They then pulled out of JEDEC and pursued their own interests. It's entirely possible that they in fact stole basic ideas from the group and patented them on their own.
The real issue, however, is that this article suggests that the patents were on technology that was pre-existent, and therefore the patent was improperly issued. The defence is one of "prior art", though I'm not really familiar with the topic.
Well, Why 3D was the original reason for my post. Perhaps I should have emphasized the "Not".
My argument is that 3d "should" be able to give you more functionality / access to information _because_ of the additional depth. Yes, there is the prospect of visual overload. But we _live_ in a 3D world, and we've learned how to take advantage of it. As for navigation and losing material, that's where translucense comes in handy. I just keep thinking of all the 3D video games that I play, and how much more functional their interfaces are than standard 2D ones. Homeworld, for example allows a very nifty 3D rotational map with effective zooming in and out. Grouping things into spherical shells is very efficient, and doesn't provide information overload as quickly as a 2D representation.
For example, take the icons on the desktop. Sure they can get overbearing. I can't have more than 10 on my desktop or I just ignore them (if it takes me more than 3 seconds to find something, it's not functional). You can get around this by putting things on different regions of the desktop; I use the Start menu for some things, the quick-launch bar for others, and the desktop for still others.. I've trained my mind on where to find these things. This is how we work in real life. We quickly get overloaded when there isn't enough unique sensation to identify objects in our mind. By finding objects in unique settings, we better remember them (supposedly that's how you remember people's names.. though I've never fully figured that one out). Having a 3D GUI could allow you to have a hell of a lot more ready information at your finger tips while at the same time REDUCING information overload.
Here is a plausible example. Let's take my MP3 drive. It has nearly 20 Gig of stuff on it right (all legal by the way). Finding stuff is a bitch. My solutions have been to A) produce sym-linked directories for the many types of catagories: personal favorits, genres, and authors. B) Produce a database which fetches path/file names based on query info. The second solution doesn't work very well with play-lists (except in generating text-files). A 3D interface could show me each and every MP3, including information about them. I could navigate a 3D neural-network-like interface where at each node there was associated information. You could not possibly fit all of this into a 2D screen, but in 3D, you could zoom in and out (while having only more important information visible while zoomed out); you could trace associations from one title or author to the next, etc. Granted this sound like a rather complex task... And for a simple MP3 database it would be. But image your entire filesystem if it were handled this way (or at least viewed this way).
The first thought that comes to mind is Jurrassic park in the little girls famous quote "It's a UNIX system". Course that interface was terribly impractical. If you knew the command-line name and it's arguments, that would have been incredibly faster. But I think part of the point here is to evolve the GUI into something that is more intuitive than a command line, and yet can provide more information than a 2D GUI, and ideally be as intuitive as real life.
All I'm saying is that I prefer 3D video games to 2D video games, and there is no reason to believe that we can't make 3D GUIs that are just as desirable. Maybe First Person isn't the answer, but it's short sighted or uninformed to only comment on them.
As for the wasted CPU cycles, seeing as how most of this is offloaded to the graphics hardware, I don't see how they're wasted.. Buying a $400 video card and only using it 5% of the time (when you're playing games) seems like more of a waste to me. Also, if done properly, a 3D interface could consume less memory. Wireframe, for example, consumes considerably less memory than layers apon layers of bitmaps. Granted, MIP-Mapped textures, lighting maps and environment maps take up a hell of a lot more memory.
Expanding on this, doesn't planting consume the nutrients of the soil.. INAF (I'm not a farmer), but don't farmers have to replenish all the nutrients periodically (sometimes by planting crops that they till into the soil). The more energy you could acquire from a crop, the more greedy it will be from the soil (like Tabacco).
Basically you'd be trading environmental friendliness with starvation of our farmlands.
My sentiments (though a little too sarcastically). The only reason that anyone would colonize the moon would be for some serious profit. The only reason Europeans ventured across the Atlantic was to find a cheaper way to get to India. I seriously doubt that we could do anything cheaper on the moon than we could on Earth.
I find it funny that we geeks, who are so fond of Sci-Fi, are so quick to assume the future. Sure space exploration/navigation was monumental, but it failed quickly as the driving forces dried up. Personally I have little faith that we'll have any manned mars missions any time soon. The "Because it's there" attitude is getting harder to swallow when you look at the ever increasing price tags. The lunar-landings were not even such an argument; they were instead, an international pissing contest.
The only thing that makes sense about main article is that if we "were" to colonize the moon a hundred years from now, then we'd have a potential source of energy (assuming we ever prove fusion to be reliable).
Perhaps I'm naive here, but I don't see why you dismiss 3D as a GUI. You imply that serious graphics hardware is really necessary for 3D, but anymore, 3D support is standard, especially in the optimized forms such as Glide and Direct3D (I know, I'm a heretic for not promoting GL instead of these proprietary standards).
In playing with Silicon Graphics machines I was not overly impressed with their GUI design. It had only a few tiny improvements, such as enhanced graphical directory navigation at the command prompt and the scaling of just about everything. Anymore, the prompt is being phased out. Hell, even in Linux, the "task-bar" is replacing more and more everyday command-prompt operations with mindless point and click. And forget about the prompt in windows. Also it wasn't too long ago that DirectDraw allowed graphics scaling on the windows platform.
I've seen a couple interesting concepts utilizing 3D. The most profound (for me at least) was the perspective view. Namely for those of you, like me, that have window-itis (never less than 10 windows open at a time), only those windows in central view are fully sized and detailed, surrounding windows are visible though compressed / distorted (the actual method I think was to provide a geometrical box which you were looking into.. All non-selected windows were on the periphery of the box and thereby taking up less space).
Perhaps you are thinking more along the lines of the movie Disclosure where you make use of a virtual reality helm and gloves. Computationally, VR is no different than standard 3D games (first person with multiple complex input devices). The only real complexity with the Disclosure model was the voice interface (which required AI), and possibly the scanning device that renders your avatar.
VRML could have been the next big GUI, but it seems to have failed miserably, probably because it never found it's killer app. Theoretically we could have all mimicked our working environment, and then applied various database queries around certain triggers, and you could have achieved a low-res version of Disclosure.
I think Apple's integration of PDF into their GUI is definitely a step in the right direction, though as you said, it's nothing new (NextStep had postscript built-in in a similar fashion). Unfortunately that's really only for show, and doesn't really provide too much additional functionality.
Hell, the whole concept of the task bar is a remarkable advancement in my opinion. Anything that allows me to seamlessly manage multiple services on my computer (or to blend them into one big service) is advancement in the science. Additionally the treed directories that expand and collapse on command (with the ability to perform operations on the tree as if you were at a command prompt) is functional (though it has been around for well over a decade even in the DOS world a la Xtree Gold, etc). Intelligent Drag and Drop has been an essential addition to the GUI world (thankfully even the UNIX world is catching up on this respect). Recent advancements have been the utilization of html/xml to design dynamic GUIs. MS has been attempting to take this approach with their active desktop, though that seems to be too much fluff. Gnome, on the other hand, is doing a good job of using XML for this purpose.
I think a generic (and more importantly open) rastering device, such as PDF along with the dynamic window modeling of XML could revolutionize graphics, if for no other reason than to simplify the process, and thereby open up GUI development to even non programmers (just look at how many web pages are maintained by clueless computer users). With the ever-growing complexity of new software, it is most important to device tools that simplify the development process which intern could attract people from other disciplines.
The apparent goals of this movement are to maintain user-privacy within a University environment and to minimize the vulnerability of the systems.
What I think they are talking about is the tightening down of services on Campuses, since they're very prone to attacks and abuses. They are encouraging campuses to instead require students to make use of POP / IMAP for mail, Instant Messengers for communication (instead of the online talk / write), of remote GUI's or client applications for access to other types of services such as databases / statistical packages.
The advantage is both the additional security of the main information servers and the alleviation of load, especially since desktops are a hell of a lot more powerful today than ever before. So much so, that the lag from a telnet window on a heavily loaded machine can be almost unbearable.
The only way this could work is if there were separate CIS / scientific networks that could still take full advantage of UNIX services like telnet. Just try taking telnet away from a CIS department and see how far you get. So long as the information contained in these extraneous networks were segmented, and contain a minimal number of accounts and services, the intention of this movement would be upheld.
From my point of view, however, removing telnet and FTP cripples the power of UNIX. First and foremost, you lose seamless remote administration, which is the main advantage over NT as far as I'm concerned. Next it'll remove familiarity of UNIX from future generations of college graduates, which in the work place would make it harder to find those with such experience; a good number of people stay in Windows as it is. I believe the main reason that a lot of people opt for Linux is because they want to have the sort of power that they're use to on campus on their own desktop. Being shielded from this technology might diminish potential future Linux devotees. It just smells too much like a windows promotion to me.
And although I am no engineer and I do not work for Intel, I can almost guarantee that both processors will give you the same performance.
Well, the PPro apparently had some odd configuration issues with 16 bit code, so it's possible that the PPro would run slower than a PII+.
Additionally, don't forget that MMX and SSE in the PII and PIII are utilized by lots of low-level drivers nowadays; so you might get noticable performance boosts.
Also, to my knowledge, there were tiny memory access tweaks added to PII+ lines. Of course, this might be moot since the majority of delay would be from the lack of cache.
I agree that there is a problem with differentiating CPU generations. I would stand behind a naming convention based on radically differing designs, such as pipelining, integrated caching, out of order execution, parallel execution ( e.g. multi-threading or even multi-processing on die ), or even the crusoe approach. From this stand-point, the Pentium would be one generation, the Pro another, the 64bit proc ( from both AMD and Intel ) would be the next while all the little evolutionary upgrades would really just be different model numbers.
There is nothing wrong with Intel naming this the Pentium I, II, III, IV, etc, because they're really just model numbers. The complete model number involves the frequency. The only real argument, as any textbook would support, is when Intel attempts to call this a 7'th or 8'th generation CPU ( which they've tried to do with their PIII line ).
I definately agree that RDRAM is not worth the money. But I know companies that shell out mega bucks on name brand server equipment because they can't afford to do any less, so it's not really an issue.
I'm not fully understanding why there is a memory size limit. I know that you can do 1, 2 and 4 channel RAMBUS configurations. I don't know if it's possible to do more ( seems likely that you should, at least in custom boards ). It would make sence to me that additional channels should be completely independant and therefore there would be no theoretical limit to the size. Thinking in terms of a SUN server where they design them from scratch, only customizing the back-plane, etc. You should be able to make a rack-based server that could have attached memory channels. This would help dessipate the heat ( by seperating them ) and if done in a sufficiently modualar and heirarchical approach, you should be able to have as much memory as you can afford ( at this point, the memory would be the least of your costs ). From what I've read ( mainly on Toms Hardware, and the like ), the timing limitiations are because each chip has to ( at boot time ) figure out the longest possible probagation path and sync itself accordingly. I believe the RDRAMS ( I can't remember from RIMMS, modules, etc ) are kind of daisy chainned, which means that the signal has to probagate through each device on a channel, and therefore the more memory chips you add ( RIMMS I believe ), the slower that channel. There's a max probagation delay that you can achieve, so depending on the setup of the memory modules, there's a max memory size that a channel can hold. I am not aware of any inter-channel dependancy, so you should be able to go as wide as necessary, though this adds incredible expense to the system. High performance systems, however, tend to spend a lot of money on the memory subsytem. I remember studying the SGI, HP and SUN setups, where you'd have many interleaved channels. It's really just a matter of what becomes the mainstream. And it looks like 1, 2 and 4 will be it ( just like 1, 2 and 4 CPU configurations ). I can't imagine that you'd have the same sort of problems with many independent channels as you would many independent CPU's. The only bandwidth you're really fighting over is the inside of the chipset, and you can cheaply splurge there( especially since your wire-count is drastically reduced ). 4 16bit RAMBUS channels shouldn't be many more wires than a single SDRAM channel. I'd be interested in learning more about the limitations though.
Onto some of your other points. The I believe that the RAMBUS guys knew that they'd have latency problems from the start ( not that you made any inference on the matter ). Intel has been working that problem for years. Their solution is making latency tolerant devices. Latency from a slow-responding memory device running at clock speed is no different than fast responding SRAM that's clocked 1/12 of your CPU on average ( since on average you'll have to wait 6 cycles before it can hear you, then you'll have to wait an additional 6 cycles before it can transmit ( even after it has a response ) ). DDR-SDRAM alleviates the problem at least, but as far as I know, it's still pipelined and therefore does not provide the best possible latency. Still, I belive it's significantly less than that of RDRAM so DDR wins this battle.
I must admit a 16bit bus could almost only justify itself if it were cheaper or easier to manufacture. You're needlessly adding delay ( albeit at 800MHZ on an 800MHZ machine, this should be negligable ). The fact that it's so many times more expensive is just an insult to everyone ( though I honestly believe this is an economy of scale, and as with my article, reaching a critical mass would mean signifcantly more affordable system ). As with the above, the real benifit is probably in the ability to multiplex many channels. 4 168pin devices, for example, would be a nightmare to multiplex.
If nothing else, the excessive heat is unbelievable. The design spends great length discussing the idle and sleep modes which are used to keep the devices from overheating!! Those sleep modes wind up causes significant latencies, especially since I've gotten the impression that a given channel can only have 1 active RIMM(?) at a time. Therefore a significantly loaded server is going to be spending almost all it's time RIMM thrashing.
Finally, in response to "do I really want RAMBUS to win". Of course not; my silver-lining was really that we _might_ get another [superior] technology to win out that would not otherwise have gotten a chance. Will RAMBUS be shoved down our throats? Of course. Will people buy into it. Well, they're already doing so ( either by ignorance, or because their particular app is well suited to RAMBUS ). Will I personally ever buy RAMBUS, or would I ever recommend a friend to do so? Not unless all other options are exhasted.. which I guess means, maybe.
Fist, and foremost. Moderation has nothing to do with agreeing with content. I therefore disaree with your supposition that I ( or comments like mine ) should not have been moderated so highly. The goal is to weed through uninteresting, or flaming remarks. If someone like myself is erroneous in my comments and it is highly marked, then someone like yourself will be able to pay attention to it and make your rebuttle. Those that see my comment will at least be given the chance to see yours as well, and all will be good. Additionaly, if I was truely incorrect, then by having someone like you find my mistake, then I would actually be given the chance to learn the err in my ways. This is called information exchange. I like this system.. It works; It has for me at least; I have been incorrect in the past about an original post or two ( meaning I would not have otherwise had the opportunity to learn ).
As a second point, I would like to thank you for not producing a flame, but instead being insightful.
With that said, I'll have to disagree with you and stick with my original comments. I do not believe that your agument holds.
First, my choice of the word speculation was not an admission of ignorance, but more a disclaimer saying that I do not have definitive evidence. Nor am I trying to prove a point based on the speculation, so it really matters little. Notice that my point was not that we're all going to be better off if RDRAM is our only choice, so long as it gets cheaper. But that, of the many ways that this situation can go, RDRAM will most likely become cheaper. Which will, in turn, help period. There is a possibility that this will backfire on RAMBUS / Intel in the creation of a nich for someone else to fulfill ( and ideally free us of memory woes ) which was the whole "shiny lining" that the article was about.
As for your comment about the "PROVEN" superiority of SDRAM. I would like to challenge you or ANYONE to verify this. I have a personal pet pieve about the word proven.. Anyone that uses it is put into a catagory in my mind; nothing in life is for certain or proven. Evidence is not proof of something, but only support of it's concept. I get tired of using the phrase, "the world was once proven to be flat because all _known_ evidence supported it".
As for SDRAM and RDRAM, I read Toms Hardware, Anandtech and Sharky Extreme. Yes, there have been benchmarks that showed SDRAM in the lead, but I have ALSO seen benchmarks by them that say the opposite. I really don't feel like digging it up, you can either take my word for it, or go research it yourself. I'm sure their articles are well marked. I'd be curious to learn of your findings. Additionally, almost all their benchmarks are on single CPU configurations, which is NOT the theoretical target of RDRAM. The stated design goals of RDRAM revolve around multiple simultaneous access; something not very well supported by existing single CPU systems. Intel's Italium is completely based on massively concurrent access. AGP is theoretically bassed around this as well ( though I do not think much aside from the failed intel 740 card ( or possibly even the i810 chipset ) makes full use of the concurrent bandwidth ( by among other things masking the latency ) ). My use of the word speculation is because I have not yet seen ANY benchmarks that test this theory. Provide a fully speced out AGP and SMP configuration then directly compare SDRAM ( and DDR for that matter ) with RDRAM, then one will be able to comment for or against my claim. I speculate primarily on the theory ( which I know can not be used as a basises for an argument, but again, that wasn't my main point in the argument ). Once again, I HAVE actually seen numbers that put RDRAM based systems ahead of others ( they were topping out the scores ). Thus, if you are paying top-dollar for a system, then I believe that your best bet at the moment is an RDRAM system.
As for DDR-SDRAM, I admit ignorance on the details. I've only read pices here and there, and don't even remember if I've seen any benchmarks on it. I do however remember that it's main call-to-fame is the double-transmittion ( rising/falling-edge transmission ) which we've come to know and love for the past two or three years. The main advancement here is NOT that they've created faster memory, but that they've learned how to transmit higher frequencies over longer distances. High freq. over the length of a motherboard will introduce lots of noise, and will drain a lot of power. By taking the same signal and getting twice as much data out of it, you're essentially getting something for nothing. A true advancement in technology. I made the comparison to ATA66 which allows maximum data-transfer rates to be un-hindered, but there is NO harddrive today that I have ever heard of that can transmit 66Meg/second continuously. This is primarily for use with cache bursts. Write 2 meg to the drive quickly, so that you can allow the second device to read. It stays in the drive's cache until it can be committed to disk at a more realistic 8 Meg / second. Upping the bandwidth allows improved latency by getting info to and from the device quicker. It works best under heavily loaded situations ( moreso in SCSI than in IDE however ). Likewise, DDR-SDRAM will allow addresses and writes to be transmitted more quickly, and thereby freeing up the bus for additional operations. However, this does not say anything about the memory's ability to sequentially process it. To my knowledge, we're still dealing with plain old, old-school memory access, though in a slightly more pipelined fashion. Concurrent access is not addressed by this technology. Theoretically, the mem-controller could rearrange memory accesses to maximize locality ( as would a SCSI controller ), but this does not garuntee throughput. RDRAM's use of independent channels can ( note: this is speculation based on the theory ) allow, under most circumstances, greater bandwidth provided critical mass of concurrent access. As we've seen, this critical mass is not zero. There are obviously situations where SDRAM _has_ outperformed RDRAM. The race, however, is closer with slower CPU speeds than with faster. And in case I somehow didn't make my point strong enough, the _theory_ only take hold after a critical mass of concurrent access is achieved. RDRAM has a massive drawback in terms of latency, so it's curve starts off with a handicap. The fact that it can outperform under extremely heavy-loads "suggests" ( here's that whole using evidence to prove, or shoud I say support a case ), that the trend should continue with ever faster machines. The theory suggests that only server-class machines ( having multiple concurrent processes ) will fully take advantage of RDRAM. This is the whole Pentium Pro argument of 32 v.s. 16 bit code. The situation back then was not well suited for 32 bit code, and they just happened to suck at 16 bit code so benchmarks could really ream the PPro. All in all, however, it was a superior architecture. The concept of RDRAM is more advanced than SDRAM ( I think this can go unquestioned ). The real question is whether the drawbacks from the more complex technology outweight the advances IN A SERVER. I highly doubt Intel will not market RDRAM for laptops or value-PCs for this very reason. I am a very theory / principle based person, so I believe that the evidence supports my case, but I can not say this with any real amount of certainty because I have not seen benchmarks that test the theory properly.
Lastly, I fully admit that my theory biases me; I am not an authority on the matter. I am reading into some benchmarks. But again, this has nothing to do with the point in my previous article.
Though this situation really eeks me, and I am appauled that Rambus can get away with this sort of patent ( though not knowing all the details, perhaps the patent has legal merit ), there might be a bright side.
Case 1: Rambus doesn't do an Apple and raise the price of licenses to shut out competition. SDRAM will remain the memory of choice for a while. Intel will deminish support for it ( more mishaps with i820, etc ) SDRAM begins to go the way of EDO. DDR-SDRAM is expensive because it doesn't have a wide support base. The rift in memory market-share allows RAMBUS to market RDRAM as server memory: low-volume, high price. Thus the consumer is faced with either cheap, yet antiquated memory or expensive memory. New memory technologies ( which have been trying to emerge ) do not get a chance because the rift in memory markets and chipset support will be hurting.
Case 2: Intel does as is currently projected. DDR-SDRAM becomes comparible to RDRAM in total value. RDRAM is going to win out, as far as I can tell. Intel is most likely only going to support RDRAM, so the market for DDR will be too small to really hit critical mass. I speculate that RDRAM is actually faster then DDR ( especially under heavy concurrent access, such as truely utilized AGP and SMP ). To my knowledge, DDR only ups the speed of the interface, the underlying technology is not significantely different than that of SDRAM ( much like ATA66 or SCSI 100). With this RDRAM will become mainstream, espeically as CPU's break the 1GHZ barrier ( more speculation on my part, based on the starvation of CPU on both memory latency and bandwidth. Of which RDRAM addresses BW. DDR mildly addresses latency ( wrt RDRAM ) and provides BW ( though only superficially ) ). In the medium run, cheaper RDRAM is going to help a lot of power-hungry people ( though probably not as much as it will hurt intro and intermediate-level system purchasers )
Case 3: RAMBUS blatently prohibitively prices DDR-SDRAM. Now SDRAM and RDRAM are the only real players for PCs. What happens here is that RDRAM production can really begin ramping up to critical mass quickly because there is less uncertainty about the future. Prices will drop quickly over time ( though no where near SDRAM prices ). This is exactly what Intel would want. Their low-cost Celeron systems are perfectly suited for 66MHZ SDRAM. If you're an intro system, why would you bother with high-perf memory. Previously the blur between 66 and 100 allowed people to over-clock the external celeron bus. Now there is a world of difference between celeron and their "workstation-class" systems which come at a significant premium. SDRAM will either become cheap or expensive in the medium run ( lower volume production might mean higher prices if demand is sufficiently high. A typical sinario would be over-stocking of ?SDRAM causes prices to plummet, which prompts massive volume reduction, which later causes prices to go through the roof ( where it will stay ) ). Thankfully I don't think SDRAM demand will tank, so it should stay relatively normal for a while. Now here is the good part. There will now be a massive rift between the expensive ( though significant less than today ) RDRAM and the SDRAM. Hard core gamers, most servers and many desk-tops are going to opt for RDRAM. Most value-PCs are going to opt for SDRAM, but those value-conscious hard-core people ( like myself ) are still going to have demand for something inbetween. And perhaps there is a better compromise between latency and BW in a newer technology ( I read memory technologies a while ago about multi-row caching via SRAM which seems an intelligent approach which is compatible with most interfaces )
Basically I'm saying that those who demand performance are going to benifit from the demise of DDR because it'll ultimately be cheaper for them. Those that are on a budget are going to see minimal increases in their low-end memory ( assuming things don't gyrate too wildly ). And those of us looking for an overall better solution might find solace in a new technology that fills this important niche.
In the long run, I think this has good consequences ( if you ignore the whole moral imperative of stifling competition, which we can't really effect here ). In the short run it doesn't really even affect me ( being an AMD person ). It is only the medium run that has issues ( I wonder if I can hold off purchasing another computer for 2 or 3 years ).
At the beginning of the article they relate things as evidence of the Saturn Theory.. A far fetched if not radical theory about a period of time in "human" history where all planets were in close proximity for an extended period of time.
Saturn Theory ( which the article references ) suggests that all the planets were in alignment in extreme proximity and in a geo-stationary northern position. I assume from this ( though they do not state it anywhere that I've read ) that gravity would be tremendously affected though in a peculiar way. The northern hemisphere would feel lighter while the southern would feel heavier. Again I haven't read this anywhere, so I'm just extrapolating.
disclaimer: I am not a lawer. I base these statements on material I have "read" and come to think are true.
That said...
Distribution of someone else's copy-righted work against their wishes is illegal. What's the difference between distributing an MP3 or MS Office 2000 over the net? Granted a lot more man hours probably went into Office 2000, but it is the artistic and creative talent ( beit good or bad ) of the artists. Though they may be altruistic ( such as free software or demo/free MP3s ), some earn a living off of it and thus can't afford to do so. ( A big record company, for example is probably not going to be able to fund itself solely through advertisements and concerts )
Additionally, if in our market, if we don't like the price or quality of something, we really should boycott them. The market can work when we're not all materialistic. Prices are enormous because our Demand is excessively high. Hell, I'm sure that they could charge a lot more and even make more money ( e.g. the Demand curve is probably pretty steep ). You can't impose regulations on prices and still be a capitalist nation. ( Salary caps in baseball, for example was a demand-side issue. It was only because of a trust between demanders of baseball ( a virtual monopsony ) that prices were checked ) I would not advocate illegal activities as a justifiable solution. ( With the exception of illegal laws ). Napster can be used in an illegal fashion, and it is indeed the responsibilty of the user to prevent using it in such an illegal fashion. I can see prosecuting individuals who violate the distribution laws ( even though I personally disagree with the prices of records and the supposed harm that MP3s cause the record industry ). Now the real controversy from my point of view are those that download or even make MP3s. If I'm using napster to download an assortment of MP3s. Some are actually legal ( though their quantity and value is questionable ). Since nobody really marks illegal MP3s as such, am I responsible if I download one? Under some circumstances, possetion is 9/10 of the law. If I don't own a metallica CD but I am found to have their entire works in MP3 form, am I in violation? I would believe this to be a violation of personal rights ( but this does impose a strong raise the same sorts of issues as drugs.. If the Demand is exceptional, Supply will find a way, no matter how drastic ). The issue of making a personal copy is where I'm specifically concerned. RIO and all those portable MP3 players are a great idea. I can have near-CD quality and convinience in a solid state-form. When used legally, it's of great value and of no harm to anyone. Of course, the legality limits us to a single copy. What does this mean, for example, if my children also get a RIO? Are they allowed to make copies off the same CD, or must I purchase 2 or 3 more CD's just as if we weren't using an MP3 player. Well, personally I find it ludicrous to have to make this purchase, especially since the limiited memory on a RIO requires me to erase it if I want to replace it with another CD. ( side: I don't own a portable MP3 player ). I'm sure the music industry would fight for those few extra dollars if they could, but really that is beyond our control. The 1-CD, 1-backup-copy idea is essential; what happens if I break, lose or wear out the CD, which often happens? Next, what happens when joe small company owner has an employee that has a massive array of hard drives ( a hundred Gig or so ) and tries to place his entire CD collection on it for his own personal enjoyment. Well, that's cool; one copy and all. But now what if he wants this same collection at work.. Well, he's willing to shell out the money to expand his workstation. Now he has two copies. Well, it stretches the law, but I would argue that it doesn't violate the spirit of the law.. Next comes the communal nature of MP3s. If I invite some friends over, we can all listen to a CD. There is no way that the MPAA is going to charge per house-hold listener. Likewise if I make a single MP3 copy from a CD and it plays off a single computer and there's a bunch of friends around I shouldn't be in any violation. But what happens when I allow coworker friends to stream audio off of my shared hard drive? They are not physically making a copy of the MP3 and thus I am not distributing it ( unless some rogue co-worker makes a copy and potentially ignorantly makes it availabe on napster ). The solution to this problem would be a sort of MP3 jukebox client/server software with a potentially encrypted data channel. Lastly, and here is the kicker. I'm having a wedding and I'm going to DJ. But I don't have a couple songs that everyone loves. So I pool my resources with several friends.. I'm "borrowing" their music for a time and publicly displaying it. This pushes the law to the limit ( since a commerical establishment can't just play records for its customers ). Is there any difference between that and all of my friends bringing me their CDs and having me encode them int MP3 and store on my publicly sharable hard drive? Each user gets his/her own directory so they are technically making their own MP3 copies and it is achnoledged as theirs; It just happens to be on a network drive. So long as nobody listens to anyone else's directory, there should be no violation of law ( especially if this is the only copy ). But it is obsurd to believe that a shared drive is not going to share its contents. Thus it should be viewed as if all are able to read each others MP3s. This is kind of like the wedding situation where a community can make use of the pooled resources. So long as nobody actually copies the MP3s to their own drive or makes a CD burn of the MP3s there is no literal violation of the law. But essentially we are providing a dynamic juke-box to all employees. The only saving argument is that the bandwidth requirements will not scale very well ( especially on an inexpensive IDE device ). Thus we're not talking about all of IBM providing a juke-box to it's employees. There are of course caveats. Namely that drives are typically tape-backuped, so if the drive were destroyed ( say because a CD was being sold and thus the license is no longer valid, or because the owner of the drive is moving ), the company could simply restore from backup ( or even take the tape home in order to copy to their home machines ).
Personally I believe that the law should allow this sort of activity, simply because there is a minimal infringement. So long as the copy of the MP3 drive is not distributed, and the owner of the drive can reproduce the individual CDs there is no evident violation. ( Thus, the same people that allowed the drive-owner to initially borrow the CDs should always be available for proof-of-license. ) A co-worker that brings the tape-backup home may not have all the contacts necesary to validate the hundreds/ thousands of CDs, and would thus be in violation. Thus a legal jukebox system would keep track of the owners of the associated CDs and for auditing purposes. Of course, I doubt the back-up system would have much justification since the "backup" is really the original CD. But it is, of course, impratical to re-encode thousands of CDs every time a drive is upgraded or otherwise replaced; Especially in a RAID configuration.
Compressed audio are a leap forward in walk-man technology: solid-state ( shock-resistent, potentially water-proof ), infinite storage potential, ease of replication for multiple audio devices ( car, walk-man, home office, work office can all have the same CD-contents without requiring carring the CD or even player ( when player is cheap enough ) ). Compressed audio is a leap forward in jukebox systems: Multiplexing literally an infinite number of songs ( at $2xx for 40Gig ) to an infinite number of users ( limited by bandwidth and server capabilities, which are rarely dedicated and thus must compete for real-work resources ).
Post-Lastly, to my knowledge you can not broadcast a song that has human voice in it without paying royalties ( hense elevator music in department stores ). Thus it would be illegal to broadcast this MP3 jukebox ( even in a legally secured/licensed fashion ) over the loud-speakers. It therefore becomes questionable at which point ( e.g. with how many users ) does a privately owned juke-box setup become considered broadcasting. 20 employees? 100 employees? To me, the very discrete nature of client/server suggests that so long as only individuals access the juke-box, it is not broadcast; We are not using multi-cast afterall; Aside from spending $50K on a ultra-RAID setup ( with redundant copies ), and multiple servers with independant ether-lines for different sections of the building.
First of all, a little professionalism would be appretiated.
Secondly, the fact still remains that there are heavy initial access delay times ( 7 cycles in PC66 SDRAM alone ). This delay is only marginally avoided by interleaving / pipelining ( unless you can produce 4 to 8 fully pipelined stages ). This is still a downside or flaw to DRAM. To my knowledge SRAM does not require independant row and column charges ( though the addressing logic may require some twiddling ).
Either way, I doubt that your nit-pick makes any difference to my main point. That you can achieve greater performance in a concurrent-access memory subsystem by going n-way ( at the cost of redundancy and expense ).
-Current IA32 CPU's and single tasking/single threaded software ( like quake ) does not present too many opportunities for multiple-concurrent memory access.
-Deeper pipelining and ever more advanced add-ons to IA32 in addition to AGP and faster DMA devices ( such as gigabit-ether and RAID drives ) would provide greater concurrent load for a memory device.
-Multi-threaded/process services such as file-serving, web serving, etc on a multi-CPU system can provide high main-memory load ( defeating virtually any caching system ) and requiring a greater need for intelligent mem-access management ( as with SCSI elevator optimizations for disk access ). Being able to service more than one mem-request simultaneously is more valuable than servicing a mem-request more quickly. You can double, or quadruple throughput easily by going to an n-way memory system instead of increasing mem-latency by 50% each generation.
-Memory Blahs: DRAM is based on leaky capacitors ( pseudo-batteries ) which must be recharged, and pre-charged in such a way that causes serious performance lag, especially when you change which row is being accessed. Thus the "rated" speed of all DRAM chips is misleading if you do not understand this. 200MHZ DDR-SDRAM is it's burst speed. Dozens of clock cycles are consumed when non-optimal adjacent memory accesses occur. This is a fundamental flaw with DRAM and is present in most architectures ( RDRAM included ). Thus, only speeding up latency can never fully resolve this problem.
-[DDR-]SDRAM is designed for high-speed dumping of closely spaced regions of memory (within a row) in a serial fashion. Higher bandwidth allows the faster flushing of internally cached hits, but there is still a severe latency between accesses. An ideal ( though costly ) advancement might be to produce multiple interleaved "channels" of [DDR-]SDRAM in order to handle multiple concurrent memory accesses. I have seen no indication of this direction in motherboard chipset manufacturers, and thus doubt it's feasibility. This solution is typically found in high-end workstations ( See SGI's visual NT station or many RISC servers )
-RDRAM is designed with the idea of multiple channels from the beginning. Sadly, it's radically different architecture means an extreme introductory price which would only decrease in higher production volumes. RDRAM did not turn out to be as glorious as would be hoped. BUT, most benchmarks I have seen deal with non-server apps in single-CPU environments. Thus scores were only marginally better.
-Intel's incentive. Tom leads us to believe that Intel is trying to make a quick buck on RDRAM. I have suggested that Intel absolutely needs an RDRAM type solution ( if not a normal interleaved solution ). Pipelining ( in both CPU and GPU ) allows the masking of memory loads ( some-what ), and thus Intel is migrating towards higher-latacey tolerant CPU's that are capable of ever increasing number of outstanding mem-requests ( which is facilitated by RDRAM and it's like ). Ultimately, Intel will move to IA64, which is completely designed around massive pre-queueing of memory accesses. Without massively parallel memory interfaces, IA64 will be even more memory starved than Alphas ( due to larger instructions ( 40 + overhead vs 32 bits/instruction ), and the heavy usage of speculative mem-loads ). I believe that IA64 will be significantly slower than IA32 unless a more advanced memory structure can be used. Additionally, I believe that IA64 will be far better suited to RDRAM than IA32 ( due to the above ). Intel NEEDS RDRAM ( or something like it ) to succeed for fear of IA64 flopping. Introducing IA32 to i820 and RDRAM is supposed to ease the market into acceptance. I doubt they care about lowering the price for IA64 ( since it'll be astronomical in and of itself ), but you need to at least encourage chip manufacturers to get the bugs out early. Rambus, on the other hand is just trying to keep their business going.. Thus they're having to give incentives out here and there ( that's just standard business ).
I think Tom is being a little emotional in saying Rambus / Intel are evil. Rambus needs customers, and Intel needs a better memory architecture.
No, Rambus is not a cost-effective solution to single IA32 CPU systems. It definately is not worth the price for single tasking systems ( such as for gaming ), though it might still work well in periferal contention situations ( 2xNIC + SCSI + RAID + CPU ). I would be curious to see RDRAM's benchmarks in IA32 mult-CPU configurations with multi-threaded / processes apps, of course.
I strongly believe that RDRAM is a good match for IA64 and possibly 4 CPU configurations ( where memory costs are not going to consist of too much of the overall package ).
Last and strongest point: Tom and many other techno-journalists, though very valuable in their insight and general contributions, are often seriously single-minded and emotional. I believe that they should spend a little more time being objective and trying to analyze the _why's_ of corporate America; looking at things from their perspective from time to time ( and actually comment about it ). You make a much stronger voice when you show an understanding of the situation, rather than preach to the choir and make ASSumptions.
Slashdot Mirror
Cute. Course, MS will make sure that none of the drivers for the latest and greatest hardware works with win 9x two years from now. Sure companies will make strives to maintain support, but it'll eventually fall off. Especially if the drivers are easier to develop under win >= 1000. Just think of all the win-modems that have minimal R&D put into them. (Not that I'd ever buy one of those)
Then, of course, as a developer for a windows market, you'd be crazy to not develop _for_ the new platform. Meaning, you're going to have to have at least some win-me machines. Then, as we typically do, once we start using the newer interface, it'll be hard to go back to the older one ( Just like win95 -> win3.1, or even win98 -> win95 ).
As a disclaimer, I'm biased towards all my OSes. (because they each give me something the others do not).
-Michael
>So instead my program runs fine then randomly crashes at the aforementioned line on code on some machines.
>Since then I have promised myself never to do any serious development in C if I can help it.
That is why you modularize your code and perform unit testing.. This sort of error will prevail in any sort of language. For a given language, there will always be problems that have complex solutions. At this point, you have to apply good programming practices and a bit of software engineering.
That a language such as Java or Pascal alleviates many types of programming errors is good, but there are just as many minuses to these languages. It's an engineering decision as to which language is best suited for a given set of problems and developers.
Personally I use Perl, but that's even more error-prone than C (with the exception of core dumps). Good coding practices are essential for this. (The benifit, of course, is rapid development time)
>Err, that's not even vaguely true.
I am going to assume that you've dealt with the perl core code, so I'm not going to debate with you. But to defend myself to others, let me say this: Scalars are a dynamic type which encompases integers ( in optimized cases ), floating point, strings and references ( which are the basis of most perl complex datatypes, including objects ). When in doubt, perl makes something a string. To my knowledge, DBI reads come in as strings ( I could do a test, but frankly I don't care enough ). Flags in the scalar object specify if it is currently in int/float/string/pointer form, and it's possible to flip flop around in most directions ( even from a pointer ). Because of this, you can always treat the scalar as a string. Hense my comment.
I think your biggest reaction had to deal with the defamation of perl sophistication, perhaps likening it onto something like COBOL, which uses pseudo-ASCII numbers ( 4 bit digits, if I recall ).
-Michael
I guess I should really qualify these things. Every other person asks me this. Yes I've used mod_perl, and I've even found better solutions ( such as FastCGI ). This was really the type of general purpose solution I was talking about. The PHP comment had to do with how quickly you get get a dynamic web site up. A Cold Fusion engine referred to a potentially higher throughput engine.
-Michael
Don't see how it's misleading since the nature of perl is to make everything a string unless otherwise specified. DBI and JDBC are similar from what I understand.
The argument isn't for a better DB interface but how to handle arbitrary data-types. A good reasoning for this is that I might not care how the database was designed. Was it a 32bit int or 64bit ( possibly 32/64 bit date stamp, etc ). Changing the database means changing the Java / C code. In Perl, I don't think I've ever had to change a line of code because I've redefined types for table columns.
This allows me to quickly get a proto-type database up ( possibly with all text fields ), then later optimize the row lengths. More importantly, if the DBA needs to lengthen a VARCHAR, he can do so without risk of affecting the perl code. The only issue that should ever come up is the formatting of the resultant HTML.
Arguably, you could create a Java DB interface that returned everything as a pointer to type "Object", then use to_string for display purposes. I think that we'd all agree, however, that this would be undermining Java and bad programming practice.
Hehe.. Isn't this why all database fields should be declared as text? Laugh.. All kidding aside. I've rarely ever had fields in a DB that perl cared about. It was almost always a medium to read from a CGI form and write to a DB ( validating fields there ) or reading from the DB and displaying on the screen. I'm sure there are cases that the information is more sensative, but I've never encountered one.
Another point of view is that because strings are so versitle in perl. It wouldn't matter if you read it in as a string, float or int, since it could easily internally type-cast to the appropriate type when used. The worst that would happen is that you'd convert a string to a zero, which should signal a warning somewhere.
As for initialization.. YOU MAKE BAD PERL JUJU, since you obviously don't use -w. If you did, then you'd know that it's impossible to use a variable without first initializing it. Perl allows you to make the command line -e '...' without any type checking, but allows you to be anal man with -w and "use strict". Trust me, when I started using -w, I'd get really pissy because I loved the default case of undef becomming an empty string. Now I have to
$str ||= "";
everything that I know is printable even when null.
-May you do good things with Perl
Theoretically, you could link to the perl reg-ex library. You could also use it's kick-ass memory manager ( due to double indirection ) to help prevent massive memory cluttering due to allocs and frees for all the tiny strings. But at that point, you'd be using perl. And what's the point, since it's quicker to code and debug a perl program than a C one. Dynamic systems, such as web pages require a development environment with a fast turn-around time.
My point is that perl had a nich back in it's day, and that way string parsing. It's libraries were optimized to do so. Many of the types of optimizations ( such as self modifying code, in the case of variable substitutions for reg-ex's or even the eval '' statement ) are hard to do in a low level language. Not that it isn't possible, but just that to do so would take an enormous amount development effort, which doesn't fit into the web-model.
Perl isn't really the best web-model for most situations either. A heavily loaded web site would be better used by a massive C-engine with customizable pages. Or a PHP/ASP setup might get pages out the door faster ( especially with new developers ). But Perl is a very good general purpose tool for text processing ( as well as other fields ).
Actually, Perl 5.005 allows typed variables. I tried designing with it, and it really gets combersome.
# Class A; Class B inherits Class A
my A $obj1 = new B;
my B $obj2 = $obj1;
I liked it because of the supposed optimization of the pseudo hashes, but I found myself typing 3 times as much to do incredibly simple tasks. Personally I like building OO libraries ( makes my work easier down the road ), but the "bolted on" perl OO model takes a lot more work when an attempt is made to be clean and concise, which you need to do every now and again.
That said, I definately agree with you about how powerful perl is when it comes to data manipulation such as in databases. I can throw together a complete CGI/DBI web site in minutes, for prototyping, then go back later and structure all the function calls when there's time.
-Michael
Most likely there will be pragmas that turn on the new syntax.
For example.. The new regular expression package can only be used by typing
use re;
Most likely there will be a requirement to say
use 6.0;
To make sure of the new engine. The older engine will probably be linked out for use in compatibility scripts. For example. the use of '&' in a reg ex makes the entire perl engine react differently; Likewise, finding a module that makes use of the new syntax would affect which interpreter / library is loaded in memory.
I hope that they find a clean way of doing this. A rewrite really should not feel like bolted on code.
It isn't really that VB is to blame, or even that OE has a bad security model ( though that does contribute ). It's that Users are allowed to execute foreign code. It wouldn't matter if IE had a really good security model, and the viruses were written in assembly. So long as the User could activate foreign code that could get to local resources, the virus could probagate.
.rhost files so that we could have our desktop icons rexec to the proper user names... thereby leaving the Xserver account as a dangerous point of virus-infestation.
The simplest security measure is to not run untrusted code. The next level is to have an isolated environment in which the code can run ( a la protected login accounts in UNIX, and to a tiny degree; in NT ). The next level would be to limit the resources that trusted code can access ( e.g. Java security box, or tainted mode in perl, etc, but more directly, preventing access to OE material ).
The fact that VB or VP are scripting languages is really irrelevant. The only time that it is a serious issue is when you can pass code as a parameter; unchecked parameters can break out as new compiled code and do virtually anything that the interpreter will let them ( which typically includes access to files and the internet ). But a good programmer runs tainted mode, etc. Thus, scripting languages are merely more suseptible to bad programming. A common error would be inserting data into a database through a web form. I could close off the SQL statement, put a semi-colon, then begin a new SQL query which could create a new account ( assuming I knew enough about the target database ).. So on and so forth.
I agree that the addition of too many powerful widget APIs opens up a user for security risks. But so long as we don't give important access to users, we should be fine at level 2. In fact, if you were really paranoid about such things, you could create an account for all your important activities. Your development could be done as a seperate user, your financial data would definately run as a seperate user, your browser would probably be it's own user ( since it's the most suseptible to attacks ), etc. This of course, assumes that you have a box at home where you can create an unlimited number of accounts. Course, most of us are too lazy; We'd probably set up
Essentially, a good security model would have a permission tree. User can login. Login users can start X. X-users can spawn netscape. Netscape users can run a limited set of programs ( such as Java ). Course, you'd have to make heavy use of group execute permissiosn, and major apps, like netscape java, etc could not be world executable. Therefore, I believe it's definately possible to secure Linux against API attacks, but it's definately not convenient.
All of this security would be necessary if the API is to be opened up so widely. But, I am much more afraid of another daunting issue; That of stability. Windows is unstable, in part, because there are so many interfaces that there are too many resource dependancies. A component can open up a resource channel, then fail.. The the resource could block indefinately, thereby tying up other components. I believe that UNIX does a good job of releasing a resource when a process fails; the idea that a process should be completely killable. However, with a GUI, it's entirely possible that a connection is so complex that programmers will get lazy and not take care of failed connections at random points.
The only solution to this latter matter is one of foundation building. Meaning, always building application components on top of concrete models that take care of all conditions. This has both the advantages of preventing the developer from making stupid mistakes, and the reduction in code for each component.
-Michael
The article says that they were part of an open standards group named JEDEC. They secretly produced several patents that partained to the results of the standards group. They then pulled out of JEDEC and pursued their own interests. It's entirely possible that they in fact stole basic ideas from the group and patented them on their own.
The real issue, however, is that this article suggests that the patents were on technology that was pre-existent, and therefore the patent was improperly issued. The defence is one of "prior art", though I'm not really familiar with the topic.
Well, Why 3D was the original reason for my post. Perhaps I should have emphasized the "Not".
My argument is that 3d "should" be able to give you more functionality / access to information _because_ of the additional depth. Yes, there is the prospect of visual overload. But we _live_ in a 3D world, and we've learned how to take advantage of it. As for navigation and losing material, that's where translucense comes in handy. I just keep thinking of all the 3D video games that I play, and how much more functional their interfaces are than standard 2D ones. Homeworld, for example allows a very nifty 3D rotational map with effective zooming in and out. Grouping things into spherical shells is very efficient, and doesn't provide information overload as quickly as a 2D representation.
For example, take the icons on the desktop. Sure they can get overbearing. I can't have more than 10 on my desktop or I just ignore them (if it takes me more than 3 seconds to find something, it's not functional). You can get around this by putting things on different regions of the desktop; I use the Start menu for some things, the quick-launch bar for others, and the desktop for still others.. I've trained my mind on where to find these things. This is how we work in real life. We quickly get overloaded when there isn't enough unique sensation to identify objects in our mind. By finding objects in unique settings, we better remember them (supposedly that's how you remember people's names.. though I've never fully figured that one out). Having a 3D GUI could allow you to have a hell of a lot more ready information at your finger tips while at the same time REDUCING information overload.
Here is a plausible example. Let's take my MP3 drive. It has nearly 20 Gig of stuff on it right (all legal by the way). Finding stuff is a bitch. My solutions have been to A) produce sym-linked directories for the many types of catagories: personal favorits, genres, and authors. B) Produce a database which fetches path/file names based on query info. The second solution doesn't work very well with play-lists (except in generating text-files). A 3D interface could show me each and every MP3, including information about them. I could navigate a 3D neural-network-like interface where at each node there was associated information. You could not possibly fit all of this into a 2D screen, but in 3D, you could zoom in and out (while having only more important information visible while zoomed out); you could trace associations from one title or author to the next, etc. Granted this sound like a rather complex task... And for a simple MP3 database it would be. But image your entire filesystem if it were handled this way (or at least viewed this way).
The first thought that comes to mind is Jurrassic park in the little girls famous quote "It's a UNIX system". Course that interface was terribly impractical. If you knew the command-line name and it's arguments, that would have been incredibly faster. But I think part of the point here is to evolve the GUI into something that is more intuitive than a command line, and yet can provide more information than a 2D GUI, and ideally be as intuitive as real life.
All I'm saying is that I prefer 3D video games to 2D video games, and there is no reason to believe that we can't make 3D GUIs that are just as desirable. Maybe First Person isn't the answer, but it's short sighted or uninformed to only comment on them.
As for the wasted CPU cycles, seeing as how most of this is offloaded to the graphics hardware, I don't see how they're wasted.. Buying a $400 video card and only using it 5% of the time (when you're playing games) seems like more of a waste to me. Also, if done properly, a 3D interface could consume less memory. Wireframe, for example, consumes considerably less memory than layers apon layers of bitmaps. Granted, MIP-Mapped textures, lighting maps and environment maps take up a hell of a lot more memory.
-Michael
Expanding on this, doesn't planting consume the nutrients of the soil.. INAF (I'm not a farmer), but don't farmers have to replenish all the nutrients periodically (sometimes by planting crops that they till into the soil). The more energy you could acquire from a crop, the more greedy it will be from the soil (like Tabacco).
Basically you'd be trading environmental friendliness with starvation of our farmlands.
-Michael
My sentiments (though a little too sarcastically). The only reason that anyone would colonize the moon would be for some serious profit. The only reason Europeans ventured across the Atlantic was to find a cheaper way to get to India. I seriously doubt that we could do anything cheaper on the moon than we could on Earth.
I find it funny that we geeks, who are so fond of Sci-Fi, are so quick to assume the future. Sure space exploration/navigation was monumental, but it failed quickly as the driving forces dried up. Personally I have little faith that we'll have any manned mars missions any time soon. The "Because it's there" attitude is getting harder to swallow when you look at the ever increasing price tags. The lunar-landings were not even such an argument; they were instead, an international pissing contest.
The only thing that makes sense about main article is that if we "were" to colonize the moon a hundred years from now, then we'd have a potential source of energy (assuming we ever prove fusion to be reliable).
Perhaps I'm naive here, but I don't see why you dismiss 3D as a GUI. You imply that serious graphics hardware is really necessary for 3D, but anymore, 3D support is standard, especially in the optimized forms such as Glide and Direct3D (I know, I'm a heretic for not promoting GL instead of these proprietary standards).
In playing with Silicon Graphics machines I was not overly impressed with their GUI design. It had only a few tiny improvements, such as enhanced graphical directory navigation at the command prompt and the scaling of just about everything. Anymore, the prompt is being phased out. Hell, even in Linux, the "task-bar" is replacing more and more everyday command-prompt operations with mindless point and click. And forget about the prompt in windows. Also it wasn't too long ago that DirectDraw allowed graphics scaling on the windows platform.
I've seen a couple interesting concepts utilizing 3D. The most profound (for me at least) was the perspective view. Namely for those of you, like me, that have window-itis (never less than 10 windows open at a time), only those windows in central view are fully sized and detailed, surrounding windows are visible though compressed / distorted (the actual method I think was to provide a geometrical box which you were looking into.. All non-selected windows were on the periphery of the box and thereby taking up less space).
Perhaps you are thinking more along the lines of the movie Disclosure where you make use of a virtual reality helm and gloves. Computationally, VR is no different than standard 3D games (first person with multiple complex input devices). The only real complexity with the Disclosure model was the voice interface (which required AI), and possibly the scanning device that renders your avatar.
VRML could have been the next big GUI, but it seems to have failed miserably, probably because it never found it's killer app. Theoretically we could have all mimicked our working environment, and then applied various database queries around certain triggers, and you could have achieved a low-res version of Disclosure.
I think Apple's integration of PDF into their GUI is definitely a step in the right direction, though as you said, it's nothing new (NextStep had postscript built-in in a similar fashion). Unfortunately that's really only for show, and doesn't really provide too much additional functionality.
Hell, the whole concept of the task bar is a remarkable advancement in my opinion. Anything that allows me to seamlessly manage multiple services on my computer (or to blend them into one big service) is advancement in the science. Additionally the treed directories that expand and collapse on command (with the ability to perform operations on the tree as if you were at a command prompt) is functional (though it has been around for well over a decade even in the DOS world a la Xtree Gold, etc). Intelligent Drag and Drop has been an essential addition to the GUI world (thankfully even the UNIX world is catching up on this respect). Recent advancements have been the utilization of html/xml to design dynamic GUIs. MS has been attempting to take this approach with their active desktop, though that seems to be too much fluff. Gnome, on the other hand, is doing a good job of using XML for this purpose.
I think a generic (and more importantly open) rastering device, such as PDF along with the dynamic window modeling of XML could revolutionize graphics, if for no other reason than to simplify the process, and thereby open up GUI development to even non programmers (just look at how many web pages are maintained by clueless computer users). With the ever-growing complexity of new software, it is most important to device tools that simplify the development process which intern could attract people from other disciplines.
The apparent goals of this movement are to maintain user-privacy within a University environment and to minimize the vulnerability of the systems.
What I think they are talking about is the tightening down of services on Campuses, since they're very prone to attacks and abuses. They are encouraging campuses to instead require students to make use of POP / IMAP for mail, Instant Messengers for communication (instead of the online talk / write), of remote GUI's or client applications for access to other types of services such as databases / statistical packages.
The advantage is both the additional security of the main information servers and the alleviation of load, especially since desktops are a hell of a lot more powerful today than ever before. So much so, that the lag from a telnet window on a heavily loaded machine can be almost unbearable.
The only way this could work is if there were separate CIS / scientific networks that could still take full advantage of UNIX services like telnet. Just try taking telnet away from a CIS department and see how far you get. So long as the information contained in these extraneous networks were segmented, and contain a minimal number of accounts and services, the intention of this movement would be upheld.
From my point of view, however, removing telnet and FTP cripples the power of UNIX. First and foremost, you lose seamless remote administration, which is the main advantage over NT as far as I'm concerned. Next it'll remove familiarity of UNIX from future generations of college graduates, which in the work place would make it harder to find those with such experience; a good number of people stay in Windows as it is. I believe the main reason that a lot of people opt for Linux is because they want to have the sort of power that they're use to on campus on their own desktop. Being shielded from this technology might diminish potential future Linux devotees. It just smells too much like a windows promotion to me.
Well, the PPro apparently had some odd configuration issues with 16 bit code, so it's possible that the PPro would run slower than a PII+.
Additionally, don't forget that MMX and SSE in the PII and PIII are utilized by lots of low-level drivers nowadays; so you might get noticable performance boosts.
Also, to my knowledge, there were tiny memory access tweaks added to PII+ lines. Of course, this might be moot since the majority of delay would be from the lack of cache.
I agree that there is a problem with differentiating CPU generations. I would stand behind a naming convention based on radically differing designs, such as pipelining, integrated caching, out of order execution, parallel execution ( e.g. multi-threading or even multi-processing on die ), or even the crusoe approach. From this stand-point, the Pentium would be one generation, the Pro another, the 64bit proc ( from both AMD and Intel ) would be the next while all the little evolutionary upgrades would really just be different model numbers.
There is nothing wrong with Intel naming this the Pentium I, II, III, IV, etc, because they're really just model numbers. The complete model number involves the frequency. The only real argument, as any textbook would support, is when Intel attempts to call this a 7'th or 8'th generation CPU ( which they've tried to do with their PIII line ).
I definately agree that RDRAM is not worth the money. But I know companies that shell out mega bucks on name brand server equipment because they can't afford to do any less, so it's not really an issue.
I'm not fully understanding why there is a memory size limit. I know that you can do 1, 2 and 4 channel RAMBUS configurations. I don't know if it's possible to do more ( seems likely that you should, at least in custom boards ). It would make sence to me that additional channels should be completely independant and therefore there would be no theoretical limit to the size. Thinking in terms of a SUN server where they design them from scratch, only customizing the back-plane, etc. You should be able to make a rack-based server that could have attached memory channels. This would help dessipate the heat ( by seperating them ) and if done in a sufficiently modualar and heirarchical approach, you should be able to have as much memory as you can afford ( at this point, the memory would be the least of your costs ). From what I've read ( mainly on Toms Hardware, and the like ), the timing limitiations are because each chip has to ( at boot time ) figure out the longest possible probagation path and sync itself accordingly. I believe the RDRAMS ( I can't remember from RIMMS, modules, etc ) are kind of daisy chainned, which means that the signal has to probagate through each device on a channel, and therefore the more memory chips you add ( RIMMS I believe ), the slower that channel. There's a max probagation delay that you can achieve, so depending on the setup of the memory modules, there's a max memory size that a channel can hold. I am not aware of any inter-channel dependancy, so you should be able to go as wide as necessary, though this adds incredible expense to the system.
High performance systems, however, tend to spend a lot of money on the memory subsytem. I remember studying the SGI, HP and SUN setups, where you'd have many interleaved channels. It's really just a matter of what becomes the mainstream. And it looks like 1, 2 and 4 will be it ( just like 1, 2 and 4 CPU configurations ). I can't imagine that you'd have the same sort of problems with many independent channels as you would many independent CPU's. The only bandwidth you're really fighting over is the inside of the chipset, and you can cheaply splurge there( especially since your wire-count is drastically reduced ). 4 16bit RAMBUS channels shouldn't be many more wires than a single SDRAM channel. I'd be interested in learning more about the limitations though.
Onto some of your other points. The I believe that the RAMBUS guys knew that they'd have latency problems from the start ( not that you made any inference on the matter ). Intel has been working that problem for years. Their solution is making latency tolerant devices. Latency from a slow-responding memory device running at clock speed is no different than fast responding SRAM that's clocked 1/12 of your CPU on average ( since on average you'll have to wait 6 cycles before it can hear you, then you'll have to wait an additional 6 cycles before it can transmit ( even after it has a response ) ). DDR-SDRAM alleviates the problem at least, but as far as I know, it's still pipelined and therefore does not provide the best possible latency. Still, I belive it's significantly less than that of RDRAM so DDR wins this battle.
I must admit a 16bit bus could almost only justify itself if it were cheaper or easier to manufacture. You're needlessly adding delay ( albeit at 800MHZ on an 800MHZ machine, this should be negligable ). The fact that it's so many times more expensive is just an insult to everyone ( though I honestly believe this is an economy of scale, and as with my article, reaching a critical mass would mean signifcantly more affordable system ). As with the above, the real benifit is probably in the ability to multiplex many channels. 4 168pin devices, for example, would be a nightmare to multiplex.
If nothing else, the excessive heat is unbelievable. The design spends great length discussing the idle and sleep modes which are used to keep the devices from overheating!! Those sleep modes wind up causes significant latencies, especially since I've gotten the impression that a given channel can only have 1 active RIMM(?) at a time. Therefore a significantly loaded server is going to be spending almost all it's time RIMM thrashing.
Finally, in response to "do I really want RAMBUS to win". Of course not; my silver-lining was really that we _might_ get another [superior] technology to win out that would not otherwise have gotten a chance. Will RAMBUS be shoved down our throats? Of course. Will people buy into it. Well, they're already doing so ( either by ignorance, or because their particular app is well suited to RAMBUS ). Will I personally ever buy RAMBUS, or would I ever recommend a friend to do so? Not unless all other options are exhasted.. which I guess means, maybe.
-Michael
Fist, and foremost. Moderation has nothing to do with agreeing with content. I therefore disaree with your supposition that I ( or comments like mine ) should not have been moderated so highly. The goal is to weed through uninteresting, or flaming remarks. If someone like myself is erroneous in my comments and it is highly marked, then someone like yourself will be able to pay attention to it and make your rebuttle. Those that see my comment will at least be given the chance to see yours as well, and all will be good. Additionaly, if I was truely incorrect, then by having someone like you find my mistake, then I would actually be given the chance to learn the err in my ways. This is called information exchange. I like this system.. It works; It has for me at least; I have been incorrect in the past about an original post or two ( meaning I would not have otherwise had the opportunity to learn ).
As a second point, I would like to thank you for not producing a flame, but instead being insightful.
With that said, I'll have to disagree with you and stick with my original comments. I do not believe that your agument holds.
First, my choice of the word speculation was not an admission of ignorance, but more a disclaimer saying that I do not have definitive evidence. Nor am I trying to prove a point based on the speculation, so it really matters little. Notice that my point was not that we're all going to be better off if RDRAM is our only choice, so long as it gets cheaper. But that, of the many ways that this situation can go, RDRAM will most likely become cheaper. Which will, in turn, help period. There is a possibility that this will backfire on RAMBUS / Intel in the creation of a nich for someone else to fulfill ( and ideally free us of memory woes ) which was the whole "shiny lining" that the article was about.
As for your comment about the "PROVEN" superiority of SDRAM. I would like to challenge you or ANYONE to verify this. I have a personal pet pieve about the word proven.. Anyone that uses it is put into a catagory in my mind; nothing in life is for certain or proven. Evidence is not proof of something, but only support of it's concept. I get tired of using the phrase, "the world was once proven to be flat because all _known_ evidence supported it".
As for SDRAM and RDRAM, I read Toms Hardware, Anandtech and Sharky Extreme. Yes, there have been benchmarks that showed SDRAM in the lead, but I have ALSO seen benchmarks by them that say the opposite. I really don't feel like digging it up, you can either take my word for it, or go research it yourself. I'm sure their articles are well marked. I'd be curious to learn of your findings. Additionally, almost all their benchmarks are on single CPU configurations, which is NOT the theoretical target of RDRAM. The stated design goals of RDRAM revolve around multiple simultaneous access; something not very well supported by existing single CPU systems. Intel's Italium is completely based on massively concurrent access. AGP is theoretically bassed around this as well ( though I do not think much aside from the failed intel 740 card ( or possibly even the i810 chipset ) makes full use of the concurrent bandwidth ( by among other things masking the latency ) ). My use of the word speculation is because I have not yet seen ANY benchmarks that test this theory. Provide a fully speced out AGP and SMP configuration then directly compare SDRAM ( and DDR for that matter ) with RDRAM, then one will be able to comment for or against my claim. I speculate primarily on the theory ( which I know can not be used as a basises for an argument, but again, that wasn't my main point in the argument ). Once again, I HAVE actually seen numbers that put RDRAM based systems ahead of others ( they were topping out the scores ). Thus, if you are paying top-dollar for a system, then I believe that your best bet at the moment is an RDRAM system.
As for DDR-SDRAM, I admit ignorance on the details. I've only read pices here and there, and don't even remember if I've seen any benchmarks on it. I do however remember that it's main call-to-fame is the double-transmittion ( rising/falling-edge transmission ) which we've come to know and love for the past two or three years. The main advancement here is NOT that they've created faster memory, but that they've learned how to transmit higher frequencies over longer distances. High freq. over the length of a motherboard will introduce lots of noise, and will drain a lot of power. By taking the same signal and getting twice as much data out of it, you're essentially getting something for nothing. A true advancement in technology. I made the comparison to ATA66 which allows maximum data-transfer rates to be un-hindered, but there is NO harddrive today that I have ever heard of that can transmit 66Meg/second continuously. This is primarily for use with cache bursts. Write 2 meg to the drive quickly, so that you can allow the second device to read. It stays in the drive's cache until it can be committed to disk at a more realistic 8 Meg / second. Upping the bandwidth allows improved latency by getting info to and from the device quicker. It works best under heavily loaded situations ( moreso in SCSI than in IDE however ). Likewise, DDR-SDRAM will allow addresses and writes to be transmitted more quickly, and thereby freeing up the bus for additional operations. However, this does not say anything about the memory's ability to sequentially process it. To my knowledge, we're still dealing with plain old, old-school memory access, though in a slightly more pipelined fashion. Concurrent access is not addressed by this technology. Theoretically, the mem-controller could rearrange memory accesses to maximize locality ( as would a SCSI controller ), but this does not garuntee throughput. RDRAM's use of independent channels can ( note: this is speculation based on the theory ) allow, under most circumstances, greater bandwidth provided critical mass of concurrent access. As we've seen, this critical mass is not zero. There are obviously situations where SDRAM _has_ outperformed RDRAM. The race, however, is closer with slower CPU speeds than with faster. And in case I somehow didn't make my point strong enough, the _theory_ only take hold after a critical mass of concurrent access is achieved. RDRAM has a massive drawback in terms of latency, so it's curve starts off with a handicap. The fact that it can outperform under extremely heavy-loads "suggests" ( here's that whole using evidence to prove, or shoud I say support a case ), that the trend should continue with ever faster machines.
The theory suggests that only server-class machines ( having multiple concurrent processes ) will fully take advantage of RDRAM. This is the whole Pentium Pro argument of 32 v.s. 16 bit code. The situation back then was not well suited for 32 bit code, and they just happened to suck at 16 bit code so benchmarks could really ream the PPro. All in all, however, it was a superior architecture. The concept of RDRAM is more advanced than SDRAM ( I think this can go unquestioned ). The real question is whether the drawbacks from the more complex technology outweight the advances IN A SERVER. I highly doubt Intel will not market RDRAM for laptops or value-PCs for this very reason. I am a very theory / principle based person, so I believe that the evidence supports my case, but I can not say this with any real amount of certainty because I have not seen benchmarks that test the theory properly.
Lastly, I fully admit that my theory biases me; I am not an authority on the matter. I am reading into some benchmarks. But again, this has nothing to do with the point in my previous article.
Though this situation really eeks me, and I am appauled that Rambus can get away with this sort of patent ( though not knowing all the details, perhaps the patent has legal merit ), there might be a bright side.
Case 1: Rambus doesn't do an Apple and raise the price of licenses to shut out competition. SDRAM will remain the memory of choice for a while. Intel will deminish support for it ( more mishaps with i820, etc ) SDRAM begins to go the way of EDO. DDR-SDRAM is expensive because it doesn't have a wide support base. The rift in memory market-share allows RAMBUS to market RDRAM as server memory: low-volume, high price. Thus the consumer is faced with either cheap, yet antiquated memory or expensive memory. New memory technologies ( which have been trying to emerge ) do not get a chance because the rift in memory markets and chipset support will be hurting.
Case 2: Intel does as is currently projected. DDR-SDRAM becomes comparible to RDRAM in total value. RDRAM is going to win out, as far as I can tell. Intel is most likely only going to support RDRAM, so the market for DDR will be too small to really hit critical mass. I speculate that RDRAM is actually faster then DDR ( especially under heavy concurrent access, such as truely utilized AGP and SMP ). To my knowledge, DDR only ups the speed of the interface, the underlying technology is not significantely different than that of SDRAM ( much like ATA66 or SCSI 100). With this RDRAM will become mainstream, espeically as CPU's break the 1GHZ barrier ( more speculation on my part, based on the starvation of CPU on both memory latency and bandwidth. Of which RDRAM addresses BW. DDR mildly addresses latency ( wrt RDRAM ) and provides BW ( though only superficially ) ). In the medium run, cheaper RDRAM is going to help a lot of power-hungry people ( though probably not as much as it will hurt intro and intermediate-level system purchasers )
Case 3: RAMBUS blatently prohibitively prices DDR-SDRAM. Now SDRAM and RDRAM are the only real players for PCs. What happens here is that RDRAM production can really begin ramping up to critical mass quickly because there is less uncertainty about the future. Prices will drop quickly over time ( though no where near SDRAM prices ). This is exactly what Intel would want. Their low-cost Celeron systems are perfectly suited for 66MHZ SDRAM. If you're an intro system, why would you bother with high-perf memory. Previously the blur between 66 and 100 allowed people to over-clock the external celeron bus. Now there is a world of difference between celeron and their "workstation-class" systems which come at a significant premium. SDRAM will either become cheap or expensive in the medium run ( lower volume production might mean higher prices if demand is sufficiently high. A typical sinario would be over-stocking of ?SDRAM causes prices to plummet, which prompts massive volume reduction, which later causes prices to go through the roof ( where it will stay ) ). Thankfully I don't think SDRAM demand will tank, so it should stay relatively normal for a while. Now here is the good part. There will now be a massive rift between the expensive ( though significant less than today ) RDRAM and the SDRAM. Hard core gamers, most servers and many desk-tops are going to opt for RDRAM. Most value-PCs are going to opt for SDRAM, but those value-conscious hard-core people ( like myself ) are still going to have demand for something inbetween. And perhaps there is a better compromise between latency and BW in a newer technology ( I read memory technologies a while ago about multi-row caching via SRAM which seems an intelligent approach which is compatible with most interfaces )
Basically I'm saying that those who demand performance are going to benifit from the demise of DDR because it'll ultimately be cheaper for them. Those that are on a budget are going to see minimal increases in their low-end memory ( assuming things don't gyrate too wildly ). And those of us looking for an overall better solution might find solace in a new technology that fills this important niche.
In the long run, I think this has good consequences ( if you ignore the whole moral imperative of stifling competition, which we can't really effect here ). In the short run it doesn't really even affect me ( being an AMD person ). It is only the medium run that has issues ( I wonder if I can hold off purchasing another computer for 2 or 3 years ).
-Michael
At the beginning of the article they relate things as evidence of the Saturn Theory.. A far fetched if not radical theory about a period of time in "human" history where all planets were in close proximity for an extended period of time.
Saturn Theory ( which the article references ) suggests that all the planets were in alignment in extreme proximity and in a geo-stationary northern position. I assume from this ( though they do not state it anywhere that I've read ) that gravity would be tremendously affected though in a peculiar way. The northern hemisphere would feel lighter while the southern would feel heavier. Again I haven't read this anywhere, so I'm just extrapolating.
disclaimer: I am not a lawer.
I base these statements on material I have "read" and come to think are true.
That said...
Distribution of someone else's copy-righted work against their wishes is illegal. What's the difference between distributing an MP3 or MS Office 2000 over the net? Granted a lot more man hours probably went into Office 2000, but it is the artistic and creative talent ( beit good or bad ) of the artists. Though they may be altruistic ( such as free software or demo/free MP3s ), some earn a living off of it and thus can't afford to do so. ( A big record company, for example is probably not going to be able to fund itself solely through advertisements and concerts )
Additionally, if in our market, if we don't like the price or quality of something, we really should boycott them. The market can work when we're not all materialistic. Prices are enormous because our Demand is excessively high. Hell, I'm sure that they could charge a lot more and even make more money ( e.g. the Demand curve is probably pretty steep ). You can't impose regulations on prices and still be a capitalist nation. ( Salary caps in baseball, for example was a demand-side issue. It was only because of a trust between demanders of baseball ( a virtual monopsony ) that prices were checked )
I would not advocate illegal activities as a justifiable solution. ( With the exception of illegal laws ). Napster can be used in an illegal fashion, and it is indeed the responsibilty of the user to prevent using it in such an illegal fashion. I can see prosecuting individuals who violate the distribution laws ( even though I personally disagree with the prices of records and the supposed harm that MP3s cause the record industry ).
Now the real controversy from my point of view are those that download or even make MP3s. If I'm using napster to download an assortment of MP3s. Some are actually legal ( though their quantity and value is questionable ). Since nobody really marks illegal MP3s as such, am I responsible if I download one? Under some circumstances, possetion is 9/10 of the law. If I don't own a metallica CD but I am found to have their entire works in MP3 form, am I in violation? I would believe this to be a violation of personal rights ( but this does impose a strong raise the same sorts of issues as drugs.. If the Demand is exceptional, Supply will find a way, no matter how drastic ).
The issue of making a personal copy is where I'm specifically concerned. RIO and all those portable MP3 players are a great idea. I can have near-CD quality and convinience in a solid state-form. When used legally, it's of great value and of no harm to anyone. Of course, the legality limits us to a single copy. What does this mean, for example, if my children also get a RIO? Are they allowed to make copies off the same CD, or must I purchase 2 or 3 more CD's just as if we weren't using an MP3 player. Well, personally I find it ludicrous to have to make this purchase, especially since the limiited memory on a RIO requires me to erase it if I want to replace it with another CD. ( side: I don't own a portable MP3 player ). I'm sure the music industry would fight for those few extra dollars if they could, but really that is beyond our control. The 1-CD, 1-backup-copy idea is essential; what happens if I break, lose or wear out the CD, which often happens?
Next, what happens when joe small company owner has an employee that has a massive array of hard drives ( a hundred Gig or so ) and tries to place his entire CD collection on it for his own personal enjoyment. Well, that's cool; one copy and all. But now what if he wants this same collection at work.. Well, he's willing to shell out the money to expand his workstation. Now he has two copies. Well, it stretches the law, but I would argue that it doesn't violate the spirit of the law..
Next comes the communal nature of MP3s. If I invite some friends over, we can all listen to a CD. There is no way that the MPAA is going to charge per house-hold listener. Likewise if I make a single MP3 copy from a CD and it plays off a single computer and there's a bunch of friends around I shouldn't be in any violation. But what happens when I allow coworker friends to stream audio off of my shared hard drive? They are not physically making a copy of the MP3 and thus I am not distributing it ( unless some rogue co-worker makes a copy and potentially ignorantly makes it availabe on napster ). The solution to this problem would be a sort of MP3 jukebox client/server software with a potentially encrypted data channel.
Lastly, and here is the kicker. I'm having a wedding and I'm going to DJ. But I don't have a couple songs that everyone loves. So I pool my resources with several friends.. I'm "borrowing" their music for a time and publicly displaying it. This pushes the law to the limit ( since a commerical establishment can't just play records for its customers ). Is there any difference between that and all of my friends bringing me their CDs and having me encode them int MP3 and store on my publicly sharable hard drive? Each user gets his/her own directory so they are technically making their own MP3 copies and it is achnoledged as theirs; It just happens to be on a network drive. So long as nobody listens to anyone else's directory, there should be no violation of law ( especially if this is the only copy ). But it is obsurd to believe that a shared drive is not going to share its contents. Thus it should be viewed as if all are able to read each others MP3s. This is kind of like the wedding situation where a community can make use of the pooled resources. So long as nobody actually copies the MP3s to their own drive or makes a CD burn of the MP3s there is no literal violation of the law. But essentially we are providing a dynamic juke-box to all employees. The only saving argument is that the bandwidth requirements will not scale very well ( especially on an inexpensive IDE device ). Thus we're not talking about all of IBM providing a juke-box to it's employees. There are of course caveats. Namely that drives are typically tape-backuped, so if the drive were destroyed ( say because a CD was being sold and thus the license is no longer valid, or because the owner of the drive is moving ), the company could simply restore from backup ( or even take the tape home in order to copy to their home machines ).
Personally I believe that the law should allow this sort of activity, simply because there is a minimal infringement. So long as the copy of the MP3 drive is not distributed, and the owner of the drive can reproduce the individual CDs there is no evident violation. ( Thus, the same people that allowed the drive-owner to initially borrow the CDs should always be available for proof-of-license. ) A co-worker that brings the tape-backup home may not have all the contacts necesary to validate the hundreds/ thousands of CDs, and would thus be in violation. Thus a legal jukebox system would keep track of the owners of the associated CDs and for auditing purposes. Of course, I doubt the back-up system would have much justification since the "backup" is really the original CD. But it is, of course, impratical to re-encode thousands of CDs every time a drive is upgraded or otherwise replaced; Especially in a RAID configuration.
Compressed audio are a leap forward in walk-man technology: solid-state ( shock-resistent, potentially water-proof ), infinite storage potential, ease of replication for multiple audio devices ( car, walk-man, home office, work office can all have the same CD-contents without requiring carring the CD or even player ( when player is cheap enough ) ).
Compressed audio is a leap forward in jukebox systems: Multiplexing literally an infinite number of songs ( at $2xx for 40Gig ) to an infinite number of users ( limited by bandwidth and server capabilities, which are rarely dedicated and thus must compete for real-work resources ).
Post-Lastly, to my knowledge you can not broadcast a song that has human voice in it without paying royalties ( hense elevator music in department stores ). Thus it would be illegal to broadcast this MP3 jukebox ( even in a legally secured/licensed fashion ) over the loud-speakers. It therefore becomes questionable at which point ( e.g. with how many users ) does a privately owned juke-box setup become considered broadcasting. 20 employees? 100 employees? To me, the very discrete nature of client/server suggests that so long as only individuals access the juke-box, it is not broadcast; We are not using multi-cast afterall; Aside from spending $50K on a ultra-RAID setup ( with redundant copies ), and multiple servers with independant ether-lines for different sections of the building.
First of all, a little professionalism would be appretiated.
Secondly, the fact still remains that there are heavy initial access delay times ( 7 cycles in PC66 SDRAM alone ). This delay is only marginally avoided by interleaving / pipelining ( unless you can produce 4 to 8 fully pipelined stages ). This is still a downside or flaw to DRAM. To my knowledge SRAM does not require independant row and column charges ( though the addressing logic may require some twiddling ).
Either way, I doubt that your nit-pick makes any difference to my main point. That you can achieve greater performance in a concurrent-access memory subsystem by going n-way ( at the cost of redundancy and expense ).
-Michael
Sorry for the above length.. High points:
-Current IA32 CPU's and single tasking/single threaded software ( like quake ) does not present too many opportunities for multiple-concurrent memory access.
-Deeper pipelining and ever more advanced add-ons to IA32 in addition to AGP and faster DMA devices ( such as gigabit-ether and RAID drives ) would provide greater concurrent load for a memory device.
-Multi-threaded/process services such as file-serving, web serving, etc on a multi-CPU system can provide high main-memory load ( defeating virtually any caching system ) and requiring a greater need for intelligent mem-access management ( as with SCSI elevator optimizations for disk access ). Being able to service more than one mem-request simultaneously is more valuable than servicing a mem-request more quickly. You can double, or quadruple throughput easily by going to an n-way memory system instead of increasing mem-latency by 50% each generation.
-Memory Blahs: DRAM is based on leaky capacitors ( pseudo-batteries ) which must be recharged, and pre-charged in such a way that causes serious performance lag, especially when you change which row is being accessed. Thus the "rated" speed of all DRAM chips is misleading if you do not understand this. 200MHZ DDR-SDRAM is it's burst speed. Dozens of clock cycles are consumed when non-optimal adjacent memory accesses occur. This is a fundamental flaw with DRAM and is present in most architectures ( RDRAM included ). Thus, only speeding up latency can never fully resolve this problem.
-[DDR-]SDRAM is designed for high-speed dumping of closely spaced regions of memory (within a row) in a serial fashion. Higher bandwidth allows the faster flushing of internally cached hits, but there is still a severe latency between accesses. An ideal ( though costly ) advancement might be to produce multiple interleaved "channels" of [DDR-]SDRAM in order to handle multiple concurrent memory accesses. I have seen no indication of this direction in motherboard chipset manufacturers, and thus doubt it's feasibility. This solution is typically found in high-end workstations ( See SGI's visual NT station or many RISC servers )
-RDRAM is designed with the idea of multiple channels from the beginning. Sadly, it's radically different architecture means an extreme introductory price which would only decrease in higher production volumes. RDRAM did not turn out to be as glorious as would be hoped. BUT, most benchmarks I have seen deal with non-server apps in single-CPU environments. Thus scores were only marginally better.
-Intel's incentive. Tom leads us to believe that Intel is trying to make a quick buck on RDRAM. I have suggested that Intel absolutely needs an RDRAM type solution ( if not a normal interleaved solution ). Pipelining ( in both CPU and GPU ) allows the masking of memory loads ( some-what ), and thus Intel is migrating towards higher-latacey tolerant CPU's that are capable of ever increasing number of outstanding mem-requests ( which is facilitated by RDRAM and it's like ). Ultimately, Intel will move to IA64, which is completely designed around massive pre-queueing of memory accesses. Without massively parallel memory interfaces, IA64 will be even more memory starved than Alphas ( due to larger instructions ( 40 + overhead vs 32 bits/instruction ), and the heavy usage of speculative mem-loads ). I believe that IA64 will be significantly slower than IA32 unless a more advanced memory structure can be used. Additionally, I believe that IA64 will be far better suited to RDRAM than IA32 ( due to the above ).
Intel NEEDS RDRAM ( or something like it ) to succeed for fear of IA64 flopping. Introducing IA32 to i820 and RDRAM is supposed to ease the market into acceptance. I doubt they care about lowering the price for IA64 ( since it'll be astronomical in and of itself ), but you need to at least encourage chip manufacturers to get the bugs out early.
Rambus, on the other hand is just trying to keep their business going.. Thus they're having to give incentives out here and there ( that's just standard business ).
I think Tom is being a little emotional in saying Rambus / Intel are evil. Rambus needs customers, and Intel needs a better memory architecture.
No, Rambus is not a cost-effective solution to single IA32 CPU systems. It definately is not worth the price for single tasking systems ( such as for gaming ), though it might still work well in periferal contention situations ( 2xNIC + SCSI + RAID + CPU ). I would be curious to see RDRAM's benchmarks in IA32 mult-CPU configurations with multi-threaded / processes apps, of course.
I strongly believe that RDRAM is a good match for IA64 and possibly 4 CPU configurations ( where memory costs are not going to consist of too much of the overall package ).
Last and strongest point: Tom and many other techno-journalists, though very valuable in their insight and general contributions, are often seriously single-minded and emotional. I believe that they should spend a little more time being objective and trying to analyze the _why's_ of corporate America; looking at things from their perspective from time to time ( and actually comment about it ). You make a much stronger voice when you show an understanding of the situation, rather than preach to the choir and make ASSumptions.
-Michael