As for losing their corporate market, I'm shocked to hear Sony ever had one. No real docking stations, crappy port replicators, structurally weak cases, little plastic doors that break off if you breathe on them, and hardware so fussy that the things lock up more than a Packard Bell.
We bought a few a year ago. One by one, they've died, broken, or become nearly unbootable. They look slick. The light ones are certainly light and seemingly inexpensive. VAIOs have some nifty features (FireWire, f'rinstance), but they don't belong on an IT department's equipment list in my experience.
If IBM made Thinkpads that looked like these new VAIOs, I'd be thrilled. Seen the new Thinkpads? There's design. Rigid construction and reinforced, rubberized hinges throughout, pass-through everything to the port replicator/dock, bright screens, and they're about as stable as a good desktop. Sure, they're black rectangles that look like every other Thinkpad of the last 5 years, but they paid attention to quality. They're also not cheap, but even if they cost twice as much as a VAIO, they're worth every penny.
If you're in charge of your company/organization's purchasing and someone wants a VAIO, either tell them to buy it for themselves, or buy two so you can have a loaner on hand when the first one breaks.
Yes, the Unix world has been filled with open-source software and free software as we know it for 15 years now. The internet, even in its academic pre-HTTP days, was built almost entirely out of open-source and Free software, though usually not free OSes.
And yeah, Linux was kicking around in a usable state for 3 years before RedHat debuted. And there were already commercial Linux distributions, too. But Red Hat was the first Linux--and Free Software--packager that was looking to do something other than make pizza money selling unsupported CD-ROMs (Slackware) or get consulting gigs (Yggdrasil). Redhat really did create the open-source business model out of thin air. Before them, your only choices for Linux support were Usenet and hiring a freelance consultant.
They didn't invent open source. Not by a long shot. But they did singlehandedly show everyone how to sell it into corporations and how to build a company around it.
It's a docking station. The deluxe kind with card slots. Most major laptop vendors have sold brand-specific ones for a couple of years now, and there are a few companies that make this sort of "universal" dock.
This not a PC. Not even sort of. Nor is it a new concept. Nor is it an especially cutting-edge version of anything. It's just a deluxe docking station with card slots. for people like you who buy consumer laptops like the Sonys only to figure out later that Sony doesn't make docking stations, just those dinky port replicators.
Rob, you really ought to peruse some product catalogs. You'd be amazed what they're making these days. Digital cameras! CD recorders! Floppy disks that store 120 megs! We live in miraculous times.
Hints for possible future stories:
Web browsers that can pre-fill forms for you!
Flat-panel monitors! Whoa!
Wild and crazy people who connect TRACKBALLS to their computers and use them like MICE!
Are you talking about those clamshell things with calculator-y keyboards exemplified by the Sharp Wizards, or are you talking about the Casio Zoomer?
The Zoomer was practical if you didn't mind pausing a second after each letter you wrote with Grafitti, and you didn't really care if syncing took ten minutes. I guess. I didn't say first PDA, which was pretty much Apple's, nor did I say the first PDA of the right size, which was the Zoomer and its slow, clumsy ilk.
The Zoomer didn't fail because of bad marketing. It was in every Radio Shack in North America displayed up front and given pride of place in the catalog. It failed because it was a deeply flawed product that did many things, none very well.
The Newton didn't fail because people were too primitive and stupid to understand its genius. The Newton failed because even when they got the speed and handwriting stuff right, they were still trying to sell the new models for $1100 USD and they were the size of a rack of barbecued ribs.
The Palm was the first PDA that had the right size (zero carry), the right price (under $400 from the start) and the right interface (simple and efficient). Consider this: it took Microsoft and its hardware partners three years and three product iterations after the Palm was introduced to figure this out and make a product that could grab more than 10% market share.
Steve Jobs would undoubtedly earn a spot in the top 5 in a list covering the 1970s or the 1980s. But in the 1990s?
Jobs turned Apple around, but Apple isn't really important to computing as a whole anymore, not with an 8% market share. They make nice, leading-edge machines, they have a nice UI, and they're swell at industrial design again, but with the exception of case design, Apple--and Steve Jobs--don't shape computing anymore.
Where's Jeff Hawkins? He's arguably the inventor of the first practical PDA. Just as Apple deserves enormous credit for making existing "outsider" technologies palatable in the '70s and '80s, Palm should get props for making the handheld computer into something for the masses back in '97.
"but I'm sure there are a lot of people who appreciate having a distro they can stick on some old SparcStation."
Which is precisely the reason they're dropping it. Of the small fraction of Sparc machines running Linux instead of Solaris or the ancient SunOS, I'd hazard a guess that most of those are old recycled hardware.
The open-source aspect of Linux is certainly nice given Sun's tendency to leave certain Solaris bugs unfixed year after year. But few people are going to buy new Sun equipment and reload it with an OS that makes mediocre use of the latest hardware.
No, I suspect Sparc Linux is what gets loaded on machines too old and underpowered to run the recent versions of Solaris well. Linux is a good way to get a modern, up-to-date *nix running on all those old 125 MHz Turbosparcs.
And if you're still updating 125 MHz Turbosparcs, you're probably not spending money on packaged OS media and support contracts.
For another thing, why run Linux on new Sun hardware? You're paying a premium for hardware that doesn't run optimally under Linux. Linux can't do SMP as well as Solaris, and you're giving up things like hot-swappable processor support and so forth. Next, you're using this fancy hardware to run what? Apache, MySQL and BIND? It would be nice to be able to run big, scary software like Oracle, DB2, Domino and WebSphere on that fast hardware, but none of those commercial apps are available for Sparc Linux.
Phooey. If you run Sparc Linux, you're unlikely to have been paying for support anyway. Why should RedHat pay people to build and tune Sparc versions of their distro? You're free to grab the RH7 sources and compile them yourself, or put together a team to do so, or switch to something like Debian, Mandrake or SuSE.
For an example of a low-demand OS's demise really disrupting things, consider OS/2's death, officially taking place in the summer of 2001. It may not be in wide use on desktops or even on network servers, but it's got a large market share in the voice-mail systems industry.
If you want to change kernels and drivers and core libraries, why do you have a Cobalt in the first place? A Cobalt has below-average hardware in a turnkey package for hosting or core workgroup services. Sure, you might add a database, some Apache modules, ssh and so forth. But why buy a Cobalt if you're going to forego their support and OS updates?
Crikeys, you'd still be able to install a compiler and so on. 95% of Cobalts are run vanilla. Now that they've been adding PHP, MySQL and ChiliASP to some models, that number will go to 99%.
I can think of a few dozen vendors you'd get a better hardware from at this price if you're looking to customize your software mix. The point of a Cobalt is that it's ready-to-run and can be patched and upgraded automatically to be identical with all other Cobalts.
Looks like NeoMedia, whose patents DC apparently licenses, patented the concept of using a barcode with attached tracking data as a means to fetch a pointer ot network data. In 1999 and 2000. I'll bet this comes as a surprise to every maker of networked barcode-enabled applications from the past 20 years.
Then again, some other yahoos seem to have a fresh patent on the very idea of a database mapping UPC codes to product-related URLs.
Time to patent my Method of Organizing a Sock Drawer. Black socks on the left, white socks on the right, colored and patterened socks in the middle. Who's reviewing these patent applications? A family of parakeets? A bag of gravel with a face painted on it?
Bonus points: NeoMedia's other three patents cover the "windowing" approach to solving the Y2k problem. So it sounds like NeoMedia specializes in buying up patents of the obvious that somehow slip through, and suing everyone in sight.
A barcode-to-web-lookup patent, especially if awarded in the last 15 years, would be especially nutty. Barcode scanners have been used to trigger data lookups across networks for as long as there have been barcodes. I find it hard to believe that shop-floor, factory and warehouse barcode readers weren't being used to pull up mainframe data 20-plus years ago. Must find this NeoMedia patent. Sounds on the face of it like yet another bit of galling ineptitude at the USPTO.
Hey! I have an idea! How about rigging, say, a modified finger daemon to hand out item URLs to scanning applications. Then the lookups wouldn't be done "on the web".
DSLreports.com is reliable in my experience. Extremely so.
Plenty of people will have perfectly smooth service from a "bad" provider and there will be people with bad service from a "good" one, but trust the overall vibe you get on a given provider on DSLreports. If it seems negative and gloomy, that's because it is. Welcome to DSL.
I'm not sure what your problem is. OK, USWest won't serve you, but DSLreports found providers that will. So find a decently-rated one and go with them. Or don't. Can't get the speed you want? You're probably too far away from the nearest central office equipped for DSL. Suck it up.
The thing with DSL is that fast DSL business service costs roughly 1/4 the price of a T1, and you'll likely find you have 4 times the number and duration of outages. You get what you pay for. If reliability isn't critical and you can deal with the occasional 4-10 hours of downtime every other month, you'll be okay.
As for residential DSL, you may be wondering why fast residential DSL costs 1/4 what the slowest business DSL costs. The answer, as I've learned from experience, is again reliability. Once again, do the math. Assume 4 times the number and severity of outages that you'd get with comparable business DSL. I assume this is because a customer paying 6 times as much gets 6 times the engineering resources devoted to it.
My Verizon (née BellAtlantic) residential service is down an average of 2 days a month. In the last month, I've had a 4-day outage and a 2-day outage as well as countless disconnects (actually, I could look at my logs and count them, but I don't feel like it).
Sounds bad, right? But here's the kicker. Though I'm switching my (small but growing) company from DSL to a T1, I have no desire to switch to a cable modem at home, which brings a whole different set of issues. I'm sticking with DSL until something genuinely better comes along. Now I just need to switch out of Verizon.
Nay, DC is right to worry about 3rd-party drivers
on
CueCat At It Again
·
· Score: 2
3rd-party Cuecat drivers for Linux pose no serious threat to DC's business model. Even if every Linux desktop user got a Cuecat, it wouldn be a drop in the bucket compared to their Windows audience.
No, the problem is what happens when alternative drivers show up in the Windows shareware and commercial worlds. Already, the $40 shareware package Readerware has added CueCat support. If DC loses this battle, as they should if anyone hopes to continue using a screwdriver or a butter knife to open paint cans, everybody will support it. Real Jukebox and Windows Media Player will allow you to catalog CDs without inserting them into a drive. Grocery shopping sites will let you scan items you want to reorder. Companies in the e-coupon business will latch onto it, all bypassing Digital Convergence.
If DC didn't want this to happen, they should have either made a smart scanner with public-key encryption built in, or they should have required a signed contract from consumers prior to giving it to them. Both of which, of course, are expensive and ruin their business model just as surely as these drivers that took someone a half hour to write in a clean-room manner.
What's wrong with selling pet food online?
on
CueCat At It Again
·
· Score: 2
You may not be interested in buying pet food online, but if you don't have a car and have several pets, or, say, a very big dog, you may like the convenience of having pet food delivered to your home, for example. And what if you do your grocery shopping at small specialty stores and you don't want to have to make an extra stop just to buy pet food?
No, selling pet food online is a reasonably good idea if you're realistic about your real market and have a good order processing and fulfillment operation in place.
Digital Convergence, on the other hand, took cheap, essentially unencrypted barcode readers that spit out transparent data as transposed ASCII to a keyboard port, and expected to use them in a business predicated on controlling all use of the scanner's output.
Doing so is not all that difficult--if you diustribute "smart" barcode scanners that only work through, say, a public/private keypair encryption scheme in which the scanner needs to be fed a site's key and then spits out data only that site can decrypt.
But that hardware would have cost money, which may be why no other company has tried giving away barcode scanners en masse prior to this in the 20-year history of cheap barcode wands. It boggles the mind that in the four years this was in the works, no engineer, no product development person, no lawyer and no investor saw the hangar-sized hole in the business plan.
I know this was meant as a joke, but reality is already way ahead of you.
You can get a Minstrel/Omnisky for a current-model Palm and use VNC to remotely-control X and Windows desktops. It's been doable for more than a year now. Granted, since the Minstrel is slow, it would be slow as all hell, but it would work. Snap something faster onto the Palm/Visor's RS-232 port, and it becomes less slow. Though panning around on a 160x160 screen may not be your idea of fun.
On the other hand, the SSH and TN5250 emulators I've used to connect to AS/400s wirelessly with a Palm work like a charm.
VA competes with Cobalt? How so?
on
Sun Buys Cobalt
·
· Score: 4
Cobalt isn't in the same business. Cobalt makes preconfigured, browser-managed server appliances for vertical markets, with a focus on easy deployment and easy, GUI-based management.
VA makes high-performance general-purpose servers with nothing but a raw OS installed on them.
You might as well say eMachines and SGI are competitors because they both make desktops that run Windows.
Er, no. They merged the products.
on
Sun Buys Cobalt
·
· Score: 2
Uh, that's funny. The way I remember it, Kiva/Netscape's app server, also acquired by Sun, had the more advanced and scalable backend but no good tools to speak of, and NetDynamics had the better development tools and a somewhat anemic and behind-the-curve backend.
The current iPlanet product is essentially a successor to the Kiva/Netscape engine with tools based on NetDynamics, though now most heavy coding can be donw ith your choice of Java IDE. And they provided migration tools and support assistance to customers moving to the merged product.
The hell with VNC. Assuming this web server is running Linux or Unix, You shouldn't be running X full time on your web servers anyway. It's a big resource drain and a yet another thing you have to worry about security on.
If the server can still be logged into remotely, go with telnet or if you give a damn about security, SSH. There are Palm clients for both that will work over a modem or a woreless gizmo like a Minstrel/Omnisky.
If you're talking about rebooting it when it's frozen solid, no application on your server is going to help with that, since your Palm ain't going to be able to connect to it. At that point, you're talking about solutions involving hardware that triggers a reboot through a special hardware interface or power-cycles the machine. Check the manuals for your server hardware or UPS to see if you have this capability.
If you have such a means of restarting it, the next step is to build an interface to it that you can get at remotely. If you can't get SSH access to a command line on the machine that does the rebooting, a protected web interface that executes the apprporiate remote-reboot command might be an okay way to go. Once you've got that, something like a Palm PQA to prompt for your password and trip the URL should be enough.
This isn't a hardware buy. It's a software buy.
on
Sun Buys Cobalt
·
· Score: 5
Sun already makes low-end 1U servers. This isn't about buying Cobalt's mediocre hardware like faulty serial consoles, power supply issues, and slow IDE drives. It's about software.
Cobalt makes plug-and-go server appliances. Although you can telnet/SSH into a Cobalt and you can install your own software on them, that's not their selling point. The selling point is that they're web-hosting/email/caching/etc. appliances that can be set up in about ten minutes and managed both by admins and customers almost entirely through slick web interfaces.
This is why ISPs and hosting providers love Cobalt. For instance, the latest Raq models come preconfigured to run as hosting servers for Apache with MySQL, PHP, ASP (thanks to their Chilisoft acquisition), POP and IMAP mail, FTP, log reporting and so forth. With 24/7 phone support for the whole shebang available. And at a price not much different from a vanilla 1U server, that makes them a bargain if you're a hosting provider.
They have competitors, none of whom have gotten it right. Plain servers aren't really competition at all. The Whistler InterJet competes with the Qubes, but it's too rigid and locked down. The Netwinders suffer from awful marketing and a so-so web inetrface.
Cobalt is a brand ISPs trust, and small development shops that build sites on hosted space like the consistency across Cobalt-based hosting providers.
I expect you'll see Sun continue to sell $1200 x86-based, single-processor Raqs and start offering higher-end machines with SCSI and fiber channel, multiple processors, redundancy and so forth, all with Cobalt's well-thought-out browser-based administration rolled in for customers that prefer a few large machines for hosting over racks full of small ones.
And owning ChiliASP can't hurt the iPlanet server line. That's the Cobalt-owned, complete, COM-aware, VBScript and JScript-running Active Server Pages environment for Unix and Linux. Don't be surprised if you see that engine's backend translated into Java and made available on the iPlanet Application Server, for a massively-scalable way to run existing ASP-based applications alongside JSP/servlet/EJB apps.
The CueCat is the product of what might just be the dumbest startup ever. I'm not sure who's going to be made to suffer for the error: the engineers or the investors.
The thing spits out whatever barcode it reads, massaged for easy merging into a URL by a logical XOR on the number 67 followed by a pass of Base64 encoding, not unlike what happens when you attach a file to e-mail. In nontechnical terms, this is "encryption" weaker than passing something through a Flash Gordon decoder ring, then passing the result through a Lone Ranger decoder ring.
The "intellectual property" Digital Convergence is trying to protect can be expressed in 3 lines of very basic Perl or a flowchart sketched inside a matchbook. I wish them luck.
As a result, I've seen a quickie book database someone slapped together: it grabs the ISBN and fetches book info from Amazon. Anonymously. Without having to pass a thing to Digital Convergence, makers of the scanner, and without passing a cookie or any other form of ID to Amazon. I've never been consumed with an urge to catalog my books or CDs on my computer, but the CueCat makes it surprisingly convenient. It took me about ten minutes to feed in about 60 books. The ones without barcodes are still a problem, but this certainly takes much of the bite out of the process. Nearly all CDs, on the other hand, have barcodes.
Another little perl script floating around lets you scan anything the Digital Convergence folks have catalogued on their servers groceries, radio shack catalog items, magazine articles) and jump to the product's site or web page.. again without passing so much as a user ID or cookie to them. The servers are wide open and will return the product URL for a given barcode regardless of whether or not you're a registered, cookied user of their official software. Whoops!
Since it's easy to distinguish between the barcodes on books, CDs and grocery items, the same three lines of perl could be used as the basis for a five-line program to put products in a shopping cart on your favorite web grocery store, again without involving the CueCat folks.
You'd think in the four years this was in development someone would have wondered why no other company had ever tried to build a tight marketing database around cheap barcode scanners given away at a loss.
It's not because it hasn't occurred to thousands of entrepreneurs since cheap barcode wands first appeared 15 or so years ago. It's because until the dunderheads behind the CueCat came along, all the other peopole who had the same dream realized that even a kinda-sorta lockable barcode scanner would cost too much to give away for free. And then with that Big Idea out of the way they went and did something productive, like wash some dishes or eat a Popsicle.
So simple, so early-80s is the CueCat's design that those Linux drivers probably took someone half an hour to write while watching TV and feeding the dog. Especially given the dozen or so little shell scripts and perl programs that have since popped up, all of them ramshackle "baby's first program"-caliber triumphs. I can't wait to see what online music, grocery and book stores do with this.
If any license agreement short of requiring a signature before receiving a security-free scanner like this holds up in court, it would open the way for hand-tool makers to require people to buy separate "screwdrivers" and "paint-can openers".
RPM packages can't be configured interactively. They won't ask you if you want to keep the current version of a configuration file, install a new version, or compare the two versions. They won't stop services before updating and restart them afterwards. The MTA won't ask you a few questions and configure itself. They won't even issue a warning to the administrator. We need to walk one more step to have it work properly.
...it would be a valuable addition to RPM to provide some mechanism to configure all unpacked but unconfigured packages. Pre- and post-install scripts, as well as pre- and post-removal scripts, should be executed appropriately to allow smooth upgrading of running services. Package maintainers would have to add such scripts to their packages and make sure they'll not break the system the package is being installed on, keeping in mind the diversity of RPM-based distributions out there. Auditing, predependencies, package flags, and auto-deconfiguration functionality must be implemented.
This doesn't sound like someone acquainted with RPM's script-calling features to me.
RPM's got its flaws--in particular the bloat of its cross-dependency database once a system's gone through a few big waves up upgrades. But Mr. Matsuoka--and Mr. Covey--show themselves to be surprisingly ignorant of RPM's capabilities.
What set off little bells in my head was his contention that RPM can only update files and doesn't run pre- and post-install scripts and can't prompt users for parameters and install options for the packages in question.
This is just plain wrong. An RPM can contain and run both pre- and post- scripts both during install and uninstall operations. Plenty of RPM packages containing shared libraries, for example, silently run an ldconfig after installation. RPMs of things like mysql and postgres often do a lot more--initializing a database, setting up default db users and, yes, prompting for things. If his SMTP MTA packages don't prompt for anything, that's the packager's fault. Hopefully Mr. Matsuoka's job at Connectiva isn't as lead packager for their distro.
It would be nice to see both apt and RPM adopt a rich XML-based standard for expressing prompts, defaults and so forth for interactive installers, along with a way to express what prompts can be silenced and with what effect, so that text, widget-independent GUI, and web-based (among others) interfaces to interactive installation can be built without breaking anything. But this wasn't Mr. Matsuoka's complaint. He seems to think RPM's can't be made to prompt users or execute scripts.
As for Mr. Matsuoka's other contention, that RPM needs changes in order to allow smooth auto-updating of packages, this too shows inexperience. I'm sure users of, say, Helix-Update, RedHat's Priority Update tool, and for that matter the fully-automated silent autoRPM utility would be surprised to hear RPM lacks such functionality. That he doesn't know this is kind-of-sort-of excusable, since it's not covered in the books and documentation for RPM. Not so the pre/post install script stuff. That's in the docs.
As y'all go around moderating up all sorts of conspiracy theories and wacky schemes and bad ideas (like declaring zero value on a $300 package), this person is right and gets marked as flamebait.
Yes, folks, here in the real world there are sometimes correct answers. In response to rampant theft and corruption, most parcel-delivery companies either charge insane rates (DHL) or simply refuse to deliver to all but the most accessible, modern Russian cities (FedEx, etc.). In response to this, thousands of small courier companies have sprung up. They operate out of storefronts in immigrant neighborhoods. They advertise in emigre newspapers and on the web. They rent container space on ships and hire local delivery people. They send small, urgent packages with couriers. They get stuff delivered. Usually with 95% of DHL's reliability at half DHL's price.
This isn't a coding challenge with points awarded for the cleverest theoretical solution. It's a simple question of how to get a parcel sent reasonably safely and resonably frugally to East Podunk, Russia (or Paraguay, or rural Vietnam, or Sierra Leone, or Uzbekistan, for that matter). And the way most private citizens do it is through these small delivery companies.
Give the/. community any topic, even a nontechnical one like this, and hundreds of people who don't know a damn thing about it will spout off all sorts of bilge, apparently. Heaven forbid anyone here acknowledge that they simply don't know.
You know, this kind of slapdash, misinformed crap was cute back when The Management here was a bunch of college undergrads running a rumors and argument site out of their rickety group house.
But now that most of you have graduated and are running this as a business, 5 minutes or so of cursory fact-checking might be in order before posting a "story" like this.
Hmmm. Too lazy to check facts. Eager to post inflammatory hearsay. Blind ignorance about some basic technology issues. Isn't that what the Ziff-Davises and CMPs are for? If it were just this once, it wouldn't be a big deal, but this kind of wild inaccuracy now accounts for one in four of the items that make the cut here.
And Rob! You of all people! I expect barn-door-sized editorial gaffes like this from, say Timothy. But you?
At the time AOL bought Mirabilis, ICQ had frequent system outages and lags, dropped connections, a website that was usually swamped and inaccessible during North American daytime hours, and a user search function that usually didn't work.
They were having some serious growing pains. They had also had a couple of rounds of financing to get them as far as they got. But I remember ICQ itself being very pokey in the months leading up to the sale, and its website being all but unusable.
Slashdot Mirror
Looks swell to me. Very 1982.
As for losing their corporate market, I'm shocked to hear Sony ever had one. No real docking stations, crappy port replicators, structurally weak cases, little plastic doors that break off if you breathe on them, and hardware so fussy that the things lock up more than a Packard Bell.
We bought a few a year ago. One by one, they've died, broken, or become nearly unbootable. They look slick. The light ones are certainly light and seemingly inexpensive. VAIOs have some nifty features (FireWire, f'rinstance), but they don't belong on an IT department's equipment list in my experience.
If IBM made Thinkpads that looked like these new VAIOs, I'd be thrilled. Seen the new Thinkpads? There's design. Rigid construction and reinforced, rubberized hinges throughout, pass-through everything to the port replicator/dock, bright screens, and they're about as stable as a good desktop. Sure, they're black rectangles that look like every other Thinkpad of the last 5 years, but they paid attention to quality. They're also not cheap, but even if they cost twice as much as a VAIO, they're worth every penny.
If you're in charge of your company/organization's purchasing and someone wants a VAIO, either tell them to buy it for themselves, or buy two so you can have a loaner on hand when the first one breaks.
Not bad, if you don't mind keeping just a single backup and don't feel like keeping the last set offsite in case of fire/theft/etc.
Yes, the Unix world has been filled with open-source software and free software as we know it for 15 years now. The internet, even in its academic pre-HTTP days, was built almost entirely out of open-source and Free software, though usually not free OSes.
And yeah, Linux was kicking around in a usable state for 3 years before RedHat debuted. And there were already commercial Linux distributions, too. But Red Hat was the first Linux--and Free Software--packager that was looking to do something other than make pizza money selling unsupported CD-ROMs (Slackware) or get consulting gigs (Yggdrasil). Redhat really did create the open-source business model out of thin air. Before them, your only choices for Linux support were Usenet and hiring a freelance consultant.
They didn't invent open source. Not by a long shot. But they did singlehandedly show everyone how to sell it into corporations and how to build a company around it.
This not a PC. Not even sort of. Nor is it a new concept. Nor is it an especially cutting-edge version of anything. It's just a deluxe docking station with card slots. for people like you who buy consumer laptops like the Sonys only to figure out later that Sony doesn't make docking stations, just those dinky port replicators.
Rob, you really ought to peruse some product catalogs. You'd be amazed what they're making these days. Digital cameras! CD recorders! Floppy disks that store 120 megs! We live in miraculous times.
Hints for possible future stories:
Are you talking about those clamshell things with calculator-y keyboards exemplified by the Sharp Wizards, or are you talking about the Casio Zoomer?
The Zoomer was practical if you didn't mind pausing a second after each letter you wrote with Grafitti, and you didn't really care if syncing took ten minutes. I guess. I didn't say first PDA, which was pretty much Apple's, nor did I say the first PDA of the right size, which was the Zoomer and its slow, clumsy ilk.
The Zoomer didn't fail because of bad marketing. It was in every Radio Shack in North America displayed up front and given pride of place in the catalog. It failed because it was a deeply flawed product that did many things, none very well.
The Newton didn't fail because people were too primitive and stupid to understand its genius. The Newton failed because even when they got the speed and handwriting stuff right, they were still trying to sell the new models for $1100 USD and they were the size of a rack of barbecued ribs.
The Palm was the first PDA that had the right size (zero carry), the right price (under $400 from the start) and the right interface (simple and efficient). Consider this: it took Microsoft and its hardware partners three years and three product iterations after the Palm was introduced to figure this out and make a product that could grab more than 10% market share.
Steve Jobs would undoubtedly earn a spot in the top 5 in a list covering the 1970s or the 1980s. But in the 1990s?
Jobs turned Apple around, but Apple isn't really important to computing as a whole anymore, not with an 8% market share. They make nice, leading-edge machines, they have a nice UI, and they're swell at industrial design again, but with the exception of case design, Apple--and Steve Jobs--don't shape computing anymore.
Where's Jeff Hawkins? He's arguably the inventor of the first practical PDA. Just as Apple deserves enormous credit for making existing "outsider" technologies palatable in the '70s and '80s, Palm should get props for making the handheld computer into something for the masses back in '97.
"but I'm sure there are a lot of people who appreciate having a distro they can stick on some old SparcStation."
Which is precisely the reason they're dropping it. Of the small fraction of Sparc machines running Linux instead of Solaris or the ancient SunOS, I'd hazard a guess that most of those are old recycled hardware.
The open-source aspect of Linux is certainly nice given Sun's tendency to leave certain Solaris bugs unfixed year after year. But few people are going to buy new Sun equipment and reload it with an OS that makes mediocre use of the latest hardware.
No, I suspect Sparc Linux is what gets loaded on machines too old and underpowered to run the recent versions of Solaris well. Linux is a good way to get a modern, up-to-date *nix running on all those old 125 MHz Turbosparcs.
And if you're still updating 125 MHz Turbosparcs, you're probably not spending money on packaged OS media and support contracts.
For another thing, why run Linux on new Sun hardware? You're paying a premium for hardware that doesn't run optimally under Linux. Linux can't do SMP as well as Solaris, and you're giving up things like hot-swappable processor support and so forth. Next, you're using this fancy hardware to run what? Apache, MySQL and BIND? It would be nice to be able to run big, scary software like Oracle, DB2, Domino and WebSphere on that fast hardware, but none of those commercial apps are available for Sparc Linux.
Phooey. If you run Sparc Linux, you're unlikely to have been paying for support anyway. Why should RedHat pay people to build and tune Sparc versions of their distro? You're free to grab the RH7 sources and compile them yourself, or put together a team to do so, or switch to something like Debian, Mandrake or SuSE.
For an example of a low-demand OS's demise really disrupting things, consider OS/2's death, officially taking place in the summer of 2001. It may not be in wide use on desktops or even on network servers, but it's got a large market share in the voice-mail systems industry.
If you want to change kernels and drivers and core libraries, why do you have a Cobalt in the first place? A Cobalt has below-average hardware in a turnkey package for hosting or core workgroup services. Sure, you might add a database, some Apache modules, ssh and so forth. But why buy a Cobalt if you're going to forego their support and OS updates?
Crikeys, you'd still be able to install a compiler and so on. 95% of Cobalts are run vanilla. Now that they've been adding PHP, MySQL and ChiliASP to some models, that number will go to 99%.
I can think of a few dozen vendors you'd get a better hardware from at this price if you're looking to customize your software mix. The point of a Cobalt is that it's ready-to-run and can be patched and upgraded automatically to be identical with all other Cobalts.
Then again, some other yahoos seem to have a fresh patent on the very idea of a database mapping UPC codes to product-related URLs.
Time to patent my Method of Organizing a Sock Drawer. Black socks on the left, white socks on the right, colored and patterened socks in the middle. Who's reviewing these patent applications? A family of parakeets? A bag of gravel with a face painted on it?
- US05933829
- US05978773
- US06108656
Bonus points: NeoMedia's other three patents cover the "windowing" approach to solving the Y2k problem. So it sounds like NeoMedia specializes in buying up patents of the obvious that somehow slip through, and suing everyone in sight.A barcode-to-web-lookup patent, especially if awarded in the last 15 years, would be especially nutty. Barcode scanners have been used to trigger data lookups across networks for as long as there have been barcodes. I find it hard to believe that shop-floor, factory and warehouse barcode readers weren't being used to pull up mainframe data 20-plus years ago. Must find this NeoMedia patent. Sounds on the face of it like yet another bit of galling ineptitude at the USPTO.
Hey! I have an idea! How about rigging, say, a modified finger daemon to hand out item URLs to scanning applications. Then the lookups wouldn't be done "on the web".
DSLreports.com is reliable in my experience. Extremely so.
Plenty of people will have perfectly smooth service from a "bad" provider and there will be people with bad service from a "good" one, but trust the overall vibe you get on a given provider on DSLreports. If it seems negative and gloomy, that's because it is. Welcome to DSL.
I'm not sure what your problem is. OK, USWest won't serve you, but DSLreports found providers that will. So find a decently-rated one and go with them. Or don't. Can't get the speed you want? You're probably too far away from the nearest central office equipped for DSL. Suck it up.
The thing with DSL is that fast DSL business service costs roughly 1/4 the price of a T1, and you'll likely find you have 4 times the number and duration of outages. You get what you pay for. If reliability isn't critical and you can deal with the occasional 4-10 hours of downtime every other month, you'll be okay.
As for residential DSL, you may be wondering why fast residential DSL costs 1/4 what the slowest business DSL costs. The answer, as I've learned from experience, is again reliability. Once again, do the math. Assume 4 times the number and severity of outages that you'd get with comparable business DSL. I assume this is because a customer paying 6 times as much gets 6 times the engineering resources devoted to it.
My Verizon (née BellAtlantic) residential service is down an average of 2 days a month. In the last month, I've had a 4-day outage and a 2-day outage as well as countless disconnects (actually, I could look at my logs and count them, but I don't feel like it).
Sounds bad, right? But here's the kicker. Though I'm switching my (small but growing) company from DSL to a T1, I have no desire to switch to a cable modem at home, which brings a whole different set of issues. I'm sticking with DSL until something genuinely better comes along. Now I just need to switch out of Verizon.
3rd-party Cuecat drivers for Linux pose no serious threat to DC's business model. Even if every Linux desktop user got a Cuecat, it wouldn be a drop in the bucket compared to their Windows audience.
No, the problem is what happens when alternative drivers show up in the Windows shareware and commercial worlds. Already, the $40 shareware package Readerware has added CueCat support. If DC loses this battle, as they should if anyone hopes to continue using a screwdriver or a butter knife to open paint cans, everybody will support it. Real Jukebox and Windows Media Player will allow you to catalog CDs without inserting them into a drive. Grocery shopping sites will let you scan items you want to reorder. Companies in the e-coupon business will latch onto it, all bypassing Digital Convergence.
If DC didn't want this to happen, they should have either made a smart scanner with public-key encryption built in, or they should have required a signed contract from consumers prior to giving it to them. Both of which, of course, are expensive and ruin their business model just as surely as these drivers that took someone a half hour to write in a clean-room manner.
You may not be interested in buying pet food online, but if you don't have a car and have several pets, or, say, a very big dog, you may like the convenience of having pet food delivered to your home, for example. And what if you do your grocery shopping at small specialty stores and you don't want to have to make an extra stop just to buy pet food?
No, selling pet food online is a reasonably good idea if you're realistic about your real market and have a good order processing and fulfillment operation in place.
Digital Convergence, on the other hand, took cheap, essentially unencrypted barcode readers that spit out transparent data as transposed ASCII to a keyboard port, and expected to use them in a business predicated on controlling all use of the scanner's output.
Doing so is not all that difficult--if you diustribute "smart" barcode scanners that only work through, say, a public/private keypair encryption scheme in which the scanner needs to be fed a site's key and then spits out data only that site can decrypt.
But that hardware would have cost money, which may be why no other company has tried giving away barcode scanners en masse prior to this in the 20-year history of cheap barcode wands. It boggles the mind that in the four years this was in the works, no engineer, no product development person, no lawyer and no investor saw the hangar-sized hole in the business plan.
I know this was meant as a joke, but reality is already way ahead of you.
You can get a Minstrel/Omnisky for a current-model Palm and use VNC to remotely-control X and Windows desktops. It's been doable for more than a year now. Granted, since the Minstrel is slow, it would be slow as all hell, but it would work. Snap something faster onto the Palm/Visor's RS-232 port, and it becomes less slow. Though panning around on a 160x160 screen may not be your idea of fun.
On the other hand, the SSH and TN5250 emulators I've used to connect to AS/400s wirelessly with a Palm work like a charm.
Cobalt isn't in the same business. Cobalt makes preconfigured, browser-managed server appliances for vertical markets, with a focus on easy deployment and easy, GUI-based management.
VA makes high-performance general-purpose servers with nothing but a raw OS installed on them.
You might as well say eMachines and SGI are competitors because they both make desktops that run Windows.
Uh, that's funny. The way I remember it, Kiva/Netscape's app server, also acquired by Sun, had the more advanced and scalable backend but no good tools to speak of, and NetDynamics had the better development tools and a somewhat anemic and behind-the-curve backend.
The current iPlanet product is essentially a successor to the Kiva/Netscape engine with tools based on NetDynamics, though now most heavy coding can be donw ith your choice of Java IDE. And they provided migration tools and support assistance to customers moving to the merged product.
But I guess conspiracy theories are more fun.
The hell with VNC. Assuming this web server is running Linux or Unix, You shouldn't be running X full time on your web servers anyway. It's a big resource drain and a yet another thing you have to worry about security on.
If the server can still be logged into remotely, go with telnet or if you give a damn about security, SSH. There are Palm clients for both that will work over a modem or a woreless gizmo like a Minstrel/Omnisky.
If you're talking about rebooting it when it's frozen solid, no application on your server is going to help with that, since your Palm ain't going to be able to connect to it. At that point, you're talking about solutions involving hardware that triggers a reboot through a special hardware interface or power-cycles the machine. Check the manuals for your server hardware or UPS to see if you have this capability.
If you have such a means of restarting it, the next step is to build an interface to it that you can get at remotely. If you can't get SSH access to a command line on the machine that does the rebooting, a protected web interface that executes the apprporiate remote-reboot command might be an okay way to go. Once you've got that, something like a Palm PQA to prompt for your password and trip the URL should be enough.
Sun already makes low-end 1U servers. This isn't about buying Cobalt's mediocre hardware like faulty serial consoles, power supply issues, and slow IDE drives. It's about software.
Cobalt makes plug-and-go server appliances. Although you can telnet/SSH into a Cobalt and you can install your own software on them, that's not their selling point. The selling point is that they're web-hosting/email/caching/etc. appliances that can be set up in about ten minutes and managed both by admins and customers almost entirely through slick web interfaces.
This is why ISPs and hosting providers love Cobalt. For instance, the latest Raq models come preconfigured to run as hosting servers for Apache with MySQL, PHP, ASP (thanks to their Chilisoft acquisition), POP and IMAP mail, FTP, log reporting and so forth. With 24/7 phone support for the whole shebang available. And at a price not much different from a vanilla 1U server, that makes them a bargain if you're a hosting provider.
They have competitors, none of whom have gotten it right. Plain servers aren't really competition at all. The Whistler InterJet competes with the Qubes, but it's too rigid and locked down. The Netwinders suffer from awful marketing and a so-so web inetrface.
Cobalt is a brand ISPs trust, and small development shops that build sites on hosted space like the consistency across Cobalt-based hosting providers.
I expect you'll see Sun continue to sell $1200 x86-based, single-processor Raqs and start offering higher-end machines with SCSI and fiber channel, multiple processors, redundancy and so forth, all with Cobalt's well-thought-out browser-based administration rolled in for customers that prefer a few large machines for hosting over racks full of small ones.
And owning ChiliASP can't hurt the iPlanet server line. That's the Cobalt-owned, complete, COM-aware, VBScript and JScript-running Active Server Pages environment for Unix and Linux. Don't be surprised if you see that engine's backend translated into Java and made available on the iPlanet Application Server, for a massively-scalable way to run existing ASP-based applications alongside JSP/servlet/EJB apps.
The CueCat is the product of what might just be the dumbest startup ever. I'm not sure who's going to be made to suffer for the error: the engineers or the investors.
The thing spits out whatever barcode it reads, massaged for easy merging into a URL by a logical XOR on the number 67 followed by a pass of Base64 encoding, not unlike what happens when you attach a file to e-mail. In nontechnical terms, this is "encryption" weaker than passing something through a Flash Gordon decoder ring, then passing the result through a Lone Ranger decoder ring.
The "intellectual property" Digital Convergence is trying to protect can be expressed in 3 lines of very basic Perl or a flowchart sketched inside a matchbook. I wish them luck.
As a result, I've seen a quickie book database someone slapped together: it grabs the ISBN and fetches book info from Amazon. Anonymously. Without having to pass a thing to Digital Convergence, makers of the scanner, and without passing a cookie or any other form of ID to Amazon. I've never been consumed with an urge to catalog my books or CDs on my computer, but the CueCat makes it surprisingly convenient. It took me about ten minutes to feed in about 60 books. The ones without barcodes are still a problem, but this certainly takes much of the bite out of the process. Nearly all CDs, on the other hand, have barcodes.
Another little perl script floating around lets you scan anything the Digital Convergence folks have catalogued on their servers groceries, radio shack catalog items, magazine articles) and jump to the product's site or web page.. again without passing so much as a user ID or cookie to them. The servers are wide open and will return the product URL for a given barcode regardless of whether or not you're a registered, cookied user of their official software. Whoops!
Since it's easy to distinguish between the barcodes on books, CDs and grocery items, the same three lines of perl could be used as the basis for a five-line program to put products in a shopping cart on your favorite web grocery store, again without involving the CueCat folks.
You'd think in the four years this was in development someone would have wondered why no other company had ever tried to build a tight marketing database around cheap barcode scanners given away at a loss.
It's not because it hasn't occurred to thousands of entrepreneurs since cheap barcode wands first appeared 15 or so years ago. It's because until the dunderheads behind the CueCat came along, all the other peopole who had the same dream realized that even a kinda-sorta lockable barcode scanner would cost too much to give away for free. And then with that Big Idea out of the way they went and did something productive, like wash some dishes or eat a Popsicle.
So simple, so early-80s is the CueCat's design that those Linux drivers probably took someone half an hour to write while watching TV and feeding the dog. Especially given the dozen or so little shell scripts and perl programs that have since popped up, all of them ramshackle "baby's first program"-caliber triumphs. I can't wait to see what online music, grocery and book stores do with this.
If any license agreement short of requiring a signature before receiving a security-free scanner like this holds up in court, it would open the way for hand-tool makers to require people to buy separate "screwdrivers" and "paint-can openers".
I wonder if Digital Convergence is publicly held.
From the Freshmeat editorial:
...it would be a valuable addition to RPM to provide some mechanism to configure all unpacked but unconfigured packages. Pre- and post-install scripts, as well as pre- and post-removal scripts, should be executed appropriately to allow smooth upgrading of running services. Package maintainers would have to add such scripts to their packages and make sure they'll not break the system the package is being installed on, keeping in mind the diversity of RPM-based distributions out there. Auditing, predependencies, package flags, and auto-deconfiguration functionality must be implemented.
RPM packages can't be configured interactively. They won't ask you if you want to keep the current version of a configuration file, install a new version, or compare the two versions. They won't stop services before updating and restart them afterwards. The MTA won't ask you a few questions and configure itself. They won't even issue a warning to the administrator. We need to walk one more step to have it work properly.
This doesn't sound like someone acquainted with RPM's script-calling features to me.
To uninstall a package, you give the name of the package, not the name of the file that it was installed from. In other words:
rpm -e Mesa
RPM's got its flaws--in particular the bloat of its cross-dependency database once a system's gone through a few big waves up upgrades. But Mr. Matsuoka--and Mr. Covey--show themselves to be surprisingly ignorant of RPM's capabilities.
What set off little bells in my head was his contention that RPM can only update files and doesn't run pre- and post-install scripts and can't prompt users for parameters and install options for the packages in question.
This is just plain wrong. An RPM can contain and run both pre- and post- scripts both during install and uninstall operations. Plenty of RPM packages containing shared libraries, for example, silently run an ldconfig after installation. RPMs of things like mysql and postgres often do a lot more--initializing a database, setting up default db users and, yes, prompting for things. If his SMTP MTA packages don't prompt for anything, that's the packager's fault. Hopefully Mr. Matsuoka's job at Connectiva isn't as lead packager for their distro.
It would be nice to see both apt and RPM adopt a rich XML-based standard for expressing prompts, defaults and so forth for interactive installers, along with a way to express what prompts can be silenced and with what effect, so that text, widget-independent GUI, and web-based (among others) interfaces to interactive installation can be built without breaking anything. But this wasn't Mr. Matsuoka's complaint. He seems to think RPM's can't be made to prompt users or execute scripts.
As for Mr. Matsuoka's other contention, that RPM needs changes in order to allow smooth auto-updating of packages, this too shows inexperience. I'm sure users of, say, Helix-Update, RedHat's Priority Update tool, and for that matter the fully-automated silent autoRPM utility would be surprised to hear RPM lacks such functionality. That he doesn't know this is kind-of-sort-of excusable, since it's not covered in the books and documentation for RPM. Not so the pre/post install script stuff. That's in the docs.
As y'all go around moderating up all sorts of conspiracy theories and wacky schemes and bad ideas (like declaring zero value on a $300 package), this person is right and gets marked as flamebait.
/. community any topic, even a nontechnical one like this, and hundreds of people who don't know a damn thing about it will spout off all sorts of bilge, apparently. Heaven forbid anyone here acknowledge that they simply don't know.
Yes, folks, here in the real world there are sometimes correct answers. In response to rampant theft and corruption, most parcel-delivery companies either charge insane rates (DHL) or simply refuse to deliver to all but the most accessible, modern Russian cities (FedEx, etc.). In response to this, thousands of small courier companies have sprung up. They operate out of storefronts in immigrant neighborhoods. They advertise in emigre newspapers and on the web. They rent container space on ships and hire local delivery people. They send small, urgent packages with couriers. They get stuff delivered. Usually with 95% of DHL's reliability at half DHL's price.
This isn't a coding challenge with points awarded for the cleverest theoretical solution. It's a simple question of how to get a parcel sent reasonably safely and resonably frugally to East Podunk, Russia (or Paraguay, or rural Vietnam, or Sierra Leone, or Uzbekistan, for that matter). And the way most private citizens do it is through these small delivery companies.
Give the
You know, this kind of slapdash, misinformed crap was cute back when The Management here was a bunch of college undergrads running a rumors and argument site out of their rickety group house.
But now that most of you have graduated and are running this as a business, 5 minutes or so of cursory fact-checking might be in order before posting a "story" like this.
Hmmm. Too lazy to check facts. Eager to post inflammatory hearsay. Blind ignorance about some basic technology issues. Isn't that what the Ziff-Davises and CMPs are for? If it were just this once, it wouldn't be a big deal, but this kind of wild inaccuracy now accounts for one in four of the items that make the cut here.
And Rob! You of all people! I expect barn-door-sized editorial gaffes like this from, say Timothy. But you?
At the time AOL bought Mirabilis, ICQ had frequent system outages and lags, dropped connections, a website that was usually swamped and inaccessible during North American daytime hours, and a user search function that usually didn't work.
They were having some serious growing pains. They had also had a couple of rounds of financing to get them as far as they got. But I remember ICQ itself being very pokey in the months leading up to the sale, and its website being all but unusable.