Slashdot Mirror

This method doesn't always work, because some printers are so spectacularly bad that not even the raw data is enough to make it print -- you also have to send the raw data down the wire according to strict timing requirements.

Having said that, the Epson R1800 should mostly work in Linux; if all you can print is text, then you're doing something wrong.

Why does Vista STILL require defragging. We hear that Linux doesn't NEED defragging because it smartly places files. Why can't microsoft eliminate this part of the market. If they aren't, just for the sake of cottage defragging companies, then aren't such companies vampires and saws and such?

http://cbbrowne.com/info/defrag.html

http://www.linuxforums.org/forum/linux-newbie/58320-disk-defragmentation.html

This one challenges Novell's reply:
http://www.novell.com/coolsolutions/qna/15032.html

http://geekblog.oneandoneis2.org/index.php/2006/08/17/why_doesn_t_linux_need_defragmenting

(Oh, BTW, just heard now 17:05 local PST, Yahoo! is scheduled to layoff numerous employees, but it's about 19hour old:

http://www.nytimes.com/2008/01/22/technology/22yahoo.html?bl&ex=1201150800&en=0019b93b4bb1c219&ei=5087

http://news.yahoo.com/fc/Business/Downsizing_and_Layoffs/

)

Have a look at Clean (http://clean.cs.ru.nl/) for a use of pointers (internally) that makes for efficient execution. An interesting read concerning the subject is found here:

http://clean.cs.ru.nl/contents/Addison__Wesley_book/addison__wesley_book.html

Actual benchmarks to show the efficiency can be examined here (note the comparison is with C-versions of the same algorithms compiled on gcc):

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=clean&lang2=gcc

Here's Java 6 (server version) for comparison:

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=java&lang2=gcc

You'll notice that differences are mainly in the memory footprint, already known to be attributable to the large number of libraries (classes) loaded into the vm at start-up, something the Clean runtime isn't quite as encumbered with:

(Java) http://java.sun.com/docs/books/performance/1st_edition/html/JPRAMFootprint.fm.html

So, the difference in speed is often-times negligible, and it's been shown that the memory footprint can be reduced to a size where you can run an embedded jvm in a mobile phone (really!), and rumour has it that someone even wrote an operating system in Java, but the memory footprint still seems the biggest culprit:

http://www.jnode.org/node/573

In other words, it's not Java - the language, but Java - the massive OO-framework, and JVM - the specific implementation, that's the problem. Even C++ or C with an OO-framework can be made into a large memory footprint, if you can believe it:

http://www.microsoft.com/windows/products/windowsvista/editions/systemrequirements.mspx

Then, of course, memory is cheap:

http://www.simmtester.com/page/memory/memprice.asp

But, the over-use of which, sometimes stays with us as itching bugs for too long:

http://blog.wired.com/monkeybites/2007/11/firefox-3-add-o.html

If memory serves me right (http://www.google.com), there's something to be said of the virtues of garbage-collection applied to systems programming:

http://www.digitalmars.com/d/

and the actual (memory and) time efficiency of such an attempt:

http://shootout.alioth.debian.org/gp4/d.php

But I could be wrong. After all, no-one in their right mind would ever attempt to write an operating system in something like, say, Lisp:

http://cbbrowne.com/info/lisposes.html

- let alone design an actual computer around it:

http://en.wikipedia.org/wiki/Lisp_machine

It simply wouldn't run. No, the skills of an engineer depend solely on the language he/she speaks, not on the abstract concepts he/she masters, applied to whatever tool he/she chooses to use/create.

That is why I propose we all forget about abstraction all-together, and revert to coding like this:

010101100001111010110101101101111101111...

But wait, that is itself an abstraction - Turing must have suffered from premature abstraculation. No, let's hear it for using copperwires instead of silicon, so we can attach some large, hand-

In fact, it was quite common to use minimal dialects of Lisp as a systems programming language in the 1980s and 1990s -- Pure Lisp (Cartwright and McCarthy, 1978) forms the basis for most of these.

More generally, the only trick to using ANY Lisp-like language for systems programming is being able to explicitly allocate and deallocate pools of memory not managed by the garbage collector, and to explicitly perform object create, destroy, slide, import and export operations in those pools.

unwind-protect and dynamic-wind systems were generally sufficient for managing transient objects in unmanaged memory, although weak pointers were also sometimes used.

In general, none of this posed much problem for compiler writers, and the careful selection of a hygeinic macro system for abstracting away management of objects from outside the GC arena also posed little difficulty.

Apart from the fact several solid Lisp environments (commercial and otherwise) have been ported to almost every major operating system in current use, and the evolution of ffi/POSIX calls as a de facto standard part of Lisp programming, the major stumbling block is that almost no modern microprocessors make it easy to accurately identify a pointer. As a result, some software tagging and boxing will be necessary, which will slow down operations on the affected datatypes (usually integers are robbed of one or two bits which are used to distinguish between integer data and memory addresses). Alternative, conservative collection could be used, imposing other costs, and running the risk of memory leaks.

The CADR processor design and its relatives were not as heavily specialized for Lisp as you'd think; the major unusual features were pointer-tagging (and tagging of other native data types), tag-based data-type-testing, rapid selecting of the correct specialized branch of an overloaded instruction, list compactification ("CDR coding"), the incremental garbage collector, and on-chip support for the function calling convention (lambda lists).

The arrival of RISC-ish ISAs with many registers allowing for fast register-to-register shift/rotate/mask-and-match operations, improvements in compiler design especially with respect to Data Flow Analysis after the Yale T project, and the development of background-thread generational garbage collection, generally eliminated most of the runtime advantages of CADR-type hardware support.

x86-64 is reasonably tolerable, as evidenced by the openmcl port in particular, and one could certainly use the output of its compiler for doing "bare metal" systems programming, including OS development.

It was pretty easy to find this page full of links to various experimental and prototype OSes involving Lisp and Lisp-like languages running on bare metal. Sadly there is some link rot, and a substantial number of abandoned projects.

>So you can imagine our suprise when we were informed by a lawyer that we would be required to publish our source code for others to use.

You can imagine my surprise when I realized your "lawyer" doesn't understand the GNU General Public License (GPL). Unless this "top online investment firm" was interested in redistributing the software to others, they are under no obligation to publish anything. As a work-for-hire code monkey, you had no obligation (or even legal right, for that matter) to publish anything.

http://www.gnu.org/licenses/gpl-faq.html

>we were unable to defrag its ext2 file system

You don't say? There is a program called defrag that defragments ext2 filesystems. It is available at better sunsite mirrors, and notably at Sunsite - /pub/linux/system/Filesystems/

http://cbbrowne.com/info/defrag.html

>Unfortunately for us, this meant that the great deal of time and money we spent "touching up" Linux to work for this investment firm would now be available at no cost to our competitors.

My condolences. All that Linux software that was available at no cost to you, and you actually had to put your own work into it? And then (gasp! horror!) you were expected to share and share alike? How did you manage? If it were me, I just would have killed myself from the shame of being so deceived and violated.

However, did you consider that all the touch ups by your competitors would also be available at no cost to you? Wow! That's almost as good as getting a whole kernel and operating system for free! Imagine that!

>Furthermore, after reviewing this GPL our lawyers advised us that any products compiled with GPL'ed tools - such as gcc - would also have to its source code released. This was simply unacceptable.

100% true, except the part that starts with "Furthermore" and ends with "unacceptable."
See the FAQ: http://www.gnu.org/licenses/gpl-faq.html#CanIUseGP LToolsForNF

>Although we had planned for no one outside of this company to ever use, let alone see the source code, we were now put in a difficult position. We could either give away our hard work, or come up with another solution.

You were paid to create something for somebody else, the work belongs to them. Normally this would entail that you would have to 'give away' your hard work, as it didn't belong to you.

>Although it was tough to do, there really was no option: We had to rewrite the code, from scratch, for Windows 2000.

Portability; teach your children that it's not a dirty word.

>I think the biggest thing keeping Linux from being truly competitive with Microsoft is this GPL. Its draconian requirements virtually guarentee that no business will ever be able to use it. After my experience with Linux, I won't be recommending it to any of my associates. I may reconsider if Linux switches its license to something a little more fair, such as Microsoft's "Shared Source". Until then its attempts to socialize the software market will insure it remains only a bit player.

I think the biggest thing keeping Microsoft from being competitive with Linux is the GPL. It's simple requirements virtually guarantee that businesses will be required to provide value through innovation and service rather than creating proprietary lock-in and forced upgrades. After your experience with Linux, I think it's best that you avoid it and creating offspring. Bit players like Ubuntu (the African word meaning 'Unable to configure Debian.') will just have to settle for things like shipping on Dell computers. Sure is rough, but we'll manage; somehow.

After everything, you are certainly free to ignore Linux. Microsoft will be happy to sell you an operating system, office software, and a software development kit.

Free Quickbooks alternatives:

Turbocash on Windows.
Gnucash on Linux. Mmm, also Grisbi, though it lacked double entry last time I looked and not to forget KMyMoney on KDE.

Tax return specific stuff:
http://cbbrowne.com/info/freetaxsoftware.html

There is a program to defrag ext2 partitions, called "defrag", go here and read http://cbbrowne.com/info/defrag.html about why it's not needed though.

... for their network appliance systems.

And Larry mentioned NetBSD for an Oracle database appliance a long time ago.

But, with their recent Linux focus, any NetBSD bias probably evaporated long ago. Linux is flashy, and because of this it is easier to find admins and apps.

Why do I keep hearing MS users insist filesystems need to be defraged constantly? Real OSes have fragmentation prevention built in. The prevention is not perfect, but it beats runing defrag every day. Even linux has had it since ext2 came out at least a decade ago. If MS hasn't done this by now, then they should be bopped in the head. Then again, they make their own users afraid to upgrade. WTF???

The need for defrag on modern systems is a myth. Read here and here

Actually, I was just reading about some alternative spreadsheet technologies the other day over at
http://cbbrowne.com/info/spreadsheets.html which I cam across when looking for
a console spreadsheet app (was looking for sc for linux); I'd prefer something that understands
xls so I can read frickin' attachments easily.

Here is an article about Schwartz and the Lighthouse applications: http://www.theregister.co.uk/2003/09/22/suns_macos _x_suite/

"Lighthouse had a highly-regarded suite of software including the Quantrix spreadsheet, Diagram! vector graphics package and Concurrence presentation software. The names might mean little to today's Apple users, more's the pity. Apple's Mac OS X is a cosmetically enhanced update of the old NeXT system... .. Jonathan - Schwartz, told us that the source would in all likelihood remain in Sun's morgue."

"Little chance," he told us. "We're not really trying to promote Objective-C anymore, much though I loved the products we built. We think this Java thing has some legs to it."

The Lighthouse's memorial site http://lighthouse.ithinksw.com/index.php referenced in the article and on this gnustep page http://cbbrowne.com/info/gnustep.html does not seem to work anymore.

I was a bit puzzled by the OP's mention of support under OS X. When I set up my wife's iBook bor her, I was pleased to notice that emacs was installed by default. Maybe he's talking about XEmacs? I've never used the latter; GNU emacs supports X11 well enough for me, and is now my editor of choice since I stopped using TECO back in the early '90s.

You mean TECO?:-D

database.store(object);

Ok, I've done my research. As found on Christopher Brownes' pages, a page about filesystems:

``I need to have files bigger than 2GB. What's the big problem?''

• ext2fs in linux-2.2 supports files bigger than 2GB (up to 1TB for filesystems with sufficiently big blocks (the limit comes from the triple-indirect blocks)).
• On Linux-2.0, there is no support for more than 2GB files.
• On Linux-2.2, files bigger than 2GB are supported but only on 64 bit architectures (alpha, Sparc64, ...). So on Intel, you're out of luck.

So no, both 32-bit and 64-bit platforms did not get large file support at the same time. It was originally developed on 64-bit platforms where it was simplest, and later a suitable mechanism was added to the 32-bit platforms that Linus was happy with. Sometime in the 2.3 development kernels I suppose. I have trouble remembering all these little historical trivia anymore.

And I never said that a system needs to address every byte. That's why I put "4G * 512 = 2T" in brackets. Didn't you notice the number 512? What I was saying was that as drive/array sizes grow, they will nolonger be (easily) addressable by 32-bit systems. Mind you, I'm sure there's lots of RAID arrays out there larger than 2T on 32-bit systems. Hell, LaCie has a portable 1T FireWire enclosure. So they obviously already have the capability and have had for some time. My bad.

My point was that it's simply easier and more efficient to pass those offsets around in single registers and do calculations in single operations. As to whether the small increase in speed/efficiency is worth the cost is another matter. But Athlon-64's are pretty cheap. And Opterons or G5's aren't much more expensive either.

Good luck getting rid of Dell at your workplace :)

But the small size doesn't make most systems faster. Running the same Unix API, L4 adds execution time overhead beyond the default monolithic Linux kernel, about 5%. (Does anyone know the figure for Linux-on-Mach? I know it's much greater than 5%....) However, there are some significant advantages having to do with debugging, maintainability, SMP, real time gaurentees, memory management, configurability, robustness, etc. Detailed discussion here.

