Lots of people prefer CDE of GNOME. Many Solaris desktops are X Terminals in large companies--say, at banks, financial services companies and so forth. The people who use them access e-mail, do data entry, and query old big-iron databases. You want such a system toi be free of distractions and clean and easy to use.
Few things are cleaner and simpler than a stripped-down CDE desktop. A drawer with the 4 or 5 most common applications, a clock, a trashcan, and a drag-and-droppable printer icon. No taskbar, no nested program menus, no disk icons, no desktop clutter.
It may be awful for an engineer (but then, maybe not; if you primarily use the command line, who needs all of GNOME's gizmos?) or a "power user", but CDE is great for heads-down managed environments like call centers, trading floors and so forth.
Yes, a modern, flexible desktop comparable to what MacOS and Windows offer is necessary for home and small-business use, and for some breeds of power user, but that's mostly because such users have to do nearly all of their own file and system maintenance. For someone who has no need for that--and that's true of many a work environment--the empty simplicity of CDE is a virtue. Not to mention easier to deploy, maintain and support on a network. CDE is terrible as a "general purpose" desktop. GNOME and especially KDE are far better for that. But the work that has to go into stripping down and locking down GNOME or KDE for ease of use in a 100-seat call center makes me cringe.
Maybe someday, Tim, you'll work for a company where Unix people have more than 20 desktops to worry about, where most of the people using those dektops aren't techies, and servers really have to be up 24/7.
Hmm. Is this the same person who asked about AS/400 access from Linux a few days ago? (The answer is the tn5250 for terminal and file xfer, and IBM's freely-available Java packages for richer AS/400 connectivity of all kinds, including administration and JDBC access to DB2/400.)
tn5250 also includes lp5250d, a daemon that will pass SCS print jobs to Unix print queues. Which is the opposite of what you're trying to do.
For you to use IPDS/SCS printers from Unix or Windows apps, you'll need either to do the translation through an AS/400 (create Windows/Unix print queues on your 400, and use it as a print server to get at the printers), or as others mentioned, get a new network module and possibly a Postscript or PCL cartridge for each of the printers. I'm pretty sure there aren't any free software PS-to-IPDS translators, but there may be some commercial ones. Check the AS/400 community sites like mindrange.com. There are active user communities out there and a lot of nice hacks and shareware for OS/400. Perl for the 400. Python for the 400. Tetris for the 5250 terminal, etc.
Why 640x480? That's higher resolution than broadcast TV. Do you need that? Broadcast TV is 460x360. Capturing at that resolution will lose you detail, of course, but if it's detail you can lose, your storage requirement just dropped by 40%.
And since you said retrieval can be "arbitrarily" slow, I'd look into using VHS videotapes--even if you store compressed digital on them--as a storage medium. They're slow as hell for rerieval, but the media might be cheap, especially compared to the likes of AIT and such.
Here's the skinny: StarOffice will open essentially any word, Excel and Powerpoint doc you throw at it. However, intricately formatted things (resumes, tightly laid out forms, "word art" drawings, etc.) won't lay out perfectly. Line breaks end up a bit different, graphic placement on presentation slides is sometimes a bit off, and so forth. Nothing terrible, but it does mean that certain heavily formatted things aren't easy to work on simultaneously in both environments. However, this seems to have improved vastly in the SO 6 betas.
Also, SO and MS Office have their own macro environments. SO won't harm MS macros, but it also won't run them. You can, however, get at the macro code and bring it to SO's own VBA clone environment and port the macros reasonably easily. Basically, if you have a lot invested in MS Office macros, switching out will cause some initial pain, and if you rely on running macros sent from outside, life will be rough. This is tru when dealing with any two different office suites.
As for training and usability, SO is picked up very easily by people who have used MS Office. The built-in help isn't nearly as good, and some advanced operations are a bit more tedious, but 90-95% of the time, things are where people expect them to be. And big thick books on it are available from the usual publishers.
SO's mail and calendaring client isn't MAPI-compatible. If an office is running Exchange servers, it's not going to cut it. It is, however a decent IMAP and POP mailer, a good newsreader, and does have good group calendaring of its own. No web interface though as of yet.
Rob, for a someone who considers himself a graphics guy, you have remarkably poor feel for the benefit of good design. This thing is half the weight and a quarter the size of the "better" Creative Nomad, can transparently sync with your MP3 collection out of the box using MP3-management software that's better designed, hands-down, than anything else out there. And it transfers the data a hundred or so times faster than the USB and IrDA interfaces on other such gadgets.
And it's got a readable screen, simple control layout, a well-designed UI and long battery life.
If you want a one-pound MP3 jukebox and you want to write your own software to transfer files and you don't mind spending a half hour transferring a couple dozen songs, I guess the Nomad "wins".
Apple's out to make easy to use consumer devices. That's what an iMac is. That's what an iBook is. And that's what the iPod is. Nomad and Archos jukeboxes are interesting gadgets in their own right, but they're not friendly, they're not easy to use, and they're not really designed. iPod may be too expensive right now to be a big seller, and the Mac-only factor will hurt sales too, but if you've got a Mac and you want a hard-drive MP3 player to listen to music on (as opposed to hack on, or do field recording on), it's the hands-down slickest thing around.
A word of advice: if you still plan on being a world-famous computer animator, let someone with some art skills design the characters and do the storyboarding. You should stick to the math and the wireframes.
NetMeeting can interoperate with any H.323 and T.120 compliant conferencing system. The H.323 part--the video and audio conferencing--is available under Linux, with apps like GnomeMeeting and the OpenH323 Project's foundational work.
But there's no free T.120 client for Linux. T.120 is the whiteboarding and application sharing part of the protocol.
DataConnection is the company that did the core work for both NetMeeting and Sun's SunForum, which is a feature-for-feature NetMeeting-alike for Solaris. Their generic name for the product is DC-Share.
Last year they ported the product to Linux, and also have a Java version--with, yes, app sharing--but they don't do direct sales.. just OEM and licensing deals. Contact them and see if anyone is selling a Linux client based on their software.
Why stop there? If you're certain that you're going to buy nothing buy the best when you eventually get some money, why not figure on getting a ruggedized P4 laptop with one of those phat 1600x1280 displays? I'm sure you can get one for about $7000. And maybe for your desktop you should get a Sun 450 with 4 processors for $30,000 or so.
Some of us have to live in the here and now and actually buy things we can afford. And a well-equipped iBook sells for over $1200 less than a similarly equipped and warrantied Powerbook G4. Yep, a G3 is a good 35% slower than a G4 for heavy Photoshop lifting, and yeah, an iBook can't drive two monitors--or even one high-res one. But if you don't need those things, spending an amount that can cover a mortgage payment or 4 car payments or a 5-day Caribbean vacation for two's worth of money on a "phatter" laptop comes down to personal choice.
A lot of graphics and video professionals need the power of a G4 laptop, and some don't have the luxury of getting both a desktop and a laptop. But an extra $1200 simply for the "cool toy" factor of a laptop that will likely be dead or useless in 3 years or less? Count me out.
killer $600 organizers
on
Pocket PC 2002
·
· Score: 3, Interesting
They're nice, much as the wave of Pocket PCs they're replacing were. But they still cost $600. $600 is what a lot of companies pay for their desktop systems these days. They have their place, and they'll sell all right.. but nobody has yet come out with a usable $150-$300 Pocket PC, and that's what most Palms sell for, even color ones now.
Palms do a lot less. They store less. They can't play MP3s without extra hardware, can't run a WinFrame client decently, and so on. They're also cheap enough to be an impulse purchase or a cheap corporate gift to employees. Some companies give senior managers Pocket PCs. But other companies give low-end Palms to pretty much anyone on a yearly salary.
The $450 high-end Palms don't compete well on features with the fancy Pocket PCs, though they are markedly simpler and quicker to use for the core organizer functions. But Palm's bread and butter nowadays is the low-to-midrange, as it is for Handspring too. And the Pocket PC devices just don't compete there at all.
Palm does need to boost its specs and give the OS a facelift soon, and they seem to be working on that with their announced move to RISC processors and the Be acquisition. But you can bet they'll stick to $200 mass-market PDAs and leave the $600 devices to whoever wants them. And all the talk about Compaq's iPaq beating Palm in sales numbers is based on dollars--on a low-margin, high-cost product. And with the Palm III/m100 series making up the bulk of Palm sales during that period, that still meant Palm was beating them by at least 3:1 in unit sales.
What IE 5.1 for the Mac should be doing is decoding the Binhexed file and then handing the decoded file back to its (IE's) MIME and Mac creator handler again, as though it were the original downloaded file, and apply the appropriate rules, whether to save, launch, or whatever.
In other words, if the normal behavior when encountering an image/tiff file is to open it in Photoshop, then that is what should happen to a binhexed TIFF. If it's an.sit from Stuffit, Stuffit Expander might be launched. If it's an Excel spreadsheet and the preferences are set to open those, then open it it should.
The problem here is that it sounds like IE is handing the decoded file to OS X's "file open" handler (the call made when double-clicking an icon in the Finder) instead of to IE's "file download" handler, which checks MIME-handling rules and security zones set in IE and systemwide preferences.
Not unlike an incident I remember back in 1995 during the Windows 95 betas, when the original webless MSN was opened to content developers. It used a Windows Explorer metaphor, with online content organized as folders and icons. Content providers were encouraged to post RTF documents as content, but any file was fair game. Thing was, when users double-cliked on files to open them, they were treated like local files. Some of the earliest Word macro viruses got spread this way. I remember being shown this at a beta developers' convention before the first macro viruses even hit and asking if it could pass opened files through the user's virus scanner before opening them. "No, we hadn't thought of that," said an engineer. Horrified looks and some intensive scribbling on notepads followed, though nothing was done in time for launch beyond a useless request to content providers that they try to scan things for viruses before posting them.
The song is directly, and utterly without metaphor, about the plane crash that killed Buddy Holly, Richie Valens and J.P. Richardson (the Big Bopper), and how the narrator's world hadn't been the same since, socially, politically, musically and personally.
McLean's point--and it's a pretty simple one; he isn't exactly James Joyce--is that that plane crash marked the end of the sheltered certainties of the 1950s and the start of what for him were the far more confusing and tumultuous 1960s (Dylan to cute Beatles to scary Beatles to the Summer of Love to Vietnam to Janis Joplin to more, scarier Vietnam).
"American Pie" isn't a deep song or a complex one, nor is it one open to terribly flexible interpretation. Which doesn't mean it isn't heartfelt or affecting or a good starting point for high school students to look at the 1960s from the perspective of someone whose world changed on February 3, 1959, when a plane crash killed three rock'n'roll singers. Period. It's not a "secret". It's not a "wacky interpretation". It's not a "hidden meaning". It's what the song's about. Sort of like how, say, John Lennon's "Oh, Yoko" is about Yoko and not about, say, the Iranain revolution or basketball.
Ask your parents. Or read any of the thousands of tedious interviews poor Don McLean has had to slog through in the decades since.
"American Pie" is a song about a plane crash. I think I can go a few weeks without songs about plane crashes unless maybe someone writes or unearths a fitting one relevant to this that makes life more bearable.
VA is out of the hardware business. They're also out of the contract hardware support business. Their remaining products are software and professional services, with an overwhelming emphasis on servers: storage management and clustering, SourceForge and so forth.
The occasional professional services gig that involves rolling out 3D engineering and CGI workstations hardly justifies keeping lead Mesa and DRI developers on board. Nearly all of VA's engagements deploy machines that never run in a graphic mode, and indeed often don't have a monitor connected at all.
As for Loki, they claim to have a positive cash flow now. Bringing on video driver developers might not be something they can afford, though, especially while under bankruptcy protection. Loki develops for a small market with low margins: gamers using Linux desktops more or less exclusively. I'd sooner think that DRI and Mesa developers would find a home with companies making high-end 3D design and animation tools, and with consumer electronics companies making video-related appliances.
StarOffice 5.2 is so resource-hungry and slow that it might as well have been written in Java 1.1. Waiting a solid minute or so for it to fire up on a P2/300 with 192MB RAM, and running into its native widget set, it's easy to unserstand why someone might think it was written in Java. Less easy to understand is why ZDNet seems to have fired all of its fact-checkers.
The OpenOffice development snapshots are definitely peppier, so StarOffice 6.0 should be fine in this regard.. but 5.2.. eek.
Where Java does enter the StarOffice picture is that 5.2 has an open interface that lets you pick a JVM--or install one--to use as yet another macro language. This is a nice touch for all the Unix shops and others that have Java programmers on hand more readily than VBA people. You can use a nice, fast 1.3.x JVM with it, and develop with your existing tools and components. The other nice "Java" feature is SO 5.2's ability to use JDBC throughout for database access instead of native drivers or ODBC. Very useful and very elegantly cross-platform on Sun's part.
And incidentially, the "other" major SO5.2 scripting language is a VB clone, both in syntax and coding environment. SO has a different document object model, so MS Office macros won't run unmodified, but at least VBA skills can carry over. KOffice's use of DCOP for automation allows the use of any available language, potentially doing things one better--but without integration with a development tool as one gets with VBA and StarBasic, it remains at a disadvantage. Maybe bidirectional KOffice-to-KDevelop hooks (for C++) and KOffice-to-Netbeans/Forte (for Java) are a way to go.
Linux is fine for point-of-sale systems. It just isn't used for many at this point, and OS dogma isn't a good reason for existing vendors to rush into it when they have products that work already.
As for Apache, MySQL and Perl/PHP/Python as the basis of such a system.. well.. I'm sure there's worse out there, but I don't think too many stores would want to use a web browser as their cash-register interface. You do intend to use a browser, right? Web browsers are bad tools for quick, reliable data entry. Too much scrolling and mouse movement.
Also, you'd have to write browser plugins to control and access things like a cash drawer, a signature tablet and a UPC scanner. Again, not out of the question, but sort of unneccessary.
And as far as the backend goes, why MySQL? Postgres is much more robust and provides an environment more in line with what you get in a commercial database. Once your data model starts to get complicated and you're doing a lot of inserts and updates, it's going to look like a better choice.
Python is a very nice language, though once you're putting it behind an HTTP server, you may consider Zope in place of Apache. PHP? Seems kind of limiting. Perl's not going to make for the most maintainable codebase. But language isn't really the issue. Architecture is. And maybe maintainability too.
An HTTP backend might be okay, though the fact that it's stateless and doesn't offer a satisfactoy way to push out alerts from the central server is a drawback. This is, after all, a network of cash registers you're building here, not a public website.
If it's still going to be HTTP, and the push-pull issue can be resolved elegantly, I'd just use HTTP as a transport layer and instead of a browser and write the frontend as a custom ncurses application (console mode!) with access to the esoteric hardware, and client-server communication via SOAP. And quite likely instead of HTTP, I'd consider something more persistent and two-way for the SOAP transport...though tiny HTTP listeners on the clients wouldn't be out of the question.
The language and "app server" engine? Those are the least important choices. Any combination that is easy to deploy, is reliable, and is easy to maintain and extend will do. Java on Tomcat/EJBoss? Python on Apache or Zope? Standalone Perl with SOAP::Lite? Whatever.
You've never used a point-of-sale system, have you
on
NYSE Goes To Linux
·
· Score: 2
Most mainstream PC-based point-of-sale systems are console applications or, if they're graphical at all, they run in a VGA framebuffer mode. The server OS might be NT, Novell or OS/2, purchased at an OEM price of under $600. Sometimes a whole lot less than $600.
The point of sale terminals themselves often aren't running Win9x or any version of Windows, for that matter, though of course some do. A mouse is seldom involved. Indeed, there usually isn't any pointing device. Just a keyboard (or just a POS keypad), maybe a barcode scanner, a touchscreen or a signature capture pad, and a cash drawer.
Yes, the application could be made cheaper. The vendor could eliminate $200-$600 in server OS costs, and anywhere from $20-$120 per terminal in client OS costs.
The POS system itself probably sells to the customer for, say, $30,000, including hardware, software, installation and setup, integration with your accounting system (which isn't running on Linux, I'd wager), and a 3-5 year support contract.
The vendor's hardware costs might be $1500 for the server box, $700 for each PC, and something like $800 for each PC's POS hardware peripherals. So let's say the hardware for the whole 5-station system costs them $9000. Those OS licenses might be adding a thousand dollars to each 5-station system going out the door. And though your POS terminals can be Pentiums since they're not doing much processing, theyaren't Pentiums because you can't buy new Pentiums. You buy hardware that your company will be comfortable supporting for 5 years or more, and that means hardware consistency is a major goal. You might buy PCs a thousand or more at a time, and servers a hundred or more at a time in order to ensure a 6-month (or longer) supply of identical hardware with identical drives, controllers, video cards, motherboard layouts, NICs and BIOS revs. Mix and match is foolish if you're in a business making a lot of its money from fixed-price support contracts.
So your assignment is to tell me how many of these typical 5-station POS packages a vendor has to sell with Linux at a savings of (and I'm being generous here) $1000 each in order to justify the money spent porting the application, testing it, and hiring and training a second team of customer support and professional services people to support this second version of software that wasn't broken in the first place.
Now you're porting the software. The current vision was written in, say, VB or maybe C or maybe even some kind of Pascal, or, even more likely, some Foxbase-family language, and calls to a smallish relational database engine whose main strength is that it runs for weeks or months at a time without any maintenenace beyond swapping backup tapes. It's old code in an old version of an old language, and it's tied to one (probably old) database engine. Porting isn't going to be a simple matter of recompiling and changing an ODBC DSN. It's going to be work. Work that will result in a more modern, portable application, but work nonetheless. Still want to do it? Great. Now put the porting team together.
Remember: hiring a junior-level programmer you're paying $45,000/year to is costing your company $60,000 once you pay them benefits, train them and give them a desk and a PC. And one programmer isn't going to be able to do the port, write the new manuals, do the QA, revamp the customer training course, and provide tech support. There are a few bodies involved.
Linux will find its way into point-of-sale systems, just as it's found its way into shop-floor terminals in factories and warehouses. But it will only get there in the context of new products, or as a result of clean-slate rewrites of applications when an old version can no longer be extended and upgraded effectively. And those aren't done on a whim.
It's not a matter of "big iron" and "geek desktops". It's about servers. The reason you don't see point-of-sale systems on Linux is that Linux--like any Unix--is still a relatively awkward choice for standalone and small-network desktop use. It's easy enough to get running for one-off engineering workstations and for hundreds or thousands of X terminals, but the cost savings and overall benefits of a Unix just aren't there for those 5-100 seat mixed-use installations found in most desktop environments.
Want a stable, non-windowed PC-based cash register? Linux gives you nothing you can't get with DOS, Netware or OS/2-based systems. There's little reason for vendors to port, and the application is so narrow that Linux offers nothing but a savings on OS licenses, which are insignificant to the cost of a 5-station point-of-sale system.
Running a small- to mid-sized office? Linux is a decent way to save on servers, and many companies do so, buying mail and file-sharing appliances like Cobalt Qubes, or IBM's Small Business Server software bundle, which gives small but ambitious companies a nicely priced bundle of DB2, Domino and Websphere. Still others bring on the accountant's nephew to set up a Samba server or two. But on the desktop? Unix and Linux office suites are mediocre at best, the best being slower and more memory-hungry than MS Office. And you can be the one to tell the senior managers how good Linux is the tenth time they can't properly open an MS Office file that was mailed to them.
Where Linux is taking over the world is on servers, and now it's not just the usual HTTP, Samba, DNS and SMTP services. In the past year, with good 1.3.x JVMs from Sun and IBM, Linux is now on par with any other platform, dollar for dollar, for running J2EE application servers.
If you're running clusters of Weblogic, Websphere or other EJB/servlet/JSP engines (Tomcat, JRun, EJBoss, etc.), there's simply no longer any technical reason to do it on Solaris, HPUX, Win2K or AIX. If you have a decent JVM (as Linux has) and decent networking and memory management (as Linux has, especially with 2.4), that's all that really matters. Why pay $700, $3000 or more on OS licenses and OS support per machine for something that you just want to (1) stay up and (2) run a Java app server or one or more of its support systems like a message queue?
Moreover, the move to journaling filesystems and better support for external storage, and the availability of many mainstream commercial-grade backup and system management tools means Linux is also a perfectly good way to run all those 1-4 CPU database servers. Oracle and DB2 on Linux aren't going to eat into the Sun E10000's turf or IBM's OS/400 and System/390 spaces just yet, but all those databases running on 1U-5U rack equipment with storage in the.5TB range can run on Linux now. And that's a lot of databases.
Add to that the fact that Linux has become (officially or not) the reference platform for a lot of Unix software, and the reference x86 Unix for many others (see Sybase) and Linux looks poised to eat not just the low end but also the middle of the server market.
The success of server-side Java has a lot to do with this. Right now, the overwhelming share of new server-side development is being done either with the MS platform (ASP, MTS, COM and the early bits of.NET) or with Java. And since that Java code really does move--unmodified--from Windows developer workstations to staging servers and production boxes that can be running any of a good dozen OSes on hardware going all the way up to mainframes, with application servers that are increasingly interoperable and interchangeable, Java's looking pretty good.
I've been using Mozilla and Netscape 6.x about half the time for a few years now, and the past few months have brought dramatic speed improvements. XUL is finally fast enough to be usable on machines slower than a 1.2 GHz x86, and mail folders open quickly enough to work with.
Mozilla 1.0 isn't a terribly meaningful concept, especially given that 0.9.3 served as the core of a genuinely commercial-quality Netscape 6.1--at least in most respects. But I do have a question for those who Mozilla or Netscape 6.x as their primary browsing and mail tool:
What's everyone doing about proper MIME support? Don't you people (and the developers!) ever send non-text e-mail attachments? Mozilla and Netscape 6 ship with virtually empty mimeTypes.rdf files and no auto-build from exisiting legacy MIME settings whether at the system level or from old Netscape 4.x configs, which means out of the box no external helper apps work--and worse, outbound email attachments other than HTML, text/plain, GIFs and JPEGs are mangled, transported as inline text. These empty MIME settings are years old.
Even more upsetting, the dialogs to edit and create mimeTypes entries from inside Mozilla/NS6 are broken: the checkbox that activates outbound MIME type declaration for a given mimetype is inactive, leaving hand-editing the poorly-documented RDF file as the only recourse. Not only that, but the Un*x Mozilla/NS6 doesn't seem to use the current environment in launching helper apps. Is it so hard or insecure or distressingly platform-specific to have the PATH environment variable--or use of "which" or "locate"--when launching helpers? Why must users manually locate the fully qualified path to their MP3 player, PDF viewer and so forth instead of simply entering, say, "acroread" or "xmms" in the dialog (or the RDF)?
Are the Netscape/Mozilla developers and those of you who claim to use Mozilla full-time passing around a hacked-up mimeTypes.rdf that isn't being shared with the public, and isn't even in an experimental branch of CVS? Or do you just never send email attachments?
And more to the point: doesn't the Netscape 6.x dev team ever send email attachments? How about the QA team? Are they all using Pine instead? And if they are, how does that jibe with the idea of eating dogfood?
Does Netscape even have a QA team?
I've thought of fleshing out mimeTypes.rdf myself, but I can't even figure out who owns it. Mail/News? Prefs? The core browser team? With the way the project owners point fingers, can I expect anyone to lay claim to it at all?
Maybe this is the problem.
Don't listen to anyone who says AOL's buyout has derailed the Mozilla project. They're clearly not taking an active role at all.
1.0 means different things in different projects, but one would expect nearly a year into the.9.x series--and two months from the putative release of a 1.0--that proper test code would be in place for core functionality like this and that things would be in a bug fix stage, not that inbound and outbound MIME handling would still be awaiting its first real-world testing two months before 1.x and more than a year after the release of Netscape 6.0.
Sounds to me like they're trying to retrieve email directly from a POP server or something; the aid worker who set that up should be fed to pack of wildebeests or tigers.
They should be using UUCP to send and receive mail via a series of relays that pass mail along one step at a time through machines that dial up in the chain periodically, fetch whatever they can before getting cut off, and get (or send) the rest next time. This is what UUCP was designed to do back in the days when a whole lot of email was transported via multiple hops of unreliable dialup. It also gets people out of the business of using the expensive, unreliable dialup connection to sit around trying to read and compose mail--activities that should be done fully offline. The only machine(s) that should be connecting to an ISP are the ones that can reach it easily, i.e. in the city where the dialup line is located. The rest of your locations should be connected by dialing into a designated parent at off-peak-times, and retrieve messages for any machines downstream from them.
When a message reaches its destination machine, it can then be read, replied to, whatever, and the multi-hop journey back begins. The SMTP servers at each hop should be configured to reject or truncate large messages, since the whole system can get bogged down by one big file attachment that can never make it over an unreliable dialup connection.
I'm also a bit confused by the reliance on (cellular?) phone modems. Surely the region would be better and more cheaply served by amateur radio. It probably is already, in fact, and your organization just may not be in contact with any hams. Amateur radio has been used for low-speed data transmissions over very long distances for decades, and for wireless UUCP in remote areas for many years. Data transmission speeds might be slow, but it's reliable, it's dirt cheap (25-year-old shortwave-band transceivers and 10-year-old packet modems should be easy finds if you can't get them donated), and as long as you can supply some electricity and keep the equipment in good shape, you can run it around the clock.
Depending on the distances and terrain, the weather, the presence of jamming activity in the area and your ambition level, you could eventually branch out from UUCP and experiment with realtime BBSes via radio. Unless I'm mistaken, quite a few branches of Fidonet were available via packet in Fido's heyday.
I'd look at HOWTOs and docs for UUCP (which isn't just for Unix; you can run UUCP nodes on pretty much any OS including DOS) and at the Linux HAM-HOWTO for some starting points.
It goes without saying that this kind of behavior is expected from Microsoft, nevertheless, has anyone gotten Opera to work with Hotmail?
Oh, grow up. (You too, some of you other editors.) Not everything in this world is part of the great evil Microsoft master plan to crush Scandinavian software developers. The only web developers who even bother testing their sites with Opera at all are the ten or twelve of them who regularly use Opera themselves.
Netscape browsers now have a market share somewhere just north of 5% when the wind is blowing right--and that's the old 4.x Netscape. Mozilla and Netscape 6.x are statistically indistinguishable from zero once you leave Slashdot and Mozilla.org, which themselves aren't exactly big draws in the scheme of things.
Does Opera even account for one half of one percent of all web traffic to mainstream, general-interest web destinations like Yahoo, MSN, Amazon and so forth?
Microsoft isn't trying to sneakily shut out Opera users. They are trying to shut out users who block cookies, but that's to be expected from a web service like Hotmail that depends on ad and cross-marketing revenue for its existence. And they couldn't care less about Opera.
Netscape, however, is another story: with the ongoing antitrust action MS has to continue some degree of support for their browsers, even as they've become economically questionable to support. Just because 1/3 of Mac users (who make up 5% of web traffic) and 95% of desktop Unix/Linux users use Netscape doesn't mean those 2% of the whole are really worth spending development money on.
Steve McConnell's Code Complete and Rapid Development
Stephen Levy's Hackers
Cliff Stoll's Silicon Snake Oil
Douglas Coupland's Microserfs
The Cathedral and the Bazaar
For the practical, replace-every-3-years, people-will-find-them-useful shelf:
The Dummies books on the most basic stuff everyone uses: MS Word, MS Excel, Excel macros, and the current versions of Windows. The series as a whole is very spotty, but these are solid, helpful guides.
Judith Bowman's Practical SQL Handbook. A solid, easy-to-follow tutorial in the basics of SQL that won't go stale. The same can't be said for the bundled CD of an old Sybase personal server.
Unix System Administration Handbook, 3rd Edition, by Hein, Nemeth, Seebass et al., a great warhorse that always opens to something useful. Possibly the only pure "Unix" book better than its O'Reilly counterpart. So well done that the last edition, some 10 years old now, is still useful, a real rarity in reference titles. I'd give this one a good 5-7 years of use.
O'Reilly's Learning Perl. As an intro tutorial, and a very good one, it should remain useful longer than a reference title.
An HTML tutorial and O'Reilly's XHTML and Javascript books. Maybe. They'll be more obsolete than a PDP-8 book in a few years, but they'll get used now.
A book on DIY PC repair. In paperback. With lots of pictures and step-by-step instructions. It will be laughable in a decade, but I think library patrons would find it useful.
A tutorial on Visual Basic.
In general, I'd skip all but the most elegant half dozen or so books on programming languages because of the shelf-life issue. Think Kernighan and Ritchie on C and maybe things like Bruce Eckel's Thinking in Java, which is as timelessly abstract a Java book as I've seen. But Java will be unrecognizable in 5 years, so tread lightly here.
Get nothing on web development other than an HTML book or two. Those are useless after one year, never mind five.
For Palm to stay in their longstanding $200-$450 price range, this move is right on schedule. Palms have been shipping for about 5 years now, just over 3 generations of Moore's Law. Since the original Palms were 20 MHz 68030-class computers, it should be possible to produce something 8-10 times faster overall with 8-10 times the memory. This roughly translates to 150-200 MHz ARM-based systems (right on target) with 4MB RAM in the lowest-end devices (think m100) and several times that in the high-end ones.
Do all the math and you can easily come up with roughly the same hardware spec as a current iPAQ handheld, but about $200 cheaper since it will hit the market about a year later, which in 2002 puts a color 200 MHz ARM-based device with 16-32MB memory built in right in Palm's pricing sweet spot.
While Compaq will be targeting its $500-$600 price range with lovely 300 MHz 64 MB devices, this hypothetical $400 Palm device should be comparable performance-wise to the current iPAQ, but with longer battery life and what will probably be transparent support for all Dragonball Palm apps. They're not dead yet.
The question was whether there are alternatives to PDF for which there are readily available viewers.
The answer is no.
In the mid-'90s, there were a couple of competing technologies, each with its own proprietary viewer. Among the worst was Corel's Barista, which used JVM 1.0 applets for a viewer. It was a nice idea that the early capabilities of Java made unworkable.
Among the best was Common Ground, which was a lot like Acrobat with the added advantage of having a very lightweight viewer. For people without the plugin or standalone viewer, you could distribute Mac and Windows executables of the document with a self-contained viewer that was in the ballpark og 40K in size. By 2.0, they also had a viewer applet in Java. However, the quality of the documents produced wasn't as good as Acrobat's. It worked well for word processor documents and spreadsheets, but wasn't good for line art and desktop-publishing output. Hummingbird acquired them and tried to turn it into a universal viewer technology for its document management system. After a while, unable to catch up with Adobe in terms of document quality, they discontinued it.
Net-it Now was another such tool. Again, it wasn't as good as Acrobat. Its niche was the use of Java (and later, ActiveX) viewers. Since Adobe eventually got Acrobat Reader distribution almost universal, the product didn't really have a compelling niche and it too was discontinued. I think parts of it live on in some Lotus/IBM products like SmartSuite.
Postscript files (compressed or not) are not a viable substitute unless you're only distributing your content to Slashdot readers and Unix sysadmins. Whereas some 95% of desktop users have a PDF viewer (usually Adobe's), fewer than 5% of people have a Postscript viewer, and many of those would have trouble making it work with a downloaded file.
Getting rid of your PDFs is a nice political statement, but shitty business practice. PDFs--especially properly hyperlinked ones--are the only decent way to distribute print materials like brochures and manuals reliably to end users. Make people download Ghostscript (with its awful installers), the Ghostscript core font set (with its manual installation process) and GSView? You try telling someone who is paying you thousands of dollars for your products or services to do that. I won't.
If you want to make a point, go ahead and add some (polite, professional) text to your pages with PDF download links noting that PDF is a convenient format regrettably put out by a company opposed to freedom of speech that also produces insecure products unfit for use with sensitive information. Offer a polite link to, say, the EFF's website for more information.
For your own part, maybe you can make a point of making any new PDFs without Adobe's tools. Say, ps2pdf if you don't need hyperlinking or color profile support. Or libpdf-based tools and libraries (from Perl, PHP, C, whatever) for PDFs you generate on the fly from raw content.
But don't get shrill and don't make it hard for your users and potential customers to get what they need in an easy and timely way. That just makes you look like an amateur and an idiot.
Their database is old and doesn't seem to be all that big. They don't seem to honor boolean terms. They'll throw back dozens or hundreds of related pages from the same part of the same site without grouping them or squelching them. No apparent support for fuzzy spelling variations.
And when Apache and Debian show up at the top of a query on "Linux", it throws the sophistication of Google's relevance calculations into relief. Apache and Debian are linked from a ton of web pages, but the overwhelming majority of those pages are message board postings and message board TOCs or things like "This site runs on..." page footers. What this says to me is that Teoma isn't doing a good job of weighting the relevance and prominence of inbound links. It's as though it's going purely on the raw number of times the search term appears in a page linking to Site x regardless of how many are clearly identical and thus probably links from menus and TOCs, and not from the pages' unique content, where a link should count far more.
If LinuxToday, that cheesy little newswire-excerpt site with the amateur design, is a major Linux news portal, then I'm the Archduke of Luxembourg.
And Internet.com! Isn't that the flagship publication of INTM, the company that operates the burned-out husks of Mecklermedia's trade papers and Earthweb's awful developer portals? Internet.com gets respectable traffic numbers, but they're not exactly in ZDNet or CNet territory.
I'm shocked--shocked--that a dorm-room project like LinuxToday would engage in planted self-promotion.
Does LinuxToday even pay for its wire feeds? I'm not sure the entire lead paragraphs og stories constitutes fair use.
As more sites refuse to serve content unless they can set and read back a cookie, the part of the web you'll be able to surf is going to get mighty small soon. It's happening already.
And it'll get even smaller when content only loads after the successful playback of a 30-second animated commercial, enforced by more cookies and some scripting to render the content itself.
Slashdot Mirror
Lots of people prefer CDE of GNOME. Many Solaris desktops are X Terminals in large companies--say, at banks, financial services companies and so forth. The people who use them access e-mail, do data entry, and query old big-iron databases. You want such a system toi be free of distractions and clean and easy to use.
Few things are cleaner and simpler than a stripped-down CDE desktop. A drawer with the 4 or 5 most common applications, a clock, a trashcan, and a drag-and-droppable printer icon. No taskbar, no nested program menus, no disk icons, no desktop clutter.
It may be awful for an engineer (but then, maybe not; if you primarily use the command line, who needs all of GNOME's gizmos?) or a "power user", but CDE is great for heads-down managed environments like call centers, trading floors and so forth.
Yes, a modern, flexible desktop comparable to what MacOS and Windows offer is necessary for home and small-business use, and for some breeds of power user, but that's mostly because such users have to do nearly all of their own file and system maintenance. For someone who has no need for that--and that's true of many a work environment--the empty simplicity of CDE is a virtue. Not to mention easier to deploy, maintain and support on a network. CDE is terrible as a "general purpose" desktop. GNOME and especially KDE are far better for that. But the work that has to go into stripping down and locking down GNOME or KDE for ease of use in a 100-seat call center makes me cringe.
Maybe someday, Tim, you'll work for a company where Unix people have more than 20 desktops to worry about, where most of the people using those dektops aren't techies, and servers really have to be up 24/7.
Hmm. Is this the same person who asked about AS/400 access from Linux a few days ago? (The answer is the tn5250 for terminal and file xfer, and IBM's freely-available Java packages for richer AS/400 connectivity of all kinds, including administration and JDBC access to DB2/400.)
tn5250 also includes lp5250d, a daemon that will pass SCS print jobs to Unix print queues. Which is the opposite of what you're trying to do.
For you to use IPDS/SCS printers from Unix or Windows apps, you'll need either to do the translation through an AS/400 (create Windows/Unix print queues on your 400, and use it as a print server to get at the printers), or as others mentioned, get a new network module and possibly a Postscript or PCL cartridge for each of the printers. I'm pretty sure there aren't any free software PS-to-IPDS translators, but there may be some commercial ones. Check the AS/400 community sites like mindrange.com. There are active user communities out there and a lot of nice hacks and shareware for OS/400. Perl for the 400. Python for the 400. Tetris for the 5250 terminal, etc.
Why 640x480? That's higher resolution than broadcast TV. Do you need that? Broadcast TV is 460x360. Capturing at that resolution will lose you detail, of course, but if it's detail you can lose, your storage requirement just dropped by 40%.
And since you said retrieval can be "arbitrarily" slow, I'd look into using VHS videotapes--even if you store compressed digital on them--as a storage medium. They're slow as hell for rerieval, but the media might be cheap, especially compared to the likes of AIT and such.
Here's the skinny: StarOffice will open essentially any word, Excel and Powerpoint doc you throw at it. However, intricately formatted things (resumes, tightly laid out forms, "word art" drawings, etc.) won't lay out perfectly. Line breaks end up a bit different, graphic placement on presentation slides is sometimes a bit off, and so forth. Nothing terrible, but it does mean that certain heavily formatted things aren't easy to work on simultaneously in both environments. However, this seems to have improved vastly in the SO 6 betas.
Also, SO and MS Office have their own macro environments. SO won't harm MS macros, but it also won't run them. You can, however, get at the macro code and bring it to SO's own VBA clone environment and port the macros reasonably easily. Basically, if you have a lot invested in MS Office macros, switching out will cause some initial pain, and if you rely on running macros sent from outside, life will be rough. This is tru when dealing with any two different office suites.
As for training and usability, SO is picked up very easily by people who have used MS Office. The built-in help isn't nearly as good, and some advanced operations are a bit more tedious, but 90-95% of the time, things are where people expect them to be. And big thick books on it are available from the usual publishers.
SO's mail and calendaring client isn't MAPI-compatible. If an office is running Exchange servers, it's not going to cut it. It is, however a decent IMAP and POP mailer, a good newsreader, and does have good group calendaring of its own. No web interface though as of yet.
Rob, for a someone who considers himself a graphics guy, you have remarkably poor feel for the benefit of good design. This thing is half the weight and a quarter the size of the "better" Creative Nomad, can transparently sync with your MP3 collection out of the box using MP3-management software that's better designed, hands-down, than anything else out there. And it transfers the data a hundred or so times faster than the USB and IrDA interfaces on other such gadgets.
And it's got a readable screen, simple control layout, a well-designed UI and long battery life.
If you want a one-pound MP3 jukebox and you want to write your own software to transfer files and you don't mind spending a half hour transferring a couple dozen songs, I guess the Nomad "wins".
Apple's out to make easy to use consumer devices. That's what an iMac is. That's what an iBook is. And that's what the iPod is. Nomad and Archos jukeboxes are interesting gadgets in their own right, but they're not friendly, they're not easy to use, and they're not really designed. iPod may be too expensive right now to be a big seller, and the Mac-only factor will hurt sales too, but if you've got a Mac and you want a hard-drive MP3 player to listen to music on (as opposed to hack on, or do field recording on), it's the hands-down slickest thing around.
A word of advice: if you still plan on being a world-famous computer animator, let someone with some art skills design the characters and do the storyboarding. You should stick to the math and the wireframes.
NetMeeting can interoperate with any H.323 and T.120 compliant conferencing system. The H.323 part--the video and audio conferencing--is available under Linux, with apps like GnomeMeeting and the OpenH323 Project's foundational work.
But there's no free T.120 client for Linux. T.120 is the whiteboarding and application sharing part of the protocol.
DataConnection is the company that did the core work for both NetMeeting and Sun's SunForum, which is a feature-for-feature NetMeeting-alike for Solaris. Their generic name for the product is DC-Share.
Last year they ported the product to Linux, and also have a Java version--with, yes, app sharing--but they don't do direct sales.. just OEM and licensing deals. Contact them and see if anyone is selling a Linux client based on their software.
Why stop there? If you're certain that you're going to buy nothing buy the best when you eventually get some money, why not figure on getting a ruggedized P4 laptop with one of those phat 1600x1280 displays? I'm sure you can get one for about $7000. And maybe for your desktop you should get a Sun 450 with 4 processors for $30,000 or so.
Some of us have to live in the here and now and actually buy things we can afford. And a well-equipped iBook sells for over $1200 less than a similarly equipped and warrantied Powerbook G4. Yep, a G3 is a good 35% slower than a G4 for heavy Photoshop lifting, and yeah, an iBook can't drive two monitors--or even one high-res one. But if you don't need those things, spending an amount that can cover a mortgage payment or 4 car payments or a 5-day Caribbean vacation for two's worth of money on a "phatter" laptop comes down to personal choice.
A lot of graphics and video professionals need the power of a G4 laptop, and some don't have the luxury of getting both a desktop and a laptop. But an extra $1200 simply for the "cool toy" factor of a laptop that will likely be dead or useless in 3 years or less? Count me out.
They're nice, much as the wave of Pocket PCs they're replacing were. But they still cost $600. $600 is what a lot of companies pay for their desktop systems these days. They have their place, and they'll sell all right.. but nobody has yet come out with a usable $150-$300 Pocket PC, and that's what most Palms sell for, even color ones now.
Palms do a lot less. They store less. They can't play MP3s without extra hardware, can't run a WinFrame client decently, and so on. They're also cheap enough to be an impulse purchase or a cheap corporate gift to employees. Some companies give senior managers Pocket PCs. But other companies give low-end Palms to pretty much anyone on a yearly salary.
The $450 high-end Palms don't compete well on features with the fancy Pocket PCs, though they are markedly simpler and quicker to use for the core organizer functions. But Palm's bread and butter nowadays is the low-to-midrange, as it is for Handspring too. And the Pocket PC devices just don't compete there at all.
Palm does need to boost its specs and give the OS a facelift soon, and they seem to be working on that with their announced move to RISC processors and the Be acquisition. But you can bet they'll stick to $200 mass-market PDAs and leave the $600 devices to whoever wants them. And all the talk about Compaq's iPaq beating Palm in sales numbers is based on dollars--on a low-margin, high-cost product. And with the Palm III/m100 series making up the bulk of Palm sales during that period, that still meant Palm was beating them by at least 3:1 in unit sales.
What IE 5.1 for the Mac should be doing is decoding the Binhexed file and then handing the decoded file back to its (IE's) MIME and Mac creator handler again, as though it were the original downloaded file, and apply the appropriate rules, whether to save, launch, or whatever.
.sit from Stuffit, Stuffit Expander might be launched. If it's an Excel spreadsheet and the preferences are set to open those, then open it it should.
In other words, if the normal behavior when encountering an image/tiff file is to open it in Photoshop, then that is what should happen to a binhexed TIFF. If it's an
The problem here is that it sounds like IE is handing the decoded file to OS X's "file open" handler (the call made when double-clicking an icon in the Finder) instead of to IE's "file download" handler, which checks MIME-handling rules and security zones set in IE and systemwide preferences.
Not unlike an incident I remember back in 1995 during the Windows 95 betas, when the original webless MSN was opened to content developers. It used a Windows Explorer metaphor, with online content organized as folders and icons. Content providers were encouraged to post RTF documents as content, but any file was fair game. Thing was, when users double-cliked on files to open them, they were treated like local files. Some of the earliest Word macro viruses got spread this way. I remember being shown this at a beta developers' convention before the first macro viruses even hit and asking if it could pass opened files through the user's virus scanner before opening them. "No, we hadn't thought of that," said an engineer. Horrified looks and some intensive scribbling on notepads followed, though nothing was done in time for launch beyond a useless request to content providers that they try to scan things for viruses before posting them.
The song is directly, and utterly without metaphor, about the plane crash that killed Buddy Holly, Richie Valens and J.P. Richardson (the Big Bopper), and how the narrator's world hadn't been the same since, socially, politically, musically and personally.
McLean's point--and it's a pretty simple one; he isn't exactly James Joyce--is that that plane crash marked the end of the sheltered certainties of the 1950s and the start of what for him were the far more confusing and tumultuous 1960s (Dylan to cute Beatles to scary Beatles to the Summer of Love to Vietnam to Janis Joplin to more, scarier Vietnam).
"American Pie" isn't a deep song or a complex one, nor is it one open to terribly flexible interpretation. Which doesn't mean it isn't heartfelt or affecting or a good starting point for high school students to look at the 1960s from the perspective of someone whose world changed on February 3, 1959, when a plane crash killed three rock'n'roll singers. Period. It's not a "secret". It's not a "wacky interpretation". It's not a "hidden meaning". It's what the song's about. Sort of like how, say, John Lennon's "Oh, Yoko" is about Yoko and not about, say, the Iranain revolution or basketball.
Ask your parents. Or read any of the thousands of tedious interviews poor Don McLean has had to slog through in the decades since.
"American Pie" is a song about a plane crash. I think I can go a few weeks without songs about plane crashes unless maybe someone writes or unearths a fitting one relevant to this that makes life more bearable.
VA is out of the hardware business. They're also out of the contract hardware support business. Their remaining products are software and professional services, with an overwhelming emphasis on servers: storage management and clustering, SourceForge and so forth.
The occasional professional services gig that involves rolling out 3D engineering and CGI workstations hardly justifies keeping lead Mesa and DRI developers on board. Nearly all of VA's engagements deploy machines that never run in a graphic mode, and indeed often don't have a monitor connected at all.
As for Loki, they claim to have a positive cash flow now. Bringing on video driver developers might not be something they can afford, though, especially while under bankruptcy protection. Loki develops for a small market with low margins: gamers using Linux desktops more or less exclusively. I'd sooner think that DRI and Mesa developers would find a home with companies making high-end 3D design and animation tools, and with consumer electronics companies making video-related appliances.
StarOffice 5.2 is so resource-hungry and slow that it might as well have been written in Java 1.1. Waiting a solid minute or so for it to fire up on a P2/300 with 192MB RAM, and running into its native widget set, it's easy to unserstand why someone might think it was written in Java. Less easy to understand is why ZDNet seems to have fired all of its fact-checkers.
The OpenOffice development snapshots are definitely peppier, so StarOffice 6.0 should be fine in this regard.. but 5.2.. eek.
Where Java does enter the StarOffice picture is that 5.2 has an open interface that lets you pick a JVM--or install one--to use as yet another macro language. This is a nice touch for all the Unix shops and others that have Java programmers on hand more readily than VBA people. You can use a nice, fast 1.3.x JVM with it, and develop with your existing tools and components. The other nice "Java" feature is SO 5.2's ability to use JDBC throughout for database access instead of native drivers or ODBC. Very useful and very elegantly cross-platform on Sun's part.
And incidentially, the "other" major SO5.2 scripting language is a VB clone, both in syntax and coding environment. SO has a different document object model, so MS Office macros won't run unmodified, but at least VBA skills can carry over. KOffice's use of DCOP for automation allows the use of any available language, potentially doing things one better--but without integration with a development tool as one gets with VBA and StarBasic, it remains at a disadvantage. Maybe bidirectional KOffice-to-KDevelop hooks (for C++) and KOffice-to-Netbeans/Forte (for Java) are a way to go.
Linux is fine for point-of-sale systems. It just isn't used for many at this point, and OS dogma isn't a good reason for existing vendors to rush into it when they have products that work already.
As for Apache, MySQL and Perl/PHP/Python as the basis of such a system.. well.. I'm sure there's worse out there, but I don't think too many stores would want to use a web browser as their cash-register interface. You do intend to use a browser, right? Web browsers are bad tools for quick, reliable data entry. Too much scrolling and mouse movement.
Also, you'd have to write browser plugins to control and access things like a cash drawer, a signature tablet and a UPC scanner. Again, not out of the question, but sort of unneccessary.
And as far as the backend goes, why MySQL? Postgres is much more robust and provides an environment more in line with what you get in a commercial database. Once your data model starts to get complicated and you're doing a lot of inserts and updates, it's going to look like a better choice.
Python is a very nice language, though once you're putting it behind an HTTP server, you may consider Zope in place of Apache. PHP? Seems kind of limiting. Perl's not going to make for the most maintainable codebase. But language isn't really the issue. Architecture is. And maybe maintainability too.
An HTTP backend might be okay, though the fact that it's stateless and doesn't offer a satisfactoy way to push out alerts from the central server is a drawback. This is, after all, a network of cash registers you're building here, not a public website.
If it's still going to be HTTP, and the push-pull issue can be resolved elegantly, I'd just use HTTP as a transport layer and instead of a browser and write the frontend as a custom ncurses application (console mode!) with access to the esoteric hardware, and client-server communication via SOAP. And quite likely instead of HTTP, I'd consider something more persistent and two-way for the SOAP transport...though tiny HTTP listeners on the clients wouldn't be out of the question.
The language and "app server" engine? Those are the least important choices. Any combination that is easy to deploy, is reliable, and is easy to maintain and extend will do. Java on Tomcat/EJBoss? Python on Apache or Zope? Standalone Perl with SOAP::Lite? Whatever.
Most mainstream PC-based point-of-sale systems are console applications or, if they're graphical at all, they run in a VGA framebuffer mode. The server OS might be NT, Novell or OS/2, purchased at an OEM price of under $600. Sometimes a whole lot less than $600.
The point of sale terminals themselves often aren't running Win9x or any version of Windows, for that matter, though of course some do. A mouse is seldom involved. Indeed, there usually isn't any pointing device. Just a keyboard (or just a POS keypad), maybe a barcode scanner, a touchscreen or a signature capture pad, and a cash drawer.
Yes, the application could be made cheaper. The vendor could eliminate $200-$600 in server OS costs, and anywhere from $20-$120 per terminal in client OS costs.
The POS system itself probably sells to the customer for, say, $30,000, including hardware, software, installation and setup, integration with your accounting system (which isn't running on Linux, I'd wager), and a 3-5 year support contract.
The vendor's hardware costs might be $1500 for the server box, $700 for each PC, and something like $800 for each PC's POS hardware peripherals. So let's say the hardware for the whole 5-station system costs them $9000. Those OS licenses might be adding a thousand dollars to each 5-station system going out the door. And though your POS terminals can be Pentiums since they're not doing much processing, theyaren't Pentiums because you can't buy new Pentiums. You buy hardware that your company will be comfortable supporting for 5 years or more, and that means hardware consistency is a major goal. You might buy PCs a thousand or more at a time, and servers a hundred or more at a time in order to ensure a 6-month (or longer) supply of identical hardware with identical drives, controllers, video cards, motherboard layouts, NICs and BIOS revs. Mix and match is foolish if you're in a business making a lot of its money from fixed-price support contracts.
So your assignment is to tell me how many of these typical 5-station POS packages a vendor has to sell with Linux at a savings of (and I'm being generous here) $1000 each in order to justify the money spent porting the application, testing it, and hiring and training a second team of customer support and professional services people to support this second version of software that wasn't broken in the first place.
Now you're porting the software. The current vision was written in, say, VB or maybe C or maybe even some kind of Pascal, or, even more likely, some Foxbase-family language, and calls to a smallish relational database engine whose main strength is that it runs for weeks or months at a time without any maintenenace beyond swapping backup tapes. It's old code in an old version of an old language, and it's tied to one (probably old) database engine. Porting isn't going to be a simple matter of recompiling and changing an ODBC DSN. It's going to be work. Work that will result in a more modern, portable application, but work nonetheless. Still want to do it? Great. Now put the porting team together.
Remember: hiring a junior-level programmer you're paying $45,000/year to is costing your company $60,000 once you pay them benefits, train them and give them a desk and a PC. And one programmer isn't going to be able to do the port, write the new manuals, do the QA, revamp the customer training course, and provide tech support. There are a few bodies involved.
Linux will find its way into point-of-sale systems, just as it's found its way into shop-floor terminals in factories and warehouses. But it will only get there in the context of new products, or as a result of clean-slate rewrites of applications when an old version can no longer be extended and upgraded effectively. And those aren't done on a whim.
It's not a matter of "big iron" and "geek desktops". It's about servers. The reason you don't see point-of-sale systems on Linux is that Linux--like any Unix--is still a relatively awkward choice for standalone and small-network desktop use. It's easy enough to get running for one-off engineering workstations and for hundreds or thousands of X terminals, but the cost savings and overall benefits of a Unix just aren't there for those 5-100 seat mixed-use installations found in most desktop environments.
.5TB range can run on Linux now. And that's a lot of databases.
.NET) or with Java. And since that Java code really does move--unmodified--from Windows developer workstations to staging servers and production boxes that can be running any of a good dozen OSes on hardware going all the way up to mainframes, with application servers that are increasingly interoperable and interchangeable, Java's looking pretty good.
Want a stable, non-windowed PC-based cash register? Linux gives you nothing you can't get with DOS, Netware or OS/2-based systems. There's little reason for vendors to port, and the application is so narrow that Linux offers nothing but a savings on OS licenses, which are insignificant to the cost of a 5-station point-of-sale system.
Running a small- to mid-sized office? Linux is a decent way to save on servers, and many companies do so, buying mail and file-sharing appliances like Cobalt Qubes, or IBM's Small Business Server software bundle, which gives small but ambitious companies a nicely priced bundle of DB2, Domino and Websphere. Still others bring on the accountant's nephew to set up a Samba server or two. But on the desktop? Unix and Linux office suites are mediocre at best, the best being slower and more memory-hungry than MS Office. And you can be the one to tell the senior managers how good Linux is the tenth time they can't properly open an MS Office file that was mailed to them.
Where Linux is taking over the world is on servers, and now it's not just the usual HTTP, Samba, DNS and SMTP services. In the past year, with good 1.3.x JVMs from Sun and IBM, Linux is now on par with any other platform, dollar for dollar, for running J2EE application servers.
If you're running clusters of Weblogic, Websphere or other EJB/servlet/JSP engines (Tomcat, JRun, EJBoss, etc.), there's simply no longer any technical reason to do it on Solaris, HPUX, Win2K or AIX. If you have a decent JVM (as Linux has) and decent networking and memory management (as Linux has, especially with 2.4), that's all that really matters. Why pay $700, $3000 or more on OS licenses and OS support per machine for something that you just want to (1) stay up and (2) run a Java app server or one or more of its support systems like a message queue?
Moreover, the move to journaling filesystems and better support for external storage, and the availability of many mainstream commercial-grade backup and system management tools means Linux is also a perfectly good way to run all those 1-4 CPU database servers. Oracle and DB2 on Linux aren't going to eat into the Sun E10000's turf or IBM's OS/400 and System/390 spaces just yet, but all those databases running on 1U-5U rack equipment with storage in the
Add to that the fact that Linux has become (officially or not) the reference platform for a lot of Unix software, and the reference x86 Unix for many others (see Sybase) and Linux looks poised to eat not just the low end but also the middle of the server market.
The success of server-side Java has a lot to do with this. Right now, the overwhelming share of new server-side development is being done either with the MS platform (ASP, MTS, COM and the early bits of
I've been using Mozilla and Netscape 6.x about half the time for a few years now, and the past few months have brought dramatic speed improvements. XUL is finally fast enough to be usable on machines slower than a 1.2 GHz x86, and mail folders open quickly enough to work with.
.9.x series--and two months from the putative release of a 1.0--that proper test code would be in place for core functionality like this and that things would be in a bug fix stage, not that inbound and outbound MIME handling would still be awaiting its first real-world testing two months before 1.x and more than a year after the release of Netscape 6.0.
Mozilla 1.0 isn't a terribly meaningful concept, especially given that 0.9.3 served as the core of a genuinely commercial-quality Netscape 6.1--at least in most respects. But I do have a question for those who Mozilla or Netscape 6.x as their primary browsing and mail tool:
What's everyone doing about proper MIME support? Don't you people (and the developers!) ever send non-text e-mail attachments? Mozilla and Netscape 6 ship with virtually empty mimeTypes.rdf files and no auto-build from exisiting legacy MIME settings whether at the system level or from old Netscape 4.x configs, which means out of the box no external helper apps work--and worse, outbound email attachments other than HTML, text/plain, GIFs and JPEGs are mangled, transported as inline text. These empty MIME settings are years old.
Even more upsetting, the dialogs to edit and create mimeTypes entries from inside Mozilla/NS6 are broken: the checkbox that activates outbound MIME type declaration for a given mimetype is inactive, leaving hand-editing the poorly-documented RDF file as the only recourse. Not only that, but the Un*x Mozilla/NS6 doesn't seem to use the current environment in launching helper apps. Is it so hard or insecure or distressingly platform-specific to have the PATH environment variable--or use of "which" or "locate"--when launching helpers? Why must users manually locate the fully qualified path to their MP3 player, PDF viewer and so forth instead of simply entering, say, "acroread" or "xmms" in the dialog (or the RDF)?
Are the Netscape/Mozilla developers and those of you who claim to use Mozilla full-time passing around a hacked-up mimeTypes.rdf that isn't being shared with the public, and isn't even in an experimental branch of CVS? Or do you just never send email attachments?
And more to the point: doesn't the Netscape 6.x dev team ever send email attachments? How about the QA team? Are they all using Pine instead? And if they are, how does that jibe with the idea of eating dogfood?
Does Netscape even have a QA team?
I've thought of fleshing out mimeTypes.rdf myself, but I can't even figure out who owns it. Mail/News? Prefs? The core browser team? With the way the project owners point fingers, can I expect anyone to lay claim to it at all?
Maybe this is the problem.
Don't listen to anyone who says AOL's buyout has derailed the Mozilla project. They're clearly not taking an active role at all.
1.0 means different things in different projects, but one would expect nearly a year into the
Sounds to me like they're trying to retrieve email directly from a POP server or something; the aid worker who set that up should be fed to pack of wildebeests or tigers.
They should be using UUCP to send and receive mail via a series of relays that pass mail along one step at a time through machines that dial up in the chain periodically, fetch whatever they can before getting cut off, and get (or send) the rest next time. This is what UUCP was designed to do back in the days when a whole lot of email was transported via multiple hops of unreliable dialup. It also gets people out of the business of using the expensive, unreliable dialup connection to sit around trying to read and compose mail--activities that should be done fully offline. The only machine(s) that should be connecting to an ISP are the ones that can reach it easily, i.e. in the city where the dialup line is located. The rest of your locations should be connected by dialing into a designated parent at off-peak-times, and retrieve messages for any machines downstream from them.
When a message reaches its destination machine, it can then be read, replied to, whatever, and the multi-hop journey back begins. The SMTP servers at each hop should be configured to reject or truncate large messages, since the whole system can get bogged down by one big file attachment that can never make it over an unreliable dialup connection.
I'm also a bit confused by the reliance on (cellular?) phone modems. Surely the region would be better and more cheaply served by amateur radio. It probably is already, in fact, and your organization just may not be in contact with any hams. Amateur radio has been used for low-speed data transmissions over very long distances for decades, and for wireless UUCP in remote areas for many years. Data transmission speeds might be slow, but it's reliable, it's dirt cheap (25-year-old shortwave-band transceivers and 10-year-old packet modems should be easy finds if you can't get them donated), and as long as you can supply some electricity and keep the equipment in good shape, you can run it around the clock.
Depending on the distances and terrain, the weather, the presence of jamming activity in the area and your ambition level, you could eventually branch out from UUCP and experiment with realtime BBSes via radio. Unless I'm mistaken, quite a few branches of Fidonet were available via packet in Fido's heyday.
I'd look at HOWTOs and docs for UUCP (which isn't just for Unix; you can run UUCP nodes on pretty much any OS including DOS) and at the Linux HAM-HOWTO for some starting points.
It goes without saying that this kind of behavior is expected from Microsoft, nevertheless, has anyone gotten Opera to work with Hotmail?
Oh, grow up. (You too, some of you other editors.) Not everything in this world is part of the great evil Microsoft master plan to crush Scandinavian software developers. The only web developers who even bother testing their sites with Opera at all are the ten or twelve of them who regularly use Opera themselves.
Netscape browsers now have a market share somewhere just north of 5% when the wind is blowing right--and that's the old 4.x Netscape. Mozilla and Netscape 6.x are statistically indistinguishable from zero once you leave Slashdot and Mozilla.org, which themselves aren't exactly big draws in the scheme of things.
Does Opera even account for one half of one percent of all web traffic to mainstream, general-interest web destinations like Yahoo, MSN, Amazon and so forth?
Microsoft isn't trying to sneakily shut out Opera users. They are trying to shut out users who block cookies, but that's to be expected from a web service like Hotmail that depends on ad and cross-marketing revenue for its existence. And they couldn't care less about Opera.
Netscape, however, is another story: with the ongoing antitrust action MS has to continue some degree of support for their browsers, even as they've become economically questionable to support. Just because 1/3 of Mac users (who make up 5% of web traffic) and 95% of desktop Unix/Linux users use Netscape doesn't mean those 2% of the whole are really worth spending development money on.
For the practical, replace-every-3-years, people-will-find-them-useful shelf:
In general, I'd skip all but the most elegant half dozen or so books on programming languages because of the shelf-life issue. Think Kernighan and Ritchie on C and maybe things like Bruce Eckel's Thinking in Java, which is as timelessly abstract a Java book as I've seen. But Java will be unrecognizable in 5 years, so tread lightly here.
Get nothing on web development other than an HTML book or two. Those are useless after one year, never mind five.
For Palm to stay in their longstanding $200-$450 price range, this move is right on schedule. Palms have been shipping for about 5 years now, just over 3 generations of Moore's Law. Since the original Palms were 20 MHz 68030-class computers, it should be possible to produce something 8-10 times faster overall with 8-10 times the memory. This roughly translates to 150-200 MHz ARM-based systems (right on target) with 4MB RAM in the lowest-end devices (think m100) and several times that in the high-end ones.
Do all the math and you can easily come up with roughly the same hardware spec as a current iPAQ handheld, but about $200 cheaper since it will hit the market about a year later, which in 2002 puts a color 200 MHz ARM-based device with 16-32MB memory built in right in Palm's pricing sweet spot.
While Compaq will be targeting its $500-$600 price range with lovely 300 MHz 64 MB devices, this hypothetical $400 Palm device should be comparable performance-wise to the current iPAQ, but with longer battery life and what will probably be transparent support for all Dragonball Palm apps. They're not dead yet.
The question was whether there are alternatives to PDF for which there are readily available viewers.
The answer is no.
In the mid-'90s, there were a couple of competing technologies, each with its own proprietary viewer. Among the worst was Corel's Barista, which used JVM 1.0 applets for a viewer. It was a nice idea that the early capabilities of Java made unworkable.
Among the best was Common Ground, which was a lot like Acrobat with the added advantage of having a very lightweight viewer. For people without the plugin or standalone viewer, you could distribute Mac and Windows executables of the document with a self-contained viewer that was in the ballpark og 40K in size. By 2.0, they also had a viewer applet in Java. However, the quality of the documents produced wasn't as good as Acrobat's. It worked well for word processor documents and spreadsheets, but wasn't good for line art and desktop-publishing output. Hummingbird acquired them and tried to turn it into a universal viewer technology for its document management system. After a while, unable to catch up with Adobe in terms of document quality, they discontinued it.
Net-it Now was another such tool. Again, it wasn't as good as Acrobat. Its niche was the use of Java (and later, ActiveX) viewers. Since Adobe eventually got Acrobat Reader distribution almost universal, the product didn't really have a compelling niche and it too was discontinued. I think parts of it live on in some Lotus/IBM products like SmartSuite.
Postscript files (compressed or not) are not a viable substitute unless you're only distributing your content to Slashdot readers and Unix sysadmins. Whereas some 95% of desktop users have a PDF viewer (usually Adobe's), fewer than 5% of people have a Postscript viewer, and many of those would have trouble making it work with a downloaded file.
Getting rid of your PDFs is a nice political statement, but shitty business practice. PDFs--especially properly hyperlinked ones--are the only decent way to distribute print materials like brochures and manuals reliably to end users. Make people download Ghostscript (with its awful installers), the Ghostscript core font set (with its manual installation process) and GSView? You try telling someone who is paying you thousands of dollars for your products or services to do that. I won't.
If you want to make a point, go ahead and add some (polite, professional) text to your pages with PDF download links noting that PDF is a convenient format regrettably put out by a company opposed to freedom of speech that also produces insecure products unfit for use with sensitive information. Offer a polite link to, say, the EFF's website for more information.
For your own part, maybe you can make a point of making any new PDFs without Adobe's tools. Say, ps2pdf if you don't need hyperlinking or color profile support. Or libpdf-based tools and libraries (from Perl, PHP, C, whatever) for PDFs you generate on the fly from raw content.
But don't get shrill and don't make it hard for your users and potential customers to get what they need in an easy and timely way. That just makes you look like an amateur and an idiot.
Their database is old and doesn't seem to be all that big. They don't seem to honor boolean terms. They'll throw back dozens or hundreds of related pages from the same part of the same site without grouping them or squelching them. No apparent support for fuzzy spelling variations.
And when Apache and Debian show up at the top of a query on "Linux", it throws the sophistication of Google's relevance calculations into relief. Apache and Debian are linked from a ton of web pages, but the overwhelming majority of those pages are message board postings and message board TOCs or things like "This site runs on..." page footers. What this says to me is that Teoma isn't doing a good job of weighting the relevance and prominence of inbound links. It's as though it's going purely on the raw number of times the search term appears in a page linking to Site x regardless of how many are clearly identical and thus probably links from menus and TOCs, and not from the pages' unique content, where a link should count far more.
If LinuxToday, that cheesy little newswire-excerpt site with the amateur design, is a major Linux news portal, then I'm the Archduke of Luxembourg.
And Internet.com! Isn't that the flagship publication of INTM, the company that operates the burned-out husks of Mecklermedia's trade papers and Earthweb's awful developer portals? Internet.com gets respectable traffic numbers, but they're not exactly in ZDNet or CNet territory.
I'm shocked--shocked--that a dorm-room project like LinuxToday would engage in planted self-promotion.
Does LinuxToday even pay for its wire feeds? I'm not sure the entire lead paragraphs og stories constitutes fair use.
As more sites refuse to serve content unless they can set and read back a cookie, the part of the web you'll be able to surf is going to get mighty small soon. It's happening already.
And it'll get even smaller when content only loads after the successful playback of a 30-second animated commercial, enforced by more cookies and some scripting to render the content itself.
I give it less than a year.