Hundreds of the Payphone 2000 model, with a CRT and what was supposed to be text and videotext access to data services, have been in airports and such for years now. As far as I know, AT+T never got around to activating any of the data services involving the screen. It ended up just being an expensive way of presenting a menu for choosing payment method.
Thete's already stiff competition for web terminals in airports, especially from those startups with BSD-based kiosks, for what is surely a short-lived market. With wireless-capable PDAs, wireless modems, 802.11b access points and web phones already out there, and 3G phones a year or so away, the business travelers who would pay $15 or so an hour for access to email have less need for these every month.
Unless they can get serious ad revenue from video interstitials--and that would be tough to foist on business travelers--the price per minute needs to remain high to justify paying for the airport real estate.
I'm surprised these were designed for such early obsolescence. Usually a payphone is meant to last a good decade. Since I think it's fair to say most travelers who would pay $15/hour for airport net access will have their own portable means of access in 2-3 years, why didn't AT+T rig these for the kinds of things that will still be out of most people's reach by then, like video conferencing and enabling high-speed large file transfers? I guess the IrDA port could be programmed for the latter, but it's still a narrow market regardless.
Are they betting that concerns about terrorism will lead airports to jam personal wireless devices and force people onto these?
I haven't seen any MD drives for computers, at least not ones compatible with the audio format. However, you can get smaller CD-R media in 3-inch and business-card sizes. The looming problem there is that slot-loading CD drives have started to catch on.
What kind of messed-up implementation of Notes does your company have? Notes/Domino can do things a generic IMAP server and client can only dream of. Efficient synchronization! Single-message stores! Support for structured data beyond plain email messages! A really nice web interface! Workflows!
If you want to give up all of this (or maybe your company doesn't use any of it), you're welcome to connect to a Domino server with your favorite plain IMAP client, and do user lookups with the little LDAP search gadgets in Outlook Express or Netscape 4.x or such.
Or were you thinking more in terms of an Emacs interface? [smirk]
Time to dump AOL/TW stock. I mean, shoot, AOL e-mail is even worse than POP3. At least with POP, you can easily save, archive and organize all your messages permanently and move them from machine to machine. AOL mail? Old messages disappear after an arbitrary number of days and you have to manually put messages you want to keep in your system's local "personal filing cabinet" which isn't exactly rich in organizational and search features.
AOL doesn't quite support standard HTML e-mail; instead, it's got its own hobbled rich-text format made from a subset of HTML, so it has a rough time with email from other modern mail clients like, say, 1996-vintage Netscape or 1997-vintage Outlook Express and Outlook.
Send more than one attachment to the outside world, and it gets zipped if you send it from a PC and Stuffed if you send it from a Mac, and godspeed the PC user who gets a binhexed Stuffit file from someone who has no idea this happens automatically.
The whining about use of SecurIDs is a bit of bellyaching, though. More companies should do things like that if they open mail access to machines outside their private network.
Then again, I'm not sure if any of the "AOL Anywhere" clients for access via WAP phones, Palm VIIs, Blackberries and whatnot support SecurID authentication. It sure would suck if all those tens of thousands of employees had no way to retrieve mail from a device smaller than a laptop.
Anyone know if AOL gives employees the ability to do mail forwarding or set vacation messages? AOL customers sure can't.
You're using IE5.5 under WINE with a bunch of WIndows 95 OSR2 DLLs in your case. I wouldn't be surprised if IE could limp along these days under clean-room WINE and no Microsoft OS DLLs too, but the way you're using it, that's not the case.
If you're going to use Windows system files to supplant the weaker parts of WINE, you're legally required to have a full license to Windows. Once you're paying for the full Windows license, isn't VMWare a better way to go? It provides a much better Windows-under-Linux environment than Windows-less WINE does even under ideal conditions. Point is, as a technology to roll out in environments where software piracy isn't an option, a tweaked WINE combined with MS's Windows DLLs isn't really a viable product.
Codeweavers is trying to build a business on selling WINE-derived products for targeted martkets. WINE is still free and will stay that way since there's no money in WINE itself. Things like VMWare do a better job of allowing people to run Windows and Linux simultaneously, and it's likely WINE will never catch up completely with whatever versions of Windows are current and thus become near-100% compatible.
WINE's commercial value is instead in the targeted use of it as a porting library or compatibility layer for specific applications, when Linux-compatibility is needed but a port to native *nix APIs is either too expensive or too far off to meet a desired street date.
They don't intend to make money selling this plugin compatibility adaptor to end-users running Linux on their desktop. While they might try to sell it--at a per-copy rolyalty--to commericial Linux distributors that target consumer desktops, that doesn't seem to be their goal here
Because this isn't going to help anyone install plugins on Linux, it's really something for companies that want to, say, sell web terminals that can play Quicktime and Shockwave, because those companies would also have to secure the rights to redistribute a repackaged version of their software (i.e. Quicktime and Showckwave players).
While an individual at home might manage to use this to run Windows Media Player, that home user doesn't have the right to run it on a system without a Windows license. Appliance vendors are unlikely to pay for Windows ME licenses solely for the right to put WMP on each Linux appliance they make, so in practice, this is really only a product for hardware vendors that want to license and distribute specific Windows browser plugins as part of their appliance.
This adaptor isn't the makings of a billion-dollar company, but there could be a nice business in this for the next few years.
As noted above, CVS can handle binary files just fine as long as you tell it it's getting a binary file. Most CVS GUI clients can also handle them.
What you're missing here is the ability to browse versions via cvsweb and the like, and do visual diffs on them, which are beyond the scope of CVS seeing as they'd involve DOC- or XLS- to-HTML conversion, among other things.
This is usually why a company or organization invests in a commercial DMS like Documentum, or in a commercial source-control system, depending on how your needs skew. Doing that stuff and making it work well and quickly while still easy to use is not simple, and doing a good job of all the format conversion and parsing requires the commercial conversion filters that Inso and Adobe have owned over the years, and which are in nearly every product that does good conversions of MS Office documents.
That said, you may be able to assemble something out of the following, for example:
CVS, and whatever client interface you want to use to get files in and out
The GPL'ed mswordiew Word-to-HTML filter or its cousins
The filters used by Gnumeric for Excel import and HTML export, or cousins thereof
A set of directories containing HTML conversions of all versions of all documents
A web search engine
cvsweb, rewired to perform diffs and display contents based on the HTML "ghosts" rather than the original files
I do, on one of those dreaded 700-series "Winprinters". I run my jobs through the reverse-engineered PPM utilities. They've had color support for well over a year, and have been included in some mainstream Linux distros for a while. Red Hat even has an entry in its Printtool for them that takes care of all the ghostscript-transformation rigamarole.
And the higher-end inkjets, of course, do PCL and are supported even better.
It's not great support, and it's not support from HP itself, but you can print to most modern HP inkjets these days.
As for config tools, there's been a Linux version of JetAdmin for some time now; also, their network printers from the 4000-range on up usually have web-based configuration these days which is also Linux compatible (and Solaris, and AIX and QNX and possibly even WebTV and Sega Dreamcast-compatible). Windows and Netware only need more elaborate config tools because with a few exceptions, client machines needed a print server to go through because the printers didn't support a protocol the client OS could speak to directly.
As for drivers, what's a Linux driver in this case? You can send PostScript right to any networked HP printer made in the last 3 years, and at least half of them from before that. What is missing are supported printcap entries for accessing advanced features like multiple trays, collating, sorting, duplexing and stapling. That would be nice to see.
Assuming slow, unreliable SQL database access to multiple copies of inconsistently-replicated data is a Good Thing (and it can be in some cases), this is a wrongheaded approach.
I looked at the Perl. What nonsense. What would be useful from a transparency standpoint would be doing this as an ODBC or JDBC driver so existing apps can hit the data.
Even more useful would be SOAP client and server transport interfaces via Freenet; then you could expose or access any API you want as-is, instead of using a special "Freenet SQL interface". If SMTP and POP3 can be viable SOAP transports--and they are, functioning as a no-budget message queue like MQSeries--why not Freenet? The asynchronous model makes more sense than a synchronous one anyway.
Read the background materials. It's worth noting that the images weren't made into prints in those days. Rather, they were shown with a special projector with separate red, green and blue beams aimed at the same spot, just like all pre-LCD projection televisions and video projectors. Very clever.
How much time passed between your first and second orders? There is a time limit on the free prints, something like 60 days. Did you contact customer service, or do you prefer to address customer service issues on Slashdot?
By the time I got to Shutterfly 6 months ago, the deal was 25 free prints, and I had no problem stretching them out across a few orders.
This isn't like timeshare real estate or shady little Caribbean calling card companies. Shutterfly lays out its tems pretty clearly in plain language when you sign up. If you're too impatient to read a couple of paragraphs, that's not their fault. And anyway, the free prints are free apart from shipping. They've lived up to the contract as I read it, but then, I did read it.
And in the meantime, new customers still get free prints, albeit only 15. They've shifted things to create bigger incentives for referrals, which still get you 25 per person. And it's a damn fine service. The prints I've gotten from my digital files, even the 8"x10"s, are gorgeous. And at $3 for an 8x10, what's to complain about? I've heard they don't do great work with film or with hand-tweaked digital files, but those aren't their main line of business, which is high-quality, well-optimized prints from unmodified digital camera images.
Will there be a deluge of cracking and virus-writing directed at Mac OS X? I'd suspect not. MacOS on the desktop accounts for less than 5% of what's out there, and on the server, it's far less than that. OS X will probably up their internet-connected server population a bit, but I wouldn't hold my breath waiting for Apple's overall market share to reach 7% any time soon.
Virus authors overwhelmingly target big targets, namely Windows. WordPerfect and Lotus Notes get hit by far fewer viruses than Word and Outlook. This isn't because they're better-written applications with good security features. It's because few people care about hitting the minority.
Until Apple's comeback a couple of years ago, there was so little interest in writing Mac trojans and viruses that months would go by without even the smallest update to Mac virus pattern files. Even now, it's an almost negligible trickle. The biggest problem lately hasn't been caused by an uptick in people targeting Macs; rather it's that MS Office 2001 for the Mac is so compatible with Windows Office that an increasing number of macro viruses now suddenly work cross-platform. This will become more pronounced in a few more months when the first new version of Mac Outlook in 4 years ships. Even so, I've seen an installation of 40 Macs go over a year without so much as detecting a Mac virus, much less getting hit by one.
Hacks/cracks/exploits/whatever are another story. Since Macs in sever roles will now be running Apache, sendmail, BIND and Unix-world FTP daemons, we should expect some Mac servers to be just as vulnerable to security holes that emerge in these services as their *BSD, Linux, Solaris and AIX cousins. Apple's auto-update functionality, similar to auto-updaters for Debian or things like AutoRPM and the Ximian updater should protect most, however, as long as Apple keeps its binaries up to date.
But targeting Mac OS X specifically? Who's going to bother?
Why port the Notes client to Linux? Domino's web interface lets you get at any clean R5 application you write. You can read and edit messages with rich text and all, too.
The only big reason--and it is a big one--to have a full Notes client these days is if you need to work disconnected, which generally means a laptop.
Linux accounts for less than one percent of all client PCs. The only folks who need replication are the ones on laptops, who are a small fraction of that one percent. And the only ones who *really* need it are the ones on laptops who neither run dual-boot nor have something like VMWare or at least WINE to run the Windows client.
So that's what fraction of one percent?
Now, how many of those people are in Notes environments? A couple thousand? Is it even that many?
On the other hand, Linux accounts for a large and growing share of the 1-4 CPU server market. It's in fact becoming one of the leading server OSes. That's why IBM offers DB/2, Domino and WebSphere for it.
We will probably see a native, replicating Domino client for Linux in the next year or two, but it might not be Notes. It may be easier for them to implement iNotes, their client encased in a "personal web server", which replicates Notes databases to the local machine just like Notes, but uses your web browser as the means to access it. It's pretty neat, and the nice part is it gives users what they need (replication and offline use of Domino resources) while using the proven web interface instead of yet another native one for the client.
Hm. I'm trying the demos. Wow. So it has no timing synchronization. It shows each frame regardless of what the frame rate is supposed to be. Let's see. A tiny postage-stamp sized video frame, maybe 240x180, at 3fps (yes, 3fps) from a 350K stream. The commercial video players do better than this at 40K.
I've seen better video performance at much lower bandwidth through server-side push of GIFs, Netscape 1.1 style. And that didn't need Java.
Hm. I do think Sybase and Microsoft are also players in the mid-to-large database market, and that a lot of companies with decent products but small market share, like Progress, would also take issue with the idea of IBM and Oracle being "it".
Sleepycat? Yeah, , Oracle and IBM do have little embedded data store products, but I'd hardly mention them in the same breath as FIlemaker, much less Oracle and DB/2. And as for MySQL and Postgres? Please. They're competition for Filemaker, MS Access, Interbase, Cloudbase and the like, and in some cases very good competition for them. But not even Postgres 7.x touches the lowest end of what the IBM, Oracle and Informix server products do. With live replication and decent hot backup features, maybe it could chew on their ankles, but that's about it. As for the middle-range, wake me up when Postgres can do clustering and failover, or when a single Postgres database can hit at least half a terabyte with good performance.
Not sure I agree with your premise that Unixes are farther along in this than, say, Windows and MacOS. Next time you're on a Windows 2000 machine, have a look at the features for synchronizing a network folder for use offline, not just the Briefcase. You can schedule syncs or have them take place during idle time.
MacOS has had a similar feature for years now, though it's a bit less slick.
As for other applications, last I checked, most mail programs, even low-end ones like Outlook Express and Netscape supported offline composition and reading, with message delivery on reconnect, and have for years. Internet Explorer's ability to pull down web pages and sites for offline browsing has been in since 4.0 and also keeps getting better, with automated background fetching and notification.
These sort of features could certainly stand to get better and easier to use; many people--yourself included, it seems--don't even know they exist, which certainly points up poor interface design and probably also bad documentation. But the funcionality is there.
Lotus in particular is good at these things. Not happy simply with Notes, the mother of all offline-sync application environments, they and IBM have now got interesting little personal web proxies and containers you can install that allow you to replicate working web-based applications, so that forms can be validated and local copies of databases can be updated with full logic offline through a browser interface.
There's enough of a learning curve involved with sedond and third mouse buttons and shift- and control-click operations to where much of it is used only by "power users". This is interesting, again, for power users. But honestly, the mouse is only an "intuitive" tool when it has one button and no chording or other such behavior modifiers.
Mice have been in the mainstream since 1984. That's 17 years. It's shocking how little innovation there has been in interface design since the Apple Lisa. We're still dealing with mice, overlapping windows with raise/close widgets, modal dialogs and trashcan icons. I look back and remember that Radio Shack had rudimentary speech recogniton and speech synthesis peripherals available in 1981. Mass-produced flat touchscreens go back at least to the GRiDpad. Moving pointers with eye movements was done years ago.
Technologies like handwriting and speech recognition made strides right up to 1984 or so, and then stagnated until a few years ago. Human-language command parsing was coming along well, too, in the mid-1980s and has barely been heard from since. The WIMP (Windows, Icons, Mouse, Pointer) UI killed off interest in a lot of things.
Things like this gesture stuff--wildly non-intuitive extensions to mouse functionality--are indicative of the myopia and stagnation among interface designers. Mouse "gestures" will be useful to small, technical audiences like engineers, providing a shorthand for dealing with complex visulaization applications. But it's much too reliant on training and so completely non-intuitive that it can never be a viable direction for mainstream UIs.
Why, in the year 2001, some 14 years after GRiD's touchscreen-and-stylus tablets, can't people reading a document onscreen simply touch the corner of a doument and flick it to the left to turn a page? Why can't I pick up a pen and scribble recognizable corrections directly on a spreadsheet? Why, if I do want to use speech dictation software, can't I make corrections with a pen at the same time using standard proofreading marks? And why isn't my speech recognition profile stored on a central sever or on a pocket-sized dongle so I can dictate text from any computer or telephone anywhere? Why are keyboards still being used by people besides programmers, paralegals and data-entry clerks?
Why do command-line OSes not offer plain-English (or French or Mandarin) command recognition? Surely if the parser used in Zork worked as well as it did on a lowly 6502 back in 1981, and I used BBSes with plain-English command recognition ("Go to the library and download 'bluebox.txt'") in 1985, you'd think natural-language access to basic (and not-so-basic) file and system management operations, among other things, would be a piece of cake by now.
You have, say, 35 people in your buddy list, scattered across 20 servers. This isn't unrealistic given that on Linux, a Jabber server can only handle 1024 simultaneous users, at least according to jabber.org's own FAQ. So now, for the duration of your session, your client is communicating every few seconds with each of 20 servers to check your friends' online status. With a protocol that's robust, but not lean.
Your client communicates with the central JUD server every time you want to look someone new up. Without the central JUD server, the whole thing balkanizes into separate small, free-floating islands and there's no ability to add or contact people not on your home server to your list until it comes back, though you can keep talking to the people already on your list.
Your topology calls for many small, independently-run servers, which is going to be slow and unreliable; on any given day, any one server can shut down, die or disappear and its user base will be orphaned since there's no replication and failover of login services going on. Some are on mom-and-pop ISPs or run by nonprofits on a virtual server, some are big, fast systems. Some are in North America, others in the EU, and others in Egypt or Thailand. A server in Egypt will provide fast, reliable services to users in Egypt, but if they're on an American's buddy list, the Egyptian users' entries will drop in and out of the "logged in" status category as packets get lost in transit or connections sporadically time out, and vice versa.
Jabber has a design that can scale, yes. But I maintain that it cannot scale to AIM/ICQ/MSN/Yahoo size, and that's what a public IM system needs in order to be useful.
A more reliable topology might involve fewer, larger Jabber servers, each with a substantial portion of the user base--which gets right back to the question of how large servers get paid for.
Usenet and email are decentralized and asynchronous. When you're sending email or posting to Usenet, nothing is checking to see if the recipients are logged in.
With instant messaging, you can't get around the thing that distinguishes real-time chat from email: the real-time status monitoring. When you log in to a real-time chat system, you need to announce your presence to a central hub that reports your status to the other users who need to see your status. You can't do that with a decentralized system, at least not one with more than a couple thousand concurrent users. Multi-hop referrals or separate regional or ISP hubs each with their own members' login status are far too slow and bandwidth-intensive to work on a large scale.
A useful public instant-messaging system covering countries with tens of millions of people and thus hundreds of thousands to millions of concurrent users needs that central hub; otherwise your client is spending all of its time querying and processing data from any number of far-flung regional hubs.
Fine, Jabber has a faint outside chance of becoming a standard protocol for private instant-messaging systems, and might eventually compete well with things like Lotus Sametime and Microsoft's conferencing server.
Granted, this isn't all that likely since both Microsoft and Lotus can already integrate their instant messaging well with H.323 videoconferencing and with T.120 application-sharing and whiteboarding tools, and seamlessly tie in to directory services (not just for authentication) in ways that also make it fairly simple to link companies' and organizations' realtime messaging/collaboration together without relaying each other's messages. Fact is, Jabber is a good 2 or 3 years behind its competitors in the intranet space in terms of features. They're even miles behind the ICQ Groupware server.
As far as public instant-messaging goes, it wouldn't be fair to say Jabber has no chance of catching on. But those chances are slim. Let's say that for some reason it does. Who is going to run and pay for the giant Jabber servers sitting in the middle of everything? An instant messaging system that can support millions of concurrent users will not run on a single donated 4-processor box running Postgres or MySQL. It won't run on two. It's going to take a server farm or two with millions of dollars in hardware, millions of dollars in commercial database licenses, and millions of dollars in engineers' salaries to tend to it. Please remember that while the messaging itself is peer to peer, the login and buddy-status monitoring services are not.
How, exactly, is this going to be paid for if the clients are open-sourced, access to the servers is unrestricted, and advertising can be blocked? A tip jar?
I'll have to get back to you guys on this one. I've been too busy reviewing the SRPM for Emacs. Another two years and maybe I'll be ready to compile it.
Having a contract that that states severance terms certainly changes things.
And unions don't "force" employers to do anything. They are simply a means by which employees get the leverage necessary to get desirable employment terms, safe working conditions, and so forth. The ability to walk out en masse with a safety net (from union dues) is that leverage.
When all you've ever worked in is a bull market where you set the terms by which you work, as so many techies have for the past 10-15 years, it's easy not to notice how hard it is to get livable working consitions when it's the employer that has the upper hand. When, say, you have an oversupply of qualified people for a given job.
Given the rate at which people in the tech sector are being laid off and pay rates are leveling off and even starting to decline, I would have thought the brand of thuggish, anti-union conservatism so popular among geeks the past few years would be on the wane. (How exactly is it "libertarian" to argue that government should assist companies in blocking people from engaging in collective bargaining?)
When you guys get laid off without severance pay in a couple of months because your department's project is being moved to a subcontractor in Russia or India, let's see how anti-union you are. Right now, the only hot jobs are for J2EE programmers and senior sysadmins. Even those are likely to dry up at the rate things are going.
Anyway, back to the AFTRA/media-company standoff:
The broadcasters have had a good five years to negotiate terms for Internet rebroadcast with AFTRA. That's how long decent streaming has been around, so it's not as though this whole "internet" thing just blindsided everyone. When the broadcast companies decided to start collecting additional advertising fees for their Internet rebroadcasts, their lawyers were well aware of the terms of the AFTRA contracts that were in place.
The New York Post is a right-wing tabloid; be aware of their bias and as with any publication, read it with the appropriate decoder ring. Clear Channel has a business unit that runs separate Internet-only "radio" stations. It's entirely possible that this cutoff has less to do with AFTRA than it does with their desire to "replace" Internet rebroadcasts of radio stations, and eventually those stations themselves, with their cheap-to-run Internet stations with their anonymous, interchangeable, and non-union deejays.
Hundreds of the Payphone 2000 model, with a CRT and what was supposed to be text and videotext access to data services, have been in airports and such for years now. As far as I know, AT+T never got around to activating any of the data services involving the screen. It ended up just being an expensive way of presenting a menu for choosing payment method.
Thete's already stiff competition for web terminals in airports, especially from those startups with BSD-based kiosks, for what is surely a short-lived market. With wireless-capable PDAs, wireless modems, 802.11b access points and web phones already out there, and 3G phones a year or so away, the business travelers who would pay $15 or so an hour for access to email have less need for these every month.
Unless they can get serious ad revenue from video interstitials--and that would be tough to foist on business travelers--the price per minute needs to remain high to justify paying for the airport real estate.
I'm surprised these were designed for such early obsolescence. Usually a payphone is meant to last a good decade. Since I think it's fair to say most travelers who would pay $15/hour for airport net access will have their own portable means of access in 2-3 years, why didn't AT+T rig these for the kinds of things that will still be out of most people's reach by then, like video conferencing and enabling high-speed large file transfers? I guess the IrDA port could be programmed for the latter, but it's still a narrow market regardless.
Are they betting that concerns about terrorism will lead airports to jam personal wireless devices and force people onto these?
I haven't seen any MD drives for computers, at least not ones compatible with the audio format. However, you can get smaller CD-R media in 3-inch and business-card sizes. The looming problem there is that slot-loading CD drives have started to catch on.
What kind of messed-up implementation of Notes does your company have? Notes/Domino can do things a generic IMAP server and client can only dream of. Efficient synchronization! Single-message stores! Support for structured data beyond plain email messages! A really nice web interface! Workflows!
If you want to give up all of this (or maybe your company doesn't use any of it), you're welcome to connect to a Domino server with your favorite plain IMAP client, and do user lookups with the little LDAP search gadgets in Outlook Express or Netscape 4.x or such.
Or were you thinking more in terms of an Emacs interface? [smirk]
Time to dump AOL/TW stock. I mean, shoot, AOL e-mail is even worse than POP3. At least with POP, you can easily save, archive and organize all your messages permanently and move them from machine to machine. AOL mail? Old messages disappear after an arbitrary number of days and you have to manually put messages you want to keep in your system's local "personal filing cabinet" which isn't exactly rich in organizational and search features.
AOL doesn't quite support standard HTML e-mail; instead, it's got its own hobbled rich-text format made from a subset of HTML, so it has a rough time with email from other modern mail clients like, say, 1996-vintage Netscape or 1997-vintage Outlook Express and Outlook.
Send more than one attachment to the outside world, and it gets zipped if you send it from a PC and Stuffed if you send it from a Mac, and godspeed the PC user who gets a binhexed Stuffit file from someone who has no idea this happens automatically.
The whining about use of SecurIDs is a bit of bellyaching, though. More companies should do things like that if they open mail access to machines outside their private network.
Then again, I'm not sure if any of the "AOL Anywhere" clients for access via WAP phones, Palm VIIs, Blackberries and whatnot support SecurID authentication. It sure would suck if all those tens of thousands of employees had no way to retrieve mail from a device smaller than a laptop.
Anyone know if AOL gives employees the ability to do mail forwarding or set vacation messages? AOL customers sure can't.
You're using IE5.5 under WINE with a bunch of WIndows 95 OSR2 DLLs in your case. I wouldn't be surprised if IE could limp along these days under clean-room WINE and no Microsoft OS DLLs too, but the way you're using it, that's not the case.
If you're going to use Windows system files to supplant the weaker parts of WINE, you're legally required to have a full license to Windows. Once you're paying for the full Windows license, isn't VMWare a better way to go? It provides a much better Windows-under-Linux environment than Windows-less WINE does even under ideal conditions. Point is, as a technology to roll out in environments where software piracy isn't an option, a tweaked WINE combined with MS's Windows DLLs isn't really a viable product.
Codeweavers is trying to build a business on selling WINE-derived products for targeted martkets. WINE is still free and will stay that way since there's no money in WINE itself. Things like VMWare do a better job of allowing people to run Windows and Linux simultaneously, and it's likely WINE will never catch up completely with whatever versions of Windows are current and thus become near-100% compatible.
WINE's commercial value is instead in the targeted use of it as a porting library or compatibility layer for specific applications, when Linux-compatibility is needed but a port to native *nix APIs is either too expensive or too far off to meet a desired street date.
They don't intend to make money selling this plugin compatibility adaptor to end-users running Linux on their desktop. While they might try to sell it--at a per-copy rolyalty--to commericial Linux distributors that target consumer desktops, that doesn't seem to be their goal here
Because this isn't going to help anyone install plugins on Linux, it's really something for companies that want to, say, sell web terminals that can play Quicktime and Shockwave, because those companies would also have to secure the rights to redistribute a repackaged version of their software (i.e. Quicktime and Showckwave players).
While an individual at home might manage to use this to run Windows Media Player, that home user doesn't have the right to run it on a system without a Windows license. Appliance vendors are unlikely to pay for Windows ME licenses solely for the right to put WMP on each Linux appliance they make, so in practice, this is really only a product for hardware vendors that want to license and distribute specific Windows browser plugins as part of their appliance.
This adaptor isn't the makings of a billion-dollar company, but there could be a nice business in this for the next few years.
What you're missing here is the ability to browse versions via cvsweb and the like, and do visual diffs on them, which are beyond the scope of CVS seeing as they'd involve DOC- or XLS- to-HTML conversion, among other things.
This is usually why a company or organization invests in a commercial DMS like Documentum, or in a commercial source-control system, depending on how your needs skew. Doing that stuff and making it work well and quickly while still easy to use is not simple, and doing a good job of all the format conversion and parsing requires the commercial conversion filters that Inso and Adobe have owned over the years, and which are in nearly every product that does good conversions of MS Office documents.
That said, you may be able to assemble something out of the following, for example:
I do, on one of those dreaded 700-series "Winprinters". I run my jobs through the reverse-engineered PPM utilities. They've had color support for well over a year, and have been included in some mainstream Linux distros for a while. Red Hat even has an entry in its Printtool for them that takes care of all the ghostscript-transformation rigamarole.
And the higher-end inkjets, of course, do PCL and are supported even better.
It's not great support, and it's not support from HP itself, but you can print to most modern HP inkjets these days.
As for config tools, there's been a Linux version of JetAdmin for some time now; also, their network printers from the 4000-range on up usually have web-based configuration these days which is also Linux compatible (and Solaris, and AIX and QNX and possibly even WebTV and Sega Dreamcast-compatible). Windows and Netware only need more elaborate config tools because with a few exceptions, client machines needed a print server to go through because the printers didn't support a protocol the client OS could speak to directly.
As for drivers, what's a Linux driver in this case? You can send PostScript right to any networked HP printer made in the last 3 years, and at least half of them from before that. What is missing are supported printcap entries for accessing advanced features like multiple trays, collating, sorting, duplexing and stapling. That would be nice to see.
Assuming slow, unreliable SQL database access to multiple copies of inconsistently-replicated data is a Good Thing (and it can be in some cases), this is a wrongheaded approach.
I looked at the Perl. What nonsense. What would be useful from a transparency standpoint would be doing this as an ODBC or JDBC driver so existing apps can hit the data.
Even more useful would be SOAP client and server transport interfaces via Freenet; then you could expose or access any API you want as-is, instead of using a special "Freenet SQL interface". If SMTP and POP3 can be viable SOAP transports--and they are, functioning as a no-budget message queue like MQSeries--why not Freenet? The asynchronous model makes more sense than a synchronous one anyway.
Read the background materials. It's worth noting that the images weren't made into prints in those days. Rather, they were shown with a special projector with separate red, green and blue beams aimed at the same spot, just like all pre-LCD projection televisions and video projectors. Very clever.
How much time passed between your first and second orders? There is a time limit on the free prints, something like 60 days. Did you contact customer service, or do you prefer to address customer service issues on Slashdot?
By the time I got to Shutterfly 6 months ago, the deal was 25 free prints, and I had no problem stretching them out across a few orders.
This isn't like timeshare real estate or shady little Caribbean calling card companies. Shutterfly lays out its tems pretty clearly in plain language when you sign up. If you're too impatient to read a couple of paragraphs, that's not their fault. And anyway, the free prints are free apart from shipping. They've lived up to the contract as I read it, but then, I did read it.
And in the meantime, new customers still get free prints, albeit only 15. They've shifted things to create bigger incentives for referrals, which still get you 25 per person. And it's a damn fine service. The prints I've gotten from my digital files, even the 8"x10"s, are gorgeous. And at $3 for an 8x10, what's to complain about? I've heard they don't do great work with film or with hand-tweaked digital files, but those aren't their main line of business, which is high-quality, well-optimized prints from unmodified digital camera images.
Will there be a deluge of cracking and virus-writing directed at Mac OS X? I'd suspect not. MacOS on the desktop accounts for less than 5% of what's out there, and on the server, it's far less than that. OS X will probably up their internet-connected server population a bit, but I wouldn't hold my breath waiting for Apple's overall market share to reach 7% any time soon.
Virus authors overwhelmingly target big targets, namely Windows. WordPerfect and Lotus Notes get hit by far fewer viruses than Word and Outlook. This isn't because they're better-written applications with good security features. It's because few people care about hitting the minority.
Until Apple's comeback a couple of years ago, there was so little interest in writing Mac trojans and viruses that months would go by without even the smallest update to Mac virus pattern files. Even now, it's an almost negligible trickle. The biggest problem lately hasn't been caused by an uptick in people targeting Macs; rather it's that MS Office 2001 for the Mac is so compatible with Windows Office that an increasing number of macro viruses now suddenly work cross-platform. This will become more pronounced in a few more months when the first new version of Mac Outlook in 4 years ships. Even so, I've seen an installation of 40 Macs go over a year without so much as detecting a Mac virus, much less getting hit by one.
Hacks/cracks/exploits/whatever are another story. Since Macs in sever roles will now be running Apache, sendmail, BIND and Unix-world FTP daemons, we should expect some Mac servers to be just as vulnerable to security holes that emerge in these services as their *BSD, Linux, Solaris and AIX cousins. Apple's auto-update functionality, similar to auto-updaters for Debian or things like AutoRPM and the Ximian updater should protect most, however, as long as Apple keeps its binaries up to date.
But targeting Mac OS X specifically? Who's going to bother?
Your company has "at least a thousand" Notes users on Linux laptops?
Didn't think so. Read, next time.
Why port the Notes client to Linux? Domino's web interface lets you get at any clean R5 application you write. You can read and edit messages with rich text and all, too.
The only big reason--and it is a big one--to have a full Notes client these days is if you need to work disconnected, which generally means a laptop.
Linux accounts for less than one percent of all client PCs. The only folks who need replication are the ones on laptops, who are a small fraction of that one percent. And the only ones who *really* need it are the ones on laptops who neither run dual-boot nor have something like VMWare or at least WINE to run the Windows client.
So that's what fraction of one percent?
Now, how many of those people are in Notes environments? A couple thousand? Is it even that many?
On the other hand, Linux accounts for a large and growing share of the 1-4 CPU server market. It's in fact becoming one of the leading server OSes. That's why IBM offers DB/2, Domino and WebSphere for it.
We will probably see a native, replicating Domino client for Linux in the next year or two, but it might not be Notes. It may be easier for them to implement iNotes, their client encased in a "personal web server", which replicates Notes databases to the local machine just like Notes, but uses your web browser as the means to access it. It's pretty neat, and the nice part is it gives users what they need (replication and offline use of Domino resources) while using the proven web interface instead of yet another native one for the client.
Hm. I'm trying the demos. Wow. So it has no timing synchronization. It shows each frame regardless of what the frame rate is supposed to be. Let's see. A tiny postage-stamp sized video frame, maybe 240x180, at 3fps (yes, 3fps) from a 350K stream. The commercial video players do better than this at 40K.
I've seen better video performance at much lower bandwidth through server-side push of GIFs, Netscape 1.1 style. And that didn't need Java.
Well, good luck to them.
Hm. I do think Sybase and Microsoft are also players in the mid-to-large database market, and that a lot of companies with decent products but small market share, like Progress, would also take issue with the idea of IBM and Oracle being "it".
Sleepycat? Yeah, , Oracle and IBM do have little embedded data store products, but I'd hardly mention them in the same breath as FIlemaker, much less Oracle and DB/2. And as for MySQL and Postgres? Please. They're competition for Filemaker, MS Access, Interbase, Cloudbase and the like, and in some cases very good competition for them. But not even Postgres 7.x touches the lowest end of what the IBM, Oracle and Informix server products do. With live replication and decent hot backup features, maybe it could chew on their ankles, but that's about it. As for the middle-range, wake me up when Postgres can do clustering and failover, or when a single Postgres database can hit at least half a terabyte with good performance.
Not sure I agree with your premise that Unixes are farther along in this than, say, Windows and MacOS. Next time you're on a Windows 2000 machine, have a look at the features for synchronizing a network folder for use offline, not just the Briefcase. You can schedule syncs or have them take place during idle time.
MacOS has had a similar feature for years now, though it's a bit less slick.
As for other applications, last I checked, most mail programs, even low-end ones like Outlook Express and Netscape supported offline composition and reading, with message delivery on reconnect, and have for years. Internet Explorer's ability to pull down web pages and sites for offline browsing has been in since 4.0 and also keeps getting better, with automated background fetching and notification.
These sort of features could certainly stand to get better and easier to use; many people--yourself included, it seems--don't even know they exist, which certainly points up poor interface design and probably also bad documentation. But the funcionality is there.
Lotus in particular is good at these things. Not happy simply with Notes, the mother of all offline-sync application environments, they and IBM have now got interesting little personal web proxies and containers you can install that allow you to replicate working web-based applications, so that forms can be validated and local copies of databases can be updated with full logic offline through a browser interface.
Or are you asking about something else?
There's enough of a learning curve involved with sedond and third mouse buttons and shift- and control-click operations to where much of it is used only by "power users". This is interesting, again, for power users. But honestly, the mouse is only an "intuitive" tool when it has one button and no chording or other such behavior modifiers.
Mice have been in the mainstream since 1984. That's 17 years. It's shocking how little innovation there has been in interface design since the Apple Lisa. We're still dealing with mice, overlapping windows with raise/close widgets, modal dialogs and trashcan icons. I look back and remember that Radio Shack had rudimentary speech recogniton and speech synthesis peripherals available in 1981. Mass-produced flat touchscreens go back at least to the GRiDpad. Moving pointers with eye movements was done years ago.
Technologies like handwriting and speech recognition made strides right up to 1984 or so, and then stagnated until a few years ago. Human-language command parsing was coming along well, too, in the mid-1980s and has barely been heard from since. The WIMP (Windows, Icons, Mouse, Pointer) UI killed off interest in a lot of things.
Things like this gesture stuff--wildly non-intuitive extensions to mouse functionality--are indicative of the myopia and stagnation among interface designers. Mouse "gestures" will be useful to small, technical audiences like engineers, providing a shorthand for dealing with complex visulaization applications. But it's much too reliant on training and so completely non-intuitive that it can never be a viable direction for mainstream UIs.
Why, in the year 2001, some 14 years after GRiD's touchscreen-and-stylus tablets, can't people reading a document onscreen simply touch the corner of a doument and flick it to the left to turn a page? Why can't I pick up a pen and scribble recognizable corrections directly on a spreadsheet? Why, if I do want to use speech dictation software, can't I make corrections with a pen at the same time using standard proofreading marks? And why isn't my speech recognition profile stored on a central sever or on a pocket-sized dongle so I can dictate text from any computer or telephone anywhere? Why are keyboards still being used by people besides programmers, paralegals and data-entry clerks?
Why do command-line OSes not offer plain-English (or French or Mandarin) command recognition? Surely if the parser used in Zork worked as well as it did on a lowly 6502 back in 1981, and I used BBSes with plain-English command recognition ("Go to the library and download 'bluebox.txt'") in 1985, you'd think natural-language access to basic (and not-so-basic) file and system management operations, among other things, would be a piece of cake by now.
This isn't innovation. It's just sort of sad.
You have, say, 35 people in your buddy list, scattered across 20 servers. This isn't unrealistic given that on Linux, a Jabber server can only handle 1024 simultaneous users, at least according to jabber.org's own FAQ. So now, for the duration of your session, your client is communicating every few seconds with each of 20 servers to check your friends' online status. With a protocol that's robust, but not lean.
Your client communicates with the central JUD server every time you want to look someone new up. Without the central JUD server, the whole thing balkanizes into separate small, free-floating islands and there's no ability to add or contact people not on your home server to your list until it comes back, though you can keep talking to the people already on your list.
Your topology calls for many small, independently-run servers, which is going to be slow and unreliable; on any given day, any one server can shut down, die or disappear and its user base will be orphaned since there's no replication and failover of login services going on. Some are on mom-and-pop ISPs or run by nonprofits on a virtual server, some are big, fast systems. Some are in North America, others in the EU, and others in Egypt or Thailand. A server in Egypt will provide fast, reliable services to users in Egypt, but if they're on an American's buddy list, the Egyptian users' entries will drop in and out of the "logged in" status category as packets get lost in transit or connections sporadically time out, and vice versa.
Jabber has a design that can scale, yes. But I maintain that it cannot scale to AIM/ICQ/MSN/Yahoo size, and that's what a public IM system needs in order to be useful.
A more reliable topology might involve fewer, larger Jabber servers, each with a substantial portion of the user base--which gets right back to the question of how large servers get paid for.
Usenet and email are decentralized and asynchronous. When you're sending email or posting to Usenet, nothing is checking to see if the recipients are logged in.
With instant messaging, you can't get around the thing that distinguishes real-time chat from email: the real-time status monitoring. When you log in to a real-time chat system, you need to announce your presence to a central hub that reports your status to the other users who need to see your status. You can't do that with a decentralized system, at least not one with more than a couple thousand concurrent users. Multi-hop referrals or separate regional or ISP hubs each with their own members' login status are far too slow and bandwidth-intensive to work on a large scale.
A useful public instant-messaging system covering countries with tens of millions of people and thus hundreds of thousands to millions of concurrent users needs that central hub; otherwise your client is spending all of its time querying and processing data from any number of far-flung regional hubs.
Fine, Jabber has a faint outside chance of becoming a standard protocol for private instant-messaging systems, and might eventually compete well with things like Lotus Sametime and Microsoft's conferencing server.
Granted, this isn't all that likely since both Microsoft and Lotus can already integrate their instant messaging well with H.323 videoconferencing and with T.120 application-sharing and whiteboarding tools, and seamlessly tie in to directory services (not just for authentication) in ways that also make it fairly simple to link companies' and organizations' realtime messaging/collaboration together without relaying each other's messages. Fact is, Jabber is a good 2 or 3 years behind its competitors in the intranet space in terms of features. They're even miles behind the ICQ Groupware server.
As far as public instant-messaging goes, it wouldn't be fair to say Jabber has no chance of catching on. But those chances are slim. Let's say that for some reason it does. Who is going to run and pay for the giant Jabber servers sitting in the middle of everything? An instant messaging system that can support millions of concurrent users will not run on a single donated 4-processor box running Postgres or MySQL. It won't run on two. It's going to take a server farm or two with millions of dollars in hardware, millions of dollars in commercial database licenses, and millions of dollars in engineers' salaries to tend to it. Please remember that while the messaging itself is peer to peer, the login and buddy-status monitoring services are not.
How, exactly, is this going to be paid for if the clients are open-sourced, access to the servers is unrestricted, and advertising can be blocked? A tip jar?
I'll have to get back to you guys on this one. I've been too busy reviewing the SRPM for Emacs. Another two years and maybe I'll be ready to compile it.
Having a contract that that states severance terms certainly changes things.
And unions don't "force" employers to do anything. They are simply a means by which employees get the leverage necessary to get desirable employment terms, safe working conditions, and so forth. The ability to walk out en masse with a safety net (from union dues) is that leverage.
When all you've ever worked in is a bull market where you set the terms by which you work, as so many techies have for the past 10-15 years, it's easy not to notice how hard it is to get livable working consitions when it's the employer that has the upper hand. When, say, you have an oversupply of qualified people for a given job.
Given the rate at which people in the tech sector are being laid off and pay rates are leveling off and even starting to decline, I would have thought the brand of thuggish, anti-union conservatism so popular among geeks the past few years would be on the wane. (How exactly is it "libertarian" to argue that government should assist companies in blocking people from engaging in collective bargaining?)
When you guys get laid off without severance pay in a couple of months because your department's project is being moved to a subcontractor in Russia or India, let's see how anti-union you are. Right now, the only hot jobs are for J2EE programmers and senior sysadmins. Even those are likely to dry up at the rate things are going.
Anyway, back to the AFTRA/media-company standoff:
The broadcasters have had a good five years to negotiate terms for Internet rebroadcast with AFTRA. That's how long decent streaming has been around, so it's not as though this whole "internet" thing just blindsided everyone. When the broadcast companies decided to start collecting additional advertising fees for their Internet rebroadcasts, their lawyers were well aware of the terms of the AFTRA contracts that were in place.
The New York Post is a right-wing tabloid; be aware of their bias and as with any publication, read it with the appropriate decoder ring. Clear Channel has a business unit that runs separate Internet-only "radio" stations. It's entirely possible that this cutoff has less to do with AFTRA than it does with their desire to "replace" Internet rebroadcasts of radio stations, and eventually those stations themselves, with their cheap-to-run Internet stations with their anonymous, interchangeable, and non-union deejays.