Sony already has a digitial vidcam (can't remember the model offhand) that supports Bluetooth and records directly to MPEG-2 using the MicroDV tape format. The price (last I looked) was somewhere around $3500 CDN. They have a similar MicroDV vidcam without Bluetooth as well.
Re:Um... There is a good point here, guys....
on
Is Linux Dead?
·
· Score: 2
There actually is a good point in replacing OS/2. IBM will be dropping support over the next few years. In fact, OS/2-based software is already being dropped by the wayside.
IBM is basically abandoning the desktop and focusing on Network Station (thin-client) clients - where they can sell lots more servers.
The death of OS/2 is a big problem for lots of big companies (most of the world's big financial institutions are now, or have been, big OS/2 customers). We're all driving towards desktop replacements and working with IBM to develop relatively graceful exit strategies.
I'm sad to see OS/2 go. It was years ahead of its time and is THE most stable o/s (desktop and local server) I've ever seen. Unfortunately, it never generated much mindshare in the ISV community and, as such, it's death was foretold many years ago.
Um... There is a good point here, guys....
on
Is Linux Dead?
·
· Score: 5, Insightful
Linux on the server has been a success. No doubt. In fact, it will only get more successful when one considers the push coming from IBM (i.e. Linux on big iron). The parallels with Java here are pretty interesting.
However, Linux on the desktop has not been successful. That's the reality. "Mom and Dad" PC users - who make up a large demographic of typical consumers - are not using Linux on the desktop. Big corporations are not using Linux on the desktop. There are lots of reasons for all this, but in the end they boil down to:
no concerted marketing push. MS excels here. Remember that superior technology does not make a product successful (look at OS/2 vs Windows).
perceived lack of professional applications and support. People need to see shrinkwrapped apps and a 1-800 support line. They don't see these today.
Case in point: I am currently developing a strategy on replacing 23,000 OS/2 platforms in my company. I have 2 basic choices for these desktops - Linux and Windows. Both have pros and cons around cost, stability, app availability, support, etc. Even though could save us millions of $$$ in licensing costs alone, Linux will be an uphill climb given the perceived lack of maturity and support in the vendor market. Linux needs a big-ass corporation (like IBM or HP) to really drive the momentum into the desktop.
Otherwise, it feels like the OS/2 saga all over again....*sigh*
I agree.... My company has farmed out some work to Bangalore and my advice is the same as crath's. My primary directives here:
spec your work as detailed as possible. That includes GUI look, feel, nav, etc. If you don't do this, you force your offshore friends to get creative - and you definitely do not want this. It's amazing how much cultural influence you get in a GUI design....
this goes double if the work is OO-based! OO development is by nature a collaborative effort, so we tend not to spec the details. This doesn't work when the team is somewhere else. Believe me.
establish up-front how software testing will be done. In my experience, unit testing is about as far as you want to go before they hand it over for system and acceptance testing. Otherwise, you end up with a big heasdaches (security, connectivity, etc.) connecting these folks to your internal development infrastructure.
bring a few of your offshore friends in-house to get a feel for the people and approach your IT shops uses. This is really key to building trust and context for future endeavours.
Only outsource what you know. Don't ask your offshore friends to develop stuff with which your company has no real experience. It will be a disaster for all involved. Trust me.
'Tis true... Career paths for tech folks is a big problem in corporate IT areas. However, it's a big problem because it's a relatively new problem. The first big demographic bulge of professional IT types is working its way through the corporate hierarchy and the rules are still being written. An interesting approach in the company I'm with (big bank) is the creation of a 'fellowship' position. Essentially this is a senior mgmt level for old, experienced geeks who want to remain geeks - i.e. guru types who have some level of social skills and practical streak that is not mesmerized by 'cool' technology. These folks are essentially advisors within the organization who can speak to coders and executives with some amount of ease and trust.
This doesn't solve the problem, of course, because there are few fellowship positions available and there are few who can really fill this niche role, but it's a start I think.
Oh yeah! And don't forget the sheer joy of running a multipart bursting machine at full tilt. This felt especially dangerous when you had a 3-foot stack of 5-part fanfold to burst and separate. Never could figure out how to get the carbon off the roller without getting my hands blackened. *sigh*
I hear you! I spent 4 years programming on a Pr1me. I loved doing Fortran on PrimOS. And how cool was COMO? Although, they never did produce a decent fullscreen editor. GET$....those were the days...
I think I agree with you - org scale does have an impact. But my fundamental premise that orgs (especially big orgs) just want a 'product' and 'support' - all from a vendor - still holds I think. A widget manufacturer stills want to make widgets - not necessarily maintain technology that is not fundamental to the business (e.g. they care deeply about maintaining their own production scheduling software, they care less deeply about maintaining their own o/s source).
As a senior IT guy at a Very Big Corp (and former geek) I must humbly point out a few errors in your logic:
I do not need the source, I need a support structure (i.e. a vendor) who has the source
I'm not willing to pay "lots_of_money" to fix something I already bought from the vendor
closed source or open source - no matter. As soon as I pay for support (under the above rules), it's closed source. Let the vendor worry about it.
Now, folks may not agree, but this is the way it works. Big corporations are in the business of doing their business, not maintaining an o/s (unless that is their business). Fact is, there's no such thing as "free' in the corp world. Corp wants to pay someone else (under an SLA) to maintain stuff. Where Linux is concerned, they want to (1) buy licenses from a vendor and (2) buy support from a vendor within an SLA. Any other arrangement does not work.
That said, I would love to exploit Linux desktops (and I'm considering that option for about 21,000 OS/2 desktops I have today). Why? Because I think it could be cheaper than going the M$ route - assuming vendor support is there. My biggest risk is the lack of applications (with support) and lack of peripheral vendors (with support). However, the picture is getting clearer and I have hope.
Wrong-o, bud. Software IS like a finished manufactured good. I buy a finished piece of software that does something useful; end of story. If it doesn't work, I get it fixed. If my chair doesn't work, I get it fixed (or replaced). That's how it is in the real world.
I work for a big bank. We do banking. We have hundreds of software developers that develop banking systems. But, we're not a software development company. We're a bank. If my bank has a problem with the Linux kernal, that's a huge risk to us (depending on how many Linux boxes out out there, what they do, etc.).
Hopping on the Net to get an answer and a fix might be fun, but it ain't the answer and it ain't the kind of risk we're willing to take. We're in the business of banking, not Linux kernals. We contract out to our technology providers to 'do' Linux kernals (or whatever).
I don't want to sound (more) facetious, but there is a stunning ignorance on Slashdot (generalization alert!) about how Big IT Shops work, how business works, and about 'risk'. This thread is yet another example. Big shops do not use public-facing support mechanisms. They use contracts.
We don't rely on boilerplate EULA arrangements. We contract exactly what we want and what obligations exist in terms of support levels, etc. If an Oracle database blows up, it matters not what Larry Ellison says. This is the way of world in large corporate customer environments. But, we're big enough to make this work (not without difficulties, though).
The real issue is economic, though. If we use an open source product, we have no one to modify that product (bug fixes, enhancements, etc.) and no timetable on which to operate. Ultimately, we have to either (1) rely on garnering support in the open source community or (2) fork the code on our own. Neither of which is particularly effective for us.
Hear, hear... Your 'chair' metaphore is bang on. I'm no rabid capitalist, but if ever come up with something really innovative software-wise, it will be mine to share in whatever manner I choose. Give it away, sell it, whatever.
I have found with any software I've developed and given away, my core rationale (however uncomfortable it is) has been 'ego'. Perhaps Mr. Stallman has a similar well-spring.
Interesting to note... The company I work for (large bank) will not use any product that is freeware or public-license. Why? They need a 'tie to grab' if something goes wrong, needs mods, etc. As well, my company is not in the business of managing someone else's code, even if that someone else is the Open Source Community.
Everyone agrees, KLOC is a dumb metric. It's something akin to Charles Dickens being paid for his stories by the chapter (true!) and so he produced extra-lengthy novels.
Everyone would agree that the real 'metric' is a combination of factors that, in total, attempts to measure "how much of the spec was implemented how fast". This doesn't necessarily measure quality, which is a whole other topic.
The idea of the Function Point methodology (been around for years) is to assign a metric based on total inputs, outputs, length, etc. etc. for an application. The number, on its own, is meaningless. Rather, it's a relative metric that over time will make sense within an organization. It allows you assign hindsight to foresight - i..e "That last project arrived under budget and under time and it's Function Point profile looked like this".
It's not perfect, but it's not bad. It was given birth way back in the heyday of mainframe Cobol development, but has tried to morph into a scheme usable in other worlds (like OO development). And, there are still legions of believers who flock to User conferences, so FP must be doing something right.
....and I need to replace them. I work for a large financial institution and, like many (many!) other banks worldwide, we run a lot of OS/2, have used it for a decade (ie. since version 1.3), and are now forced to move. This is not trivial.
All you closet OS/2-lovers are right, this o/s is rock-solid and needs very little active systems management to run. As well, we run all of our OS/2 desktops in RIPL-mode - which is akin to treating them all a 'network stations' sucking their o/s off a server at boot time. These desktops only have hard disk for swapping. And I could go on ad nauseaum about the PM API, file system, etc. etc.
As to OS/2 murky history, it's the stuff of legend. MS was there to handle the desktop interface while IBM was bringing it's mainframe skills to bear (swapping, pre-emptive multitasking, etc.). When things went sour, IBM had the OS/2 kernal and MS had some pretty desktop icons and a vague notion of what a real o/s might be. The rest, unfortunately, is history.
So, dear friends, where to go? What real choices do I have? MS with their obscene pricing and inferior technology (next to what I have today)? Otherwise, it's Linux with its low cost-of-ownership and less-than-clear (but getting clearer) support from mainstream vendors?
Fact is, nothing today comes close to matching OS/2's combination of solid technology and ease of support. Regardless, I have to choose.
I agree, this is sales. But, I should point out that Global Services (for the most part) is staffed by non-sales-types. I've done a ton of work with Global Services over the years and found (in my case anyways) they've never singled out their own products. That said, we have a standard clause we use in any of our contracts with them that clearly states they will have no contact with IBM Marketing (a separate arm) in regards to any consultantcy work with our company. Seems to work fine.
Oh come on... Modern systems are complex for sure, but they're only complex because we make them that way. Biological organisms appear complex because we really don't know how they work and their design is not of our own making. To compare these two domains on any kind of equal footing is wrong.
I think the point Katz tries to make (badly) is that we - the collective tech community - do not always think about our customers. We build interfaces that are hard to use, we employ too many competing standards and let our customers sort them out (think cell-phones for example), and we love tech for the sake of tech (not necessarily for what it does for us).
These are generalizations, sure. But look at cars, telephones, electrical grids, and televisions. Easy to use, tremendous hidden complexity, general agreements on standards by vendors, and the list goes on. These technologies are successful because their inventors and providers understood who their customers are and made products accordingly.
In the end....the infamous Mom Test. My mother doesn't need to understand POP mail's internals any more than she needs to understand the physics of the engine in her car. Sadly, she does need to understand the difference between leaving her mail on her ISP's server vs. having it downloaded to her PC. Is this right? I don't think so, but the fact others will disagree with me speaks volumes about the tech industry.
Re:Are we missing the point here?
on
Java RMI
·
· Score: 2
Not sure what 'rubblish' is, but I bet it's a bad thing. In retort: au contraire, mon frere... I started developing CORBA apps long ago (back when IBM's CORBA 1.0 SOM implementation was beta). Fact is, the CORBA 2.x spec is vague and bloated. Most CORBA implementations produce slow, bloated apps. It's NOT good for doing large-scale distributed apps that are maintainable. It's NOT good for doing granular dist. object interactions. Period. If CORBA (and other neat ideas like *nix RPC) were the right answer, we'd see much more large0-scale penetration (and marketing!) of the technology.
I don't pretend that SOAP/XML is pretty or easy. What I AM saying is that the direction is, by and large, a saner one for IT folks to manage because it suggests a more component-based, message-oriented design-point that does CORBA or RMI. My persprective is that of a corporate IT guy who needs to architect large-scale app infrastructure accessible (and simple) for hundreds of developers. Individual mileage may vary...
Are we missing the point here?
on
Java RMI
·
· Score: 2
The problems (I think) with the distributed objects approach via CORBA and even RMI are that:
they are bloated from both infrastructure and application perspectives
they expose too much 'implementation' of the remote object you're after
there is little connection between the design and performance perspectives of building an app
you cannot easily develop large-scale apps in this realm without an IDE (so you get tied to a toolset...)
So what does this mean in shops that produce high-volume, high-throughput, high-userbase apps? You usually find that dist. object implementations have their object-to-object interactions up-levelled (artificially) to ensure that 'messages' (as opposed to granular method calls) become the implemented design-point.
This is why RPCs (home-grown, SOAP/XML, or otherwise) make a lot more sense (to me). The technologies might be new, but the concepts are old and useful. Bottom-line (for me), is that RMI and CORBA do not implement service-based architectures very well. RPC-style solutions are a more natural fit from both the business requirement and technical design perspective.
Um...I think a sense of fulfillment would come from a whole lotta people watching their movie, not from a few hundred voting members of The Academy who may (or may not) have watched it. As for helping get other movie ideas considered - well perhaps. But I still think it's all about money. How else can one explain American Pie 2?
I cannot understand the preoccupation that some folks have with whether or not LOTR (or Star Wars or whatever) wins an Oscar (or whatever). These movies still seem to get made, regardless of winning any trophies. Why? Because they are enjoyable to lots of people and they make money.
Sorta makes me wonder whether too any people's sense of self-worth gets bolstered somehow if LOTR wins an Oscar or two - i.e. if you all like LOTR you must all like me....
I've run into this, too. My company upgraded its PC inventory a few years back and, consequently, we ended with (literally) thousands of surplus, high-end 486s. My idea was to get these PCs out to some schools, daycares, community groups, etc. (who would LOVE to have h/w of even this calibre) and, in return, my company would get some good karma (win-win). As well, we had staff offering to work on their own time to refresh the o/s on each machine (to deliver pristine h/w).
Well, lawyers got involved and were not happy with any technical solution we offered up to ensure all company data on these PCs was truly wiped clean. In the end, the only solution they felt acceptable was to rip out every drive and DRILL A HOLE THEM! Management, anxious about vague liability issues, rolled over in favour of the lawyers.
Needless to say, the PCs never got distributed to anyone who could use 'em, and my company ended up paying a PC salvager $200 per PC (!!!) to perform the aforementioned drilling exercise. Does the world suck sometimes or what?
Re:...a swing and a miss.
on
Heart of the Net
·
· Score: 3, Interesting
Absolutely bang on.... Look at the Net's parallels with the adoption of VCR tech by the masses. Notwithstanding the bizarre tale of the Fall of Beta, this communications mechanism (albeit 'push') was arguably funded and thrust into the mainstream by porn. Joe Public could obtain and enjoy the porn in his own home - a sharp contrast to the taboo of visiting some sleazy theater, etc.
In the early days (or is it daze) of Usenet, I remember seeing stats that estimated 40% of Usernet sites/traffic was porn-related. It's probably not a whole lot different on today's Web (maybe a lower percentage). Point is, porn sites are typically on the vanguard of implementing 'richer' Web experiences (streaming video, interactive video/chat, etc.) and developing self-serve economic models (i.e. credit-card processing). This would not exist if a significant portion of the Web community did not want it. Right?
I think the fees are a moot point since it's all but impossible to signup for Rogers@Home anyways. I tried 7 times over 2 weeks to signup for the service IN PERSON at several Rogers (and non-Rogers) locations in my city. Each time I was plagued by a lack of signup kits or crashes in the app that merchants use to signup customers.
In the end, I signed up with Bell Sympatico HSE (DSL) - which was a cakewalk to get going. Just for a laugh, I documented my experiences (tongue-in-cheek fashion) and emailed them to Rogers. I got a polite response thanking me for pointing out their process problems, but no mention of how I could actually get their service.
BTW, this behaviour is typical of Rogers in all their divisions. Their cable TV division tried to screw customers a few years back using a technique called 'negative billing'. They gave everyone a bunch of extra (but crappy) channels and then set a deadline by which you'd have to pay. If you didn't let Rogers know you DIDN'T want the channels, they'd assume you wanted 'em and would start charging you. This created a shitstorm in Parliment and Rogers eventually had to back down from this tactic. You can be sure that this latest Rogers@Home fee scam will catch the Feds attention given that one the Liberal government's platforms is (or was) to ensure broadband service is available in all parts of Canada (no matter how remote).
I agree with your points, mostly. The company I work for has a TON of function implemented on Websphere running on AIX. We really haven't cared too much about cross-platform features (do a bit of sharing between NT PC apps and Websphere AIX). We were an early adopter of Java because it seemed to address a lot of issues we had in developing C++ and Smalltalk apps (e.g. packaging, garbage collection, change mgmt, etc.).
However, we are planning to move our Websphere AIX implementation (for EJBs anyways) to an IBM390 box (or Z Series these days I guess) and we've found the proof-of-concept effort easier than we anticipated - simply because we can pickup our code (in JARs) and run it on big iron. Very nice! It also gives us some encouragement that we can really start to share more Java classes/components between browser-delivery and fat-client environments if we're smart about it.
OK Skippy... I'll put my 20 years of IT experience building large-scale computing infrastructure against your community college Perl course anyday.
Of course, if the disintermediation between sources of porn and Knuckle Monkeys such as yourself is proof of the Web's society-changing effects, then congrats. Maybe you can be Wired's Man(?)-Of-The-Year.
Slashdot Mirror
Sony already has a digitial vidcam (can't remember the model offhand) that supports Bluetooth and records directly to MPEG-2 using the MicroDV tape format. The price (last I looked) was somewhere around $3500 CDN. They have a similar MicroDV vidcam without Bluetooth as well.
IBM is basically abandoning the desktop and focusing on Network Station (thin-client) clients - where they can sell lots more servers.
The death of OS/2 is a big problem for lots of big companies (most of the world's big financial institutions are now, or have been, big OS/2 customers). We're all driving towards desktop replacements and working with IBM to develop relatively graceful exit strategies.
I'm sad to see OS/2 go. It was years ahead of its time and is THE most stable o/s (desktop and local server) I've ever seen. Unfortunately, it never generated much mindshare in the ISV community and, as such, it's death was foretold many years ago.
However, Linux on the desktop has not been successful. That's the reality. "Mom and Dad" PC users - who make up a large demographic of typical consumers - are not using Linux on the desktop. Big corporations are not using Linux on the desktop. There are lots of reasons for all this, but in the end they boil down to:
Case in point: I am currently developing a strategy on replacing 23,000 OS/2 platforms in my company. I have 2 basic choices for these desktops - Linux and Windows. Both have pros and cons around cost, stability, app availability, support, etc. Even though could save us millions of $$$ in licensing costs alone, Linux will be an uphill climb given the perceived lack of maturity and support in the vendor market. Linux needs a big-ass corporation (like IBM or HP) to really drive the momentum into the desktop.
Otherwise, it feels like the OS/2 saga all over again....*sigh*
- spec your work as detailed as possible. That includes GUI look, feel, nav, etc. If you don't do this, you force your offshore friends to get creative - and you definitely do not want this. It's amazing how much cultural influence you get in a GUI design....
- this goes double if the work is OO-based! OO development is by nature a collaborative effort, so we tend not to spec the details. This doesn't work when the team is somewhere else. Believe me.
- establish up-front how software testing will be done. In my experience, unit testing is about as far as you want to go before they hand it over for system and acceptance testing. Otherwise, you end up with a big heasdaches (security, connectivity, etc.) connecting these folks to your internal development infrastructure.
- bring a few of your offshore friends in-house to get a feel for the people and approach your IT shops uses. This is really key to building trust and context for future endeavours.
- Only outsource what you know. Don't ask your offshore friends to develop stuff with which your company has no real experience. It will be a disaster for all involved. Trust me.
Guess that's it. Good luck.This doesn't solve the problem, of course, because there are few fellowship positions available and there are few who can really fill this niche role, but it's a start I think.
Oh yeah! And don't forget the sheer joy of running a multipart bursting machine at full tilt. This felt especially dangerous when you had a 3-foot stack of 5-part fanfold to burst and separate. Never could figure out how to get the carbon off the roller without getting my hands blackened. *sigh*
I hear you! I spent 4 years programming on a Pr1me. I loved doing Fortran on PrimOS. And how cool was COMO? Although, they never did produce a decent fullscreen editor. GET$....those were the days...
I think I agree with you - org scale does have an impact. But my fundamental premise that orgs (especially big orgs) just want a 'product' and 'support' - all from a vendor - still holds I think. A widget manufacturer stills want to make widgets - not necessarily maintain technology that is not fundamental to the business (e.g. they care deeply about maintaining their own production scheduling software, they care less deeply about maintaining their own o/s source).
Now, folks may not agree, but this is the way it works. Big corporations are in the business of doing their business, not maintaining an o/s (unless that is their business). Fact is, there's no such thing as "free' in the corp world. Corp wants to pay someone else (under an SLA) to maintain stuff. Where Linux is concerned, they want to (1) buy licenses from a vendor and (2) buy support from a vendor within an SLA. Any other arrangement does not work.
That said, I would love to exploit Linux desktops (and I'm considering that option for about 21,000 OS/2 desktops I have today). Why? Because I think it could be cheaper than going the M$ route - assuming vendor support is there. My biggest risk is the lack of applications (with support) and lack of peripheral vendors (with support). However, the picture is getting clearer and I have hope.
Hopping on the Net to get an answer and a fix might be fun, but it ain't the answer and it ain't the kind of risk we're willing to take. We're in the business of banking, not Linux kernals. We contract out to our technology providers to 'do' Linux kernals (or whatever).
I don't want to sound (more) facetious, but there is a stunning ignorance on Slashdot (generalization alert!) about how Big IT Shops work, how business works, and about 'risk'. This thread is yet another example. Big shops do not use public-facing support mechanisms. They use contracts.
The real issue is economic, though. If we use an open source product, we have no one to modify that product (bug fixes, enhancements, etc.) and no timetable on which to operate. Ultimately, we have to either (1) rely on garnering support in the open source community or (2) fork the code on our own. Neither of which is particularly effective for us.
I have found with any software I've developed and given away, my core rationale (however uncomfortable it is) has been 'ego'. Perhaps Mr. Stallman has a similar well-spring.
Interesting to note... The company I work for (large bank) will not use any product that is freeware or public-license. Why? They need a 'tie to grab' if something goes wrong, needs mods, etc. As well, my company is not in the business of managing someone else's code, even if that someone else is the Open Source Community.
Everyone would agree that the real 'metric' is a combination of factors that, in total, attempts to measure "how much of the spec was implemented how fast". This doesn't necessarily measure quality, which is a whole other topic.
The idea of the Function Point methodology (been around for years) is to assign a metric based on total inputs, outputs, length, etc. etc. for an application. The number, on its own, is meaningless. Rather, it's a relative metric that over time will make sense within an organization. It allows you assign hindsight to foresight - i..e "That last project arrived under budget and under time and it's Function Point profile looked like this".
It's not perfect, but it's not bad. It was given birth way back in the heyday of mainframe Cobol development, but has tried to morph into a scheme usable in other worlds (like OO development). And, there are still legions of believers who flock to User conferences, so FP must be doing something right.
All you closet OS/2-lovers are right, this o/s is rock-solid and needs very little active systems management to run. As well, we run all of our OS/2 desktops in RIPL-mode - which is akin to treating them all a 'network stations' sucking their o/s off a server at boot time. These desktops only have hard disk for swapping. And I could go on ad nauseaum about the PM API, file system, etc. etc.
As to OS/2 murky history, it's the stuff of legend. MS was there to handle the desktop interface while IBM was bringing it's mainframe skills to bear (swapping, pre-emptive multitasking, etc.). When things went sour, IBM had the OS/2 kernal and MS had some pretty desktop icons and a vague notion of what a real o/s might be. The rest, unfortunately, is history.
So, dear friends, where to go? What real choices do I have? MS with their obscene pricing and inferior technology (next to what I have today)? Otherwise, it's Linux with its low cost-of-ownership and less-than-clear (but getting clearer) support from mainstream vendors?
Fact is, nothing today comes close to matching OS/2's combination of solid technology and ease of support. Regardless, I have to choose.
Anyone got any bright ideas?
I agree, this is sales. But, I should point out that Global Services (for the most part) is staffed by non-sales-types. I've done a ton of work with Global Services over the years and found (in my case anyways) they've never singled out their own products. That said, we have a standard clause we use in any of our contracts with them that clearly states they will have no contact with IBM Marketing (a separate arm) in regards to any consultantcy work with our company. Seems to work fine.
I think the point Katz tries to make (badly) is that we - the collective tech community - do not always think about our customers. We build interfaces that are hard to use, we employ too many competing standards and let our customers sort them out (think cell-phones for example), and we love tech for the sake of tech (not necessarily for what it does for us).
These are generalizations, sure. But look at cars, telephones, electrical grids, and televisions. Easy to use, tremendous hidden complexity, general agreements on standards by vendors, and the list goes on. These technologies are successful because their inventors and providers understood who their customers are and made products accordingly.
In the end....the infamous Mom Test. My mother doesn't need to understand POP mail's internals any more than she needs to understand the physics of the engine in her car. Sadly, she does need to understand the difference between leaving her mail on her ISP's server vs. having it downloaded to her PC. Is this right? I don't think so, but the fact others will disagree with me speaks volumes about the tech industry.
I don't pretend that SOAP/XML is pretty or easy. What I AM saying is that the direction is, by and large, a saner one for IT folks to manage because it suggests a more component-based, message-oriented design-point that does CORBA or RMI. My persprective is that of a corporate IT guy who needs to architect large-scale app infrastructure accessible (and simple) for hundreds of developers. Individual mileage may vary...
So what does this mean in shops that produce high-volume, high-throughput, high-userbase apps? You usually find that dist. object implementations have their object-to-object interactions up-levelled (artificially) to ensure that 'messages' (as opposed to granular method calls) become the implemented design-point.
This is why RPCs (home-grown, SOAP/XML, or otherwise) make a lot more sense (to me). The technologies might be new, but the concepts are old and useful. Bottom-line (for me), is that RMI and CORBA do not implement service-based architectures very well. RPC-style solutions are a more natural fit from both the business requirement and technical design perspective.
Um...I think a sense of fulfillment would come from a whole lotta people watching their movie, not from a few hundred voting members of The Academy who may (or may not) have watched it. As for helping get other movie ideas considered - well perhaps. But I still think it's all about money. How else can one explain American Pie 2?
Sorta makes me wonder whether too any people's sense of self-worth gets bolstered somehow if LOTR wins an Oscar or two - i.e. if you all like LOTR you must all like me....
Well, lawyers got involved and were not happy with any technical solution we offered up to ensure all company data on these PCs was truly wiped clean. In the end, the only solution they felt acceptable was to rip out every drive and DRILL A HOLE THEM! Management, anxious about vague liability issues, rolled over in favour of the lawyers.
Needless to say, the PCs never got distributed to anyone who could use 'em, and my company ended up paying a PC salvager $200 per PC (!!!) to perform the aforementioned drilling exercise. Does the world suck sometimes or what?
In the early days (or is it daze) of Usenet, I remember seeing stats that estimated 40% of Usernet sites/traffic was porn-related. It's probably not a whole lot different on today's Web (maybe a lower percentage). Point is, porn sites are typically on the vanguard of implementing 'richer' Web experiences (streaming video, interactive video/chat, etc.) and developing self-serve economic models (i.e. credit-card processing). This would not exist if a significant portion of the Web community did not want it. Right?
In the end, I signed up with Bell Sympatico HSE (DSL) - which was a cakewalk to get going. Just for a laugh, I documented my experiences (tongue-in-cheek fashion) and emailed them to Rogers. I got a polite response thanking me for pointing out their process problems, but no mention of how I could actually get their service.
BTW, this behaviour is typical of Rogers in all their divisions. Their cable TV division tried to screw customers a few years back using a technique called 'negative billing'. They gave everyone a bunch of extra (but crappy) channels and then set a deadline by which you'd have to pay. If you didn't let Rogers know you DIDN'T want the channels, they'd assume you wanted 'em and would start charging you. This created a shitstorm in Parliment and Rogers eventually had to back down from this tactic. You can be sure that this latest Rogers@Home fee scam will catch the Feds attention given that one the Liberal government's platforms is (or was) to ensure broadband service is available in all parts of Canada (no matter how remote).
I agree with your points, mostly. The company I work for has a TON of function implemented on Websphere running on AIX. We really haven't cared too much about cross-platform features (do a bit of sharing between NT PC apps and Websphere AIX). We were an early adopter of Java because it seemed to address a lot of issues we had in developing C++ and Smalltalk apps (e.g. packaging, garbage collection, change mgmt, etc.).
However, we are planning to move our Websphere AIX implementation (for EJBs anyways) to an IBM390 box (or Z Series these days I guess) and we've found the proof-of-concept effort easier than we anticipated - simply because we can pickup our code (in JARs) and run it on big iron. Very nice! It also gives us some encouragement that we can really start to share more Java classes/components between browser-delivery and fat-client environments if we're smart about it.
Anyways, just one experience that's worked out...
Of course, if the disintermediation between sources of porn and Knuckle Monkeys such as yourself is proof of the Web's society-changing effects, then congrats. Maybe you can be Wired's Man(?)-Of-The-Year.