When Win95 came out it broke every single Windows program I had compiled with Borland C++ that used the Borland classes for the GUI. Borland had to rapidly put out an update, I think this was 3.5 to 4.0, or maybe that was 4.0 to 4.5. I still think to this day that MS did this on purpose considering how programs compiled with the MS tools for 3.0, 3.1, 3.11, and WfW ran just fine on Win95 unless the programmer did some unlucky rare things. I certainly saw a lot of people move to VC++ then since they had dlls ready to take advantage of the new features of Win95 right away as well. Personally I installed linux and gcc.
I think the reason most manufacturers do it is not to save a few bucks but to create a reason for someone to buy from their more expensive business line instead.
I remember when I was kid (pre-TASM) and my dad got a blazing fast internal ISA 2400 baud modem (hee hee). But it would not work right in Windows 3.0, it worked fine in a DOS program. Back then you had to assign an IRQ and port. The internal cards used the same as COM1 and COM2, but it should have been okay. The ISR should have checked the first card and then chained to the next. But it simply was not working, we had a serial port mouse and the other serial port was used for a printer (the machine had two printers one for carbon copy forms the other a laser printer for letters on the parallel port).
So after trying everything that I could think of I called MS support. Back then things were VERY different. The lady that answered spoke pacific NW English and was incredibly competent. She explained that some BIOSes were buggy and did not do the IRQ chaining correctly. We could not find an IRQ that was free that the modem card had a jumper for so she walked me over the phone commands to do in debug to patch a driver in Windows 3.0 to get around this issue. I was a freshman in high school at the time, that really left a mark on me. I had just learned how to use edlin before that. Soon after I got a copy of Turbo Pascal from this Polish guy I knew and I never looked back.
Before then I had only done Basic and later TASM (no relation Turbo ASM, that is what the cartridge+floppy interface was called, probably Tandy ASM) programming on a CoCoII. But that few minutes in debug got me hooked on modern systems and led to C/C++ TASM by the time I finished high school. I got a summer job just so I could afford Borland C++, it was something like $400 (student discount, I could not sell programs I compiled), the printed manuals it came with were incredible. DOS, Windows, dBase, WP all had incredible printed manuals too. Man have times changed.
Before TASM I sure did used debug a lot. It was a cheap assembler, disassembler (I needed to figure out some VGA routines from Borland), and you could use it a lot like you would dd on unix too.
"due to the fact that the x86-64 CPUs cannot switch to 16-bit mode."
????
AMD64 CPUs most certainly support real mode. In fact that is how they boot, how else would you expect the VGA bios to execute during boot?
They also support Virtual 8086 mode which you are confusing with 16-bit mode. The issue is that in Long mode (which is all that 64-bit MS OSs supprort) you cannot run in those modes. Instead you either run in 64-bit mode or compatibility mode (32-bit or 16-bit, no extra regs). MS certainly could have provided a way to switch between Long mode and Legacy mode but chose not to. Then when encountering a real mode program it would switch to Legacy mode. These switches are not cheap though, you'd likely have do things like quiesce DMA, and that is why MS decided to ditch it. In fact there was a similar issue with the 80286 and 16-bit protected mode, essentially a soft reset was needed to get back into real mode but that was done back then (with the advent of Windows 3.0) since so many programs would have been unusable otherwise.
My goodness, I can't believe I did not think about it from that point of view. Yes certainly ARM can add instruction reordering and register renaming (hopefully also speculative execution and branch prediction) and then it would be really on a more even playing field. I guess those ideas are so against the early RISC-isms of ARM up until now that it just seemed unthinkable to me, DOH. Yup decent cache, fast bus, and those modern cpu features (which should be easier to implement, read lower transistor count and power) and ARM really can preform well per clock and watt.
"Thumb mode is rare these days except in the smallest embedded products. It's just too much of a pain to use."
Oh yes but there is no way around it when I only have so many MIPS and a 16-bit bus. That extra wait state really hurts.
"I think ARM will have an advantage because RISC is easier to pipeline, and more importantly ARM has more registers."
I don't know, x86 has instruction reordering, register renaming, and at least some cache always. They tend to have faster buses as well. ARM will use less juice though and will probably be able to get good enough performance very soon at lower wattage, and once that happens it will be very a different landscape. But yes it is hard to say which is faster per clock but it should become irrelevant soon and it WILL be interesting what Apple makes.
Actually the observance of neutrino oscillation is what indicates that neutrinos have mass. The fact that it exists means (if the standard model is right) that there must be a difference in mass between the different neutrinos. If all of them had a mass of zero, the difference would be zero as well. It also means that mass may be more fundamental than previously thought and the standard model might need to be tweaked in regards to that, especially if Higgs related HEP works reveals some surprises, precisely the research that will be done at CERN after the next start-up. This was a lot more fundamental and earth shaking of a discovery than simply a free particle in the standard model. In fact it is not known what the masses actually are!
I'm am not sure I am parsing you correctly but PET and MRI are direct benefits of from HEP research. The positron part of PET is pretty clear. The high gauss magnets in MRI are direct descendants of the powerful magnets used to steer and focus beams in HEP.
Also the detectors used in things like nuclear stress tests are descendant on HEP track detectors.
That is just medicine and over the past 25 years. In the last five or so, it is actually becoming feasible to detect neutrinos in a facility the size of four or so semi trailers. The application being detecting nuclear materials (read bombs) in ports. (Enough material will stop the neutrons, nothing stops the neutrinos.) Expect to hear about that publicly in the next ten years or so.
Also HEP needs lots of amps, in the last 25 years the electric grid has adopted technology pioneered at CERN and Fermilab to make long range utility transmission lines more efficient.
Then there are is all the technology that was driven by HEP that you take for granted today. First supercomputers, then big fast clusters. Also fast huge data storage and retrieval, first tape based, now disk based. How about gate arrays? HEP needed that and drove it in the beginning. How about PCI? Fermilab was one of the early members since it needed an alternative to the old IP standard. High speed digitizers are now used in many applications outside of HEP, at first labs made their own and licensed the tech to the companies that manufacture them now. That continues to this day where labs make ever faster digitizers that eventually get used in industry.
Even color NTSC TV is a descendant of tech at Fermilab. At first there were many competing proposals, but eventually simple scheme employed for the monitors there became the accepted standard.
In my situation, the school board pres is not only my neighbor and coworker, he is also the manager of one of the projects I work on so I report to him. Also the two prior presidents burned-out from dealing with admin/teacher/parent/student crap. There sort of was a coup of getting admin friendly people elected. I don't know my neighbor well enough yet to say what interests he really is concerned with, so it just is not worth the potential grief it could cause at work and in the neighborhood.
Yeah sometimes this stuff gets complicated and frankly not worth it in the long run.
I probably should have added I use ARM and PPC in embedded/realtime for my job. So you're preaching to the converted. Lately though pc104, pc104+, and pci104 with NetBSD or Linux for embedded have been really attractive to me for cost and size reasons.
Atom is pretty low power, for Intel. Via has got more promise at that though less MIPS. When I said "saving grace" I meant it in terms of the original question, how fast is an ARM going to be in a netbook. My gut was not as fast but almost. The kicker is that you can throw interesting things into the same package (SoC) more easily with the ARM core. Interesting things you can throw in there include nic, fb, crypt accel, video dec, etc. That can give it an edge.
But I do think that when you would try and price a beefy ARM like this it would come close to the Atom plus support chips price. It would most likely still use less W though.
Also for a while now with APIC interrupts have been sane (though way complicated and initially buggy) on Intel. You actually can do more with APIC now than you can with the ARM, which is simply an easy and quick way requiring no support chips to nest IRQs of different priorities and easily get different cores in your chip to twiddle one another.
At one point I had to add a signature like this to the end of my emails:
"mzs - place of employment"
The reason, a vendor I contacted for a quote complained that he was unsure if I was really from where I was from. I guess the From: line was not enough.
Then I had to add under that:
"The ideas and opinions expressed... are mine and not those of my employer"
This was after I emailed an the assistant principal at my son's school and instead of addressing my concern about the teacher he got into a tizzy that I emailed him from work and were these things the opinion of my employer.
Then I just went back to mzs and used my personal email when he kept being a jerk. He never did address my concerns, just kept looking for ways to avoid the issue. The school year is almost over, so water under the bridge.
I think some people just are sort of clueless about email and others like to cause trouble. I am not sure about the fellow in this article but certainly one of those are the explanation.
"This is just off the top of my head. Is there something special about SPARC that would make it remarkably good at some specific application that Oracle uses?"
The latest Sun sparc chips have been designed specifically around Oracle DB license costs. They can run a lot of threads in one physical object (that falls within the definition of what Oracle uses for per-processor) where there are a lot of concurrent accessors to a DB and none of them doing much FP which when the thread of execution needs to block (often due to the tasks being IO bound in Oracle DB) another thread of execution continues on.
These chips were designed so that they could be relatively expensive but when the shops that run Oracle DB figure in how much they save in per year licensing to Oracle corp the end-up being the least expensive option. The chips need to be relatively expensive because there are not as much of them sold and the R&D costs need to be spread out.
I kind of wonder now that Oracle owns Sun what will happen. If Oracle corp changes the terms of future licensing to its customers than that could indicate their tacit admission of non-interest in sparc for the future. It would also be a calculated move to increase revenue overall.
But in reality we are just now starting to see ARM cores that go +1GHz and have ~512K cache, some reasonable floating point, and 32-bit bus. What was common before was 200-600MHz in the high MIPS ones, at most 32K cache, a 16-bit bus (making non-thumb code painful, some would not even have a cache, simply preload the next 16-bit word to avoid one of the extra wait states) and a real mess when it came to floating point. Some had none, some had something in a DSP, some did it in a SIMD extension (but only single frecision), and some had an external fp IEEE compatible unit that used one of the exceptions and the data bus (slowwwwwww). Honestly in my opinion a 1.3 GHz ARM is going to be a smidge slower than an Atom. Even to this day ARM are very much old RISC in their pipeline. The Atom does some more register renaming, branch prediction, speculative execution, etc that gives it an edge. With the 32-bit bus you can probably avoid thumb mode and teh compiler can be a bit more clever though. The saving grace for ARM is what special sauce can be put in the DSP or even maybe they can throw in a 10K or so gate array. That would be interesting at least.
This is not so much for the Sun employees or the JAVA stockholders, this is for the Oracle DB shops that run on solaris/sparc aka the guys paying big money to Oracle now. Oracle does not want to alienate them and get them to go IBM (and then possibly DB2) or Red Hat (and the possibly Postgress/MySQL). Also now Oracle will be making revenue on those solaris/sparc shops not just for the DB. They want to at least make outward indication that they do not intend to cause trouble for them.
Oh I forgot one thing. My friend later had a IIgs and when we played the older prodos Apple II games, brown invariably looked like yellow, but on the PCjr brown was actually brown. I do not know if that was an Apple II thing or just his monitor, but I always noticed it. So I always had this view that the graphics were better on the PCjr than on the Apple II as a kid. The IIgs though, that blew me away, but it did come out years later.
You picked sort of a bad yet sort of a good example in the IBM PCjr. Yes I had one. That really was the best of the design for home use from IBM at the time. The design emphasized different characteristics though. The Mac had small where luggable was important, the PCjr had small where expandable was important. But the real problem in your comparison is that the Mac was made as a competitor to the IBM 5150, while the IBM PCjr was made as a competitor to the Apple II line (in particular the IIc). There was innovation in the Mac that was not in the PCjr simply since it was not targeting the same audience (like the mouse+gui) so I am going to ignore that.
So some things where the PCjr was innovative:
That thing on the side, that was an expansion module, you could just keep plugging in in more on the side. That one in the picture was probably a parallel port sidecar.
The two holes on the bottom, those were for ROM carts, I had a BASIC ROM and a few games.
That little circle on the bottom, that was an infrared receiver for the wireless keyboard.
That monitor on top was an RGBI style CGA+ monitor. RGBI was digital. The PCjr could do 320x200 16 color and 640x200 4 color and that monitor was really crisp at 80x25 at the time.
The PCJr also had good sound for the time, I think better than Apple II.
They also had a light pen connector and two joystick ports. Yes I had software that used the light pen, again targeted to home use where at the time mouse seemed not as simple for kids and certainly not as good for drawing (hee hee).
But in fact that wireless keyboard truly sucked. It was not fun to type on, the Apple II and IIc keyboards were much nicer. So there is a case of innovation gone wrong at IBM.
If you wanted to pick a worse example from the PC camp you could have picked the Tandy 1000. That was a typical large box with drive bays and a few 8-bit expansion ports. It was ugly by Apple standards. The innovation there was that some later models (was it the XL) had a higher speed NEC 8088 compatible. The PCjr was small in comparison.
I actually had hardware self destruct due to script kiddies. When I was at the university the only way to log in to the mail servers was via telnet. This was also the case for physics and math boxes. I also had a linux box running on a 486 laptop. This was '96 or '97. In any case due to someone having a weak password a script kiddie was able to get in and install a key logger on one of the boxes in the physics dept. Yup one that I had sshed from into my linux box, so there was the name in known_hosts. This box was not admined well at all and it was almost a week before anyone noticed. The script kiddie had a key logger logind running. In the meantime I logged in to the physics box. Guess what because of NIS I had the same password on a handful of mail servers and a math and physics box. For convenience I used the same password on my linux box. The script kiddie took a long time to figure-out the name of a better admined mail server but they sure found-out about my poor linux box right away. When they did notice because of NIS they were able to get on that mail server easily as well. Once they tried for local root exploits and an admin noticed jktr on that mail server the admins knew something was up. The bad news was that On friday I left for a college bowl tournament and did not get back until Sunday. In two days the script kiddie had IRC and FTP running on my poor little box and the HD was dead before the admins figured-out was going on. It had most likely overheated and that caused the premature death of the HD. Back then it was a real pain in the neck to find a 2.5 IDE drive to replace it with and even get to the old drive in the notebook.
You know the whole chair and how strong CliffyB is thing later on, makes me think that guy has a good sense of humor. Also the word STORY in bold at the beginning...
Wow this should have not been modded as flamebait. We should have simply addressed the better ways to do what the AC suggested. Honestly Linux is pretty decent about being backwards compatible at the syscall level. What is a real PITA is how glibc and libstdc++ do not remain backwards compatible. The BSDs do a much better job of backwards compatibility, and Solaris does an exceptional job. I just simply think that the Linux people do not care so much about that sadly. There were some backwards compat issues that made sense (like teh move from COFF to ELF and the broken relocation types originally used in ELF) but others have not made sense:
Yet again changing the relocation types. Various times the C++ library broke backwards compatibility. Various times that glibc broke backwards compatibility.
Also what is up with changing the options to programs in/usr/bin willy nilly?!
Ha! That's a great idea in principle, though I don't know how I would feel about there being a/compat dir containing glibc on Linux, you know it would be needed. It also would be a lot of work to get apps and libs that have workarounds or have come to expect (even without knowing it) glibc-isms to be fixed. The other thing is that there are lots of programs that rely on glibc internals to link. They would need a recompile. Then there are those programs that actually use glibc internals, and there are more of those than you think. For a while there that was the only way to really get internationalization to work right with glibc.
In any case I think the Debian folks use a BSD libc in some ports and there was a some work on BSD libc in Gentoo. That all sort of came to the problems I outlined above when trying to use BSD libc on i386.
Slashdot Mirror
When Win95 came out it broke every single Windows program I had compiled with Borland C++ that used the Borland classes for the GUI. Borland had to rapidly put out an update, I think this was 3.5 to 4.0, or maybe that was 4.0 to 4.5. I still think to this day that MS did this on purpose considering how programs compiled with the MS tools for 3.0, 3.1, 3.11, and WfW ran just fine on Win95 unless the programmer did some unlucky rare things. I certainly saw a lot of people move to VC++ then since they had dlls ready to take advantage of the new features of Win95 right away as well. Personally I installed linux and gcc.
I think the reason most manufacturers do it is not to save a few bucks but to create a reason for someone to buy from their more expensive business line instead.
Here is another former TASM user piping up.
I remember when I was kid (pre-TASM) and my dad got a blazing fast internal ISA 2400 baud modem (hee hee). But it would not work right in Windows 3.0, it worked fine in a DOS program. Back then you had to assign an IRQ and port. The internal cards used the same as COM1 and COM2, but it should have been okay. The ISR should have checked the first card and then chained to the next. But it simply was not working, we had a serial port mouse and the other serial port was used for a printer (the machine had two printers one for carbon copy forms the other a laser printer for letters on the parallel port).
So after trying everything that I could think of I called MS support. Back then things were VERY different. The lady that answered spoke pacific NW English and was incredibly competent. She explained that some BIOSes were buggy and did not do the IRQ chaining correctly. We could not find an IRQ that was free that the modem card had a jumper for so she walked me over the phone commands to do in debug to patch a driver in Windows 3.0 to get around this issue. I was a freshman in high school at the time, that really left a mark on me. I had just learned how to use edlin before that. Soon after I got a copy of Turbo Pascal from this Polish guy I knew and I never looked back.
Before then I had only done Basic and later TASM (no relation Turbo ASM, that is what the cartridge+floppy interface was called, probably Tandy ASM) programming on a CoCoII. But that few minutes in debug got me hooked on modern systems and led to C/C++ TASM by the time I finished high school. I got a summer job just so I could afford Borland C++, it was something like $400 (student discount, I could not sell programs I compiled), the printed manuals it came with were incredible. DOS, Windows, dBase, WP all had incredible printed manuals too. Man have times changed.
Before TASM I sure did used debug a lot. It was a cheap assembler, disassembler (I needed to figure out some VGA routines from Borland), and you could use it a lot like you would dd on unix too.
"due to the fact that the x86-64 CPUs cannot switch to 16-bit mode."
????
AMD64 CPUs most certainly support real mode. In fact that is how they boot, how else would you expect the VGA bios to execute during boot?
They also support Virtual 8086 mode which you are confusing with 16-bit mode. The issue is that in Long mode (which is all that 64-bit MS OSs supprort) you cannot run in those modes. Instead you either run in 64-bit mode or compatibility mode (32-bit or 16-bit, no extra regs). MS certainly could have provided a way to switch between Long mode and Legacy mode but chose not to. Then when encountering a real mode program it would switch to Legacy mode. These switches are not cheap though, you'd likely have do things like quiesce DMA, and that is why MS decided to ditch it. In fact there was a similar issue with the 80286 and 16-bit protected mode, essentially a soft reset was needed to get back into real mode but that was done back then (with the advent of Windows 3.0) since so many programs would have been unusable otherwise.
My goodness, I can't believe I did not think about it from that point of view. Yes certainly ARM can add instruction reordering and register renaming (hopefully also speculative execution and branch prediction) and then it would be really on a more even playing field. I guess those ideas are so against the early RISC-isms of ARM up until now that it just seemed unthinkable to me, DOH. Yup decent cache, fast bus, and those modern cpu features (which should be easier to implement, read lower transistor count and power) and ARM really can preform well per clock and watt.
"Thumb mode is rare these days except in the smallest embedded products. It's just too much of a pain to use."
Oh yes but there is no way around it when I only have so many MIPS and a 16-bit bus. That extra wait state really hurts.
"I think ARM will have an advantage because RISC is easier to pipeline, and more importantly ARM has more registers."
I don't know, x86 has instruction reordering, register renaming, and at least some cache always. They tend to have faster buses as well. ARM will use less juice though and will probably be able to get good enough performance very soon at lower wattage, and once that happens it will be very a different landscape. But yes it is hard to say which is faster per clock but it should become irrelevant soon and it WILL be interesting what Apple makes.
Actually the observance of neutrino oscillation is what indicates that neutrinos have mass. The fact that it exists means (if the standard model is right) that there must be a difference in mass between the different neutrinos. If all of them had a mass of zero, the difference would be zero as well. It also means that mass may be more fundamental than previously thought and the standard model might need to be tweaked in regards to that, especially if Higgs related HEP works reveals some surprises, precisely the research that will be done at CERN after the next start-up. This was a lot more fundamental and earth shaking of a discovery than simply a free particle in the standard model. In fact it is not known what the masses actually are!
I'm am not sure I am parsing you correctly but PET and MRI are direct benefits of from HEP research. The positron part of PET is pretty clear. The high gauss magnets in MRI are direct descendants of the powerful magnets used to steer and focus beams in HEP.
Also the detectors used in things like nuclear stress tests are descendant on HEP track detectors.
That is just medicine and over the past 25 years. In the last five or so, it is actually becoming feasible to detect neutrinos in a facility the size of four or so semi trailers. The application being detecting nuclear materials (read bombs) in ports. (Enough material will stop the neutrons, nothing stops the neutrinos.) Expect to hear about that publicly in the next ten years or so.
Also HEP needs lots of amps, in the last 25 years the electric grid has adopted technology pioneered at CERN and Fermilab to make long range utility transmission lines more efficient.
Then there are is all the technology that was driven by HEP that you take for granted today. First supercomputers, then big fast clusters. Also fast huge data storage and retrieval, first tape based, now disk based. How about gate arrays? HEP needed that and drove it in the beginning. How about PCI? Fermilab was one of the early members since it needed an alternative to the old IP standard. High speed digitizers are now used in many applications outside of HEP, at first labs made their own and licensed the tech to the companies that manufacture them now. That continues to this day where labs make ever faster digitizers that eventually get used in industry.
Even color NTSC TV is a descendant of tech at Fermilab. At first there were many competing proposals, but eventually simple scheme employed for the monitors there became the accepted standard.
Nice idea about #3, but past that sadly.
In my situation, the school board pres is not only my neighbor and coworker, he is also the manager of one of the projects I work on so I report to him. Also the two prior presidents burned-out from dealing with admin/teacher/parent/student crap. There sort of was a coup of getting admin friendly people elected. I don't know my neighbor well enough yet to say what interests he really is concerned with, so it just is not worth the potential grief it could cause at work and in the neighborhood.
Yeah sometimes this stuff gets complicated and frankly not worth it in the long run.
I probably should have added I use ARM and PPC in embedded/realtime for my job. So you're preaching to the converted. Lately though pc104, pc104+, and pci104 with NetBSD or Linux for embedded have been really attractive to me for cost and size reasons.
Yeah I think we are agreeing here.
Atom is pretty low power, for Intel. Via has got more promise at that though less MIPS. When I said "saving grace" I meant it in terms of the original question, how fast is an ARM going to be in a netbook. My gut was not as fast but almost. The kicker is that you can throw interesting things into the same package (SoC) more easily with the ARM core. Interesting things you can throw in there include nic, fb, crypt accel, video dec, etc. That can give it an edge.
But I do think that when you would try and price a beefy ARM like this it would come close to the Atom plus support chips price. It would most likely still use less W though.
Also for a while now with APIC interrupts have been sane (though way complicated and initially buggy) on Intel. You actually can do more with APIC now than you can with the ARM, which is simply an easy and quick way requiring no support chips to nest IRQs of different priorities and easily get different cores in your chip to twiddle one another.
I used to sign my emails:
"mzs"
At one point I had to add a signature like this to the end of my emails:
"mzs - place of employment"
The reason, a vendor I contacted for a quote complained that he was unsure if I was really from where I was from. I guess the From: line was not enough.
Then I had to add under that:
"The ideas and opinions expressed ... are mine and not those of my employer"
This was after I emailed an the assistant principal at my son's school and instead of addressing my concern about the teacher he got into a tizzy that I emailed him from work and were these things the opinion of my employer.
Then I just went back to mzs and used my personal email when he kept being a jerk. He never did address my concerns, just kept looking for ways to avoid the issue. The school year is almost over, so water under the bridge.
I think some people just are sort of clueless about email and others like to cause trouble. I am not sure about the fellow in this article but certainly one of those are the explanation.
"This is just off the top of my head. Is there something special about SPARC that would make it remarkably good at some specific application that Oracle uses?"
The latest Sun sparc chips have been designed specifically around Oracle DB license costs. They can run a lot of threads in one physical object (that falls within the definition of what Oracle uses for per-processor) where there are a lot of concurrent accessors to a DB and none of them doing much FP which when the thread of execution needs to block (often due to the tasks being IO bound in Oracle DB) another thread of execution continues on.
These chips were designed so that they could be relatively expensive but when the shops that run Oracle DB figure in how much they save in per year licensing to Oracle corp the end-up being the least expensive option. The chips need to be relatively expensive because there are not as much of them sold and the R&D costs need to be spread out.
I kind of wonder now that Oracle owns Sun what will happen. If Oracle corp changes the terms of future licensing to its customers than that could indicate their tacit admission of non-interest in sparc for the future. It would also be a calculated move to increase revenue overall.
But in reality we are just now starting to see ARM cores that go +1GHz and have ~512K cache, some reasonable floating point, and 32-bit bus. What was common before was 200-600MHz in the high MIPS ones, at most 32K cache, a 16-bit bus (making non-thumb code painful, some would not even have a cache, simply preload the next 16-bit word to avoid one of the extra wait states) and a real mess when it came to floating point. Some had none, some had something in a DSP, some did it in a SIMD extension (but only single frecision), and some had an external fp IEEE compatible unit that used one of the exceptions and the data bus (slowwwwwww). Honestly in my opinion a 1.3 GHz ARM is going to be a smidge slower than an Atom. Even to this day ARM are very much old RISC in their pipeline. The Atom does some more register renaming, branch prediction, speculative execution, etc that gives it an edge. With the 32-bit bus you can probably avoid thumb mode and teh compiler can be a bit more clever though. The saving grace for ARM is what special sauce can be put in the DSP or even maybe they can throw in a 10K or so gate array. That would be interesting at least.
This is not so much for the Sun employees or the JAVA stockholders, this is for the Oracle DB shops that run on solaris/sparc aka the guys paying big money to Oracle now. Oracle does not want to alienate them and get them to go IBM (and then possibly DB2) or Red Hat (and the possibly Postgress/MySQL). Also now Oracle will be making revenue on those solaris/sparc shops not just for the DB. They want to at least make outward indication that they do not intend to cause trouble for them.
Oh I forgot one thing. My friend later had a IIgs and when we played the older prodos Apple II games, brown invariably looked like yellow, but on the PCjr brown was actually brown. I do not know if that was an Apple II thing or just his monitor, but I always noticed it. So I always had this view that the graphics were better on the PCjr than on the Apple II as a kid. The IIgs though, that blew me away, but it did come out years later.
You picked sort of a bad yet sort of a good example in the IBM PCjr. Yes I had one. That really was the best of the design for home use from IBM at the time. The design emphasized different characteristics though. The Mac had small where luggable was important, the PCjr had small where expandable was important. But the real problem in your comparison is that the Mac was made as a competitor to the IBM 5150, while the IBM PCjr was made as a competitor to the Apple II line (in particular the IIc). There was innovation in the Mac that was not in the PCjr simply since it was not targeting the same audience (like the mouse+gui) so I am going to ignore that.
So some things where the PCjr was innovative:
That thing on the side, that was an expansion module, you could just keep plugging in in more on the side. That one in the picture was probably a parallel port sidecar.
The two holes on the bottom, those were for ROM carts, I had a BASIC ROM and a few games.
That little circle on the bottom, that was an infrared receiver for the wireless keyboard.
That monitor on top was an RGBI style CGA+ monitor. RGBI was digital. The PCjr could do 320x200 16 color and 640x200 4 color and that monitor was really crisp at 80x25 at the time.
The PCJr also had good sound for the time, I think better than Apple II.
They also had a light pen connector and two joystick ports. Yes I had software that used the light pen, again targeted to home use where at the time mouse seemed not as simple for kids and certainly not as good for drawing (hee hee).
But in fact that wireless keyboard truly sucked. It was not fun to type on, the Apple II and IIc keyboards were much nicer. So there is a case of innovation gone wrong at IBM.
If you wanted to pick a worse example from the PC camp you could have picked the Tandy 1000. That was a typical large box with drive bays and a few 8-bit expansion ports. It was ugly by Apple standards. The innovation there was that some later models (was it the XL) had a higher speed NEC 8088 compatible. The PCjr was small in comparison.
I actually had hardware self destruct due to script kiddies. When I was at the university the only way to log in to the mail servers was via telnet. This was also the case for physics and math boxes. I also had a linux box running on a 486 laptop. This was '96 or '97. In any case due to someone having a weak password a script kiddie was able to get in and install a key logger on one of the boxes in the physics dept. Yup one that I had sshed from into my linux box, so there was the name in known_hosts. This box was not admined well at all and it was almost a week before anyone noticed. The script kiddie had a key logger logind running. In the meantime I logged in to the physics box. Guess what because of NIS I had the same password on a handful of mail servers and a math and physics box. For convenience I used the same password on my linux box. The script kiddie took a long time to figure-out the name of a better admined mail server but they sure found-out about my poor linux box right away. When they did notice because of NIS they were able to get on that mail server easily as well. Once they tried for local root exploits and an admin noticed jktr on that mail server the admins knew something was up. The bad news was that On friday I left for a college bowl tournament and did not get back until Sunday. In two days the script kiddie had IRC and FTP running on my poor little box and the HD was dead before the admins figured-out was going on. It had most likely overheated and that caused the premature death of the HD. Back then it was a real pain in the neck to find a 2.5 IDE drive to replace it with and even get to the old drive in the notebook.
You know the whole chair and how strong CliffyB is thing later on, makes me think that guy has a good sense of humor. Also the word STORY in bold at the beginning...
It did run okay on my 33 Mhz 486 with ISA SVGA card though unlike Quake. The multiplayer was better as well. Also it came-out earlier.
Two other things are becoming common:
No more of those little nubs on the head lights to ease robotic installation.
Windshield wipers without non-deformable parts or those parts well below a deformable hood.
Wow this should have not been modded as flamebait. We should have simply addressed the better ways to do what the AC suggested. Honestly Linux is pretty decent about being backwards compatible at the syscall level. What is a real PITA is how glibc and libstdc++ do not remain backwards compatible. The BSDs do a much better job of backwards compatibility, and Solaris does an exceptional job. I just simply think that the Linux people do not care so much about that sadly. There were some backwards compat issues that made sense (like teh move from COFF to ELF and the broken relocation types originally used in ELF) but others have not made sense:
Yet again changing the relocation types.
Various times the C++ library broke backwards compatibility.
Various times that glibc broke backwards compatibility.
Also what is up with changing the options to programs in /usr/bin willy nilly?!
Ha! That's a great idea in principle, though I don't know how I would feel about there being a /compat dir containing glibc on Linux, you know it would be needed. It also would be a lot of work to get apps and libs that have workarounds or have come to expect (even without knowing it) glibc-isms to be fixed. The other thing is that there are lots of programs that rely on glibc internals to link. They would need a recompile. Then there are those programs that actually use glibc internals, and there are more of those than you think. For a while there that was the only way to really get internationalization to work right with glibc.
In any case I think the Debian folks use a BSD libc in some ports and there was a some work on BSD libc in Gentoo. That all sort of came to the problems I outlined above when trying to use BSD libc on i386.
Seriously, somebody mod this up.
glibc itself does not stay binary compatible to prior versions, that itself is a real PITA.