Boo collapsed because it was an ill-conceived mess. Sure, it had lovely design. Sue, it had all sorts of interface bells and whistles. But it was a godawful e-commerce site.
Its home page didn't show any product or say what it was. It popped up a window that also didn't show any product or say what it was. Instead, it asked what country you were in. This was idiotic, given that the largest pool of visitors were in the US, and doubly idiotic because the US was at the bottom of an alphabetized list of countries. Very egalitarian and politically astute, sure, but idiotic if your goal is to sell, especially given that on average you lose half of all visitors with each click. Why ask the country up front? Why not wait until late in the transaction? And if you have different warehouses for Europe and North America, then advertise two separate sites, stupid!
Once you drilled down to a product through its lovely but tedious Flash menus, you had to return to the store entrance to pick another brand or type of product. In other words, to pick a shirt and then get a pair of jeans, you'd have to click "continue shopping", which would take you to the front of the store again, because menus don't follow you through the drilldown.
And the Flash. Flash is nice. Flash is close enough to universal these days to be justifiable on a commerce site. But Boo's use of complex framesets, multiple windows and multiple Flash elements per screen makes computers with less than 128MB RAM cry.
Multiple windows. Eek! A Boo shopping session is pretty crowded with all the windows it opens on a 1280x1024 display. Windows overlap on 1024x768. At least a third of all web users are running in 800x600 or 640x480. And those on bigger monitors probably have other windows open for other apps anyway. Ouch.
Boo was theoretically right in some of its design decisions. The mix-and-match clothing previewer is a keeper, or will be someday, as are the ideas behind the fabric zoom and 360-degree views. But the way they did it, over the heads and over the hardware reality of potential customers, was pure idiocy. The only serious interface change they made over time was to get rid of the "clippy"-like virtual advisor (also in a separate window). Adn I sort of liked that element.
As noted above, there are a few for Motif, if Motif's what you want to use, and it's more or less the Solaris default, given their use of the CDE.
Some offbeat alternatives that go beyond or sidestep the sort of standalone GUI-builder you sound like you're looking for would be:
A Tk frontend, built with the free Visual Tcl (not to be confused with the other 3 or 4 products called Visual Tcl)
GTK+. If you're prepared to require GTK+ on the deployment systems, or build static binaries, there's a fine standalone GUI builder out there, but I forget what it's called. It generates C. Then there's VDKBuilder, which is an entire C++ IDE that includes a GUI builder.
KDE. For KDE, there are a few full-featured IDEs, the best of which right now is KDevelop. If you can get QT on deployment machines or want KDE on deployment systems (it's a damn fine desktop, and is available as Solaris.pkgs), you can do some *really* slick, fully GNU tools-ified work with KDevelop, and it will let you do "ordinary" QT development if you don't want to build KDE apps. It'll happily package up your source tree with autoconf support, SGML, HTML and man page documentation while you're at it. Since you're looking into commercial GUI builders, I assume you don't have a problem with the license fee for doing commercial QT development.
Having tried the recent Helix Code tweaks of GNOME and the beta of KDE 2, it's clear we're getting there fast. KDE 1.x still has GNOME beat hands-down on ease of use, but the UI changes Helix has been putting out lately are closing the gap. Dialog boxes are starting to look clean and rational, and menus are more consistent than before. They're on the right track.
KDE 1.x is still far ahead of GNOME on the usability side of things, if not its internals--and it's rock solid. I could give a KDE 1.1.x machine to a genuine novice, and with an hour of coaching they'd be able to do everything they need with minimal help from a "Dummies" book. Software installation remains the big barrier between *nix and the mainstream of personal computing. With KDE, everyday computer use is no longer a problem.
However, last week's KDE 2 beta was a real eye-opener. The icons are prettier, the design cleaner and warmer. They've moved on from aping their benchmark, Windows 98, to making something easier for novices and power users alike to use. The "first use" user-settings wizard absolutely blew me away, as did the context-sensitivity and embedding capabilities of the new file manager/browser. KDE 2 beta 1 is unstable as all hell, not yet usable by any stretch, mind you. But for the curious and hardy techie, it's worth looking at. Unix desktop environments are coming into their own.
Ah, answered my own question and found a vendor. Looks like Sophos's server scanning package does the trick. Supports a while bunch of Unices and OpenVMS, too. Sure would be nice of CA and Trend Micro would do the same, as I prefer their overall suites as an enterprise solution.
In Linux's (and Unix's) favor is its strong permissions system out of the box, which does prevent things like this from hitting system-level files (applications, default settings and system services). I was appalled when I ran a registry fix on our NT boxes that an ordinary user by default could edit the HKEY_CLASSES_ROOT registry tree.
However, there are serious vulnerabilities in Linux and Unix thanks to the same laziness about security on the part of *nix applications developers that made Windows so vulnerable. StarOffice, Applixware and Corel Office all have built-in scripting engines, and all are configured to allow easy execution of unsigned scripts. Indeed, do any of these packages have code-signing for macros at all? MS Office 2000 finally does, though it's rendered all but useless thanks to the default settings that don't bother checking for signing.
This means that as these office suites proliferate, so will the likelihood of the same kinds of worm outbreaks unless applications vendors step up and (1) make code-signing easy and simple and (2) ship software that defaults to disabling any and all unsigned scripts. Without this, we're all doomed.
The good news here is the Unix world's clear boundaries between user data and things that can/should be read-only. A Linux desktop user is only putting their personal files and files on public shares at risk. A Windows user under all but the rarest, most rigorously secured circumstances, is putting their entire system at risk: applications, OS and all.
Another *nix vulnerability is on server systems. One big disadvantage Samba servers have is an apprent lack of realtime antivirus software. Yes, there's server antivirus software for Linux, as well as SMTP, Notes, HTTP and FTP realtime protection packages.. but as far as I can tell, for filesystems (as opposed to mail and network traffic), there's only stuff that does on-demand or periodic scans, not surveillance of all files as they're being written. There's no reason this should be the case, apart from antivirus software vendors simply not doing the port. If anyone knows of realtime virus scanning software for Linux file servers, let me know. I'm in the market for it. This vulnerability, mind you, seems to be true of all filesharing platforms other than NT and Netware. Not even an AS/400 or an Oracle iFS server is safe in this regard.
This means that a *nix box acting as a fileserver for even one Windows client is putting shared user files at more risk (at least in this respect) than an NT/2000/Netware file server with realtime server virus protection.
Every fly-by-night electronics store in New York (and doubtless other immagrant meccas like L.A.) sells no-name handheld translation gadgets. Typically they only do a word (cheap) or sentence ($200 or so) at a time, not whole passages. You can get them with one language or with a bunch at once. Some have speech synthesis.
If you have a Palm handheld with a fair amount of RAM (8MB), there are a fair number of translation dictionaries out there. They're all one-word-at-a-time, though, so one of the better dedicated handheld gadgets will serve you better.
Or, as long as you stay in North America (whoops! not so good for travel!) you could get a Palm VII or get a Palm III or V with a snap-on wireless modem and use the GO Network translator, for which there is a query app that handles the usual 4 or 5 European languages.
Don't be so quick to reject the "donated hardware" approach. An old Pentium PC with a default kernel and a $30 Tulip-based 10/100 managed NIC isn't going to need much special configuration. The XF86_SVGA package should be compatible at 800x600 or even 1024x768 on nearly any hardware you throw at it, even if it won't necessarily be "optimal".
Let's imagine you're using RedHat or Mandrake, for the sake of keeping this explanation simple, though similar things can be done with Debian-based distros, too. Once you've got the right assortment of packages loaded and have removed the ones you don't want, you can make a kickstart install floppy, which will allow for a hands-free install (put in floppy, put in CD, and power on).
If you're okay at making your own RPMs, you can make an extra RPM with your configs (for example, configuring the eth0 interface to configure itself via DHCP, and activating NIS or pam_ldap to participate in centralized configuration). Burn that onto your otherwise-ordinary CD.
With a bit of planning, unless you have some weird and eccentric systems in the mix, the only substantial thing you'll likely have to do manually is run Xconfigurator, since every monitor and video card dot-clock is possibly different.
The hell with KDE2 anbd KOffice. It's not going to be finished and stable for months, nice as it'll be. Same goes for GNOME, which is imprioving but just not stable enough yet. Go with KDE 1.1.2. It's extremely stable and a fairly seamless end-user environment. For office software, go with StarOffice 5.1a. It's cost-free, full-featured, easy to learn, and there are good books on it available at any bookstore.
The thing about this is that both KDE and StarOffice (or for that matter, Corel Office) are very resoure-hungry. You will need a server (or more than one server) with a whole lot of RAM (assume at least 32MB for each connected user) and, (guessing off the top of my head), 70-100MHz of processing power for each.
If you want to be able to scale down the server, you may want to look into a leaner (but less capable) desktop environment, and Applixware, which is a leaner (but not free) office suite.
Why do they need an entire office suite, anyway? Will something like LyX/KLyX for documents and Gnumeric for spreadsheets do what the kids need?
$350 with displays is really pushing things. It can be done, but isn't your time worth something? The iOpener is cheap not because a computer can be made for $99, but because it's being sold at a loss with the expectation of people paying for monthly service.
Uh, there's AutoRPM. There's also Symantec's LiveUpdate feature. And let's not forget Lotus Notes replication (which does code, not just data, y'all).
That's off the top of my head. And that's just ones using the public Internet that have UIs that ask users what they want to do. I daresay, this is no different from what most automated file mirroring and ASD (automated software distribution) systems do. Computer Associates, Tivoli and a few other companies I can think of will have something to say about this. A look at the legal status screen makes it appear they already have.
Seems okay by me (1) as long as they don't pollute the license of the code by requiring that they be left intact permanently, and (2) as long as they don't add instability by changing video mode, using sound, etc.
Not sure what a court would make any of this.. a proprietary grab at an IETF task force submission (itself similar to the patent application for stylesheets last year).
Maybe the answer is to get some 15-year-old programmers to merge this into the Samba, OpenLDAP and standard Kerberos code trees.
In any case, this certainly poisons the well. Releasing the specs of their changes like this is worse than keeping it closed: it will make it extremely difficult for an unpolluted clean-room implementation of the modified protocol to be accepted into anything, as anyone who has reviewed this spec may well be barred from participating in even a reverse-engineered implementation.
This is brilliantly evil.
I wonder if the PDFs are individually watermarked to track *who* leaked a given copy. I don't think I've ever seen Microsoft publish anything as a PDF before. They usually pass this stuff out as HTML or a Word document.
Maybe genuinely secure laptops make more sense.
on
Laptop Lojack?
·
· Score: 2
Not a terrible idea, but what would you be tracking? The motherboard? THe hard drive? Both?
Far more sensible for a laptop with classified information would be to use a filesystem that stores all data on the drivce with strong encryption, and requiring a revocable digital certificate to decrypt it.
I find it worrisome that any country's intelligence services would allow sensitive information to be carried around in cleartext. I don't know whatencrypted filesystem options there are for NT/Win2K.. maybe there is one. But I do know that there are readily available solutions for Linux and other Unix-style OSes.
Assuming they go with a StrongARM chip no slower than 200MHz at launch, one nifty thing is that the increase in power and speed over a 16MHz 68020-family chip like the Dragonball is so great that you could run the Dragonball-based Palm binaries on it at full speed in an emulation harness easily.
This should be fun.
So much for 2-month battery life from a pair of AAA cells, though.
Tell those cheap marketing folks "upstairs" that at the very least installation and quickstart guides must be provided in print, and that they must at least sell printed versions of all documnetation, especially that boring, repetitive and bulky "reference" stuff.
PDF documentation is nice to have, especially if it's searchable, indexed, and linked. It's good to be able to print a book yourself if the prnted copy has walked away. But a stack of 8.5"x11" or A4 printouts in a binder or held together with a big paperclip is a horrible substitute for a bound book. And reading docs onscreen is nice unless you're trrying to get work done and read the docs at the same time. Clicking back and forth gets tedious quickly.
HTML docs and context-sensitive help are nice for some things. But again, they are used differently from a nice book. Sometimes you just need a book. This will change when large-format high-resolution (>200 dpi) e-book readers become available, but until then the rule should be: if you have enough documentation to make a 200-page book, you must offer it as a 200-page book.
Marketing folks will argue that since you've made the sale, it doesn't matter what format the docs are in, because you've already won the customer. But that's not true. Software with awkward, inaccessible documentation makes for unhappy, frustrated users, and when the product comes up for re-evaluation 18 months later, that frustration gets expressed in a desire to work with something "less awkward".
You can have the best product on the market, but if your documentation is frustrating to work with, then your product is frustrating to work with.
Ask your company's inside-sales people, who deal with current customers. Customers tell them what they think of CD-only documnentation. And it's not nice.
OpenSSL can function as a cert server just fine out of the box. The key issue here is trust.
Web browsers and other software using SSL only allow clean passage of certificates from cert authorities for which the master cert for that authority is present. When you get a mainstream we browser, it comes with keys installed for Verisign, Thawte, Deutsche Telekom, Equifax, GTE and a number of other signing authorities.
You can add more signers yourself. If you're deploying browsers for a company/school/organization extranet, for example, you can hand out browsers with your organization's master cert installed, and the browser will happily accept the certs you issue, with no money going to a Verisign, Thawte, etc.
Thing is, in order to get into the master list of signer certs that get bundled with the major browsers, your signing authority has to be considered fully trustworthy. That means you have to be able to vouch for the authenticity of every cert you issue. Verisign and Thawte do that by doing a verification of the info provided by an applicant. That generally costs a bit of money and labor. But then there's the CA's bigger expense: covering themselves in case of liability. A Verisign or Thawte cert, level 3 or higher, costs money because Verisign and Thawte are outting their necks on the chopping block if they issue a false cert. They are liable for fraud committed with a false certificate. Remember: when a browser passively accepts a cert, it isn't just signifying that encryption is taking place. It's telling you that the site (or personal) certificate is correct, that if the cert is claimed to be from Spumco at 123 Main Street, it really is Spumco's cert.
The best you could really hope to put together is a non-profit CA. You can't get rid of significant cost altogether. Insurance costs money.
If I roll it out, it will be thin-client for most users. We will be using combo ICA/XWindow terminals, and presumably running StarOffice on a big Linux or Solaris box (~4 CPUs, 1GB RAM), serving out sessions to the 20 or so people on the terminals. In other words, low-end, diskless machines on desks and a big fat server or two behind the scenes. You don't save the money on hardware (or software, necessarily). You save on downtime and maintenance. As long as the server is humming along, desktop maintenance consists of throwing terminals away when they break and zero prep time required for a new one.
By the way, those P133s, as long as they have a 2MB video card, make darn good X or ICA terminals. Throw on a nice pared-down install of Linux, point 'em at a *nix box running XDM, and you're in business.
No, they haven't slimmed it down or made noticeable UI changes. This is a subtle upgrade.
It seems a bit snappier than 5.1. The Win32 version now embeds the IE browser engine if it's present, which improves web browsing from within the app. The IMAP mail support is a bit slicker, roughly on par with Netscape 4.x but with some extra niceties thanks to its integration with the rest of the suite. It ain't Outlook 2000 yet, but then it's also not succeptible to script macros in message bodies.
But the best improvement I've seen is in the MS Office import and export capabilities. It always did a better-than-average job of opening MS Office files, but it wasn't good enough to replace MS Office for shops with lots of Office documents floating around. Now, it's nailed every small to mid-sized Word, Excel and Powerpoint doc I've thrown at it, save for the Microsoft-dialect VBA macros, and it neither runs nor harms those. Based on my use of it over the past two days on Linux and NT, I now feel it's a viable product to roll into mixed MS Office environments for roles where VBA doesn't come into play.
Now that 5.2 plays nicer with MS Office files, I will definitely be evaluating it as a server-based X app for a 20-person call center I'm putting together.
The only thing any of these companies are selling are videotapes, brochures for investors, and simulation software. Exactly two of the three that claim to have a product have exactly one prototype apiece, each of which have flown a few hundred feet, and they won't make one for you at any price.
If you don't want any of this prime swampland I'm selling in New Jersey, I hear the Brooklyn Bridge is for sale.
What's wrong with convenience? If 14 million households have AOL accounts, why should they have to custom-program "email" "web" and "weather" keys on their keyboard, or go through menus to get to the 3 or 4 things they use their computers for 95% of the time?
What a bunch of babies y'all are. Is ease-of-use really so horrible? Why not just crawl under a rock and go back to flipping a panel of toggle switches to enter data like you had to on the Altair?
PHP's swell and all, but there aren't any IDEs for it, never mind slick, drag-and-drop RAD tools like Drumbeat 2000.
And PHP3 is still woefully two-tier. Where are the fully-supported APIs for talking to transaction servers or CORBA and COM objects? And why write your core logic in a language different from your outer layer, as you end up doing with PHP? At least with ASP you can leverage VB skills one a few layers.
Even JSP (which is especially nifty at the 3-tier game) has RAD tools bublling up. There's the JSP version of Drumbeat and IBM's WebSphere Studio. AFAIK, both only generate code certified for WebSphere, but that's more than there is for PHP.
I'd argue that QNX is what killed Coherent. Coherent, if I recall, was promoted mainly for "appliance" applications, not for business servers or desktops.
Call up your local IBM, Lotus or Sybase rep and ask them which x86 Unix-family OS they recommend for their products. Even a year ago, the answer would have been SCO. Not anymore. I'm told Sybase now even goes so far these days as to encourage their existing SCO customers to make the switch to Linux.
Oracle seems to be ramping up to do the same, given the pace at which they're porting much of their product line. The bigger-iron Unixes aren't being hurt much by Linux right now, and won't be until good support for SANs and 8-64 CPU servers finds its way in. Which it will. But in the 1-2 CPU server market, Linux is rapidly becoming software vendors' reference platform. It's hard to imagine SCO getting any new OS customers these days, save for the few shops picking Tarantella as their thin-client environment.
Looks like SCO is going to be the first Unix effectively killed by Linux. Sun will prop up x86 Solaris as long as it costs them practically nothing to recompile it. I'd wager BSDI/OS is next to go. BSDI's big selling points over *BSD were robustness and commercial support. The robustness gap has largely been closed, with things like Solaris and AIX RISC boxen more affordable from above, and Linux and *BSD eating its lunch from below. And anyone with a staff of smart techs and some seed money can set up shop providing support for the free OSes.
Companies like VA and Red Hat have the equity necessary to pull similar moves on some of the other not-quite-free software out there. Keep the engineers. Keep the other staff to continue selling support and training. And then release the code under the LGPL or a BSD-style license. Good candidates IMHO would onclude:
Qt, so the remaining apprehension over KDE can be put to rest and the GNOME and KDE projects can share more code without worries over license conflicts
After playing with the latest builds of WINE over the weekend, I'm not surprised Corel was able to ship so quickly. Now, with an install of WINE with access to a real Windows system directory and a Truetype font server, I not only got Excel 97 working pretty decently(!), but I also got IE 5 to load a few pages. Properly. WIth DHTML working.
These are interesting times. Native apps are always best, but it's clear x86 Linux is heading to a place where you'll soon also be able to run most Windows software cleanly. Not a Terrible Thing for desktop penetration.
I suspect Corel WP Office 2000 doesn't suck, or at least doesn't suck any more than StarOffice 5.1a does. Corel can't market its way out of a paper bag, though. At least they pushed the WINE project ahead nicely.
I've long argued that this newfangled Internet thing won't really take off until a parallel network of pneumatic tubes is in place at every desktop.
The Internet's big flaw is its inability to trransport, say, kittens or french fries. Right now, if you want french fries over the 'net, you need to place an order which is then delivered by a person. Pneumatic tubes would make it possible to eliminate all human interaction.
With efficient digital switching systems in place, today's pneumatic tube networks could be made efficient enough to handle fully-automated person-to-person routing of the cargo cylinders.
Slashdot Mirror
Boo collapsed because it was an ill-conceived mess. Sure, it had lovely design. Sue, it had all sorts of interface bells and whistles. But it was a godawful e-commerce site.
Its home page didn't show any product or say what it was. It popped up a window that also didn't show any product or say what it was. Instead, it asked what country you were in. This was idiotic, given that the largest pool of visitors were in the US, and doubly idiotic because the US was at the bottom of an alphabetized list of countries. Very egalitarian and politically astute, sure, but idiotic if your goal is to sell, especially given that on average you lose half of all visitors with each click. Why ask the country up front? Why not wait until late in the transaction? And if you have different warehouses for Europe and North America, then advertise two separate sites, stupid!
Once you drilled down to a product through its lovely but tedious Flash menus, you had to return to the store entrance to pick another brand or type of product. In other words, to pick a shirt and then get a pair of jeans, you'd have to click "continue shopping", which would take you to the front of the store again, because menus don't follow you through the drilldown.
And the Flash. Flash is nice. Flash is close enough to universal these days to be justifiable on a commerce site. But Boo's use of complex framesets, multiple windows and multiple Flash elements per screen makes computers with less than 128MB RAM cry.
Multiple windows. Eek! A Boo shopping session is pretty crowded with all the windows it opens on a 1280x1024 display. Windows overlap on 1024x768. At least a third of all web users are running in 800x600 or 640x480. And those on bigger monitors probably have other windows open for other apps anyway. Ouch.
Boo was theoretically right in some of its design decisions. The mix-and-match clothing previewer is a keeper, or will be someday, as are the ideas behind the fabric zoom and 360-degree views. But the way they did it, over the heads and over the hardware reality of potential customers, was pure idiocy. The only serious interface change they made over time was to get rid of the "clippy"-like virtual advisor (also in a separate window). Adn I sort of liked that element.
Some offbeat alternatives that go beyond or sidestep the sort of standalone GUI-builder you sound like you're looking for would be:
Having tried the recent Helix Code tweaks of GNOME and the beta of KDE 2, it's clear we're getting there fast. KDE 1.x still has GNOME beat hands-down on ease of use, but the UI changes Helix has been putting out lately are closing the gap. Dialog boxes are starting to look clean and rational, and menus are more consistent than before. They're on the right track.
KDE 1.x is still far ahead of GNOME on the usability side of things, if not its internals--and it's rock solid. I could give a KDE 1.1.x machine to a genuine novice, and with an hour of coaching they'd be able to do everything they need with minimal help from a "Dummies" book. Software installation remains the big barrier between *nix and the mainstream of personal computing. With KDE, everyday computer use is no longer a problem.
However, last week's KDE 2 beta was a real eye-opener. The icons are prettier, the design cleaner and warmer. They've moved on from aping their benchmark, Windows 98, to making something easier for novices and power users alike to use. The "first use" user-settings wizard absolutely blew me away, as did the context-sensitivity and embedding capabilities of the new file manager/browser. KDE 2 beta 1 is unstable as all hell, not yet usable by any stretch, mind you. But for the curious and hardy techie, it's worth looking at. Unix desktop environments are coming into their own.
Ah, answered my own question and found a vendor. Looks like Sophos's server scanning package does the trick. Supports a while bunch of Unices and OpenVMS, too. Sure would be nice of CA and Trend Micro would do the same, as I prefer their overall suites as an enterprise solution.
These folks should give Cobalt a call.
In Linux's (and Unix's) favor is its strong permissions system out of the box, which does prevent things like this from hitting system-level files (applications, default settings and system services). I was appalled when I ran a registry fix on our NT boxes that an ordinary user by default could edit the HKEY_CLASSES_ROOT registry tree.
However, there are serious vulnerabilities in Linux and Unix thanks to the same laziness about security on the part of *nix applications developers that made Windows so vulnerable. StarOffice, Applixware and Corel Office all have built-in scripting engines, and all are configured to allow easy execution of unsigned scripts. Indeed, do any of these packages have code-signing for macros at all? MS Office 2000 finally does, though it's rendered all but useless thanks to the default settings that don't bother checking for signing.
This means that as these office suites proliferate, so will the likelihood of the same kinds of worm outbreaks unless applications vendors step up and (1) make code-signing easy and simple and (2) ship software that defaults to disabling any and all unsigned scripts. Without this, we're all doomed.
The good news here is the Unix world's clear boundaries between user data and things that can/should be read-only. A Linux desktop user is only putting their personal files and files on public shares at risk. A Windows user under all but the rarest, most rigorously secured circumstances, is putting their entire system at risk: applications, OS and all.
Another *nix vulnerability is on server systems. One big disadvantage Samba servers have is an apprent lack of realtime antivirus software. Yes, there's server antivirus software for Linux, as well as SMTP, Notes, HTTP and FTP realtime protection packages.. but as far as I can tell, for filesystems (as opposed to mail and network traffic), there's only stuff that does on-demand or periodic scans, not surveillance of all files as they're being written. There's no reason this should be the case, apart from antivirus software vendors simply not doing the port. If anyone knows of realtime virus scanning software for Linux file servers, let me know. I'm in the market for it. This vulnerability, mind you, seems to be true of all filesharing platforms other than NT and Netware. Not even an AS/400 or an Oracle iFS server is safe in this regard.
This means that a *nix box acting as a fileserver for even one Windows client is putting shared user files at more risk (at least in this respect) than an NT/2000/Netware file server with realtime server virus protection.
Every fly-by-night electronics store in New York (and doubtless other immagrant meccas like L.A.) sells no-name handheld translation gadgets. Typically they only do a word (cheap) or sentence ($200 or so) at a time, not whole passages. You can get them with one language or with a bunch at once. Some have speech synthesis.
If you have a Palm handheld with a fair amount of RAM (8MB), there are a fair number of translation dictionaries out there. They're all one-word-at-a-time, though, so one of the better dedicated handheld gadgets will serve you better.
Or, as long as you stay in North America (whoops! not so good for travel!) you could get a Palm VII or get a Palm III or V with a snap-on wireless modem and use the GO Network translator, for which there is a query app that handles the usual 4 or 5 European languages.
Don't be so quick to reject the "donated hardware" approach. An old Pentium PC with a default kernel and a $30 Tulip-based 10/100 managed NIC isn't going to need much special configuration. The XF86_SVGA package should be compatible at 800x600 or even 1024x768 on nearly any hardware you throw at it, even if it won't necessarily be "optimal".
Let's imagine you're using RedHat or Mandrake, for the sake of keeping this explanation simple, though similar things can be done with Debian-based distros, too. Once you've got the right assortment of packages loaded and have removed the ones you don't want, you can make a kickstart install floppy, which will allow for a hands-free install (put in floppy, put in CD, and power on).
If you're okay at making your own RPMs, you can make an extra RPM with your configs (for example, configuring the eth0 interface to configure itself via DHCP, and activating NIS or pam_ldap to participate in centralized configuration). Burn that onto your otherwise-ordinary CD.
With a bit of planning, unless you have some weird and eccentric systems in the mix, the only substantial thing you'll likely have to do manually is run Xconfigurator, since every monitor and video card dot-clock is possibly different.
The hell with KDE2 anbd KOffice. It's not going to be finished and stable for months, nice as it'll be. Same goes for GNOME, which is imprioving but just not stable enough yet. Go with KDE 1.1.2. It's extremely stable and a fairly seamless end-user environment. For office software, go with StarOffice 5.1a. It's cost-free, full-featured, easy to learn, and there are good books on it available at any bookstore.
The thing about this is that both KDE and StarOffice (or for that matter, Corel Office) are very resoure-hungry. You will need a server (or more than one server) with a whole lot of RAM (assume at least 32MB for each connected user) and, (guessing off the top of my head), 70-100MHz of processing power for each.
If you want to be able to scale down the server, you may want to look into a leaner (but less capable) desktop environment, and Applixware, which is a leaner (but not free) office suite.
Why do they need an entire office suite, anyway? Will something like LyX/KLyX for documents and Gnumeric for spreadsheets do what the kids need?
$350 with displays is really pushing things. It can be done, but isn't your time worth something? The iOpener is cheap not because a computer can be made for $99, but because it's being sold at a loss with the expectation of people paying for monthly service.
Uh, there's AutoRPM. There's also Symantec's LiveUpdate feature. And let's not forget Lotus Notes replication (which does code, not just data, y'all).
That's off the top of my head. And that's just ones using the public Internet that have UIs that ask users what they want to do. I daresay, this is no different from what most automated file mirroring and ASD (automated software distribution) systems do. Computer Associates, Tivoli and a few other companies I can think of will have something to say about this. A look at the legal status screen makes it appear they already have.
Seems okay by me (1) as long as they don't pollute the license of the code by requiring that they be left intact permanently, and (2) as long as they don't add instability by changing video mode, using sound, etc.
Not sure what a court would make any of this.. a proprietary grab at an IETF task force submission (itself similar to the patent application for stylesheets last year).
Maybe the answer is to get some 15-year-old programmers to merge this into the Samba, OpenLDAP and standard Kerberos code trees.
In any case, this certainly poisons the well. Releasing the specs of their changes like this is worse than keeping it closed: it will make it extremely difficult for an unpolluted clean-room implementation of the modified protocol to be accepted into anything, as anyone who has reviewed this spec may well be barred from participating in even a reverse-engineered implementation.
This is brilliantly evil.
I wonder if the PDFs are individually watermarked to track *who* leaked a given copy. I don't think I've ever seen Microsoft publish anything as a PDF before. They usually pass this stuff out as HTML or a Word document.
Not a terrible idea, but what would you be tracking? The motherboard? THe hard drive? Both?
Far more sensible for a laptop with classified information would be to use a filesystem that stores all data on the drivce with strong encryption, and requiring a revocable digital certificate to decrypt it.
I find it worrisome that any country's intelligence services would allow sensitive information to be carried around in cleartext. I don't know whatencrypted filesystem options there are for NT/Win2K.. maybe there is one. But I do know that there are readily available solutions for Linux and other Unix-style OSes.
Assuming they go with a StrongARM chip no slower than 200MHz at launch, one nifty thing is that the increase in power and speed over a 16MHz 68020-family chip like the Dragonball is so great that you could run the Dragonball-based Palm binaries on it at full speed in an emulation harness easily.
This should be fun.
So much for 2-month battery life from a pair of AAA cells, though.
Tell those cheap marketing folks "upstairs" that at the very least installation and quickstart guides must be provided in print, and that they must at least sell printed versions of all documnetation, especially that boring, repetitive and bulky "reference" stuff.
PDF documentation is nice to have, especially if it's searchable, indexed, and linked. It's good to be able to print a book yourself if the prnted copy has walked away. But a stack of 8.5"x11" or A4 printouts in a binder or held together with a big paperclip is a horrible substitute for a bound book. And reading docs onscreen is nice unless you're trrying to get work done and read the docs at the same time. Clicking back and forth gets tedious quickly.
HTML docs and context-sensitive help are nice for some things. But again, they are used differently from a nice book. Sometimes you just need a book. This will change when large-format high-resolution (>200 dpi) e-book readers become available, but until then the rule should be: if you have enough documentation to make a 200-page book, you must offer it as a 200-page book.
Marketing folks will argue that since you've made the sale, it doesn't matter what format the docs are in, because you've already won the customer. But that's not true. Software with awkward, inaccessible documentation makes for unhappy, frustrated users, and when the product comes up for re-evaluation 18 months later, that frustration gets expressed in a desire to work with something "less awkward".
You can have the best product on the market, but if your documentation is frustrating to work with, then your product is frustrating to work with.
Ask your company's inside-sales people, who deal with current customers. Customers tell them what they think of CD-only documnentation. And it's not nice.
OpenSSL can function as a cert server just fine out of the box. The key issue here is trust.
Web browsers and other software using SSL only allow clean passage of certificates from cert authorities for which the master cert for that authority is present. When you get a mainstream we browser, it comes with keys installed for Verisign, Thawte, Deutsche Telekom, Equifax, GTE and a number of other signing authorities.
You can add more signers yourself. If you're deploying browsers for a company/school/organization extranet, for example, you can hand out browsers with your organization's master cert installed, and the browser will happily accept the certs you issue, with no money going to a Verisign, Thawte, etc.
Thing is, in order to get into the master list of signer certs that get bundled with the major browsers, your signing authority has to be considered fully trustworthy. That means you have to be able to vouch for the authenticity of every cert you issue. Verisign and Thawte do that by doing a verification of the info provided by an applicant. That generally costs a bit of money and labor. But then there's the CA's bigger expense: covering themselves in case of liability. A Verisign or Thawte cert, level 3 or higher, costs money because Verisign and Thawte are outting their necks on the chopping block if they issue a false cert. They are liable for fraud committed with a false certificate. Remember: when a browser passively accepts a cert, it isn't just signifying that encryption is taking place. It's telling you that the site (or personal) certificate is correct, that if the cert is claimed to be from Spumco at 123 Main Street, it really is Spumco's cert.
The best you could really hope to put together is a non-profit CA. You can't get rid of significant cost altogether. Insurance costs money.
If I roll it out, it will be thin-client for most users. We will be using combo ICA/XWindow terminals, and presumably running StarOffice on a big Linux or Solaris box (~4 CPUs, 1GB RAM), serving out sessions to the 20 or so people on the terminals. In other words, low-end, diskless machines on desks and a big fat server or two behind the scenes. You don't save the money on hardware (or software, necessarily). You save on downtime and maintenance. As long as the server is humming along, desktop maintenance consists of throwing terminals away when they break and zero prep time required for a new one.
By the way, those P133s, as long as they have a 2MB video card, make darn good X or ICA terminals. Throw on a nice pared-down install of Linux, point 'em at a *nix box running XDM, and you're in business.
No, they haven't slimmed it down or made noticeable UI changes. This is a subtle upgrade.
It seems a bit snappier than 5.1. The Win32 version now embeds the IE browser engine if it's present, which improves web browsing from within the app. The IMAP mail support is a bit slicker, roughly on par with Netscape 4.x but with some extra niceties thanks to its integration with the rest of the suite. It ain't Outlook 2000 yet, but then it's also not succeptible to script macros in message bodies.
But the best improvement I've seen is in the MS Office import and export capabilities. It always did a better-than-average job of opening MS Office files, but it wasn't good enough to replace MS Office for shops with lots of Office documents floating around. Now, it's nailed every small to mid-sized Word, Excel and Powerpoint doc I've thrown at it, save for the Microsoft-dialect VBA macros, and it neither runs nor harms those. Based on my use of it over the past two days on Linux and NT, I now feel it's a viable product to roll into mixed MS Office environments for roles where VBA doesn't come into play.
Now that 5.2 plays nicer with MS Office files, I will definitely be evaluating it as a server-based X app for a 20-person call center I'm putting together.
The only thing any of these companies are selling are videotapes, brochures for investors, and simulation software. Exactly two of the three that claim to have a product have exactly one prototype apiece, each of which have flown a few hundred feet, and they won't make one for you at any price.
If you don't want any of this prime swampland I'm selling in New Jersey, I hear the Brooklyn Bridge is for sale.
What's wrong with convenience? If 14 million households have AOL accounts, why should they have to custom-program "email" "web" and "weather" keys on their keyboard, or go through menus to get to the 3 or 4 things they use their computers for 95% of the time?
What a bunch of babies y'all are. Is ease-of-use really so horrible? Why not just crawl under a rock and go back to flipping a panel of toggle switches to enter data like you had to on the Altair?
They're doing one using Mozilla as the basis for the editors, parsers, etc, It's in very early stages, though.
PHP's swell and all, but there aren't any IDEs for it, never mind slick, drag-and-drop RAD tools like Drumbeat 2000.
And PHP3 is still woefully two-tier. Where are the fully-supported APIs for talking to transaction servers or CORBA and COM objects? And why write your core logic in a language different from your outer layer, as you end up doing with PHP? At least with ASP you can leverage VB skills one a few layers.
Even JSP (which is especially nifty at the 3-tier game) has RAD tools bublling up. There's the JSP version of Drumbeat and IBM's WebSphere Studio. AFAIK, both only generate code certified for WebSphere, but that's more than there is for PHP.
I'd argue that QNX is what killed Coherent. Coherent, if I recall, was promoted mainly for "appliance" applications, not for business servers or desktops.
Call up your local IBM, Lotus or Sybase rep and ask them which x86 Unix-family OS they recommend for their products. Even a year ago, the answer would have been SCO. Not anymore. I'm told Sybase now even goes so far these days as to encourage their existing SCO customers to make the switch to Linux.
Oracle seems to be ramping up to do the same, given the pace at which they're porting much of their product line. The bigger-iron Unixes aren't being hurt much by Linux right now, and won't be until good support for SANs and 8-64 CPU servers finds its way in. Which it will. But in the 1-2 CPU server market, Linux is rapidly becoming software vendors' reference platform. It's hard to imagine SCO getting any new OS customers these days, save for the few shops picking Tarantella as their thin-client environment.
Looks like SCO is going to be the first Unix effectively killed by Linux. Sun will prop up x86 Solaris as long as it costs them practically nothing to recompile it. I'd wager BSDI/OS is next to go. BSDI's big selling points over *BSD were robustness and commercial support. The robustness gap has largely been closed, with things like Solaris and AIX RISC boxen more affordable from above, and Linux and *BSD eating its lunch from below. And anyone with a staff of smart techs and some seed money can set up shop providing support for the free OSes.
After playing with the latest builds of WINE over the weekend, I'm not surprised Corel was able to ship so quickly. Now, with an install of WINE with access to a real Windows system directory and a Truetype font server, I not only got Excel 97 working pretty decently(!), but I also got IE 5 to load a few pages. Properly. WIth DHTML working.
These are interesting times. Native apps are always best, but it's clear x86 Linux is heading to a place where you'll soon also be able to run most Windows software cleanly. Not a Terrible Thing for desktop penetration.
I suspect Corel WP Office 2000 doesn't suck, or at least doesn't suck any more than StarOffice 5.1a does. Corel can't market its way out of a paper bag, though. At least they pushed the WINE project ahead nicely.
I've long argued that this newfangled Internet thing won't really take off until a parallel network of pneumatic tubes is in place at every desktop.
The Internet's big flaw is its inability to trransport, say, kittens or french fries. Right now, if you want french fries over the 'net, you need to place an order which is then delivered by a person. Pneumatic tubes would make it possible to eliminate all human interaction.
With efficient digital switching systems in place, today's pneumatic tube networks could be made efficient enough to handle fully-automated person-to-person routing of the cargo cylinders.
Kittens direct to the desktop.