Slashdot Mirror

dominik@schnitzer.at, mozparty-at-subscribe@relax.ath.cx, dominik@schnitzer.at, david_markvica@web.de, johannes_richter@gmx.net, kairo@kairo.at, rossi@chello.at, markush@world-direct.com, cbiesinger@web.de, jenskager@gmx.net, jo-at-mt@gmx.net, johann.petrak@gmx.at, dviper01@gmx.net, simon@simonschwaighofer.net, dreckskerl@glump.at, wt-lists@trexler.at, dusty@strike.wu-wien.ac.at, kasparhauserjr@hotmail.com, b.schallar@gmx.net, mutato@libero.it, phil@goli.at, diddalick@gmx.net, studio@paw8.com, croco@utanet.at, petru@paler.net, jlemmerer@node.at, bigkub@time2change.at, patrick@seher-it.at, ronald@hartwig.at, mozilla_party@webterminate.com, stefan@kleinhans.it, horst.jens@gmx.at, jjan@gibts.net, mjahn@agency.at, gpoul@gnu.org, green@eggs.ham, gerhard.hipfinger@openforce.at, mailto:moz@moz.org>, florianweinwurm@yahoo.com, christian@precht-jensen.dk, Bill_Gates@microsoft.com, Tux_the_penguin@linux.rules.microsoft.sux.open.sou rce.is.the.way.to.go.net, domi@schnitzer.at, joe_ringmaster@gmx.at, sifu@isohypse.org, dk@perm.ru, nobandwidth@bigpond.com, nobandwidth@bigpond.com, luke@strangemonkey.com, mrundataker@optushome.com.au, mcgarry@tig.com.au, chris@think.net.au, Mathias.Burbach@Bigfoot.com, acuteparanoia@optushome.com.au, syzh401@cse.unsw.edu.au, maillist@jasonlim.com, ram@digitalmethod.org, jason@sydneypubguide.net, geek@digitalone.com.au, curious@ihug.com.au, bill@maidment.com.au, kristof@staesis.org, bill@microsoft.com, belle@netset.net.au, ksosez@softhome.net, jruderman@hmc.edu, andyed@surfmind.com, down8@yahoo.com, mozparty@sigkill.com, bulbul@ucla.edu, gavin-mozparty@doughtie.com, roger@digitalfountain.com, matt@linuxschooltorrance.com, mozparty@ventura.nu, rombouts@compuserve.com, ian@freenetproject.org, tristanreid@yahoo.com, groovefx@yahoo.com, jj@lacasabonita.com, gmoudry@hotmail.com, eyezero@yahoo.com, ian@primewave.net, jlawson7@adelphia.net, el_arturo@att.net, janie@freenetproject.org, 145371217@numenor.net, infinite_8_monkey@yahoo.com, charshman@divus.org, mozparty@shadowlurker.net, john@marinapacific.com, ilanterrell@yahoo.com, aafes@psu.edu, bustamam98@yahoo.com, mozparty@myunixbox.com, yaten@sbcglobal.net, joelinux@pacificnet.net, dgc@penguino.net, poserskater69@yahoo.com, lheartb@hotmail.com, ncmother@zimage.com, daniel@likeicare.com, digital.evil@lycos.com, cjeburke@yahoo.com, jblow@hotmail.com, zachary.anthony@verizon.net, boogah@23.org, mebelost@yahoo.com, nickkricheff@netscape.net, mikemcg@ucla.edu, gogomozilla@denofslack.net, mike@mm1.com, seanmcoleman@attbi.com, jsm@bigfoot.com, hoarycripple@crippl3.net, mozparty@nslu.x.myxomop.com, mozparty@camworld.com, mozpartyNYC@isoga.net, ccarlen@netscape.com, h@rediffmail.com, lefever@rcn.com, tedjackson@accounting.org, darren@ny.com, marlon@nyc.com, plui@hyperreal.org, dzeluff@zeluff.com, joel@natividads.com, ken@bigbadapple.com, treebeard@treebeard.net, florent@nyc.com, chad@macristy.com, spud@montelshow.com, gbman_of_gvill@yahoo.com, eam-mozparty@learningpatterns.com, pkrause@primavera.com, tossoffus@yahoo.com, ryan@pantz.com, nichomof@eecs.tulane.edu, billg@microsoft.com, DevilsRejection@msn.com, petergunn@hotmail.com, bagerj@sullcrom.com, isaac@structuredsystems.net, bobk@panix.com, ngellner@hotmail.com, luke@sigterm.org, vivake@yahoo.com, jon@mediavortex.com, groovefx@yahoo.com, brendan@sighup.net, jds@panix.com, bluerose@bluerose.com, chris@allermann.net, dimkal@yahoo.com, preppyl@yahoo.com, blujoker@blujoker.net, nowell_h@hotmail.com, aragorn@cs.stanford.edu, treed@cpr.com, brt204@nyu.edu, andreas@antonopoulos.com, dj@randomwalks.com, lists@pote.com, mike@mhudack.com, reliable57@yahoo.com, jared@geek-boy.com, ondadl@mac.com, floss@myrealbox.com, xod@thestonecutters.net, mozilla@sectae.net, tywonm@screamingmedia.com, Odin_NT@hotmail.com, crooney@panix.com, bg25222@binghamton.edu, eugenem@brainlink.com, dave@downneck.net, romspace@mac.com, sdaejo@yahoo.com, masseo1@yahoo.com, jim@fearandloathing.net, mike@mjoy.us, miles@openly.com, LuciferSD@hotmail.com, nsdilwor@intertechmedia.com, chrisdowden@yahoo.com, pgs10@columbia.edu, sbrennan@ovid.com, lthomiso@rcn.com, paralox@paralox.ath.cx, Jester_458@yahoo.com, jsadove@beltion.net, stuehmke@yahoo.com, mike@realfx.com, alex@risky-roosky.com, shava@efn.org, kra10@columbia.edu, saihung@ix.netcom.com, gropo@mac.com, scottnym@yahoo.com, shaas@vibe.com, roon_toon@hotmail.com, ajaygautam@yahoo.com, jhdaly@mindspring.com, manuel@sphinx.ms, very_itchy_rash@yahoo.com, emeldrum@drew.edu, jeld@mindless.com, as867@columbia.edu, slams@penguin.rutgers.edu, wassa@columbia.edu, tony@vegan.net, zilla@bibliotrack.com, zeno_lee@hotmail.com, fosh@fishnet.cx, linux@gpl.us, jblow@hotmail.com, dkrook@hotmail.com, ivesti@yahoo.com, arek@arekwyderka.com, bljoechang@yahoo.com, brian@tribrothers.com, sparky@marklife.org, charles@softwareprototypes.com, scottkundla@hotmail.com, ccharabaruk@meldstar.com, ian@pottinger.ca, netdemonz@yahoo.com, diatribe@mailcity.com, nick@tomkinet.com, shawnlin@yahoo.com, sculley@pathcom.com, herd.killing@rogers.com, dave@renouf.com, aliyamin@hotmail.com, aswitzer@ispgn.com, netm0nkey@ispgn.com, hyakugei@hotmail.com, geduggan.mozparty@peri.csclub.uwaterloo.ca, lwhite@darkfires.ca, jorel@the-wire.com, js@tap.net, davew@tap.net, tmh@whitefang.com, vid_mozillaparty@zooid.org, anon@foolswisdom.org, morris_mk@yahoo.ca, colinmc@idirect.com, marcus.brubaker@utoronto.ca, akish@kishcom.com, nconway@klamath.dyndns.org, jason@thegeekcave.com, rampaging_simian@hotmail.com, garret@sirsonic.com, piowie@myrealbox.com, m5m5m@yahoo.com, ivan.brovko@net-sweeper.com, returnofthedorks@hotmail.com, axxackall@yahoo.com, tednye@sympatico.ca, darren.fuller@bell.ca, jbailey@nisa.net, swangeo@yahoo.ca, Hercynium@yahoo.com, cinetron@passport.ca, jotaroh@hotmail.com, aghajani@principle.com, fzv@yahoo.com, rocketmail_com@rocketmail.com, foo@bar.com, wolfe@alt.net, drew@xyzzy.dhs.org, jimmiejaz@nixhelp.net, bofh@swma.net, nilesh_mehta@email.com, mslack@rogers.com, m-cahill@rogers.com, tworkowski@sympatico.ca, george@openlight.com, irina@openlight.com, ilia@lobsanov.com, rjs@tao.ca, paul-mp@it.ca, alvarolists@aycuens.com, xan@dimensis.com, ike@lab.org, miguel@asiinfo.net, marevalo@marevalo.net, iolalla@yahoo.com, peluz0n@justice.com, weeddeveloper@yahoo.com, alfonsobugs@terra.es, sgala@apache.org, z_gringo@hotmail.com, santiz@madritel.es, murphy@litio.net, fox@mozilla.gr.jp, party@mozilla.org.uk, danj@fledgeling.com, fun@thingy.apana.org.au, moz@the-allens.net, onelists@hotmail.com, joel@fysh.org, simon.mozilla-party-if-its-in-central-london@rumbl e.net, bigboyjim@excite.com, andrew.and.friends.iff.central.london@sent.freeser ve.co.uk, itwillbecentrallondon@mozilla.org.uk, noahsark2x2@tiscali.co.uk, mmm-central-london@smileyben.com, jonathan-for-central-london@peepo.com, dave-Party-in-Central-London@dgta.co.uk, DJGMOL@netscape.net, srick@europe.yahoo-inc.com, moz-party@zpok.demon.co.uk, moz-party-central-london@trickofthelight.org, marc@brosystems.com, party@budge.net, rillian@telus.net, uphillsurfer@hotmail.com, edward@debian.org, mozilla@robertbrook.com, reagan@technomoose.com, lew@saltbeefsandwich.co.uk, osama@afghanistan.com, barking@insaneworld.org.uk, john@billabong-media.com, leith@cs.bu.edu, mozparty@noseynick.org, jonasj@jonasj.dk, bugzilla@kenneth.dk, chr_damsgaard@hotmail.com, alring@email.com, hp.grondal@get2net.dk, martin@marquentein.dk, Lovechild@foolclan.com, Kim@schulz.dk, kl@vsen.dk, mbendix@dunghill.dk, schnitzer.at@tange.dk, tommy@svindel.net, moz10@pbb.dk, dezral@despammed.com, nick@tioka.com, ask@fujang.dk, gecko@c.dk, spam@deck.dk, bugzilla@gemal.dk, b@bogdan.dk, kenneth@gnu.org, jee@email.dk, daniel@rtfm.dk, umfalvo@yahoo.com, christian@ostenfeld.dk, xor@ivwnet.com, Jason@screaminweb.com, alex@spamcop.net, dustym@riseup.net, rmcgee1@earthlink.net, dr_zeus@hotmail.com, chris.lozano@myrealbox.com, looney_binn@yahoo(dot)com, apendell@attbi.com, dantrevino@wrevolution.org, fireball1244@mac.com, tommyo@hargray.com, natas@redtailboa.net, emmett_in_dallas@yahoo.com, razzbuten@yahoo.com, igdavis@truculent-telephone.org, foobar@null.net, bob@kludgebox.com, cgrimland@yahoo.com, ghamlett@swbell.net, bgood@inceptual.com, slot0k@pogox.org, kwhudson@netin.com, jimjamjoh@softhome.net, jimmys@utdallas.edu, charlesv@mfos.org chris@focus2.com jest6r@hotmail.com steve@ncc.com, usrg@mail.utexas.edu, steve@deltos.com, alex@avengergear.com, mkoenecke@alum.haverford.edu langley@hex.net mordred@inaugust.com swapan@yahoo.com drosoph@hotmail.com, goulash1@mac.com, ean@brainfood.com, vj@vj.com lpret42@hotmail.com bugoff@hotmail.com chad@digitaltriage.net, stewart@digitaltriage.net scottvr01@yahoo.com adam@dfwuptime.com dsaint@gnumatt.org naltrexone42@yahoo.com, webmaster@bast.net, tommyo@hargray.com, ladd@kryp.to, jtaylor5@bayou.uh.edu, jgschmitz@linuxmail.org, enslaver@enslaver.com edfierro@yahoo.com, moz@photonsphere.com, rayw@fuckmicrosoft.com, rfmobile@swbell.net, kevin@unif.com trident5@bigfoot.com Erik_Osterholm@ieee.org, tmunson@houston.rr.com, alessi_brand@hotmail.com, rballa1@lsu.edu, wasted@kewlhair.com, jofficer@martinapparatus.com, idiot@mylinuxisp.com, j0sh01@ev1.net faust@wintermarket.org bouncer@hotmonkeyporn.com tk-mozparty_@perljam.net janisch@students.zcu.cz, aha@pinknet.cz kuzi@atlas.cz scat@reboot.cz, petr@dousa.cz, ruzicka@core.cz, roman@management.cz, hojan@students.zcu.cz, tille@soti.org, cas.tuyn@hetnet.nl, aeon@pandora.be, sensi_millia2000@yahoo.com, crypto@shiftat.com, jan.fabry@vsknet.be, monkeyboy@fruru.com, adulau@foo.be, johan@linux.be, karu@pobox.com, soggie@soti.org nick@tomkinet.com, why_are_you_too_lazy_to_drive_1_hour_to_toronto@yo u_lazy.com try_grammer_class_a_while@get_a_life.com john@interlynx.ca asharp@axo.cc, unionstation@ryder.ca, prade@hotmail.com, 2600@hamilton2600.ca, chris.lozano@myrealbox.com, dantrevino@wrevolution.org, jksteinhauer@netscape.net, i_love_junk_email@yahoo.com, cmiller@surfsouth.com, jan@bestbytes.de, me@phillipoertel.com, sebastian@pixelsalon.de, ccozan@andtek.com, ben@itlib.de, martin.ament@gmx.de, pulsar@highteq.net, muid@gmx.de, cedi@zooomclan.org, soapy@soapy.ch, deep_blue_ocean@gmx.ch, stamp@zooomclan.org, hans@switzerland.com, milamber@zooomclan.org, mtettea@switzerland.com, cylander@zooomclan.org, duke@zooomclan.org, pegirun@gmx.ch, pilif@pilif.ch, mlati@yahoo.com, Mozillzooom@holophrastic.com, erichiseli@yahoo.com, la_burdet@yahoo.com, rkoerber@gmx.de, dotzmasta@hotmail.com, B.Eckstein@cli.de, rtfm@linux.de, info@phosmo.de, gz@disintegrated.de, byronbay@gmx.de, stiwi@mac.com, mage@koeln.netsurf.de, mozilla@portfolio16.de, wrede@fh-aachen.de, ilikemozilla@html.de, cloud@final-fantasy.de, sfricke@sfricke.de, info@flossbau.de, no@dom.de, julian.suschlik@gmx.net, omero@m4d.sm, lapo@lapo.it, alcor78@email.it, info@fuelcat.it, mutato@libero.it, ildella@inwind.it, a.marabini@spinthehumanfactor.com, uomoman@criticalbit.com, thefl74@netscape.net, elbardo@libero.it, clem131@libero.it, t-i-e@bigfoot.com, gng74@libero.it, moz.party.20.gnes@spamgourmet.com, ema.cerqui@libero.it, ubertob@tin.it, mozparty.20.anagoor@spamgourmet.com, gianpaolo@preciso.net, ian@deepsky.com, marco@porciletto.org, planetx2100@hotmail.com, billabong@tiscalinet.it, piofree@libero.it, skunkyboy@tiscalinet.it, vincenzo@mondopiccolo.net, macmatteo@interfree.it, contreras@jce.it, hereandnow@libero.it, pza@students.cs.mu.oz.au, caedwa@students.cs.mu.oz.au, mgi@students.cs.mu.oz.au, bah@humbug.net, mfp@cs.mu.oz.au, nospamplease@indevelopment.org, peter@simplyit.screaming,net, pmj@users.sf.net, xanni@sericyb.com.au, agh@kalcium-is.com, felicityconsult@ozemail.com.au, lucas@lucaschan.com, andrewg@nopninjas.com, andym@abnormal.com, ts@meme.com.au, jasonpell@hotmail.com, syngin@gimp.org, mhammond@skippinet.com.au, szutshi@devraj.org, rmoonen@bigpond.net.au, fawad@fawad.net, ufs@softhome.net, kotrade@yahoo.com, ben@benscorp.com, stevesmith@columbus.rr.com, kkimmelosu@yahoo.com, neal.lindsay@peaofohio.com, pat@linuxcolumbus.com, chrisbaker@iname.com, hiroki2c@yahoo.com, seth@remor.com, jsohn@columbus.rr.com, ross@nanonet.net, mark@cushman.net, swinghammer.2@osu.edu, roberto.12@osu.edu, farhat@hotmail.com, pgunn@dachte.org, jwagner@gcfn.org, bp@osc.edu, joepletch@postmark.net, dsherman@iwaynet.net, glenn@uniqsys.com, bernstein.46@osu.edu, trent_reznor@nothing.com, erikniklas@bobanddoug.com, walters@gnu.org, timo@bolverk.net, annek25@aol.com, jlamb@leader.com, bart@osc.edu, jason@mcvetta.org

