While mySQL does have a lot going for it, the dearth of some basic functionalities continues to make me nuts – which is why I use other databases (notably Postgres) when I’m able.

When building Web sites, however, mySQL is a necessity, as it’s the only DB you can really get hosted on Linux sites.

But…augh!!! Today’s issue: Defaults and dates.

On just about all databases I’ve worked with, you can set defaults on date fields (even Access, fer christ’s sake!). For example, let’s use this Postgres table:

Note how the date_added and date_modified fields default to now(): So, upon profile creation, each is automagically set to the time of creation. Date_deleted, of course, is nulled out – will be filled out when necessary.

But you can’t do this in mySQL – you can only default date fields if you use the timestamp data type. This has the following effects:

• Most (all?) tools – including the command line – display timestamp without formatting (20031230161304) and datestamp formatted (2003-12-30 16:13:04). Why two different views of essentially the same data?
• The first timestamp column will behave differently from second and subsequent timestamp columns in a given table. Timestamp is designed to essentially give a date modified time stamp – any insert or updates to row will increment the timestamp but only if it’s the first timestamp column. That’s wacky.

RE: The second point. Assume the following table (note the two timestamp columns):

If I insert into this table – say, add only name and d1 (datetime type; use now() function) values – here is what we will see:

So, the first timestamp column defaults to current time; the second one just sits there. Ditto for updates. And god forbid if I just reorganize my columns – but keep the same names and types – suddenly, another column may begin timestamping instead of the other. Grrr…

And this second timestamp field defaults to 00000000000, not NULL.

Ungood.

Another example of why I bash mySQL.

Deep breath.

I’m currently in the midst of reading Eric S. Raymond’s The Art of Unix Programming.

Highly recommended.

The book is not a Unix programming book, and it’s not a philosphy book.

It’s both…and neither.

Good read; Joel Spolsky has an excellent and insightful review of this book, so I won’t clog up the Blogsphere with my own idiotic ramblings and ruminations (wait! why should today be different?).

It’s an interest book for what it says about Unix history, the art of programming – in general – and the art of programming in Unix, specifically.

As I’m not a seasoned Unix hacker, it was good to read some of the tenents Raymond puts forth (he did not invent them; he’s just documenting them).

One of the more interesting ones – to me – was the concept that a routine/function or whatever should succeed silently. This is the opposite of what most users would expect – users want confirmation.

Programmers want silence, lack of clutter – only display when something goes wrong.

Which made me feel a little better (and smarter): I had just written a bunch of PHP functions and my decision was to return FALSE unless there was an error (then an error message will return). In this way, the program just keeps chugging along if all is well without any success echoes.

This is better for the program, but somewhat counter-intuitive: Return FALSE for a SUCCESS?

This book says that’s a good thing.

Wow. I got something right.

I’m not one for New Years’ resolutions or stuff like that, but the end of the year is a good marker to start to look at things and go either, “Hmmm….this should have been…” or “Hmm…maybe next year….”

And so on.

Why I’m doing this:

• To a large extent, just for the hell of it: While there are limitations to what I have now (see below), there are a lot of options out there – low- and no-cost – that I could select if I were really desperate for change. But I’d rather trying rolling my own so I can learn something and customize it in every way.
• To make the blog dynamic: Right now I’m using Blogger, which has been great because it’s free. It’s been a drag, however, because Blogger owns the database (I’m not really complaining; it’s free, recall), so a lot of the stuff I’d like to do I can’t. I.e., the site could be more dynamic, but – because I can’t get to the database, I’m pretty limited in my tweaks (I’ve done a bunch of tweaks already, however).
• To add features: While blogging tools offer options – take MT (Moveable Type) for an example – the integration is not complete and, well, true unless it’s one codebase. I’ve build MT modules (locally), such as a blogroll tool. Works great. But the integration is not fluid – if I update MT, for example, I have to re-hack the MT code to install my modules etc.

That’s the short list; the long list is – as expected – longer. But I won’t bore any hapless readers.

However, one of the interesting decisions to make up front is the following – Where does the Blog’s logic reside. For example:

• Build blog and components locally and push HTML only to the public site (examples: Tim Bray’s Ongoing (emacs & scripts) or the Scobleizer Weblog (Radio). Note the lack of search.
• Have the database reside on the public site (examples: Pick any MT site). Usually a mySQL database on the Web server, not local.
• Have the database reside on the local site but replicate to the public site. I’m not sure of examples here, but – for example – it’d be possible to have a complete site local but replicate all/some of the local database to the public site for dynamic use there.
• What degree of dynamic is desired? Should I write out a lot of pages (a la MT and Blogger), or leave the site basically a template that is created when user calls it? (Examples of the latter are a large percentage of current Web sites – Amazon, Slashdot and so on.)

Interesting questions; I have to figure out what it best for me and the site.

While my site should get about 3 hits a year, I still want to build it in an extensible, flexible and robust manner, just for the hell of it. Anyone can build a crappy blogging tool; I’d like to make one that is at least useful to me and has the potential of holding up if I suddenly became popular.

Why not do it right?

But what is right for this tool/for me?

Aye, there’s the rub…

I’m not a big holiday fan – I guess I lean more toward the pre-ghost Scrooge than the post-ghost version. That said, the holidays still mess up one’s system.

Travel, copious amounts of food/drink, the what-day-is-today syndrome and so on takes its toll.

Today, my mind is the consistency of figgy pudding.

But that’s not always a bad thing.

Before I begin, some basics:

There are a lot of arguments – pro and con – regarding Microsoft products and the Microsoft environment.

There are a lot of arguments – pro and con – regarding Linux and the Linux environment.

Yet many people seem to see a lot of these arguments as Apples vs. Apples, when it isn’t. (And let’s not even go into the whole Apple COMPUTER company debates).

Some facts:

• Microsoft makes both operating systems (OS) and applications (Word, Excel, IIS).
• Linux is an operating system – more properly, the kernel (foundation) of an operating system.
• Linux doesn’t make applications. Many apps are built in the same way and with the same spirit as the Linux kernel, but Linux != apps.

So saying “Linux is better than MS” (or vice versa) is really a misnomer, but – in a broad sense – makes sense.

I’ll be using the broad sense for this entry.

Basically, Linux is missing the boat with one of the largest groups that it should be wooing: The just-below Uber-geek type.

Such as me. Sure, I rebuild Linux boxes; I do most things from the command line and so on.

But it still seems like you need to know the secret handshake to do certain things on Linux – things that will foster wide acceptance – that are trivial on Windows, for example.

For example?

I was looking into upgrading the PHP (essentially, an app that sits on top of the OS) on one of my boxes to a more current version. Since I’m past the dot release stage (4.1.x to 4.3.x), there is no simple patch.

How to upgrade?

Damn good question.

Essentially, it appears – and I’m still not certain – that I have to back out all my PHP stuff (PHP itself, PHP ODBC, PHP JDBC, PHP mySQL, PHP Postgres, PHP dev tools and so on) and do a new install.

But wait – there’s more!

The new PHP requires certain libraries and so on, other dependancies that are not necessarily a 1:1 update relationship with the old edition.

Will these new, non-PHP installs mess up something else? Will my system even see the new PHP?

And so on.

MS, with all the install wizards, makes it pretty easy to upgrade even from Win95 to Windows XP, for example. Here on Linux, I can’t easily figure out how to upgrade a point release product.

That’s not good.

It’s getting better. Debian’s aptget and RedHat’s RPM are good starts, but there is still that wide middle ground – between really savvy users and really newbies – that is stymied by stuff like this.

Trash MS all you want, but its install wizards and so on make installing/deinstalling stuff pretty much a no-brainer. Yes, you can rag all you want about how the wizards are necessary because of the seven circles of hell known as the registry and so on (and that’s valid!), but at least MS has it.

I – a pretty geeky dude – want to be able to easily upgrade stuff. It can be command line (I use CPAN, for example, all the time for Perl modules – not intuitive but it works), but I need the following:

• Full package of all items that might be necessary for the upgrade. For example, the newer PHP requires some non-PHP library. Include it
• A way to view what you will be installing ahead of time: This can be a list of files, but it should also say what it satisfies – so I can install this ODBC driver and see that it satisfies the mySQL driver need or whatever.
• A way to narrow the install: Database drivers for DB A, B and C are part of package. I don’t use database B – a way to say don’t install this one
• A way to test to see if the install – as selected – will go in cleanly: RPM has this already; echos unsatisfied dependancies, and so on.
• Detect old versions of package contents and react: I’m installing PHP 4.1.2; I already have PHP 4.1.0 – echo a Yes/No question: Version 4.1.0 has been detected; upgrade(Y/N)?

Basically, the Windoze-like install features, though it does not have to have all the bells and whistles today (later, they will be expected by Linux GUI users).

Let me add or update something simply.

Because – right now – that is not an option.

And that’s a shame.

Again – I AM geeky, but should everyone who want to run a Linux/Unix system have to learn the complete get/make/install routine, figure out how/what libraries are/are needed and so on? It’d be like MS users having to care about DLLs.

End rant.

Without further ado, here are some thoughts on what may/may not happen in 2004.

This is mainly an exercise I do so I can make fun of myself a year from now…

2004 Events/Non-Events

• Sun: I think that 2004 will be, much like 2003, surprisingly quiet for Sun. I expected big upheavals at Sun last year; I was wrong. In 2004, I expect Sun to continue to lose Unix market share, but to make an impact with their Linux desktop (for reasons completely unclear – another nod to the ‘Sun has no clue what to do with Java’ proponents – named the Java Desktop).
• Linux: Will continue its quiet but relentless progress, appearing in all but the most hard-core MS shops by years end in some form. The desktop will make inroads, mainly due to government and 3rd-world adoption, but it will not be a strong contender for the homeowner. Lack of apps and non-Window’s-like behavior will prevent it from being a contender this year. (Note: Users who like Unix desktops will continue to turn to Apple, with the BSD core under a great GUI). The brand-spanking new 2.6 kernel will start making an apearance in a plethora of non-server/desktop tools (phones, toaster ovens…).
• Microsoft: Longhorn will again be delayed; more anti-trust type suits will haunt this company. Some major snafu will come out of the XP Service Pack 2 upgrade (probably security). By year’s end, MS will still be struggling to articulate its .Net initiative. Its stock will still close 2004 above 2003 levels.
• SCO vs. the World: I’m going to go out on a limb here and say that the case against IBM – at least in its current form – will be dismissed this year.
• Apple: Like Linux, a quiet year, but they will do well for Apple. No big introductions, unless some unknown video product emerges.
• Blogs: The blush is off the bride (or whatever that phrase is). I see more mainstream use of blogs while, at the same time, interest in blogs decline. In other words, the initial thrill is gone, and that’ll leave the hard-core bloggers and those that will actually use the medium for something useful, potentially something new and exciting. I’ve noted before the drop off in the number of posts by many bloggers that I read; I expect this to continue. The fascination is gone; now is the time to reap the useful.
• IT Market/Jobs: Spending will increase this year; however, the growth is jobs will be marginalized by two factors: 1) Many of the new jobs will be overseas; 2) There will not be the number of jobs – especially at yesterday’s salaries – offered. Yes, companies will begin hiring again, but very carefully. The recovering economy will not trickle down to the IT worker this year in any compelling manner.
• Languages: Same as 2003 – C# will continue to steal from both Java and VB, but Java will continue to draw programmers. Perl will still be the duct tape that holds the Internet togehter (and makes the majority of most folk’s scripting possible). PHP may make a foray into Java, as ColdFusion has done with ColdFusion MX. If PHP does this, it will be more successful in gaining marketshare and market attention in doing so.
• Google: Google will have – or announce – an IPO. Wall Street will cheer. On another note, Google will draw intense flak for some decision/behavior (blocking access to XX, allowing paid links to YY, for examples) and have to bow to public pressure and roll back on this decision.

