What kind of rotten grandkid are you? Linux for an 89-year-old computer newcomer? Eek!
Actually, if there were a decent SVGA-mode graphical web browser and a decent simple textmode word processor, I'd be almost okay with this. But there isn't.
But there are both of these things for DOS. Try, say, an old DOS word processor like WordPerfect 5.1 or 6.x for word processing, and Arachne as a web browser.
Then top it off with a few simple *.bat files for the following:
wp: Start the word processor
www: Start the web browser
help: Show this list of commands and change back to the home c:\ directory.
If Linux does take off on the desktop--which won't be in 2000, but may well start in 2001--rest assured a port of IE, followed by a port of Office 2003 if they haven't gone thin-client by then, will come along to fill the "[Microsoft] application void" suffered by Linux.
Its incompatibilities with IE for Win32 and IE for the Mac aside, IE5 for Solaris is a rather good browser--and unlike the Mac IE, it reportedly shares a great deal of code with the Win32 version. It may well only take a couple of developers at MS a few days to get IE5 or its successor up and running on Linux.
Given that IE5 probably shares a great deal under the hood with Office 2000, I suspect Office itself nowadays can move easily to Unix.
The spinoff of Palm into its own publicly-traded company allows it to be nimble.. and makes it ripe for--or vulnerable to--a buyout.
If PalmOS market share holds up for another year, and it may well do so with Handspring making cute models and Palm making corporate ones, and Symbol making vertical-market ones, and Qualcomm making kitchen-sink ones, we may see a AOL/Sun vs. Microsoft bidding war for Palm. Heck, the likes of Sony or Phillips might also be interested.
The IIS-ASP-COM combo may not be a perfect world, especially at the MTS layer, but you can't say it isn't usable at the high end. I'm sure Dell, barnesandnoble.com and the major MSN affiliates would be surprised to hear that you can't build some typical types of high-volume dynamic sites with it.
Sure, the range of scaling, clustering and load-balancing approaches you can take are constrained and sometimes not pretty, but that's not the same as saying there aren't any. And presenting a seamless 24/7 face to the world may require more sweat, but there are sites that manage it, give or take a few multi-hour outages (salve Web TurboTax).
No, I probably wouldn't do a 100%-Microsoft realtime airline ticketing system, or something involving terabytes of filesystem storgae (read: Hotmail). Nor would I recommend it to a company that sets very high uptime requirements, or to any company that doesn't already have a very high NT committment in place. But even though it invites some headaches, a shop that has a heavy investment in NT infrastructure and skills and nothing on the Unix side can often do what it needs with the MS approach, as long as you understand there are brick walls you will run into if you try to do certain things.
[N.B.: Yes, I know much of Web Turbotax was built largely out of ISAPI DLLs, not so much with ASP and MTS.. but the most notorious outage they had was elsewhere.]
As with Zope, this looks like a perfectly fine product that may well be usable for some very good high-volume systems. But as with Zope, it's also a latecomer to a field of products that are on their way out.
This sounds similar in developer feng shui to Intershop: all-in-one sitebuilding system, based on Perl, built for quick setup or involved customization.
Thing is, as Zope's creators can tell you of their Storyserver-cousin, and as Groupe Bull can tell you of their low-end EJB app server, sometimes you realize you're trailing the market and the only things you can do are close up shop and call it a day, or give away the product and sell support and consulting.
Nowadays, the hot technologies in three-tier high end sites are EJB+JSP app servers and/or the ASP+COM combo. In (mostly two-tier) smaller projects, the cresting environments are PHP and Cold Fusion.
I did some looking around, and I'm convinced now that a high-end EJB + CORBA + JSP app server comparable to a Weblogic, Dynamo, Websphere, etc. can be built out of parts with GPL, BSD, and similar licenses. It mostly looks like a matter of choosing a baseline set of components and writing glue scripts to facilitate install and configuration of the critter.
The writer only really went through the install process once! And it worked! Hell, the first time I installed Linux back in 1995, after a year of Solaris expeience and with some serious geek credentials, it took me two whole weekends to get it more or less running.
And as nasty as the process is (take note here, geeks: there's too much jargon in even Caldera's installer!), it doesn't sound all that much worse than installing NT 4.0. There are good lessons here.
For all the writer's sarcasm and suffering, I'd say Caldera deserves some quiet applause. And--oh-yeah--all distro maintainers should take note; say it along with me: there's too much jargon in installers.
And fer chrissakes, the warning about XF86 autoprobe damaging hardware really isn't necessary, is it? Sure, it's correct, but friggin' DirectX autoprobes and you don't see it warning anyone of peril. We're such pedants, us Linux folk.
Sendmail Pro isn't news, of course, but it seems a bit sad, not to mention frustrating, that it came about the way it did.
The way I was taught in history class, Eric Allman's been the lead maintainer of sendmail for years, and has overseen it through a half dozen or so major redesigns of the config file formats, each more complex than the last, bringing it to where it's been for a while now.
Now, sendmail.cf is so painful that there are sysadmins who make a living doing nothing but sendmail configs, what with the same file having sections that are space-delimited, and others that are tab-delimited, several macro languages, several variable-assignment syntaxes, and so forth, to the point where one is supposed to write m4 macros to generate these monstrosities.
I'm not knocking sendmail's flexibility so much as what comes to look like a willful contempt for usability issues, especially when it appears the same folks behind the tangle of sendmail had no problem at all putting a clean, pleasant config toolset together once they decided to make that the distinguishing feature of their commercial version.
I'm torn on what to think of this. On the basis of the work he's done for years on sendmail, Eric Allman deserves a nice house in the hills, an expensive car, and maybe even a wine cellar and an attentive stockbroker.
But I can't help but think it might have been more sporting to release even the pretty admin interfaces under the BSD license, and build a business around support, training, certification, professional services, and so forth.
I wish the guy well, except maybe when I'm busy ripping out my hair wrestling with sendmail configuration.
As others have noted, SSNs as student ID numbers aren't anything new. The University of Michigan, for one, was using them more than 10 years ago, with the addition of a check digit. In plaintext. Embossed or printed on cards.
...and instructors often posted them on sheets outside classrooms for students to look up their grades on exams.
...and they had to be filled in on myriad forms, and on quizzes, and on papers, and on scan grids, and on blue books--with names.
Corel's been in a tailspin for years. They can't market their way out of a paper bag. They've taken the once-proud WordPerfect and Ventura brands and despite decent engineering to this day, have made them synonymous with amateurish shovelware through kitchen-sink bundling and cheap, ugly advertising.
Corel Linux will likely be a highly refined, high-quality product; their proprietary admin tools will probably be lovely. But it's going to be sold by Corel.
PHP's nifty, but the trend is away from loading business logic and presentation logic onto the same layer, as PHP and Cold Fusion both generally do. Cold Fusion has been moving toward a 3-tier approach with the addition of a separate app server, but it's not really there yet in terms of being able to run on separate hardware and having intelligent failover at the middle tier.
This is where in the NT world the typical scenario of hosting COM objects on something like MTS comes in, and ASP or Cold Fusion in front of it.I've heard it doesn't work thrillingly well in some cases, especially when you're trying to host Java COM objects, but the approach is right and there are ways to make this work well.
The usual platform-independent approach is to use a CORBA (for C++ or Java) or EJB (Java) app server, or at least plain old Java Servlets, which does essentially the same thing, typically with JSP for the presentation scripting layer. One nice thing about JSP is that they compile to Java bytecode and run very fast indeed.
Yes, you can run ASPs on a number of Unixes, Cold Fusion on Solaris (and gosh, don't they have a Java implementation of their server piece now?). And a number of Unix-family OSes can also host and/or access COM objects, though they won't magically have access to Win32 APIs.
And yes, the JSP/Servlet/EJB/CORBA approaches work very well indeed on NT as well as Unixes, with most of the higher-end app server vendors all abandoning their proprietary technologies and standardizing on this set of technologies these days.. See Broadvision, BEA Weblogic, ATG, Sun NetDynamics, Netscape Appserver, and IBM WebSphere for just some examples of the vendors doing this. It's mighty compelling.
On the low-end, getting started with the JSP/servlet combo can be very inexpensive and very stable indeed on any OS. There are free servlet engines (which you can use to connect to CORBA and COM objects without much fuss) for all the popular webservers, free JSP environments that can sit on the servlet engines, and many choices for getting into EJB and CORBA, from free (albeit sometimes not ready for wide use) to commercial (industrial strength). The great part about this is that you end up with code at each layer that runs fast and is extremely portable to and between the most scalable and bulletproof app servers around.
As for commercial RAD tools, you may want to look into a new version of Drumbeat that generates JSP instead of ASP. And most modern Java IDEs make for great EJB and servlet development environments.
Can't speak for the forthcoming PHP4. It may come closer to this sort of thing.
One thing to say in PHP3's favor is that some pretty large and high-volume sites do use it, though the heavy-traffic ones probably have the nastier logic on a middl tier or as stored procedures in the database.
Last time I checked, gcc was still very much available on NT along with most of the core GNU tools, a couple of commercial ports of sendmail on NT were available, and the Qt widget set worked very well indeed on NT, albeit not as part of a window manager and desktop environment. (And by the way, NT4's DNS services are provided by a registry-aware BIND, if I recall.)
Seems like this is a neat and clever way for MS to smooth their transition from NT to a Un*x-family OS for application servers.
Step 1: Offer an environment for running Unix-style apps under Windows 2000.
Step 2: Spend the next couple of years migrating or converting core server apps (IIS, Exchange, Active Directory) to the Unix-like side, in some cases replacing them with customized, MS-branded versions of Apache, OpenLDAP, etc. Elevate this layer to full parity with Win32 from a support standpoint.
Step 3: New release of disk-based NT with a true BSD or Linux kernel at its core, completing the transition to MS-branded Unix. Run "legacy" apps in an emulation layer, possibly even WINE or its successor. Reassign the thousands of engineers who have been previously occupied with the economically dubious task of writing and maintaining a proprietary OS core.
Seeing as overall system speeds double every 18 months, a 2GHz new-generation PPC chip, probably running on a "brand new" 200MHz bus at launch, sounds about right two years from now.
If it's going to be sold as a high-end workstation/server CPU, it should benchmark about 2.6 times faster than the high-end Alpha. If it's going to come out at the mainstream price point, figure on it benchmarking 2.6 times faster than an Athlon 650.
Wake me up when Moore's Law finally breaks. Looks like it still has legs. And no, the zippy faster-bus Mac G4/500s won't do it when they ship in a month or two. Certainly not at twice the price of an Intel box.
When I got the 2nd edition of Running Linux, I was still running the friggin' Yggdrassil distro on a 486 that dual-booted to Win3.1. Yggdrassil, fer chrissakes.
The 2nd Edition is so out of date that I've had to recommend those sad Que and SAMS books to newcomers. At least they're aware of most of the newer apps and nifty admin tools that have come along during the last few years. Enough of that. Viva the Third Edition. It'll be nice to have a modern book that isn't shovelware and isn't tied to one version of one distro.
Cheap PCs are cheap up front. The thing is, the hardware cost is nothing compared to the cost of maintaining the things. Sure, a well-managed *nix workstation is easier to manage than an NT box under SMS or Tivoli, which is easier to manage than a Mac, which is easier to manage than a Win95/98 PC.
But all of these things, with their varying hardware, their local filesystems, and in too many cases their local apps and OS, are a total money pit compared to running thin clients, whether they're pure terminals, or something with local CPU but no local disk-based apps and data, like this.
Past NC attempts have been underpowered, and viable apps outside vertical markets have been few. But at some point, large businesses will be more than ready for the right thin-client machines.
Besides, our own/. testosterone-fueled lust for playing with computer guts isn't shared by most people, nor will it ever be. Nor should it. Most people want nothing more than a foolproof, zero-maintenance way to run a range of general-interest apps. Sooner or later, the PC as we know it is going to become something only developers and hackers will want. Everyone else will be perfectly happy to plug away on a ROM-based box with high-speed net connectivity.
Will Sun Ray succeed? Ehh. The odds are certainly against it. Will something like it succeed in the next couple of years? Yup.
No, it's not Open Source(TM), but it is an office suite with source code available. So no, the source code can't be swallowed into other projects, and no, StarOffice can't become part of the GNU Hurd kernel.
But companies and institutions looking for an office suite they can audit for security, lock down features on, and that lets them take fixing bugs into their own hands, will have something they could well be happy with.
Whine, whine, whine. StarOffice would be pretty hard to GPL even if Mr, McNealy smoked something funny and decided to do it. The file conversion filters, for example, are the same commercial ones everyone licenses from Inso. And the VBA scripting engine under it is probably 3rd-party, too.
And once you rip out the 3rd-party commercial stuff, I'm sure we'd hear no end to the whining about the proprietary GUI toolkit it's built with.
You want a free office suite? Go work on KOffice. It seems to have potential. Don't like the Qt license? Then go work on AbiWord and Gnumeric or something. Stop begging for table scraps.
I hear Collas is heading to the new Atari Computer, a division of SGI that will be using intellectual property from the 400/800/XL/XE series, the revolutionary "poor man's Mac" ST series, and the mighty Jaguar to make a new 4-processor system, each processor completely different from the others.
It's going to be amazing stuff. They've been demoing a prototype running a new version of Star Raiders at 1600x1280 on stereoscopic goggles. It's fully immersive, especially if you use the full-body tactile suit.
See, the new Amiga's going to be a handheld designed by super-secret startup Handspring, running multiple versions of Linux on a Transmeta CPU emulating an Athlon, an Alpha, a StrongARM, a G4 PPC, a 68060 and a MIPS simultaneously.
But seriously. Gateway is funding this new Amiga project, so the idea of them shipping a series of low-power handhelds, tablets, set-top boxes and whatnot running a locked-down, embedded Linux kernel with custom GUIs and a suite of net-centric apps is certainly possible, and clearly has nothing to do with "classic" Amigas apart perhaps from a few nifty ideas for the A/V subsystem.
Isn't the Amiga name a liability? Shouldn't they just use the patents they want and come up with a name that isn't so synonymous with (a) market failure and (b) a community of babbling loons? Amigas were swell 12-15 years ago.
Right on schedule, an Intel price cut to coincide with the rollout of machines with AMD's latest processor. It's so routine by now that companies probably plan their Intel-based hardware budgets based on AMD chip rollout timetables.
Given what this sort of price cutting does to spur PC sales, it's probably in software companies' interest to throw money at AMD to prop them up for a few more years just to keep the pressure on Intel.
One good thing about this is that Sun's programmers, and indeed, any programmers besides Stardivision's, know how to write shared libraries. Maybe we'll see some componentization of the code so StarOffice 6 won't need 40MB of contiguous RAM just to blow its nose.
In the meantime, the Java thin-client front end to the Unix version fits well into Sun's thin desktop roadmap.
This is like the radar detector detectors police started using a few years ago.
Old macs are pretty just sitting there
on
High Tech Junk
·
· Score: 1
At work I have 9 Mac Classic IIs stacked on my desk. They're like sculpture. They're soothing to look at, what with that playful smirk the of the floppy drive and that sort of wide-eyed toddler look of the overall design.
A Palm Pilot ~== Mac Classic II
on
High Tech Junk
·
· Score: 1
The Palms have a 680x0-class CPU running at 16MHz, which makes them more or less similar to, say, a later Mac II, a Classic II, or SE/30. So, no. That old machine isn't ten tims more powerful, unless, say, it's a Pentium or some such.
For one thing, the AIM protocols were published but kept proprietary. TiK, GAIM and all the other alternative AIM clients were bound by a restrictive license on use of the protocol. Mozilla, on the other hand, is protected by a self-protecting open license much in the same way as GNU software.
Secondly, AOL's main intent behind the temporary withdrawl of the open-source AIM clients is to impose order on what has been lax enforcement of their license terms in recent months. Besides the perhaps peevish restriction on misuse of the protocol for cracking and address-harvesting apps, AOL has a perfectly valid interest in preserving their ad-revenue stream on the mainstream clients. A few thousand Unix users running adless (and kinda crappy) clone clients without ads is harmless and keeps hackers happy. Mass-market clones that do so and insert their own ads (see MSN Messenger) are another story.
Slashdot Mirror
Actually, if there were a decent SVGA-mode graphical web browser and a decent simple textmode word processor, I'd be almost okay with this. But there isn't.
But there are both of these things for DOS. Try, say, an old DOS word processor like WordPerfect 5.1 or 6.x for word processing, and Arachne as a web browser.
Then top it off with a few simple *.bat files for the following:
You get the idea. I hope.
If Linux does take off on the desktop--which won't be in 2000, but may well start in 2001--rest assured a port of IE, followed by a port of Office 2003 if they haven't gone thin-client by then, will come along to fill the "[Microsoft] application void" suffered by Linux.
Its incompatibilities with IE for Win32 and IE for the Mac aside, IE5 for Solaris is a rather good browser--and unlike the Mac IE, it reportedly shares a great deal of code with the Win32 version. It may well only take a couple of developers at MS a few days to get IE5 or its successor up and running on Linux.
Given that IE5 probably shares a great deal under the hood with Office 2000, I suspect Office itself nowadays can move easily to Unix.
The spinoff of Palm into its own publicly-traded company allows it to be nimble.. and makes it ripe for--or vulnerable to--a buyout.
If PalmOS market share holds up for another year, and it may well do so with Handspring making cute models and Palm making corporate ones, and Symbol making vertical-market ones, and Qualcomm making kitchen-sink ones, we may see a AOL/Sun vs. Microsoft bidding war for Palm. Heck, the likes of Sony or Phillips might also be interested.
The IIS-ASP-COM combo may not be a perfect world, especially at the MTS layer, but you can't say it isn't usable at the high end. I'm sure Dell, barnesandnoble.com and the major MSN affiliates would be surprised to hear that you can't build some typical types of high-volume dynamic sites with it.
Sure, the range of scaling, clustering and load-balancing approaches you can take are constrained and sometimes not pretty, but that's not the same as saying there aren't any. And presenting a seamless 24/7 face to the world may require more sweat, but there are sites that manage it, give or take a few multi-hour outages (salve Web TurboTax).
No, I probably wouldn't do a 100%-Microsoft realtime airline ticketing system, or something involving terabytes of filesystem storgae (read: Hotmail). Nor would I recommend it to a company that sets very high uptime requirements, or to any company that doesn't already have a very high NT committment in place. But even though it invites some headaches, a shop that has a heavy investment in NT infrastructure and skills and nothing on the Unix side can often do what it needs with the MS approach, as long as you understand there are brick walls you will run into if you try to do certain things.
[N.B.: Yes, I know much of Web Turbotax was built largely out of ISAPI DLLs, not so much with ASP and MTS.. but the most notorious outage they had was elsewhere.]
Mmmm, pretty nice.
As with Zope, this looks like a perfectly fine product that may well be usable for some very good high-volume systems. But as with Zope, it's also a latecomer to a field of products that are on their way out.
This sounds similar in developer feng shui to Intershop: all-in-one sitebuilding system, based on Perl, built for quick setup or involved customization.
Thing is, as Zope's creators can tell you of their Storyserver-cousin, and as Groupe Bull can tell you of their low-end EJB app server, sometimes you realize you're trailing the market and the only things you can do are close up shop and call it a day, or give away the product and sell support and consulting.
Nowadays, the hot technologies in three-tier high end sites are EJB+JSP app servers and/or the ASP+COM combo. In (mostly two-tier) smaller projects, the cresting environments are PHP and Cold Fusion.
I did some looking around, and I'm convinced now that a high-end EJB + CORBA + JSP app server comparable to a Weblogic, Dynamo, Websphere, etc. can be built out of parts with GPL, BSD, and similar licenses. It mostly looks like a matter of choosing a baseline set of components and writing glue scripts to facilitate install and configuration of the critter.
The writer only really went through the install process once! And it worked! Hell, the first time I installed Linux back in 1995, after a year of Solaris expeience and with some serious geek credentials, it took me two whole weekends to get it more or less running.
And as nasty as the process is (take note here, geeks: there's too much jargon in even Caldera's installer!), it doesn't sound all that much worse than installing NT 4.0. There are good lessons here.
For all the writer's sarcasm and suffering, I'd say Caldera deserves some quiet applause. And--oh-yeah--all distro maintainers should take note; say it along with me: there's too much jargon in installers.
And fer chrissakes, the warning about XF86 autoprobe damaging hardware really isn't necessary, is it? Sure, it's correct, but friggin' DirectX autoprobes and you don't see it warning anyone of peril. We're such pedants, us Linux folk.
Sendmail Pro isn't news, of course, but it seems a bit sad, not to mention frustrating, that it came about the way it did.
The way I was taught in history class, Eric Allman's been the lead maintainer of sendmail for years, and has overseen it through a half dozen or so major redesigns of the config file formats, each more complex than the last, bringing it to where it's been for a while now.
Now, sendmail.cf is so painful that there are sysadmins who make a living doing nothing but sendmail configs, what with the same file having sections that are space-delimited, and others that are tab-delimited, several macro languages, several variable-assignment syntaxes, and so forth, to the point where one is supposed to write m4 macros to generate these monstrosities.
I'm not knocking sendmail's flexibility so much as what comes to look like a willful contempt for usability issues, especially when it appears the same folks behind the tangle of sendmail had no problem at all putting a clean, pleasant config toolset together once they decided to make that the distinguishing feature of their commercial version.
I'm torn on what to think of this. On the basis of the work he's done for years on sendmail, Eric Allman deserves a nice house in the hills, an expensive car, and maybe even a wine cellar and an attentive stockbroker.
But I can't help but think it might have been more sporting to release even the pretty admin interfaces under the BSD license, and build a business around support, training, certification, professional services, and so forth.
I wish the guy well, except maybe when I'm busy ripping out my hair wrestling with sendmail configuration.
As others have noted, SSNs as student ID numbers aren't anything new. The University of Michigan, for one, was using them more than 10 years ago, with the addition of a check digit. In plaintext. Embossed or printed on cards.
...and instructors often posted them on sheets outside classrooms for students to look up their grades on exams.
...and they had to be filled in on myriad forms, and on quizzes, and on papers, and on scan grids, and on blue books--with names.
Corel's been in a tailspin for years. They can't market their way out of a paper bag. They've taken the once-proud WordPerfect and Ventura brands and despite decent engineering to this day, have made them synonymous with amateurish shovelware through kitchen-sink bundling and cheap, ugly advertising.
Corel Linux will likely be a highly refined, high-quality product; their proprietary admin tools will probably be lovely. But it's going to be sold by Corel.
PHP's nifty, but the trend is away from loading business logic and presentation logic onto the same layer, as PHP and Cold Fusion both generally do. Cold Fusion has been moving toward a 3-tier approach with the addition of a separate app server, but it's not really there yet in terms of being able to run on separate hardware and having intelligent failover at the middle tier.
This is where in the NT world the typical scenario of hosting COM objects on something like MTS comes in, and ASP or Cold Fusion in front of it.I've heard it doesn't work thrillingly well in some cases, especially when you're trying to host Java COM objects, but the approach is right and there are ways to make this work well.
The usual platform-independent approach is to use a CORBA (for C++ or Java) or EJB (Java) app server, or at least plain old Java Servlets, which does essentially the same thing, typically with JSP for the presentation scripting layer. One nice thing about JSP is that they compile to Java bytecode and run very fast indeed.
Yes, you can run ASPs on a number of Unixes, Cold Fusion on Solaris (and gosh, don't they have a Java implementation of their server piece now?). And a number of Unix-family OSes can also host and/or access COM objects, though they won't magically have access to Win32 APIs.
And yes, the JSP/Servlet/EJB/CORBA approaches work very well indeed on NT as well as Unixes, with most of the higher-end app server vendors all abandoning their proprietary technologies and standardizing on this set of technologies these days.. See Broadvision, BEA Weblogic, ATG, Sun NetDynamics, Netscape Appserver, and IBM WebSphere for just some examples of the vendors doing this. It's mighty compelling.
On the low-end, getting started with the JSP/servlet combo can be very inexpensive and very stable indeed on any OS. There are free servlet engines (which you can use to connect to CORBA and COM objects without much fuss) for all the popular webservers, free JSP environments that can sit on the servlet engines, and many choices for getting into EJB and CORBA, from free (albeit sometimes not ready for wide use) to commercial (industrial strength). The great part about this is that you end up with code at each layer that runs fast and is extremely portable to and between the most scalable and bulletproof app servers around.
As for commercial RAD tools, you may want to look into a new version of Drumbeat that generates JSP instead of ASP. And most modern Java IDEs make for great EJB and servlet development environments.
Can't speak for the forthcoming PHP4. It may come closer to this sort of thing.
One thing to say in PHP3's favor is that some pretty large and high-volume sites do use it, though the heavy-traffic ones probably have the nastier logic on a middl tier or as stored procedures in the database.
exactly.
Last time I checked, gcc was still very much available on NT along with most of the core GNU tools, a couple of commercial ports of sendmail on NT were available, and the Qt widget set worked very well indeed on NT, albeit not as part of a window manager and desktop environment. (And by the way, NT4's DNS services are provided by a registry-aware BIND, if I recall.)
Seems like this is a neat and clever way for MS to smooth their transition from NT to a Un*x-family OS for application servers.
Step 1: Offer an environment for running Unix-style apps under Windows 2000.
Step 2: Spend the next couple of years migrating or converting core server apps (IIS, Exchange, Active Directory) to the Unix-like side, in some cases replacing them with customized, MS-branded versions of Apache, OpenLDAP, etc. Elevate this layer to full parity with Win32 from a support standpoint.
Step 3: New release of disk-based NT with a true BSD or Linux kernel at its core, completing the transition to MS-branded Unix. Run "legacy" apps in an emulation layer, possibly even WINE or its successor. Reassign the thousands of engineers who have been previously occupied with the economically dubious task of writing and maintaining a proprietary OS core.
Seeing as overall system speeds double every 18 months, a 2GHz new-generation PPC chip, probably running on a "brand new" 200MHz bus at launch, sounds about right two years from now.
If it's going to be sold as a high-end workstation/server CPU, it should benchmark about 2.6 times faster than the high-end Alpha. If it's going to come out at the mainstream price point, figure on it benchmarking 2.6 times faster than an Athlon 650.
Wake me up when Moore's Law finally breaks. Looks like it still has legs. And no, the zippy faster-bus Mac G4/500s won't do it when they ship in a month or two. Certainly not at twice the price of an Intel box.
When I got the 2nd edition of Running Linux, I was still running the friggin' Yggdrassil distro on a 486 that dual-booted to Win3.1. Yggdrassil, fer chrissakes.
The 2nd Edition is so out of date that I've had to recommend those sad Que and SAMS books to newcomers. At least they're aware of most of the newer apps and nifty admin tools that have come along during the last few years. Enough of that. Viva the Third Edition. It'll be nice to have a modern book that isn't shovelware and isn't tied to one version of one distro.
Cheap PCs are cheap up front. The thing is, the hardware cost is nothing compared to the cost of maintaining the things. Sure, a well-managed *nix workstation is easier to manage than an NT box under SMS or Tivoli, which is easier to manage than a Mac, which is easier to manage than a Win95/98 PC.
/. testosterone-fueled lust for playing with computer guts isn't shared by most people, nor will it ever be. Nor should it. Most people want nothing more than a foolproof, zero-maintenance way to run a range of general-interest apps. Sooner or later, the PC as we know it is going to become something only developers and hackers will want. Everyone else will be perfectly happy to plug away on a ROM-based box with high-speed net connectivity.
But all of these things, with their varying hardware, their local filesystems, and in too many cases their local apps and OS, are a total money pit compared to running thin clients, whether they're pure terminals, or something with local CPU but no local disk-based apps and data, like this.
Past NC attempts have been underpowered, and viable apps outside vertical markets have been few. But at some point, large businesses will be more than ready for the right thin-client machines.
Besides, our own
Will Sun Ray succeed? Ehh. The odds are certainly against it. Will something like it succeed in the next couple of years? Yup.
No, it's not Open Source(TM), but it is an office suite with source code available. So no, the source code can't be swallowed into other projects, and no, StarOffice can't become part of the GNU Hurd kernel.
But companies and institutions looking for an office suite they can audit for security, lock down features on, and that lets them take fixing bugs into their own hands, will have something they could well be happy with.
Whine, whine, whine. StarOffice would be pretty hard to GPL even if Mr, McNealy smoked something funny and decided to do it. The file conversion filters, for example, are the same commercial ones everyone licenses from Inso. And the VBA scripting engine under it is probably 3rd-party, too.
And once you rip out the 3rd-party commercial stuff, I'm sure we'd hear no end to the whining about the proprietary GUI toolkit it's built with.
You want a free office suite? Go work on KOffice. It seems to have potential. Don't like the Qt license? Then go work on AbiWord and Gnumeric or something. Stop begging for table scraps.
I hear Collas is heading to the new Atari Computer, a division of SGI that will be using intellectual property from the 400/800/XL/XE series, the revolutionary "poor man's Mac" ST series, and the mighty Jaguar to make a new 4-processor system, each processor completely different from the others.
It's going to be amazing stuff. They've been demoing a prototype running a new version of Star Raiders at 1600x1280 on stereoscopic goggles. It's fully immersive, especially if you use the full-body tactile suit.
See, the new Amiga's going to be a handheld designed by super-secret startup Handspring, running multiple versions of Linux on a Transmeta CPU emulating an Athlon, an Alpha, a StrongARM, a G4 PPC, a 68060 and a MIPS simultaneously.
But seriously. Gateway is funding this new Amiga project, so the idea of them shipping a series of low-power handhelds, tablets, set-top boxes and whatnot running a locked-down, embedded Linux kernel with custom GUIs and a suite of net-centric apps is certainly possible, and clearly has nothing to do with "classic" Amigas apart perhaps from a few nifty ideas for the A/V subsystem.
Isn't the Amiga name a liability? Shouldn't they just use the patents they want and come up with a name that isn't so synonymous with (a) market failure and (b) a community of babbling loons? Amigas were swell 12-15 years ago.
Right on schedule, an Intel price cut to coincide with the rollout of machines with AMD's latest processor. It's so routine by now that companies probably plan their Intel-based hardware budgets based on AMD chip rollout timetables.
Given what this sort of price cutting does to spur PC sales, it's probably in software companies' interest to throw money at AMD to prop them up for a few more years just to keep the pressure on Intel.
...have you ever used StarOffice?
In the meantime, the Java thin-client front end to the Unix version fits well into Sun's thin desktop roadmap.
This is like the radar detector detectors police started using a few years ago.
At work I have 9 Mac Classic IIs stacked on my desk. They're like sculpture. They're soothing to look at, what with that playful smirk the of the floppy drive and that sort of wide-eyed toddler look of the overall design.
The Palms have a 680x0-class CPU running at 16MHz, which makes them more or less similar to, say, a later Mac II, a Classic II, or SE/30. So, no. That old machine isn't ten tims more powerful, unless, say, it's a Pentium or some such.
For one thing, the AIM protocols were published but kept proprietary. TiK, GAIM and all the other alternative AIM clients were bound by a restrictive license on use of the protocol. Mozilla, on the other hand, is protected by a self-protecting open license much in the same way as GNU software.
Secondly, AOL's main intent behind the temporary withdrawl of the open-source AIM clients is to impose order on what has been lax enforcement of their license terms in recent months. Besides the perhaps peevish restriction on misuse of the protocol for cracking and address-harvesting apps, AOL has a perfectly valid interest in preserving their ad-revenue stream on the mainstream clients. A few thousand Unix users running adless (and kinda crappy) clone clients without ads is harmless and keeps hackers happy. Mass-market clones that do so and insert their own ads (see MSN Messenger) are another story.