The narrow timeframe for getting this done every year means an effort to do this successfully would require a way of making contribution to the rulesets very easy and accessible to as many tax experts as possible.
I like a post somewhere down there that proposes XML-based rulesets. It lets fragments be broken off easily and worked on independently. It lets non-programmers contrinbute in a way that doesn't require double entry when logic is added. It offers a tree sturcuture that can follow the section numbering of the tax codes themselves. Use XML elements for expressing labels, instructions and field specs. Use Xlink to point to field and rule dependencies, and use ECMAscript for the math and much of the logic.
I used Web Turbotax under Windows. When I attempted to use it with Netscape on Linux, it blocked me for not using a browser on an appropriate OS. I didn't pursue setting up a proxy to pass a fake Win32 user agent. I suspect it function properly. They didn't do anything too crazy.. it seemed to be straight HTML, safe javascript and AWT Java applets.
I'm going to try a bit (a bit) harder this time and see how it goes, out of curiosity.
Of course, Web Turbotax means placing your tax info, including worksheets and calculations, on Intuit's servers. Privacy sentimentalists probably won't go for that, so a locally-executed tax package for *nix--or pure Java--still probably has a niche.
Not sure this would work well as a Free Software project, though. The research involved and the complexity of a lot of the rules might be prohibitive, especially given the undiminished amount of effort that would have to go into updates every subsequent year. To say nothing of the horror of getting the state tax forms taken care of.
I humbly suggest that the core logic of such a project be done as a set of javabeans without the aid of a relational database, so that standalone, web, client-server and other interfaces can be built on top of it, and make it comfortably cross-platform. The Unix/Linux community probably doesn't have enough programming-literate tax accountants to get this done. If it's platform-independent, there would be a better chance of something like this coming together.
They're going to be using a Gameboy-like reflective color LCD. The part (from Motorola, as part of an announcement of new Dragnoball chips) went into production a couple of months ago. Battery life may not be 2 months, but it'll still be comfortably several weeks.
Again, reflective LCD. This is not going to be a bright, active-matrix, high-color, video-capabale battery guzzler like the color WinCE devices. Palm waited until the right technology was on hand, and now they're making their move.
Don't expect gorgeous thusands-of-colors displays. Not having the specs on hand, I'm taking an unnecessary gues that it will support a limited palette of 16-64 simultaneous colors from a total of maybe 256.
Spot color. Good enough for nice visual cues throughout and some stripped-down web access. More than good enough for me. They'll sell a zillion of 'em. I'd expect no size increase either.. certainly they'll be able to keep it in the form factor of the III-series, and maybe they'll get it down to the size of the VII. We'll have to see. They're not dumb.
Priceline appears to have an extra-special set of cojones. Their patent covers something that was done on timesharing computers years ago, notably by a company that one of the Priceline founders was associated with, and the new twist is that they're doing it on the web.
While we're getting the hang of rooting for Microsoft for once, does anyone know how things are going vis-a-vis Cleartype, the Microsoft flat-panel font-rendering techniqe that eerily resembles something an Apple engineer did on CRTs 20 years ago?
I pulled down a pre-M12 nightly last week and for the first time, Gecko nailed ZDNet pages properly.
At last, some hope that it will be an acceptable mainstream browser. And, oh, at least on Win32, the XUL widget stuff is suddenly many orders of magnitude faster. Still a bit awkward-looking, but it's pretty much as fast as native dialogs.
It's still months away from being a product, but it's clearly turned the corner. Now if they can work on usability, especially in terms of plugin/embed support, etc., they may yet have something interesting indeed.
I'm not one to agree with most of Stallman's pronouncements. I'm a KDE-using, dual-booting, BSD-license-approving heathen.
But this. This. I had to do something, and not just stop shopping at Amazon for a while. No, I've stopped shoiping at Amazon altogether, and paved over my account to make sure I don't again without real effort.
I wrote to Amazon and asked them to deactivate my account permanently. After sending a list of recent purchases as identity verification, they've pulled the plug. And I've bought a couple thousand dollars worth of stuff there.. including gifts and personal and business purchases.
Boycott, my ass. Burn your account. Ditto for Priceline, eBay and eToys. Tell them to do the right thing and set up a strawman case and file briefs with the Supreme Court in favor of knocking down these frivolous "everything old is patentable again on the web" patents.
Priceline has a patent on their style of reverse auctions. They don't bother claiming it's a new form of reverse auction, or even that they were the first to do it via client-server computing. Their patent is on doing that kind of auction on the web.
If eBay (or Ticketmaster, or insert-name-of-company-suing-over-deep-linking) spent half a day writing a routine to have its pageserving routines combine a cookie check with a check for a valid referer URL, they'd be able to block deep linking altogether.
Yes, referers are forgeable, but if you check to see that a referer contains something that, say, matches a user-level cookie, the indexers would be able to index all they want, but they wouldn't be able to link anyone to anything.
The fact is, eBay wants people do deep-link: they want users to be able to send each other links to items, which this would preclude. They just don't want anyone to make a compelling business of it.
Sorry, eBay. Unless you want to start distributing special client software, you're going to have to choose between allowing deep linking for everyone or for no one at all. If the courts fail to see this, there are some judges who need to go back to law school.
So let's see. VA's an Intel-based hardware company. They sell the usual ATX-case Celeron PCs, some decent workstation models, and some good-but-not-terribly-innovative servers in the 1-4 CPU range.
So all the excitement is over the fact that they do a good job of testing and preinstalling Linux on them? That they have a modest services operation that builds turnkey Beowulf clusters? That they employ a few prominent programmers, and do some of their own hardware R+D?
And once the Dells, IBMs, HPs and Compaqs of the world ramp up support and services organizations for Linux, where does that put VA? VA makes good, speedy machines, but customers that care most about speedy machines want a hardware vendor with a broad product line and a comprehensive support solution. Supporting only one OS on Intel hardware is a bit archaic these days, and VA's 4-CPU top-of-the-line makes them no more a threat to Compaq in the Fortune 500 than Dell is.
By comparison, Cobalt is a more rational investment. They picked a couple of vertical applications and homed in on them hard.
You can spend a few hours building your appliance, and then spend the next couple of days configuring everything from ipfwadm to samba and apache, and continue to configure it via telnet and vi.
Or you can be someone who knows something about networking but nothing about Unix and buy one of these and have a working NAT box, firewall, workgroup webserver, Windows/Mac fileserver, IMAP mailserver and majordomo box up and running in ten minutes. No joke.
Cobalt's boxen aren't cutting-edge from a software standpoint (they don't use LDAP, no PHP preinstalled on the webserver, etc.) and if you want a general-purpose Linux server, the MIPS CPU can be a minor hassle.
But they have done an incredible, genius job of gluing everything together with seamless web-based configuration, good documentation, and a fuss-free experience. If you want an infinitely flexible system, or want to use it for things it wasn't meant for (databases, XWindow app hosting, etc.), it's a bad choice. But if you're going to use it for what it's made for, it's an absolutely wonderful gizmo.
In sum, unlike a general-purpose server, it's a real appliance, which means it's as easy to set up as a videogame console. I started a new job with a smallish company and discovered they had an unprotected network and no email, and I didn't have time to spend a couple of days building and configuring all the services on a generic PC or server, so I ordered a Qube. I was blown away. They deserve all the accolades they get.
And given the time it saves and the sysadmin burden it gets rid of, it's a bargain.
Fuel-cell cars kick up significant heat, so they're probably fine in a world with these, but what about pure electrics? Would the brakes and maybe the climate control system be the only significant heat sources? Would they be enough to see an electric car by in warmer months?
I suspect Teamware Office is a tough sell at the moment, what with no PDA synchronization. Show me an IT manager with a decent budget and I'll show you the Palm cradle in their office. And an IT manager's not going to buy a group calendaring/mail/planning system they can't sync to their Palm.
At the very least, they ought to license Starfish's web-to-Palm sync software for Win32, though between the Java conduit SDK and an XML parser, cross-platform sync for web and client/server alike shouldn't be that hard for these web-groupware vendors to do.
This is C|Net tooting its own horn. Yes, IDG has stumbled in the last few years, with a bad web strategy and a tendency to make wild, random changes to its strategy.
But how about Ziff-Davis? ZDNet is a very successful web venture, and very competitive with C|Net. And their editorial content remains much, much deeper in both quantity and quality.
Yeah, something like Computer Shopper is an anachronism, what with most hardware geeks now shopping online. But the likes of PC,Infoworld and PC Week, among others, will continue to flourish until full-color e-books become pleasant to read on a commuter train, or over a meal in a cramped luncheonette, or on the toilet. After all, most computer magazines are really sublimated pornography.
So yeah, they're doomed, and they'll eventually be the first genre to go all-e-book, but there are a few good years left, and it will only happen when e-book interfaces (and readability, and dot pitch) are better than a vintage-1999 "web browser".
And on another note, Byte collapsed because they changed into an enterprise computing magazine. 10,000 CTOs do not a viable newsstand magazine circulation base make. Their original formula--voracious eclecticism--was poised for a comeback thanks to the open-source revolution, and the editors and publishers didn't see it. The computing world was once again ready for its original mix of hardware projects, programming theory, treatises on chip fabrication techniques, code snippets and stringent product evaluations. If Linux Journal were any good at what it tries to do, it would be very much like the old Byte. Instead, they've got some high school intern reviewing Oracle 8i on the basis of how easily it installs and how easy it was to set up a 3-table CD-catalogger. And worse.
Apart from Pournelle's column, the magazine that shut down some time back was Byte only in name.
Redhat paid fees to RSA quite some time ago and has been passing along the result in the "Secure" and "Commerce" (now called "Professional") editions of its distro since at least 5.2. They use the same mod_ssl and openSSL packages you can download for free but aren't legally allowed to use for commercial deployment in North America.
Redhat is paying RSA's "toll" for using their patented algorithms in North America. In other words, they make it legal for commercial sites in the US to run Apache with mod_ssl, making for a cheap, first-rate alternative to Raven or Stronghold.
As far as I can tell, this PR blitz is mostly RSA stock trying to ride in Redhat's jetstream.
Um, last time I checked, most iPlanet products were picking up where the Netscape ones left off. Most of the "migrations" such as they are, are going to be from the discontinued Sun products. Let's look at that:
Directory server. It's an LDAPv3 server with LDIF support. Migrating to the Netscape/iPlanet product won't take long at all.
Mail server. Sun's mail server is a POP3/SMTP/IMAP server with no particularly special features. It authenticates against an LDAP server. THe Netscape/iPlanet mail server is a POP3/SMTP/IMAP server with a few special features. It authenticates against an LDAP server. Migration of mailboxes should consist of a few Net::IMAP perl scripts.
Web server. Sun's non-Java webserver is nothing special, and nobody of note uses it anyway. Moving CGIs written for it (which is about all it can do) won't take much. And Sun's Java Webserver is a Servlet 2.0 webserver with sub-1.0 JSP support. The Netscape/iPlanet Enterprise Server supports 2.0 servlets and sub-1.0 JSP. No code will likely have to change to move to this. The big deal, such as it is, is learning a new admin tool and config file format.
Application server. This is as much of a trouble spot as there will be. In essence, the iPlanet Application Server is going to be the Kiva/Netscape engine combined with the NetDynamics tools. So NetDynamics customers might have a bit of a hump to get over, but nothing much worse than what most EJB appserver customers go through in order to take advantage of new revs of the APIs.
As a customer of both companies, this doesn't seem bad at all. I've seen worse upgrade headaches from a single vendor. What are Sun's customers pissed about with regard to their server software? They've got the most popular commercial Unix out there, and some of the best hardware and hardware support around. Their own server software line was never that popular in the first place, and moving customers from one standards-compliant server software line to another isn't bad at all.
Yeah, iPlanet == Sun, but it's not like changing the brand name means the underlying products came out of nowhere.
Are you a paying customer of either? Personally, I'd rather use OpenLDAP, Cyrus, and an EJB appserver that plays nice with Apache. But as a customer of both Sun and Netscape over the years, I think the Sun adoption of the Netscape server product line is good news.
This is tiresome. Corel doesn't have a SQL database server in their product line,nor do they have a web app server. What do you mean by "their own product"? Corel Linux? With PHP3 and Postgres?
Why should their Linux Desktop Apps Group waste their time reinventing the wheel and learning PHP when Corel already has a generic beta-tester signup form handy? It's not as though this is, say, Sun, still running a web store written with Dynamo when they own not one but two competing app servers.
Lord knows I've never seen a MySQL or Postgres database throw errors when a tablespace fills up and there's no room for more extents. Not.
For one thing, the buyout made millionaires out of most longtime Netscape employees. Bolting the minute one vests is a perennial problem at tech companies, and it's getting worse.
Second, Netscape's Unix-oriented tech culture started to hurt them when focus shifted towards usability features and cute UI flourishes in 1996. This was clear both on the browser side
the tedium of installing plugins, the horrors of SmartUpdate
their miserable signed-applet security dialogs
and on the server side
the stubborn insistence on browser-based interfaces for server administration; client Java wasn't good enough but a native GUI would have made many admin tasks easier. Between their awful web admin UI and their poorly-documented config file format, Apache was easier to administer
for all their open APIs, and with all due respect for their LDAP servers, would it have killed them to bundle modules for native-OS authentication (at least NTDOM and NIS) with their admin server? This sort of thing came across as arrogance and contempt for the customer.
I don't, however, fault them for their lousy tech support. I always found their server support group competent and responsive. It wasn't their fault that the product engineers would leave nasty bugs unfixed for release after release. That's why Apache's so compelling. And unless you had a special relationship with Microsoft, mediocre support like Netscape's was far above average.
AOL and Sun bought themselves a troubled company with a faltering product vision, and they knew it. That doesn't mean Mozilla's not great technology; it is. And it doesn't mean Netscape's server line isn't good. It is. That's why their mail, web, directory, cert and app servers are the basis for the iPlanet line. But both the client and server groups at Netscape were sorely lacking product architects with customer and market focus.
In this regard, the buyout offered Netscape a chance for redemption. If AOL can be made to care about Mozilla, their understanding of customer-focused (as opposed to geek-focused) usability can help it in ways XUL and XPFE as rallying slogans couldn't. And though Sun is still coming up to speed as a software vendor, they at least know how to listen to their customers in designing products in a way Netscape never did.
Yeah, M10 and the recent nightlies show a pretty good browser with what appears to be decent DHTML support and good speed. And yeah, it supports XML+CSS1. But last time I checked, draft-spec XSL support (which is very much a part of IE5, thanks) was both lousy and not part of the main branch. Boo.
And how's the ActiveX support? Crappy security model? Yeah. IT manager's nightmare? Yeah. Only really supported on Win32? Yeah. Integral part of MSIE, which they're shooting for compatibility with? Big yeah.
And unless they work really hard on making their icky dynamic-update module installation system usable by normal people (and SmartUpdate sure wasn't), they're still going to be way behind IE5 when they ship. Sure, Mozilla's cross-platform, but can it go on being a year behind in standards implementation and ease of use?
Netscape's Server-Side Javascript (formerly known as Livewire) is a buggy, sloppily-written engine for running compiled web apps in a memory-resident manner. In other words, the templates are kept in RAM, and have been since late 1995.
Since the version in their 3.0 webservers, it has had decent server-level object support, too. Which means, yes, data cached in memory at the master HTTP process level. A common tecnique is to populate an array element at the server level when a piece of content is first retrieved, and only hit the data source again for records that aren't present, or which have aged.
Even more fun, I'd be glad to show interested lawyers an application I architected at a past employer that's been in production use for almost 3 years now. It's a distributed custom-email delivery system that caches content data both at the server level and at a spoke client level, in RAM. The clients request and use the cached data to assemble outbound messages.
As for using OS-level shared memory for this sort of thing, I'm sure some database and high-performance filesystem vendors are having a good laugh right now.
No. Vignette StoryServer caches page fragments to disk. Of course, if it happens to be caching to a filesystem that itself is cached in memory, pretty much the same thing is happening.
However, good old GroupLens, the personalization server they bundle, does cache user preferences and such to memory. Of course, these aren't page components. But plenty of other systems do that.
CPAN is a good starting point for inspiration.. but could it be taken further?
What if you could take the CPAN system's support for automated download and install of modules and apply the concept to, say, Java environments in some of the following ways:
Automated download and install of beans, JARs, etc. from any of a set of mirrors via CVS, WebDAV, FTP, ot the like.
Distribution (and auto-generation) of Javadoc, UML diagrams, beaninfo, etc through similar open mechanisms
Integration with development environments, to allow the repositories to be browsed as though all the files are local, by distributing RDF catalogs of metatdata. (Picture GnoRPM to get an idea of one UI approach to this). Selecting a package would trigger retrieval of API docs, class diagrams, or the package itself.
Similarly, a utility analogous to AutoRPM could handle automated, unattended installation of necessary packages. RPM itself could be the means for this, but maybe it could be taken further to standardize such actions as installing and registering a servlet, genertating IDL, deploying code on an ORB, etc.
In other words, making a freshmeat not for direct human access, but for automated machine access and autodiscovery.
Back in the day, Hüsker Dü had a song called "How to Skin a Cat", some spoken-word nonsense about figuring out a way to get rich by selling cat skins. The punchline, following a "Hey! I've got it!":
We'll feed the cats to the rats And the rats to the cats And get the cat skins for nothing!
I'm tempted to laugh along, but I'm ready to give this a bit more credit.
The folks he took from Netscape include one of the two LDAP leads they got from UMich, and one of the Kiva appserver people. These two things were the strongest technology pieces they had in their core server line--and indeed, they're staying in the product line at Sun/iPlanet.
Still don't know what they're going to do.. the speculation is less than compelling. Netsacape tried to sell a product line of bare servers with no bundled finished apps (in contrast with Notes, for one), and fell on their collective arse. Hosted bare server apps? Ehh.
And Andressen himself was very much a figurehead much of the time at Netscape. But even if you think of Andressen as a money guy instead of a tech guy, he's an asset. He has a good rolodex.
One interesting idea this leads to is the adoption of Doom as the basis for a 3-D visulaization interface for network and system management.
Imagine extending things like Ganymede, Scotty and relational asset databases to auto-generate.WAD files represtenting network maps, zonefiles, LDAP directories, SNMP agents and so forth, and using a modified Doom interface to select and perform actions on objects.
I never got into.WAD design back in the day, but surely there are tools out there for turning architectural floorplans into.WADs, too.
The big issues would be (1) the one-map-at-a-time design of Doom, which would make it hard to toggle between physical and logical views of networks, and (2) the fixed-target UI of Doom, which is good for the game, less good for this. Marathon, with its mouse-positioned gunsight, may not have been as good a game, but it would have made a bettern WAN visualization tool out of the box.
Slashdot Mirror
The narrow timeframe for getting this done every year means an effort to do this successfully would require a way of making contribution to the rulesets very easy and accessible to as many tax experts as possible.
I like a post somewhere down there that proposes XML-based rulesets. It lets fragments be broken off easily and worked on independently. It lets non-programmers contrinbute in a way that doesn't require double entry when logic is added. It offers a tree sturcuture that can follow the section numbering of the tax codes themselves. Use XML elements for expressing labels, instructions and field specs. Use Xlink to point to field and rule dependencies, and use ECMAscript for the math and much of the logic.
I used Web Turbotax under Windows. When I attempted to use it with Netscape on Linux, it blocked me for not using a browser on an appropriate OS. I didn't pursue setting up a proxy to pass a fake Win32 user agent. I suspect it function properly. They didn't do anything too crazy.. it seemed to be straight HTML, safe javascript and AWT Java applets.
I'm going to try a bit (a bit) harder this time and see how it goes, out of curiosity.
Of course, Web Turbotax means placing your tax info, including worksheets and calculations, on Intuit's servers. Privacy sentimentalists probably won't go for that, so a locally-executed tax package for *nix--or pure Java--still probably has a niche.
Not sure this would work well as a Free Software project, though. The research involved and the complexity of a lot of the rules might be prohibitive, especially given the undiminished amount of effort that would have to go into updates every subsequent year. To say nothing of the horror of getting the state tax forms taken care of.
I humbly suggest that the core logic of such a project be done as a set of javabeans without the aid of a relational database, so that standalone, web, client-server and other interfaces can be built on top of it, and make it comfortably cross-platform. The Unix/Linux community probably doesn't have enough programming-literate tax accountants to get this done. If it's platform-independent, there would be a better chance of something like this coming together.
They're going to be using a Gameboy-like reflective color LCD. The part (from Motorola, as part of an announcement of new Dragnoball chips) went into production a couple of months ago. Battery life may not be 2 months, but it'll still be comfortably several weeks.
Again, reflective LCD. This is not going to be a bright, active-matrix, high-color, video-capabale battery guzzler like the color WinCE devices. Palm waited until the right technology was on hand, and now they're making their move.
Don't expect gorgeous thusands-of-colors displays. Not having the specs on hand, I'm taking an unnecessary gues that it will support a limited palette of 16-64 simultaneous colors from a total of maybe 256.
Spot color. Good enough for nice visual cues throughout and some stripped-down web access. More than good enough for me. They'll sell a zillion of 'em. I'd expect no size increase either.. certainly they'll be able to keep it in the form factor of the III-series, and maybe they'll get it down to the size of the VII. We'll have to see. They're not dumb.
Priceline appears to have an extra-special set of cojones. Their patent covers something that was done on timesharing computers years ago, notably by a company that one of the Priceline founders was associated with, and the new twist is that they're doing it on the web.
While we're getting the hang of rooting for Microsoft for once, does anyone know how things are going vis-a-vis Cleartype, the Microsoft flat-panel font-rendering techniqe that eerily resembles something an Apple engineer did on CRTs 20 years ago?
I pulled down a pre-M12 nightly last week and for the first time, Gecko nailed ZDNet pages properly.
At last, some hope that it will be an acceptable mainstream browser. And, oh, at least on Win32, the XUL widget stuff is suddenly many orders of magnitude faster. Still a bit awkward-looking, but it's pretty much as fast as native dialogs.
It's still months away from being a product, but it's clearly turned the corner. Now if they can work on usability, especially in terms of plugin/embed support, etc., they may yet have something interesting indeed.
I'm not one to agree with most of Stallman's pronouncements. I'm a KDE-using, dual-booting, BSD-license-approving heathen.
But this. This. I had to do something, and not just stop shopping at Amazon for a while. No, I've stopped shoiping at Amazon altogether, and paved over my account to make sure I don't again without real effort.
I wrote to Amazon and asked them to deactivate my account permanently. After sending a list of recent purchases as identity verification, they've pulled the plug. And I've bought a couple thousand dollars worth of stuff there.. including gifts and personal and business purchases.
Boycott, my ass. Burn your account. Ditto for Priceline, eBay and eToys. Tell them to do the right thing and set up a strawman case and file briefs with the Supreme Court in favor of knocking down these frivolous "everything old is patentable again on the web" patents.
Priceline has a patent on their style of reverse auctions. They don't bother claiming it's a new form of reverse auction, or even that they were the first to do it via client-server computing. Their patent is on doing that kind of auction on the web.
If eBay (or Ticketmaster, or insert-name-of-company-suing-over-deep-linking) spent half a day writing a routine to have its pageserving routines combine a cookie check with a check for a valid referer URL, they'd be able to block deep linking altogether.
Yes, referers are forgeable, but if you check to see that a referer contains something that, say, matches a user-level cookie, the indexers would be able to index all they want, but they wouldn't be able to link anyone to anything.
The fact is, eBay wants people do deep-link: they want users to be able to send each other links to items, which this would preclude. They just don't want anyone to make a compelling business of it.
Sorry, eBay. Unless you want to start distributing special client software, you're going to have to choose between allowing deep linking for everyone or for no one at all. If the courts fail to see this, there are some judges who need to go back to law school.
So let's see. VA's an Intel-based hardware company. They sell the usual ATX-case Celeron PCs, some decent workstation models, and some good-but-not-terribly-innovative servers in the 1-4 CPU range.
So all the excitement is over the fact that they do a good job of testing and preinstalling Linux on them? That they have a modest services operation that builds turnkey Beowulf clusters? That they employ a few prominent programmers, and do some of their own hardware R+D?
And once the Dells, IBMs, HPs and Compaqs of the world ramp up support and services organizations for Linux, where does that put VA? VA makes good, speedy machines, but customers that care most about speedy machines want a hardware vendor with a broad product line and a comprehensive support solution. Supporting only one OS on Intel hardware is a bit archaic these days, and VA's 4-CPU top-of-the-line makes them no more a threat to Compaq in the Fortune 500 than Dell is.
By comparison, Cobalt is a more rational investment. They picked a couple of vertical applications and homed in on them hard.
You can spend a few hours building your appliance, and then spend the next couple of days configuring everything from ipfwadm to samba and apache, and continue to configure it via telnet and vi.
Or you can be someone who knows something about networking but nothing about Unix and buy one of these and have a working NAT box, firewall, workgroup webserver, Windows/Mac fileserver, IMAP mailserver and majordomo box up and running in ten minutes. No joke.
Cobalt's boxen aren't cutting-edge from a software standpoint (they don't use LDAP, no PHP preinstalled on the webserver, etc.) and if you want a general-purpose Linux server, the MIPS CPU can be a minor hassle.
But they have done an incredible, genius job of gluing everything together with seamless web-based configuration, good documentation, and a fuss-free experience. If you want an infinitely flexible system, or want to use it for things it wasn't meant for (databases, XWindow app hosting, etc.), it's a bad choice. But if you're going to use it for what it's made for, it's an absolutely wonderful gizmo.
In sum, unlike a general-purpose server, it's a real appliance, which means it's as easy to set up as a videogame console. I started a new job with a smallish company and discovered they had an unprotected network and no email, and I didn't have time to spend a couple of days building and configuring all the services on a generic PC or server, so I ordered a Qube. I was blown away. They deserve all the accolades they get.
And given the time it saves and the sysadmin burden it gets rid of, it's a bargain.
Fuel-cell cars kick up significant heat, so they're probably fine in a world with these, but what about pure electrics? Would the brakes and maybe the climate control system be the only significant heat sources? Would they be enough to see an electric car by in warmer months?
Percentages are good, but what I liked was taking the change in the number of hosts and looking at the sheer numbers.
Do the math. Approximately 4 Apache hosts went up for each IIS/PWS host that went up in the past month.
Yes, lots of those hosts are virtual hosts on the same machines, but even that says something about Apache's penetration at web hosting providers.
I suspect Teamware Office is a tough sell at the moment, what with no PDA synchronization. Show me an IT manager with a decent budget and I'll show you the Palm cradle in their office. And an IT manager's not going to buy a group calendaring/mail/planning system they can't sync to their Palm.
At the very least, they ought to license Starfish's web-to-Palm sync software for Win32, though between the Java conduit SDK and an XML parser, cross-platform sync for web and client/server alike shouldn't be that hard for these web-groupware vendors to do.
This is C|Net tooting its own horn. Yes, IDG has stumbled in the last few years, with a bad web strategy and a tendency to make wild, random changes to its strategy.
But how about Ziff-Davis? ZDNet is a very successful web venture, and very competitive with C|Net. And their editorial content remains much, much deeper in both quantity and quality.
Yeah, something like Computer Shopper is an anachronism, what with most hardware geeks now shopping online. But the likes of PC, Infoworld and PC Week, among others, will continue to flourish until full-color e-books become pleasant to read on a commuter train, or over a meal in a cramped luncheonette, or on the toilet. After all, most computer magazines are really sublimated pornography.
So yeah, they're doomed, and they'll eventually be the first genre to go all-e-book, but there are a few good years left, and it will only happen when e-book interfaces (and readability, and dot pitch) are better than a vintage-1999 "web browser".
And on another note, Byte collapsed because they changed into an enterprise computing magazine. 10,000 CTOs do not a viable newsstand magazine circulation base make. Their original formula--voracious eclecticism--was poised for a comeback thanks to the open-source revolution, and the editors and publishers didn't see it. The computing world was once again ready for its original mix of hardware projects, programming theory, treatises on chip fabrication techniques, code snippets and stringent product evaluations. If Linux Journal were any good at what it tries to do, it would be very much like the old Byte. Instead, they've got some high school intern reviewing Oracle 8i on the basis of how easily it installs and how easy it was to set up a 3-table CD-catalogger. And worse.
Apart from Pournelle's column, the magazine that shut down some time back was Byte only in name.
Redhat paid fees to RSA quite some time ago and has been passing along the result in the "Secure" and "Commerce" (now called "Professional") editions of its distro since at least 5.2. They use the same mod_ssl and openSSL packages you can download for free but aren't legally allowed to use for commercial deployment in North America.
Redhat is paying RSA's "toll" for using their patented algorithms in North America. In other words, they make it legal for commercial sites in the US to run Apache with mod_ssl, making for a cheap, first-rate alternative to Raven or Stronghold.
As far as I can tell, this PR blitz is mostly RSA stock trying to ride in Redhat's jetstream.
As a customer of both companies, this doesn't seem bad at all. I've seen worse upgrade headaches from a single vendor. What are Sun's customers pissed about with regard to their server software? They've got the most popular commercial Unix out there, and some of the best hardware and hardware support around. Their own server software line was never that popular in the first place, and moving customers from one standards-compliant server software line to another isn't bad at all.
Yeah, iPlanet == Sun, but it's not like changing the brand name means the underlying products came out of nowhere.
Are you a paying customer of either? Personally, I'd rather use OpenLDAP, Cyrus, and an EJB appserver that plays nice with Apache. But as a customer of both Sun and Netscape over the years, I think the Sun adoption of the Netscape server product line is good news.
This is tiresome. Corel doesn't have a SQL database server in their product line,nor do they have a web app server. What do you mean by "their own product"? Corel Linux? With PHP3 and Postgres?
Why should their Linux Desktop Apps Group waste their time reinventing the wheel and learning PHP when Corel already has a generic beta-tester signup form handy? It's not as though this is, say, Sun, still running a web store written with Dynamo when they own not one but two competing app servers.
Lord knows I've never seen a MySQL or Postgres database throw errors when a tablespace fills up and there's no room for more extents. Not.
Babies.
Second, Netscape's Unix-oriented tech culture started to hurt them when focus shifted towards usability features and cute UI flourishes in 1996. This was clear both on the browser side
and on the server side
I don't, however, fault them for their lousy tech support. I always found their server support group competent and responsive. It wasn't their fault that the product engineers would leave nasty bugs unfixed for release after release. That's why Apache's so compelling. And unless you had a special relationship with Microsoft, mediocre support like Netscape's was far above average.
AOL and Sun bought themselves a troubled company with a faltering product vision, and they knew it. That doesn't mean Mozilla's not great technology; it is. And it doesn't mean Netscape's server line isn't good. It is. That's why their mail, web, directory, cert and app servers are the basis for the iPlanet line. But both the client and server groups at Netscape were sorely lacking product architects with customer and market focus.
In this regard, the buyout offered Netscape a chance for redemption. If AOL can be made to care about Mozilla, their understanding of customer-focused (as opposed to geek-focused) usability can help it in ways XUL and XPFE as rallying slogans couldn't. And though Sun is still coming up to speed as a software vendor, they at least know how to listen to their customers in designing products in a way Netscape never did.
Yeah, M10 and the recent nightlies show a pretty good browser with what appears to be decent DHTML support and good speed. And yeah, it supports XML+CSS1. But last time I checked, draft-spec XSL support (which is very much a part of IE5, thanks) was both lousy and not part of the main branch. Boo.
And how's the ActiveX support? Crappy security model? Yeah. IT manager's nightmare? Yeah. Only really supported on Win32? Yeah. Integral part of MSIE, which they're shooting for compatibility with? Big yeah.
And unless they work really hard on making their icky dynamic-update module installation system usable by normal people (and SmartUpdate sure wasn't), they're still going to be way behind IE5 when they ship. Sure, Mozilla's cross-platform, but can it go on being a year behind in standards implementation and ease of use?
Netscape's Server-Side Javascript (formerly known as Livewire) is a buggy, sloppily-written engine for running compiled web apps in a memory-resident manner. In other words, the templates are kept in RAM, and have been since late 1995.
Since the version in their 3.0 webservers, it has had decent server-level object support, too. Which means, yes, data cached in memory at the master HTTP process level. A common tecnique is to populate an array element at the server level when a piece of content is first retrieved, and only hit the data source again for records that aren't present, or which have aged.
Even more fun, I'd be glad to show interested lawyers an application I architected at a past employer that's been in production use for almost 3 years now. It's a distributed custom-email delivery system that caches content data both at the server level and at a spoke client level, in RAM. The clients request and use the cached data to assemble outbound messages.
As for using OS-level shared memory for this sort of thing, I'm sure some database and high-performance filesystem vendors are having a good laugh right now.
No. Vignette StoryServer caches page fragments to disk. Of course, if it happens to be caching to a filesystem that itself is cached in memory, pretty much the same thing is happening.
However, good old GroupLens, the personalization server they bundle, does cache user preferences and such to memory. Of course, these aren't page components. But plenty of other systems do that.
What if you could take the CPAN system's support for automated download and install of modules and apply the concept to, say, Java environments in some of the following ways:
In other words, making a freshmeat not for direct human access, but for automated machine access and autodiscovery.
We'll feed the cats to the rats
And the rats to the cats
And get the cat skins for nothing!
I'm tempted to laugh along, but I'm ready to give this a bit more credit.
The folks he took from Netscape include one of the two LDAP leads they got from UMich, and one of the Kiva appserver people. These two things were the strongest technology pieces they had in their core server line--and indeed, they're staying in the product line at Sun/iPlanet.
Still don't know what they're going to do.. the speculation is less than compelling. Netsacape tried to sell a product line of bare servers with no bundled finished apps (in contrast with Notes, for one), and fell on their collective arse. Hosted bare server apps? Ehh.
And Andressen himself was very much a figurehead much of the time at Netscape. But even if you think of Andressen as a money guy instead of a tech guy, he's an asset. He has a good rolodex.
One interesting idea this leads to is the adoption of Doom as the basis for a 3-D visulaization interface for network and system management.
.WAD files represtenting network maps, zonefiles, LDAP directories, SNMP agents and so forth, and using a modified Doom interface to select and perform actions on objects.
.WAD design back in the day, but surely there are tools out there for turning architectural floorplans into .WADs, too.
Imagine extending things like Ganymede, Scotty and relational asset databases to auto-generate
I never got into
The big issues would be (1) the one-map-at-a-time design of Doom, which would make it hard to toggle between physical and logical views of networks, and (2) the fixed-target UI of Doom, which is good for the game, less good for this. Marathon, with its mouse-positioned gunsight, may not have been as good a game, but it would have made a bettern WAN visualization tool out of the box.