I have Quicken running just fine on my Mac OS X system. I guess the title should be "Personal Finance Software for Unix*? (*not including Mac OS X)". ;-)

Anyway, google found these...

Good summary page...
http://vip.hex.net/~cbbrowne/finances.html

Various packages...
http://www.moneydance.com/
http://cbb.sourceforge.net/
http://www.thekompany.com/products/kapital/

Do you really care to do a little research, before Ask:Slashdot?!

The main page of Christopher Browne's "Finances, Linux, and Stuff" is here!

Click to that little "2. Linux-based Financial Software" you can find what you need.

*grumble*

As I mentioned there, Christopher Browne's List is a good starting point. Note that a number of the multi-module accounting packages include POS modules.

Also mentioned were Samco, and Proven Choice Accounting.

As I mentioned there, Christopher Browne's List is a good starting point. Note that a number of the multi-module accounting packages include POS modules.

Also mentioned were Samco, and Proven Choice Accounting.

I'd focus on data storage first; without that, it really doesn't matter what kind of pretty GUI face you put on the front of it.

One of the "keys to success" on both PalmOS and Newton was that of having a whole lot of the system based on persistent data structures, e.g. where "everything is stored in a database." (Newton called this soups. )

Thus, when you're "juggling data," all you're juggling is a record here and there, rather than the traditional Unix "filesystem" approach where it's a whole file full of data being juggled, with attendant increases in risk of failure, in time consumed, and in storage required for "scratch space."

