Back on June 9 2003, OSNews posted an article by Joshua Boyles entitled “The Edge Computing System“. In that article Joshua lays out his vision, “of a new and very unique computing system”. In this new article, an attempt will be made to further build on Jonathan’s ideas through what can be termed, “Open Peripheral Hardware Connectivity”.
1. Introduction
In the original article, Joshua proposed: “A system of computing that allows you to carry with you at all times your documents, configuration, and even programs stored in flash memory. And then upon arrival at your destination…your home, your hotel room, libraries…all of these destinations would be equipped with generic computers. So that you would just plug in your very own personalized context(flash), and using your own files, you could e-mail, surf the Web, edit documents, essentially do anything you would do at home or work.”
And then Joshua sums it all up, “That’s the point of this entire system, to be able to work on your stuff everywhere, to never have to worry about anything being left behind.” My apologies to Joshua if I, in my paraphrasing, have mangled any of his insights.
But, this is pretty heady stuff for an 18-year-old. And in my estimation…HE’S RIGHT ON!
But, hasn’t this always been the computing Holy Grail? To have something portable you can take with you. Something that’s ubiquitous. Something, similar to, and as simple as the telephone. Just plug it into the wall…and have it work every time, giving the equivalent
of “digital dial tone”. Yes, that’s definitely the idea. But, in my mind (up to now) the quest for this envisioned level of ease and simplicity has not happened.
2. Where We Have Been
I’m over twice Joshua’s age (coming up on the big 52), and I have been in this PC arena since
the early 80’s. I’ve built my own homegrown computer systems (about one every 3 years) and in
every case I’ve struggled! Why did things magically work when I reloaded it for the 5th time?
I did nothing different!
For all those “old-geezers” out there, remember back in the early days. It was jumpers and conflicting IRQ’s. Or config.sys files listing the device driver files that needed to “be loaded in a specific order“. Remember all those memory managers and extenders?
Then along came P&P…Plug and Play that is. Has It Really Ever Worked? Oh let’s not forget the dreaded DLL. The one that every software vendor on Earth has the opportunity to overlay with his own version — breaking everything!
No things really haven’t gotten much easier. BUT, there are some recent developments on the scene that have the opportunity to change things and make things much more seamless. And that THING can be expressed in one word……CHIPS!
But before delving into the meat and potatoes of this proposal I want to go back to my very first computer and explore a powerful concept that permeates the computing landscape. This is a concept that has wide ranging implications towards what I’m about to present.
3. What the Heck’s an “Escape Sequence”?
My Dad worked his entire career for IBM. And as soon as the Original IBM PC hit the scene, he got on the waiting list to purchase one. Finally, it came. The printer it came with was the IBM Epson Printer (dot matrix, 80 characters per second). It ran off the Parallel Port…but for our discussion, let’s assume it ran off the Asynchronous Serial Port.
Of course the first thing I did was to learn the IBM Interpreted Basic Language and make the printer print something. I soon grasped the concept of “escape sequences”. Escape Sequences are “non-printable characters” that can be randomly intermixed with the other “printable characters”, to do things like: Turn On wide character printing, Form Feed the paper, etc.
For me, the most important concept I learned regarding escape sequences is this. The printer didn’t know what was attached at the other end of the cable. It could be an IBM PC, an Apple, DEC Rainbow, a Mainframe. Also, the printer didn’t know or particularly care what OS or
Language was running at the other end. The bottom line was that as long as the printer received ASYNC characters at the proper baud rate and parity…the printer would work as designed.
The printer just looked at each character coming in–and it either:
1. Printed the character (if it was printable).
…or…
2. If it was an escape sequence, the printer preformed the “required change of state”.
(i.e…Turn on compressed print or maybe do a form-feed)
…or…
3. If the character were unrecognizable, the printer would simply ignore it.
It would just figuratively drop it on the floor…and then go on the next character.
The second most important point of all this was the following. The designers of the printer only
had to test that printer a single time. As long as the characters coming into the Printer met the
Physical Connectivity Specifications of Asynchronous Serial Ports–that printer would work as
specified. And as new computers, OS’s or Languages came along; the only reason to retest the
printer would be to uncover bugs in the new Computer, OS, or Language.
The sole challenge on the computer side of things was to develop a Physical Serial Device
Driver for the computer’s OS. The main function of the driver would be to provide an API to
allow a language to set parity and baud rate, as well as send and receive characters.
Furthermore, as the IBM line of printers added capabilities, new escape sequences would be
added to what could be termed as “the printer control language”. But these extensions were
always just that…extensions. Another way of saying it is that minus new functionality,
the printer command language was always backward compatible to the previous level.
4. Escape Sequences in the Days of Dumb Terminals
OK…let’s unhook the printer and let’s replace it with an “old fashioned” “dumb terminal”.
A terminal like the DEC VT-100 or WYSE-150. Again with dumb terminals we deal with escape
sequences. There are sequences to blank the screen, position the cursor, reverse video,
blink, underscore, etc.
What do we have to do from an OS perspective to make this terminal work? The answer
is–NADA–or at least not much. We already have a serial device driver to set parity and baud
rate and send/receive characters. At the application level we need to learn a new “terminal
control language” pertaining to the installed terminal (VT100, Wyse150)…but that’s about it.
5. The Original Hayes Smart Modem…the PINNACLE of Escape Sequences
OK, let’s take off the terminal and now attach an original 300-Baud Hayes External Modem.
The Hayes “Smart Modem” represents the pinnacle of the power and ingenuity of escape
sequences. Before Hayes modems, all modem phone calls were dialed with a handset. When the
far end answered, either the handset was placed in “a cradle”, or a button on the modem was
pushed to “take over the call”.
In the Hayes modem, touch-tone capabilities were embedded into the modem itself (for
embedded dialing capability) and the modem operated in one of two modes. “AT-command
mode”…or…”pass-through connected mode”. When first powered on, the modem was in
command mode, ready to accept all characters in what amounted to “a string of escape sequence
control characters”. They wer more commonly known as “AT dial command strings”. In this mode
the modem could “dial all by itself” as well as send back return/progress codes of the
dial/connect process. When the far end answered and “Carrier Was Established”,
the modem switched into pass-through mode.
Other modem manufacturers copied the idea with their own but different command sets–IBM
being the best example. However, IBM’s modems failed miserably in the marketplace. They
were good modems, but, the “command set non-compatibility issue” lead to their downfall.
Again, from the OS perspective, the driver for a serial port was accomplished back at the printer
example. It’s only the “modem command language” that presents a one-time challenge. And if
all modems utilize the identical command set language, the challenge needs only be faced a
single time.
6. The Moral of the Story
These examples show how a single physical connection and physical OS device driver can be
leveraged over multiple hardware devices. The “Physical” device driver development needs to
occur ONLY ONCE. And if the higher level command languages are standardized for each
device type–those devices essentially become Plug n Play accross any conceivable combination of… computer, OS and programming language.
7. How Powerful Concepts Tend to Repeat Themselves
We’ve alluded to the power of escape sequences as they relate to hardware connectivity. What
other manifestations of this concept can we identify in the general computing scene?
What about Ethernet? Couldn’t we consider the header of the Ethernet message a form of escape
sequence (containing control info–specifically destination address)? Extending on this theme
of enveloping data–what about IP? The entire Internet runs on this concept. Has the architecture
of the Internet ever had to worry about the trivialities of what kind of computer hardware, OS,
or applications are running at the host/user endpoints? Of course not — the Internet as we know it would never be possible!
What about the “markup” in HTML or XML. Markup sure looks like escape sequences. The whole Web
and HTML Browser technologies are based on it. And again, all of them are there tofacilitate
functionality…A One Size Fits All environment!
8. Time for the Meat and Potatoes
Now that we’re in the right frame of mind let’s put on our hardware designer hats. First let’s
select a transport mechanism that presents the flexibility of the old serial port. Three
options immediately come to mind: Gigabyte Ethernet, Serial Bus 2.0, and Firewire. Let’s choose
Firewire (just go with it for now…it’s the concept that is important.)
Now, let’s build the piece of the new hardware system that will, in the words of Jonathan Boyles,
“allow us to carry with us all of our programs, files, context…etc.”
We’ll start with a PDA sized box containing:
– A CPU (either an Intel, AMD, Power PC, Strong Arm, Mips…pick your poison.)
– A 30 gig. IDE mini-hard drive (loaded with our favorite OS…any one will do.)
– Flash Memory containing enough BIOS to run a POST and Boot the OS off the Drive.
– 1/2 gig. of DRAM.
– Time/Date chip with 10-year battery to constantly track date/time.
– A Firewire chip.
– And finally, a single Firewire port in the side of the box.
From a Physical Device Driver perspective our OS needs concern itself with primarily 2
physical device drivers. One to talk ATA/API to the hard drive. The other to talk to the
Firewire chip running the Firewire port.
Now, let’s build a second box. We’ll call it the “Base Station”. It’s the piece that sits on our
desk at home, office, library, dorm, hotel room, etc. It will include:
– A power supply.
– Multiple Firewire ports on the front panel that serve as Firewire Bridge Ports.
– Ports on the back: Ethernet, Cable modem, DSL, Telephone Line, antenna for wireless.
Now with a Firewire cable in hand, lets connect our Personal Box (PDA) into one of the Firewire
ports on the Base Station front panel. Immediately, power flows into our PDA through the 2
Power wires in the Firewire cable. The Firewire Specification actually calls for ports and cables
to optionally source some fairly decent voltages and amps, so for our needs the PDA will be
totally powered off the Base Station.
The CPU comes to life…BIOS runs POST…Boots OS. At this point the OS just sits and waits for
interrupts raised by incoming messages on the Firewire port.
Now let’s connect our “Open Firewire Peripherals”.
Firewire Keyboard:
– Connect a Firewire keyboard to and empty port on the Base Station and hit a key.
– The resulting scan code is enveloped in a header that identifies it as a keystroke.
– The message is sent out over the Firewire Bus addressed to the PDA.
– It comes into the PDA port and the Firewire Chip sends an interrupt to the CPU.
– The Firewire interrupt handler looks at the header for the “message type”.
– Seeing it is a key stoke it takes the data and stuffs it into the keyboard buffer.
Firewire Mouse:
– Connect it up.
– It follows exactly the same principle as the Keyboard–but with mouse packets.
Firewire Printer:
– Connect up the printer.
– This time run a program to send print data within Firewire Packets to print on the printer.
– Since most printers are PCL compatible, your print data packets need to include any of the
proper PCL escape sequences.
Auxiliary IDE compatible…Hard Drives, CD, CD/RW, DVD, Zip Drives…etc.
– Just plug into one of the base station Firewire ports.
Currently available Firewire to AT/API “tailgate chips” allow these to work seamlessly.
Firewire Scanners, Digital Cameras, etc.
– As before, just plug into one of the base station Firewire ports.
In all the above instances the Physical Firewire Device Driver that is resident in the PDA must
look at the incoming “Packet Types”. Then it simply acts as a “SUPER DUPER ROUTER”–routing data
to the proper application or internal buffers. Going the other direction, outgoing messages
have to be enveloped in the correct packet-type and routed out correctly.
Any “control language” tied up in the operation of the various hardware peripheral devices must
be embedded within the raw message data itself and standardized and documented so that
Software/Subsystems/and High-level Drivers can deal with the commands appropriately.
9. The Hard Part
As in all things…some pieces are easy…and some not so easy. The above devices strike me as
being fairly straightforward. But when it comes to Video Display and Sound–there are more
hurdles to overcome.
Sound is problematic in that I don’t clearly grasp it from a low-level standpoint. Sound,
especially the sound chips are extremely proprietary. And in reality, anything analog is totally
out of my realm of knowledge. So I’m just going to ignore it for now, and assume it can be
packaged-up and shipped-out over the Firewire.
From a Video Display standpoint, what I see as necessary is the totally new creation of a
“Standardized Graphical Command Language” used to drive the equivalent of a “Graphically
Capable Dumb Terminal”. Here too, I am a bit fuzzy on what, if anything, is currently available
out there in the marketplace. Does X-Terminal qualify? How about whatever runs that Windows
Terminal Server, MetaFrame, Citrix Systems thing? What is that? Is there an equivalent of a
“graphical terminal” used in that environment?
I believe that whatever would work needs to have a fairly “lean” “low-level” command language
providing capabilities like block-fill with color, line and curve drawing, BitBlit capabilities.
Low level 3-D may or may not be out of the question. What is not desirable is some large
piece of bloat. In this case, I see leaner as better.
Of course this display–whatever it is–would simply plug into the Firewire port.
10. Variations on a Theme
Having brought up Windows Terminal Services and Citrix in the previous section, let’s
momentarily shift gears.
Lets assume we’re at work. Let’s unhook our PDA from the base station, and keeping everything
else the same, replace the Firewire chip in the PDA with a Gigabyte Ethernet Chip. Then let’s
remove the outside covering and repackage our PDA into a “Blade Configuration”. Make the
Blade capable of being inserted into a huge rack along with hundreds of other blades in the
computer room of the large corporation we work at.
Now let’s connect each blade into the Gigabyte Ethernet Network running throughout the
building. At the desktop let’s connect the Base Station to the Ethernet network. Now assuming
correct addressability, the Blade directly communicates to the Base Station through the network.
A SINGLE TRANSLATION that bridges packets from Ethernet to Firewire must occur upon entry or exit
to the base station–before the packets hit the peripherals.
Of course what I’m describing goes by many names…Thin Client, Network Computer. But the overall concept survives package modifications–BLADE or PDA–everything works identically!
11. Conclusions
With the exception of a readily available “Graphical Display Terminal” and accompanying
“Graphical Display Command Language” it would seem to me that the possibility for this type of
architecture is well within our grasp.
The advantages are:
– Portability.
– True Plug and Play Compatibility.
– Flexibility in Physical Topology and Component Packaging.
– Peripherals increase in overall market scope leading to lower costs.
– Hardware (CPU), OS, Programming Language is totally neutral!
Early on I alluded to some current developments in chips that could be used to drive this vision.
Briefly some of the developments in Firewire chips deal with the concept of “tailgating”. For
instance, chips combining Firewire/ATA/API capabilities allowing for currently available IDE
hard drives, CD, and DVD drives to operate seamlessly over the Firewire. Or another class of
Firewire chips facilitating the streaming of A/V Mpeg from digital cameras. And, in addition,
the advent of open software specifications such as OHCI 1.1 and SBP-2 that facilitate the
utilization of these new firewire hardware chips.
But I’ve already gone on too long–and those discussions are full-blown papers in themselves.
In conclusion, the realization of the dream is to: Preserve personal preferences at the OS and
Application Level, and take advantage of cheap readily available OPEN PERIPHERALS, all in
a simple, fool-proof, PnP environment.
Or as Jonathan Boyles puts it–“To be able to work on your stuff everywhere!”
About the Author:
My name is Jim Kirkley from Columbus, Ohio and I have been employed in the computer field from the early 1980’s. I have been involved in programming everything from IBM mainframes and Series 1’s to PC’s and proprietary point of sale systems.
I enjoyed your article, and it’s something I’ve had a gripe about for a long time. It would make sense to me (and be much easier for the OSs) if, instead of the OS interpreting the electrical signals from the device according to software which must be intalled, you should have the electrical signals sent from the device standardized, so that everything is natively supported, which is exactly what you said (I think). You would have one driver for everything (well, one for every type of device).
Joshua Boyles
SCSI, IDE, ehternet, IEEE1394, PCI, etc are all standards.
vacuum tubes for the most part, agree upon 6.3Volt and 12.6 Volt filament voltages.
That’s what we have now! First, one comment: the whole thing about “escape codes” is an inversion of a general concept. Escape codes are merely a primitive subset of the idea of mixing control information with data, which is common to all computer protocols. Next, our current computer interfaces do this already. Both Firewire and USB have device classes and device class drivers. For example, there is the USB-HID device class, which encompasses all sorts of peripherials, like joysticks, mice, keyboards, etc. The device sends packets (command headers wrapped around device data) over the USB bus, and the USB-HID driver recognizes the specific device protocol and processes those packets. Thus, you can write a USB-HID device once and have it run any USB-HID device. Same thing goes for USB and Firewire mass storage devices, IDE and ATAPI devices, AC97 sound devices, etc.
The only constant that exists in the universe is “change.” The fact that the only way computer and computer peripheral hardware companies stay in business is to continually reinvent the mousetrap. Compatibility sounds great, but competition — newer, bigger, better, faster — is how these companies stay in business. We live in a market driven world. It’s the way of the world. People buy what is hyped to them — always have and always will.
A Corporation can decide to purchase a truckload of computers all built the same way with the same hardware and software. Ultimately, they can because one person or a group can say its so, and it is. Everybody in the same company can go anywhere in that company, get on a computer and have compatibility. Take it out side into the real world where competition dictates what is being pushed and sold to the masses and now you have a problem.
Everyone in the world would have to update. That is not likely. There are still people out there using Tandy HX1000 boxes, and happy to never change. I know, that’s a real stretch, but that’s reality, and that’s my point.
The clincher will be to get all the companies who make billions of dollars a year to change the way they do things. In other words, they would all have to agree to throw out the baby with the bath water. No more newer, bigger, better, faster to drive there multi billion dollar money machines. Right? Like that is going to happen. Remember, those companies are the ones who pay for those cool TV commercials. If their stuff wasn’t different (better, bigger, faster, “NEW”) then how could they get Joe chump to buy a new computer every two years and give the old one to Goodwill. I don’t know about your area, but here where I live, thousands of people who worked for these computer companies and got laid off a year ago are all losing their homes.
On the other hand, this could work as a grass roots movement, kind of like Linux. The problem is, you are talking about hardware. I for one am not able to produce a cdrom drive, or a sound card, or any other piece of hardware. Have you ever seen what it takes to produce a circuit board?
Who are these people who are going to throw away the status quo, break with competition, and risk building only one or no driver hardware.
On the file compatibility end, I can tell you right now, MS doesn’t want their file types to work with anything but their software. There are some nice pieces of software out there come very close to opening a .doc file without losing format, but don’t bet your two hundred page legal brief on it. It’s hard to get off death row once you’ve been sentences.
Good Luck. It’s a nice dream, but communism went down in the beginning of the nineties. Short of an all-powerful central governing body to enforce the guidelines it would take to make this all happen like they do in China – well? Huh!
Hi Jim, your trip down memory lane calls for a parallel example: the telephone.
Joshua, please ask your parents about telephones that actually *dialed* and had these funny swiggly cords between the handset and the telephone — image uncordless and unhandsfree! Not to mention they were only found in fixed locations…(heard that?!).
What is really different Chris? People are still just talking on the telephone…
Basic Darwin Natural Selection Internet Forum Survival of the Fittest Human Technolgy Evolution Postulates (Wow, now that’s a stretch! 😉 ):
1. The strong get stronger
2. The weak die
3. Mutation occurs
The act or process of being altered or changed in genetics involves the change of the DNA sequence within a gene or chromosome in an organism that results in the creation of a new character or trait not found in the parent. Lets look to the computing world described as a strand of DNA in the day-to-day *life* of people — we just need to *arrange* things…;-)
The things people do will not change in the normal course of events, but how they are done will if the *new* way is arranged better, more conveniently, cheaper, easier, anywhere, anytime, etc. The key: do the same things better! These small shifts can give way to big changes.
The key question for us today is where and when — first. Will the technology discussed by Joshua and expounded on by Jim need to make its own proverbial trip to the Galápagos Islands (controlled environment) or will we find a way to do things on the “fly” here, right where we are?!
Thanks Jim and Joshua, we appreciate your musings. Narrowing things down to where and when are easier once you know what, why and how.
Raquel and Bill
http://www.pegasosppc.com
Jim,
had the same idea one year ago, started to write but never finished it.
It’s nice to see that other people have the same ideas.
When I did my research I found out, that such a system, specially transporting Real-Time-Audio and Real-Time-Video could only work with Firewire never ever, with acceptable results, over USB.
Firewire uses similar technical principals as SCSI, two clients can send data back and forth to each other without sending the data to the CPU.
Under USB the data always runs through the CPU even when 2 clients talk to each other. Intel invented USB specially to use the CPU, a powerful CPU from Intel!
Also I placed the Graphic card into the TFT screen (there should be a AGP slot or so insde the screen…)
BTW:
What I don’t get is why we have all these different serial connections -> Firewire = one size fits all!
No serial ATA needed. No USB or whatever.
Every hardware could be connected over Firewire.
AFAIK Apple already has Firewire/800 and Firewire/1600 is planned.
If SONY can send Real-Time-Audio and Real-Time_Video over Firewire/400 than the next computer generation could be a Firewire/1600 only computer.
But the BAD thing would be: after 10 years your old hardware would work excellent with the newest CPU Extravaganza with 50GHZ and this would be bad for the industry.
I actually had a similar idea once too, except I wanted to use it to build a completely modular computer rather than a portable one.
The concept of embedding device driver in the devices such as USB printers, PCI modem, LCD display and even motherboards is a great idea. Think of such device which you don’t have to hunt for device driver and the devices will install for u. The embedded device driver should also support future versions of OSes. and this is mere a concept so dont take it seriously.
In the non computer world nearly everthing is standardised from appliance voltages, vehicle emissions, dimensions of beer cans etc. PCs are increasingly conformist – no ADB or NuBus ports on Macs, common ATX form factors, slots etc. Eventually computers will be completely generic and standards compliant in operation like telephones, TVs and toasters.
Do you have any *idea* how much bandwidth a graphics card needs? At best a monitor link can provide maybe ~200MB/sec of bandwidth. We’re talking AGP 1x-era bandwidth here!
And what one has to do when the driver is buggy? Download the updated driver from the internet and replace the old one with the new one? Becomes the same thing the we are already doing… Or your printer downloads the updated version and updates its internal memory and then installs the updated driver?
its all about these interface chips for the first generation. You need to have 2 things, a standard interface and a standard protocol. for instance.
Gigabit ethernet for the interface(more below)
A new, low latancy protocal for communication over the wire.
Gigabit ethernet could be changed to a new, smaller connector for convienience in small devices. Every device would have a Gigabit ethernet port on in and a “translator” chip. This chip does one thing, translated the devices native language into the standard protocal and sends it out over the wire. All vendors could build their own protocals and interfaces however they liked, as long as the connected to the translator to send over the wire.
consider than gigabit is not the best solution for this, a higher speed seriel link would be preferable like 10Gb line because a 1600x1200x24bit colour image would saturate the wire if it were uncompressed.
be sure to provide power over the wire as well, for small devices, keyboards, mice, etc. Make all hub devices switches. Allow various levels of compression to be used by the “translator” chips, each generation could include better compression and higher clock speeds with autosensing of compression and clock to keep backwards compatability.
also, allow every device to have a static but adjustable address with number ranges based on device type. i.e. 10xxx for keyboards, 11xxx, for mouses, etcetc. Each server device you be able to autoidentify and enable anything directly plugged into it, but also be able to “grab” controll of a device over the network by address. This way a device may be controlled from accross the facility and also displayed accross the facility. make controll and display devices operate together on a local switch basis, so if a keyboard has controll of a blade somewhere else in the building, the local monitor and mouse will also gain access, as well as the local CDrom, printer, scanner, etc if available. that adds a number to the address field for switches, but that is transparent to the user. another option would be to not give addresses to individual devices but only to switches and have an LCD interface to select address of the server machine and compression levels, passwords and access rights, etc etc. maybee even a flash card/smart card slot for security uses and also offline file storage and personal settings.
their would be no device specific drivers. each device would interface via the standard protocal for that type of device. Like printers or mouses. each advancement in the interface would include an updated interface to expand options available in new devices, but remain backwards compatible with old devices by still using the base set of calls. to print you would require just a single print driver than would allow you to print on all printers.
profit is made by differentiation
VGA with 16 colors is pretty much the common ground, did you use that mode to view this site ?
Deep wrote:
> Think of such device which you don’t have to hunt
> for device driver and the devices will install for
> u. The embedded device driver should also support
> future versions of OSes.
Dano wrote:
> their would be no device specific drivers. each
> device would interface via the standard protocal
> for that type of device. Like printers or mouses.
> each advancement in the interface would include an
> updated interface to expand options available in new
> devices, but remain backwards compatible with old
> devices by still using the base set of calls.
Both concepts are already specified, and mostly implemented, in the Uniform Driver Interface (UDI), which is gleefully ignored by the masses (even among OS alternative advocates around here) and actively flamed by the FSF because it doesn’t fit their picture of “free” software.
🙁
at least, to an extend.
sorry for putting my favorit os ahead: linux (no flamewar intended)
with linux you can already be anywhere on the world and log in to your own pc with your own files. You have a X display manager running on your PC and on the one you’re sitting at that moment you just download an X-Server and connect to your PC. So you have a local keyboard/mouse/screen and the rest is working at home.
even sound can be local when you use N(etwork)A(udio)S(ound)
Printers can be used locally with Samba over TCP.
i realize it’s not exactly what is described here, but the fundamental thing, that you can work everywhere on your PC is the same.
Like the firmware some device needs to work (a firmware is basically a program for the device to adapt to the computer language), we could have embedded java or .Net or whatever pseudo-assembly-based driver inside the device.
The device is plugged, the computer loads the driver, compiles it in native format or keep it interpreted, then begins transactions with the device.
It needs a common framework for driver though.
But for now, the USB protocol is well designed. If only device manufacturer could only use standard USB-class, we wouldn^’t need that much drivers.
No wonder the Linux crowd flames it, the site is hosted by Caldera!
isn’t this sort of like I2O hardware? all the hardware spesific stuff in on the hardware and there is a generic public interface for a programmer to use to make the computer talk to the hardware.
>> “Both concepts are already specified, and mostly implemented, in the Uniform Driver Interface (UDI), which is gleefully ignored by the masses (even among OS alternative advocates around here) and actively flamed by the FSF because it doesn’t fit their picture of “free” software.”
UDI isn’t exactly what those two guys described. UDI is a way to write drivers once for all OSes, but specific to a hardware version/vendor. In other words, under UDI you could have 30 different sound or video drivers, or 300 different NIC drivers. What the guys were describing is devices using one common set of commands, therefore requiring only one NIC driver.
Combining this open hardware connection idea with UDI, it would mean we could have a single driver working under all OSes. It still presents a couple of problems, since UDI is expecting x86 hardware IIRC, rather than using some VM bytecode.
First of all… as for being able to carry your “stuff” everywhere you go… I don’t want to do that… carrying means that one could potentially lose their stuff along with the hardware it goes on. The future I would rather see is some easy to set up home information server which would let you access your ‘stuff’ from anywhere that has a net connection.
As for the device interconnection… I don’t know if I even want to see that happen beyond the level it’s almost already at. Right now I have a USB keyboard, mouse, printer, wacom tablet and gamepad hooked up to my computer… to me that’s pretty d@mn good. Then when I need more bandwidth for stuff such as expandible storage or video I can switch over to Firewire. Sure it would be great if there was some connection bus that had so much bandwidth it could suit every possible need… but that’s just not how I’ve ever seen the computer evolve. Someone is always coming up with a way to do things faster.
3rd. this wouldn’t be great for everyone. Being someone who works with 3D models a lot, generic computers would all this universall interface trickery wouldn’t do diddly squat to help me work on my ‘stuff’ I gotsa to have some decent 3D capability and a decent monitor.
Your PDA device appears to have no support for high-bandwidth peripherals. For example, how would one use your device with complex 3D GPUs like those found in the latest generation of games? In your idea the GPU and its related circuitry would be located in the base station, and the only link between the game on the PDA and the GPU in the base station would be a relatively slow Firewire connection. And what is the latency difference between an external connection like Firewire compared with an internal connection like PCI-X?
Of course one might argue that your PDA is just a portable home directory – a sort of hot pluggable Firewire drive. It does not need an operating system, CPU, or RAM per se, but would fulfill your expectations if both the base stations and the PDAs maintained a standard interface for storing and retrieving user documents and OS-agnostic preferences. You could plug your PDA into any base station and the base station would automatically retrieve your theme, mail client settings, mailbox, wallpaper and other OS-agnostic settings as well as provide you with access to your documents and all your personal data.
Thanks Jim for a great article! One reader submitting a fascinating article and then another submitting one building on the first – that’s OS News at its best!!
Dano and Charlie Mac,
We are with you there! WIFI and smart cards.
R&B
http://www.pegasosppc.com
The “Physical” device driver development needs to occur ONLY ONCE. And if the higher level command languages are standardized for each device type–those devices essentially become Plug n Play accross any conceivable combination of… computer, OS and programming language.
Its this formalized division of purpose that SciTech SNAP is built on… as long as the physical device never changes then nether should its associated device driver. Changes made to an already supported OS for the most should have no impact on the physical devise driver and as such are isolated in a separate OS shell driver.
Anonymous wrote :
>In the non computer world nearly everthing is standardised >from appliance voltages, vehicle emissions, dimensions of >beer cans etc. PCs are increasingly conformist – no ADB or >NuBus ports on Macs, common ATX form factors, slots etc. >Eventually computers will be completely generic and >standards compliant in operation like telephones, TVs and
>toasters.
Then if PC are more standarized, explain me why are there so much bugs on PC that are explained by “weird/strange” hardware.
Another thing, Mac are evolving, Macs are using PCI and AGP now, but some graphic cards have a special Mac version, with a specific bios.. If PCI and AGP are standards then why ?
Another thing, Mac are evolving, Macs are using PCI and AGP now, but some graphic cards have a special Mac version, with a specific bios.. If PCI and AGP are standards then why ?
PCI as a spec defines that the firmware of the device be in Forth bytecode and that the underlying architecture support the interpretation of this bytecode….. unless the processor is an x86. In that case, the firmware is just x86 machine code.
Not sure if AGP is the same, but I understand that as a spec it builds upon PCI so it probably is the same story.
Speaking of which, it’s nice to see editorials like this, but the bottom line is that it doesn’t propose anything new. Solutions very much like this have been proposed and even implemented dozens of times before but have fallen short on adoption because of market forces. And for good reason! 90% of the time when a spec is abandoned there’s a good technical reason for it. It’s frustrating for sure but you have to be crazy to believe that this industry with it’s preposterous rate of change could lock down on a total ‘Universal’ standard.
good God, does this thing need an executive summary.
Thanks everyone for their input.
I’ll just take a few lines to make a few observations.
In an early post, Rayiner Hashem pointed out that, “escape codes are merely a primitive subset of the idea of mixing control information with data, which is common to all computer protocols.” Of course he caught me “red-handed”. I was really using the escape sequence idea as a “straw man” to get the brain cells working regarding control information as it applies to its use in perpherial hardware devices.
More than once it was pointed out that bandwidth would preclude this as anything approaching what is possible in todays PC’s. Again that is absolutely correct. I have a friend who is a big-time gamer. He says his PC sounds like a jet winding up when it’s turned on. Those new cooling fans remind me of the turbo fans on that tank killer fighter jet…the warthog.
Yes, the game arena (or anything 3D video intensive) will never work. And because memory is not getting much faster all sorts of optimizations are being offered. Things like double data rate DRAM and “ever wider” front-end buses as witnessed by the latest crop of Intel CPU’s and Chipsets. Even AGP 8x may at some point become the bottleneck.
But, maybe there’s a work around. Say there’s a follow-on to the X-box. A single board(no slots). An Intel/Nvidia whopper. No AGP at all. Just a superfast, superwide(256 bits) local bus between CPU, Video Chip, D-ram, and Video ram. Also an embedded hard drive and power supply. Two ports on the back of the box…VGA and Firewire. Your have all your bandwith to video and hard drive self contained. All your other perpherials are Firewire connected off the base station.
The best part of this is, when Johnny loads his brand new game and trashes the hard drive, or one of the turbofans blows a bearing sending everything crashing in flames, no one really cares.
Mom and the girls have their own PDA’s (self contained hard drives) with all their recipes(I am NOT a chauvinst…it was stupid Johnny that caused all this!), home work, and term papers intact. Just unplug Johnny’s smoking cinder from the base station…plug in the PDA and away you go. (Do you really think teenagers have the sense to do backups?)
I must admit, some of the other comments left me scratching my head…things like somehow effecting(trashing) file system and document compatability?
Finally, some said this would stiffle competition, cause companies to go out of business, people lose their jobs and homes, compainies to fail. Others opined that we already have standards…that all that was proposed was was “already here today”.
My opinion is that we “aren’t there yet” and this will not stifle, but will actually foster competition and new innovation. I hope to be presenting some of my thoughts in these areas in follow-on Part II.
Anonymous wrote:
> if PC are more standarized, explain me why are
> there so much bugs on PC that are explained
> by “weird/strange” hardware.
Because most of today’s hardware (sic!) isn’t standards compliant.
With the power of electronic technology, it makes really no sense to think in terms of Central Processors managing remote peripherals. Move the smarts close to the device! Devices should have sufficient processing power to not only perform their basic function, but should also be situationally aware so that they can update themselves and adapt to changing conditions. For example, devices should be able to phone home to their manufacturer’s web site and see if they need a driver update. They should be able to operate over multiple wire protocols (USB, Firewire, whatever) and negotiate their service delivery with other consumer devices. Let’s make hardware services more autonomic and dump the ‘peripheral’ term completely. That term exposes a CPU-bigoted mindset, to a printer, the act of printing is not peripheral at all, it is its reason to exist.
I am encouraged that this is happening. The costs of support far outweigh the costs of manufacturing and sales for many high-tech products. It just makes sense to enable these devices to manage themselves and learn to adapt.
The article was good. Apple is heading in this direction already with Rendevous (open source). And Bluetooth. And WiFi (for several years now). And OS X (including Darwin and Quartz). And whatever they announce next.
Rendevous: http://developer.apple.com/darwin/projects/rendezvous/
Bluetooth: http://developer.apple.com/hardware/bluetooth/
I liked this concept the first time i heard it. When I sought the opinions of other “computer savy” I remembered why I never read the comments.
Most people were negative and focused on why it couldnt be done. Complete non-constructive banter. when i tell my linux friend, the guy who got me into alt. os, about something another non-linux-os does better I get the same kind of arrogance. No one like any idea they or thier particular group didnt come up with. This is the same reason one guy can wright Atheos, but an entire community cant do better than rpm’s cli for the most basic functions.
Linux is an excellent operating system, but the fact is 99.9% of the globe, as of today, will prefer windows when they have to get their hands dirty at all.
It doesn’t take a science fiction novelist to figure out computers will one day be as small as a credit card. In the not too distant future, the computer u are using today, with all its processing power, will fit inside something the size of your wallet. These new gameboys have better graphics than my old 486sx33 could ever pump out. Its the trend.
So what the hell is everybody talking about?
Chris:
“Compatibility sounds great, but competition — newer, bigger, better, faster — is how these companies stay in business.”
Take the word bigger out of that sentence right off the bat, replace with smaller. Now think back to setting jumpers for comm ports and irq’s on 2400 baud modems. Modems have gotten smaller and more compatible while at THE SAME TIME becoming faster, and as a result BETTER. I dont see the problem?
You dont think there is a market for, say, large businesses and universities who have to supply their employees/students with pcs. why not give them what is the future’s equivalent of portable HDs, while dumb terminals do all the simple stuff you need. At home you can have whatever you want, the best monitor/GPU/sound card, at work/school you get what they give you.
There is still a market for hardware and a market for edge computiong systems. Hardware manufacturers may not like it, but they will adapt, or it will come out of the OSS comunity.
And is it just me or did beos work out of the box after 15 minutes of install, on udma-33 hardrives in about twohundred megs, five years ago. Imagine how fast you could essentially just reinstall a system on different hardware, storing the the OS in RAM memory using 128 bit MICROprocessors, with all your bits moving around on cooler-than-dr.-evil’s-shark’s laser. Will it be done like beos did it in ten years? No, but the point is we have the ability to do this right NOW.
Oizoken:
“sorry for putting my favorit os ahead”
I agree. Xdmcp worked just fine when I finally got it working last year. (I must be becomming a geek cuz no one spends that much time getting anything running “just to see”)
Charlie Mac:
“First of all… as for being able to carry your “stuff” everywhere you go… I don’t want to do that… carrying means that one could potentially lose their stuff along with the hardware it goes on”
You missed the point. No one said you couldnt back-up anymore or even have two “blade” cards.
null_pointer_us:
“For example, how would one use your device with complex 3D GPUs like those found in the latest generation of games?”
If I can have “all my stuff” on one card why cant I have a driver for my GPU on it too? Heck if my boss lets me play doom V at work, i can have a driver for his hardware too.
Jim Kirkley:
“But, maybe there’s a work around. Say there’s a follow-on to the X-box. A single board(no slots). An Intel/Nvidia whopper. No AGP at all. Just a superfast, superwide(256 bits) local bus between CPU, Video Chip, D-ram, and Video ram.”
Yeah, lets make the whole thing outta those!
————-
In closiong, I know less about computers than anyone else who has posted on this article, but in a way I think that helps. Hope my first post was a good one. Is this what you guys call “flaming”?