That's a copout. I simply said that the OS people have in mind when referring to "Linux" is the GNU OS, running on the Linux kernel.
If I write a program that used X for display purposes, I'd say that I wrote an X program.
If I write a program that expects that functions present in the standard C library to be there (select, gettimeofday, fopen, fabs, etc.), I'd say I wrote a UNIX program, or a GNU program.
Either way, unless I dispense with the standard library myself and use ONLY system calls and functions which I wrote myself (which themselves only use system calls and functions which I wrote myself, ad infinitum), it's not a Linux program, it's a GNU (or UNIX) program executed and managed by the Linux kernel.
You could argue that it's just semantics, but the "it's just semantics" argument could be used to dispense with many other issues as well, and doesn't do anything to address the issue.
Go delete libc6 and see how many programs you can compile (remember to use a statically linked GCC!) and run without having it around, then come back and tell me that it's still an operating system without GNU.
That did bother me as well, and I'm glad you commented on it.
It amazes me, when reading replies to my post, that people don't seem to realize how important the C library is to the overall system. Without the availability of a standard C library, every programmer would be forced to write their own implementations of printf, or fopen, or gettimeofday.
I used to condemn the FSF for requiring that developers assign copyright of their work to them (to the FSF, that is). However, if someone (SCO?) decided to claim ownership, the FSF could trace the code back to its original contributor. The more I pay attention, the more I realize that RMS really may have something with his ramblings;)
I'm not implying that the final goal was to interoperate with closed kernels. However, when you're developing on a system that you don't own and don't have complete control over (as was the case for the developers at the time), you can't just opt to rewrite the kernel based on your own "philosophical drive."
What you seem to be saying (and correct me if I'm wrong) is that you doubt that GNU software was initially written in such a way that it would function on the only systems to which the creators had access.
It's not quite semantics. Go read my post on the same topic in another thread, and really think about what a core Linux-based OS needs to operate in the way that you might expect.
From http://www.debian.org/ports/#nonlinux, regarding Debian/NetBSD:
"This is a port of the Debian operating system, complete with apt, dpkg, and GNU userland, to the NetBSD kernel. It is currently in a very preliminary stage..."
Essentially the same is said of the Debian/FreeBSD port, and as I understand it, the HURD isn't ready to replace Linux as a highly usable general-purpose kernel.
Can you come up with a ready-for-primetime example?
After further thought, the article mentions that SCO implies that "UNIX" could not be recreated without looking at UNIX source.
There is a lot of vagueness there -- aside from the kernel, GNU had recreated the majority of the OS long before SCO owned any such trademarks.
The part they lacked most, the kernel, has been so long in coming almost because of that fact -- they recreated the OS to work with existing kernels, so there wasn't a dire need for one.
In other words, reinventing the OS was more important than reinventing the kernel. But the OS (GNU) was recreated legally, and the FSF owns copyright to every line of code in a GNU project (to prevent silly suits such as this one).
Then, about a decade ago, a young Finn named Linus Torvalds introduced an operating system (named Linux, after its creator) that did some of what UNIX did. Linux proved remarkably successful. The community of Linux users adopted a mascot--the penguin - as a sort of trademark.
At the risk of parroting RMS here, Linus started the kernel roughly a decade ago.
GNU started the OS itself about two decades ago.
It is an important distinction. I really wish that there was a distribution of the GNU OS that used a non-Linux kernel (but was otherwise like other GNU/Linux distros), which would be more concrete evidence of the importance (and extent!) of the GNU portions of the overall OS.
The reason he doesn't insist on GNU/NetBSD is that the BSDs are based on a codebase that was originally UNIX.
Back when AT&T owned UNIX, some of the UNIX source was released freely, and the rest was rewritten by the educational community and released freely as well.
BSD (Berkeley Standard Distribution, as in the University of California at Berkeley, as I recall) is UNIX-based, through and through, since it derives heavily from "UNIX", which at the time was the OS owned by AT&T.
The BSDs "forked" from UNIX proper, and later branched into Open, Net, FreeBSD, et. al.
In the early 1980's, RMS (among others) realized that since UNIX was a commercially owned and controlled OS, certain freedoms were lost. In order to prevent this from being a future limitation, he started GNU, which, again, means GNU's Not UNIX.
GNU includes much more than just GCC -- such as the standard command-line utils (GNU textutils, binutils, ls, sed, etc. are used by most [all?] distributions of operating systems using Linux as their kernel, for instance). Much of the base system, which other programs depend on to run (this includes the C library itself, a central part of any UNIX-like system).
GNU's software includes everything that a UNIX-like OS needs, except for a kernel. That's the "Linux" part.
Now, again, the BSDs came from UNIX (so, BSD Was UNIX, you could say). This includes the BSD kernels, libraries, and command-line utilities.
The only GNU major component that the BSDs use is GCC.
RMS doesn't insist on GNU/NetBSD for the same reason that nobody insists on calling it DevStudio/Windows XP -- it'd be idiotic, since an OS is much more than just the compiler which built it (which is NetBSD's relation to GNU tools). He insists on GNU/Linux because GNU is the operating system proper, and Linux is the kernel on which it runs. Insisting on calling it GNU/Linux is like insisting that Apple call their OS "MacOS" or "MacOS/BSD" instead of just "BSD" -- there's much more to an OS than the kernel, and it wouldn't make sense to call Apple's newest OS "BSD" just because of the kernel itself.
If you really, really don't think that GNU is that important, go install a base installation of your favorite "Linux-based" distro (Debian's base system is roughly 15 MB worth of.tar.gz, IIRC, and I'm sure other distros allow you to install a bare-bones system as well). Hell, throw in the compiler as well.
Now, look at exactly what is installed. How much of it is GNU? Here's a quick list utilities which contain either an "@gnu.org" email address or an FSF copyright notice in their --help output on a Debian-based router that I administer:
[ a2ps aclocal aclocal-1.5 addr2line ar as autoconf autoheader autom4te automake automake-1.5 autopoint autoreconf autoscan autoupdate awk basename bash bashbug bc bison build-prc c++ c++filt card cat catchsegv cc cg_annotate chgrp chmod chown cksum cmp comm cp cpp csplit cut date dch dd df diff diff3 dir dircolors dscverify du echo env expand expr factor false find fixps flea fmt fold g++ gawk gcc gccbug gcov gdb gencat getconf getent gettext gettextize git gitaction gitkeys gitmount gitrgrep gitunpack glibcbug gnut gpg gpgsplit gpgv gprof grep grep-excuses groff groups gunzip gzexe gzip head hindent hostid i386-linux-cpp i386-linux-g++ i386-linux-gcc iconv id ifnames igawk info infobrowser infokey install join ld ldd libtool libtoolize link ln locale localedef locate logname ls make makeinfo md5sum.textutils mergechanges mkdir mkfifo mknod msgattrib msgcat msgcmp msgcomm msgconv msgen msgexec msgfilter msgfmt msggrep msginit msgmerge msgunfmt msguniq mtrace mutt muttbug mv nano nawk nice nl nm nohup objcopy objdump od paste patch pathchk pdiff pgawk pinky pr printenv printf psmandup psset ptx pwd ranlib rbash rcs2log readelf readlink rm rmdir screen sdiff sed seq sh sha1sum shred size sleep slrn sort split stat strings strip stty sum sync tac tack tail tar tee test texi2dvi texi2dvi4a2ps texi2html texindex touch t
They gave the exact configuration files and compiler flags used. You can download the tools they used for the test -- even the Fortran compiler is available for a free 30-day trial.
How much more honest can they get? You can go buy exactly what they used, install exactly what they installed, use exactly the software they used, and try to produce their results.
But until I can have a featureful Mac for around the same price as I can build (yes, build) a functional PC, I wouldn't consider buying one.
I'm not going to squabble about numbers here, but I seriously doubt that I'd be able to get a 2+GHz 2-CPU system with 512 MB of RAM and a tower-style (ie, not iMac) form factor for less than $2000.
This is always my response to those who hold their Machood over me. I'd like a Dodge Viper, but I'm on a 1989 Ford Crown Victoria budget. I'd like a Mac, but I'm on a commodity-hardware budget.
Let me get this straight -- you're saying that because it's possible to replace the existing fuel tanks and pumps, the infrastructure for hydrogen is "mostly deployed"?
That's like saying that a shopping mall is "almost built" at the old Pittsburgh airport, since they already have tons of pavement to use as a parking lot. All they have to do is replace the airport with a mall.
Mostly deployed, my ass. To convert a single gas station would cost tons.
You'd need a cheap source of hydrogen. You'd need a cheap way of transporting it to gas stations. You'd need auto manufacturers to build enough hydrogen-capable cars to create a demand for hydrogen. These cars must be as powerful and as large as normal gas-powered cars, cost the same amount or less money, and also take gasoline, because none of the gas stations carry hydrogen.
Given all of this, you'd need Exxon or BP or Shell or some other national chain to decide that enough hydrogen-ready cars are on the road to profit from.
This is a complex decision, but it comes down to money and publicity. The amount of hydrogen required to go, say, 100 miles must be sold at a lower price than the amount of gasoline required to go 100 miles. If it makes financial sense, then companies will race to be first to deploy hydrogen nationally -- but only if the money is there.
Within this price limit, there must be enough of a profit margin so that the gasoline companies will make more profit from hydrogen than from gasoline. Nobody wants to reduce their income, and gas companies simply wouldn't support a fuel source that brought them less profit.
So, to sum up:
- It must cost less to produce hydrogen, otherwise producers will produce gasoline. - It must cost less to transport an equivalent amount of hydrogen (in terms of what can be sold to the customer), otherwise getting it to the stations won't be cost-effective. - It must cost less for the customer to drive, in terms of fuel costs. - The vehicle must cost less for the customer to purchase than traditional vehicles, or else they won't buy one in the first place. - Hydrogen-powered cars must take gasoline also, or the customer will be afraid of committing to a new fuel source.
As I see it, only if all of these conditions are satified would the gas stations even consider investigating hydrogen distribution. Now, can you tell me which of those conditions are satisfied, given your assertion that the infrastructure is "mostly deployed"?
I don't know much about g, other than that it's supposedly backwards-compatible. I do think that for a low-powered device with modest amounts of storage, ultra-high bandwidth shouldn't be a major concern. Even if storage runs as high as 256MB, a fully-utilized 11MB wireless connection could back up the handheld's entire store in just a few minutes, and with a USB dock (cradle) you could transfer all of the data pretty quickly. I'd think that the wireless would more be used for instant messages and the occasional data transfer, but I doubt you'd miss the extra bandwidth much.
That said, if you've never perused Palm's information on their handhelds, it's actually pretty interesting.
For instance, the OS does not include a busy-wait cursor. Apps aren't meant to make the user wait. (Okay, it may not seem like much, but seeing that in platform docs makes me giddy).
I remember reading something about how the Palm processor was designed for low-power operation. Basically, any hardware that isn't being used is shut off.
Broad-level design and philosophy overview: http://www.palmos.com/dev/start/intro.html
Neat quotes from this link include "requiring a user to spend an extra 30 seconds to find the information they need most often is... cumbersome on a handheld when that is the only thing they are going to do before they turn it off", "consider providing a way for users to enter data on the desktop and providing a conduit that downloads this information to the device", "the processing speed of a Palm Powered handheld ranges from 16MHz to 33MHz. They simply aren't designed to perform the same type of processing as a desktop PC. Users of handhelds do not expect to stare at an hourglass waiting for the next screen to appear", "Users depend on being able to use their device without needing to worry about whether or not it is charged up", and "users are not expected to upgrade their operating system as much as they would on a desktop computer."
More specific docs: http://www.palmos.com/dev/support/docs/
You have a point regarding writing portable code. However, I think that the UI would have to be highly redesigned to make a desktop app work on a Palm.
Early Palm screens are 160x160, and later revisions use 320x320. It's specifically backwards-compatible in such a way that low-res apps work flawlessly on high-res screens. High-res Palm apps usually don't display more on the screen at once, but what they do display looks better.
Palm design is a bit different than general design. It's well-suited to a handheld, but not well-suited for general usage. For instance, you don't interact with files -- there's no filesystem heirarchy. What an app does is create a database and manage records (of arbitrary length) using the Palm OS API. For instance, the address book has a single database which stores all contacts. Each record in a database is marked as clean (unmodified) or dirty. When you sync ("HotSync") the Palm with the desktop system, all dirty records are synchronized between handheld and desktop.
If you want to write a Palm app with a desktop counterpart, it's best to follow their suggestions:
The handheld features a processor that is significantly slower than the processors on most desktop computers. Because of this, PalmSource encourages developers to write applications for Palm Powered handhelds that off-load processor-intensive tasks to the desktop computer. Specifically, handhelds are intended for applications such as the following:
â portable data entry â portable data viewing â remote transactions
Applications that perform the following operations are considered more suitable for the desktop computer's processing power:
â high volume data entry â backing up data â printing â configuration â data storage
Most of the work you'll do on a hand-held device is pretty lightweight compared to the work you'd do on a desktop app. Fortunately, they make it
Bah. Drop the 802.11g (use b instead -- g devices will talk to b hardware), use a DSP for the MP3 decoding, so the core CPU requirements can be less demanding (and the DSP can be powered off by the core OS when not in use).
Forget Java also -- with a slow CPU, I'd think that GC delays would suck. Palm OS is easy to code for, and you can use free tools (GCC, etc.).
With the switch to 802.11b and using a DSP instead of a battery-sucking CPU, I'd say that price sounds reasonable.
(Basically, you're left with a Palm V with a keyboard and a DSP...)
That's exactly my point. Pink Floyd songs are generally good individually, but when you listen to them as an album they're so much more.
Look at "Wish You Were Here". Great song. Even better album.
Dark Side has many tracks that are definitely "radio-worthy". Ditto The Wall.
Sure, not all Pink Floyd albums had tracks which would find time on a mainstream radio station. But the ones that do are still worth more as a whole album, because of the added benefit of an overall theme instead of just a bunch of good songs.
Put another way, I'd still buy Pink Floyd albums, because they're good albums. I'd still buy Radiohead albums, because they're good albums.
I wouldn't buy the Moby album -- I like a few songs, but most of them just don't do it for me. I wouldn't buy, say, the Sir Mix-a-Lot album with Baby Got Back on it, though I might on a whim shell out $0.99 for it. I wouldn't buy the Digital Underground album with the Humpty Dance.
But I'd still spend $10 for the enjoyment that I know I'll get out of a complete copy of Dark Side of the Moon, Wish You Were Here, The Wall, or the less radio-friendly stuff.
I disagree. I like Radiohead, and would probably not buy their singles -- even classic Pink Floyd albums, while rich with hit singles, are better appreciated as a musical whole, and I'd gladly shell out $10 to appreciate the work as a whole, and to own the physical media.
Interestingly enough, have you ever thought about just why they're called "albums"?
When the "recording industry" first started, individual songs were sold on 45's. People would buy books (similar to picture albums) in which they would store their records. Some enterprising blues artist came up with the idea of making songs which went together as a greater work, meant to fill such an album.
The recording industry _has_ survived the trade of single songs.
This is like reading a story saying that the recording industry doesn't want to return to a vinyl format (or cassette tape, or whatever), because they think it'll be bad for sales. The recording industry has not only survived the sale of single songs, it started that way, whether those in charge have any idea or not.
The way I see this developing, is this: single-spitting "pop artists" will earn their $0.99 per track, because that's what they produce best.
Those who can produce albums which really, REALLY make sense as albums will still sell what they produce best -- albums.
Basically he says, "Something which wasn't designed to do what I want it to do is fundamentally broken! Let's change the RFC* and rewrite SMTP to do something that will make it do exactly what we want, with no side effects!"
I challenge anyone to explain to me just what is insightful here. Mods, you can still log out and post as AC...
i dunno. file this parent under content-free.
* It's my understanding that RFC's aren't changed, but superceded...
Slashdot Mirror
That's a copout. I simply said that the OS people have in mind when referring to "Linux" is the GNU OS, running on the Linux kernel.
If I write a program that used X for display purposes, I'd say that I wrote an X program.
If I write a program that expects that functions present in the standard C library to be there (select, gettimeofday, fopen, fabs, etc.), I'd say I wrote a UNIX program, or a GNU program.
Either way, unless I dispense with the standard library myself and use ONLY system calls and functions which I wrote myself (which themselves only use system calls and functions which I wrote myself, ad infinitum), it's not a Linux program, it's a GNU (or UNIX) program executed and managed by the Linux kernel.
You could argue that it's just semantics, but the "it's just semantics" argument could be used to dispense with many other issues as well, and doesn't do anything to address the issue.
Go delete libc6 and see how many programs you can compile (remember to use a statically linked GCC!) and run without having it around, then come back and tell me that it's still an operating system without GNU.
That did bother me as well, and I'm glad you commented on it.
;)
It amazes me, when reading replies to my post, that people don't seem to realize how important the C library is to the overall system. Without the availability of a standard C library, every programmer would be forced to write their own implementations of printf, or fopen, or gettimeofday.
I used to condemn the FSF for requiring that developers assign copyright of their work to them (to the FSF, that is). However, if someone (SCO?) decided to claim ownership, the FSF could trace the code back to its original contributor. The more I pay attention, the more I realize that RMS really may have something with his ramblings
What about the C library, which allows programs to do things such as open files, and get the system time?
I'm not implying that the final goal was to interoperate with closed kernels. However, when you're developing on a system that you don't own and don't have complete control over (as was the case for the developers at the time), you can't just opt to rewrite the kernel based on your own "philosophical drive."
What you seem to be saying (and correct me if I'm wrong) is that you doubt that GNU software was initially written in such a way that it would function on the only systems to which the creators had access.
A UNIX-like OS includes at the very least the C library.
Where can I find the source of this authoritative definition of an OS?
It's not quite semantics. Go read my post on the same topic in another thread, and really think about what a core Linux-based OS needs to operate in the way that you might expect.
Would you say that a SysV-style and a BSD-style distro are the same OS, simply because of the shared kernel?
Compile the following (statically!), and call it
Reboot. You now have a system devoid of anything except the boot loader, kernel, and a tiny shell.
Once you've done this, come back and tell me about how well Apache works.
I didn't come CLOSE to implying that GNU "started" Linux.
As far as the rest of your troll, read my earlier post in another thread on the same topic.
GNU didn't help Linux -- Linux helped GNU, as the availability of a Free kernel allowed the distribution of a complete OS.
Why, is either one finished?
Essentially the same is said of the Debian/FreeBSD port, and as I understand it, the HURD isn't ready to replace Linux as a highly usable general-purpose kernel.
Can you come up with a ready-for-primetime example?
After further thought, the article mentions that SCO implies that "UNIX" could not be recreated without looking at UNIX source.
There is a lot of vagueness there -- aside from the kernel, GNU had recreated the majority of the OS long before SCO owned any such trademarks.
The part they lacked most, the kernel, has been so long in coming almost because of that fact -- they recreated the OS to work with existing kernels, so there wasn't a dire need for one.
In other words, reinventing the OS was more important than reinventing the kernel. But the OS (GNU) was recreated legally, and the FSF owns copyright to every line of code in a GNU project (to prevent silly suits such as this one).
At the risk of parroting RMS here, Linus started the kernel roughly a decade ago.
GNU started the OS itself about two decades ago.
It is an important distinction. I really wish that there was a distribution of the GNU OS that used a non-Linux kernel (but was otherwise like other GNU/Linux distros), which would be more concrete evidence of the importance (and extent!) of the GNU portions of the overall OS.
The reason he doesn't insist on GNU/NetBSD is that the BSDs are based on a codebase that was originally UNIX.
.tar.gz, IIRC, and I'm sure other distros allow you to install a bare-bones system as well). Hell, throw in the compiler as well.
Back when AT&T owned UNIX, some of the UNIX source was released freely, and the rest was rewritten by the educational community and released freely as well.
BSD (Berkeley Standard Distribution, as in the University of California at Berkeley, as I recall) is UNIX-based, through and through, since it derives heavily from "UNIX", which at the time was the OS owned by AT&T.
The BSDs "forked" from UNIX proper, and later branched into Open, Net, FreeBSD, et. al.
In the early 1980's, RMS (among others) realized that since UNIX was a commercially owned and controlled OS, certain freedoms were lost. In order to prevent this from being a future limitation, he started GNU, which, again, means GNU's Not UNIX.
GNU includes much more than just GCC -- such as the standard command-line utils (GNU textutils, binutils, ls, sed, etc. are used by most [all?] distributions of operating systems using Linux as their kernel, for instance). Much of the base system, which other programs depend on to run (this includes the C library itself, a central part of any UNIX-like system).
GNU's software includes everything that a UNIX-like OS needs, except for a kernel. That's the "Linux" part.
Now, again, the BSDs came from UNIX (so, BSD Was UNIX, you could say). This includes the BSD kernels, libraries, and command-line utilities.
The only GNU major component that the BSDs use is GCC.
RMS doesn't insist on GNU/NetBSD for the same reason that nobody insists on calling it DevStudio/Windows XP -- it'd be idiotic, since an OS is much more than just the compiler which built it (which is NetBSD's relation to GNU tools). He insists on GNU/Linux because GNU is the operating system proper, and Linux is the kernel on which it runs. Insisting on calling it GNU/Linux is like insisting that Apple call their OS "MacOS" or "MacOS/BSD" instead of just "BSD" -- there's much more to an OS than the kernel, and it wouldn't make sense to call Apple's newest OS "BSD" just because of the kernel itself.
If you really, really don't think that GNU is that important, go install a base installation of your favorite "Linux-based" distro (Debian's base system is roughly 15 MB worth of
Now, look at exactly what is installed. How much of it is GNU? Here's a quick list utilities which contain either an "@gnu.org" email address or an FSF copyright notice in their --help output on a Debian-based router that I administer:
[ a2ps aclocal aclocal-1.5 addr2line ar as autoconf autoheader autom4te automake automake-1.5 autopoint autoreconf autoscan autoupdate awk basename bash bashbug bc bison build-prc c++ c++filt card cat catchsegv cc cg_annotate chgrp chmod chown cksum cmp comm cp cpp csplit cut date dch dd df diff diff3 dir dircolors dscverify du echo env expand expr factor false find fixps flea fmt fold g++ gawk gcc gccbug gcov gdb gencat getconf getent gettext gettextize git gitaction gitkeys gitmount gitrgrep gitunpack glibcbug gnut gpg gpgsplit gpgv gprof grep grep-excuses groff groups gunzip gzexe gzip head hindent hostid i386-linux-cpp i386-linux-g++ i386-linux-gcc iconv id ifnames igawk info infobrowser infokey install join ld ldd libtool libtoolize link ln locale localedef locate logname ls make makeinfo md5sum.textutils mergechanges mkdir mkfifo mknod msgattrib msgcat msgcmp msgcomm msgconv msgen msgexec msgfilter msgfmt msggrep msginit msgmerge msgunfmt msguniq mtrace mutt muttbug mv nano nawk nice nl nm nohup objcopy objdump od paste patch pathchk pdiff pgawk pinky pr printenv printf psmandup psset ptx pwd ranlib rbash rcs2log readelf readlink rm rmdir screen sdiff sed seq sh sha1sum shred size sleep slrn sort split stat strings strip stty sum sync tac tack tail tar tee test texi2dvi texi2dvi4a2ps texi2html texindex touch t
They gave the exact configuration files and compiler flags used. You can download the tools they used for the test -- even the Fortran compiler is available for a free 30-day trial.
How much more honest can they get? You can go buy exactly what they used, install exactly what they installed, use exactly the software they used, and try to produce their results.
What are they hiding?
What about total system cost?
I'd love a Mac. I'd love one.
But until I can have a featureful Mac for around the same price as I can build (yes, build) a functional PC, I wouldn't consider buying one.
I'm not going to squabble about numbers here, but I seriously doubt that I'd be able to get a 2+GHz 2-CPU system with 512 MB of RAM and a tower-style (ie, not iMac) form factor for less than $2000.
This is always my response to those who hold their Machood over me. I'd like a Dodge Viper, but I'm on a 1989 Ford Crown Victoria budget. I'd like a Mac, but I'm on a commodity-hardware budget.
Let me get this straight -- you're saying that because it's possible to replace the existing fuel tanks and pumps, the infrastructure for hydrogen is "mostly deployed"?
That's like saying that a shopping mall is "almost built" at the old Pittsburgh airport, since they already have tons of pavement to use as a parking lot. All they have to do is replace the airport with a mall.
Mostly deployed, my ass. To convert a single gas station would cost tons.
You'd need a cheap source of hydrogen. You'd need a cheap way of transporting it to gas stations. You'd need auto manufacturers to build enough hydrogen-capable cars to create a demand for hydrogen. These cars must be as powerful and as large as normal gas-powered cars, cost the same amount or less money, and also take gasoline, because none of the gas stations carry hydrogen.
Given all of this, you'd need Exxon or BP or Shell or some other national chain to decide that enough hydrogen-ready cars are on the road to profit from.
This is a complex decision, but it comes down to money and publicity. The amount of hydrogen required to go, say, 100 miles must be sold at a lower price than the amount of gasoline required to go 100 miles. If it makes financial sense, then companies will race to be first to deploy hydrogen nationally -- but only if the money is there.
Within this price limit, there must be enough of a profit margin so that the gasoline companies will make more profit from hydrogen than from gasoline. Nobody wants to reduce their income, and gas companies simply wouldn't support a fuel source that brought them less profit.
So, to sum up:
- It must cost less to produce hydrogen, otherwise producers will produce gasoline.
- It must cost less to transport an equivalent amount of hydrogen (in terms of what can be sold to the customer), otherwise getting it to the stations won't be cost-effective.
- It must cost less for the customer to drive, in terms of fuel costs.
- The vehicle must cost less for the customer to purchase than traditional vehicles, or else they won't buy one in the first place.
- Hydrogen-powered cars must take gasoline also, or the customer will be afraid of committing to a new fuel source.
As I see it, only if all of these conditions are satified would the gas stations even consider investigating hydrogen distribution. Now, can you tell me which of those conditions are satisfied, given your assertion that the infrastructure is "mostly deployed"?
I don't know much about g, other than that it's supposedly backwards-compatible. I do think that for a low-powered device with modest amounts of storage, ultra-high bandwidth shouldn't be a major concern. Even if storage runs as high as 256MB, a fully-utilized 11MB wireless connection could back up the handheld's entire store in just a few minutes, and with a USB dock (cradle) you could transfer all of the data pretty quickly. I'd think that the wireless would more be used for instant messages and the occasional data transfer, but I doubt you'd miss the extra bandwidth much.
That said, if you've never perused Palm's information on their handhelds, it's actually pretty interesting.
For instance, the OS does not include a busy-wait cursor. Apps aren't meant to make the user wait. (Okay, it may not seem like much, but seeing that in platform docs makes me giddy).
I remember reading something about how the Palm processor was designed for low-power operation. Basically, any hardware that isn't being used is shut off.
Broad-level design and philosophy overview: http://www.palmos.com/dev/start/intro.html
Neat quotes from this link include "requiring a user to spend an extra 30 seconds to find the information they need most often is... cumbersome on a handheld when that is the only thing they are going to do before they turn it off", "consider providing a way for users to enter data on the desktop and providing a conduit that downloads this information to the device", "the processing speed of a Palm Powered handheld ranges from 16MHz to 33MHz. They simply aren't designed to perform the same type of processing as a desktop PC. Users of handhelds do not expect to stare at an hourglass waiting for the next screen to appear", "Users depend on being able to use their device without needing to worry about whether or not it is charged up", and "users are not expected to upgrade their operating system as much as they would on a desktop computer."
More specific docs: http://www.palmos.com/dev/support/docs/
You have a point regarding writing portable code. However, I think that the UI would have to be highly redesigned to make a desktop app work on a Palm.
Early Palm screens are 160x160, and later revisions use 320x320. It's specifically backwards-compatible in such a way that low-res apps work flawlessly on high-res screens. High-res Palm apps usually don't display more on the screen at once, but what they do display looks better.
Palm design is a bit different than general design. It's well-suited to a handheld, but not well-suited for general usage. For instance, you don't interact with files -- there's no filesystem heirarchy. What an app does is create a database and manage records (of arbitrary length) using the Palm OS API. For instance, the address book has a single database which stores all contacts. Each record in a database is marked as clean (unmodified) or dirty. When you sync ("HotSync") the Palm with the desktop system, all dirty records are synchronized between handheld and desktop.
If you want to write a Palm app with a desktop counterpart, it's best to follow their suggestions:
The handheld features a processor that is significantly slower than the processors on most desktop computers. Because of this, PalmSource encourages developers to write applications for Palm Powered handhelds that off-load processor-intensive tasks to the desktop computer. Specifically, handhelds are intended for applications such as the following:
â portable data entry
â portable data viewing
â remote transactions
Applications that perform the following operations are considered more suitable for the desktop computer's processing power:
â high volume data entry
â backing up data
â printing
â configuration
â data storage
Most of the work you'll do on a hand-held device is pretty lightweight compared to the work you'd do on a desktop app. Fortunately, they make it
Bah. Drop the 802.11g (use b instead -- g devices will talk to b hardware), use a DSP for the MP3 decoding, so the core CPU requirements can be less demanding (and the DSP can be powered off by the core OS when not in use).
Forget Java also -- with a slow CPU, I'd think that GC delays would suck. Palm OS is easy to code for, and you can use free tools (GCC, etc.).
With the switch to 802.11b and using a DSP instead of a battery-sucking CPU, I'd say that price sounds reasonable.
(Basically, you're left with a Palm V with a keyboard and a DSP...)
Neat!
Thanks for the correction.
That's exactly my point. Pink Floyd songs are generally good individually, but when you listen to them as an album they're so much more.
Look at "Wish You Were Here". Great song. Even better album.
Dark Side has many tracks that are definitely "radio-worthy". Ditto The Wall.
Sure, not all Pink Floyd albums had tracks which would find time on a mainstream radio station. But the ones that do are still worth more as a whole album, because of the added benefit of an overall theme instead of just a bunch of good songs.
Put another way, I'd still buy Pink Floyd albums, because they're good albums. I'd still buy Radiohead albums, because they're good albums.
I wouldn't buy the Moby album -- I like a few songs, but most of them just don't do it for me. I wouldn't buy, say, the Sir Mix-a-Lot album with Baby Got Back on it, though I might on a whim shell out $0.99 for it. I wouldn't buy the Digital Underground album with the Humpty Dance.
But I'd still spend $10 for the enjoyment that I know I'll get out of a complete copy of Dark Side of the Moon, Wish You Were Here, The Wall, or the less radio-friendly stuff.
Understandable ;)
;)
Would you consider revealing which program you're grepping the logs of?
I'd consider signing an NDA
I disagree. I like Radiohead, and would probably not buy their singles -- even classic Pink Floyd albums, while rich with hit singles, are better appreciated as a musical whole, and I'd gladly shell out $10 to appreciate the work as a whole, and to own the physical media.
Interestingly enough, have you ever thought about just why they're called "albums"?
When the "recording industry" first started, individual songs were sold on 45's. People would buy books (similar to picture albums) in which they would store their records. Some enterprising blues artist came up with the idea of making songs which went together as a greater work, meant to fill such an album.
The recording industry _has_ survived the trade of single songs.
This is like reading a story saying that the recording industry doesn't want to return to a vinyl format (or cassette tape, or whatever), because they think it'll be bad for sales. The recording industry has not only survived the sale of single songs, it started that way, whether those in charge have any idea or not.
The way I see this developing, is this: single-spitting "pop artists" will earn their $0.99 per track, because that's what they produce best.
Those who can produce albums which really, REALLY make sense as albums will still sell what they produce best -- albums.
Where can I get this spamstat script? A 10-second perusal of Google results wasn't helpful.
;)
Release! Release! Release!
What is insightful about this post?
Basically he says, "Something which wasn't designed to do what I want it to do is fundamentally broken! Let's change the RFC* and rewrite SMTP to do something that will make it do exactly what we want, with no side effects!"
I challenge anyone to explain to me just what is insightful here. Mods, you can still log out and post as AC...
i dunno. file this parent under content-free.
* It's my understanding that RFC's aren't changed, but superceded...
Anyone can reduce the population. Now doing it without getting caught, that's the ultimate challenge!