There is something arguably similar available on Linux; take a look at Casbah, which maps data in various forms onto a directory hierarchy.

Given a sound way of storing information, it then makes sense to proceed to provide useful abstractions for accessing that information; PalmOS has been successful foremost because they were open to developers wanting to use the system, from whence comes the hordes of useful and not so useful Palm apps.

It is not at all obvious to me that the up and coming would-be dethroners of PalmOS have taken seriously the task to get data storage right; most of the Linux-based systems seem pretty loose about this.

I would like to favor Linux-based PDAs, but based on what I see so far, I see little reason to consider an iPAQ running Linux over the alternative of upgrading to a TRGPro with 8MB of RAM.

I'd focus on data storage first; without that, it really doesn't matter what kind of pretty GUI face you put on the front of it.

One of the "keys to success" on both PalmOS and Newton was that of having a whole lot of the system based on persistent data structures, e.g. where "everything is stored in a database." (Newton called this soups. )

Thus, when you're "juggling data," all you're juggling is a record here and there, rather than the traditional Unix "filesystem" approach where it's a whole file full of data being juggled, with attendant increases in risk of failure, in time consumed, and in storage required for "scratch space."

There is something arguably similar available on Linux; take a look at Casbah, which maps data in various forms onto a directory hierarchy.

Given a sound way of storing information, it then makes sense to proceed to provide useful abstractions for accessing that information; PalmOS has been successful foremost because they were open to developers wanting to use the system, from whence comes the hordes of useful and not so useful Palm apps.

It is not at all obvious to me that the up and coming would-be dethroners of PalmOS have taken seriously the task to get data storage right; most of the Linux-based systems seem pretty loose about this.

I would like to favor Linux-based PDAs, but based on what I see so far, I see little reason to consider an iPAQ running Linux over the alternative of upgrading to a TRGPro with 8MB of RAM.

You won't accomplish "success" merely by breathing the air that ESR has belched, and the cost of arranging for a "celebrity" will far outweigh the value in most cases.

On the other hand, it is a good idea to pull in people with new and interesting ideas.

There are all sorts of interesting sorts of projects out there that it would be nice to discuss with one of those involved.

• People use XFree86; it would be interesting to hear about various aspects of it, whether about the technologies of the components, or about the way the project is organized vis-a-vis licensing, source code control, and "politics."

  It doesn't take Dirk Hoendel to discuss that; almost anybody on the team could have useful insights. Other members of the team might actually be on the same continent.

• My LUG's last guest speaker was the organizer of LiViD; he spoke on both the technologies involved, as well as the legal wranglings surrounding DeCSS. Most excellent.

If the goal is to learn something, then it most certainly is valuable to get speakers from remote places so that the local group doesn't get overly parochial or provincial.

A good comparison here is with academic institutions where they try to pull in guests for seminars and lectures. This helps "diversify the gene pool of ideas," where the alternatives can tend towards a sort of "academic inbreeding."

(Grumble... I need to put together a topic or three myself; the last time I presented anything locally was my Internet Filtering talk of 1997; I should probably put a couple of generic talks together that could allow me to candidate for this sort of thing... Have laptop, will travel...)

And just as the Classic Failed Project is the one that tries to develop a word processor to compete with Word, the widely useful thing that few have really seriously tried to do is to construct a "multiplexing data access tool" like MS Access.

Access may suck bad as a data repository, and MySQL and PostgreSQL may have it well-beat in that arena. But you can use Access with those DBMSes, thus obviating that demerit. What they don't offer, and nothing else does, either, is a tool that provides pretty/flexible ways of:

• Building queries using QBE (Query By Example);
• Screen Forms (not entirely unlike HTML Forms);
• Reports;
• The code that hides between Forms, Queries, and Reports...

And just as the Classic Failed Project is the one that tries to develop a word processor to compete with Word, the widely useful thing that few have really seriously tried to do is to construct a "multiplexing data access tool" like MS Access.

Access may suck bad as a data repository, and MySQL and PostgreSQL may have it well-beat in that arena. But you can use Access with those DBMSes, thus obviating that demerit. What they don't offer, and nothing else does, either, is a tool that provides pretty/flexible ways of:

• Building queries using QBE (Query By Example);
• Screen Forms (not entirely unlike HTML Forms);
• Reports;
• The code that hides between Forms, Queries, and Reports...

