Apparently you've never worked in a union before. Otherwise, you'd realize the difficulty in dealing with people who know they can't be fired, as long as they don't do anything illegal. Takes twice as long to get anything done, I'll tell you that.
Yes, it is bad if the browser doesn't render bad source correctly. When I worked on Mosaic, we used to get hammered by our user base for this very thing.
Imagine if they did this for RAM. Instead of one bit being on or off, have variations, one bit could be any of 2 or more values. Make 'em color, and then you'd have 24bit depth per bit. Imagine how programming would change.:-)
Whoa! I remember Toker. Been a long time since I thought of that!
The POKE command didn't fry the motherboard..well, not exactly. It would start driving the screen at a higher rate, and blow a capacitor because of it. I did it to my PET. Doh!
This was the first question that the person from Slashdot (forgive me, I can't remember who it was). The response was there was a demo there (not shown on the ZDNet broadcast) of a machine running X86 byte code and Java bytecode natively, at the same time.
This is much along the lines of what we discussed here in a post from last September. See the Chips that change on the fly thread (starting at post #44) from September 23rd.
Too bad they didn't give out prizes for guessing right.:-)
We've kicked this idea around for the last two years. The biggest thing is coordinating everything, documentation and versioning.
A few issues:
Once a component goes into the repository, what's the best way to keep backwards compatibilty?
Who controls versioning for each component, and decides what goes into it?
Most coders hate writing doc. How do you maintain consistancy for your docs?
Someone pointed out that you need a component model; there's at least one group that's working on that (name escapes me at the moment).
Which languages do you support? Do you have interoperability between languages? What do you use now? Corba? It's going towards the JavaBeans model in the next version....do you go for that?
Those are just a few of the things to worry about.
Don't get me wrong, I think this is a great idea. It's going to take a LOT of work to coordinate.
I think the best way to handle this is to get a very small group (four or less) people together, and decide these, and the other issues that will arise. Don't use any more people than that...if you do, the committee will argue until they're blue in the face, and you'll never get anything done.
Another poster said something about a chip that can change its personality by downloading microcode. I think this a pretty good guess, but they might have taken it one step further.
They might have come up with a chip (or chips) that can actually run multiple different microcode sets at the same time. The benefit here would be that the consumer wouldn't have to switch between different microcode and reboot machines everytime they wanted to use something else. They'd be able to run multiple OSs at the same time, ala VMWARE.
Slashdot Mirror
Apparently you've never worked in a union before. Otherwise, you'd realize the difficulty in dealing with people who know they can't be fired, as long as they don't do anything illegal. Takes twice as long to get anything done, I'll tell you that.
Commodore PET, with a whopping 8k of memory.
Yes, it is bad if the browser doesn't render bad source correctly. When I worked on Mosaic, we used to get hammered by our user base for this very thing.
Is it fair? No.
You shouldn't need a phone line
I have DISHnetwork and TiVO. The DISHnetwork devices don't need to be hooked up to the phone line. They get their program info over the air.
One of them is hooked up to a regular TiVO, and we use wireless networking to get the updated program guides.
The PCMCIA adapter for the iPAQ has been out for a while. We have it on our iPAQs with 802.11b cards now.
Imagine if they did this for RAM. Instead of one bit being on or off, have variations, one bit could be any of 2 or more values. Make 'em color, and then you'd have 24bit depth per bit. Imagine how programming would change. :-)
Whoa! I remember Toker. Been a long time since I thought of that!
The POKE command didn't fry the motherboard..well, not exactly. It would start driving the screen at a higher rate, and blow a capacitor because of it. I did it to my PET. Doh!
This is much along the lines of what we discussed here in a post from last September. See the Chips that change on the fly thread (starting at post #44) from September 23rd.
Too bad they didn't give out prizes for guessing right. :-)
A few issues:
Once a component goes into the repository, what's the best way to keep backwards compatibilty?
Who controls versioning for each component, and decides what goes into it?
Most coders hate writing doc. How do you maintain consistancy for your docs?
Someone pointed out that you need a component model; there's at least one group that's working on that (name escapes me at the moment).
Which languages do you support? Do you have interoperability between languages? What do you use now? Corba? It's going towards the JavaBeans model in the next version ....do you go for that?
Those are just a few of the things to worry about.
Don't get me wrong, I think this is a great idea. It's going to take a LOT of work to coordinate.
I think the best way to handle this is to get a very small group (four or less) people together, and decide these, and the other issues that will arise. Don't use any more people than that...if you do, the committee will argue until they're blue in the face, and you'll never get anything done.
The movie "Enemy of the State" did a pretty interesting job protraying it's computer geeks.
They might have come up with a chip (or chips) that can actually run multiple different microcode sets at the same time. The benefit here would be that the consumer wouldn't have to switch between different microcode and reboot machines everytime they wanted to use something else. They'd be able to run multiple OSs at the same time, ala VMWARE.