Apart from the redraw problems, the sloppy interface design, the godawful ergonomics, the slow response times on a PII/400, the counterintuitive bundled widgets and the poor "integration" with GNOME, E sure is coming along.
I want to like it, I really do. I want GNOME and E to be a better high-usability desktop than KDE because Qt dependence is Wrong and GPL widget libraries are Right.
But it's Just Not Usable. Stability will come. Speed probably will, too. But someone should have shooed a few cooks out of the kitchen when it came to design, because it's a mess in there.
KDE is bland. KDE is Bad for Free Software. KDE is breathtakingly, unambiguously, seamlessly usable in a way that no Unix GUI has ever been. Not NeXT, not CDE, not nothing.
Is one big big piece of iron really the best way to demonstrate Linux scalability? Maybe the next step is to distribute the processing load, perhaps by putting the logic on ORBs on separate machines and making your (perl, php3, servlets, whatever) real thin.
You silly person. The Hawkins-Dubinsky team designed the IIIx, the V and the VII (and probably a forthcoming VI) and probably anything else in the pipeline for 1999.
How could these be evidence of stagnation when the designs had to be far enough along to be sent off to manfacturing months ago?
The Palms are appliances, and unlike Wince devices are designed to absolutely positively
Fit in a shirt pocket
Run 6 weeks on a set of batteries
Be so easy to use that a nontechnical consumer can be entering names and addresses within 15 minutes of tearing open the box.
The extra features the naysayers want are generally not necessary or terribly useful for even a power user. Voice recording without transcription? Richtext wordprocessing? Animation support? Frames-capable web browser? Color?
Any of these would be nice, but with the possible exception of color, they run counter to the Palm devices' mission: to replace a Filofax.
The Palm V offers no reason for a Palm III-level user to upgrade, but heck, my Personal upgraded to a Pro upgraded to a III does its job just fine. As a corporate web app developer, the only PDA around that really offers something new and compelling is the forthcoming Palm VII. If you're an end user, it looks expensive and limited. If you're a developer interested in roaming field apps, it's exciting as all hell.
As HTML 4.0 (and soon XML+XSL) goes mainstream, they're becoming a universal UI toolkit; a growing number of apps are being written to run under MSIE4 with the expectation that 5.0-generation browsers will have as-good-or-better capabilities as a universal application frontend.
One big thing missing is the lack of embeddable media players for Unix in general and Linux too. Standalone, helper-app audio and video players are a start, but they need to be embeddable, whether via plugins, signed Java applet wrappers or <SMIRK>ActiveX controls</SMIRK>. That goes for streaming media, AVI, quicktime and MPEG alike. It's got to happen or a lot of the new generation of browser-based, theoretically cross-platform apps won't work.
BeOS's fate was sealed when Apple walked away from the buyout negotiations with Be and bought NeXT instead.
Hardware is cheap. Nobody cares about squeezing maximum efficiency from a single- or dual-CPU workstation. If they did, the Macintosh, with its zero-scalabiliity, not-quite-multitasking desktop OS would be dead as a doornail by now. It's not.
Very few people currently care about having a desktop OS that has high uptime, and fewer need one. Those that do already use Unix-family OSes. And by "care", I mean care enough to be willing to switch to something with less software.
Most open-source developers dislike the work required to keep their software compatible with multiple non-Unixy OSes. Some software gets ported--eventually--to OS/2 and NT. But most never does. BeOS is just as far removed from Unixen, in ways that are different from both.
The fact is, the artists and musicians that psychopath Gasse claims he's targeting don't give a damn about (and seldom know about) the internals of their OS. They just want to get their work done, which means they need apps and they need ease of use.
First, apps:
With MIDI connectivity standard on 99% of all x86-compatible desktop machines made in the past 6 years and hardly rocket science on Macs, what does BeOS bring to the table besides a lack of software apart from a few shareware-quality titles? What musician is going to choose an OS that can't run any of the top ten sequencing, patch-library and compositional tools?
Now, ease of use:
Why is the Mac so popular in design and music? Because Macs are generally maintainable by an artist or musician, and so many designers and musicians work solo out of home or in freelance situations. Sure, techies who also make music use Unix and Windows. But apart from them, when you see an artist using a Unix or NT workstation, chances are they're working in an office setting with a dedicated IT staff to shield them from most of the necessary system maintennce tasks.
The probem with BeOS is its premise: that the Mac end-user community is crying out for a technologically superior desktop OS core to run the same GUI, the same hardware and the same kinds of apps they already use. What malarkey. They just want an applicance that works, and they've got one already. Linux, user-hostility and all, has better prospects in this market than BeOS because the developer community is so much larger and more diverse. Check back in two years. BeOS may still be around thanks to Gasse's checking account, but it won't have more than 200,000 active users.
Those sure are pretty config tools they've got there, but they don't look one bit "easier" or "friendlier" than Red Hat's less-glamorous, but clean and clear color textmode installation.
I think their interface approach is a nice one, but it looks to me like it will still only address the technical market of people who know what video chipset they have and why they're partitioning drives in the first place. Seems more an equivalent to the pretty GUI installer Solaris has these days. Still no substitute for knowing some pretty gritty hardware details.
No, to have a consumer, home-user Linux installer, this has to become a wizard that walks you through everything, with nice blobby general options and sensible defaults based on the hardware autodetection. These choices and options and the notion of "total control" have to be hidden behind an "Advanced Settings" button.
Fact is, in today's world of gigantic drives, you can come up with one fixed scheme per, say, each popular drive size, that will leave 99% of consumers perfectly happy. Requiring people to think hard about mount points is a nice educational goal, but not a battle that should be fought as part of a user's first 10 minutes of the Linux experience.
I'm sure all the major non-techie distribs will soon have something that combines this kind of Qt or GTK+ GUI with some soothing consumer-oriented wizards as a "novice" install otipon soon enough.
Remote manageability would have been nice.
on
Space Station's LAN
·
· Score: 1
Given that they won't be able to establish peppy TCP/IP links to run something like, heck, PCAnywhere effectively to do remote configuration and maintenance of the systems, this looks like an pretty bad idea. There are probably going to be situations where their only practical choice will be to ship up replacement machines or ship up an MCSE to keep things working.
A Windows network can be a real bear to maintain remotely in situations where you don't have a WAN or realtime dialup access to fall back on. NASA is not staffed by Unix-phobic fools, though, so I have to cling to the hope that they've got redundant Tivoli or BackOffice servers in place, an ability to do network boot and a total wipe of the client machines, and the ability to wipe and rebuild the servers from scratch and then do data-only recovery from tape.
Until this interview, I'd always wince at the photos of him wearing that goofy red hat. Now I understand. He's a scary guy the same way the young Steve Jobs and W.H. Gates III were. Hold on tight, folks, and get ready for an interesting couple of years. This is going to be a fun ride.
Yes, at $1200 Canadian per NetWinder, that's about 400 NetWinders.
In any case, the product is not bad for what, USD$3.3 million in R+D? That itself is an eye-opener. Starting from an open-source base and opening the project in both directions to the community clearly had benefits other vendors will doubtless find impressive.
To their credit regarding the LC's non-appaearance thus far, nobody has ever succeeeded in packaging a user-manageable, truly turnkey general-use Un*x desktop for users without any Unix background.
Even with KDE, there's a lot of glue (and new/better control panels with a unified UI) that needs to be written to pull this off right, so it can and should be expected to take longer than the server machines have. This is something any vendor has to understand needs to be done right on the first try, lest it get deservedly savaged like the original Newton.
They make decent software, but have an inept marketing staff and the most hideous packaging of any company with its distribution reach.
They try to sell powewrful, high-end software at bargain prices, providing family users with software only a trained professional can use and preculding themselves from being taken seriously by IT buyers.
Now they take an admittedly odd fit--computers from a software company--and strip it of the one thing that made it promising: a brand with broad name recognition.
I don't know how high HCC's profile is in Canada and elsewhere, but here in the US, I'd wager Cobalt and VAResearch are more widely known, and that's faint praise.
Being known as the best-known vendor for SPARC clones and an up-and-coming player in the Canadian IT services world may be lucrative, but it's not a promising position to be in if you're looking to make a splash by selling workgroup-scale servers and thin-client desktops built around an offbeat CPU.
I hope for their sake HCC is getting some experienced direct-sales and channel marketing people from Corel in the deal, and that if they don't get to keep the Corel brand on the boxes, that they have a US$20million war chest on hand for an all-out brand-awareness campaign in the likes of InfoWorld and, yes, PCWeek.
Though I may change my mind as things progress, I suspect I'm taking Netwinders of my short-list for the 4 single-CPU servers I need in the second quarter.
If this "Mac-oriented" service is just plain-ol' INPUT TYPE=FILE webform attachments, won't it present the unique problem email attachments have always had in the Mac world, namely that only the data fork of attachments would get transferred?
There isn't much tech info on their site (any, actually) so I don't know if/how they tackled this. Unless browser behavior (or some kind of signed applet ot helper app they'd have to provide) automagically BinHexes the files or at least transfers both forks some other way, these files will certainly have no MIME type associated with them and may even be missing crucial resource-fork data in some cases (such as nonflattened Quicktimes).
How did they approach this? Surely they do something.
If this is being billed as an iMac-only service, why didn't they just set this up as a big AppleShare IP server? What could possibly be more intuitive than giving people a platform-native shared volume?
In a close second, for those with firewall issues, doesn't MacOS 8.5 have one of those fancy FTP clients (a la KDE, and Win32 utilities like FTP Explorer) that looks and feels like an extension to the users' drives?
On a related note, I sure would like to see sensible security rather than paranoid or lazy security become the norm for OS installs so that SMB (poor throughput and all) and NFS file sharing over the 'net can become the norm for purposes like this.
FTP is speedy and reliable, but from a usability standpoint, its all-pull refresh scheme leaves it with a maddening combination of the bad traits of both persistent-connection and stateless protocols.
The TI-99/4zilla project is at a crucial juncture. We are trying to figure out the best way to distribute the application. Since the standard TI floppy holds 90k, requiring users to have 18 daisy-chained floppy drives may prove inelegant. If anyone knows how to extend page-switching to allow us to break the 32K ROM cartridge limit to make a 1.6MB cart, it would be a big help. We don't want to limit ourselves to the few users out there with those nice, big 5MB hard drives.
Of course, if we could double this ROM capacity again for about 4MB, then we could run it from ROM and get a huge speed increase because we wouldn't have to swap from RAM into the 32K maximum RAM environment.
One interesting feature of TI-99/4Zilla unique to the platform is the availability of 1-bit sprites, addressable through the DOM and ECMAScript. We have a few demo pages at our site for those 99/4 users who are interested. Unfortunately, we can't get it to work properly under eumlators:(
On a related note, we hear that our friends at the University of Ljubljana are looking for people to help with the Ohio Scientific Challenger port. Besides the constraints of working in a mere 16K of RAM, the project team has concerns about dynamically linking to the libraries stored on audiocassette at a mere 300 baud.
Yes, you can get faster hardware and more capacity for less money. If you build your own (which corporate and institutional buyers seldom do) or if you buy from the DellMicronGateways of the world.
But for that smaller price tag, you gate a case 5x the size of one of these, you have to supply your own NIC and install drivers for it yourself, plus, worst of all from an institutional perspective, ordering the same model from the same non-premium vendor doesn't get you the same parts from system to system. Unlike the HPs and Compaqs of the world, who charge more but make their boxes identical, the lower-cost vendors will use different suppliers from week to week. You can order two "identical" Dells and get an IBM hard drive in one and a Western Digital in the other. This doesn't make busy techs happy.
This is why the high-road mainstream vendors like HP, Compaq and IBM continue to do well against the likes of Dell in corporate, government and education markets, despite Dell making quality machines. Quality is sometimes only a starting factor, and this is what Corel and Cobalt seem to understand. (Notice how Cobalt Qubes still run a fairly old kernel and a 1.2.x Apache? Their market sees this as a Good Thing.)
When you work a 50-hour week, there's something to be said for a machine with preinstalled, preconfigured, pre-integrated installs of server software and 100% identical hardware configurations.
When you want to set up 8 departmental webservers, you come to appreciate a machine that's always the same, fully supported in all regards, and can be slapped into a rack and running 20 minutes after you tear off the bubble wrap.
Mmmmm. Yummy. Though I'm a little torn on their use of the StrongARM CPU: peppy and cool-running, yes. But I can't use those oh-so-convenient x86 binary.rpms. That said, I like their approach so much I'm sure I'll be ordering a couple for that big hardware expansion I'm doing in the next month or so.
Gimme. Can't wait for the rackmount one. 80 CPUs per one-sided rack and all sorts of preinstalled stuff set up for practical use! Joy!
And any machine with an IrDA port is a friend of mine.
The fact is, Win95 widgets are too different from MacOS 7.x widgets are too different from Motif widgets are too different from MacOS 8.x widgets and so on.
Since for any kind of tight page layout the size and behavior differences between platform widget sets is too great for an interface to look and work right on more than one, web interface design has had to tend towards sprawl and wasted space. With HTML 4.0 and decent stylesheet support, HTML/XML combined with stylesheets and good DOM support can be used as the windowing UI design language of choice. There is no GUI interface that you can't create with 5.x-generation browser engines... except...
As I think we all learned in the days of Java 1.0.x, even the best of the layout managers couldn't really achieve the goal of fully abstract UI design that would render usably with significantly different widgets sets. Even with GridBagLayout, a Java UI designed under Windows would often prove too tight to fit on its canvas when run on a Mac or Unix box. Developers ended up spending inordinate amounts of time rearranging blocks of widgets in their layouts and expanding the canvas in order to account for all the differences. There was also the matter of the way MacOS in particular lacked keyboard equivalents for much UI navigation, along with other subtle differences in the way the "same" kind of widget (a pulldown, a select list...) behaves in different OSes and widget sets.
This led to Netscape creating its own across-the-board widget set called IFC, which they later turned over to Sun as the foundation of Swing, which allows both pluggable skins with more tolerance for abstraction, and for those cases where abstraction just doesn't cut it, the ability to force a specific widget set.
Scrolling web pages are okay and all, but they're not the way people usually like to get work done. If we want to be able to build HTML/XML interfaces that offer the same tight feel of a traditional windowing GUI when they're being rendered under one, we need to be able to get specific about our widgets.
Where this might have been horrifying in the old days, as an example of HTML being bent into a design language rather than one of abstract interfaces, code written for a scheme like this can safely be written with the same kind of mode-independence "purist" HTML has always had, the difference being that now design specificity can ride on top of it.
So that's $1000 for BSD 4.4 bundled with a commercial-grade Appleshare server and a copy of what I perhaps foolishly assume will be a developer-only license for WebObjects, given that WebObjects traditionally costs tens of thousands of dollars to deploy.
And I guess you get phone tech support.. which I sure hope they're busy training people to provide.
I'd still think hard about this. Do you want Apple to be your frontline support provider for a BSD variant? Are you committed to using WebObjects as your web templating and middleware system? And assuming you need to do Mac filesharing, does netatalk not do what you need?
If you answer yes to all the above, this has appeal. If not, you're buying a mighty expensive single-CPU, low-capacity, no-hotswappable-anything box to run that $1000 version of BSD, which is the same price as BSDI/OS AFAIK.
I mean, for the $4000 they're getting for that 256MB G3/400, you can get a pretty nice dual-PII server with 6 hotswap drive bays and a hot-spare power supply.
This is a big leap forward for Apple, but the pricing still isn't quite competitive, and at the moment it's a dead-end as far as scalability goes. Where are the SMP systems to migrate up to as your needs grow once you commit to OS X? It's not as though they'll be able to pitch Mac-like ease-of-use as a price justification for these MacBSD systems.
I'm impressed by the direction they've taken, but the lack of bigger iron in their product line would make it foolish to consider for now. And their decision to forge ahead with what looks like yet another branch off the BSD tree sets off little alarm bells.
For $4999, you get a single-CPU system with what appears to be 2 drive bays, no floppy drive, and a mighty generous 16MB video RAM that most servers never flex.
Considering the scary dual-PII/450 systems with 6 bays you can get for that money, you'd better plan on making good use of that copy of WebObjects they throw in (which I guess you'll need level-4 JDBC drivers to talk to the world with) and the Appleshare file and print services.
To be fair, it is sort of neat that Apple will now be shipping a rock-solid server OS, of all things.
That's a nice thought, but in pratice, ick. If you do that, then the userdirectory becomes a spammer's paradise: a quick, queryable database of email addresses matched to real names. Ick! Ick! Ick!
This of course will eventually be the Right Way to do it, once cerificate-signed email becomes the norm and any and all email without at least a Class-2 caliber cert behind it gets discarded.
Slashdot Mirror
Apart from the redraw problems, the sloppy interface design, the godawful ergonomics, the slow response times on a PII/400, the counterintuitive bundled widgets and the poor "integration" with GNOME, E sure is coming along.
I want to like it, I really do. I want GNOME and E to be a better high-usability desktop than KDE because Qt dependence is Wrong and GPL widget libraries are Right.
But it's Just Not Usable. Stability will come. Speed probably will, too. But someone should have shooed a few cooks out of the kitchen when it came to design, because it's a mess in there.
KDE is bland. KDE is Bad for Free Software. KDE is breathtakingly, unambiguously, seamlessly usable in a way that no Unix GUI has ever been. Not NeXT, not CDE, not nothing.
Is one big big piece of iron really the best way to demonstrate Linux scalability? Maybe the next step is to distribute the processing load, perhaps by putting the logic on ORBs on separate machines and making your (perl, php3, servlets, whatever) real thin.
The New Amiga fills a very important niche, offering an alternative for people dismayed by the runaway popularity of BeOS.
How could these be evidence of stagnation when the designs had to be far enough along to be sent off to manfacturing months ago?
The Palms are appliances, and unlike Wince devices are designed to absolutely positively
The extra features the naysayers want are generally not necessary or terribly useful for even a power user. Voice recording without transcription? Richtext wordprocessing? Animation support? Frames-capable web browser? Color?
Any of these would be nice, but with the possible exception of color, they run counter to the Palm devices' mission: to replace a Filofax.
The Palm V offers no reason for a Palm III-level user to upgrade, but heck, my Personal upgraded to a Pro upgraded to a III does its job just fine. As a corporate web app developer, the only PDA around that really offers something new and compelling is the forthcoming Palm VII. If you're an end user, it looks expensive and limited. If you're a developer interested in roaming field apps, it's exciting as all hell.
As HTML 4.0 (and soon XML+XSL) goes mainstream, they're becoming a universal UI toolkit; a growing number of apps are being written to run under MSIE4 with the expectation that 5.0-generation browsers will have as-good-or-better capabilities as a universal application frontend.
One big thing missing is the lack of embeddable media players for Unix in general and Linux too. Standalone, helper-app audio and video players are a start, but they need to be embeddable, whether via plugins, signed Java applet wrappers or <SMIRK>ActiveX controls</SMIRK>. That goes for streaming media, AVI, quicktime and MPEG alike. It's got to happen or a lot of the new generation of browser-based, theoretically cross-platform apps won't work.
BeOS's fate was sealed when Apple walked away from the buyout negotiations with Be and bought NeXT instead.
Hardware is cheap. Nobody cares about squeezing maximum efficiency from a single- or dual-CPU workstation. If they did, the Macintosh, with its zero-scalabiliity, not-quite-multitasking desktop OS would be dead as a doornail by now. It's not.
Very few people currently care about having a desktop OS that has high uptime, and fewer need one. Those that do already use Unix-family OSes. And by "care", I mean care enough to be willing to switch to something with less software.
Most open-source developers dislike the work required to keep their software compatible with multiple non-Unixy OSes. Some software gets ported--eventually--to OS/2 and NT. But most never does. BeOS is just as far removed from Unixen, in ways that are different from both.
The fact is, the artists and musicians that psychopath Gasse claims he's targeting don't give a damn about (and seldom know about) the internals of their OS. They just want to get their work done, which means they need apps and they need ease of use.
First, apps:
With MIDI connectivity standard on 99% of all x86-compatible desktop machines made in the past 6 years and hardly rocket science on Macs, what does BeOS bring to the table besides a lack of software apart from a few shareware-quality titles? What musician is going to choose an OS that can't run any of the top ten sequencing, patch-library and compositional tools?
Now, ease of use:
Why is the Mac so popular in design and music? Because Macs are generally maintainable by an artist or musician, and so many designers and musicians work solo out of home or in freelance situations. Sure, techies who also make music use Unix and Windows. But apart from them, when you see an artist using a Unix or NT workstation, chances are they're working in an office setting with a dedicated IT staff to shield them from most of the necessary system maintennce tasks.
The probem with BeOS is its premise: that the Mac end-user community is crying out for a technologically superior desktop OS core to run the same GUI, the same hardware and the same kinds of apps they already use. What malarkey. They just want an applicance that works, and they've got one already. Linux, user-hostility and all, has better prospects in this market than BeOS because the developer community is so much larger and more diverse. Check back in two years. BeOS may still be around thanks to Gasse's checking account, but it won't have more than 200,000 active users.
Those sure are pretty config tools they've got there, but they don't look one bit "easier" or "friendlier" than Red Hat's less-glamorous, but clean and clear color textmode installation.
I think their interface approach is a nice one, but it looks to me like it will still only address the technical market of people who know what video chipset they have and why they're partitioning drives in the first place. Seems more an equivalent to the pretty GUI installer Solaris has these days. Still no substitute for knowing some pretty gritty hardware details.
No, to have a consumer, home-user Linux installer, this has to become a wizard that walks you through everything, with nice blobby general options and sensible defaults based on the hardware autodetection. These choices and options and the notion of "total control" have to be hidden behind an "Advanced Settings" button.
Fact is, in today's world of gigantic drives, you can come up with one fixed scheme per, say, each popular drive size, that will leave 99% of consumers perfectly happy. Requiring people to think hard about mount points is a nice educational goal, but not a battle that should be fought as part of a user's first 10 minutes of the Linux experience.
I'm sure all the major non-techie distribs will soon have something that combines this kind of Qt or GTK+ GUI with some soothing consumer-oriented wizards as a "novice" install otipon soon enough.
Given that they won't be able to establish peppy TCP/IP links to run something like, heck, PCAnywhere effectively to do remote configuration and maintenance of the systems, this looks like an pretty bad idea. There are probably going to be situations where their only practical choice will be to ship up replacement machines or ship up an MCSE to keep things working.
A Windows network can be a real bear to maintain remotely in situations where you don't have a WAN or realtime dialup access to fall back on. NASA is not staffed by Unix-phobic fools, though, so I have to cling to the hope that they've got redundant Tivoli or BackOffice servers in place, an ability to do network boot and a total wipe of the client machines, and the ability to wipe and rebuild the servers from scratch and then do data-only recovery from tape.
Until this interview, I'd always wince at the photos of him wearing that goofy red hat. Now I understand. He's a scary guy the same way the young Steve Jobs and W.H. Gates III were. Hold on tight, folks, and get ready for an interesting couple of years. This is going to be a fun ride.
Yes, at $1200 Canadian per NetWinder, that's about 400 NetWinders.
In any case, the product is not bad for what, USD$3.3 million in R+D? That itself is an eye-opener. Starting from an open-source base and opening the project in both directions to the community clearly had benefits other vendors will doubtless find impressive.
To their credit regarding the LC's non-appaearance thus far, nobody has ever succeeeded in packaging a user-manageable, truly turnkey general-use Un*x desktop for users without any Unix background.
Even with KDE, there's a lot of glue (and new/better control panels with a unified UI) that needs to be written to pull this off right, so it can and should be expected to take longer than the server machines have. This is something any vendor has to understand needs to be done right on the first try, lest it get deservedly savaged like the original Newton.
They make decent software, but have an inept marketing staff and the most hideous packaging of any company with its distribution reach.
They try to sell powewrful, high-end software at bargain prices, providing family users with software only a trained professional can use and preculding themselves from being taken seriously by IT buyers.
Now they take an admittedly odd fit--computers from a software company--and strip it of the one thing that made it promising: a brand with broad name recognition.
I don't know how high HCC's profile is in Canada and elsewhere, but here in the US, I'd wager Cobalt and VAResearch are more widely known, and that's faint praise.
Being known as the best-known vendor for SPARC clones and an up-and-coming player in the Canadian IT services world may be lucrative, but it's not a promising position to be in if you're looking to make a splash by selling workgroup-scale servers and thin-client desktops built around an offbeat CPU.
I hope for their sake HCC is getting some experienced direct-sales and channel marketing people from Corel in the deal, and that if they don't get to keep the Corel brand on the boxes, that they have a US$20million war chest on hand for an all-out brand-awareness campaign in the likes of InfoWorld and, yes, PCWeek.
Though I may change my mind as things progress, I suspect I'm taking Netwinders of my short-list for the 4 single-CPU servers I need in the second quarter.
If this "Mac-oriented" service is just plain-ol' INPUT TYPE=FILE webform attachments, won't it present the unique problem email attachments have always had in the Mac world, namely that only the data fork of attachments would get transferred?
There isn't much tech info on their site (any, actually) so I don't know if/how they tackled this. Unless browser behavior (or some kind of signed applet ot helper app they'd have to provide) automagically BinHexes the files or at least transfers both forks some other way, these files will certainly have no MIME type associated with them and may even be missing crucial resource-fork data in some cases (such as nonflattened Quicktimes).
How did they approach this? Surely they do something.
If this is being billed as an iMac-only service, why didn't they just set this up as a big AppleShare IP server? What could possibly be more intuitive than giving people a platform-native shared volume?
In a close second, for those with firewall issues, doesn't MacOS 8.5 have one of those fancy FTP clients (a la KDE, and Win32 utilities like FTP Explorer) that looks and feels like an extension to the users' drives?
On a related note, I sure would like to see sensible security rather than paranoid or lazy security become the norm for OS installs so that SMB (poor throughput and all) and NFS file sharing over the 'net can become the norm for purposes like this.
FTP is speedy and reliable, but from a usability standpoint, its all-pull refresh scheme leaves it with a maddening combination of the bad traits of both persistent-connection and stateless protocols.
The TI-99/4zilla project is at a crucial juncture. We are trying to figure out the best way to distribute the application. Since the standard TI floppy holds 90k, requiring users to have 18 daisy-chained floppy drives may prove inelegant. If anyone knows how to extend page-switching to allow us to break the 32K ROM cartridge limit to make a 1.6MB cart, it would be a big help. We don't want to limit ourselves to the few users out there with those nice, big 5MB hard drives.
:(
Of course, if we could double this ROM capacity again for about 4MB, then we could run it from ROM and get a huge speed increase because we wouldn't have to swap from RAM into the 32K maximum RAM environment.
One interesting feature of TI-99/4Zilla unique to the platform is the availability of 1-bit sprites, addressable through the DOM and ECMAScript. We have a few demo pages at our site for those 99/4 users who are interested. Unfortunately, we can't get it to work properly under eumlators
On a related note, we hear that our friends at the University of Ljubljana are looking for people to help with the Ohio Scientific Challenger port. Besides the constraints of working in a mere 16K of RAM, the project team has concerns about dynamically linking to the libraries stored on audiocassette at a mere 300 baud.
Yes, you can get faster hardware and more capacity for less money. If you build your own (which corporate and institutional buyers seldom do) or if you buy from the DellMicronGateways of the world.
But for that smaller price tag, you gate a case 5x the size of one of these, you have to supply your own NIC and install drivers for it yourself, plus, worst of all from an institutional perspective, ordering the same model from the same non-premium vendor doesn't get you the same parts from system to system. Unlike the HPs and Compaqs of the world, who charge more but make their boxes identical, the lower-cost vendors will use different suppliers from week to week. You can order two "identical" Dells and get an IBM hard drive in one and a Western Digital in the other. This doesn't make busy techs happy.
This is why the high-road mainstream vendors like HP, Compaq and IBM continue to do well against the likes of Dell in corporate, government and education markets, despite Dell making quality machines. Quality is sometimes only a starting factor, and this is what Corel and Cobalt seem to understand. (Notice how Cobalt Qubes still run a fairly old kernel and a 1.2.x Apache? Their market sees this as a Good Thing.)
When you work a 50-hour week, there's something to be said for a machine with preinstalled, preconfigured, pre-integrated installs of server software and 100% identical hardware configurations.
.rpms. That said, I like their approach so much I'm sure I'll be ordering a couple for that big hardware expansion I'm doing in the next month or so.
When you want to set up 8 departmental webservers, you come to appreciate a machine that's always the same, fully supported in all regards, and can be slapped into a rack and running 20 minutes after you tear off the bubble wrap.
Mmmmm. Yummy. Though I'm a little torn on their use of the StrongARM CPU: peppy and cool-running, yes. But I can't use those oh-so-convenient x86 binary
Gimme. Can't wait for the rackmount one. 80 CPUs per one-sided rack and all sorts of preinstalled stuff set up for practical use! Joy!
And any machine with an IrDA port is a friend of mine.
The fact is, Win95 widgets are too different from MacOS 7.x widgets are too different from Motif widgets are too different from MacOS 8.x widgets and so on.
Since for any kind of tight page layout the size and behavior differences between platform widget sets is too great for an interface to look and work right on more than one, web interface design has had to tend towards sprawl and wasted space. With HTML 4.0 and decent stylesheet support, HTML/XML combined with stylesheets and good DOM support can be used as the windowing UI design language of choice. There is no GUI interface that you can't create with 5.x-generation browser engines... except...
As I think we all learned in the days of Java 1.0.x, even the best of the layout managers couldn't really achieve the goal of fully abstract UI design that would render usably with significantly different widgets sets. Even with GridBagLayout, a Java UI designed under Windows would often prove too tight to fit on its canvas when run on a Mac or Unix box. Developers ended up spending inordinate amounts of time rearranging blocks of widgets in their layouts and expanding the canvas in order to account for all the differences. There was also the matter of the way MacOS in particular lacked keyboard equivalents for much UI navigation, along with other subtle differences in the way the "same" kind of widget (a pulldown, a select list...) behaves in different OSes and widget sets.
This led to Netscape creating its own across-the-board widget set called IFC, which they later turned over to Sun as the foundation of Swing, which allows both pluggable skins with more tolerance for abstraction, and for those cases where abstraction just doesn't cut it, the ability to force a specific widget set.
Scrolling web pages are okay and all, but they're not the way people usually like to get work done. If we want to be able to build HTML/XML interfaces that offer the same tight feel of a traditional windowing GUI when they're being rendered under one, we need to be able to get specific about our widgets.
Where this might have been horrifying in the old days, as an example of HTML being bent into a design language rather than one of abstract interfaces, code written for a scheme like this can safely be written with the same kind of mode-independence "purist" HTML has always had, the difference being that now design specificity can ride on top of it.
Here in New York (and I hear all up and down the coasts) plenty of recruiters place inexperienced people, even without the 4-year degree.
Maybe it's your location. This seems likely.
Or maybe you smell bad. Or you show up to interviews in a Rammstein t-shirt. Or your resume is printed with ugly TeX fonts.
Or maybe you not only advocate Linux (fine) but badmouth Microsoft in pre-screenings (probably not a good idea at that stage).
So that's $1000 for BSD 4.4 bundled with a commercial-grade Appleshare server and a copy of what I perhaps foolishly assume will be a developer-only license for WebObjects, given that WebObjects traditionally costs tens of thousands of dollars to deploy.
And I guess you get phone tech support.. which I sure hope they're busy training people to provide.
I'd still think hard about this. Do you want Apple to be your frontline support provider for a BSD variant? Are you committed to using WebObjects as your web templating and middleware system? And assuming you need to do Mac filesharing, does netatalk not do what you need?
If you answer yes to all the above, this has appeal. If not, you're buying a mighty expensive single-CPU, low-capacity, no-hotswappable-anything box to run that $1000 version of BSD, which is the same price as BSDI/OS AFAIK.
I mean, for the $4000 they're getting for that 256MB G3/400, you can get a pretty nice dual-PII server with 6 hotswap drive bays and a hot-spare power supply.
This is a big leap forward for Apple, but the pricing still isn't quite competitive, and at the moment it's a dead-end as far as scalability goes. Where are the SMP systems to migrate up to as your needs grow once you commit to OS X? It's not as though they'll be able to pitch Mac-like ease-of-use as a price justification for these MacBSD systems.
I'm impressed by the direction they've taken, but the lack of bigger iron in their product line would make it foolish to consider for now. And their decision to forge ahead with what looks like yet another branch off the BSD tree sets off little alarm bells.
For $4999, you get a single-CPU system with what appears to be 2 drive bays, no floppy drive, and a mighty generous 16MB video RAM that most servers never flex.
Considering the scary dual-PII/450 systems with 6 bays you can get for that money, you'd better plan on making good use of that copy of WebObjects they throw in (which I guess you'll need level-4 JDBC drivers to talk to the world with) and the Appleshare file and print services.
To be fair, it is sort of neat that Apple will now be shipping a rock-solid server OS, of all things.
That's a nice thought, but in pratice, ick. If you do that, then the userdirectory becomes a spammer's paradise: a quick, queryable database of email addresses matched to real names. Ick! Ick! Ick!
This of course will eventually be the Right Way to do it, once cerificate-signed email becomes the norm and any and all email without at least a Class-2 caliber cert behind it gets discarded.
But it isn't, so it's not.