This has the demerit that it doesn't buy you a tax deduction, but it may have the corresponding merit of allowing the gift to remain a gift, and NOT be taxable in the recipient's hands.

The point here is that there is little net difference between:

• Giving developer a gift of $100, with no involvement of tax authorities after that, and
• Donating $140, which, after tax deductibility, costs you $100, and which, being taxable in the recipient's hands, nets them $100, or perhaps less!, and involves greater administrative costs...

See Free Software (Gift) Exchange Registry - FSEX for a likely-more-coherent presentation.

If you visit TPC.org , you will find that they don't have one benchmark, but rather about four, with substantially different purposes:

• TPC-C is intended to determine throughput of a transaction processing system in creating transactions;
• TPC-H measures performance on what is intended to be an "ad-hoc DSS environment."
• TPC-R measures performance on "business reporting," intended to be more like "typical DSS reports."
• TPC-W measures performance on a "web transaction" workload.

The notion that there can be a comparable benchmark between the databases is something of which people should disabuse themselves.

If you need to have high performance transactional behaviour, I would point out that ODBC is NOT the issue; regardless of whether the SQL-CLI drivers suck, the important point is that neither database fully supports the industry standard SQL/XA or X/Open DTP and XA standards.

Serious transaction systems commonly use transaction monitors like BEA Tuxedo or Encina, interfacing via XA to a relational database (like Oracle, Sybase, DB/2, Sleepycat DB, TimesTen, ...). From that perspective, MySQL and PostgreSQL are both still "toys," although SDTP - A Multilevel-Secure Distributed Transaction Processing System outlines how an XA interface to PostgreSQL was constructed in Common Lisp for use in a set of applications running on FreeBSD.

If you build a benchmark based on an application exercising the strengths of MySQL, it will probably perform badly when used with PostgreSQL, and vice-versa.

Take these systems seriously when they start supporting things like XA, and when BEA makes Tuxedo available for use with them.

The really cool thing is that this will "force" everyone else to improve their graphics cards, which means that in another year's time, by the time that XFree86 4.x drivers are available:

• There may actually be general availability of XFree86 4.x;
• There may be reasonably-well-tested accelerated GLX / DRI support in XFree86;
• There will be all sorts of other graphics cards with ludicrous amounts of RAM, relatively competitive with GeForce
• The "only somewhat ludicrously powerful" graphics cards with 32MB of RAM will be, at that point, "obsolete," and thus, dirt cheap.

The one thing I'd be concerned about, a year from now, is that you might be buying graphics cards with 256MB of RAM, which is more than the amount of "regular RAM."

(I can remember the "good 'ol days" when we upgraded an Alpha 4600 system to 256MB of RAM to help it to better support 40 online users with the ludicrously-wasteful SAP R/3 ERP system. I can now imagine someone putting that much RAM on a video card, for use by one user. Unbelievable...)

The Palm machines are designed around the exact opposite, namely being designed around a set of design compromises.

• There is a limited set of buttons (7 in all)
• There is a screen of limited size
• Limited resolution
• Limited set of colours
• Limited amount of memory
• Limited amount of CPU horsepower
• NO "secondary storage."

  Thus nothing resembling "disk," or "files."

This set of design constraints mean that rather than doing the "WinCE" thing of "trying to be Windows, with a somewhat smaller screen," PalmOS is completely different.

It encourages creating embedded applications that do fairly specific things, rather than creating "generic" applications like spreadsheets to do "generic" things.

While all of the above looks like criticism, particularly in light of the usual "GNU" thing of encouraging there to be no arbitrary limits, I would take the opposite tack. PalmOS has provided a case of relishing the limitations, and working with them rather than the approach of fighting against them.

The net result has been pretty successful. You can do a number of useful things with a Palm III, which make it worth having one.

I'm not sure that the Yopi has chosen its design compromises carefully enough to be able to be successful.

• If all it provides is a faster address/calendar book than PalmComputing, it loses.

  PalmComputing generally doesn't suffer from being too slow.

• If it needs a barrel of additional hardware, like keyboards and such, to be made useful, it loses.

  It needs to be useful without the extra stuff, unless it includes a keyboard by default.

• If the "cool part" is merely that it runs Linux, it loses.

  A few people will run it because of that, but I'm a Linux advocate and I wouldn't spend the money just because of that.

  At present, the iPAQ 3600 may run Linux, but does so only if you have a desktop "terminal" to connect to it. It may ultimately become "useful on the road," but it's not there yet.

I just don't think Yopi has yet come up with a suitable set of compromises in order to become amazingly functional.

If you want to use Sather-based applications on multiple distributions, then the tasks are twofold:

• Make sure that there are, ubiquitously-available, Sather RPMs or DEBs or whatever that will run on the various distributions.
• Make sure that the secondary libraries (stuff like a "libncurses-sather" or "libgtk-sather") has some well-thought-out location to be, that can be compatible across distributions, as well as suitable packaging.
• Make sure that there's actually someone still doing development work on Sather. (Last I heard, the sponsors at Berkley weren't working on it anymore.)

  Oops. That's three things.

If you want to start deploying "killer apps" written in OCAML (and there are some interesting OCAML apps! ), the requirements will parallel what the "LDPS" provides, albeit by changing "C" to "OCAML."

Feel free to write the OCAML Development Platform Specification. No one will stop you, and if it's good, and is worth doing some rework of packages for, this may be a very good thing.

• WIMP - Windowed Interface with Mouse Pointer

  This "model" has become fairly much dominant, and continues to undergo various forms of "tweaking," lately with everyone going gonzo over Themes.

  Unfortunately, major changes require either nuking the whole thing and starting from scratch, which is a lot of work, or else making systems of more and more byzantine complexity to operate.

  The latter is where adding additional "stuff-to-click" takes us. Every added toolbar results in another "hieroglyphic" language, moving us towards ancient Egyptian rather than anything modern. (The McLuhan "Laws of Media" strike again...)

• MVC - Model/View/Controller

  The more "intelligent" sorts of changes don't necessarily involve increasing the visible complexity, but rather trying to split systems more clearly into this paradigm of designing, somewhat separately, an underlying model, a set of controller functions to control the object, and then some form of "front end," or "view."

  It's hardly new; Smalltalk and NeXTStep promoted the MVC "view of the world" umpteen years ago, and the problem really is that the ad-hoc GUI construction systems have so often conflated M, V, and C together that many GUI applications wind up as jumbled sets of functionality.

  It may be that introducing things like Glade User Interface Builder along with libglade , to encourage keeping "controller" stuff in once place, GNOME-print, Gnome Canvas, DPS for XFree86, and Display Ghostscript, ReportLab, providing "view" tools, and CORBA, providing separation of "model," may provide a direction to clearly separate these functions so that GUIs will be less confused.

None of this represents dramatic, overnight change, and I'm not sure that that's a bad thing.

But for $550, just for the mobo/cpu, I suspect it'll see few takers outside of people that need test beds for developing embedded systems.

Actually, I seem to recall seeing this site referenced, probably on Slashdot, a few months ago as a "source of StrongARM motherboards." Based on RCS logs, I've had a link at My Linux VAR page since January 14, 2000, which probably means that this purported "news" is actually "olds," likely mentioned at Slashdot in early-to-mid-January. I noticed then that the pricing was "a bit frightening."

Things people should be trying out include:

• VSTa
• Hurd
• MIT Exokernel
• SpinOS
• OSKit
• EROS
• Some variation on Wirth's Oberon systems

Even if you look at these, and go back to a UNIX-like system, there is benefit to seeing the extra abstractions they offer.

I'm not resisting "non-UNIX" things for the sake of them not being UNIX. Your conclusion that I am promoting "doctrinaire orthodoxy" comes from only half-reading the signature.

