so much as an approach to weening the consumer from their reliance on clock speeds as a measure of performance
You know, in a couple years clock speeds will be so high that that they will be largely irrelevant for most PC purchasers. Except for a very small group of users, neither the Mhz or the benchmarks will really matter all that much. At that point the chip specs become a footnote in the manual.
Look at the current situation -- AMD has a very fast 1.4Ghz chip that they apparently have to almost give away at $100 or so a unit. Long gone are the days when Intel could release a chip that was 10% faster and demand twice as much money for it. A 2 Ghz chip comes out, and it's being sold at Walmart, not as a $8000 workstation. Mhz is no longer moving product.
The OEMs have been primarily relying on Intel and AMD to 'add value' by routinely upping clockspeeds. The result is a commodity low-margin business where the CPU guys make all the profits. They've got a couple years to try to figure out another way to squeeze blood out of a turnip (like Apple did with style and video apps, for example), and then it's all over.
Ami/Samna was a well-regarded product in the early days (long before being bundled by Lotus), although I think you'd find that it post-dates the excellent early versions of Word for the Mac.
Lotus shipped a integrated GUI office suite called "Jazz" for the Mac that included fancy features like embedding in 1985, but grew disinterested and dropped the product within a year.
Microsoft was 'bundling' Office together from nearly the beginning, and this was a key sales point. For less than price of WordPerfect and Lotus 1-2-3 (for DOS), you could also get PowerPoint essentially for free, and Access for only $100 more. They were not OEM bundling until much later.
It took WP and Lotus a long time to both match MS's price structure and round out their product lines, apart from their complete inability to ship working GUI versions. (And even tho Office included the MS Mail client software, it did NOT include the seat licence. Microsoft later settled some class-action suits surrounding this bit of false advertising.)
Don't forget -- you're dealing with thirty-odd years of history here -- Unix is what it is
For some reason, Unix has the only userbase that has these expectations. "It's always sucked that way! You'll fix it over my cold dead shell scripts!"
The sad thing is that Unix has turned into a mess of hard-coded paths, even more so than Windows. Symlinks are the band-aid, but have allowed a real solution to be put off indefinately. The whole 'look, but don't touch' bit certain (even in package managed installations) increases admin work and decreases flexibility for the average users. Too bad that someone couldn't look at MacOS or NeXT (or even steal ideas from MS's.NET), and come up with an elegant solution that's in the spirit of the Unix tradition.
Yeah, that's the essential argument -- across and organization people might be using 80% of a huge package like Office's features, and it's useful for users using obscure features to be able to send files to those who aren't without having to deploy additional tools. I agree with the parent's gist that Office is overkill for most individual users, tho.
They utterly failed on the dos and windows side. They failed in the market and consistently placed last in reviews.
Maybe on DOS, Microsoft apps were a joke, but your statement is complete bullshit on Windows. You want to see bad reviews -- look up WordPerfect's and Lotus' early attempts at GUI applications (whether on Mac, OS/2, or Windows). Pathetic!
(And the business world figured fairly quickly that going with a GUI environment had enormous advantages, so much so that they were willing to deal with Windows 3.x.)
And then something happened: Office suddenly started shipping pre-installed on everything from several major hardware manufacturors
Your conspiracy theory is totally wrongheaded. Office was not preinstalled on anything until it had by-in-large become the business standard office suite in the mid-90s. Your theory doesn't even make any sense because Microsoft has always viewed Windows as the loss-leader for Office (it was Windows that was being pre-installed for free, not Office).
You want conspiracy? Office became popular essentially due to a 'user rebellion' against crappy and obscured DOS applications. This rebellion included tons of casual piracy, which of course Microsoft did absolutely nothing to discourage until they had the market more than locked up.
Office wasn't pre-installed until Microsoft figured that if the users were going beg-borrow-steal a copy no matter what, they might as well get a little bit of money for it.
The lesson here is that the media is easily distracted
Distracted, or disinterested in covering legislation that materially affected them? I seem to recall that they pretty much slept through the two year long debate that lead up to the 96 telecom act with only the normal sex scandal background noise.
I have never seen anything to date that said Sklyarov himself was involved with the Ebook decoder project.
Two scenarios:
1) The FBI was acting on hearsay from the Adobe corporation, and arrested Sklyarov because he claimed at a hacker convention that he cracked eBooks. Totally possible, but this scenario would leave them open to great embarassment if it was found that either they had the wrong person or the software did not work as advertised.
2) The FBI purchased or obtained the software from the person said to be Sklyarov and then verified it did in fact bypass eBook copy protection before making the arrest.
Most people here seem to be assuming #1. I'll bet a dollar on scenario #2.
That being said, shouldn't the United States be going after the company's officers (CEO, etc.)
Is there any evidence that there's more than one employee at this company?
First, very good article on os2hq that shows an order of magintude greater understanding of the situation than most OS/2 post-mortums.
They failed to recognize the unique opportunity to put a brutal whipping on Microsoft's mediocre, unreliable kludges on the Intel-based desktop. Instead, IBM went for the whole enchilada by attempting to develop a version of OS/2 specially tuned to work efficiently and reliably on the PowerPC platform, in hopes of providing a complete spectrum of operating systems for this nascent would-be Intel-killer. However, OS/2's architecture does not translate well to match the machine internals of PowerPC.
That cracked me up, because OS/2 was exactly the sort of "mediocre, unreliable kludges on the Intel-based desktop" that the author is bemoaning, although it managed to outpace Windows 3.1.
The irony was that Microsoft was well aware of the platform-dependancy of OS/2, which is why they went off with the NT project. The part of "OS/2's architecture" that didn't translate well was scads of 286 and 386 asm code.
But IBM did not want to push OS/2 on the Intel platform, legitimizing Intel as a realistic alternative to other IBM offerings such as AS/400 and AIX-based machines.
This is true -- OS/2 was always a product that was squeezed out of it's own market. IBM refused to seriously market it as a server OS (or even a client OS in a client-server network) for fear of their high-profit midrange business. When NT Server and higher-powered Intel boxes hit the scene, IBM missed the market opportunity and instead chased the so-ho desktop. I don't know if they were aware or not in 94-96 that OS/2 had long ago hit it's high-water mark in big corporations, 'Chicago' FUD or no, but by the time that OS/2-PPC systems were starting to be pre-marketed, wintel was so entrenched that that idea was almost comic.
IBM learned their lessson big-time, and are finally now a real force in the PC server market, with substantial support resources poured into both W2K and Linux.
The stardock.com rant is good too, because it outlines how enormous retail sales of OS/2 weren't translating into a real userbase. (An old c.o.o.a post argued that if even 50% of the retail OS/2 customers were running OS/2, they would have a greater user base than MacOS. Turns that ratio was wildly optimistic. Sellers of retailed box Linux distros take note.)
Eh, problem is that the # of people working with audio/video is 1/100 of the number of people working with Word/Powerpoint.
Until about 500mhz, there was a subjective (if pointless) improvement in the feel of common desktop apps. No longer. In fact the only reason that corporations don't buy low-power low-speed chips is that Intel/AMD refuse to make them anymore. If the market was truly meeting demand instead of in a MAD arms race, you wouldn't see 2Ghz chips except at a very high cost (see the old MIPS and Alpha chips).
Bottom line was that Apple was right -- things like the iMac/cube (and Compaq and IBM's attempts at office 'appliance' machines) are the future. CPU speed will be a footnote in the back of the manual for almost every box. People will blow their dollars on fancy flatscreen monitors instead of CPU. Intel might as well print up t-shirts that say "We made a 2Ghz chip and all we got was a lousy $100 bucks", and R+D will be 'adjusted' to suit that market situation.
Another possibility is that it was a hardware key logger. Someone posted a link to a commercial device called the KeyGhost that plugs inline on your PS/2 cable and looks like your ordinary cable bump.
In all the applications I have been a part of, we keep the ERD pretty much the same as the OOD.
This has been a problem with some of applications I've worked on. Suffice it to say that there has good reasons to let these diverge, and SPs can be used to hold it together, although you could use another application server 'tier' to do this.
your DBA to hide the fact that he can't coherently design the datamodel
Well, IMO, the DBA shouldn't be designing the data model or writing the stored procs and should stick to DBA things. Any project I've been involved in where there's a special 'database guy' has been doomed from the get-go as he basically has to do all of the application analysis *again* between worrying about backup schedules and managing database devices.
please note that decent appservers can cache these Ejbs in memory so that many queries don't even hit the database
It's true that you can 'disconnect' entity beans from the DB, but if you don't, you are holding a transaction lock over the wire. Plus EJBs are really bad for set processing (something that SQL is really good at). The idea of entity beans seems to be that the Java programmer can worry about java and not have to understand the database interactions. This is only true to the extent you are willing to suffer on performance.
1) Stored Procedures should be considered a 'tier' in your application. They are the only real way to abstract your business logic away from your underlying database schema.
It's true you don't want business logic in your SQL as much as possible, but you also don't want a bunch of hardcoded SQL in your business logic if you can help it. Stored procedures help here, even at the cost of seriously reduced portability.
2) N-tier programming has the nasty habit of encourging very slow client-side joins and holding transaction locks over the wire. Especially if you get into (gack) EJB entity beans. If you can massivly reduce round-trips to the database by using stored procs, it's a clear win on performance.
Perl stored procedures seems to have it all back-assward. Rather than doing the join on the client side with your 'fast' Perl, they push it into the database, which gives you the abstraction, but doesn't help you an ounce on the speed bit. I suppose this is sorta like running an EJB container in your database, but I'm not completely familiar with how that works.
"HTCP -- has been part of i.Link firmware since at least 1999"
OK, I didn't know that. I thought the standard was relatively recent.
I also should have more strongly made the point that yet another copy protection 'black box' is about to be added to people's "Personal" Computers, err, Media Consumption Terminals.
Re:Retro gaming takes off
on
MAME on X-Box
·
· Score: 1
The DMCA allows for reverse engineering when "the sole purpose of identifying and analyzing those elements of the program that are necessary to achieve interoperability of an independently created computer program [Linux] with other programs [XBox bios]". (IANAL and all normal/. bullshitter disclaimers)
For example, if you reverse engineered DVD CSS with the intent of making your own CSS-protected movies and not paying the licence fees, it would (probably) be legal.
It should also be pointed out that Sony has big plans for iLink (their brandname for 1394/firewire), and wants to see it as the universal interconnect for the digital home theater of the future. However, they essentially put it on ice for everything (except for camcorders) until the 5C copy protection stuff could be implemented. As you mentioned, the first 1394 TV has just come onto the market.
For the home computer user, Firewire might seem a little useless right now, unless you are doing video or using a removable drive. However, in the future, being able to seemless connect and control your TV and stereo systems could bring about some great applications. That is, unless the copy protection stuff locks it up to the point of being useless.
Re:Retro gaming takes off
on
MAME on X-Box
·
· Score: 2
From what I've heard, the XBox only boots from DVD-9, and requires some sort of crypto authentication check in the bios. Microsoft has an open challenge out that "Anyone who gets Linux booting on the XBox has a job waiting for them at Microsoft". (some reward, eh?) Meaning that they feel that it's darn well impossible.
This could be interesting, because if the XBox boot sequence is reverse engineered or bypassed, it would be perfectly legal to sell non-licenced software for the thing in the US. (see Activision/Atari and Accolade+EA?/Sega)
Maybe I should have mentioned that exiting and restarting Windows 3.1 could be done in under 10 seconds. Meanwhile, in not uncommon case when WinOS2 brought down or locked OS/2, you would have to wait thru it's interminable boot sequence.
Face it, if WinOS2 was a compelling environment, OS/2 might have actually gotten popular.
"Bingo! So why hold Linux to the same standard as Windows when it comes to ease of installation? "
The whole installation issue is a non-issue. Windows XP still uses the scary DOS5/Win3.1-style text mode bluescreens for example, and that won't hurt it's sales one bit.
Another non-issue is the GUI itself. Both KDE and Gnome are pretty much more than 'good enough'. Don't forget that people happily standardized on Windows 3.1 back in the day, even though it's GUI was terrible compared to all alternatives. (Examples of your wife/girlfriend/little sister using a Unix GUI are pointless because they are not doing any admin.)
The huge issue affecting Linux/Unix adoption is post-install configuration. This is where the ease-of-use advocates are running smackdab into the Unix traditionalists' love of vi and flatfiles and custom compiles. Until someone can plug a printer/scanner/mouse in and have it 'just work', the OEMs that ship most copies of Windows will want nothing to do with Linux because they will get destroyed on support costs.
"OS/2 often times ran Win16 apps better than Windows itself. And thats not just typical anti-MS FUD!"
Yes it is. In the best case, OS/2 ran Windows apps exactly as well as Windows did (==not well), because it was by-in-large the same codebase. The advantage was that you didn't have to reboot after one of the frequent crashes, and that you could run multiple WinOS2 partitions.
Of course, the best case wasn't all that common. Many apps didn't like WinOS2, there were videodriver issues with the environment, and the 'seemless windows' mode tended to hang the entire OS due to the single input queue issue.
I'm not posting this to knock OS/2 -- it's Win16 environment existed as a minor transition feature. Just that the whole "Better Windows than Windows" marketing line was a bunch of bullshit. (I ran OS/2 in production as both clients and servers, but lots of dabblers that sprung for the cheap retail copies can attest to this.)
(The WOW feature in NT actually was a better Windows environment because it dumped all of the shite Win3.1 code and thunked API calls directly to Win32, thus resolving the 'resource pools' issues as well as general stability issues. Too bad it required so much memory [32MB!])
So by reducing the # of wires going to your PC, you reduce the rats nest. I know it would for me.
I think what you miss is that with pre-USB PCs the big problem was the *lack* of a rat's nest.
Until USB, PCs commonly shipped with NO general external expansion bus, just specialized ports, although you could use something klugy to have a non-printer device on the parallel port. This made it exteremely difficult to ship things like scanners and cameras for the PC market, unless you were targetting the 1-in-a-million users that actually ran on SCSI.
What we've seen since USB is an explosion of external perpherials, thus causing a rat's nest. Fortuantely, technology is here to save the day again with bluetooth.
(I'm replying to you on the bottom of the thread, but insert the response anywhere...)
When IRDA was hot tech back in the mid-90s, I tried a number of things with some Win95 laptops, and it just plain did not work except (sometimes) between two identical IBM laptops. Configuring Winders to transfer files was a pain in the ass and involved setting up a dial-up networking server. HP had just started shipping printers with an IR interface, a practice they later scaled back, mainly because none of the numerous laptops I tried could actually print to the damn things.
So it might have failed because line-of-sight, but it also could have been that the tech was plain broken during the adoption phase, and later was widely forgotton.
(Bluetooth came out of the cell phone makers desire to build a wireless headset -- it wasn't orginally intended to be computer tech per se, although that's where it will probably be adopted first.)
Re:So how would IBM do an AIX-Linux switch?
on
IBM Wants Linux
·
· Score: 2
The reason we will probably not see an IBM-branded Linux OS is that IBM would then feel obligated to provide IBM-style service and support for the product.
Right now if a big customer wants a feature that Linux doesn't have, IBM can point them to the RedHat/Alan Cox/Linus entanglement and let them work it out for themselves. It it were "IBM Linux", they would look at the numbers on the sales contract and feel the need to just go ahead and implement the feature, possibly forking or burning bridges with the existing Linux developer base. IBM has extremely long maintenence cycles (look at OS/2). Imagine Linux 2.2 being under active development for the next 4 years...
In short, IBM probably loves the current Linux distribution model because it gives them some insulation in the support process and allows them to turn over product with Microsoft-like speed.
Re:It's more AS/400 vs RS/6000
on
IBM Wants Linux
·
· Score: 1
The machines are almost the same hardware -- pretty much the only reason they aren't exactly the same is market segmentation.
With the apparent death of OpenVMS, the AS/400 is the last of the great proprietary minicomputers. Heavily used in certain industrial and financial applicaitons, the things manage to sell like hotcakes, and the support contracts are huge $$$ for IBM (even a text editor costs extra money on the thing). If you were IBM and could make money the old fashion way with complete vendor lock-in, why would you even think about dropping the AS/400? The UNIX boxes exists specifically because some customers obviously won't go for that.
Re:Copied != Stolen, even by IP-Shyster Definition
on
IBM Wants Linux
·
· Score: 2
It should also be noted that POSIX and the Single UNIX Specification (etc) are published standards specifically so that independant parties can re-implement them without having to pay licence fees. That's the original meaning of the term "Open System".
The money is on the certification side (the "UNIX" brandname). The fact that Linux hasn't been certified hasn't seemed to hurt it a bit.
Slashdot Mirror
so much as an approach to weening the consumer from their reliance on clock speeds as a measure of performance
You know, in a couple years clock speeds will be so high that that they will be largely irrelevant for most PC purchasers. Except for a very small group of users, neither the Mhz or the benchmarks will really matter all that much. At that point the chip specs become a footnote in the manual.
Look at the current situation -- AMD has a very fast 1.4Ghz chip that they apparently have to almost give away at $100 or so a unit. Long gone are the days when Intel could release a chip that was 10% faster and demand twice as much money for it. A 2 Ghz chip comes out, and it's being sold at Walmart, not as a $8000 workstation. Mhz is no longer moving product.
The OEMs have been primarily relying on Intel and AMD to 'add value' by routinely upping clockspeeds. The result is a commodity low-margin business where the CPU guys make all the profits. They've got a couple years to try to figure out another way to squeeze blood out of a turnip (like Apple did with style and video apps, for example), and then it's all over.
You're damn right Apple was unwilling to do something stupid like this
You forget when Apple retroactively doubled the clockspeed of all their 040 machines, even those that were no longer in production.
Ami/Samna was a well-regarded product in the early days (long before being bundled by Lotus), although I think you'd find that it post-dates the excellent early versions of Word for the Mac.
Lotus shipped a integrated GUI office suite called "Jazz" for the Mac that included fancy features like embedding in 1985, but grew disinterested and dropped the product within a year.
Microsoft was 'bundling' Office together from nearly the beginning, and this was a key sales point. For less than price of WordPerfect and Lotus 1-2-3 (for DOS), you could also get PowerPoint essentially for free, and Access for only $100 more. They were not OEM bundling until much later.
It took WP and Lotus a long time to both match MS's price structure and round out their product lines, apart from their complete inability to ship working GUI versions. (And even tho Office included the MS Mail client software, it did NOT include the seat licence. Microsoft later settled some class-action suits surrounding this bit of false advertising.)
Don't forget -- you're dealing with thirty-odd years of history here -- Unix is what it is
.NET), and come up with an elegant solution that's in the spirit of the Unix tradition.
For some reason, Unix has the only userbase that has these expectations. "It's always sucked that way! You'll fix it over my cold dead shell scripts!"
The sad thing is that Unix has turned into a mess of hard-coded paths, even more so than Windows. Symlinks are the band-aid, but have allowed a real solution to be put off indefinately. The whole 'look, but don't touch' bit certain (even in package managed installations) increases admin work and decreases flexibility for the average users. Too bad that someone couldn't look at MacOS or NeXT (or even steal ideas from MS's
Yeah, that's the essential argument -- across and organization people might be using 80% of a huge package like Office's features, and it's useful for users using obscure features to be able to send files to those who aren't without having to deploy additional tools. I agree with the parent's gist that Office is overkill for most individual users, tho.
They utterly failed on the dos and windows side. They failed in the market and consistently placed last in reviews.
Maybe on DOS, Microsoft apps were a joke, but your statement is complete bullshit on Windows. You want to see bad reviews -- look up WordPerfect's and Lotus' early attempts at GUI applications (whether on Mac, OS/2, or Windows). Pathetic!
(And the business world figured fairly quickly that going with a GUI environment had enormous advantages, so much so that they were willing to deal with Windows 3.x.)
And then something happened: Office suddenly started shipping pre-installed on everything from several major hardware manufacturors
Your conspiracy theory is totally wrongheaded. Office was not preinstalled on anything until it had by-in-large become the business standard office suite in the mid-90s. Your theory doesn't even make any sense because Microsoft has always viewed Windows as the loss-leader for Office (it was Windows that was being pre-installed for free, not Office).
You want conspiracy? Office became popular essentially due to a 'user rebellion' against crappy and obscured DOS applications. This rebellion included tons of casual piracy, which of course Microsoft did absolutely nothing to discourage until they had the market more than locked up.
Office wasn't pre-installed until Microsoft figured that if the users were going beg-borrow-steal a copy no matter what, they might as well get a little bit of money for it.
The lesson here is that the media is easily distracted
Distracted, or disinterested in covering legislation that materially affected them? I seem to recall that they pretty much slept through the two year long debate that lead up to the 96 telecom act with only the normal sex scandal background noise.
I have never seen anything to date that said Sklyarov himself was involved with the Ebook decoder project.
Two scenarios:
1) The FBI was acting on hearsay from the Adobe corporation, and arrested Sklyarov because he claimed at a hacker convention that he cracked eBooks. Totally possible, but this scenario would leave them open to great embarassment if it was found that either they had the wrong person or the software did not work as advertised.
2) The FBI purchased or obtained the software from the person said to be Sklyarov and then verified it did in fact bypass eBook copy protection before making the arrest.
Most people here seem to be assuming #1. I'll bet a dollar on scenario #2.
That being said, shouldn't the United States be going after the company's officers (CEO, etc.)
Is there any evidence that there's more than one employee at this company?
First, very good article on os2hq that shows an order of magintude greater understanding of the situation than most OS/2 post-mortums.
They failed to recognize the unique opportunity to put a brutal whipping on Microsoft's mediocre, unreliable kludges on the Intel-based desktop. Instead, IBM went for the whole enchilada by attempting to develop a version of OS/2 specially tuned to work efficiently and reliably on the PowerPC platform, in hopes of providing a complete spectrum of operating systems for this nascent would-be Intel-killer. However, OS/2's architecture does not translate well to match the machine internals of PowerPC.
That cracked me up, because OS/2 was exactly the sort of "mediocre, unreliable kludges on the Intel-based desktop" that the author is bemoaning, although it managed to outpace Windows 3.1.
The irony was that Microsoft was well aware of the platform-dependancy of OS/2, which is why they went off with the NT project. The part of "OS/2's architecture" that didn't translate well was scads of 286 and 386 asm code.
But IBM did not want to push OS/2 on the Intel platform, legitimizing Intel as a realistic alternative to other IBM offerings such as AS/400 and AIX-based machines.
This is true -- OS/2 was always a product that was squeezed out of it's own market. IBM refused to seriously market it as a server OS (or even a client OS in a client-server network) for fear of their high-profit midrange business. When NT Server and higher-powered Intel boxes hit the scene, IBM missed the market opportunity and instead chased the so-ho desktop. I don't know if they were aware or not in 94-96 that OS/2 had long ago hit it's high-water mark in big corporations, 'Chicago' FUD or no, but by the time that OS/2-PPC systems were starting to be pre-marketed, wintel was so entrenched that that idea was almost comic.
IBM learned their lessson big-time, and are finally now a real force in the PC server market, with substantial support resources poured into both W2K and Linux.
The stardock.com rant is good too, because it outlines how enormous retail sales of OS/2 weren't translating into a real userbase. (An old c.o.o.a post argued that if even 50% of the retail OS/2 customers were running OS/2, they would have a greater user base than MacOS. Turns that ratio was wildly optimistic. Sellers of retailed box Linux distros take note.)
Eh, problem is that the # of people working with audio/video is 1/100 of the number of people working with Word/Powerpoint.
Until about 500mhz, there was a subjective (if pointless) improvement in the feel of common desktop apps. No longer. In fact the only reason that corporations don't buy low-power low-speed chips is that Intel/AMD refuse to make them anymore. If the market was truly meeting demand instead of in a MAD arms race, you wouldn't see 2Ghz chips except at a very high cost (see the old MIPS and Alpha chips).
Bottom line was that Apple was right -- things like the iMac/cube (and Compaq and IBM's attempts at office 'appliance' machines) are the future. CPU speed will be a footnote in the back of the manual for almost every box. People will blow their dollars on fancy flatscreen monitors instead of CPU. Intel might as well print up t-shirts that say "We made a 2Ghz chip and all we got was a lousy $100 bucks", and R+D will be 'adjusted' to suit that market situation.
Another possibility is that it was a hardware key logger. Someone posted a link to a commercial device called the KeyGhost that plugs inline on your PS/2 cable and looks like your ordinary cable bump.
In all the applications I have been a part of, we keep the ERD pretty much the same as the OOD.
This has been a problem with some of applications I've worked on. Suffice it to say that there has good reasons to let these diverge, and SPs can be used to hold it together, although you could use another application server 'tier' to do this.
your DBA to hide the fact that he can't coherently design the datamodel
Well, IMO, the DBA shouldn't be designing the data model or writing the stored procs and should stick to DBA things. Any project I've been involved in where there's a special 'database guy' has been doomed from the get-go as he basically has to do all of the application analysis *again* between worrying about backup schedules and managing database devices.
please note that decent appservers can cache these Ejbs in memory so that many queries don't even hit the database
It's true that you can 'disconnect' entity beans from the DB, but if you don't, you are holding a transaction lock over the wire. Plus EJBs are really bad for set processing (something that SQL is really good at). The idea of entity beans seems to be that the Java programmer can worry about java and not have to understand the database interactions. This is only true to the extent you are willing to suffer on performance.
1) Stored Procedures should be considered a 'tier' in your application. They are the only real way to abstract your business logic away from your underlying database schema.
It's true you don't want business logic in your SQL as much as possible, but you also don't want a bunch of hardcoded SQL in your business logic if you can help it. Stored procedures help here, even at the cost of seriously reduced portability.
2) N-tier programming has the nasty habit of encourging very slow client-side joins and holding transaction locks over the wire. Especially if you get into (gack) EJB entity beans. If you can massivly reduce round-trips to the database by using stored procs, it's a clear win on performance.
Perl stored procedures seems to have it all back-assward. Rather than doing the join on the client side with your 'fast' Perl, they push it into the database, which gives you the abstraction, but doesn't help you an ounce on the speed bit. I suppose this is sorta like running an EJB container in your database, but I'm not completely familiar with how that works.
"HTCP -- has been part of i.Link firmware since at least 1999"
OK, I didn't know that. I thought the standard was relatively recent.
I also should have more strongly made the point that yet another copy protection 'black box' is about to be added to people's "Personal" Computers, err, Media Consumption Terminals.
The DMCA allows for reverse engineering when "the sole purpose of identifying and analyzing those elements of the program that are necessary to achieve interoperability of an independently created computer program [Linux] with other programs [XBox bios]". (IANAL and all normal /. bullshitter disclaimers)
For example, if you reverse engineered DVD CSS with the intent of making your own CSS-protected movies and not paying the licence fees, it would (probably) be legal.
It should also be pointed out that Sony has big plans for iLink (their brandname for 1394/firewire), and wants to see it as the universal interconnect for the digital home theater of the future. However, they essentially put it on ice for everything (except for camcorders) until the 5C copy protection stuff could be implemented. As you mentioned, the first 1394 TV has just come onto the market.
For the home computer user, Firewire might seem a little useless right now, unless you are doing video or using a removable drive. However, in the future, being able to seemless connect and control your TV and stereo systems could bring about some great applications. That is, unless the copy protection stuff locks it up to the point of being useless.
From what I've heard, the XBox only boots from DVD-9, and requires some sort of crypto authentication check in the bios. Microsoft has an open challenge out that "Anyone who gets Linux booting on the XBox has a job waiting for them at Microsoft". (some reward, eh?) Meaning that they feel that it's darn well impossible.
This could be interesting, because if the XBox boot sequence is reverse engineered or bypassed, it would be perfectly legal to sell non-licenced software for the thing in the US. (see Activision/Atari and Accolade+EA?/Sega)
Maybe I should have mentioned that exiting and restarting Windows 3.1 could be done in under 10 seconds. Meanwhile, in not uncommon case when WinOS2 brought down or locked OS/2, you would have to wait thru it's interminable boot sequence.
Face it, if WinOS2 was a compelling environment, OS/2 might have actually gotten popular.
"Bingo! So why hold Linux to the same standard as Windows when it comes to ease of installation? "
The whole installation issue is a non-issue. Windows XP still uses the scary DOS5/Win3.1-style text mode bluescreens for example, and that won't hurt it's sales one bit.
Another non-issue is the GUI itself. Both KDE and Gnome are pretty much more than 'good enough'. Don't forget that people happily standardized on Windows 3.1 back in the day, even though it's GUI was terrible compared to all alternatives. (Examples of your wife/girlfriend/little sister using a Unix GUI are pointless because they are not doing any admin.)
The huge issue affecting Linux/Unix adoption is post-install configuration. This is where the ease-of-use advocates are running smackdab into the Unix traditionalists' love of vi and flatfiles and custom compiles. Until someone can plug a printer/scanner/mouse in and have it 'just work', the OEMs that ship most copies of Windows will want nothing to do with Linux because they will get destroyed on support costs.
"OS/2 often times ran Win16 apps better than Windows itself. And thats not just typical anti-MS FUD!"
Yes it is. In the best case, OS/2 ran Windows apps exactly as well as Windows did (==not well), because it was by-in-large the same codebase. The advantage was that you didn't have to reboot after one of the frequent crashes, and that you could run multiple WinOS2 partitions.
Of course, the best case wasn't all that common. Many apps didn't like WinOS2, there were videodriver issues with the environment, and the 'seemless windows' mode tended to hang the entire OS due to the single input queue issue.
I'm not posting this to knock OS/2 -- it's Win16 environment existed as a minor transition feature. Just that the whole "Better Windows than Windows" marketing line was a bunch of bullshit. (I ran OS/2 in production as both clients and servers, but lots of dabblers that sprung for the cheap retail copies can attest to this.)
(The WOW feature in NT actually was a better Windows environment because it dumped all of the shite Win3.1 code and thunked API calls directly to Win32, thus resolving the 'resource pools' issues as well as general stability issues. Too bad it required so much memory [32MB!])
So by reducing the # of wires going to your PC, you reduce the rats nest. I know it would for me.
I think what you miss is that with pre-USB PCs the big problem was the *lack* of a rat's nest.
Until USB, PCs commonly shipped with NO general external expansion bus, just specialized ports, although you could use something klugy to have a non-printer device on the parallel port. This made it exteremely difficult to ship things like scanners and cameras for the PC market, unless you were targetting the 1-in-a-million users that actually ran on SCSI.
What we've seen since USB is an explosion of external perpherials, thus causing a rat's nest. Fortuantely, technology is here to save the day again with bluetooth.
(I'm replying to you on the bottom of the thread, but insert the response anywhere...)
When IRDA was hot tech back in the mid-90s, I tried a number of things with some Win95 laptops, and it just plain did not work except (sometimes) between two identical IBM laptops. Configuring Winders to transfer files was a pain in the ass and involved setting up a dial-up networking server. HP had just started shipping printers with an IR interface, a practice they later scaled back, mainly because none of the numerous laptops I tried could actually print to the damn things.
So it might have failed because line-of-sight, but it also could have been that the tech was plain broken during the adoption phase, and later was widely forgotton.
(Bluetooth came out of the cell phone makers desire to build a wireless headset -- it wasn't orginally intended to be computer tech per se, although that's where it will probably be adopted first.)
The reason we will probably not see an IBM-branded Linux OS is that IBM would then feel obligated to provide IBM-style service and support for the product.
Right now if a big customer wants a feature that Linux doesn't have, IBM can point them to the RedHat/Alan Cox/Linus entanglement and let them work it out for themselves. It it were "IBM Linux", they would look at the numbers on the sales contract and feel the need to just go ahead and implement the feature, possibly forking or burning bridges with the existing Linux developer base. IBM has extremely long maintenence cycles (look at OS/2). Imagine Linux 2.2 being under active development for the next 4 years...
In short, IBM probably loves the current Linux distribution model because it gives them some insulation in the support process and allows them to turn over product with Microsoft-like speed.
The machines are almost the same hardware -- pretty much the only reason they aren't exactly the same is market segmentation.
With the apparent death of OpenVMS, the AS/400 is the last of the great proprietary minicomputers. Heavily used in certain industrial and financial applicaitons, the things manage to sell like hotcakes, and the support contracts are huge $$$ for IBM (even a text editor costs extra money on the thing). If you were IBM and could make money the old fashion way with complete vendor lock-in, why would you even think about dropping the AS/400? The UNIX boxes exists specifically because some customers obviously won't go for that.
It should also be noted that POSIX and the Single UNIX Specification (etc) are published standards specifically so that independant parties can re-implement them without having to pay licence fees. That's the original meaning of the term "Open System".
The money is on the certification side (the "UNIX" brandname). The fact that Linux hasn't been certified hasn't seemed to hurt it a bit.