cell phone companies plan on continuing to rake the money in from their analog networks
Not over here in Europe they're not. Analogue is extinct -- there's a bandwidth shortage and the last thing the operators want is to waste their valuable spectrum licences on the poor spectrum / profit ratio of analogue. There have even been trade-in bounty schemes on ETACS gear.
Last Xmas the UK had a massive surge in pre-paid SIM phones. They're a low capital outlay for a capable, but not leading-edge, GSM phone (display, SMS, lots of memories, voicemail, but nothing like data connectivity) and a regular purchase of top-up cards for the price of a few six-packs of beer. Now you can't look around a trailer park without seeing piles of these old pre-pay phones up on bricks.
I once worked in one of those things for a month. Yes, there were chaps in green outside guarding us with rifles and big dogs too.
Despite the fact that the Tempest shielding manual read awfully like Reich's instructions for building an Orgone Accumulator, I continually felt like crap. I never saw daylight, I breathed more ozone than orgone, and Navy issue coffee is the worst stuff anyone ever fed coders on.
When executing a CGI script, execution time is orders of magnitude faster than the network can pump the data out at. So the network is the bottleneck.
If your bottleneck is network lag, then you don't have a big enough hit rate, or enough simultaneous traffic. Serving static pages, sure. Big hairy-arsed database searches, with a myriad simultaneous connections ? - the backend maxes out long before the bandwidth does (unless you've hung Amazon off a dial-up line).
Seen from the server's side, the client's network bandwidth is effectively infinite -- If an individual user don't have enough bandwidth to grind you into the dirt, they'll gang up and do it to you in teams.
As far as I can tell, ASP is a Microsoft (boo!) proprietary thing
ASP is not only proprietary (as near as makes no difference), but it's also not a competitor for Perl, as it isn't a scripting language. ASP is an environment to run scripting languages in, not a language itself. ASP is closer to doing what CGI does, than it is to being a scripting language.
ASP's most common scripting language is VBSCript, followed by JScript. Now both of these are (shall we say) less-than-optimal as languages, but they're fine as a thin glue layer between COM objects and HTML responses. If you _need_ much more processing here, then you ought to be fattening up the back end services, not trying to do it with a scripting language.
My web site's database smarts are built in the finest-crafted hand-tweaked low-level code money can buy -- I use SQL Server (or Oracle). Can anyone really say that for heavyweight back-end performance of a complex task, they'd favour a piece of a scripting language knocked up in a weekend, compared to a proper database engine which has had gazillions spent on it ?
Perl and ASP ? no problem - use PerlScript (or RexxScript) and you get all the session state management stuff from ASP that you don't get from CGI.
I love ASP - I just wish I didn't have to host on NT to get it.
I'm puzzled, and worried, by what appears to be very vague wording, even for an intitial draft.
An electronic application requires either credit card details, or a digital signature. A requirement for these is an excluding measure, which removes web access from those citizens who don't have credit cards - it leads to an information-impoverished underclass, built from an already economically disadvantaged section of society.
Fortunately the paper-based application doesn't appear to require credit cards, as other proof of age is accepted. However, we then read that such applications may be invalidated if "credit transaction is not approved by relevant credit provider". Does this mean that credit cards are still required ? Does it mean that registration also requires a fee to be paid ? (and if not, who does fund this huge scheme ?)
We don't know what this is, and even the Mike Nash example doesn't make it clear. There's nothing visible on the M$oft site that clears this up, and I don't trust CNET's degree of technical literacy to understand the pedantic implications of it.
A logon to the NT Domain is clearly an authenticated connection and requires a CAL. Intranet users of NT servers - get your chequebooks out. What about a client-side certificate ? What about SSL ?
eCommerce is not going to be using NT Domain logons as an authentication mechanism. It was impossible to offer that to the public before and it was even most unlikely that it would be offered to a closed user community (my current project is doing this on an NT server, and we're using client side certificates).
As soon as anyone knows what the real position is with SSL and W2K, please post it. We don't care about charging for the Domain (that's fair) and only if M$oft are charging for SSL could this be reasonably regarded as a major foot-shoting.
If they've actually phrased it to include any 3rd party product that could be said to "authenticate" users on an open NT server, then it really is time to nuke Redmond from orbit.
The same sort of problem occurs on eBay (seller trustworthiness) and even more closely on Usenet (lying moron detection). Both have developed mechanisms to cope; eBay has a means of rating suppliers by the comments of previous purchasers, in some of the longer established Usenet virtual communities particular posters are known by their past contributions to be worthwhile sources of information.
Informarco will obviously need something similar. Whether this consists of consumer moderation by feedback, or by requiring all contributors to check in their PhDs at the door and to post liability bonds from their professional trade guild, remains to be seen. I don't think infomarco themselves know the answer to this - it depends on how their market develops and whether the most profitable market is in low-cost, low-risk, low-trust advice (such as consumer reviews) or in high-end advice from consulting architects and medics.
I would pay serious money for a system that allowed me to buy the time of professorial-grade knowledge, yet allowed me to buy it in half-hour chunks. I can often justify a single question to an acknowledged guru, but such a guru is only available for hire by the entire day.
$2500 is cheap when you see what's in an Aibo. Walking robots are very hard work, especially small, light and agile ones.
If you're interested in DIY robots, take a look at RobotWars. Major technology, homebrew construction and technical carnage. I don't know a serious team though that hasn't needed close to a $2500 budget, even buying much as scrap and not accounting for time.
Re:Just what the hell is that supposed to mean?
on
Which BSD?
·
· Score: 1
Linux is the "WinTel hardware world"?!?
I read that as "If you want wacky new Wintel devices, and you want the drivers to work, go with Linux". If you want to rejuvenate a weird old dinosaur, then use FreeBSD.
It's a positive statement about Linux, not a criticism of it.
ISP's can (technologically) very easily monitor and log every Internet packet
I disagree. I disagree very strongly about the "easy" part.
Compare the budget for an ISP in a cut-throat market, and the NSA. If you have the budget and the overall constraints of the NSA, then you can talk reasonably about logging everything in sight (although it's still not easy, in a rapidly expanding volume). If you're an ISP, then forget it. Go inside an ISP some time and see how difficult it is to simply keep core services on-line 24x7. The last thing any ISP wants to deal with is some packet level logging on all the traffic, and the horrendous data-mining task of putting those logs back together again afterwards.
if your ISP really wanted to [...] a manner much more efficient than by gleaming the data from proxy servers and cookies.
No, gleaning data from cookies is efficient, that's why they were invented. Gleaning data from raw IP-level logs is mind-numbingly hard work, and that's before you start dealing with DHCP and proxying on the client-side of the ISP (not uncommon for small businesses).
Try building a logging engine some time. Take the proxy logs from a small departmental web proxy and try writing some Perl that reconstructs a user's (single static IP) click trail across different sites. It's not easy, is it ? Now imagine what that's like when you have a much larger haystack to search for your needle. It's a scaling problem - when it gets to ISP volumes, then you just can't do it in any rational budget.
Now do the same thing with cookies available. Much, much easier. It's so much easier that it becomes a practical proposition.
Yes, it's technically possible to do all you claim - but so is nuclear fusion, and we still can't use that to keep the lights on.
Why would your ISP even *want* to construct such an intimately personal profile about you?
You are probably absolutely right.
You are possibly very wrong indeed. That is the crux of the privacy debate.
This isn't a useful time or place to explain why - if anyone who doesn't understand that difference already cares to find out why, then there are already many resources to read on the subject.
This sort of thing is made much harder due to the Data Protection Act
Oh come off it !
When has the DPA ever been more than a useless damp rag in the face of snooping ? It's fundamentally there to provide some registration of groups collecting data, not to control what they can collect. Enforcement of it has been farcically lax in the past.
Aside from which, the geographical scope of the DPA isn't much help on a WORLD Wide Web.
Time was when cookies just applied to a single site. What this fine article points out is that this is no longer true. The vendors of banner ads can now not only tell that I read Slashdot, but also that I read other sites AND they'll know that it's the same user agent who reads both Slashdot and UFO review, or who regularly reads content from 15 different sites about PalmPilots. This is much more commercially valuable information than simple being a Slashdot reader.
Weblog and magazine sites aren't the best place to sell banner ads. Lovely sites, but their catchment is just too broad. A real killer for banner ads would be technology that hits me with cigar ads on the prestigious Salon site, because it also knows that my browser visits regularly visits humidor.com.
Assuming that they'll do the things most profitable to them, chances are that the banner ad companies will use this information to send more specifically targetted banners. This isn't a bad thing overall. It probably means that when I read Slashdot in a year's time, I'll see the Linux banners replaced by golf club banners, because I'm not a Linux person but I do play an awful lot of golf. Is decoupling the banner ad from its host site context such a bad thing ? I think not.
Expect also to see cheap banner ad rates for small specialist sites like golf and cigars. They're not feeding the banners to make revenue, they're doing it to catch demographics. We're already seeing many kid's sites with on-line games, that are just there to catch information on who has kids and who is worth targetting with toy adverts. Imagine that being used to sell you kid's toys when you're browsing Slash, because months back it found you had a couple of pokemon-crazed offspring.
OTOH - If you're feeling paranoid, consider what a malicious ad server company could do with a cross reference of those browsers that regularly access both Church News and World Of Pron, or Accountancy Online and the Lose-Your-Shirt Casino. Remember too that "media" companies often extend from gutter tabloids to market research and new media companies. Now that makes me uneasy.
We need banner ads. They're a way of funding the Net from the disposable income of the WebTeeVee horde, so as to keep it cheap for those of the elite nerderati who have the ability to filter them.
Think of it as funding opera from lottery tickets 8-)
I'd agree with that, but let them know why you're doing it.
There's a general concensus here on/. that granting this type of unjustifiable patent is a bad thing, and that pursuing this type of patent is a particularly bad thing. Note also that Amazon have gone after another bookseller - that's not the action of an outraged innovator, that's just the nasty old (mainly American) business practice of throwing lawyers at your legitimate competitors.
I put all my work nerd-books through Amazon, and anyone who plays catch-up on the M$oft treadmill will know how much that amounts to. Slashdot, and the nerd virtual community as a whole, have considerable commercial leverage here.
Looks like a great idea for home-based browsers looking to verify themselves over the Web. The combination of physical device (the Palm) and biometrics (the scribble) are connected to the user's browser, and that connects to the vendor via the 'Net.
So what happens in a traditional walk-in shop ?
Do I walk in and sign the shop's Palm on the counter (losing the secure digital signature), or do I walk in carrying my own Palm and dock it into the shop's cradle ? As a retailer, I seem to be choosing between either rather poor security (scribble alone) or requiring all my customers to carry their own Palms. I can see this as an in-house application for workflow, quality control etc., but I can't see it affecting retailing in the near future.
Also (a minor point) what happens when a Palm dies and the signature is serialed to that Palm ? If yours hasn't croaked at least once, you've been lucky.
Good point. I'd forgotten Google and of course this is one of those instances where Google's algorithms (counting inbound links) works where webcrawlers simply cannot.
There's an article at http://webreview.com/pub/97/04/11/feature/part2.html about web design in general; chiefly why pervasive format-based markup is a bad thing (use CSS ASAP), but also about the problems of search engines finding their way through database and script driven sites.
So, how does this worthwhile piece stay preserved for all eternity, and somewhere it will be findable by future search engines. Is a basically transitory medium like Slashdot the best place, and is a script-driven site like Slashdot the best place to make it accessible (it's fairly webcrawler proof). Do postings like this need something more from the Slashdot mechanism ?
Didn't you get the Official Hacker Reading List along with your Cap'n Crunch decoder ring and the bandaid for your glasses ?
"Stuff to read" lists are an impossibly pompous notion. No worthwhile group would try to impose them, other than to reinforce some self-selecting clique of "People who read the right books / listen to the right music / wear the right clothes". Read Katz' Columbine High pieces for an indication of where that leads us.
Rather than studying a list, why not try to find some people of similar interests and read what they're reading ? When one of you finds a new author, spread the word.
Snow Crash is good, but I'm sure it's not a patch on a book to be published in the next couple of years by a writer none of us have yet heard of. Don't pick your reading from a static list, instead try and widen your catchment area. Thomas Moore was probably the last person who had the chance to read all the worthwhile books then available - these days we're all filter-feeders swimming through an ocean, catching a bare fraction of what's worth having. Work on this filter network and make it a communal effort. Maybe Slashdot is just the place to do it.
I have a friend who decided, around a decade ago, just what he wanted to read. He now owns more books than anyone else I know (and that's a lot) and is far less well read than most. Only things on his "list of interest" ever make it onto the shelves and nothing new ever changes there. It's like the library in "The Name of The Rose", only those texts by the ancient masters are deemed acceptable of study. He's even become an incredibly dull person to talk to, because every concept kicking around his head can be traced to a book on those shelves, and that's still only a small pool of what the world has to offer. This is a very bad way to choose your reading material.
OK, I give in. Most of the stuff the others have recommended, and Greg Egan for my personal pick.
Re:Best Part of Snow Crash
on
Snow Crash
·
· Score: 1
One of the best written opening chapters I've ever read.
eBusiness is going to be about B2B comms, not B2C (not quite there yet).
Customers are easy. They turn up at your site, all using nice predictable browsers. I'm sick of hearing some bunch of Mac-using Gustavs whinging and whining about needing to support both IE and Netscape as client UAs 8-)
The really awkward problem is supplier comms. How do you talk to suppliers when barely a tenth of them have EDI, EDI sucks dead bunnies through a straw anyway, their legacy platforms are all over the show and you can't even rely on workable tcp/ip comms to the machine room.
The holy grail of eCommerce at present is warehouseless trading; where orders are despatched to suppliers on a Just-In-Time basis, then turn up at UPS to be broken down off the pallets, packed into customer-sized boxes and then dispatched. The retailer doesn't need to own a distribution chain, and they don't need to pay for stockholding. Getting this to work right makes a huge difference to your bottom line figures and it all depends on good B2B comms engines.
We all love to flame M$oft, but if BizTalk works right, then I'd just love to talk to Bill about licensing deals over my soul.
Slashdot Mirror
cell phone companies plan on continuing to rake the money in from their analog networks
Not over here in Europe they're not. Analogue is extinct -- there's a bandwidth shortage and the last thing the operators want is to waste their valuable spectrum licences on the poor spectrum / profit ratio of analogue. There have even been trade-in bounty schemes on ETACS gear.
Last Xmas the UK had a massive surge in pre-paid SIM phones. They're a low capital outlay for a capable, but not leading-edge, GSM phone (display, SMS, lots of memories, voicemail, but nothing like data connectivity) and a regular purchase of top-up cards for the price of a few six-packs of beer. Now you can't look around a trailer park without seeing piles of these old pre-pay phones up on bricks.
I once worked in one of those things for a month. Yes, there were chaps in green outside guarding us with rifles and big dogs too.
Despite the fact that the Tempest shielding manual read awfully like Reich's instructions for building an Orgone Accumulator, I continually felt like crap. I never saw daylight, I breathed more ozone than orgone, and Navy issue coffee is the worst stuff anyone ever fed coders on.
watch them jump all over you.
Sorry to disappoint, but that's just electrostatic attraction 8-)
Even if the EHT doesn't get you, there's always the UV and the ozone.
When executing a CGI script, execution time is orders of magnitude faster than the network can pump the data out at. So the network is the bottleneck.
If your bottleneck is network lag, then you don't have a big enough hit rate, or enough simultaneous traffic. Serving static pages, sure. Big hairy-arsed database searches, with a myriad simultaneous connections ? - the backend maxes out long before the bandwidth does (unless you've hung Amazon off a dial-up line).
Seen from the server's side, the client's network bandwidth is effectively infinite -- If an individual user don't have enough bandwidth to grind you into the dirt, they'll gang up and do it to you in teams.
As far as I can tell, ASP is a Microsoft (boo!) proprietary thing
ASP is not only proprietary (as near as makes no difference), but it's also not a competitor for Perl, as it isn't a scripting language. ASP is an environment to run scripting languages in, not a language itself. ASP is closer to doing what CGI does, than it is to being a scripting language.
ASP's most common scripting language is VBSCript, followed by JScript. Now both of these are (shall we say) less-than-optimal as languages, but they're fine as a thin glue layer between COM objects and HTML responses. If you _need_ much more processing here, then you ought to be fattening up the back end services, not trying to do it with a scripting language.
My web site's database smarts are built in the finest-crafted hand-tweaked low-level code money can buy -- I use SQL Server (or Oracle). Can anyone really say that for heavyweight back-end performance of a complex task, they'd favour a piece of a scripting language knocked up in a weekend, compared to a proper database engine which has had gazillions spent on it ?
Perl and ASP ? no problem - use PerlScript (or RexxScript) and you get all the session state management stuff from ASP that you don't get from CGI.
I love ASP - I just wish I didn't have to host on NT to get it.
I'm puzzled, and worried, by what appears to be very vague wording, even for an intitial draft.
An electronic application requires either credit card details, or a digital signature. A requirement for these is an excluding measure, which removes web access from those citizens who don't have credit cards - it leads to an information-impoverished underclass, built from an already economically disadvantaged section of society.
Fortunately the paper-based application doesn't appear to require credit cards, as other proof of age is accepted. However, we then read that such applications may be invalidated if "credit transaction is not approved by relevant credit provider".
Does this mean that credit cards are still required ?
Does it mean that registration also requires a fee to be paid ? (and if not, who does fund this huge scheme ?)
First they vote to throw the Queen out, now they won't even let the citizens of the New Republic see her web site.
What is an authenticated conection ?
We don't know what this is, and even the Mike Nash example doesn't make it clear. There's nothing visible on the M$oft site that clears this up, and I don't trust CNET's degree of technical literacy to understand the pedantic implications of it.
A logon to the NT Domain is clearly an authenticated connection and requires a CAL.
Intranet users of NT servers - get your chequebooks out.
What about a client-side certificate ?
What about SSL ?
eCommerce is not going to be using NT Domain logons as an authentication mechanism. It was impossible to offer that to the public before and it was even most unlikely that it would be offered to a closed user community (my current project is doing this on an NT server, and we're using client side certificates).
As soon as anyone knows what the real position is with SSL and W2K, please post it. We don't care about charging for the Domain (that's fair) and only if M$oft are charging for SSL could this be reasonably regarded as a major foot-shoting.
If they've actually phrased it to include any 3rd party product that could be said to "authenticate" users on an open NT server, then it really is time to nuke Redmond from orbit.
The same sort of problem occurs on eBay (seller trustworthiness) and even more closely on Usenet (lying moron detection). Both have developed mechanisms to cope; eBay has a means of rating suppliers by the comments of previous purchasers, in some of the longer established Usenet virtual communities particular posters are known by their past contributions to be worthwhile sources of information.
Informarco will obviously need something similar. Whether this consists of consumer moderation by feedback, or by requiring all contributors to check in their PhDs at the door and to post liability bonds from their professional trade guild, remains to be seen. I don't think infomarco themselves know the answer to this - it depends on how their market develops and whether the most profitable market is in low-cost, low-risk, low-trust advice (such as consumer reviews) or in high-end advice from consulting architects and medics.
I would pay serious money for a system that allowed me to buy the time of professorial-grade knowledge, yet allowed me to buy it in half-hour chunks. I can often justify a single question to an acknowledged guru, but such a guru is only available for hire by the entire day.
famous Russian rocket scientist
Tsiolkovsky
How could it be anyone else ?
$2500 is cheap when you see what's in an Aibo. Walking robots are very hard work, especially small, light and agile ones.
If you're interested in DIY robots, take a look at RobotWars. Major technology, homebrew construction and technical carnage. I don't know a serious team though that hasn't needed close to a $2500 budget, even buying much as scrap and not accounting for time.
Linux is the "WinTel hardware world"?!?
I read that as "If you want wacky new Wintel devices, and you want the drivers to work, go with Linux". If you want to rejuvenate a weird old dinosaur, then use FreeBSD.
It's a positive statement about Linux, not a criticism of it.
ISP's can (technologically) very easily monitor and log every Internet packet
I disagree. I disagree very strongly about the "easy" part.
Compare the budget for an ISP in a cut-throat market, and the NSA. If you have the budget and the overall constraints of the NSA, then you can talk reasonably about logging everything in sight (although it's still not easy, in a rapidly expanding volume). If you're an ISP, then forget it. Go inside an ISP some time and see how difficult it is to simply keep core services on-line 24x7. The last thing any ISP wants to deal with is some packet level logging on all the traffic, and the horrendous data-mining task of putting those logs back together again afterwards.
if your ISP really wanted to [...] a manner much more efficient than by gleaming the data from proxy servers and cookies.
No, gleaning data from cookies is efficient, that's why they were invented. Gleaning data from raw IP-level logs is mind-numbingly hard work, and that's before you start dealing with DHCP and proxying on the client-side of the ISP (not uncommon for small businesses).
Try building a logging engine some time. Take the proxy logs from a small departmental web proxy and try writing some Perl that reconstructs a user's (single static IP) click trail across different sites. It's not easy, is it ? Now imagine what that's like when you have a much larger haystack to search for your needle. It's a scaling problem - when it gets to ISP volumes, then you just can't do it in any rational budget.
Now do the same thing with cookies available. Much, much easier. It's so much easier that it becomes a practical proposition.
Yes, it's technically possible to do all you claim - but so is nuclear fusion, and we still can't use that to keep the lights on.
Why would your ISP even *want* to construct such an intimately personal profile about you?
You are probably absolutely right.
You are possibly very wrong indeed.
That is the crux of the privacy debate.
This isn't a useful time or place to explain why - if anyone who doesn't understand that difference already cares to find out why, then there are already many resources to read on the subject.
This sort of thing is made much harder due to the Data Protection Act
Oh come off it !
When has the DPA ever been more than a useless damp rag in the face of snooping ? It's fundamentally there to provide some registration of groups collecting data, not to control what they can collect. Enforcement of it has been farcically lax in the past.
Aside from which, the geographical scope of the DPA isn't much help on a WORLD Wide Web.
Ignorance, fear and unjustified paranoia mainly.
Time was when cookies just applied to a single site. What this fine article points out is that this is no longer true. The vendors of banner ads can now not only tell that I read Slashdot, but also that I read other sites AND they'll know that it's the same user agent who reads both Slashdot and UFO review, or who regularly reads content from 15 different sites about PalmPilots. This is much more commercially valuable information than simple being a Slashdot reader.
Weblog and magazine sites aren't the best place to sell banner ads. Lovely sites, but their catchment is just too broad. A real killer for banner ads would be technology that hits me with cigar ads on the prestigious Salon site, because it also knows that my browser visits regularly visits humidor.com.
Assuming that they'll do the things most profitable to them, chances are that the banner ad companies will use this information to send more specifically targetted banners. This isn't a bad thing overall. It probably means that when I read Slashdot in a year's time, I'll see the Linux banners replaced by golf club banners, because I'm not a Linux person but I do play an awful lot of golf. Is decoupling the banner ad from its host site context such a bad thing ? I think not.
Expect also to see cheap banner ad rates for small specialist sites like golf and cigars. They're not feeding the banners to make revenue, they're doing it to catch demographics. We're already seeing many kid's sites with on-line games, that are just there to catch information on who has kids and who is worth targetting with toy adverts. Imagine that being used to sell you kid's toys when you're browsing Slash, because months back it found you had a couple of pokemon-crazed offspring.
OTOH - If you're feeling paranoid, consider what a malicious ad server company could do with a cross reference of those browsers that regularly access both Church News and World Of Pron, or Accountancy Online and the Lose-Your-Shirt Casino. Remember too that "media" companies often extend from gutter tabloids to market research and new media companies. Now that makes me uneasy.
We need banner ads. They're a way of funding the Net from the disposable income of the WebTeeVee horde, so as to keep it cheap for those of the elite nerderati who have the ability to filter them.
Think of it as funding opera from lottery tickets 8-)
I'd agree with that, but let them know why you're doing it.
There's a general concensus here on /. that granting this type of unjustifiable patent is a bad thing, and that pursuing this type of patent is a particularly bad thing. Note also that Amazon have gone after another bookseller - that's not the action of an outraged innovator, that's just the nasty old (mainly American) business practice of throwing lawyers at your legitimate competitors.
I put all my work nerd-books through Amazon, and anyone who plays catch-up on the M$oft treadmill will know how much that amounts to. Slashdot, and the nerd virtual community as a whole, have considerable commercial leverage here.
I'm still confused here....
Looks like a great idea for home-based browsers looking to verify themselves over the Web. The combination of physical device (the Palm) and biometrics (the scribble) are connected to the user's browser, and that connects to the vendor via the 'Net.
So what happens in a traditional walk-in shop ?
Do I walk in and sign the shop's Palm on the counter (losing the secure digital signature), or do I walk in carrying my own Palm and dock it into the shop's cradle ? As a retailer, I seem to be choosing between either rather poor security (scribble alone) or requiring all my customers to carry their own Palms. I can see this as an in-house application for workflow, quality control etc., but I can't see it affecting retailing in the near future.
Also (a minor point) what happens when a Palm dies and the signature is serialed to that Palm ? If yours hasn't croaked at least once, you've been lucky.
It'll never replace the tattooed barcode....
Good point. I'd forgotten Google and of course this is one of those instances where Google's algorithms (counting inbound links) works where webcrawlers simply cannot.
There's an article at http://webreview.com/pub/97/04 /11/feature/part2.html about web design in general; chiefly why pervasive format-based markup is a bad thing (use CSS ASAP), but also about the problems of search engines finding their way through database and script driven sites.
Excellent indeed.
So, how does this worthwhile piece stay preserved for all eternity, and somewhere it will be findable by future search engines. Is a basically transitory medium like Slashdot the best place, and is a script-driven site like Slashdot the best place to make it accessible (it's fairly webcrawler proof). Do postings like this need something more from the Slashdot mechanism ?
Didn't you get the Official Hacker Reading List along with your Cap'n Crunch decoder ring and the bandaid for your glasses ?
"Stuff to read" lists are an impossibly pompous notion. No worthwhile group would try to impose them, other than to reinforce some self-selecting clique of "People who read the right books / listen to the right music / wear the right clothes". Read Katz' Columbine High pieces for an indication of where that leads us.
Rather than studying a list, why not try to find some people of similar interests and read what they're reading ? When one of you finds a new author, spread the word.
Snow Crash is good, but I'm sure it's not a patch on a book to be published in the next couple of years by a writer none of us have yet heard of. Don't pick your reading from a static list, instead try and widen your catchment area. Thomas Moore was probably the last person who had the chance to read all the worthwhile books then available - these days we're all filter-feeders swimming through an ocean, catching a bare fraction of what's worth having. Work on this filter network and make it a communal effort. Maybe Slashdot is just the place to do it.
I have a friend who decided, around a decade ago, just what he wanted to read. He now owns more books than anyone else I know (and that's a lot) and is far less well read than most. Only things on his "list of interest" ever make it onto the shelves and nothing new ever changes there. It's like the library in "The Name of The Rose", only those texts by the ancient masters are deemed acceptable of study. He's even become an incredibly dull person to talk to, because every concept kicking around his head can be traced to a book on those shelves, and that's still only a small pool of what the world has to offer. This is a very bad way to choose your reading material.
OK, I give in. Most of the stuff the others have recommended, and Greg Egan for my personal pick.
One of the best written opening chapters I've ever read.
eBusiness is going to be about B2B comms, not B2C (not quite there yet).
Customers are easy. They turn up at your site, all using nice predictable browsers. I'm sick of hearing some bunch of Mac-using Gustavs whinging and whining about needing to support both IE and Netscape as client UAs 8-)
The really awkward problem is supplier comms. How do you talk to suppliers when barely a tenth of them have EDI, EDI sucks dead bunnies through a straw anyway, their legacy platforms are all over the show and you can't even rely on workable tcp/ip comms to the machine room.
The holy grail of eCommerce at present is warehouseless trading; where orders are despatched to suppliers on a Just-In-Time basis, then turn up at UPS to be broken down off the pallets, packed into customer-sized boxes and then dispatched. The retailer doesn't need to own a distribution chain, and they don't need to pay for stockholding. Getting this to work right makes a huge difference to your bottom line figures and it all depends on good B2B comms engines.
We all love to flame M$oft, but if BizTalk works right, then I'd just love to talk to Bill about licensing deals over my soul.