Check back in a year for a chuckle.

The news that United Linux may include only one GUI – probably Gnome – is, of course, creating a small firestorm (See the /. thread).

When I first read the blurb on Slashdot, my first reaction was, “What ever happened to ‘Linux is all about choice’ “?

As I thought more about it – and read Bruce Peren’s take on all this – my thinking comes down to this:

• Users still have a choice of installing KDE etc on their machines. While this is a barrier to entry and will in some way hurt KDE, the option is still there
• Linux is about choice. This is a choice the UnitedLinux folks (mainly Perens, I assume) made. May not be your choice, but it is a choice.
• Sure, it would be great if UnitedLinux came with every possible UI … not. Can you say MS-style software bloat? Tough decisions have to be made, and that includes cutting some features/apps some like. Get over it.
• Don’t like the choice? Get another distro or build your own.
• By making the disto as streamlined and uniform as possible, UnitedLinux is doing Linux a service. It’s putting a Linux distro in front of a lot of people who have never used it; it’s best if this first Linux use/deployment is as easy to use/deploy as possible

Also, Perens notes that UnitedLinux will probably go with Postgres for a standard database, instead of the vastly more popular mySQL.

Why? Not really on the databases’ relative merits – it’s because Postgres is fully open; mySQL has some proprietary baggage (the same is true of Gnome vs. KDE – Gnome is fully open).

