My first thought was "What's the oldest working clock with mechanical chimes?" e.g. Big Ben or the like? As long as it's still running the original design, then I think it qualifies.
Give africa an open source laptop and they will develop their own unencumbered software...
And here's the important part most people miss: This is important even if 99.44% of the users remain simply users and don't tinker under the hood. You don't need many tinkerers to be able to develop and grow the platform. But, you need the ability to tinker.
Too many people are using the argument "Well, most people will just use the machine and won't tinker with the OS." That's not sound thinking. It'd be like welding the hood of your car shut just because you don't happen to be a mechanic, and neither are most of the people you know. After all, most people just drive their cars. Who needs to get under the hood?
Hmmm... Let's say you're trying to feed a starving nation with fruits, vegetables, and meat, and then Frito Lay shows up saying "Let's feed them all Funyuns and Doritos instead!" It doesn't matter as long as it's food, right?
That's right. I see Windows as the junk food of OSes.
Sure, but the number of neutrons determines an awful lot about the atom's behavior as well. It mostly affects atomic mass and stability/radioactivity. That's why I say the nucleus pretty much defines all the relevant properties of a given element in general.
Whether a given atom exhibits a charge is a function of whether that atom is missing (or has extra) electrons. But, in the context of the mass spectrometry, I imagine they don't mention electrons at all because it's irrelevant to defining the overall properties of this discovered element. Numbers of protons and neutrons are all that matter.
Well, lessee... Take 10,000 paid orders, ship 100 units, skip town. Sure, those 100 units might cost $1500 to build, but that's still a heck of a profit margin.
Atomic mass really isn't affected much by electron mass, since electrons are so tiny. The nucleus of an atom pretty much defines all its relevant properties. The mass spectrometer really just gives a reading on the mass of the nucleus, as I understand it.
The formula for Coca Cola is a trade secret, and yet you can get a can of it just about anytime from the soda machine. Just because you ship an embodiment of a trade secret doesn't mean you ship the sufficient details to reproduce it.
Furthermore, the protocol itself may have corner conditions or situations that make it difficult to implement unless you know the "tricks" of the implementation. These too can be trade secrets.
Now that I've had a chance to look through the photos, I'm pretty sure none of those are for Intellivision at least.:-) Intellivision EPROMs come in pairs because the system used 10-bit wide ROMs back in the day. They emulated them by pairing up 8-bit EPROMs and just filling the upper 6 bits with 0s. That netted you with "hi/lo" pairs. The "hi" half typically had a really small checksum, too.
Actually, that's entirely the direction I was thinking. HTML may not be the best choice, given its relatively slow render times and layout that shifts with the display device. Something like PDF, though, might work. Apple's Quartz already does that, earning it the (inaccurate) nickname Display PDF, so it doesn't seem like a huge stretch to cut the processing chain there at a different link.
I don't see why a structured display protocol can't be standardized, nor why a local, non-networked wireless link couldn't be employed. It *would* take a quantum shift to move in that direction, and there would be non-compatible stabs at the solution in the short run more than likely, but I see it as a direction things naturally have to move if we ever want to get to high DPI displays. And for projectors in conference rooms, you could always have the video cable fall back until things are sorted out.
Perhaps start with something relatively standard, such as VNC, and grow from there.
True, but how often are those videos (a) full screen, (b) full res, (c) full frame rate? And besides, with a structured display protocol such as what I'm thinking of, you could send the compressed bit stream and display parameters, not the decoded video, not unlike what YouTube does today.
In the main situation I've seen, it's mostly presentations that are being shown over such links. 1024×768×60Hz is all you really need there most of the time, and the actual update rate is much, much lower than that—typically no more than 2-3 slides/sec if you're flipping through a presentation trying to find a slide of interest. Even at HD resolutions (1920x1080 territory) it's not too bad if the update rate is typical presentation speeds.
Yeah, if you're doing HD resolution FMV, then you probably do still need a video connection, and that should remain an option. But for the typical "pop up this PowerPoint" or "bring up the spreadsheet" type situations that we currently play "pass the cable" for, it would be nice to have something a little less flaky. Heck, it seems like you ought to be able to send a much higher level representation to the display anyway, and let it render natively.
In general, I've been getting tired of the growing video bandwidth issue. It feels like more of the rendering should belong in the display and we should move to structured display protocols. That's the only way I see displays breaking into the 300dpi and up range at decent display sizes. It works against the trends for 3-D acceleration, but I'm not sure that realm benefits as much from high DPI displays as, say, text. I think dead trees start to lose their readability advantages once displays get a comparable DPI.
And on an entirely different point: Why are we still using video signals and cables to interface to projectors anyway? Seems like we ought to be able to do this digitally by now, either wirelessly, or even over Ethernet, a'la Netmeeting or VNC.
For awhile, our IT department's version of this was to set everyone's display to 1024x768 before delivering the machine to the end customer, since the native resolution "made everything too small." *sigh* They thankfully don't seem to do this anymore.
Actually, that tends to really confuse Windows if you have the same setting at your desk and you continually dock/undock without a shutdown in between. I know this from experience. Several of my coworkers have also tried this and eventually disabled it.
Slashdot Mirror
Cue Shatner screaming "Icaaaaaaaaaaaaaaaaahn!"
My first thought was "What's the oldest working clock with mechanical chimes?" e.g. Big Ben or the like? As long as it's still running the original design, then I think it qualifies.
To do that takes developers, developers, developers, Developers, Developers! DEVELOPERS! DEVELOPERS! DEVELOPERS!! DEVELOPERS!! DEVELOPERS!!
(don't use so many caps. It's like Steve Ballmer.)
And here's the important part most people miss: This is important even if 99.44% of the users remain simply users and don't tinker under the hood. You don't need many tinkerers to be able to develop and grow the platform. But, you need the ability to tinker.
Too many people are using the argument "Well, most people will just use the machine and won't tinker with the OS." That's not sound thinking. It'd be like welding the hood of your car shut just because you don't happen to be a mechanic, and neither are most of the people you know. After all, most people just drive their cars. Who needs to get under the hood?
Self sufficiency, that's why.
Hmmm... Let's say you're trying to feed a starving nation with fruits, vegetables, and meat, and then Frito Lay shows up saying "Let's feed them all Funyuns and Doritos instead!" It doesn't matter as long as it's food, right?
That's right. I see Windows as the junk food of OSes.
Be one with the Slashdot.
Sure, but the number of neutrons determines an awful lot about the atom's behavior as well. It mostly affects atomic mass and stability/radioactivity. That's why I say the nucleus pretty much defines all the relevant properties of a given element in general.
Whether a given atom exhibits a charge is a function of whether that atom is missing (or has extra) electrons. But, in the context of the mass spectrometry, I imagine they don't mention electrons at all because it's irrelevant to defining the overall properties of this discovered element. Numbers of protons and neutrons are all that matter.
Sure, the number of electrons as compared to the number of protons defines the overall charge (e.g. whether it's neutral or an ion). Fair enough.
The chemical and radioactive properties (including the atom's proclivity for becoming an ion or not) are determined by the nucleus.
Well, lessee... Take 10,000 paid orders, ship 100 units, skip town. Sure, those 100 units might cost $1500 to build, but that's still a heck of a profit margin.
Atomic mass really isn't affected much by electron mass, since electrons are so tiny. The nucleus of an atom pretty much defines all its relevant properties. The mass spectrometer really just gives a reading on the mass of the nucleus, as I understand it.
I can has deus ex machina plz? KTHXBAI.
The formula for Coca Cola is a trade secret, and yet you can get a can of it just about anytime from the soda machine. Just because you ship an embodiment of a trade secret doesn't mean you ship the sufficient details to reproduce it.
Furthermore, the protocol itself may have corner conditions or situations that make it difficult to implement unless you know the "tricks" of the implementation. These too can be trade secrets.
Here's a nice, concise explanation.
Now that I've had a chance to look through the photos, I'm pretty sure none of those are for Intellivision at least. :-) Intellivision EPROMs come in pairs because the system used 10-bit wide ROMs back in the day. They emulated them by pairing up 8-bit EPROMs and just filling the upper 6 bits with 0s. That netted you with "hi/lo" pairs. The "hi" half typically had a really small checksum, too.
Any chance any of these EPROMs are for systems other than Atari 2600? Coleco did games for the Intellivision and their own Colecovision also.
No Steve Austin / Six Million Dollar Man references yet? Tsk... tsk...
Oh ye of no sense of humor, and no appreciation for a good bit of wordplay....
And if you're really feeling pedantic, it depends on when you learned it and where you learned it from. Even Donald Knuth uses nybble.
Actually, that's entirely the direction I was thinking. HTML may not be the best choice, given its relatively slow render times and layout that shifts with the display device. Something like PDF, though, might work. Apple's Quartz already does that, earning it the (inaccurate) nickname Display PDF, so it doesn't seem like a huge stretch to cut the processing chain there at a different link.
I don't see why a structured display protocol can't be standardized, nor why a local, non-networked wireless link couldn't be employed. It *would* take a quantum shift to move in that direction, and there would be non-compatible stabs at the solution in the short run more than likely, but I see it as a direction things naturally have to move if we ever want to get to high DPI displays. And for projectors in conference rooms, you could always have the video cable fall back until things are sorted out.
Perhaps start with something relatively standard, such as VNC, and grow from there.
True, but how often are those videos (a) full screen, (b) full res, (c) full frame rate? And besides, with a structured display protocol such as what I'm thinking of, you could send the compressed bit stream and display parameters, not the decoded video, not unlike what YouTube does today.
In the main situation I've seen, it's mostly presentations that are being shown over such links. 1024×768×60Hz is all you really need there most of the time, and the actual update rate is much, much lower than that—typically no more than 2-3 slides/sec if you're flipping through a presentation trying to find a slide of interest. Even at HD resolutions (1920x1080 territory) it's not too bad if the update rate is typical presentation speeds.
Yeah, if you're doing HD resolution FMV, then you probably do still need a video connection, and that should remain an option. But for the typical "pop up this PowerPoint" or "bring up the spreadsheet" type situations that we currently play "pass the cable" for, it would be nice to have something a little less flaky. Heck, it seems like you ought to be able to send a much higher level representation to the display anyway, and let it render natively.
In general, I've been getting tired of the growing video bandwidth issue. It feels like more of the rendering should belong in the display and we should move to structured display protocols. That's the only way I see displays breaking into the 300dpi and up range at decent display sizes. It works against the trends for 3-D acceleration, but I'm not sure that realm benefits as much from high DPI displays as, say, text. I think dead trees start to lose their readability advantages once displays get a comparable DPI.
And on an entirely different point: Why are we still using video signals and cables to interface to projectors anyway? Seems like we ought to be able to do this digitally by now, either wirelessly, or even over Ethernet, a'la Netmeeting or VNC.
--JoeFor awhile, our IT department's version of this was to set everyone's display to 1024x768 before delivering the machine to the end customer, since the native resolution "made everything too small." *sigh* They thankfully don't seem to do this anymore.
Actually, that tends to really confuse Windows if you have the same setting at your desk and you continually dock/undock without a shutdown in between. I know this from experience. Several of my coworkers have also tried this and eventually disabled it.
Or, as we would say it in C, do_it(p), or in C++, p->do_it(). :-)
(Disclosure: I'm a C programmer.)