The point of the signature is that if you don't know the "orthodox," you are unlikely to do anything better than to merely replicate many of its features, badly.

It is also pretty fair to say that:

Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. -- Philip Greenspun

I think there should be a richer set of systems software research going on; people should be trying out EROS. People should be trying out And Hurd.

There should be work going on to provide OS environments supporting:

• Persistent data structures
• Garbage collected operating environments
• Filesystems with semantics going beyond the UNIX "bags of bytes."
• Security management using capabilities

Some of them will surely fail, and that's OK. Some of them may succeed, and that's a good thing.

One of the steps to allow people to actually learn from getting into system designs is to actually understand the systems that have come before.

In that light, it is not doctrinaire orthodoxy to consider that...

Unfortunately, notable ones like ML and Haskell head very quickly into the arcania of type theory, which may be a bit more math than you want to push at youngsters that are still working on getting used to the notion of abstract ideas.

In contrast, the arcaneness of "pointer twiddling" in the C descendants is rather nasty.

Contrast with the arcania of "program structure" in Pascal, where a single semicolon out of place causes great contortions...

Lisp-like systems have irritating quantities of parentheses. (At least, for the first month that you use Lisp...)

Which all goes to say that all the languages out there have some strengths and some weaknesses.

Unfortunately, notable ones like ML and Haskell head very quickly into the arcania of type theory, which may be a bit more math than you want to push at youngsters that are still working on getting used to the notion of abstract ideas.

In contrast, the arcaneness of "pointer twiddling" in the C descendants is rather nasty.

Contrast with the arcania of "program structure" in Pascal, where a single semicolon out of place causes great contortions...

Lisp-like systems have irritating quantities of parentheses. (At least, for the first month that you use Lisp...)

Which all goes to say that all the languages out there have some strengths and some weaknesses.

• Pricing.

  It is notoriously difficult to get pricing information for QNX.

  I have heard differing reports on comp.os.qnx, including that it is "very expensive, hundreds of dollars per system," or, on the other hand, the vague answer of "you can license it reasonably economically." (With no definition of what "reasonably economical" means, of course.)

• If people should start thinking of QNX, then they should also start thinking of:
  • VSTa

    A copylefted system that "lifts" ideas from QNX and Plan 9

    It looks like development has not been terribly active lately.

  • MIT Exokernel

    Again, not terribly active, but an interesting OS kernel.

  • EROS

    Eric Raymond thinks it's mindblowing, so the Eric Raymond Personality Cult should all be preparing to drop Linux in favor of EROS. (Of course, it isn't yet capable of self-hosting, which indicates that it's not all that useful at this point. But, to cultists, usefulness is irrelevant...)

  • Possibly even Hurd

    It's different from the other options; certainly not a tiny OS option...

  • eCos
  • RTEMS

    Which, like QNX, appears to be used in some reasonably critical system environments...

  • Fiasco

    Which is a "lighter microkernel than Mach"...

  • On Linux, people interested in QNX should almost certainly look at SRR -- QNX API compatible message passing for Linux

    This is the critical programming abstraction that QNX uses heavily which isn't all that widely used on traditional UNIXes, namely asynchronous messaging.

  These are all interesting alternatives, albeit not all being of identical levels of interest.

• I'm sure that Linus has a bunch of stock options, but. Stock option plans tend to have some stipulations.
  • They tend to vest over time.

    Thus, if Linus has options to $20M of shares, it is fairly likely that he only has part of that now, and that leaving now would cost him big.

  • Those options that aren't vested are lost if he leaves.
  • At this point, Transmeta stock isn't publicly traded.

    Repeat after me: Not Publicly Traded.

    I've gotten phone calls from people (morons!) who want to buy Transmeta stock who thought that my Speculations About Transmeta indicated that I actually owned shares.

    Despite the "excitement," there is no public market in the stock. Any stock that has vested in Linus Torvalds' hands doesn't have a market in which to sell it.

    The theory that the stock is somehow "worth something" is only made true when there is actually a public market in Transmeta stock. Maybe that will happen next year; I suspect it won't be this year.

• For those that didn't know, Linus Torvalds is Finnish. He is not an American citizen. And so, his employment at Transmeta is at the "sufferance" of the INS, under an H1B visa.

  There was a Slashdot story on this; see Workers - Including Linus - Left in Limbo by INS

  If Linus walks away from Transmeta, he will very likely not wind up employed by a US company, as he would be asked, fairly shortly, to return to Finland.

• As for why Transmeta hired him, I would tend to think that they wanted something more than just a marketing figurehead.

  Suggesting that he's a worthless figurehead is decidedly "flameworthy;" I don't have to be part of the Linus Personality Cult to find that distasteful.

Long and short is that there are a number of reasons why Linus is not likely to leave Transmeta tomorrow.

However, I certainly agree that the tendancy for students to try to get "the Internet" to do their research for them is extremely annoying.

• The newsgroup comp.lang.lisp tends to get hit hard by this; there's an almost-weekly attempt for students to get answers to what are obviously homework assignments that they have put off.
• I get a few emails a month that show that students are trying to satisfy research requirements by reading my web page on relational databases, and then figure that I am the obvious "consulting resource" to answer their assignments for them.
• There was one entertaining occasion when a considerable chunk of a class of accounting students asked my opinion on what Linux-based software package Corel should adopt, and why.

I learned my research skills, which have mapped not too badly onto new media such as the web, by virtue of spending many hours in university libraries tenaciously searching for books and papers and references between them.

If I use "my powers of research" to help the new students too very much, they won't bother learning those sorts of skills, and the next time media changes, they may not develop the tenaciousness to be able to fight their way through to grasping the next new thing.

I'm happy to suggest some references, particularly those that are a little unusual so as to promote a wider array of insights. Thus, Marshall and Eric McLuhan's "Laws of Media" represent a probably-unexpected useful way of grappling with analyzing effects of changing technology, and I'm happy to cite that as an approach.

But to write peoples' research reports for them is quite another thing. It is not merely immoral for them, as students.

It is also immoral for those that do the writing, as they discourage students from becoming competent researchers. And in an increasingly information-oriented economy, that is a horrible way to handicap them.

• They tend to be extremely proprietary.

  You can't just buy into the 4GL; you have to buy into the database on the back end, and whatever "TUI" or "GUI" is on the front end.

  In the case of tightly integrated options, which buy you decent performance, such as Oracle's tools, this means "marrying" Oracle. (And no "With this ring I thee wed," and no "You may kiss the bride." There does, however, tend to be a rather one-way form of "wedding night"...)

  Alternatively, SAP R/3 provides a DB-independent and OS-independent option, but is a rather heavyweight system.

• When the Development Model Du Jour changes, the 4GL becomes obsolete.

  Text-based systems were obsoleted by GUIed ones, and both have tended to be obsoleted by "web app" ones.

  In order for the 4GL to buy "ease of use," it has to provide a very specific development approach, and that results in it being very "brittle" in a changing environment.

• Incomplete Results

  The "benefit" of a 4GL is that it makes certain things (perhaps creating certain forms of reports) very easy.

  Unfortunately, this may only extend to covering 60% of system requirements. Which is wonderful when prototyping, when you only need to fulful 40% of system requirements. But it is not so wonderful when you're fighting to get the rest of the way, and have to fight with a tool that just wasn't meant to add in whatever that last 10% is.

  I worked with a group that was building a GIS system atop PowerBuilder; they got about 1/2 done, and then had to discard it and recreate the whole application using MFC/C++ because they just couldn't push PowerBuilder far enough.

I think the most important thing to realize is that no single thing defines what makes Unix be Unix instead of Just Another Operating System. Sure, there is POSIX, but POSIX doesn't cover everything. Sure, there are the "standard" Unix shell tools, but those can be ported. You can't nail Unix down in any easy definition. Yet, Unix inevitably feels like The Right Thing to those who know it. If you like cliches, Unix reminds me of the old line "I don't know art, but I know what I like."