From the overview:

Kernels based on the L4 API are second-generation -kernels. They are very lean and feature fast, message-based, synchronous IPC, simple-to-use external paging mechanisms, and a security mechanism based on secure domains (tasks, clans and chiefs). The kernels try to implement only a minimal set of abstractions on which operating systems can be built flexibly.

Other links: L4KA homepage, background info, more info with some historical L3 links.

Frankly, I think L4 is very much the right way to do things. I wish I could say the same for other parts of HURD.

How about graphical programming languages (GPLs) like LabVIEW which I believe was decended from a language called G.

And then there is the whole class of functional programming languages like FP and ML and their various derivates.

Another language I didn't spot was SAS , a high-level statistical programming language used by auditors and banks a few years back.

Not to mention anything about more hardware related languages like VHDL.

I'll stop now, before my background starts showing too much.

Preferably killer apps?

If you write a whole new desktop system, you'll have to port a lot of apps to it. In fact, you'll probably want a compatibility layer with some other system; given that the only one of the Big Three desktop standards that isn't proprietary is X, you'll have an X compatibility layer (this is fairly easy to do, too).

But what does this really gain you? Where's the payoff for the user? How does using e.g. NVIDIA pixel shaders enhance usability in a way you can't do with X?

There are routinely groups of people who set out to do this. The Berlin project (which appears to have moved to http://www.fresco.org/) is the biggest example; the last news on that page is from 2003, so we can consider them dead.

Read this on X bloat...

"I would feel more comfortable in (given the concept in a skills test is assessment in a short space of time, a conceptually 'nice' RAD language (that can be programmed quickly as well as designed quickly) would win over stock languages)."

That would be Flowdesigner.

Failing that there's Lisp or Smalltalk.

"I would feel more comfortable in (given the concept in a skills test is assessment in a short space of time, a conceptually 'nice' RAD language (that can be programmed quickly as well as designed quickly) would win over stock languages)."

That would be Flowdesigner.

Failing that there's Lisp or Smalltalk.

This is very true; I'd go further and say if you want to experiment with OSes, want the result to be usable, but don't want to implement the boring but difficult to get right bits, you can't do better than OSkit. Check out Christopher Browne's Novel OS work page for leads to cool things.

Can anyone please provide a link?!

Oh, nevermind...

I think you might have confued bragging with desperation.

Novel OSes. Most research is currently being done on capability-based OSes, not Unix-based OSes.

You are, unfortunately, really speaking out of ignorance here. The very structure of the kernel should change if executing atop a Mach (or any other) microkernel, since the microkernel provides services that should be offered directly to executing applications, rather than funneled through a monolithic kernel running on top of the microkernel. You should probably read up on the topic, if you really want to know. (I make no guarantees about that link; it's just what google popped up this morning.)

The proof is here

A REAL comparison would be nice.

Here is a review of the linux offerings and another. One more.

Does Common Lisp lend itself easily to kernel, systems, or real-time programming on mass-market computer architectures?

I know that the developers of a popular PS2 game have disclosed that the game's business logic is written in Lisp

but would one want to write a 3D engine or a cellphone game in Lisp?

PS - in a recent dick-measuring benchmark (the "Coyote Gulch" floating-point ephemeris calculator), CMU Common Lisp and Steel Bank Common Lisp produced code 5% faster than GCC on a Pentium IV. The participants claim it was "an hour-or-so's work".

Is there just no way to do this with GPL software?

>The interface isn't as nice, i.e. it's not as easy to get things done.
depends on what you use it for....depends on who you ask..etc...

>The startup time is abysmal
try loading it into memory right after boot....and leave it there mister 512mb RAM.

>I use a spreadsheet for time tracking mostly
there are other programs besides OO, you know?

>The large company I work for during the day has a deal with Microsoft where I can get the full version of the latest Office for $20.
Sounds great...not many other people have such a great deal, and many people are trying to get away from being locked-in to MS products. Oh yeah, and MS doesnt like to play with all the other boys and girls, rather they try to break them. Take, say, Corel WordPerfect. It took many hours trying to diagnose problems with it only to find out that Office INTENTIONALLY tried to crash it. So if OO doesnt seem great on a Win machine, perhaps you should compare it to that running on linux...just to calibrate how correct a feel you are getting in terms of speed, memory, and stability.

> the big downside is it is a hinderance to productivity.
depends on what you use it for....depends on who uses it...depends on who you ask..etc...

For a good bit more work, but less money and the karma boost of avoiding proprietary (and somewhat buggy) Access, it looks like OpenOffice has rudimentary support for databases. Take a look at the UnixODBC project, specifically this PDF, which seems to do a decent job of explaining the steps involved. Note that I've never tried this, but it certainly looks workable. As a bonus, you should be able to use any database with an ODBC component.

Of course, you could always go with dBase (who bought some of the rights from Borland), who have a web enabled dBase version. It'll need to be hosted on a Windows machine, it looks like though.

You may also want to take a look here which lists Windows and *nix xBase compatible programs. xBase was (is?) a standard that dBase, Clipper, FoxPro and others adhered to. Perhaps you'll find something there. Also, there was a dBase for UNIX at one point...I don't think it's still for sale, but you may be able to turn up a copy on eBay or something.

One last suggestion would be KNoda which is a KDE frontend that allows for queries, forms, and table design. It looks a bit like Access, though, once again I haven't tried it.

That should start you on your research...good luck.

It is quite interesting what they are doing with MySQL-Max with seems to be their enterprise solution. They teamed up with SAP DB, an open source database technology that SAP bought from Software AG to tease Oracle a bit. It is based on Adabas D a commercial database that has a "oracle compatibly mode" via ODBC.

It is quite interesting to see a mixture of SAP DB and MySQL united in MySQL-MAX. (Infoworld article)

Although we met several technical challenges along the way (specifically, Linux's lack of Token Ring support and the fact that we were unable to defrag its ext2 file system)

See here for HOWTO on Linux Token Ring, and here for a discussion of why ext2 filesystems don't really need defragging. Oh, and report to the CEO of each company you consult for, requesting to be fired for being a pig-ignorant moron; I found these examples from 2 minutes on Google.

Dude, you got modded up for trolling!

The UNIX philosophy is about design. The book explains some of the ideals behind how UNIX, and UNIX like, operating systems came to be what they are and why they work as well as they do. People who get hung up on the word "philosophy" and think that it only pertains to metaphysics, economics, theology, or morality need to understand that philosophy also applies to design and the creative arts.

Perhaps they should admit that they really have no idea what philosophy means instead of attempting to deny it's presence in areas of thought where they fail to recognise it.

Christopher Browne has a good synopsis for those who would like a primer before they run out and buy one of the books.

Extension of your point: all instant messaging systems I can think of will have the same limitation. AIM, Jabber, iChat (not that that's relevant here), MSN, etc. will not queue up messages for users when they aren't logged in. I seem to remember that ICQ would store up messages, but how many people use ICQ anymore? In any case, the only IM server that can reasonably be run by yourself is Jabber, and as far as I know (I welcome corrections) it won't queue up messages.

As some in this thread have said, Jabber is probably the best band-aid over this particular problem, but fixing the multiuser aspects of the database software is the true cure. If Quickbooks Pro can do the job, it should be considered. Alternatively -- and this may be a stretch, depending on your needs & your trust in free software -- GnuCash can be configured to run PostgreSQL as the back-end data storage. This should address all the concurrency & stability issues beautifully; the only issue is that, as near as I can tell, this is still a beta quality feature, and the database schema seems to be evolving.

That and GnuCash might run more happily on Linux, which could scotch the idea if you're really an all XP shop... :-(

If that's the case, the QBpro is probably the safest option -- it should be examined.

But the reason it takes so long to fix them is stupid design.

The myth that complexity is only achieved through complicated design is pervasive in computer programming, typified in Windows, and becoming more prevalant in Linux applications as Gnome and KDE become the standards.

The UNIX operating system was highly complex even in the days when it was dominated by small programs that were designed with the The Unix Philosophy. Small programs that did one thing well were the rule and complexity was achieved by utilizing clean well documented interfaces, standard data storage formats (ASCII), and non-captive UIs. The result is that most bugs can be tracked down to a specific small program that can either be fixed relatively quickly by the maintainer, or be replaced with one of a number of equivalent programs (either permanantly, or until the bug is found and fixed).

Windows design is mostly large programs that try to do everything for themselves, although they do share library functions. The result is huge masses of code that can effectively hide bugs indefinately (shatter), cannot be replaced with another program without breaking the OS (integration), and that the company seems to think of as "not our problem".

The issue I have with the desktop environments is that they seem to be following in the footsteps of Windows design, creating a tangled mess of (what should be) unecessary dependancies, huge libraries, and code that no one person is inheirently familiar with. As yet, I am unaware of any security problems inherent in either Gnome or KDE, but I do consider it a bug that installing a spreadsheet requires also requires a sound library to work properly.

Complex ends can be achieved through simple means and complex programs or OS do not need to be complicated.

You've probably already come across it, but Compiere is a great ERP/POS. It's open source (MPL), but currently requires Oracle, which ups the minimum investment to $1,500 -- probably not in your budget. The PostgreSQL port is reportedly in progress.

There are other small systems around that you've likely already seen, such as SQL Ledger (with a web UI, yuck).

This site seems to have some suggestions as well:
Christopher Browne's compilation of free software for accounting.

It would not be outside the realm of possibility to utilize wine to run your accounting software. FYI, I wasn't able to get QuickBooks 2002 running with Wine 5/08/03 snapshot -- but I didn't try very hard.

Good luck.

The argument of "what's out there isn't good enough" doesn't fly either. You have the source to fix it and make it better!

Quick show of hands please: How many people have tried to "fix" the X Window System?

Many people feel that X11 is a bloated, unmaintainable hack. It is absolutely full of cruft.

My hope is that this effort gains enough of a foothold that it attracts developers that can put a WINE-like layer on it to translate KDE or QT calls. Then, as people migrate from lower-level toolkit libraries (Athena Widgets, TCL/TK, etc.) to higher-level libraries, it becomes simple to port their apps to an O/S like Syllable that doesn't have all the cruft that comes with an underlying X11 layer. Now, I realize that's a bit far fetched, but it is a step in what I feel is the right direction.

Yes, it is extra work to develop a new O/S, but the GNU/Linux crowd is inextricably tied to X11. If it takes a new O/S to see the benefits of a simpler graphical subsystem, then I say its worth it. DirectFB could be the answer for Linux, but doesn't get the attention or support I feel it should. (Hey, Trolltech, how about a QT port?) For those of you with your favorite X11 apps that don't have a port yet, DirectFB even has a rootless X-server.

FWIW, I use X11, but I don't program with it. Everyone I know of that does program with it complains about it. They say its bloated, difficult to program at the lower levels, and generally complain about its cruftiness. Use of higher level libraries are making these types more and more scarce, which I think is a good thing.

Those who do not learn from history are doomed to repeat it.

NeWS was a peer of X-Windows, based on postscript; it was incredibly powerful and underpromoted. The only licensee that I recall was SGI: it was the basis of the IRIX window system in the early 90s. The language itself was an object oriented version of PostScript; the frameworks were entirely object oriented.

NeWS was canned because it couldn't compete commercially with (free) X11. For a humorous slant, check out the Unix Haters Handbook or this link.

Many of the language implementation ideas from NeWS went on to Java; James Gosling was a primary with both.

As an aside, this is an example of how "free" software dealt a death blow to demonstrably superior commercial software.

A brief look at the picogui web pages found 10 different themes for the eye-candy set and 0, count'em, zero, applications. If I wanted that, I could run MGR
(Howto, Screenshot),
which does have actual applications (not that anybody's maintained it in years, but it's small and lightweight and at least used to be really fast back when computers were slow)
or some of the Other Obsolete Operating Systems.

Any Ideas why it hasn't been included ?

IMHO, it is because Bluetooth recognition/adoption by both manufacturers and users has been slower than WiFi. Also, the implementations of Bluetooth have been pretty uninspiring. I can create a Bluetooth net with a Tungsten, headset and SonyEricsson, and with the phone in my briefcase place a call using the Tungsten. Neat. When a call comes in however, the Caller ID information is not passed back to the Tungsten through the Bluetooth net so I can see on the Tungsten who is calling (the Mac OS X Address Book supports this). Almost a textbook illustration of flashy demo technology that is impractical in daily use.

Palm's choice of data architecture unfortunately makes it difficult to take advantage of these technologies that bring a Unix-like philosophy to devices (make 'em small and usable in different contexts, allow users to combine and recombine, sometimes in ways the original designers never thought of). These types of devices really come into their own when they can fluidly share data between themselves; their utility grows far beyond the hardware's core benefit, and is only limited by the software. The Apple Newton's Lisp'ish soups data architecture held a lot of promise, and worked really well when vendors took advantage of it.

Manufacturers also share some responsibility however for lacking some marketing foresight. Not being able to reprogram the Bluetooth support in their devices limits their future utility. It also places a cap on possible revenue streams for software upgrades, implementing features for increased and diverse uses, often driven by businesses, that the market finds. These uses sometimes fall outside of the original vision of the device, and add revenue streams from unexpected places. And That's A Good Thing (tm). A lot of people who hear about Bluetooth, and it seems these people might include the device manufacturers, do not understand that simply implementing the Bluetooth transport doesn't make magic happen. Just as simply expressing your invoices into XML doesn't replace your EDI system overnight. The magic happens because a protocol is exploited by both sides of a transaction. Locking up your protocol support implementation into non-replaceable firmware means you just locked yourself out of exploiting different uses of your hardware that become apparent later on. This drives up the useful lifecycle of your product line's core implementation, drives down R&D costs, and drives up the number of revenue sources to tap into.

These are a very rich vein of sales and marketing possibilities that Palm and manufacturers spending R&D money on Bluetooth support for their product lines have failed to grasp. They implemented Bluetooth without grasping these possibilities and taking action upon them, then stood aside expecting the world to beat a path to their door. When that didn't happen, they charged off to chase the next chimera of profitability, which you see today.

Just remember, Linus (the roof making Finnish kid you talk about) didn't even originally brand the kernel as Linux. He named it Freax. Get your facts right.

On the other hand, GNU/Freax sounds more appropriate.

From the article:

The Nazis were archetypal Romantics.

While appearing on the web, not on Usenet, clearly this is a violation of Godwin's Law.

Sorry, Dave.

The following may be dated, but as far as I know it is still accurate. Time is stored in many fields that we cannot simply change on a recompile for all sorts of reasons, like binary compatibility in your filesystem.

Yes, Linux compiled on 64-bit platforms has Y2038 problems still.

Furthermore even if it was as easy as you say, we still would want a better solution. One second granularity made sense with 1970's hardware. It doesn't make nearly as much sense today. If you are going to 64-bits anyways, then there is no reason not to come up with a solution that stores timestamps to the nearest millionth of a second, even if it is only good for the next few hundred thousand years.

We're talking about Naive Bayesian Filtering, where the assumption is made that we can assume the use of Bayes' formula even though we know it's not quite independent.

What you're missing is that the real formula doesn't just involve two words; it involves all of the words in the message.

The usual formula is Rf, and you'll notice that it involves multiplying the occurrances of words in the message with the logarithm of their frequencies in each folder.

The word "sexy" may usually be enough to consign messages to the Spam/Websex folder, but if there are some occurances of the term "sexy window manager" in a discussion of some window managers, the fact that the names Enlightenment, WindowMaker, stupid , memory-hungry and themes occur rather a lot in X/WM and never in the Spam folders means the relevance total will most likely favor the right folder.

The typical formula is
Relevance - Rf

There may be a bit of a "fight" between the words, but if all the messages containing the string my_wife@frobozz.org go in the Honey folder, and occasionally contain phrases like That dress was so sexy or the likes, that will change the Ff(w) value for f = Honey , and the message will be appropriately routed, perhaps into the subfolder Honey/Rendezvous where you put the weekly messages of that sort from your wife.

Of course, there's then the non-technical problem, namely locating a wife that would actually send that message.

"Since oral sex is topologically equivalent to anal sex, converting one to the other is simply a matter of finding the right conformal map. Currently I only have solutions for a spherical girlfriend." -- Robert Bowler

But this isn't enough, by itself, to classify a message. Messages do not solely consist of one or two words; they consist of many. And collecting the statistics together requires calculating a "relevance factor," based on all the words.

The one used for Naive Bayesian Inference is as follows: Rf calculation , and you'll notice it involves doing a logarithm-based weighting.

The formula doesn't care what words are used, or that you think one folder contains "spam" and that another contains "gold."

In my corpus, the word sex is used in 65 different mail folders, mostly probably pretty "innocently."

Drawing conclusions based on one or two words is, unfortunately, pretty incomplete. It might well be that the one use of "sexy" in a particular message doesn't force it into the Spam/Phonesex folder because it makes even more extensive mention of Enlightenment and WindowMaker and GTK Themes and winds up being very strongly tied to the X/WindowManager folder because there are several other words not related to sexual activity that make it (correctly) appear relevant to a discussion of window managers.

Graham is drawing an analogy based on two words (words likely to grip adolescent attention!); reality involves adding everything up, and those two words certainly don't tell the whole story of the whole corpus.

It should also be noted that the Soups data structures (see a brief description of how they work, which would be immediately familiar to Lisp/Scheme hackers) has still not been recognized, embraced and exploited by the PDA community to date. This one innovation would make it far easier for Palm developers to leverage off of each others' work instead of the ludicrous workarounds we have today to try to store related data in other Palm applications' databases.

The system has been functioning perfectly well with the non-existent (in comparison!) bandwidth of Plain Old Telephone Modems; there's no reason for the product they're selling to need Firewire.

Doubtless the MPAA and related folks would be aghast at the thought of having fast interfacing to disk; that's just "piracy" asking to happen.

If they can get USB cheaply on the motherboard, and that allows hooking up a number of cheap USB devices, that's quite enough enhancement for now.

As for Ethernet, I agree that it would be pretty slick to throw that in. It would seem to me that dropping an Ethernet chip onto the motherboard and a port out the back would be a pretty good way to go, and would offer the merit that folks with ADSL or "cable modems" could then get their TV guide updates faster without needing the ISP service. (That saves TiVO some Actual Dollars, no doubt!)

However, there are some technical hurdles to get thru in supporting the Ethernet-to-Some-ISP-connection strategy; it means:

• Users of this have to have a router and/or hub;
  
• Users of this have to have a bunch of spare Ethernet cabling (or wireless Ethernet; that's more expensive!!!;
  
• Users that think of this as an appliance will need considerable handholding in the process of Integrating EtherTiVO into The Home Network Architecture
  
  

I'd be comfortable with all this, but then, I've got a hub, firewall, and have my own 10BaseT cable-building equipment. I'm hardly the "appliance user" they're mostly selling to.
Colour me unsurprised that they didn't want to just leap into that...