The Palm's Dragonball processors are in the 68020 family. The Atari STs used its brothers, so a Palm port of GEM can probably be done. However, the rest of the hardware design was probably very different, so how hard this would be may depend on how well the code is organized on the device driver front.
And most existing GEM apps would be a bit awkward in 160x160. But that never stopped anyone.
And unlike the Linux distro for the Palm, GEM should be small enough to fit on a stock Palm Professional, to say nothing of the later models.
GEM is cross-platform. GEM runs fine on a 286 with 512K RAM, not to mention a plain old 68000.
Hey! I know what would be great: a DOS palmtop with Hercules graphics support and IrDA running the DOS GEM version of Ventura Publisher. You could turn it into a handheld print shop and beam PostScript output to IR-capable printers and PCs.
Until I installed some AOL content provider tools on my copy of AOL that WINE chokes on, I'd been running AOL 4.0 for Win95 under WINE for a couple of months.
Apart from modem dialing, font-encoding issues and its lack of a web browser (since it can't use IE), the core AOL client stuff is pretty much at beta quality, at least as far as x86 Unixes goes. Chat, IM, Rainman/VPD forms, and TCP/IP connectivity all work fine.
So between the development momentum WINE has and a motivation to build the core browser engine of Mozilla to release, AOL would have a pretty easy time making a solid AOL 4.0 client for x86 Linux.
I suspect AOL's next direction is going to be toward DHTML and a phase-out of their proprietary content format and rendering technologies. During the transition, for an AOL 5.0 product phase, they could move the Rainman/VPD support to Java, basically turning thr AOL client into "Mozilla + pluggable chat (sound familiar?) + a JVM (from partner Sun)".
Such a creature could run in whole or in parts, using the same codebase everywhere, on anything from a PDA to a screenphone to a PC.
For those of you who missed the page while it was up: the proposal came from Netscape and AOL people, presumably from the instant messaging client product groups.
The proposal did seem to be pretty narrow and a little wrongheaded in its approach, though, and for that deserved to be withdrawn. I suspect this will be coming back after some discussion on the relevant newsgroups. For one thing, there's no reason each IM client has to come bundled with its own UI shell. I might be mistaken, but my quick read of the spec called for each client to bring its own.
AIM and ICQ (and things that present a siumilar UI, like private messages on IRC) could employ a shared UI, and clients that need a modified or different UI could instead subclass it and make use of the relevant bits (like the buddy list or the multiperson chat windows).
Again, if this remains merely a removable module, and is created by people who aren't already working on core browser/editor/mail/news, it seems pleasant enough.
If someone wants to write a generalized, pluggable chat and IM interface, so be it. Nothing wrong with adding hooks for such components as long as it doesn't distract anyone working on the components the browser, editor, mail and news depend on.
Indeed, as long as we're resigned to an understanding that there isn't going to be an NGLayout-based browser in wide, stable release for another year, this sort of thing is actually good for the Mozilla project, since it increases the number of people coding for (and thus familiar with) the Mozilla architecture and APIs.
And who's to say that contributions to tendrils like an AIM, ICQ or IRC client won't bubble up to the browser core? Again, I'd hate to see this take people away from the core, is all.
Why shouldn't they post it as MP3 files? It's not as though Public Enemy has put out five half-decent songs in the years since Fear of a Black Planet came out about ten years ago, and even that was a step down from A Nation of Millions....
In other MP3 "news" regarding David Bowie, you'd likely have to go back to 1983 to find him mattering, unless you're a particularly tone-deaf sort.
Wake me up when someone whose career is still viable goes the MP3 route. I mean, Chuck D's a swell guy, but nobody cares about him anymore.
Qualcomm signed on the better part of a year ago. The pdQ will probably ship in quantity around midyear. Symbol has been shipping a ruggedized Palm with a built-in barcode scanner for a few months. Handspring signed on as a licensee before they were even called Handspring.
AFAIK, IBM is in more of an OEM deal as far as the actual devices go, but they too are a technology licensee, most notably having provided the de facto standard IrDA syncing software and contributing related code to the extended IR libraries (for dealing with IR pagers and phones, mostly), and some research stuff (bioelectric data transfer) that hasn't gone public yet.
Why not equip a PC with a DVD-RAM drive for recording, and a DVD-ROM drive for playback jimmied open to work with the mechanicals of one of those $250 home-audio 200-CD jukeboxes? Then you'd get 5GB per disk times 200 disks. A terabyte!
Surely a terabyte of, gosh, nice 256-kilobit mp3s is enough for even a/. reader. At 256-kilobit sampling, that's about 8400 hours of music. At the more common but lossier 128 kilobits, it's over 16,000 hours. Yum.
But me, if I needed that 16,000 hours, I'd rather just hook up multiple 200-disk changers to the same computer and stick with the higher sound quality. You could store all your indexing and CDDB playlists on a small $70 hard drive easily.
Didn't anyone else connect the dots? There's a contest kicking off April 26. They're expecting to get a lot of entries, and thus a lot of marketing leads from entries. That means they expect to get a big traffic spike starting on that day.
My counterargument is that having a disk drive, or more precisely a disk-based OS, is what cripples a PC. The "flexibility" of the PC is its biggest problem. Being able to add software and update pieces of the OS and choose how you configure your hardware is what makes PCs unreliable and complex.
Very few people are interested in a PC's flexibility. It just happens to be the only way you can run AOL, Quicken and Word 97. Give someone something with those apps in ROM or on a DVD, and let them save documents on a network or on flashcards, and I swear they'll hug you. And this is the real reason why the next-generation consumer OS from Microsoft isn't going to be NT. It's going to be CE, and Microsoft knows this already.
In order to make a desktop computer truly easy to use and bring maintenance to absolute zero (which is what it should be), you have to stop trying to add layers of software to a PC and rather strip the complex crap away. Leaving a thin device.
If it means less-ugly PCs, fine. But this isn't what the industry needs most.
The general-purpose PC with a disk-based OS is an anachronism. I'm a geek. I like doing geek stuff with a unix machine as much as the next geek.
But the PC, in its 20-year-old recognizable form, is not and never will be an appealing home fixture. Even on a Mac or Windows PC, everyone spends a huge amount of their computing time playing system administrator: running installers, resolving conflicts, cleaning up files, using virus checkers, refreshing the OS, troubleshooting hardware and so forth.
The only reason any non-geek puts up with this is that a PC is the only way you can run Quicken, or a WYSIWYG word processor, or look at big web pages. Nobody likes it. I don't.
Thin clients, NCs, computing appliances, call them whatever you want. They're the future for the vast majority of the things PCs are used for.
You write software? Fine, keep your disk-based PC for a while. But everyone else will be happy, indeed thrilled, to have a diskless workstation running local and remote apps stored on a network. Maybe it will run WinCE. Maybe it'll run an embedded ROM version of Linux, or whatever. But cable modems and DSL will make it possible for the vast majority of people who want to use applications to use them and not become a CompSci minor in order to keep it running.
I'm sick of geeks slagging things like WebTV on the basis of it being limited. Its limitations are its strengths. It can browse 95% of the web, and works with all the public sites anyone really needs (search engines, shopping, news and reference). It can send and receive email. It can read porn newsgroups. It can access IRC.
So much focus is on what it doesn't do: it can't be used to write a print memo. It can't be used to edit graphics. It can't be used to run an Atari 2600 emulator. It can't be used to write C++.
I prefer to focus on the other things it doesn't do or have. It doesn't crash. It doesn't get infected with viruses. It doesn't experience file corruption. It doesn't need security patches. It doesn't require users to install software. It doesn't require an understanding of IRQ conflicts. It doesn't have environment variables.
Expanding what this kind of thing does (and this kind of thing includes Palmpilots, game consoles, and Winframe terminals) in equally clean, simple, foolproof ways is where things need to and will go. Trying to simplify disk-based PCs is futile. Disk-based OSes belong on application servers. Period.
Released-source commercial software is helpful
on
Open Source Windows
·
· Score: 1
This would be the same thing Sun is doing. Windows pricing and runtime/binary licensing wouldn't change. But at least if you're running into a nasty bug, or need to replace an insecure function with a secure one and so forth, you'll be able to.
It's not free beer. It's not free speech. It would, however, mean that IT shops would no longer be hostage to Microsoft's development cycle when they need a feature and need it now.
I do think Released-Source Software is likely to become the norm for most enterprise-scale commercial applications. It makes good sense and makes customers comfortable.
netbeans on the low end
on
Java for EGCS
·
· Score: 1
Netbeans is a very good IDE, itself 100% Java with Swing. But unless something's changed recently, it's only an entry-level IDE.. no versioning integration, no bundled javabeans for JDBC, no servlet debugging, etc. Some of these features are available in controlled betas.
Because of that, it only really competes with the $100 entry-level IDEs, but in that realm it stacks up very well. It's on par with the base versions of Visual Cafe 3 and JBuilder 2.x. Very nice two-way development, a damn fine form painter, Java 2 support, and so forth. Runs like a charm under Linux, too.
There's a high-end version with all the other bells and whistles supposedly on the way, but last time I checked it was vaporware and behind schedule. At least it looks like they made it easier to obtain the beta JDBC support for now.
It's commercialware, but free for personal noncommercial use AFAIK.
'Redhat GNU/Linux' == $weird . $weird . $weird;
on
CDE vs Gnome
·
· Score: 1
You're right. That is odd. I always thought the people who insist on calling the OS "GNU/Linux" all run Debian, save for the ten or so still running Slackware.
And while we're on that, why is KDE with its problematic (free beer) community licensing morally worse than the Motif-based and commercial-only CDE (free nuthin')?
While I like the goals set forth for HTCPCP, the functionailty would be better implemented through simple GET and POST methods and conveying the other directives through XML in the body of the passed file object.
This would allow for greater flexibility in client and server implementations, and would foster interoperability with proposed protocols for teapots, soda machines, beer kegs and drinking fountains.
I know I've been out of schoool for 8 years now, but schools I know of let students drop a class at little or no penalty within the first few sessions.
You'd think that if someone signed up for a class that turned out to be different from what it sounded like, or with a really bad instructor, or broken equipment, it would occur to them to drop it and find something else to take.
I wasn't a CS major. I once signed up for an intro to AI class that supposedly required intro-level programming skills. It was clear the very first day that it was being taught with a much higher assumed background level. So I dropped it.
I should have stuck it through and sued when I got an F. The bastards raised tuition again the following year and the extra cash would have been nice.
The LSB's main thrust is a good one: collaboration between developers and packagers of Linux distributions in order to prevent needless divergence (i.e. keeping apache in/www instead of all over the filesystem, putting smb.conf in/etc, and so forth).
Where the good intentions go a little awry is in trying to make the certification side an all-or-nothing prospect. Such a thing sounds good at first glance, but it works against some of Linux's strengths.
Rearranging things to allow use of an innovative configuation management toolset. Moving, removing or replacing components for security. This should be encouraged. Doing these things doesn't change Linux's openness, though it can create islands of incompatibility. The point is that this kind of differentiation is one of the sources of the good ideas that find their way into all the distribs sooner or later.
Stop this and things stagnate. And then the LSB will implode and you'll have the kind of fragmentation you see in Unix.
There's undeniable value to a label that indicates broad inter-distribution interoperability and common configuration consistency. But under the current model, it's too constricting. What the LSB needs to do is find a mission that balances consensus and standardization without ever being stifling.
One or two might leave over it, but only because they're already sick of the lack of sunlight in Seattle. MS is the biggest game in town over there, and it's a fairly cushy gig if you're not a permatemp. Nice offices, lots of toys and treats.
If they've never done serious C++ or XWindow programming, then at least they won't be able to read the Qt source and risk tainting their clean-room code.
Yes, a legacy desktop app that's printing via OS printing services would need a generalized IPP driver.
But regarding a need for a driver for the end printer, no, the point of IPP is that the operating environment does not need to know the printer's capabilities or have a driver for the printer itself. Rather, I assume they're doing something like the following (and I'd have to read the spec to see if this is exacltly right):
the print request starts by asking the IPP server what kinds of print jobs it accepts
the IPP server responds by stating what kinds of jobs it accepts (postscript, HTML4, HPGL, XML+XSL, plain ASCII, whatever). There's even an opportunity here to offer the client something akin to a printer description file so the client can do optimizations based on available resolution options, etc.
the client decides which of these formats it likes best, and sends the output that way.
In other words, presumably something like HTTP content negotiation, but in reverse.
Over on Oracle Technology Network, the following are available for x86 Linux, all final production releases:
Oracle8 Standard 8.0.5.1
Oracle8 Enterprise 8.0.5.1
Oracle Application Server 3.0.2
Patches to upgrade (preumably from the prelrelease version) of Standard to version 8.0.5.1
It ain't an unsupported beta anymore. And yes, if you're up for 168MB of downloading, you can grab Enterprise to eval from the web. Registration for OTN is free.
Tinkerers with limited bandwidth may want to wait a few more weeks to get 8i.
What I do wish I could find are client installers, minus the server or the major tools. Not every machine I want to put the Net*8 client on has the necessary 450 MB disk space the installer needs to extract all the server stuff. Ah well. Soon.
Raw disk storage is the Right Way for Informix, Sybase and Oracle 7. With Oracle 8, the claim made is that the performance gap between filesystem and raw device access is well under 10% for most uses. Maybe they accomplished this by slowing down raw device access [grin].
As other have pointed out, the answer depends on your situation. Oracle on Linux is probably stable enough and can probably take you easily to the order of 10GB of data (and likely more) without a hint of trouble if set up properly. But is it the sensible choice?
NT's not a good choice for Oracle unless your IT department is unwilling to deal with Unix. Starting on NT with the intention of moving to Unix is not too smart, either. Administration skills from the NT side--to say nothing of backup scripts and the like--don't move to Unix very well.
For an initial Oracle rollout on Unix, the first rule is to go with what you know. If you have HP/UX, use HP/UX. If you have Solaris, use Solaris.
If your company is new to Unix, I'd go with an established Oracle platform, and Solaris is as good (or better) as any; whatever its performace shortcomings, it's usualy the first to get upgrades, it gets all the apps, it runs on big, scary hardware that can make up for a whole lot of slow code, and you can get decent support.
Oracle on Linux seems fine. Oracle wouldn't release it if they didn't think so. Customers running it seem happy. But I'd venture a guess that most production sites deploying it already had expertise with another Oralce-on-Unix platform. If your company has Oracle expertise and real Linux expertise already, you can probably do it with confidence. If not, I'd recommend Solaris as a better way to kick off a deployment of Oracle. It's better-traveled ground.
A little over a week ago, the nightly builds were pretty awful, crashing on Win32 after loading a couple of pages, if that. And the new XPFE widgets(?) just plain didn't work right. From the looks of it, you'd have to conclude the Mozilla project was farther from release code than when it started.
However, the builds of the last couple of days have been eye-openers. If it's not exactly stable, it is running for extended periods of time on my machines and doing better at rendering bad HTML (compliant HTML was never a problem, of course, but what mainstream website is compliant?).
And the new widget stuff is looking snappy, if incomplete. And the whole thing renders about as quickly as IE5, even with all the debug code in place. Something good is going to come of this after all. Eventually.
Given that NS5 is going to hit the mainstream some 6 months after IE5, the two things that work in Mozilla's favor in the long term are
The common codebase and cross-platform consistency. This is what has kept Netscape in the running since IE4 hit. As business apps get built to run in browsers, it's the most-standard browser that wins, not necessarily the best-featured one. As the Linux phenomenon begins to make inroads on the desktop, Netscape's cross-OS fetish will look less like the energy drain it has been and more like a smart strategy.
Its free (as in speech, not beer) nature. An embeddable binary browser helps Microsft build apps. And it helps other developers build apps on Win32 platforms that include the browser's functionns. An embeddable open-source browser, on the other hand, helps developers build apps on any platform, and lets them extend (or restrict) the browser in ways the standard build of it won't let them.
Forget extra legs. Let's eliminate the head, the bones, most internal organs, and the inefficient, irregular shape. Yes, folks, this is the first step toward the ideal: the Vat of Meat.
All the Vat of Meat needs is muscle, a basic circulatory and digestive system, a bit of fat, skin to hold things in (and cook up tasty), and nerves triggered from outside by computerized equipment to give the muscle some tone by making it twitch at regular intervals.
Slashdot Mirror
The Palm's Dragonball processors are in the 68020 family. The Atari STs used its brothers, so a Palm port of GEM can probably be done. However, the rest of the hardware design was probably very different, so how hard this would be may depend on how well the code is organized on the device driver front.
And most existing GEM apps would be a bit awkward in 160x160. But that never stopped anyone.
And unlike the Linux distro for the Palm, GEM should be small enough to fit on a stock Palm Professional, to say nothing of the later models.
GEM is cross-platform. GEM runs fine on a 286 with 512K RAM, not to mention a plain old 68000.
Hey! I know what would be great: a DOS palmtop with Hercules graphics support and IrDA running the DOS GEM version of Ventura Publisher. You could turn it into a handheld print shop and beam PostScript output to IR-capable printers and PCs.
Until I installed some AOL content provider tools on my copy of AOL that WINE chokes on, I'd been running AOL 4.0 for Win95 under WINE for a couple of months.
Apart from modem dialing, font-encoding issues and its lack of a web browser (since it can't use IE), the core AOL client stuff is pretty much at beta quality, at least as far as x86 Unixes goes. Chat, IM, Rainman/VPD forms, and TCP/IP connectivity all work fine.
So between the development momentum WINE has and a motivation to build the core browser engine of Mozilla to release, AOL would have a pretty easy time making a solid AOL 4.0 client for x86 Linux.
I suspect AOL's next direction is going to be toward DHTML and a phase-out of their proprietary content format and rendering technologies. During the transition, for an AOL 5.0 product phase, they could move the Rainman/VPD support to Java, basically turning thr AOL client into "Mozilla + pluggable chat (sound familiar?) + a JVM (from partner Sun)".
Such a creature could run in whole or in parts, using the same codebase everywhere, on anything from a PDA to a screenphone to a PC.
You'll see.
For those of you who missed the page while it was up: the proposal came from Netscape and AOL people, presumably from the instant messaging client product groups.
The proposal did seem to be pretty narrow and a little wrongheaded in its approach, though, and for that deserved to be withdrawn. I suspect this will be coming back after some discussion on the relevant newsgroups. For one thing, there's no reason each IM client has to come bundled with its own UI shell. I might be mistaken, but my quick read of the spec called for each client to bring its own.
AIM and ICQ (and things that present a siumilar UI, like private messages on IRC) could employ a shared UI, and clients that need a modified or different UI could instead subclass it and make use of the relevant bits (like the buddy list or the multiperson chat windows).
Again, if this remains merely a removable module, and is created by people who aren't already working on core browser/editor/mail/news, it seems pleasant enough.
If someone wants to write a generalized, pluggable chat and IM interface, so be it. Nothing wrong with adding hooks for such components as long as it doesn't distract anyone working on the components the browser, editor, mail and news depend on.
Indeed, as long as we're resigned to an understanding that there isn't going to be an NGLayout-based browser in wide, stable release for another year, this sort of thing is actually good for the Mozilla project, since it increases the number of people coding for (and thus familiar with) the Mozilla architecture and APIs.
And who's to say that contributions to tendrils like an AIM, ICQ or IRC client won't bubble up to the browser core? Again, I'd hate to see this take people away from the core, is all.
Why shouldn't they post it as MP3 files? It's not as though Public Enemy has put out five half-decent songs in the years since Fear of a Black Planet came out about ten years ago, and even that was a step down from A Nation of Millions....
In other MP3 "news" regarding David Bowie, you'd likely have to go back to 1983 to find him mattering, unless you're a particularly tone-deaf sort.
Wake me up when someone whose career is still viable goes the MP3 route. I mean, Chuck D's a swell guy, but nobody cares about him anymore.
Qualcomm signed on the better part of a year ago. The pdQ will probably ship in quantity around midyear. Symbol has been shipping a ruggedized Palm with a built-in barcode scanner for a few months. Handspring signed on as a licensee before they were even called Handspring.
AFAIK, IBM is in more of an OEM deal as far as the actual devices go, but they too are a technology licensee, most notably having provided the de facto standard IrDA syncing software and contributing related code to the extended IR libraries (for dealing with IR pagers and phones, mostly), and some research stuff (bioelectric data transfer) that hasn't gone public yet.
Why not equip a PC with a DVD-RAM drive for recording, and a DVD-ROM drive for playback jimmied open to work with the mechanicals of one of those $250 home-audio 200-CD jukeboxes? Then you'd get 5GB per disk times 200 disks. A terabyte!
/. reader. At 256-kilobit sampling, that's about 8400 hours of music. At the more common but lossier 128 kilobits, it's over 16,000 hours. Yum.
Surely a terabyte of, gosh, nice 256-kilobit mp3s is enough for even a
But me, if I needed that 16,000 hours, I'd rather just hook up multiple 200-disk changers to the same computer and stick with the higher sound quality. You could store all your indexing and CDDB playlists on a small $70 hard drive easily.
Didn't anyone else connect the dots? There's a contest kicking off April 26. They're expecting to get a lot of entries, and thus a lot of marketing leads from entries. That means they expect to get a big traffic spike starting on that day.
This means 6.0 ships April 26. You'll see.
My counterargument is that having a disk drive, or more precisely a disk-based OS, is what cripples a PC. The "flexibility" of the PC is its biggest problem. Being able to add software and update pieces of the OS and choose how you configure your hardware is what makes PCs unreliable and complex.
Very few people are interested in a PC's flexibility. It just happens to be the only way you can run AOL, Quicken and Word 97. Give someone something with those apps in ROM or on a DVD, and let them save documents on a network or on flashcards, and I swear they'll hug you. And this is the real reason why the next-generation consumer OS from Microsoft isn't going to be NT. It's going to be CE, and Microsoft knows this already.
In order to make a desktop computer truly easy to use and bring maintenance to absolute zero (which is what it should be), you have to stop trying to add layers of software to a PC and rather strip the complex crap away. Leaving a thin device.
If it means less-ugly PCs, fine. But this isn't what the industry needs most.
The general-purpose PC with a disk-based OS is an anachronism. I'm a geek. I like doing geek stuff with a unix machine as much as the next geek.
But the PC, in its 20-year-old recognizable form, is not and never will be an appealing home fixture. Even on a Mac or Windows PC, everyone spends a huge amount of their computing time playing system administrator: running installers, resolving conflicts, cleaning up files, using virus checkers, refreshing the OS, troubleshooting hardware and so forth.
The only reason any non-geek puts up with this is that a PC is the only way you can run Quicken, or a WYSIWYG word processor, or look at big web pages. Nobody likes it. I don't.
Thin clients, NCs, computing appliances, call them whatever you want. They're the future for the vast majority of the things PCs are used for.
You write software? Fine, keep your disk-based PC for a while. But everyone else will be happy, indeed thrilled, to have a diskless workstation running local and remote apps stored on a network. Maybe it will run WinCE. Maybe it'll run an embedded ROM version of Linux, or whatever. But cable modems and DSL will make it possible for the vast majority of people who want to use applications to use them and not become a CompSci minor in order to keep it running.
I'm sick of geeks slagging things like WebTV on the basis of it being limited. Its limitations are its strengths. It can browse 95% of the web, and works with all the public sites anyone really needs (search engines, shopping, news and reference). It can send and receive email. It can read porn newsgroups. It can access IRC.
So much focus is on what it doesn't do: it can't be used to write a print memo. It can't be used to edit graphics. It can't be used to run an Atari 2600 emulator. It can't be used to write C++.
I prefer to focus on the other things it doesn't do or have. It doesn't crash. It doesn't get infected with viruses. It doesn't experience file corruption. It doesn't need security patches. It doesn't require users to install software. It doesn't require an understanding of IRQ conflicts. It doesn't have environment variables.
Expanding what this kind of thing does (and this kind of thing includes Palmpilots, game consoles, and Winframe terminals) in equally clean, simple, foolproof ways is where things need to and will go. Trying to simplify disk-based PCs is futile. Disk-based OSes belong on application servers. Period.
This would be the same thing Sun is doing. Windows pricing and runtime/binary licensing wouldn't change. But at least if you're running into a nasty bug, or need to replace an insecure function with a secure one and so forth, you'll be able to.
It's not free beer. It's not free speech. It would, however, mean that IT shops would no longer be hostage to Microsoft's development cycle when they need a feature and need it now.
I do think Released-Source Software is likely to become the norm for most enterprise-scale commercial applications. It makes good sense and makes customers comfortable.
Netbeans is a very good IDE, itself 100% Java with Swing. But unless something's changed recently, it's only an entry-level IDE.. no versioning integration, no bundled javabeans for JDBC, no servlet debugging, etc. Some of these features are available in controlled betas.
Because of that, it only really competes with the $100 entry-level IDEs, but in that realm it stacks up very well. It's on par with the base versions of Visual Cafe 3 and JBuilder 2.x. Very nice two-way development, a damn fine form painter, Java 2 support, and so forth. Runs like a charm under Linux, too.
There's a high-end version with all the other bells and whistles supposedly on the way, but last time I checked it was vaporware and behind schedule. At least it looks like they made it easier to obtain the beta JDBC support for now.
It's commercialware, but free for personal noncommercial use AFAIK.
You're right. That is odd. I always thought the people who insist on calling the OS "GNU/Linux" all run Debian, save for the ten or so still running Slackware.
And while we're on that, why is KDE with its problematic (free beer) community licensing morally worse than the Motif-based and commercial-only CDE (free nuthin')?
Don't answer that. Please. Just noticing.
While I like the goals set forth for HTCPCP, the functionailty would be better implemented through simple GET and POST methods and conveying the other directives through XML in the body of the passed file object.
This would allow for greater flexibility in client and server implementations, and would foster interoperability with proposed protocols for teapots, soda machines, beer kegs and drinking fountains.
I know I've been out of schoool for 8 years now, but schools I know of let students drop a class at little or no penalty within the first few sessions.
You'd think that if someone signed up for a class that turned out to be different from what it sounded like, or with a really bad instructor, or broken equipment, it would occur to them to drop it and find something else to take.
I wasn't a CS major. I once signed up for an intro to AI class that supposedly required intro-level programming skills. It was clear the very first day that it was being taught with a much higher assumed background level. So I dropped it.
I should have stuck it through and sued when I got an F. The bastards raised tuition again the following year and the extra cash would have been nice.
The LSB's main thrust is a good one: collaboration between developers and packagers of Linux distributions in order to prevent needless divergence (i.e. keeping apache in /www instead of all over the filesystem, putting smb.conf in /etc, and so forth).
Where the good intentions go a little awry is in trying to make the certification side an all-or-nothing prospect. Such a thing sounds good at first glance, but it works against some of Linux's strengths.
Rearranging things to allow use of an innovative configuation management toolset. Moving, removing or replacing components for security. This should be encouraged. Doing these things doesn't change Linux's openness, though it can create islands of incompatibility. The point is that this kind of differentiation is one of the sources of the good ideas that find their way into all the distribs sooner or later.
Stop this and things stagnate. And then the LSB will implode and you'll have the kind of fragmentation you see in Unix.
There's undeniable value to a label that indicates broad inter-distribution interoperability and common configuration consistency. But under the current model, it's too constricting. What the LSB needs to do is find a mission that balances consensus and standardization without ever being stifling.
One or two might leave over it, but only because they're already sick of the lack of sunlight in Seattle. MS is the biggest game in town over there, and it's a fairly cushy gig if you're not a permatemp. Nice offices, lots of toys and treats.
Nice sentiment, tho.
If they've never done serious C++ or XWindow programming, then at least they won't be able to read the Qt source and risk tainting their clean-room code.
Kidding. Kidding.
But regarding a need for a driver for the end printer, no, the point of IPP is that the operating environment does not need to know the printer's capabilities or have a driver for the printer itself. Rather, I assume they're doing something like the following (and I'd have to read the spec to see if this is exacltly right):
In other words, presumably something like HTTP content negotiation, but in reverse.
It ain't an unsupported beta anymore. And yes, if you're up for 168MB of downloading, you can grab Enterprise to eval from the web. Registration for OTN is free.
Tinkerers with limited bandwidth may want to wait a few more weeks to get 8i.
What I do wish I could find are client installers, minus the server or the major tools. Not every machine I want to put the Net*8 client on has the necessary 450 MB disk space the installer needs to extract all the server stuff. Ah well. Soon.
Raw disk storage is the Right Way for Informix, Sybase and Oracle 7. With Oracle 8, the claim made is that the performance gap between filesystem and raw device access is well under 10% for most uses. Maybe they accomplished this by slowing down raw device access [grin].
As other have pointed out, the answer depends on your situation. Oracle on Linux is probably stable enough and can probably take you easily to the order of 10GB of data (and likely more) without a hint of trouble if set up properly. But is it the sensible choice?
NT's not a good choice for Oracle unless your IT department is unwilling to deal with Unix. Starting on NT with the intention of moving to Unix is not too smart, either. Administration skills from the NT side--to say nothing of backup scripts and the like--don't move to Unix very well.
For an initial Oracle rollout on Unix, the first rule is to go with what you know. If you have HP/UX, use HP/UX. If you have Solaris, use Solaris.
If your company is new to Unix, I'd go with an established Oracle platform, and Solaris is as good (or better) as any; whatever its performace shortcomings, it's usualy the first to get upgrades, it gets all the apps, it runs on big, scary hardware that can make up for a whole lot of slow code, and you can get decent support.
Oracle on Linux seems fine. Oracle wouldn't release it if they didn't think so. Customers running it seem happy. But I'd venture a guess that most production sites deploying it already had expertise with another Oralce-on-Unix platform. If your company has Oracle expertise and real Linux expertise already, you can probably do it with confidence. If not, I'd recommend Solaris as a better way to kick off a deployment of Oracle. It's better-traveled ground.
However, the builds of the last couple of days have been eye-openers. If it's not exactly stable, it is running for extended periods of time on my machines and doing better at rendering bad HTML (compliant HTML was never a problem, of course, but what mainstream website is compliant?).
And the new widget stuff is looking snappy, if incomplete. And the whole thing renders about as quickly as IE5, even with all the debug code in place. Something good is going to come of this after all. Eventually.
Given that NS5 is going to hit the mainstream some 6 months after IE5, the two things that work in Mozilla's favor in the long term are
Forget extra legs. Let's eliminate the head, the bones, most internal organs, and the inefficient, irregular shape. Yes, folks, this is the first step toward the ideal: the Vat of Meat.
All the Vat of Meat needs is muscle, a basic circulatory and digestive system, a bit of fat, skin to hold things in (and cook up tasty), and nerves triggered from outside by computerized equipment to give the muscle some tone by making it twitch at regular intervals.