That being said, I'd like to touch upon a few things that make Unix what it is:

The design of Unix is driven by synthesis. You don't create a specific tool to solve a particular problem; you break it down into smaller, general problems and write general tools to solve them. You then combine those tools to solve the original problem -- but you can continue using them afterwards.

This leads us to The Unix Philosophy. Anything you call "Unix" or "Unix-like" will adhere to it. However, the Unix philosophy is a set of design goals, not a system definition. Something can follow those goals without being Unix. So that doesn't cover everything.

Let's start with the filesystem. As others have said, a key element of Unix is the single filesystem. Unix must have a root filesystem mounted at /, and cannot function without it. It is more then not being able to do anything useful without the programs in the root; it is the fact that the Unix filesystem is a large part of the Unix API.

Additional filesystems are spliced into this single presentation, not mounted as separate trees. System hardware is abstracted and presented using file system entries. These are things that cannot be done if your OS doesn't support them. Then you have the organization of the files in the Unix filesystem. Programs in /bin, configuration data in /etc, devices in /dev, temporary files in /tmp, "user files" in /usr. None of these are mandated by the kernel or the utilities, but they are definitely old friends to a Unix hacker like me.

Unix processes also behave in a certain way. Process spawn overhead is low and context switching is fast. Signals and exit codes are used for IPC. fork() and exec() are separate system calls.

Unix treats text as data and data as text. Configuration files are generally human-readable. You can "cat" a binary file without the OS doing end-of-line manipulations. Any particular meaning of a character (^D for EOF, e.g.) comes from the terminal driver, not the I/O mechanism.

Lastly, Unix was implemented in C, and C was designed to implement Unix. Contrast this with other OSes, where the language you're programming in and the system library are generally completely separate things. This synthesis (to borrow from the Mazda ad campaign) "just feels right".

While I'm on the subject, I'd like to address two things that Unix explicitly isn't:

Unix is not a trademark. I'm sure The Open Group doesn't agree with me, but Unix was around before they were, and will continue to be around long after they are gone. They control who can legally put "UNIX" on their product, but that is a matter of layers and money, of which Unix cares about neither.

Unix is not a particular source implementation. There are very Unix-ish things which have not one line of AT&T or BSD code in them, and there are things totally not Unix which contain BSD code. MS-Windows is one of them.

I forget who said it, but if you're looking for one line answers, then this fits best:

"Unix isn't so much an operating system as it is a painstakingly compiled oral history of the hacker culture."

It runs up against several problems:

• According to Multicians, an important aspect to Multics was the use of PL/I as the programming language.

  There's not a "free" PL/I compiler.

  Probably the nearest alternative would be to implement using the nearest thing to MacLisp, namely Common Lisp. But down that road lies the rather different path of creating a Lisp OS.

• Another crucial aspect was the hardware support for memory management and rings.

  Apparently Intel designed some Multics-like capabilities into some (not all!) members of the IA-32 series.

• One alternative is to create a hardware emulator that emulates the Honeywell hardware. That would allow using existing Multics software, rather than merely involving creating analagous software.

  Unfortunately, that means having to get access to the Multics software base, which is not likely terribly available these days.

  The only system known to still be in production use is at DND: Maritime Command in Halifax, Nova Scotia, and its decommissioning is planned this year. Remember, military system. They're not likely to be willing to give out copies, independent of any rights Honeywell, Bull, and others may have...

• Another option would be to create a "Multics shell" to parallel Ksh, Zsh, ... and create a vaguely Multics-like environment atop Linux.

  Of course, that doesn't get you segment/ring control, which hurts the emulation.

• I've had Organick's book on Multics on order from Spamazon for a couple years, and have heard nothing. Some documentation may be hard to come by.

• Determining a criterion for "Multicsness."

  Does it have to run the same software? Does it have to use PL/I? Can it be upgraded with other modern notions?

• Getting suitable data to specify the system.

• Look at the Font De-uglification HOWTO
  FDU-Mini HOWTO
• Install some True Type fonts from ...... Microsoft!
  They have a fontpack
• 
  which provides some nice stuff like Arial Black etc...and then install one of the TT font servers:
• One of the most popular is xfsft
• Another available for download is xfstt
• Use RH6.1 which has xfs prepatched with xfsft for TT fonts
• If it's just the sizes that bother you, that's a pretty oldish problem which is fixed by switching the order of the 100dpi and 75dpi fonts in your font catalogue
  There's a note about it from as far back as NS2 at bigfontsthat might help
• Finally Christopher Browne has really helpful web-pages with this topic indexed (among many others) at cbbrowne

I don't think it is possible to overestimate the importance of the issue of data formats, at least not in the context of looking at word processors. If you want your document to be usable five years from now, it is ludicrously unacceptable to use whatever "document embedding" scheme MSFT uses this year.

The format has several notable effects:

• If it is "text-based," this may mean that you can email documents without worrying about special encodings.

  Note that the spreadsheet XESS promotes this as a "selling feature."

  (Others may say, uuencode is your friend. )

• If it is text-based, this means that you may be able to modify the document using other tools than the word processor.

  That's useful for debugging, solving problems, modifying the document when you move it over to a laptop that doesn't have the word processor installed and have to use vi.

• If the format is based on some normative standard, this means that you can expect to be able to create documents using external tools.

  For instance, if the program uses an XML-based format, it becomes reasonable to write a Perl, Python, or Scheme.

  Example-of-the-week: I've been working on generating spreadsheet files for use with Gnumeric. The plan is to write Scheme scripts that pull data out of GnuCash, and generate reports. I haven't gotten to the "extraction" part, but have generated some pretty slick demo spreadsheets.

  Someone in a law (or para-law) office might want to create a document template scheme where they run a K001 GUIed program that asks for names and sundry fields, and then generates legal documents. Given a sufficiently "open" format, that's pretty practical.

Using formats where there's at least some visible ASCII text seems to me to be the only reasonable way to go. I'll remain a bit skeptical of XML; just 'cause it's buzzword-compliant doesn't mean that the DTD will be in use in the long term...

I don't think it is possible to overestimate the importance of the issue of data formats, at least not in the context of looking at word processors. If you want your document to be usable five years from now, it is ludicrously unacceptable to use whatever "document embedding" scheme MSFT uses this year.

The format has several notable effects:

• If it is "text-based," this may mean that you can email documents without worrying about special encodings.

  Note that the spreadsheet XESS promotes this as a "selling feature."

  (Others may say, uuencode is your friend. )

• If it is text-based, this means that you may be able to modify the document using other tools than the word processor.

  That's useful for debugging, solving problems, modifying the document when you move it over to a laptop that doesn't have the word processor installed and have to use vi.

• If the format is based on some normative standard, this means that you can expect to be able to create documents using external tools.

  For instance, if the program uses an XML-based format, it becomes reasonable to write a Perl, Python, or Scheme.

  Example-of-the-week: I've been working on generating spreadsheet files for use with Gnumeric. The plan is to write Scheme scripts that pull data out of GnuCash, and generate reports. I haven't gotten to the "extraction" part, but have generated some pretty slick demo spreadsheets.

  Someone in a law (or para-law) office might want to create a document template scheme where they run a K001 GUIed program that asks for names and sundry fields, and then generates legal documents. Given a sufficiently "open" format, that's pretty practical.

Using formats where there's at least some visible ASCII text seems to me to be the only reasonable way to go. I'll remain a bit skeptical of XML; just 'cause it's buzzword-compliant doesn't mean that the DTD will be in use in the long term...

Note that there is an Objective C binding for GTK...