Again, before people flame, realize that a company deploying UnitedLinux can still standardize on mySQL. They are not “stuck” with Postgres.

Linux is about choice.

UnitedLinux is one of many distro choices.

What’s the problem?

(Full disclosure: On the one Linux box that I have X Windows installed, I run KDE. However, I rarely touch the GUI, so I’m not particularly vested on one GUI vs. another. But my bias is to KDE, and I’m still not at all upset about this development.)

Congrats to all concerned at Groklaw – especially the Webmistress, PJ, on the selection of Groklaw as winning the first annual OSDir.com award for Best News Site.

This is a surprise to no one who has read or contributed to Groklaw; leaves some large shoes to fill for the 2nd annual awards.

Groklaw: The SCO Anti-FUD! Now with whiteners and Awards!

A couple of unrelated thoughts have been rattling around my skull lately.

The first is the issue of competition fostering progress – or, at least, competition being a good thing. This is best summed up, in the tech world, as Microsoft is Evil.

Competition – the thinking goes – forces all players in a particular arena to keep improving (in some manner), and the ultimate outcome of this competition is that the end users benefit, as do the competitors (sometimes, and in different ways).

OK, but think about it. There are (at least) two basic ways a product/service can be considered improved.

• Product differentiation – something different about the latest offering: Faster, stronger …
• Lower cost – Cheaper to use/buy either upfront and/or in the long run

Obviously, these can – and often are – combined.

But note how the non-monetary way to progress is – for the most part – directly at odds with standards. While some product improvements may bring it more in line with overall product-type standards (browser that it CSS2 compliant), there is a good chance that this differentiation will, at least temporarily – move the product away from standards.

So this progress is both a good and bad thing.

Good – Forcing a change in a better direction

Bad: – Changing the status quo – which can lead to integration issues, lock-out tussles and so on

A good example of how a proprietary change affected standards is then-Netscape’s unilateral decision to introduce the FONT tag: It was not part of the HTML spec at the time, but it was quickly adopted (mainly because, at the time, there really was only one browser: Netscape Navigator. Mosaic was around, but it was an academic exercise [and the basis of Navigator] ).

While you can argue that the FONT tag was a good move or not (delayed CSS?), it did have the effect of getting other browsers (i.e. IE) to introduce their own tags/proprietary extensions. While, in themselves, this was not necessarily a good thing (ActiveX, BLINK tag), it did allow the browser to grow and showed the masses that this Web thing could be powerful – could move beyond Times text on a gray background with blue and purple links.

So, competition hurt standards, but raised the bar for when the competitors circled back and started to adhere to more refined standards (CSS 1 and 2, for example, or JavaScript).

So competition can hurt standards but promote progress – and (to a degree) offer end users a choice.

Standards, on the other hand, seems to stifle progress.

Perhaps the best example of standards stifling progress is Microsoft Outlook. The bane of most security-conscious folks’ existence, Outlook is still the de facto standard for e-mail. And – leaving the whole security and MS is the devil issues behind – it’s the standard because it does do so much and does it pretty well. It’s a killer app.

So, the OSS community has to come up with a way to match this killer app.

