Three travelers stop at a hotel for the evening. The manager offers the travelers a single room at a cost of $30, to which the travelers agree, each paying the manager $10.
Later that evening the manager realizes that he has over charged the travelers for their room: the price should have been $25 rather than $30. The manager calls the bellhop over, giving him $5 and instructing him to take the money up to three travelers as a refund. On his way up to the travelers' room the bellhop considers that there is no even way to divide $5 between three people, and decides, in the interest of civility, to keep $2 for himself as a tip, giving the travelers' only a $3 refund
When the bellhop gets to the room, he gives the travelers their $3, which they divide equally amoung themselvs, $1 per person, and everyone is happy. Here, however, is the problem: Each traveler has now paid $9 ($10-$1=$9), meaning that they have paid a total of $27 (3*$9=$27) for the room. Add in the $2 that the bellhop kept as a tip and we have $29 ($27+$2=$29). But the three travelers originally paid $30! Where is the missing dollar?
This can be persuaive because it shows a way to use a computer program (gzip) to circumvent CSS when that program was clearly never intended as a circumvention method in the first place. This is an attack on DMCA in the broad, rather than on CSS and MPAA in particular.
First, I'd seriously consider granite. It is available from all regular sources and it doesn't noticably degrade over the 100 year timespan (I did a bit of 'field research' a few years back: comparing the apparant degradataion of tombstones of different materials in local graveyards) If you are really worried about long term readability, you could spend a bit extra for a larger monument with deeper inscriptions.
Another option, that you probably won't find at the regular sources, is glass. Tempered glass several inches thick is unlikely to be easily shattered and should resist acid rain fairly well. The inscription could be embeded beneath a clear outer layer to add some extra resistance to environmental damage. I haven't any idea where you would go to get a glass tombstone, or how much you would expect to pay.
A fair number of 'us' haven't been using "8.3 filenames" since we started computing back in the eighties. The only place I have ever been forced to deal with "8.3", as you correctly point out, is on certain, particularly benighted, file repositories that either cater to, or run themselves, a certain, unmentionable, glorified program loader from a company in Seatle.
The main reason that we can't get rid of such trash is backward compatability: any file wandering across the net must be named in such a way that the system supporting the shortest maximum filename length can store that file, even if only momentarily. This is the same reason that we have uuencode and base64, and that various kinds of file metadata (unix permissions/ACLs, VMS generations, Macintosh resources and creators/types, etc.) don't travel well. Without some form of encoding all these nice extra bits get stripped off as soon as they pass through a system that doesn't know what to do with them.
Yes, similar techniques are used to identify chemicals all the time (and have been for at least the past 30 years). In fact, identification of materials through chemical reaction is only the crudest manner of identifying materials. Try doing some google searches on the spectroscopy, spectrometry, spectral analysis, mass analysis, chromatography and chromotography (note the different spellings: chromo versus chroma). These methods make use of non-chemical atomic and molecular properties (the mass of atoms or molecules, absorbtion or emission of various frequencies of light by atoms' electrons or by certain molecular bonds, etc.) to identify the components of test samples and how the compenents are arranged.
In order for Moore's law to dictate the half life of the "digital divide" it would need to say something about the rate of decline in retail price of computers. Unfortunately, that is not what Moore's law talks about: it says that the feature geometry of integrated circuits doubles every 18 months, which is only one factor in the retail price of products which use integrated circuits.
The actual half-life of the "digital divide," as measured by the price for an entry level home computer, has been declining steadily since the mid-'80s, but not by 50% every 18 months. While you may be able to purchase twice as much of any given computer resource (memory, storage, instructions-per-second) every 18 months, this is not due to a decrease in system price, but to an increase in system performance, while prices stayed, largely, fixed. The actual rate of decline in the price of computer systems is more like 10% per year, over the past 15 years, which makes the half-life of the digital divide something more like 5-years (especially when we also account for wage and price inflation).
With a half-life of 5-years, the "digital divide" will be essentially gone (less than 10% of the world population will be offline) by 2050. Long before then, however, the "digital divide" will have lost any political power it may currently have: by 2010 we can expect that less than one quarter of the world population will be offline.
It's often hard to think outside the box when you've become accustomed to doing something one way for so long. The current state of GUI's seems like 'the right way' now, but that could all change in 5 years.
Although my reflexive response to this is "5 years? Unlikely!" I think you have a very good point. A moments reflection on the grand sweep of human computer interfaces (HCI) is instructive:
1950-1970: sequential batch processing
1968-1988: interactive command lines
1984-????: windows, icons, and mice
Note that each major era of HCI is roughly 20 years (maybe not coincidentally the same a one human generation), which means that we might expect the current HCI model, windowed GUIs, will be replaced by something else around 2005 (or a few years earlier, since my table above has some overlap for each 'generation').
Note, as well, that, contrary to Neil Stephenson's well known essay In the Beginning was the Command Line, the command line was far from the beginning...
Your example is a bit contrived, however. For me, writting a letter on the computer consists of:
start word processor
type letter
print letter
Back when I used a typewriter to write letters, however, I had to do the following:
open typewriter case
insert paper into typewritter
type letter
which looks like an awfully similar amount of work. Granted, I rarely turn off my computer, which saves me the step of turning on the computer, but I just don't feel that using the computer has been a net loss in productivity for me, especially if you include the retyping cycle needed because I'm not the most accurate typist in the world.
Essentially, the article says that Raskin doesn't like MacOS X, MS Windows, or any other general purpose operating system for that matter, because he thinks that computers should be pure appliances, relieving the user of having to worry about mundanities like file storage or program launching, rather than infinitely mutable environments. Raskin is a visionary, which is a good thing, but it means that he is concentrating on the future possabilities of ideal computer interfaces, while missing the more prosaic uses of technology today.
Personally, I agree with Raskin on what I would like my computing experience to be like, but I also recognize that we are a long way from making that experience happen in a ubiquitous manner. For the moment, I get more milage out of an OS centric system that provides me with the primitives that can be combined into a tailored work environment (e.g. Linux running X and Fvwm2 with a small collection of application programs and shell scripts) than I would out of a more turn-key system that wasn't designed by me for my own uses (e.g. MacOS, Windows, PalmOS, and even Gnome and KDE).
Raskin is talking about a system that would be preconfigured to do exactly what the user wants to do, but he fails to mention, and possibly fails to consider, that such a system is nearly impossible to produce, simply because there are too many different kinds of user with too many different preferred modes of work. It is much easier to produce a clumsy generic environment that can be shoehorned into many different task niches, than to custom engineer a system and user-interface for each prospective user.
The users that really care about a streamlined work environment (sometimes referred to as Power Users) will take the time and effort to tailor their system to their tastes. The users that don't care, and such users do exist, will either suffer (silently or otherwise) or pay someone else to produce a more tailored configuration for them. (while I am no Libertarian, or even much of a Capitalist, and as much as I hate to point this out, the dominance of generic, operating system centered, computing environments looks like a perfect example of the free market at work)
I like the major.minor.patch scheme, but I like also like to be able to tell something from the version number. Specifically, I want all releases with the same major version number to be backward compatible (stuff that worked with 4.1.x will still work with 4.2.x but may well break with 5.x.y). This equates to the following rules for assigning version numbers:
major version numbers change when an external protocol is deleted or modified in some non-compatible way.
minor version number change when an external protocol is added or an existing one is extended but is still compatible with the old semantics.
patch level changes with each new build. The patch level essentially tells the user that some bugs have been (hopefully) fixed in x.y.n that weren't fixed in x.y.n-1.
Obviously this version number scheme is only really usefull for libraries and client-server systems. If your program doesn't provide an external interface then there is nothing worth keeping track of.
Incidentally, for things other than libraries and servers, I agree with the posters who are saying that version numbers are an antiquated concept (or a marketing ploy) and we should just be letting CVS take care of things for us. Still, there are plenty of folks out there (myself included) who care about what version of a specific piece of software they are using, if only because they know that 3.2.25 was the first release to have the features that they wanted.
This suggests that, even if you normally rely on CVS for version control, you should tag important released with meaninfull version numbers for the convenience of users. For this purpose, however, you might as well go the route of simple sequential integers or complete date-times.
NOTE: where my version numbering scheme is meant to communicate something about the status and feature set of the finished software product, the CVS version numbering scheme is meant to communicate something about the status of the sources with respect to the development process. My versioning scheme doesn't easily support branching of the source tree, while the CVS scheme will be nearly incomprehensible to users for any project of reasonable size. This is why CVS has tags and rtags.
About the time I got my first K6-3D box, and was considering an early Athlon box, I looked into weather simulation programs as a fun thing to run in order to use up all the excess CPU cycles I now had. A number of different packages exist that will produce interesting results, though I don't know how easily they can be made to compile and run on Linux (the problem is finding a good Fortran compiler): NCAR/Pennstate mesoscale model MM5, NCAR Community Climate Model CCM3, and Colorado State RAMS model.
The basic set of books I recomend for a company library are:
The C Programming Langauge - Kernighan & Ritchie, Prentice Hall
The Standard C Library - P.J. Plauger, Prentice Hall
The UNIX Programming Environment - Kernighan & Pike, Prentice Hall
The Practice of Programming - Kernighan & Pike, Addison-Wesley
The Elements of Programmiing Style - Kernighan & Plauger, McGraw-Hill
The Mythical Man-Month - Fred Brooks, Prentice Hall
Peopleware DeMarco & Lister, Droset House Publishing
The Cathedral and the Bazaar - Eric Raymond, O'Reilly & Assoc.
C+C++ Programming with Objects in C and C++ - Allen Holub, McGraw-Hill
Enough Rope to Shoot Yourself in the Foot - Allen Holub, McGraw-Hill
Tog on Software Design - Bruce Tognazzini, Addison-Wesley
Tog on Interface - Bruce Tognazzini, Addison-Wesley
Managing Projects with make - Oram & Talbott, O'Reilly & Assoc.
Open Source Development with CVS - Karl Fogel, Coriolis Inc.
This set covers a wide range of topics, from bare language issues, through design and coding practices, all the way up to project and corporate management issues. You may need to supplement these books with a few more that address specific fields of interest to your business (my list is a bit short on web, C++ and unix system programming books, for example), but these are a good start.
The "thruoughput rate" of floppies is actually on the order of 500KB/sec, which isn't so bad compared to some popular networking media (10BaseT is only able to achieve about 600-700KB/sec once you have factored in protocol and collision overhaad).
Since other devices have been designed to adapt the floppy drive to alternative media (I'm thinking of memory sticks and the like) there shouldn't be too much problem doing the same thing for a networking medium.
The real problem would likely be how to present the interface to the rest of the system: would you use a new disk driver which would translate the local networking API or would the device itself present the network as a set of files on a virtual floppy disk? Either way you have some big headaches if you are going to support more than a few target systems.
Windows CE is more like a full OS, complete with almost everything you can find in the deskstop Windows : installer/desintaller, TCP-IP networking with dial-up wizard, bunch of dll's, desktop wallpaper or a lightweight DirectX.
Which is wonderfull if you want a comfortable desktop/development platform, but next to useless in a handheld/embedded setting.
PalmOS is a pure handheld OS made for handhelds and handhelds only : there's the bare minimum of services and code.
Which is really nice if you want to deploy it on a slimmed down compuuting platform designed to fit in someones shirt pocket and run for weeks on a couple of AA batteries, but sucks some (but not nearly all or even most) other computing tasks.
for a developper Windows CE is clearly better, because it uses a subset of the Win32 API
Ah, this must be some new usage of the word better to which I have been hitherto unaware!
Pocket PC PDAs have larger screens (240x320 pixels and 12 or 16 bits per pixel) while Palm devices have a tiny one (160x160 in gray scale or 256 color). PocketPC have MUCH beefier CPUs, sound, easy connectivity through Ethernet or Modem cards, mass-storage availability (Flash cards or Microdrive, etc...)
None of which are features of the OS, and, hence, are irrelevant to the question that was asked.
Microsoft is giving away the full SDK AND Visual C++ AND Visual Basic for Windows CE (not just the add-on, the full complete apps with cross-compiler and all !).
Or you could use the GCC cross-compiler tools for PalmOS, which are also free and run on some of the most successfull and program friendly computing environments ever written.
If your app already exists as a Visual Basic program, then it will mike porting easier than rewriting from scratch for PalmOS, un C and with a totally different API.
Of course, you will have to rewrite the program anyway, since the assumptions you made about the human interface will likely be completely different in a handheld device that it was for the desktop systems you orriginally wrote the program for.
Overall Palm devices are nice calender/todo/agenda/etc. but they just don't cut it if you want desktop functionnalities.
Which begs the question: why are you targeting a handheld device if what you really want is a desktop?
Anyone who has been using Windows since version 3.1 (the earliest version at which the product was anything more than a joke) then they have, by now, paid between $250 and $500 for the product, if they have been upgrading faithfully. If they made the jump to Windows NT they are probably verging on that magical $1000 mark by now, if they have not already surpassed it.
On top of the outright cost, we should probably be counting the costs factored into bundled hardware sales and third party software development, which I couldn't even begin to compute here. I'll just say that I suspect that costs to consumers have been increased, rather than lowered, by the existance of the Microsoft monopoly.
If Microsoft has anything to say about the matter, every Windows user will be forced to pay an annual fee for the privilage. I don't know what the actual fee is likely to be, but I suspect that it would rapidly accumulate into a sizable chunk of change.
It is exactly the monopoly power that Microsoft wields that will allow them to institute this new pricing scheme.
Software. Use open source. If you need Win32, don't upgrade beyond Win98.
Better yet, don't use Windows at all! If you feel the need for Windows, of any version:
Actively search out open source/non-Windows alternatives.
Run the 'needed' windows software under WINE.
Many 'Windows only' programs actually have versions for use on MacOS. Buy a cheap iMac and run the Mac version.
Third, enter a detox program;-)
Hardware. Never buy RDRAM-based motherboards.
Better yet, never by Intel based hardware (which is the one of the main RDRAM boosters). Try an Alpha-based system, Power Macintosh, or even a Sun workstation. If you absolutely must use an x86 compatible system, get an AMD solution. When the AMD x86-64 stuff comes out definitely get an AMD solution;-)
Music....
Start going to local music events by small, unsigned bands. You might be suprised by how much good music is out there that never makes it to national distribution. Many of those small bands are even able to afford to have their own CDs pressed and sell them at performances.
Movies. Watch'em in the theater and buy DVD's as you see fit....
Watch them in the theaters only after they move to the second string, $1/$1.50/$2.00 theaters or wait for the movis on non-pay-per-view cable or open broadcast TV. As for DVD's just don't buy them at all! If you really care about this issue, you can forego a little bit of entertainment.
Vote....
I can't agree more with this one. If you live in a democratic country and you don't like what's going on, get out there and do something about it. If you don't live in a democracy, maybe you should look into doing something about that as well;-)
Heisenberg's Uncertainty Principle states that certain pairs of properties can only be measured to a finite degree of precision. There are only a few such paired properties: position/momentum and time/energy are the only ones mentioned in my Physics text [Physics for Scientists and Engineers Volume 2, 3rd Ed., 1991 Paul A. Tipler, Worth Publishers, page 1180]. Electron phase is not one of the effected properties, so Heisenberg doesn't seem to be a limit here. Shannon, on the other hand, may have something to say in the matter.
What about Coherent, a V7 clone for 8086/80286 from Mark Williams Corp. and QNX?
I'm a bit suprised that these two are missing, but XINU has made it onto the chart, even though it doesn't show any actual inheritance from any unix strain (and rightly so: XINU's only relationship to unix, aside from the name, was entirely spiritual).
These projects all make use of various methods of sensing user movement without the need to add extra bits of stuff to the person. One of the projects that I have heard about (I think it is part of metaDesk) uses an array of theramin-like* devices to sense the users hand positions over a table top. The devices are able to sense both hands along with palm and finger orientations.
* A theramin is an electronic musical instrument where the musician plays the instrument by passing her hand between a radio transmitter and reciever, interrupting the electromagnetic field and producing various tones and sounds. This is similar to the effect that you can see on either TV or radio reception as people move around relative to the receiver antena (obviously this doesn't happen if you have cable TV).
There is a tool for MacOS called FilterTop which allows you to construct pipelines from special filter programs. You can then drag-and-drop files into the resulting filters (called 'droplets' in MacOS) and have the pipeline executed on the contents of the file, spitting the results out into another file afterwards.
I think that there was something else for the Mac, released back around 1995, that did something similar by arranging icons on the desktop, but I can't find any reference to it through Google.
The cited portion of the @home contract is not preventing users from running a masquerading (aka NAT in the non-Linux world) firewalls. VPN's are a way of tunneling network traffic over a non-secure network in a secure fashion (using encrypted connections/packets) and provide the illusion that many, spatially distant computers are communicating over a common LAN, rather than over the open internet.
There may well be a section of the @home contract that forbids masquerading/NAT firewalls, I know that such clauses were popular a year or so back (mostly specifying that only a single computer could be hooked up to the service, which pretty much forbids masquerading/NAT firewalls) but the cited section is dealing with something else entirely.
Covering the top of your cubical is likely to be a fire hazard, since it would block not only the light from the overhead flourescents, but any water from overhead sprinkler systems (mandatory in most commercial, and some residential, buildings in the U.S.) Rather than violate the firecode by building impormptu structures, I have found that simply removing some of the flourescent bulbs from the fixtures yeilds a very pleasing light level, without an increased risk of fire.
The only problem I have encountered when deactivating lighting fixtures is when my cube-neighbors and I don't agree on the proper light level. A little friendly and reasonable discussion, however, usually goes a long way toward solving and disputes (especially since you can often deactivate just the lights directly over your own cube without affecting the lighing in neighboring cubes overmuch).
First, Apple is at least rumored to have an investment in Transmeta, which suggests that there may be some work being done on a Transmeta based PowerPC. I would expect that, so long as the Transmeta technology (whatever that means) is not too tied to conversion and emulation of x86 instructions (I can think of a number of things that might be done to speed up x86 emulation that would be of no use for any other architecture), emulating any CPU architecture should be fairly simple.
Second, given that Transmeta is trying to keep the ability to completely revamp the underlying architecture of crusoe, I would be willing to lay a bet that they could design a crusoe that would be able to 'emulate' IA-64 with fair performance, (which shouldn't be too hard, since IA-64 is shaping up to be a real dog). As for the current crusoe design, I would think that it probably lacks sufficient resources (mainly too few registers) to run IA-64 code with any efficiency.
Here is a link to anECM scanner (a device that will read the diagnostic codes on modern cars) for only about $500. It looks like it can handle a wide variety of Chrysler, Ford and GM vehicles built between 1984 and 1995.
The company sells a few other interesting toys that could be of use to automotive/electronics geeks.
Otherwise, there are some links I found along the way:
Datalogger a commercial hack from TechnMotive similar to the poster's requrest. There may be other good stuff on the TechnoMotive site.
An overview of electronic engine control from Intel.
I got these links simply by doing a Google search on "engine computer diagnostic". There were many more (about 4000 pages worth) but I got tired of skimming through them (I was averaging about 2 usefull hits per page).
While much of the basics of human interaction and GUIs was worked out years ago (at Xerox and Apple) there are still people thinking of better ways to do things. Check out Bruce Tognazzini's web site AskTog for some coverage of this topic. He has tutorials on user interface design, cogent criticism of current GUIs, suggestions for improvements, as well as sundry and other essays.
Slashdot Mirror
Three travelers stop at a hotel for the evening. The manager offers the travelers a single room at a cost of $30, to which the travelers agree, each paying the manager $10.
Later that evening the manager realizes that he has over charged the travelers for their room: the price should have been $25 rather than $30. The manager calls the bellhop over, giving him $5 and instructing him to take the money up to three travelers as a refund. On his way up to the travelers' room the bellhop considers that there is no even way to divide $5 between three people, and decides, in the interest of civility, to keep $2 for himself as a tip, giving the travelers' only a $3 refund
When the bellhop gets to the room, he gives the travelers their $3, which they divide equally amoung themselvs, $1 per person, and everyone is happy. Here, however, is the problem: Each traveler has now paid $9 ($10-$1=$9), meaning that they have paid a total of $27 (3*$9=$27) for the room. Add in the $2 that the bellhop kept as a tip and we have $29 ($27+$2=$29). But the three travelers originally paid $30! Where is the missing dollar?
This can be persuaive because it shows a way to use a computer program (gzip) to circumvent CSS when that program was clearly never intended as a circumvention method in the first place. This is an attack on DMCA in the broad, rather than on CSS and MPAA in particular.
First, I'd seriously consider granite. It is available from all regular sources and it doesn't noticably degrade over the 100 year timespan (I did a bit of 'field research' a few years back: comparing the apparant degradataion of tombstones of different materials in local graveyards) If you are really worried about long term readability, you could spend a bit extra for a larger monument with deeper inscriptions.
Another option, that you probably won't find at the regular sources, is glass. Tempered glass several inches thick is unlikely to be easily shattered and should resist acid rain fairly well. The inscription could be embeded beneath a clear outer layer to add some extra resistance to environmental damage. I haven't any idea where you would go to get a glass tombstone, or how much you would expect to pay.
A fair number of 'us' haven't been using "8.3 filenames" since we started computing back in the eighties. The only place I have ever been forced to deal with "8.3", as you correctly point out, is on certain, particularly benighted, file repositories that either cater to, or run themselves, a certain, unmentionable, glorified program loader from a company in Seatle.
The main reason that we can't get rid of such trash is backward compatability: any file wandering across the net must be named in such a way that the system supporting the shortest maximum filename length can store that file, even if only momentarily. This is the same reason that we have uuencode and base64, and that various kinds of file metadata (unix permissions/ACLs, VMS generations, Macintosh resources and creators/types, etc.) don't travel well. Without some form of encoding all these nice extra bits get stripped off as soon as they pass through a system that doesn't know what to do with them.
Yes, similar techniques are used to identify chemicals all the time (and have been for at least the past 30 years). In fact, identification of materials through chemical reaction is only the crudest manner of identifying materials. Try doing some google searches on the spectroscopy, spectrometry, spectral analysis, mass analysis, chromatography and chromotography (note the different spellings: chromo versus chroma). These methods make use of non-chemical atomic and molecular properties (the mass of atoms or molecules, absorbtion or emission of various frequencies of light by atoms' electrons or by certain molecular bonds, etc.) to identify the components of test samples and how the compenents are arranged.
In order for Moore's law to dictate the half life of the "digital divide" it would need to say something about the rate of decline in retail price of computers. Unfortunately, that is not what Moore's law talks about: it says that the feature geometry of integrated circuits doubles every 18 months, which is only one factor in the retail price of products which use integrated circuits.
The actual half-life of the "digital divide," as measured by the price for an entry level home computer, has been declining steadily since the mid-'80s, but not by 50% every 18 months. While you may be able to purchase twice as much of any given computer resource (memory, storage, instructions-per-second) every 18 months, this is not due to a decrease in system price, but to an increase in system performance, while prices stayed, largely, fixed. The actual rate of decline in the price of computer systems is more like 10% per year, over the past 15 years, which makes the half-life of the digital divide something more like 5-years (especially when we also account for wage and price inflation).
With a half-life of 5-years, the "digital divide" will be essentially gone (less than 10% of the world population will be offline) by 2050. Long before then, however, the "digital divide" will have lost any political power it may currently have: by 2010 we can expect that less than one quarter of the world population will be offline.
Although my reflexive response to this is "5 years? Unlikely!" I think you have a very good point. A moments reflection on the grand sweep of human computer interfaces (HCI) is instructive:
- 1950-1970: sequential batch processing
- 1968-1988: interactive command lines
- 1984-????: windows, icons, and mice
Note that each major era of HCI is roughly 20 years (maybe not coincidentally the same a one human generation), which means that we might expect the current HCI model, windowed GUIs, will be replaced by something else around 2005 (or a few years earlier, since my table above has some overlap for each 'generation').Note, as well, that, contrary to Neil Stephenson's well known essay In the Beginning was the Command Line, the command line was far from the beginning...
Your example is a bit contrived, however. For me, writting a letter on the computer consists of:
- start word processor
- type letter
- print letter
Back when I used a typewriter to write letters, however, I had to do the following:- open typewriter case
- insert paper into typewritter
- type letter
which looks like an awfully similar amount of work. Granted, I rarely turn off my computer, which saves me the step of turning on the computer, but I just don't feel that using the computer has been a net loss in productivity for me, especially if you include the retyping cycle needed because I'm not the most accurate typist in the world.Essentially, the article says that Raskin doesn't like MacOS X, MS Windows, or any other general purpose operating system for that matter, because he thinks that computers should be pure appliances, relieving the user of having to worry about mundanities like file storage or program launching, rather than infinitely mutable environments. Raskin is a visionary, which is a good thing, but it means that he is concentrating on the future possabilities of ideal computer interfaces, while missing the more prosaic uses of technology today.
Personally, I agree with Raskin on what I would like my computing experience to be like, but I also recognize that we are a long way from making that experience happen in a ubiquitous manner. For the moment, I get more milage out of an OS centric system that provides me with the primitives that can be combined into a tailored work environment (e.g. Linux running X and Fvwm2 with a small collection of application programs and shell scripts) than I would out of a more turn-key system that wasn't designed by me for my own uses (e.g. MacOS, Windows, PalmOS, and even Gnome and KDE).
Raskin is talking about a system that would be preconfigured to do exactly what the user wants to do, but he fails to mention, and possibly fails to consider, that such a system is nearly impossible to produce, simply because there are too many different kinds of user with too many different preferred modes of work. It is much easier to produce a clumsy generic environment that can be shoehorned into many different task niches, than to custom engineer a system and user-interface for each prospective user.
The users that really care about a streamlined work environment (sometimes referred to as Power Users) will take the time and effort to tailor their system to their tastes. The users that don't care, and such users do exist, will either suffer (silently or otherwise) or pay someone else to produce a more tailored configuration for them. (while I am no Libertarian, or even much of a Capitalist, and as much as I hate to point this out, the dominance of generic, operating system centered, computing environments looks like a perfect example of the free market at work)
I like the major.minor.patch scheme, but I like also like to be able to tell something from the version number. Specifically, I want all releases with the same major version number to be backward compatible (stuff that worked with 4.1.x will still work with 4.2.x but may well break with 5.x.y). This equates to the following rules for assigning version numbers:
- major version numbers change when an external protocol is deleted or modified in some non-compatible way.
- minor version number change when an external protocol is added or an existing one is extended but is still compatible with the old semantics.
- patch level changes with each new build. The patch level essentially tells the user that some bugs have been (hopefully) fixed in x.y.n that weren't fixed in x.y.n-1.
Obviously this version number scheme is only really usefull for libraries and client-server systems. If your program doesn't provide an external interface then there is nothing worth keeping track of.Incidentally, for things other than libraries and servers, I agree with the posters who are saying that version numbers are an antiquated concept (or a marketing ploy) and we should just be letting CVS take care of things for us. Still, there are plenty of folks out there (myself included) who care about what version of a specific piece of software they are using, if only because they know that 3.2.25 was the first release to have the features that they wanted.
This suggests that, even if you normally rely on CVS for version control, you should tag important released with meaninfull version numbers for the convenience of users. For this purpose, however, you might as well go the route of simple sequential integers or complete date-times.
NOTE: where my version numbering scheme is meant to communicate something about the status and feature set of the finished software product, the CVS version numbering scheme is meant to communicate something about the status of the sources with respect to the development process. My versioning scheme doesn't easily support branching of the source tree, while the CVS scheme will be nearly incomprehensible to users for any project of reasonable size. This is why CVS has tags and rtags.
About the time I got my first K6-3D box, and was considering an early Athlon box, I looked into weather simulation programs as a fun thing to run in order to use up all the excess CPU cycles I now had. A number of different packages exist that will produce interesting results, though I don't know how easily they can be made to compile and run on Linux (the problem is finding a good Fortran compiler): NCAR/Pennstate mesoscale model MM5, NCAR Community Climate Model CCM3, and Colorado State RAMS model.
The basic set of books I recomend for a company library are:
- The C Programming Langauge - Kernighan & Ritchie, Prentice Hall
- The Standard C Library - P.J. Plauger, Prentice Hall
- The UNIX Programming Environment - Kernighan & Pike, Prentice Hall
- The Practice of Programming - Kernighan & Pike, Addison-Wesley
- The Elements of Programmiing Style - Kernighan & Plauger, McGraw-Hill
- The Mythical Man-Month - Fred Brooks, Prentice Hall
- Peopleware DeMarco & Lister, Droset House Publishing
- The Cathedral and the Bazaar - Eric Raymond, O'Reilly & Assoc.
- C+C++ Programming with Objects in C and C++ - Allen Holub, McGraw-Hill
- Enough Rope to Shoot Yourself in the Foot - Allen Holub, McGraw-Hill
- Tog on Software Design - Bruce Tognazzini, Addison-Wesley
- Tog on Interface - Bruce Tognazzini, Addison-Wesley
- Managing Projects with make - Oram & Talbott, O'Reilly & Assoc.
- Open Source Development with CVS - Karl Fogel, Coriolis Inc.
This set covers a wide range of topics, from bare language issues, through design and coding practices, all the way up to project and corporate management issues. You may need to supplement these books with a few more that address specific fields of interest to your business (my list is a bit short on web, C++ and unix system programming books, for example), but these are a good start.The "thruoughput rate" of floppies is actually on the order of 500KB/sec, which isn't so bad compared to some popular networking media (10BaseT is only able to achieve about 600-700KB/sec once you have factored in protocol and collision overhaad).
Since other devices have been designed to adapt the floppy drive to alternative media (I'm thinking of memory sticks and the like) there shouldn't be too much problem doing the same thing for a networking medium.
The real problem would likely be how to present the interface to the rest of the system: would you use a new disk driver which would translate the local networking API or would the device itself present the network as a set of files on a virtual floppy disk? Either way you have some big headaches if you are going to support more than a few target systems.
Which is wonderfull if you want a comfortable desktop/development platform, but next to useless in a handheld/embedded setting.
Which is really nice if you want to deploy it on a slimmed down compuuting platform designed to fit in someones shirt pocket and run for weeks on a couple of AA batteries, but sucks some (but not nearly all or even most) other computing tasks.
Ah, this must be some new usage of the word better to which I have been hitherto unaware!
None of which are features of the OS, and, hence, are irrelevant to the question that was asked.
Or you could use the GCC cross-compiler tools for PalmOS, which are also free and run on some of the most successfull and program friendly computing environments ever written.
Of course, you will have to rewrite the program anyway, since the assumptions you made about the human interface will likely be completely different in a handheld device that it was for the desktop systems you orriginally wrote the program for.
Which begs the question: why are you targeting a handheld device if what you really want is a desktop?
Just two points:
Anyone who has been using Windows since version 3.1 (the earliest version at which the product was anything more than a joke) then they have, by now, paid between $250 and $500 for the product, if they have been upgrading faithfully. If they made the jump to Windows NT they are probably verging on that magical $1000 mark by now, if they have not already surpassed it.
On top of the outright cost, we should probably be counting the costs factored into bundled hardware sales and third party software development, which I couldn't even begin to compute here. I'll just say that I suspect that costs to consumers have been increased, rather than lowered, by the existance of the Microsoft monopoly.
If Microsoft has anything to say about the matter, every Windows user will be forced to pay an annual fee for the privilage. I don't know what the actual fee is likely to be, but I suspect that it would rapidly accumulate into a sizable chunk of change.
It is exactly the monopoly power that Microsoft wields that will allow them to institute this new pricing scheme.
Better yet, don't use Windows at all! If you feel the need for Windows, of any version:
Better yet, never by Intel based hardware (which is the one of the main RDRAM boosters). Try an Alpha-based system, Power Macintosh, or even a Sun workstation. If you absolutely must use an x86 compatible system, get an AMD solution. When the AMD x86-64 stuff comes out definitely get an AMD solution ;-)
Start going to local music events by small, unsigned bands. You might be suprised by how much good music is out there that never makes it to national distribution. Many of those small bands are even able to afford to have their own CDs pressed and sell them at performances.
Watch them in the theaters only after they move to the second string, $1/$1.50/$2.00 theaters or wait for the movis on non-pay-per-view cable or open broadcast TV. As for DVD's just don't buy them at all! If you really care about this issue, you can forego a little bit of entertainment.
I can't agree more with this one. If you live in a democratic country and you don't like what's going on, get out there and do something about it. If you don't live in a democracy, maybe you should look into doing something about that as well ;-)
Heisenberg's Uncertainty Principle states that certain pairs of properties can only be measured to a finite degree of precision. There are only a few such paired properties: position/momentum and time/energy are the only ones mentioned in my Physics text [Physics for Scientists and Engineers Volume 2, 3rd Ed., 1991 Paul A. Tipler, Worth Publishers, page 1180]. Electron phase is not one of the effected properties, so Heisenberg doesn't seem to be a limit here. Shannon, on the other hand, may have something to say in the matter.
What about Coherent, a V7 clone for 8086/80286 from Mark Williams Corp. and QNX?
I'm a bit suprised that these two are missing, but XINU has made it onto the chart, even though it doesn't show any actual inheritance from any unix strain (and rightly so: XINU's only relationship to unix, aside from the name, was entirely spiritual).
Have a look at the MIT Media Lab Responsive Environments Group and their current projects, specifically responsive surfaces as well as the Tangible Media Group and their senstable and m etaDesk projects.
These projects all make use of various methods of sensing user movement without the need to add extra bits of stuff to the person. One of the projects that I have heard about (I think it is part of metaDesk) uses an array of theramin-like* devices to sense the users hand positions over a table top. The devices are able to sense both hands along with palm and finger orientations.
* A theramin is an electronic musical instrument where the musician plays the instrument by passing her hand between a radio transmitter and reciever, interrupting the electromagnetic field and producing various tones and sounds. This is similar to the effect that you can see on either TV or radio reception as people move around relative to the receiver antena (obviously this doesn't happen if you have cable TV).
There is a tool for MacOS called FilterTop which allows you to construct pipelines from special filter programs. You can then drag-and-drop files into the resulting filters (called 'droplets' in MacOS) and have the pipeline executed on the contents of the file, spitting the results out into another file afterwards.
I think that there was something else for the Mac, released back around 1995, that did something similar by arranging icons on the desktop, but I can't find any reference to it through Google.
The cited portion of the @home contract is not preventing users from running a masquerading (aka NAT in the non-Linux world) firewalls. VPN's are a way of tunneling network traffic over a non-secure network in a secure fashion (using encrypted connections/packets) and provide the illusion that many, spatially distant computers are communicating over a common LAN, rather than over the open internet.
There may well be a section of the @home contract that forbids masquerading/NAT firewalls, I know that such clauses were popular a year or so back (mostly specifying that only a single computer could be hooked up to the service, which pretty much forbids masquerading/NAT firewalls) but the cited section is dealing with something else entirely.
Covering the top of your cubical is likely to be a fire hazard, since it would block not only the light from the overhead flourescents, but any water from overhead sprinkler systems (mandatory in most commercial, and some residential, buildings in the U.S.) Rather than violate the firecode by building impormptu structures, I have found that simply removing some of the flourescent bulbs from the fixtures yeilds a very pleasing light level, without an increased risk of fire.
The only problem I have encountered when deactivating lighting fixtures is when my cube-neighbors and I don't agree on the proper light level. A little friendly and reasonable discussion, however, usually goes a long way toward solving and disputes (especially since you can often deactivate just the lights directly over your own cube without affecting the lighing in neighboring cubes overmuch).
First, Apple is at least rumored to have an investment in Transmeta, which suggests that there may be some work being done on a Transmeta based PowerPC. I would expect that, so long as the Transmeta technology (whatever that means) is not too tied to conversion and emulation of x86 instructions (I can think of a number of things that might be done to speed up x86 emulation that would be of no use for any other architecture), emulating any CPU architecture should be fairly simple.
Second, given that Transmeta is trying to keep the ability to completely revamp the underlying architecture of crusoe, I would be willing to lay a bet that they could design a crusoe that would be able to 'emulate' IA-64 with fair performance, (which shouldn't be too hard, since IA-64 is shaping up to be a real dog). As for the current crusoe design, I would think that it probably lacks sufficient resources (mainly too few registers) to run IA-64 code with any efficiency.
Here is a link to anECM scanner (a device that will read the diagnostic codes on modern cars) for only about $500. It looks like it can handle a wide variety of Chrysler, Ford and GM vehicles built between 1984 and 1995.
The company sells a few other interesting toys that could be of use to automotive/electronics geeks.
Otherwise, there are some links I found along the way:- Miata Engine Computer Self Diagnotics
- Chrysler, Plymouth, and Dodge Computer Fault Codes
- Datalogger a commercial hack from TechnMotive similar to the poster's requrest. There may be other good stuff on the TechnoMotive site.
- An overview of electronic engine control from Intel.
I got these links simply by doing a Google search on "engine computer diagnostic". There were many more (about 4000 pages worth) but I got tired of skimming through them (I was averaging about 2 usefull hits per page).While much of the basics of human interaction and GUIs was worked out years ago (at Xerox and Apple) there are still people thinking of better ways to do things. Check out Bruce Tognazzini's web site AskTog for some coverage of this topic. He has tutorials on user interface design, cogent criticism of current GUIs, suggestions for improvements, as well as sundry and other essays.