That's easy enough to implement, when all it involves is taking a dozen 8"x8" piece of plastic and placing them in well-defined magazine rack locations.

What people clearly don't understand is that Attempts to prevent the use of packet-switched communications networks such as the Internet to transmit information that could possibly offend are technically doomed to failure, because it's all just packets.

The best that has been done thus far is that the seriously offensive stuff sits behind barriers that require a credit card validation to open up.

Your suggestion of determining what sites fall under a "general obscenity law" doesn't work, as the general result of such laws is not simply to "filter" such things, but rather to establish that the police ought to go over and outright close the site down.

What you're looking for is some sort of "in between;" stuff that is permitted "viewing" for adults, but forbidden for children. And that is decidedly not something that is well-defined.

One of the more interesting situations I have been in was a "debate" over this; a district attorney with experience in the matter in the Ontario jurisdiction discussed censorship in the context of a church youth group.

There were a surprising variety of opinions on the matter, and what was more surprising still was that even in the context of a group that you might expect to focus on it blindly (and there were a few people like that), it was quite clear that there could be no clear legislation to agree on.

Consider some examples of situations with varying levels of permissiveness/ambiguity:

• You and I might agree that "extreme"/"hard core" publications like Hustler or Penthouse "leap over the line," and have often gotten censored and censured as a result of running afoul of obscenity laws.
• Playboy and other clearly "soft core" publications may be "clearly" inappropriate for youngsters, but considering them to be obscenity is far less clear.
• What of things that are merely "suggestive," such as swimsuit catalogues, the Victoria's Secret catalogue, Sports Illustrated Swimsuit edition and such?
• What of the "nearly naked Africans" that appear in National Geographic?
• What treatment should a medical anatomy text get?

  Does it differ if purchased by a doctor, or by a hormonally-challenged teenager?

  What if the teenager, despite hormonal challenges, truly is planning to study medicine?

• What about an issue of a medical journal, Deviant Psychology, specifically dealing with the treatment of individuals with addictions to dramatically obscene materials, that has to excerpt from such in order to help doctors treat patients?
• What about a documentary about pornography? There have been controversies over the documentary Not A Love Story.

Can you comment on possibilities for developments relating to transaction processing and database management systems?

"For instances" to make this clearer include:

• RHAT has apparently been putting work into the availability of raw partitions that the major DBMS vendors prefer to the use of native filesystems.

  Ala SCT-RAW , raw i/o patches

• TP monitors such as BEA Tuxedo as well as message queueing systems such as IBM MQSeries.

  There's one "libre" option, Isect

Good overview: http://www.hex.net/~cbbrowne/finances.ht ml, where CBB, Xfinans, etc are described.

At http://www.lrz-muenchen.de/~phm/banks hen.html the situation in Germany is described. Using my easily-customizable Perl software package TOAD one can generate money transfer instructions in a format called DTAUS that many German banks accept. My local Munich Sparkasse accepts DTAUS files either via T-Online or via diskettes. It talks about the "programmable bank account" also.

The QIF - Quicken Interchange Format - is described at http://www.hex.net/~cbbrowne/finan ceformats.html.

I have notes about IFX and OFX as upcoming standards for online transactions, but no references right now.

The unofficial"quicken page sounds useful.

-Neal

--Neal

Good overview: http://www.hex.net/~cbbrowne/finances.ht ml, where CBB, Xfinans, etc are described.

At http://www.lrz-muenchen.de/~phm/banks hen.html the situation in Germany is described. Using my easily-customizable Perl software package TOAD one can generate money transfer instructions in a format called DTAUS that many German banks accept. My local Munich Sparkasse accepts DTAUS files either via T-Online or via diskettes. It talks about the "programmable bank account" also.

The QIF - Quicken Interchange Format - is described at http://www.hex.net/~cbbrowne/finan ceformats.html.

I have notes about IFX and OFX as upcoming standards for online transactions, but no references right now.

The unofficial"quicken page sounds useful.

-Neal

--Neal

I agree that it would be nice to have the various new FSes; I don't think Reiserfs will be quite ready, and it looks likewise for ext3, more be the pity. As for Procfs, if it's not there already, I have a hard time believing it'll get there soon. And you forgot NFS3, no?

As for ACLs, I don't think the rest of the world is ready for them. They're practically useless without fairly sweeping changes to things like:

• LIBC
• GNU Fileutils
• RPM, dpkg
• Anything else that might need to be aware of them.

I somewhat favor a rather different ACL model based on TOPS-10 FILDAE; 'tis unclear that we've got a clear model of how to configure security with ACLs, and it doesn't make sense to push it into the kernel until there are some clear ideas on how to implement the user-space ACL management.

I don't personally know this guy, but this guy shows up everywhere (usenet, mailing-lists, even slashdot), and he always has something insightful to say. He's so eloquent, too.

I'm surprised he hasn't been mentioned yet. Next to Ballard, I'd go with cbbrowne.

According to the company history:

Prolog Development Center (PDC) was founded in 1984 with the development of a Prolog compiler - later to be known as Turbo Prolog, PDC Prolog and now Visual Prolog as its main activity. Since then PDC has established itself as a world leader in the development of Prolog and related products.

Today, PDC consists of an R&D and a consultancy division. The R&D Division is concerned with the development of the Visual Prolog compiler together with new methodologies and development tools.

Borland might be an evidence against the common contention that "Microsoft is the company that never produces anything, but merely buys out products from other companies that are creative," as many of Borland's products were not natively produced, but rather resold on behalf of other componies.

By the way, that was Ashton Tate that used to own the dBase trademark...

As for integration with DBM variants, I see little importance to that. InterBase is a relational database (or at least, as relational as they come), as opposed to merely being a data store. The value would be in sharing code between InterBase and PostgreSQL or MySQL, or maybe using InterBase as a "data store" for persistent data in KDE or GNOME.

According to the company history:

Prolog Development Center (PDC) was founded in 1984 with the development of a Prolog compiler - later to be known as Turbo Prolog, PDC Prolog and now Visual Prolog as its main activity. Since then PDC has established itself as a world leader in the development of Prolog and related products.

Today, PDC consists of an R&D and a consultancy division. The R&D Division is concerned with the development of the Visual Prolog compiler together with new methodologies and development tools.

Borland might be an evidence against the common contention that "Microsoft is the company that never produces anything, but merely buys out products from other companies that are creative," as many of Borland's products were not natively produced, but rather resold on behalf of other componies.

By the way, that was Ashton Tate that used to own the dBase trademark...

As for integration with DBM variants, I see little importance to that. InterBase is a relational database (or at least, as relational as they come), as opposed to merely being a data store. The value would be in sharing code between InterBase and PostgreSQL or MySQL, or maybe using InterBase as a "data store" for persistent data in KDE or GNOME.

What did you expect? Hurd was intended as a free UNIX clone, just like linux. It is just a kernel, there shouldn't be any differences above the kernel in the user space.

If there are no differences above kernel level, then there is little point to bothering with Hurd. Might as well just improve Linux a bit.

The point is twofold:

• Many things about Hurd will be much the same as Linux. It has GLIBC, and anything that runs atop GLIBC on Linux should, by and large run on Hurd.

  Things may not be there yet, but that's certainly the intent.

  The result of this is much as you suggest, that there don't have to be a lot of differences visible in user space. Applications that run on Linux should also be able to run on Hurd.

• On the other hand, Hurd uses a microkernel, has some kernel structures that are different from Linux, and allows building things that are hard/impossible on Linux.

  The notion of filesystem translators, for instance, is something that Linux doesn't do.

  As time goes by, if there is any merit to Hurd, the use of Hurd facilities such as translators should result in systems based on Hurd diverging from the way Linux looks.

Conclusion: Both Linux and Hurd offer many things that are similar, such as:

• Multiple users
• Multiple tasks
• Hierarchical filesystems
• GLIBC
• ...

The similarities at present comes from trying to get the stuff that works on Linux to work on Hurd.

Eventually, if Hurd "goes well," the differences will emerge...

Better still would be to use the Bible as the text onto which messages would be layered.

• The Bible is a fairly long document, with lots of semi-repeated substrings, thus providing a lot of useful material for building a dictionary of substrings.
• The material that you would get out of this would look more like a rambling Bible study than anything else.

  The "Bad Guys" might think you're a religious crank; raving a bit, but harmless.

• The Bible actually is a tremendously subsersive book. Many totalitarian regimes have considered it highly dangerous.
• The Bible is widely available, and quoting bits of it, or things that look like bits of it, isn't particularly unusual.

This kind of amounts to a reverse form of Bible Codes analysis... There are cranks out there that think that God put special "codes" into the Bible that they can analyze; using the Bible in this way produces documents that are "Biblical" that actually do contain special codes.

• SGI needs to actually get revenue streams from selling Linux-oriented hardware, or from selling training programs. On the training side, they seem to truly be putting in some real effort; the hardware side is far less clear.
• It would be a cool idea to have cheap MIPS-based Linux boxes; I'd love to see a Linux for Nintendo 64 much like the IX "April Fools" article of 1997.

  Unfortunately, this isn't a substantial profit centre for SGI, as they probably only make a few bucks per farmed-out MIPS CPU. To turn this into significant help, there need to be millions of CPUs being sold for this purpose, and I just don't see that happening.

• What to do about Cray?

  This looked like a useful synergy; Cray didn't have the quantity of sales to allow development of all the hardware they needed, and if SGI could use some of it in other product lines, that could make the costs more readily amortized, and even improve performance on SGI's "own" product lines.

  I suspect Cray holds a bunch of critical patents on computer hardware for HPC; killer question is who's going to want to buy, when SGI couldn't make the synergies work...

• NVidia looks a whole lot more like an organ donation than anything else; there's only just so much money SGI can get out of the deal, and if it makes NVidia hardware more competitive with SGI hardware, this can diminish the deployment of SGI's hardware. Looks dangerous to me.

EGCS compatibility is somewhat different; it represents some examples of cases where Linux was not conforming to the official standards of how C is supposed to work. (Largely regarding treatment of pointer aliasing, I believe...) Linux has arguably been made buggy in doing things that C isn't supposed to support, but which GCC used to.

Conformance to standards isn't a "feature" in the way many kernel facilities are...

Consider that I didn't mention GGI as an example; it is an example of something that was initially rejected, and quite legitimately so, as the proposed implementation was not, three years ago, developed, debugged, and perfected. Interestingly, the recent framebuffer support is now the GGI support; they don't need to integrate big gobs of stuff as they have the crucial interface that they do need, with the benefit that it has made supporting some of the more obscure systems ( e.g. - Atari ST and such) easier.

EGCS compatibility is somewhat different; it represents some examples of cases where Linux was not conforming to the official standards of how C is supposed to work. (Largely regarding treatment of pointer aliasing, I believe...) Linux has arguably been made buggy in doing things that C isn't supposed to support, but which GCC used to.

Conformance to standards isn't a "feature" in the way many kernel facilities are...

Consider that I didn't mention GGI as an example; it is an example of something that was initially rejected, and quite legitimately so, as the proposed implementation was not, three years ago, developed, debugged, and perfected. Interestingly, the recent framebuffer support is now the GGI support; they don't need to integrate big gobs of stuff as they have the crucial interface that they do need, with the benefit that it has made supporting some of the more obscure systems ( e.g. - Atari ST and such) easier.

The question is not simply of whether the "delay is acceptable;" it is of whether any delay is acceptable.

Consider the situation of running a Telnet session. You press a key, and expect the system to respond to you, updating the screen every time you press a key.

That is a case where there is a need for something rather like streaming; in effect, the communications stream needs to be able to respond to each key press, and transmit them immediately. Not only is your "two minute" delay unacceptable, I would (and sometimes do ) find a 0.5s delay to be unacceptable. If I'm running Emacs or vi across an encrypted Telnet session, I am absolutely NOT going to find it acceptable for the system to collect up two minutes worth of updates, and handle 'em all at once. (If I was running TECO, where updates are queued 'til I hit ESC, or a mainframe editor where updates are queued until I press [ENTER], that may be a different story...)

That being said, it is fairly usual for network-based transmissions to mandate block-oriented schemes, as the transmission medium is not a "stream," but rather a set of "packets" that map nicely onto "blocks."

• New this fall is Sun's MAJC
• Patriot shBoom (a 1996 relabelling of Chuck Moore's 32 bit FORTH chip)
• IBM's Java Chip - 1997 - apparently some extra logic hung off a PPC logic set
• Sun Scrapped their initial Java Chip
• UC Berkeley students designed one for a CS course
• Rockwell had one...

None of these have really gone anywhere in terms of influencing Java deployment.

The only way they would have been important is if:

• Network Computers had taken off, but they didn't.
• Java was getting deployed heavily in embedded systems. That factor is not evident.

You may not see any of this on UNIX systems where the "problem date" is in 2038; that does not diminish that there are huge quantities of "bespoke" applications, custom software written for this department or that within companies, where the code has stayed running far longer than it was designed for.

Linux may not have much of a ``Y2K problem;'' there are a whole lot of database-oriented and COBOL-oriented applications that do, or (hopefully by this point) did.

You may not see any of this on UNIX systems where the "problem date" is in 2038; that does not diminish that there are huge quantities of "bespoke" applications, custom software written for this department or that within companies, where the code has stayed running far longer than it was designed for.

Linux may not have much of a ``Y2K problem;'' there are a whole lot of database-oriented and COBOL-oriented applications that do, or (hopefully by this point) did.

There may be some problems in third world nations where they may have gotten some old System 34/36 systems shipped in, that will burn up on Jan 1st, but if they're just barely automated, stepping back to non-computerized methods isn't liable to be that much of a problem.

I am a bit less worried about the "people" problem.

• There have been fewer religious "millennial paranoia" movements than I expected (and I was anticipating there to be some. ). Yes, there are crackpots. But they've been remarkably quiet.
• The serious crackpots are going to all load up with guns, and head to a deserted spot in Montana.

  Ed Yourdon says so :-).

  Supposing thousands of crazed lunatics head, heavily armed, to Montana next month. What's likely to happen? They're liable to accidentally shoot each other. This might make next year's Darwin Awards as one of the dumbest things of 1999.

• I agree with Yourdon's assessment that New York City is liable to be a bad place to be on New Year's Eve; if you put vast numbers of partiers wanting to hold "the blowout of the millennium" in one spot, problems are a given.

While the diminishing of confidence that would result from a "serious bad occurrance" would not be particularly good, this would have the merit of encouraging people to look past your "false pretences."

A LinuxOne gone bad situation, where, in looking at the documentation, their business case is half-baked, is not going to seriously undermine the ability of Corel to keep trading on NASDAQ and the TSE. After all, they do have a big gold building on Carling Avenue, unlike LinuxOne.

The thing that is really peculiar about the LinuxOne IPO, and it is the thing that is likely to hurt them most, is the consideration that they haven't been able to get an underwriter of any sort, and particularly not a credible one. They're selling stock directly, and the comparison could be drawn that you can go out back to the truck in the parking lot and buy some stock. This has more parallels to the guy in a van driving down Bronson Avenue that says, We've got some extra car speakers. You want some? than it does to a sale through Goldman Sachs & Co.

So no, I'm not terribly worried about this; anyone with a little skepticism about finances will take this IPO with at least some of the "grains of salt" that it deserves...