Right now, it’s Ximian’s Evolution e-mail and calendar application – which is, essentially, an Outlook clone.

In other words, it’s not really better (probably better for security; probably worse in terms of functionality); it’s just a different outfit’s product. It’s like comparing two 5-lb bags of sugar. Which to buy? The cheaper one. Sugar is sugar and so on.

So instead of making something different – taking a new approach – Ximian essentially cloned Outlook. While it’s a lot different under the hood, it’s the same to users.

Which is part of the point, but that’s not really progress.

Here, standards hurt progress; here, competition really doesn’t affect progress.

I guess the message that’s been rattling around my skull is that you can’t be too attached to standards or competition or too vociferously against monoliths such as Microsoft. Because there is a flaw to adhering to strictly to a very competitive environment or a very standards-compliant one.

And – at some fundamental level – standards are the antithesis of competition.

Standards are about interaction, integration, getting similar.

Competition is about differentiation, venturing down dissimilar paths.

OK, first of all, I’m not an idiot (or, a complete idiot…depends on your perspective).

I understand the underlying reason behind the lack of IM (instant messaging) – money. Whoever controls the IM tools (server & client) can control what it does. What it does, ultimately, is provide a revenue stream for AOL, MSN, Yahoo! and so on.

OK, I get that.

But I still don’t get why this ubiquitous, Internet-only tool is proprietary.

The Net is all about interoperability (yeah, Longhorn and zillions of other examples nonwithstanding).

I remember the first online providers, such as Prodigy. Prodigy was a tool that works much like today’s IM tools in that it was closed. Sure, it mimicked some Internet functionality, but – in the end – it was a closed loop. Sure, you could e-mail…but only to another Prodigy member. Your friend/mother/spouse on another system – such as CompuServe? Suck it up and get accounts on each, or forget about e-mailing them.

And if you did suck it up and get two accounts, that’s two dial-ins. And so on.

Sheer madness!

Today, such a notion would be laughed out of a business development meeting. You can only e-mail people who are also on Earthlink? Surely you jest, and stop calling me Shirley…

So why do we accept it for IM?

Mainly because we have no choice, and because IM is not (yet) an enterprise-necessary tool like e-mail, so the outcry and potential solutions come from the tattered masses, not from the Suits in the Boardroom.

But at some point, someone is going to say enough is enough – how it will be handled will be the killer app, but the decision will come down is that messaging is a key Internet tool, and how you add on to the protocol is your call, but everyone’s IM should be able to at least “text message” any other. (Yes, all sorts of buddy list questions and so on, but bear with me…).

In other words, someone/some company is going to figure out – or, if a government, say, mandate – how to get all these tools talking to each other, at some base level. Sure, the problems are huge, but – at the simplest level – the issues are not technological issues, they are business issues. Example questions/scenarios:

• How do you get an AOL (for example) to open their network and lose that ad revenue?
• Who gets to set the framework for how the Open IM works?
• Will this be a new standard, or will it be the same? If the former, backward compatible?
• What – if anything – does this mean for phone text messaging? Or other non-PC uses (car?)

And so on.

Basically, someone is going to get rich (or, at least moderately famous in some tech circles) figuring out how to leverage the ubuqitious nature of IM.

The same is really true of a lot of tools we use every day.

Doubt it?

OK, let’s take e-mail as an example of something that has had the potential of its ubiquity tapped. I.e. I have e-mails from numerous e-mail servers funneled into one e-mail client, not one for each.

So why do I:

• Have a separate favorites/bookmarks list for each browser? (Sure, you can import them, but why not have ONE file that serves all browsers
• Ditto for passwords and so on – yes, there are tools for this sort of thing, including those built into (EACH) browser – but this is for geeks only. So there goes the ubiqutious factor.
• The whole issue of RSS and aggregators and so on is due for a serious shake out. While you could argue that a RSS feed is just like a Web page, it’s something a user has requested in some fashion, then why do I (currently) have to use a different app? Some consolidation is needed to leverage this powerful tool.

There are more such examples; see if you can find some yourself.

It’s just interesting to me. I wish I had the solutions to these problems; I don’t. But that doesn’t keep me from wondering about them.