God forbid AOL be allowed to collect ad revenue from an instant-messaging service that runs on millions of dollars worth of equipment. Instant messaging is only "cheap" and "easy" to implement when you have a few thousand users.
This is one case where GPL'ed software isn't going to win out for at least a few years. Right now, a large IM system requires massive, massively-parallel directory and routing services, which require massive databases (read: not MySQL or Postgres 7) and massive servers with fast interconnect and low latency.
All of this costs money. If you open the protocol and the servers to all comers, where does that money come from? The GAIM team could build in support for AOL's ads, but the GPL would allow for patched or forked versions that strip out the ads. So it wouldn't do AOL any good to ask the GAIM team to support its ads.
For a bunch of Microsoft-skeptics, Slashdot readers are mighty easily swayed by Microsoft's PR spin on this. AOL isn't being anti-competitive by blocking 3rd-party clients. They're protecting a revenue stream that pays (they hope) for dozens of racks of expensive servers and millions of dollars in database licenses.Microsoft and Yahoo aren't fighting for freedom. They're fighting to convince naive courts that they have a "right" to strip out AOL's ads--on a service AOL is paying for in its entirety--and replace them with their own ads. If it goes to arbitration and MS and Yahoo are told they can make AIM clients as long as they give AOL's ads and ad-reporting mechanisms clear passage, you'll see MS and Yahoo lose interest in the whole idea mighty quickly indeed.
Massive peer-to-peer systems without central servers are a tough thing to do right now. Just ask the folks at Napster and the other filesharing projects. All of them are running clusters of independent servers. Sign on to Napster twice, and you'll see two sets of users and files.
When an equally massive, fully-distributed scheme for instant message routing and directory services becomes viable, those expensive central servers can go away, and so can the need for massive revenue. Seems to me something could be cobbled together out of a stripped-down version of OpenLDAP and ml.org-style dynamic DNS projects, so that any of your devices that are connected report their presence, and the lookups get farmed out over zillions of LDAP servers doing referrals.
By the time this happens, of course, text-based instant messaging may well be fading out in favor of IP telephony and videoconferencing, both of which all of the instant-messaging players are rolling into their clients as fast as they can.
Doesn't anyone here use Helix-GNOME yet? This is just the existing Helix-update application shipped with Helix-GNOME swallowed into a window with a siebar.
In any event, helix-update is very nice stuff, probably the nicest end-user or small-network admin interface yet for RPM and dpkg. It's very friendly, very non-technical in its presentation, and well-designed. It's every bit as good and pleasant as the similar interfaces in MacOS 9 and Win98 and Win2K.
I find it endlessly fascinating that the core GNOME team, especially Miguel, made such an interface mess out of GNOME itself but have somehow managed to make the Helix stuff look and feel "right". Have they secretly hired a good human interface designer?
It's an SMB print server--apparently built out of Samba, no less. That means if you have Samba (or a commercial SMB implementation, for that matter) installed on your Unix, Linux or BSD systems, you can print to this just fine. Will HP engineers field your support calls? Nope. But will you be able to print? Absolutely.
And Samba's been bundled with civilized admin tools on every mainstream (read: bigger than 2 floppies) Linux distro of the past 4 years. It works like a champ on nearly every other Unix-like OS out there, too.
This particular model JetDirect is a bit different from most past ones. This one is for printers that are already network-enabled, and communicates with them by LPD. It's simply a way to add SMB print queues without running a disk-based print server.
On-board native SMB print queueing is still a fairly new and exotic feature on printers. LPD, Netware and Appletalk support aren't. Any printer you connect to this, by the way, already can be printed to directly from Unix via LPD (at the very least). But if you want to manage a single print queue for, say, logging and accounting purposes, all you need to do to bring Unix clients under this is to add four simple lines to your Samba config for each printer this is managing.
On another note: I've never seen an HP network printer that didn't support LPD natively. It's the baseline protocol for network printers.
I'm not sure what you do at VA/Andover, Rob, but if you're just hacking Slashcode, maybe you should treat your employment at VA/Andover as an opportunity to learn a bit about the IT real world, about heterogeneous networks built out of systems running things other than Linux and *BSD.
HP's network printers all support LPD. If you have even one mediocre PCL5-to-Postscript filter for Ghostscript, you can print to it. If your printer supports Postscript, you don't even need that little bit of configuration.
A JetDirect server is a little box or card that converts a non-network printer into a network printer, typically by receiving jobs via ethernet and handing them to the device's parallel interface. I've never seen a JetDirect server that didn't support LPD. As far as I know, they all do. HP is a large Unix vendor, after all. Most Windows printing to HP network printers prior to this native SMB support is actually done via LPD. Client machines send jobs via SMB to a print server (typically an NT box), and the print server transmits it as an LPD job to the printer. The newer JetDirect cards remove the need to run a "software" print server by putting the SMB support into (or next to) the printer.
Later JetDirect models have added built-in support for Netware, Ethertalk and most recently, direct SMB support. If for some reason (security, strict job management, or some weird neurosis) you want to print fron Linux machines using something other than LPD, you're certainly welcome to do so. Netatalk and CAP both support Ethertalk printing, Mars-NWE (if I recall) supports Netware printing, and Samba supports SMB printing just fine, and they've all done so for years.
Unless HP has suddenly abandoned all four of these protocols (and no, they haven't) in favor of a strage new networked variation of PPA (the "Winprinter" protocol on some of their cheap inkjets), you can print from Linux very easily indeed on any and all JetDirect-connected printers. Not to mention the myriad LPD-capable Xerox, Canon, Textronix and IBM printers chugging away out there. Granted, if you have a $50,000 printer with multiple output trays, six paper drawers, multipoint stapling, a laminator and an envelope-stuffing attachment, you're not going to have a Linux driver on hand that can use all of those features. But you'll be able to print just fine.
It's pretty questionable whether DMCA and contractual prohibitions on reverse-engineering will hold up in court, and doubly so when dealing with a fairly transparent, essentially unencrypted protocol. Everquest's EULA does explicitly bind users of the software not to reverse-engineer it, but even beyond the enforceability of this clause, the end user is also prohibited from using the client with non-approved (read: clone) servers.
So even if you developed a clean-room server clone that stood up to legal scrutiny, end users are prohibited from using it. In other words, you might be able to defend the creation of the server, but nobody can play on it with a real Everquest client. The players don't own the software, you know. They just have a revocable license to use it with the official servers under its terms of service.
My approach to defending against this--if the clone server was made in a defensible, double-blind manner--would start by warning users that connecting to a clone server is a violation of their Everquest license agreement and that they (the players) are open to prosecution if they connect to it with the offiicial software.
You may want focus on a (clean-room) clone of the client. Even an incomplete, experimental one. And then distribute it so that it becomes difficult to determine who is connecting to the clone servers with an EULA-violating official client. After all, if there's reasonable probability that a given user on a legal clone server is using a legal clone client, a judge feel that a request to subpoena IP traffic information logging who was connecting to the server and when would be too broad and invasive.
Just some thoughts. Your lawyer's advice may be very different.
Man, the signal-to-noise ratio here just keeps getting worse. Dvorak keyboards and "good" keyboards ain't gonna stop RSI. Dictation software alone isn't well suited to coding, what with the massive amounts of critical punctuation and formatting. And handwriting and gesture recognition is just plain slow compared to typing or speech.
What I'm surprised by is how little imagination the handwriting recognition and speech-recognition developers have. Dictation software is usually used by people who *do* have the use of at least one hand. So why not have hybrid interfaces?
The tedious process of editing material in a dictation environment could be simplified and sped up greatly if you could simultaneously use a stylus to jump the cursor around and scriblle out or mark errors--or make corrections. You could also be presented with floating popups showing choices for ambiguous words and phrases the dictation engine is having trouble with even as you continue to dictate.
I think a hybrid interface like this--using handwriting, gestures and speech together would allow for quicker and more precise and efficient dictation, and would make dictating things like source code or scientific data and equations at least as quick and fluid as keyboarding.
It really is about time the keyboard and that other vile RSI torture device, the mouse, started to go away for most applications. Shaking developers out of the misguided focus on 100% hands-free dictation and all-or-nothing handwriting recognition would help immensely.
Them Kodak cameras have been running MAME for almost a year now, as reported previously here on Slashdot. Good, now they've got the a direct port of the PC/Unix version of Doom.
Um, Bonobo, KDE's DCOP, OLE, any drag-n-drop
on
Pipes In GUI's
·
· Score: 3
Plenty of GUI applications have been piping between each other for years now. Apart from some scientific and audio/video processing apps, the UI representation is usually different, but the purpose and function are the same. When you embed an updateable spreadsheet in a word processing document, that's piping. When you drag a document icon to a prionter icon, you're piping to the application that renders the document for printing, which in turn pipes to the print spooler. Ditto when you drag and drop a compressed file's icon onto an icon representing a decompression program.
Implementing a pipe metaphor into an entire UI framework isn't a bad idea. It is one that will likely have a small, techy audience. Using a nonverbal GUI to indicate what is being piped and to where, you run into a lot of ambiguity. When you connect one widget or window to another, what is it you're piping?
the content of a widget, the underlying value passed by the widget, the functioning widget itself, or the bitmap/vector graphic contents of the widget?
at this moment in time, or updated dynamically?
Plain text? HTML? Richtext?
At a certain point in the stagnant WIMP interface, getting at these distinctions involves wizards and property sheets, and it ends up looking and feeling like an IDE.
Again, truly ubiquitous embedding and linking at the desktop environment level would be useful for programmers and for some power-user applications. But I wouldn't expect it to take the world by storm in the two-dimensional, mouse-driven windowing environments we use today, outside the self-contained applications (like audio processors) that it's used in already.
Apply the concept to VR interfaces and tactile interfaces, and maybe it'll be something fluidly usable for everyday use.
id3 tags are in MP3 file because they're part of the MP3 file format spec. Ditto.xcf files. In order to attach similar metadata to other filetypes that don't already have metadata blocks, you need a scheme at the filesystem access level that manages and accesses a "shadow" filesystem or a database containing this data. In other words, something like the MacOS's resource forks, which have been around for over 15 years.
The problem, of course, is that the internet's file-transfer protocols like HTTP, FTP, NFS, SMB and, heck, DCC transfers over IRC, have no notion of multi-"fork" files, designed as they are around the Unix/DOS/CPM/etc. file model. This is why Mac users often user Binhex or MacBinary formats to Base64 encode files they transfer over the 'net. What's actually happening is the file itself and its resource fork (where the icons, metadata and so forth are stored) are being packaged together so that the two parts can be reconsitituted when they're received on another Mac. As the Mac world has gradually strived to interoperate better with the rest of the computing world, less and less of a file is being stored in resource forks. Where once all the bitmaps and dialogs and audio samples used by a Mac database or multimedia file might have been in the resource fork, now cross-platform compatibility has cut that back to little more than a file's icon and its mimetype.
The problem with doing this on Linux--or any Unix or on DOS and Windows, for that matter--is that the tools that read, write and move files around aren't built to accomodate multipart files, apart from limited support for things like versioning in some of the more advanced OSes.
If you want to do something like this without changing the file formats themselves, you need to start by getting down to the filesystem level so that all read and write operations also read and write the metadata, whether to a database or to parallel invisible files, transparently.
I think there are two things that make a palette a palette:
A thinner titlebar on the window
No "close" button on the window. Closing is done by clicking the "close" widget in the titlebar or through program menus only.
If it's just palettes Adobe's claiming, Macromedia simply needs to give their "palettes" a thicker titlebar, which would turn them into "dialog boxes".
Thing is, AIM costs money to run. It's made out of piles of servers, large, speedy SQL databases and a bunch of load balancers and replication machines. AIM may seem simple, but on that kind of massive scale, it certainly isn't. The only current revenue stream for it is inline ads and integrated add-ons like Net2Phone. AOL doesn't really give a rat's ass who makes AIM-compatible clients; they just want clients out there that they're collecting all the ad revenue from. They don't go after the Unix clients aggressively because they account for practically no traffic at all.
Now that AOL's getting into the net appliance business and gearing up to offer AOL service to Linux devices, Linux is a platform they care about because it will eventually be the platform of a big chunk of their user base. So they need an AIM client that they control, that they can serve ads to that can't be disabled, among other things.
GAIM, swell as it is, can't be the basis for AOL's official Linux AIM client. Why? Because GAIM is GPL'ed, not even issued under a dual license. So anything they do with the GAIM code would have to be released as open source. Which would mean that folks would be able to make adless versions of it.
Once a good 3-4% of AIM users are using Linux, or AOL starts offering its paid services via Linux devices, you should expect to see GAIM, TiK and the other OSS AIM clients get blocked out just as agressively as MSN Instant Messenger has been.
And once AOL works out contracts with Microsoft, Yahoo, et al. that guarantee free flow and full reporting of AOL's ads, you'll see MSN Messenger, etc. suddenly gain access to AOL's network. Not so the OSS stuff, because it would imply discriminatory business practices.
If GAIM were under a BSD-style or MPL-style license, you can bet AOL would make use of their code. My hunch is that the GAIM developers have no interest in a license that allows closed-source forks in the code, though. Good for them. But honestly, the GPL doesn't leave much room to work out a deal by which the GAIM developers could offer up AOL's ad stream in exchange for continued access to the AIM servers from an "official" GAIM release.
The moral of the story? The GAIM team should start thinking about exit strategies. Do they modularize it and release each module separately under the GPL so they can be used as plugins by AOL's official client? Do they go to a dual-license model so AOL can use all their hard work? Do they find new projects to work on and leave it out to dry so none of the code gets used by AOL?
Poor thing can probably only handle three or four simultaneous users, what with being a CGI and all. And probably one in an interpreted scripting language at that.
Maybe in two or three weeks when the story is sufficiently hard to find in the/. archives it'll be possible to have a look at it.
I'm seeing a clear pattern here. Nearly every story Timothy posts is either exceptionally stupid, or it's a rerun of of something that's been discussed here recently. I am sure that if I screened out all of his stories, I wouldn't be missing anything important or interesting.
Any chance of getting adding to/. preferences the ability to screen out stories posted by a given editor? I'd be happy to cut things down to Rob, Neal, Nate and Roblimo if I could.
No offense, Tim. I'm sure you're a swell guy. But jeez.
Doesn't anyone make flowcharts or other software and data diagrams before they launch their text editor? Assuming you're writing new code and not debugging, why are you staring at the screen? Coding anything vaguely complex off the top of your head is Not Good.
Stop thinking in C++. Start with the big picture. Map out the problem. Then drill down to the architecture. Then drill down to the core functions of each module. Then firm up your data/object models. Next, drill down to the detailed design. Most of this should be boxes, arrows and lines, not code.
Then, and only then, start doing serious real coding. If you wing it, you're liable to get stuck or produce something pretty unwieldy.
Why should basic end-user interaction with a computer be arcane and require training or hours with a shelf of books?
As a lone voice up there said, you should be able to view your wedding photos by saying, typing, writing or thinking "show me my wedding photos". Not "see-dee slash-home-slash-images-slash-wedding, semicolon ee-ee dot-slash-star-dot-jay-peg".
This is about natural-language recognition. A Unix, DOS, CP/M or VMS shell is not natural-language.
It's about time we got back to this. The Apple Lisa and the Macintosh did untold damage to progress in this area when it made the WIMP GUI the new standard way for an end user to interact with a computer. Nobody wanted to work on refining the command-line interface for end users, so the command line became an ever-more byzantine interface solely for programmers and administrators.
I remember back in the mid-1980s using dialup BBSes that had natural language interfaces. They ran on humble PC ATs, and set Zork and the other Infocom text adventures as their benchmark for success. These bulletin boards worked just fine with commands like
go to the library and download "BLUEBOX.TXT"
list the forums
go to the cafe and read the new messages
post a message
how long have i been connected?
If a BBS running on a system with 320K of RAM could do that in 1985, imagine what a WebTV should be capable of today, never mind a current-day traditional PC. It's about time companies and organizations doing UI research came back to this; the Unix CLI hasn't evoled significantly since the mid 1980s, and the windowing GUI hasn't changed significantly since around 1988.
It doesn't surprise me that/. regulars are dismissive about this with the usual nonsense about making the average person who wants to surf the web and write email learn Unix shell programming. Phooey. Most people use computers as an appliance, not as the center of their lives or as an end in themselves, just as most Linux heads eat pizza without knowing how to make cheese from raw milk.
Nobody's going to take good ol'/bin/bash away from you. Stop begrudging non-programmers ease-of-use.
I don't think this is going to be the invention that turns around Ukraine's economy.
More seriously, I'd guess this is a way to grab attention for what is, after all, a PCI card that can hold a 6-low-power processor Linux parallel computer. The SETI client in flash ROM is sort of silly, but burn your own algorithms into it and you have a mighty interesting coprocessor similar to the sort of things Microway makes, for $500.
The pricing for Palm VII service isn't great, especially compared to Omnisky service. But it's competitive with American web-enabled phones, so there's not much to complain about there.
I think the month of solid use I get out of a pair of AAA alkalines on a VII is just fine; granted, it's not as good as the 6-8 weeks I got on a Palm Pro or III. And it's much more convenient than having to worry about buying weird batteries or having to carry around a cradle when you travel just so you can charge the thing.
It really did need more RAM, though; thank goodness they've bumped it to 8MB. As far as I'm concerned, that should be the norm for anything they sell for $200 or more at this point.
For one thing, SCO has Tarantella, a nifty multi-OS graphical-terminal-server technology similar to Citrix's MetaFrame. For another thing, SCO's Unix has some nice innards that would be nice to get hold of, although as others have noted, some of those pieces may end up being sold off separately to a company like Sun.
But more importantly, probably, SCO has an estblished professional sales force and field offices, and a Rolodex full of current paying customers at medium-to-large companies that have both server and desktop deployments of Unix on x86 hardware. Caldera's desktop and server Linux distros target SCO's traditional markets directly, more so than any other Linux distro, and they're probably looking to set up more field sales offices and build up their sales force.
Sounds like the consumer-ratings strategy Deja's moved to hasn't been working and they're grabbing at any idea that might, might, might catch on and get them more page views and ad revenue.
Incidentally, it's a touch arrogant of them to use a generically-named header field that other, more scrupulous Usenet archivers would use, as their opt-out trigger now that they're in the business of editing people's posts without consent. Maybe folks just don't want their posts archived by Deja in light of something like this.
And for the record, it most certainly does give the appearance of being a hyperlink created by the post's author. Putting ads and links in a aidebar--even right next to the relevant line in the post--would not.
It's certainly creative on their part, but it's not going to be the "innovation" that saves them. Deja's move away from straight Usenet webification to being a product and service rating site was a good idea. Their big problem is that their interface design is more convoluted than their competitors'. And more convoluted than a newsreader, which is no easy feat.
You'd think they'd have hired an interface designer by now. Maybe they've never talked to regular users or held any focus groups.
TeraTerm and the SSH version of it work very nicely. TeraTerm isn't the flashiest telnet client around, but it does do correct display emulation (a rare thing even in commercial packages), has a correct keymap, and decent copy/paste support. I like it better than a number of shareware and commercial ones I've had.
The Java port of the WP Office suite had reached a reasonable beta quality by the time they scrapped it. Public demos were available. It has a pretty broad feature set, and an interesting, somewhat StarOffice-like single-window user interface.
However, this being 1996 and Java being what it was back then, it was too slow to be useful on 95% of the hardware of the day. The level of polish, while not perfect, was very impressive considering that it was done with AWT, these being pre-Swing (and pre-JIT) days.
Since it needed insanely fast hardware (for the time) to run, the goal of deploying it on low-end networked computers wasn't realistic. Add to that the clear trend in the world of terminal computing toward very-thin clients (X, Citrix, Tarantella, etc.), and the reasons for making an office suite for Java-enabled diskless stations fall away. Corel put their thin-client energy, such as it was, into projects like the NetWinder and GraphOn's Citrix-like remote-display-server technology.
It wasn't a "rumor". It was a well-publicized project and a nifty proof-of-concept with working demos open to the public on their website.
The computing world wasn't ready (literally, from a hardware standpoint) for large-scale Java desktop apps at the time.. but Corel, incompetent though they may be, did manage to prove it could be done.
When someone's job involves accessing mainframe data on a terminal emulator and dashing off brief e-mails and faxes, you do not want that person to use a word processor in the course of their work. A word processor, with its font choices, advanced formatting tools and endless options is a huge productivity drain when it's used for short notes and memos, just as pick-and-pack staff in a warehouse shouldn't have a spreadhseet or presentation package available on shop-floor terminals, but the warehouse managers should.
Does this neatly counteract the argument that MS Office applications are necessary for complex, scripted integration (via Visual Basic)?
Say what? That's quite a leap in logic. No, MS Office applications are still necessary for scripted integration compatbile with MS Office, though. Python's a nonstarter here. Corel WP Office now uses a language with VBA syntax (but not its object model) as its scripting language. StarOffice also has a VBA-clone language with its own object model, as well as the options to script in Javascript and from Java. Lotus and Vistasource/Applix each have their own scripting languages.
This means Corel and StarOffice users can leverage skills honed on MS Office without being able to reuse any macros directly.. and Lotus users can leverage Notes skills. What advantages Applix offers to people who have used office software for eludes me.
So no, you never needed MS Office to script and integrate office suites. You just need it to script and integrate with MS Office.
Will someone please enroll Tim in a remedial/. editor's course? I'm sure you're a swell coder/hardware geek/washroom attendant/whatever at BSI, dude, but the stories you post.. and the comments you make.. Heavens.;]
Slashdot Mirror
God forbid AOL be allowed to collect ad revenue from an instant-messaging service that runs on millions of dollars worth of equipment. Instant messaging is only "cheap" and "easy" to implement when you have a few thousand users.
This is one case where GPL'ed software isn't going to win out for at least a few years. Right now, a large IM system requires massive, massively-parallel directory and routing services, which require massive databases (read: not MySQL or Postgres 7) and massive servers with fast interconnect and low latency.
All of this costs money. If you open the protocol and the servers to all comers, where does that money come from? The GAIM team could build in support for AOL's ads, but the GPL would allow for patched or forked versions that strip out the ads. So it wouldn't do AOL any good to ask the GAIM team to support its ads.
For a bunch of Microsoft-skeptics, Slashdot readers are mighty easily swayed by Microsoft's PR spin on this. AOL isn't being anti-competitive by blocking 3rd-party clients. They're protecting a revenue stream that pays (they hope) for dozens of racks of expensive servers and millions of dollars in database licenses.Microsoft and Yahoo aren't fighting for freedom. They're fighting to convince naive courts that they have a "right" to strip out AOL's ads--on a service AOL is paying for in its entirety--and replace them with their own ads. If it goes to arbitration and MS and Yahoo are told they can make AIM clients as long as they give AOL's ads and ad-reporting mechanisms clear passage, you'll see MS and Yahoo lose interest in the whole idea mighty quickly indeed.
Massive peer-to-peer systems without central servers are a tough thing to do right now. Just ask the folks at Napster and the other filesharing projects. All of them are running clusters of independent servers. Sign on to Napster twice, and you'll see two sets of users and files.
When an equally massive, fully-distributed scheme for instant message routing and directory services becomes viable, those expensive central servers can go away, and so can the need for massive revenue. Seems to me something could be cobbled together out of a stripped-down version of OpenLDAP and ml.org-style dynamic DNS projects, so that any of your devices that are connected report their presence, and the lookups get farmed out over zillions of LDAP servers doing referrals.
By the time this happens, of course, text-based instant messaging may well be fading out in favor of IP telephony and videoconferencing, both of which all of the instant-messaging players are rolling into their clients as fast as they can.
Doesn't anyone here use Helix-GNOME yet? This is just the existing Helix-update application shipped with Helix-GNOME swallowed into a window with a siebar.
In any event, helix-update is very nice stuff, probably the nicest end-user or small-network admin interface yet for RPM and dpkg. It's very friendly, very non-technical in its presentation, and well-designed. It's every bit as good and pleasant as the similar interfaces in MacOS 9 and Win98 and Win2K.
I find it endlessly fascinating that the core GNOME team, especially Miguel, made such an interface mess out of GNOME itself but have somehow managed to make the Helix stuff look and feel "right". Have they secretly hired a good human interface designer?
It's an SMB print server--apparently built out of Samba, no less. That means if you have Samba (or a commercial SMB implementation, for that matter) installed on your Unix, Linux or BSD systems, you can print to this just fine. Will HP engineers field your support calls? Nope. But will you be able to print? Absolutely.
And Samba's been bundled with civilized admin tools on every mainstream (read: bigger than 2 floppies) Linux distro of the past 4 years. It works like a champ on nearly every other Unix-like OS out there, too.
This particular model JetDirect is a bit different from most past ones. This one is for printers that are already network-enabled, and communicates with them by LPD. It's simply a way to add SMB print queues without running a disk-based print server.
On-board native SMB print queueing is still a fairly new and exotic feature on printers. LPD, Netware and Appletalk support aren't. Any printer you connect to this, by the way, already can be printed to directly from Unix via LPD (at the very least). But if you want to manage a single print queue for, say, logging and accounting purposes, all you need to do to bring Unix clients under this is to add four simple lines to your Samba config for each printer this is managing.
On another note: I've never seen an HP network printer that didn't support LPD natively. It's the baseline protocol for network printers.
I'm not sure what you do at VA/Andover, Rob, but if you're just hacking Slashcode, maybe you should treat your employment at VA/Andover as an opportunity to learn a bit about the IT real world, about heterogeneous networks built out of systems running things other than Linux and *BSD.
HP's network printers all support LPD. If you have even one mediocre PCL5-to-Postscript filter for Ghostscript, you can print to it. If your printer supports Postscript, you don't even need that little bit of configuration.
A JetDirect server is a little box or card that converts a non-network printer into a network printer, typically by receiving jobs via ethernet and handing them to the device's parallel interface. I've never seen a JetDirect server that didn't support LPD. As far as I know, they all do. HP is a large Unix vendor, after all. Most Windows printing to HP network printers prior to this native SMB support is actually done via LPD. Client machines send jobs via SMB to a print server (typically an NT box), and the print server transmits it as an LPD job to the printer. The newer JetDirect cards remove the need to run a "software" print server by putting the SMB support into (or next to) the printer.
Later JetDirect models have added built-in support for Netware, Ethertalk and most recently, direct SMB support. If for some reason (security, strict job management, or some weird neurosis) you want to print fron Linux machines using something other than LPD, you're certainly welcome to do so. Netatalk and CAP both support Ethertalk printing, Mars-NWE (if I recall) supports Netware printing, and Samba supports SMB printing just fine, and they've all done so for years.
Unless HP has suddenly abandoned all four of these protocols (and no, they haven't) in favor of a strage new networked variation of PPA (the "Winprinter" protocol on some of their cheap inkjets), you can print from Linux very easily indeed on any and all JetDirect-connected printers. Not to mention the myriad LPD-capable Xerox, Canon, Textronix and IBM printers chugging away out there. Granted, if you have a $50,000 printer with multiple output trays, six paper drawers, multipoint stapling, a laminator and an envelope-stuffing attachment, you're not going to have a Linux driver on hand that can use all of those features. But you'll be able to print just fine.
It's pretty questionable whether DMCA and contractual prohibitions on reverse-engineering will hold up in court, and doubly so when dealing with a fairly transparent, essentially unencrypted protocol. Everquest's EULA does explicitly bind users of the software not to reverse-engineer it, but even beyond the enforceability of this clause, the end user is also prohibited from using the client with non-approved (read: clone) servers.
So even if you developed a clean-room server clone that stood up to legal scrutiny, end users are prohibited from using it. In other words, you might be able to defend the creation of the server, but nobody can play on it with a real Everquest client. The players don't own the software, you know. They just have a revocable license to use it with the official servers under its terms of service.
My approach to defending against this--if the clone server was made in a defensible, double-blind manner--would start by warning users that connecting to a clone server is a violation of their Everquest license agreement and that they (the players) are open to prosecution if they connect to it with the offiicial software.
You may want focus on a (clean-room) clone of the client. Even an incomplete, experimental one. And then distribute it so that it becomes difficult to determine who is connecting to the clone servers with an EULA-violating official client. After all, if there's reasonable probability that a given user on a legal clone server is using a legal clone client, a judge feel that a request to subpoena IP traffic information logging who was connecting to the server and when would be too broad and invasive.
Just some thoughts. Your lawyer's advice may be very different.
Man, the signal-to-noise ratio here just keeps getting worse. Dvorak keyboards and "good" keyboards ain't gonna stop RSI. Dictation software alone isn't well suited to coding, what with the massive amounts of critical punctuation and formatting. And handwriting and gesture recognition is just plain slow compared to typing or speech.
What I'm surprised by is how little imagination the handwriting recognition and speech-recognition developers have. Dictation software is usually used by people who *do* have the use of at least one hand. So why not have hybrid interfaces?
The tedious process of editing material in a dictation environment could be simplified and sped up greatly if you could simultaneously use a stylus to jump the cursor around and scriblle out or mark errors--or make corrections. You could also be presented with floating popups showing choices for ambiguous words and phrases the dictation engine is having trouble with even as you continue to dictate.
I think a hybrid interface like this--using handwriting, gestures and speech together would allow for quicker and more precise and efficient dictation, and would make dictating things like source code or scientific data and equations at least as quick and fluid as keyboarding.
It really is about time the keyboard and that other vile RSI torture device, the mouse, started to go away for most applications. Shaking developers out of the misguided focus on 100% hands-free dictation and all-or-nothing handwriting recognition would help immensely.
Let's see. Linux, Red Hat, Amiga, a gaming SDK, Corel, Java and vaporware. All in one item.
The only way to make it more ridiculous would be to somehow connect it to Pete Townshend and the next Star Wars movie.
Them Kodak cameras have been running MAME for almost a year now, as reported previously here on Slashdot. Good, now they've got the a direct port of the PC/Unix version of Doom.
Implementing a pipe metaphor into an entire UI framework isn't a bad idea. It is one that will likely have a small, techy audience. Using a nonverbal GUI to indicate what is being piped and to where, you run into a lot of ambiguity. When you connect one widget or window to another, what is it you're piping?
- the content of a widget, the underlying value passed by the widget, the functioning widget itself, or the bitmap/vector graphic contents of the widget?
- at this moment in time, or updated dynamically?
- Plain text? HTML? Richtext?
At a certain point in the stagnant WIMP interface, getting at these distinctions involves wizards and property sheets, and it ends up looking and feeling like an IDE.Again, truly ubiquitous embedding and linking at the desktop environment level would be useful for programmers and for some power-user applications. But I wouldn't expect it to take the world by storm in the two-dimensional, mouse-driven windowing environments we use today, outside the self-contained applications (like audio processors) that it's used in already.
Apply the concept to VR interfaces and tactile interfaces, and maybe it'll be something fluidly usable for everyday use.
id3 tags are in MP3 file because they're part of the MP3 file format spec. Ditto .xcf files. In order to attach similar metadata to other filetypes that don't already have metadata blocks, you need a scheme at the filesystem access level that manages and accesses a "shadow" filesystem or a database containing this data. In other words, something like the MacOS's resource forks, which have been around for over 15 years.
The problem, of course, is that the internet's file-transfer protocols like HTTP, FTP, NFS, SMB and, heck, DCC transfers over IRC, have no notion of multi-"fork" files, designed as they are around the Unix/DOS/CPM/etc. file model. This is why Mac users often user Binhex or MacBinary formats to Base64 encode files they transfer over the 'net. What's actually happening is the file itself and its resource fork (where the icons, metadata and so forth are stored) are being packaged together so that the two parts can be reconsitituted when they're received on another Mac. As the Mac world has gradually strived to interoperate better with the rest of the computing world, less and less of a file is being stored in resource forks. Where once all the bitmaps and dialogs and audio samples used by a Mac database or multimedia file might have been in the resource fork, now cross-platform compatibility has cut that back to little more than a file's icon and its mimetype.
The problem with doing this on Linux--or any Unix or on DOS and Windows, for that matter--is that the tools that read, write and move files around aren't built to accomodate multipart files, apart from limited support for things like versioning in some of the more advanced OSes.
If you want to do something like this without changing the file formats themselves, you need to start by getting down to the filesystem level so that all read and write operations also read and write the metadata, whether to a database or to parallel invisible files, transparently.
If it's just palettes Adobe's claiming, Macromedia simply needs to give their "palettes" a thicker titlebar, which would turn them into "dialog boxes".
This is funny.
Thing is, AIM costs money to run. It's made out of piles of servers, large, speedy SQL databases and a bunch of load balancers and replication machines. AIM may seem simple, but on that kind of massive scale, it certainly isn't. The only current revenue stream for it is inline ads and integrated add-ons like Net2Phone. AOL doesn't really give a rat's ass who makes AIM-compatible clients; they just want clients out there that they're collecting all the ad revenue from. They don't go after the Unix clients aggressively because they account for practically no traffic at all.
Now that AOL's getting into the net appliance business and gearing up to offer AOL service to Linux devices, Linux is a platform they care about because it will eventually be the platform of a big chunk of their user base. So they need an AIM client that they control, that they can serve ads to that can't be disabled, among other things.
GAIM, swell as it is, can't be the basis for AOL's official Linux AIM client. Why? Because GAIM is GPL'ed, not even issued under a dual license. So anything they do with the GAIM code would have to be released as open source. Which would mean that folks would be able to make adless versions of it.
Once a good 3-4% of AIM users are using Linux, or AOL starts offering its paid services via Linux devices, you should expect to see GAIM, TiK and the other OSS AIM clients get blocked out just as agressively as MSN Instant Messenger has been.
And once AOL works out contracts with Microsoft, Yahoo, et al. that guarantee free flow and full reporting of AOL's ads, you'll see MSN Messenger, etc. suddenly gain access to AOL's network. Not so the OSS stuff, because it would imply discriminatory business practices.
If GAIM were under a BSD-style or MPL-style license, you can bet AOL would make use of their code. My hunch is that the GAIM developers have no interest in a license that allows closed-source forks in the code, though. Good for them. But honestly, the GPL doesn't leave much room to work out a deal by which the GAIM developers could offer up AOL's ad stream in exchange for continued access to the AIM servers from an "official" GAIM release.
The moral of the story? The GAIM team should start thinking about exit strategies. Do they modularize it and release each module separately under the GPL so they can be used as plugins by AOL's official client? Do they go to a dual-license model so AOL can use all their hard work? Do they find new projects to work on and leave it out to dry so none of the code gets used by AOL?
Poor thing can probably only handle three or four simultaneous users, what with being a CGI and all. And probably one in an interpreted scripting language at that.
/. archives it'll be possible to have a look at it.
Maybe in two or three weeks when the story is sufficiently hard to find in the
Okay, okay. Now I see it. I missed it among the 8 other blocks of checkboxes on that one of the three vaguely-named prefs pages. Phew. Much better.
I'm seeing a clear pattern here. Nearly every story Timothy posts is either exceptionally stupid, or it's a rerun of of something that's been discussed here recently. I am sure that if I screened out all of his stories, I wouldn't be missing anything important or interesting.
/. preferences the ability to screen out stories posted by a given editor? I'd be happy to cut things down to Rob, Neal, Nate and Roblimo if I could.
Any chance of getting adding to
No offense, Tim. I'm sure you're a swell guy. But jeez.
Doesn't anyone make flowcharts or other software and data diagrams before they launch their text editor? Assuming you're writing new code and not debugging, why are you staring at the screen? Coding anything vaguely complex off the top of your head is Not Good.
Stop thinking in C++. Start with the big picture. Map out the problem. Then drill down to the architecture. Then drill down to the core functions of each module. Then firm up your data/object models. Next, drill down to the detailed design. Most of this should be boxes, arrows and lines, not code.
Then, and only then, start doing serious real coding. If you wing it, you're liable to get stuck or produce something pretty unwieldy.
As a lone voice up there said, you should be able to view your wedding photos by saying, typing, writing or thinking "show me my wedding photos". Not "see-dee slash-home-slash-images-slash-wedding, semicolon ee-ee dot-slash-star-dot-jay-peg".
This is about natural-language recognition. A Unix, DOS, CP/M or VMS shell is not natural-language.
It's about time we got back to this. The Apple Lisa and the Macintosh did untold damage to progress in this area when it made the WIMP GUI the new standard way for an end user to interact with a computer. Nobody wanted to work on refining the command-line interface for end users, so the command line became an ever-more byzantine interface solely for programmers and administrators.
I remember back in the mid-1980s using dialup BBSes that had natural language interfaces. They ran on humble PC ATs, and set Zork and the other Infocom text adventures as their benchmark for success. These bulletin boards worked just fine with commands like
- go to the library and download "BLUEBOX.TXT"
- list the forums
- go to the cafe and read the new messages
- post a message
- how long have i been connected?
If a BBS running on a system with 320K of RAM could do that in 1985, imagine what a WebTV should be capable of today, never mind a current-day traditional PC. It's about time companies and organizations doing UI research came back to this; the Unix CLI hasn't evoled significantly since the mid 1980s, and the windowing GUI hasn't changed significantly since around 1988.It doesn't surprise me that /. regulars are dismissive about this with the usual nonsense about making the average person who wants to surf the web and write email learn Unix shell programming. Phooey. Most people use computers as an appliance, not as the center of their lives or as an end in themselves, just as most Linux heads eat pizza without knowing how to make cheese from raw milk.
Nobody's going to take good ol' /bin/bash away from you. Stop begrudging non-programmers ease-of-use.
I don't think this is going to be the invention that turns around Ukraine's economy.
More seriously, I'd guess this is a way to grab attention for what is, after all, a PCI card that can hold a 6-low-power processor Linux parallel computer. The SETI client in flash ROM is sort of silly, but burn your own algorithms into it and you have a mighty interesting coprocessor similar to the sort of things Microway makes, for $500.
The pricing for Palm VII service isn't great, especially compared to Omnisky service. But it's competitive with American web-enabled phones, so there's not much to complain about there.
I think the month of solid use I get out of a pair of AAA alkalines on a VII is just fine; granted, it's not as good as the 6-8 weeks I got on a Palm Pro or III. And it's much more convenient than having to worry about buying weird batteries or having to carry around a cradle when you travel just so you can charge the thing.
It really did need more RAM, though; thank goodness they've bumped it to 8MB. As far as I'm concerned, that should be the norm for anything they sell for $200 or more at this point.
For one thing, SCO has Tarantella, a nifty multi-OS graphical-terminal-server technology similar to Citrix's MetaFrame. For another thing, SCO's Unix has some nice innards that would be nice to get hold of, although as others have noted, some of those pieces may end up being sold off separately to a company like Sun.
But more importantly, probably, SCO has an estblished professional sales force and field offices, and a Rolodex full of current paying customers at medium-to-large companies that have both server and desktop deployments of Unix on x86 hardware. Caldera's desktop and server Linux distros target SCO's traditional markets directly, more so than any other Linux distro, and they're probably looking to set up more field sales offices and build up their sales force.
Sounds like a sensible move to me.
Sounds like the consumer-ratings strategy Deja's moved to hasn't been working and they're grabbing at any idea that might, might, might catch on and get them more page views and ad revenue.
Incidentally, it's a touch arrogant of them to use a generically-named header field that other, more scrupulous Usenet archivers would use, as their opt-out trigger now that they're in the business of editing people's posts without consent. Maybe folks just don't want their posts archived by Deja in light of something like this.
And for the record, it most certainly does give the appearance of being a hyperlink created by the post's author. Putting ads and links in a aidebar--even right next to the relevant line in the post--would not.
It's certainly creative on their part, but it's not going to be the "innovation" that saves them. Deja's move away from straight Usenet webification to being a product and service rating site was a good idea. Their big problem is that their interface design is more convoluted than their competitors'. And more convoluted than a newsreader, which is no easy feat.
You'd think they'd have hired an interface designer by now. Maybe they've never talked to regular users or held any focus groups.
TeraTerm and the SSH version of it work very nicely. TeraTerm isn't the flashiest telnet client around, but it does do correct display emulation (a rare thing even in commercial packages), has a correct keymap, and decent copy/paste support. I like it better than a number of shareware and commercial ones I've had.
The Java port of the WP Office suite had reached a reasonable beta quality by the time they scrapped it. Public demos were available. It has a pretty broad feature set, and an interesting, somewhat StarOffice-like single-window user interface.
However, this being 1996 and Java being what it was back then, it was too slow to be useful on 95% of the hardware of the day. The level of polish, while not perfect, was very impressive considering that it was done with AWT, these being pre-Swing (and pre-JIT) days.
Since it needed insanely fast hardware (for the time) to run, the goal of deploying it on low-end networked computers wasn't realistic. Add to that the clear trend in the world of terminal computing toward very-thin clients (X, Citrix, Tarantella, etc.), and the reasons for making an office suite for Java-enabled diskless stations fall away. Corel put their thin-client energy, such as it was, into projects like the NetWinder and GraphOn's Citrix-like remote-display-server technology.
It wasn't a "rumor". It was a well-publicized project and a nifty proof-of-concept with working demos open to the public on their website.
The computing world wasn't ready (literally, from a hardware standpoint) for large-scale Java desktop apps at the time.. but Corel, incompetent though they may be, did manage to prove it could be done.
When someone's job involves accessing mainframe data on a terminal emulator and dashing off brief e-mails and faxes, you do not want that person to use a word processor in the course of their work. A word processor, with its font choices, advanced formatting tools and endless options is a huge productivity drain when it's used for short notes and memos, just as pick-and-pack staff in a warehouse shouldn't have a spreadhseet or presentation package available on shop-floor terminals, but the warehouse managers should.
Does this neatly counteract the argument that MS Office applications are necessary for complex, scripted integration (via Visual Basic)?
/. editor's course? I'm sure you're a swell coder/hardware geek/washroom attendant/whatever at BSI, dude, but the stories you post.. and the comments you make.. Heavens. ;]
Say what? That's quite a leap in logic. No, MS Office applications are still necessary for scripted integration compatbile with MS Office, though. Python's a nonstarter here. Corel WP Office now uses a language with VBA syntax (but not its object model) as its scripting language. StarOffice also has a VBA-clone language with its own object model, as well as the options to script in Javascript and from Java. Lotus and Vistasource/Applix each have their own scripting languages.
This means Corel and StarOffice users can leverage skills honed on MS Office without being able to reuse any macros directly.. and Lotus users can leverage Notes skills. What advantages Applix offers to people who have used office software for eludes me.
So no, you never needed MS Office to script and integrate office suites. You just need it to script and integrate with MS Office.
Will someone please enroll Tim in a remedial