A truly sophisticated attacker could probably hit the number of aggregates limit, but that's a second order issue and is unlikely to happen with current tools (as long as source addresses are not used in filters, since they are usually faked).
My suggestion for using current tools would work only in a single provider - cooperation between providers would require an IETF standard, perhaps using BGP extensions to carry requests for filtering/limiting, or perhaps using a human-checkable format for these filtering.
Whether in a single provider or not, routers are clearly less likely to melt if you can push the filtering/limiting upstream, reducing pressure on router and bandwidth resources by acting as close to the source of attack as possible.
Universal ingress filtering should be mandatory - enterprises should demand it of providers, and vice versa. There is a good RFC discussing this, 2827 - see http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2827. html
I sometimes drive with a passenger who likes to talk to me continually, but particularly when I am just merging into a motorway lane at some speed, when I really need to concentrate. I have absolutely no idea why this is...
However, mobile phones can be very distracting too - it's very easy to pay too much attention to the phone, e.g. when listening to automated traffic reports that can't be paused. The same can probably happen if you are listening to someone and don't interrupt them for whatever reason.
I can never find anything very useful on the palm.com support site. I end up googling, particularly for newsgroup messages, to solve anything significant. An example of this is SUDS (Sudden USB Death Syndrome) on m500 series Palms - while Palm claim this only affects m505 with old cradles, this hit my Palm m515 with a new cradle. Palminfocenter.com provided a workaround that has worked so far, while Palm.com had nothing.
Mind you, this is generally true of most vendors - Internet support is so much better that you can often just bypass the official support. This is probably one reason why Linux has succeeded, because the lack of (as much) official vendor support doesn't really make much difference (and of course you can buy such support if you want it).
A BGP feed will only help if you want to drop ALL traffic to a given IP prefix - the ACC proposal actually lets you limit traffic by port number as well.
Also, a BGP-only solution would only let you drop traffic, so it's not very useful for flash crowds, where the traffic is legitimate but excessive. It's also not useful where the port / prefix etc can't precisely identify only DDoS traffic - rate limiting allows some good traffic to get through while also limiting the DDoS. Blackholing != limiting (did you read the paper at all?)
I agree that this can be prototyped using existing technology (see my post elsewhere), but if this approach proves useful, a dedicated protocol would be helpful - though this could perhaps be piggybacked onto BGP using additional attributes to carry the filter and rate limit information.
This is mainly laziness - there are tools to help you do this, from Expect-based scripts up to commercial router provisioning tools (which can also be used to activate IP VPNs and QoS).
As for router capacity - Junipers don't have this problem, and if the ISP manages the CPE router on the customer site they can just push it down to that device. On a Cisco, where you have symmetric routing (probably the case for most smaller customers i.e. not dual-homed), you can just set the IP reverse-path forwarding option, which is very efficient - on each packet, the router does a routing lookup on the *source* address, as if it was trying to send a packet back to its origin. If the routing table doesn't have an entry for that source address that points out via the interface the packet was received on, the source address has been forged. This is not much overhead at all - just one more routing lookup.
For dual-homed customers, the provider has to use ACLs or perhaps a managed CPE, but ideally this would be a selling point for the ISP helping to generate cash to pay for router upgrades if needed - it safeguards the customer's network from being used to generate DDoS attacks with forged source addresses, which could save the customer from a lawsuit.
That's not true of all such routers - as long as the number of aggregates to be filtered is fairly low, it shouldn't have too much impact. Most of the filtering should be on the routers at the edge of a given provider's network, which have less work to do than the true core routers - this is similar to the DiffServ QoS model except that the core routers don't need to do anything at all, since traffic is limited on the edges.
Juniper routers do this sort of filtering and policing in hardware, and can also generate traffic stats efficiently. Other vendors have similar features - Cisco 7500 routers can have multiple VIP processors, distributing the work down to the interface cards.
The main constraint is that you need new software written, installed and debugged in these routers, which will take time and require an agreed standard across router vendors. In the short term, it's easier to use existing features such as NetFlow/cflowd for traffic stats, feeding into an existing DDoS analysis tool (e.g. the Arbor Networks ones), which then tells a router provisioning tool to reconfigure the routers. This would not be as slick or dynamic as the proposed scheme, but could be done today. It would also make it possible to have a human in the loop initially, reviewing suggested changes. This would work OK as long as management and routing traffic are assigned a separate queue on each router interface, guaranteeing enough bandwidth to make these changes in the face of a DDoS attack (something that the ACC approach would also need).
There is some truth in what you say - certainly local loop ownership is a big reason why ILECs survived and CLECs didn't, particularly in the xDSL market where ILECs had a natural tendency to be slow and incompetent in integrating their provisioning processes with the CLEC (and benefited from not integrating well).
However, that doesn't explain why AT&T, Sprint and other long-distance telcos in the US, who don't have local loops, are doing OK (despite shrinking long-distance revenues) compared to many CLECs that offered (some of) its IP-based services. The answer IMO is that they have enough customers, revenues and sheer size to survive a downturn, and a diverse enough business that ISP-type services can become less profitable without sinking the company.
So I don't buy the conspiracy theory except in the local loop / xDSL arena. When downturns hit, it is usually the largest and most diverse companies that survive, in any industry.
Good point about ArrayComm - http://www.arraycomm.com/internetproducts/system.h tml gives a bit more detail but the size of their cells and the power consumption in mobile devices is unclear. It's possible it's not really a 3G competitor, since it may not be able to reach 3G phone battery consumption (but maybe it can in the future). Probably best to think of it as aimed at PDAs, laptops and other devices, whether at home, at work or out and about.
If you look at all the telcos of various types, it is the incumbents (RBOCs, Baby Bells, ILECs, PTTs...) who are surviving quite well and even prospering. They didn't get sucked into the IP-based boom/bust as much as others, and more importantly their legacy phone switches make significant money through well-established per-minute billing. Wireless operators who charge per-minute are also doing OK, although 3G will probably kill some of them off.
It's precisely the next-gen telcos (CLECs, ISPs, xSPs) who invested in the new IP technology that ran into the boom/bust and are struggling or going bust. WorldCom is something of a special case - it had a lot of legacy technology that should have tided it over, but the accounting shenanigans were too much to survive.
This doesn't mean that IP-based networks are a passing fad, though - all that's happened is that the pioneers have gone through the normal bleeding-edge live/die cycle. Some of them have made it, some have gone bust, and all the old-line telcos have adopted the same technologies.
I agree that failing telcos should normally not be propped up - as long as someone can step in to maintain services by buying up their assets, particularly local loops that are hard to recreate, the customer shouldn't notice that much interruption. My problem is with the analysis that the legacy technology is why telcos are going bust.
The journalist who wrote the article seems to be assuming there will be no payback at all from 3G, in its UMTS or CDMA2000 incarnations, to make a more exciting story. Some of the developments discussed aren't really competing in the same market as 3G in any case, e.g. the Arraycomm technology is mainly for fixed wireless last-mile access, and doesn't have much to do with 3G. The Flarion flash-OFDM approach is interesting, though.
While it may take a lot longer to get a payback than people planned, it's mainly a question of pricing and services. The real issue is delivering, at reasonable price points, services that are of interest, e.g. multimedia messaging (zap a photo to your friends/family), location-based services (where's the closest garage/ATM, and how do I get there?), multiplayer gaming (already happening with text messaging, one game lets you zap combatants who are in the same part of the physical world as you are), and much more. An open market for 3G services is critical, the idea being that anyone with a bright idea can put together their own service.
Of course, it doesn't make such a good story if telcos aren't 'scrambling' to fix 3G - in any case, these are all post-3G developments and will be competing with next-generation WiFi as well.
- it talks about red lights causing interference, even though 3G is far from 'immediately below infrared'...
- (real clue) talks about ultrasonic devices causing interference with 3G phones. How one earth can *sound* interfere with *electromagnetic radiation*???
How about a team of five people with PDAs only that want to edit and refer to online docs held on the HD. Or a bunch of people with laptops, where cabling to each laptop is not really an option - you either carry an Ethernet hub and patch cables, and find another power plug, or you carry a Bluetooth HD.
There are lots of other examples for PDA users who want to have a huge set of data with them (e.g. large databases, huge number of online books, MP3s, videos,...)
This is really intended as a personal device, just as Bluetooth enables personal area networks not LANs. While you can use the HD to serve local users, you might be better off with 802.11b, or just a server with a boring Ethernet connection to a WiFi access point. FTP would be a bit tedious IMO, you'd be better off having Samba/NFS or similar on the HD device so that all sorts of clients can access it, and using FTP only for devices that don't have file sharing support (e.g. most PDAs).
This would be useful for small teams of workers who have to arrive somewhere with laptops and PDAs, and be productive quickly - particularly since the HD should be a lot more reliable than Windows laptops:) Such a HD could store documentation for a whole set of large technical consulting projects, as well as a huge source tree and online reference manuals for development projects. Of course, backups become a big issue with this sort of data - you'd really need to have a USB/firewire connection and to be very disciplined about running backups every night. Or perhaps you could incrementally backup throughout the day via a Bluetooth access point to a server.
Good examples - with the right software, you could use your phone's UI from your laptop, to reconfigure things or whatever. Bluetooth phones already let you reconfigure a Bluetooth headset over the air, meaning the headset needs a minimal set of buttons and no display.
At that rate, the HD really needs USB/firewire as well so you can fill it up from a PC. This could still be useful once filled up - you could carry around a huge music collection and stream it to any Bluetooth device including your friends' MP3 players. Or you could have a huge database for some vertical application - the scary part is that you could mislay the disk with the database, so you'd need some serious encryption of all data stored, not just over the air...
Interesting setup, but Bluetooth is much faster at 700Kbps plus than CDMA2000 1x as used by Sprint PCS Vision (153 Kbps max, probably more like 50 Kbps in reality, and will fluctuate much more depending on distance from base station, radio interference, other users in cell, etc). CDMA2000 1xEV should do 2 Mbps but there will be similar caveats about fluctuating real-world bandwidth - and it's not deployed anywhere in the US.
Bluetooth is mainly a replacement for cables used to connect peripherals, but it's also convenient for ad hoc networking (beaming stuff to other people without the point-and-squint infrared hassles).
It would make more sense to have a 1 GB flash drive with Bluetooth, since battery drain is a problem. But if you have a big enough battery, a hard drive is quite useful, and the idea of having data available to various devices is a good one.
It's entertaining how the component parts of a laptop are fragmenting out into separate devices to some extent - e.g. PDA (small version of laptop screen+keyboard), mobile phone (like a modem), hard drive, etc. A bit like the mecha's shuttle craft near the end of 'AI'...
Thanks - I downloaded the update (for HotSync 4.0.1) and installed it even though I had 4.0.2. At the time of install, the hotsync was working, so it's hard to tell if this did anything - I suspect not, as the example of timeout given related to AvantGo etc, and I don't see how a Hotsync upgrade on the PC could make the USB chip in the Palm work.
One symptom of a working Palm (after battery drain) is that my PC (Win2K) discovers it as a new USB device, before Hotsync gets a chance to look at it.
Very interesting - had another look on the Palm.com site and on Palminfocenter.com, but couldn't find anything new. The Palm position is stated at http://www.palm.com/support/m50XUSBcradle.html - i.e. they say it only happens on m500/m505s with the old cradles. However, searching for 'palm usb timeout m515' and clicking on the PalmInfocenter link shows the real situation, i.e. that this can happen to m515s even with the new cradle.
If you could find the link, it would be much appreciated, as I can't find a software fix. It would need to be something that downloads onto the device - I already reinstalled the Hotsync software and the 'drain battery then restore from SD card' fix worked fine, so it's not on the PC side.
The only fix I know about is to replace the m515, and the only workaround is to drain the battery when it happens (twice in the last week or so).
There's an interesting book at http://www.winface.com that looks at how to re-orient a whole IT department from Windows to Unix/Linux. It's mainly about using Unix, but Linux gives the same advantages, only even more so due to improved compatibility across Linuxes compared to the various Unixes, and much lower licensing costs, lower hardware costs for Intel deployments and so on. The book has some annoying errors in places, but the guts of it are very useful for costing out complete deployments of Windows vs. Unix, for small through medium to enterprise scales.
You can download some parts of the book for free to get a flavour of what it's about. I actually bought a copy and would recommend it for anyone thinking about converting from Windows to Linux - it's only $30.
Good thing you're not massively biased against Palm, eh?
- I have a colour m515 and the screen is much clearer even for mono text than my old mono Palms/Handsprings. I don't really care too much about battery life, I just charge it every few days. As long as I don't go into the wilderness for days on end it's not a problem (and if I did, why would I need a Palm?)
- I've not had any problems with cradle drain
- wireless is dependent on roll-out of GPRS, CDMA2000, and WiFi, and on uptake of Bluetooth mobile phones. Palm can't do much about those, wireless has not taken off big-time on PocketPC either.
- SD/MMC works just fine in non-secure mode to store ordinary date - SD is about 4x faster than MMC, smaller than Compact Flash, can do I/O cards (with SDIO, like CF), and is non-proprietary and low-cost (unlike Memory Stick). I'm a technophile and I don't despise it - speak for yourself.
- m130 with non-upgradeable hardware (presumably you mean the OS is not in flash) - I prefer flashable devices myself, so here I would agree with you, but every Handspring before the Treo line was non-flash and they seemed to do OK.
I am not a huge Palm fan (currently trying to work around the sudden USB death syndrome that is not meant to affect m515s but does, stopping hotsync from working), and they have produced less exciting products than Sony, but they have done some things right, which is why I got an m515.
See http://www.ripe.net/ripencc/about/presentations/ri pencc-ietf-ec/ for a presentation about ENUM. The interesting part is that it lets you take a phone number and map it to one or more URLs of the form mailto:foo@example.com, sip:foo@example.com (for VoIP and conferencing), http://blah, etc.
Since the phone number space is relatively constrained in many countries and cities (e.g. London in the UK has changed its number space twice in the last decade), phone numbers are not an ideal solution to 'throwaway' numbers to give to potential telemarketers, but ENUM could help in theory.
My idea was that you would have a number of email and SIP addresses, some only given to friends/family, some published on websites, and some given to companies that may resell these addresses without your permission. This last set of addresses can be dropped rapidly as and when spammers get hold of them, exactly as some people do today with email addresses.
ENUM comes in as a way of mapping phone numbers to these more flexible email/SIP addresses - you have a 'private' ENUMed phone number, ideally ex directory, that maps to the friends/family address, and another for companies, and so on. You can change this mapping quite rapidly.
Where ENUM is weak is that it discloses the actual SIP and email addresses used (as it has to). So anybody who caches the old addresses can continue to spam you, which is why you need to have more then one ENUM phone number.
Overall, ENUM makes it easier to spam people (no surprise), but I thought I would at least explore if it could be used for anti-spam purposes... The weakness is that the number-to-address translation is made available to the client - this is the virtually unavoidable result of using a directory service to implement this mapping. Something like a forwarding service for SIP and email would be much more useful - i.e. it gateways from a public SIP/email address into a secret address, meaning that when the mapping changes the spammer is left with a useless address.
Overall, I think ENUM is primarily useful for legacy reasons, since so many people know about phone numbers (ditto for equipment). What would be more useful is to enable phones to understand SIP URLs and email addresses (latter is already happening with mobile phones, and SIP will arrive in later versions of UMTS 3G mobile phones in Europe/Asia), and have a forwarding service as mentioned.
There are lots of dead Wikis on the Net, just as there are lots of dead static websites. Lots of Wiki usage is within intranets, where it is often successful because people really need to share information of various types that is not highly structured. Some of these Wiki sites have upwards of five hundred users and thousands of pages.
The original Portland Patterns Repository wiki, by Ward Cunningham, is one example of a public Wiki that remains quite active.
I'm trying for a replacement phone but unfortunately I bought it on a UK network that doesn't make this easy. I usually get phones through Orange who have an excellent replacement policy as part of their insurance deal (free in the first year) - you just get a new phone by courier and send the old one back.
Since you are coming from VB, I would try Python, which is supported 'in-the-box' by wxWindows' wxPython piece. Personally, I prefer Perl, but Python has a much cleaner syntax and will be easier to get into. There is a huge array of third party modules for Python, and they are all free - however, if you are using commercial VB controls you may find some bits are missing.
The one issue to beware of is speed - however, if you prototype your application in wxPython, you can then switch to wxWindows and C++ for any parts that are performance critical (in fact they may not even be GUI related). However, if you are using VB, I'd imagine that Python give similar performance.
Slashdot Mirror
A truly sophisticated attacker could probably hit the number of aggregates limit, but that's a second order issue and is unlikely to happen with current tools (as long as source addresses are not used in filters, since they are usually faked).
. html
My suggestion for using current tools would work only in a single provider - cooperation between providers would require an IETF standard, perhaps using BGP extensions to carry requests for filtering/limiting, or perhaps using a human-checkable format for these filtering.
Whether in a single provider or not, routers are clearly less likely to melt if you can push the filtering/limiting upstream, reducing pressure on router and bandwidth resources by acting as close to the source of attack as possible.
Universal ingress filtering should be mandatory - enterprises should demand it of providers, and vice versa. There is a good RFC discussing this, 2827 - see http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2827
I sometimes drive with a passenger who likes to talk to me continually, but particularly when I am just merging into a motorway lane
at some speed, when I really need to concentrate. I have absolutely no idea why this is...
However, mobile phones can be very distracting too - it's very easy to pay too much attention to the phone, e.g. when listening to automated traffic reports that can't be paused. The same can probably happen if you are listening to someone and don't interrupt them for whatever reason.
I can never find anything very useful on the palm.com support site. I end up googling, particularly for newsgroup messages, to solve anything significant. An example of this is SUDS (Sudden USB Death Syndrome) on m500 series Palms - while Palm claim this only affects m505 with old cradles, this hit my Palm m515 with a new cradle. Palminfocenter.com provided a workaround that has worked so far, while Palm.com had nothing.
Mind you, this is generally true of most vendors - Internet support is so much better that you can often just bypass the official support. This is probably one reason why Linux has succeeded, because the lack of (as much) official vendor support doesn't really make much difference (and of course you can buy such support if you want it).
A BGP feed will only help if you want to drop ALL traffic to a given IP prefix - the ACC proposal actually lets you limit traffic by port number as well.
Also, a BGP-only solution would only let you drop traffic, so it's not very useful for flash crowds, where the traffic is legitimate but excessive. It's also not useful where the port / prefix etc can't precisely identify only DDoS traffic - rate limiting allows some good traffic to get through while also limiting the DDoS. Blackholing != limiting (did you read the paper at all?)
I agree that this can be prototyped using existing technology (see my post elsewhere), but if this approach proves useful, a dedicated protocol would be helpful - though this could perhaps be piggybacked onto BGP using additional attributes to carry the filter and rate limit information.
This is mainly laziness - there are tools to help you do this, from Expect-based scripts up to commercial router provisioning tools (which can also be used to activate IP VPNs and QoS).
As for router capacity - Junipers don't have this problem, and if the ISP manages the CPE router on the customer site they can just push it down to that device. On a Cisco, where you have symmetric routing (probably the case for most smaller customers i.e. not dual-homed), you can just set the IP reverse-path forwarding option, which is very efficient - on each packet, the router does a routing lookup on the *source* address, as if it was trying to send a packet back to its origin. If the routing table doesn't have an entry for that source address that points out via the interface the packet was received on, the source address has been forged. This is not much overhead at all - just one more routing lookup.
For dual-homed customers, the provider has to use ACLs or perhaps a managed CPE, but ideally this would be a selling point for the ISP helping to generate cash to pay for router upgrades if needed - it safeguards the customer's network from being used to generate DDoS attacks with forged source addresses, which could save the customer from a lawsuit.
That's not true of all such routers - as long as the number of aggregates to be filtered is fairly low, it shouldn't have too much impact. Most of the filtering should be on the routers at the edge of a given provider's network, which have less work to do than the true core routers - this is similar to the DiffServ QoS model except that the core routers don't need to do anything at all, since traffic is limited on the edges.
Juniper routers do this sort of filtering and policing in hardware, and can also generate traffic stats efficiently. Other vendors have similar features - Cisco 7500 routers can have multiple VIP processors, distributing the work down to the interface cards.
The main constraint is that you need new software written, installed and debugged in these routers, which will take time and require an agreed standard across router vendors. In the short term, it's easier to use existing features such as NetFlow/cflowd for traffic stats, feeding into an existing DDoS analysis tool (e.g. the Arbor Networks ones), which then tells a router provisioning tool to reconfigure the routers. This would not be as slick or dynamic as the proposed scheme, but could be done today. It would also make it possible to have a human in the loop initially, reviewing suggested changes. This would work OK as long as management and routing traffic are assigned a separate queue on each router interface, guaranteeing enough bandwidth to make these changes in the face of a DDoS attack (something that the ACC approach would also need).
There is some truth in what you say - certainly local loop ownership is a big reason why ILECs survived and CLECs didn't, particularly in the xDSL market where ILECs had a natural tendency to be slow and incompetent in integrating their provisioning processes with the CLEC (and benefited from not integrating well).
However, that doesn't explain why AT&T, Sprint and other long-distance telcos in the US, who don't have local loops, are doing OK (despite shrinking long-distance revenues) compared to many CLECs that offered (some of) its IP-based services. The answer IMO is that they have enough customers, revenues and sheer size to survive a downturn, and a diverse enough business that ISP-type services can become less profitable without sinking the company.
So I don't buy the conspiracy theory except in the local loop / xDSL arena. When downturns hit, it is usually the largest and most diverse companies that survive, in any industry.
Good point about ArrayComm - http://www.arraycomm.com/internetproducts/system.h tml gives a bit more detail but the size of their cells and the power consumption in mobile devices is unclear. It's possible it's not really a 3G competitor, since it may not be able to reach 3G phone battery consumption (but maybe it can in the future). Probably best to think of it as aimed at PDAs, laptops and other devices, whether at home, at work or out and about.
If you look at all the telcos of various types, it is the incumbents (RBOCs, Baby Bells, ILECs, PTTs...) who are surviving quite well and even prospering. They didn't get sucked into the IP-based boom/bust as much as others, and more importantly their legacy phone switches make significant money through well-established per-minute billing. Wireless operators who charge per-minute are also doing OK, although 3G will probably kill some of them off.
It's precisely the next-gen telcos (CLECs, ISPs, xSPs) who invested in the new IP technology that ran into the boom/bust and are struggling or going bust. WorldCom is something of a special case - it had a lot of legacy technology that should have tided it over, but the accounting shenanigans were too much to survive.
This doesn't mean that IP-based networks are a passing fad, though - all that's happened is that the pioneers have gone through the normal bleeding-edge live/die cycle. Some of them have made it, some have gone bust, and all the old-line telcos have adopted the same technologies.
I agree that failing telcos should normally not be propped up - as long as someone can step in to maintain services by buying up their assets, particularly local loops that are hard to recreate, the customer shouldn't notice that much interruption. My problem is with the analysis that the legacy technology is why telcos are going bust.
The journalist who wrote the article seems to be assuming there will be no payback at all from 3G, in its UMTS or CDMA2000 incarnations, to make a more exciting story. Some of the developments discussed aren't really competing in the same market as 3G in any case, e.g. the Arraycomm technology is mainly for fixed wireless last-mile access, and doesn't have much to do with 3G. The Flarion flash-OFDM approach is interesting, though.
While it may take a lot longer to get a payback than people planned, it's mainly a question of pricing and services. The real issue is delivering, at reasonable price points, services that are of interest, e.g. multimedia messaging (zap a photo to your friends/family), location-based services (where's the closest garage/ATM, and how do I get there?), multiplayer gaming (already happening with text messaging, one game lets you zap combatants who are in the same part of the physical world as you are), and much more. An open market for 3G services is critical, the idea being that anyone with a bright idea can put together their own service.
Of course, it doesn't make such a good story if telcos aren't 'scrambling' to fix 3G - in any case, these are all post-3G developments and will be competing with next-generation WiFi as well.
Given the number of anti-Telstra stories on that site, I'd advise Simon and Dan to be very careful how they open any bag from Telstra :)
Some clues that the parent message is crap:
- it talks about red lights causing interference, even though 3G is far from 'immediately below infrared'...
- (real clue) talks about ultrasonic devices causing interference with 3G phones. How one earth can *sound* interfere with *electromagnetic radiation*???
How about a team of five people with PDAs only that want to edit and refer to online docs held on the HD. Or a bunch of people with laptops, where cabling to each laptop is not really an option - you either carry an Ethernet hub and patch cables, and find another power plug, or you carry a Bluetooth HD.
...)
There are lots of other examples for PDA users who want to have a huge set of data with them (e.g. large databases, huge number of online books, MP3s, videos,
This is really intended as a personal device, just as Bluetooth enables personal area networks not LANs. While you can use the HD to serve local users, you might be better off with 802.11b, or just a server with a boring Ethernet connection to a WiFi access point. FTP would be a bit tedious IMO, you'd be better off having Samba/NFS or similar on the HD device so that all sorts of clients can access it, and using FTP only for devices that don't have file sharing support (e.g. most PDAs).
:) Such a HD could store documentation for a whole set of large technical consulting projects, as well as a huge source tree and online reference manuals for development projects. Of course, backups become a big issue with this sort of data - you'd really need to have a USB/firewire connection and to be very disciplined about running backups every night. Or perhaps you could incrementally backup throughout the day via a Bluetooth access point to a server.
This would be useful for small teams of workers who have to arrive somewhere with laptops and PDAs, and be productive quickly - particularly since the HD should be a lot more reliable than Windows laptops
Good examples - with the right software, you could use your phone's UI from your laptop, to reconfigure things or whatever. Bluetooth phones already let you reconfigure a Bluetooth headset over the air, meaning the headset needs a minimal set of buttons and no display.
At that rate, the HD really needs USB/firewire as well so you can fill it up from a PC. This could still be useful once filled up - you could carry around a huge music collection and stream it to any Bluetooth device including your friends' MP3 players. Or you could have a huge database for some vertical application - the scary part is that you could mislay the disk with the database, so you'd need some serious encryption of all data stored, not just over the air...
Interesting setup, but Bluetooth is much faster at 700Kbps plus than CDMA2000 1x as used by Sprint PCS Vision (153 Kbps max, probably more like 50 Kbps in reality, and will fluctuate much more depending on distance from base station, radio interference, other users in cell, etc). CDMA2000 1xEV should do 2 Mbps but there will be similar caveats about fluctuating real-world bandwidth - and it's not deployed anywhere in the US.
Bluetooth is mainly a replacement for cables used to connect peripherals, but it's also convenient for ad hoc networking (beaming stuff to other people without the point-and-squint infrared hassles).
It would make more sense to have a 1 GB flash drive with Bluetooth, since battery drain is a problem. But if you have a big enough battery, a hard drive is quite useful, and the idea of having data available to various devices is a good one.
It's entertaining how the component parts of a laptop are fragmenting out into separate devices to some extent - e.g. PDA (small version of laptop screen+keyboard), mobile phone (like a modem), hard drive, etc. A bit like the mecha's shuttle craft near the end of 'AI'...
Thanks - I downloaded the update (for HotSync 4.0.1) and installed it even though I had 4.0.2. At the time of install, the hotsync was working, so it's hard to tell if this did anything - I suspect not, as the example of timeout given related to AvantGo etc, and I don't see how a Hotsync upgrade on the PC could make the USB chip in the Palm work.
One symptom of a working Palm (after battery drain) is that my PC (Win2K) discovers it as a new USB device, before Hotsync gets a chance to look at it.
Still, thanks for the URL, it was worth a try!
Very interesting - had another look on the Palm.com site and on Palminfocenter.com, but couldn't find anything new. The Palm position is stated at http://www.palm.com/support/m50XUSBcradle.html - i.e. they say it only happens on m500/m505s with the old cradles. However, searching for 'palm usb timeout m515' and clicking on the PalmInfocenter link shows the real situation, i.e. that this can happen to m515s even with the new cradle.
If you could find the link, it would be much appreciated, as I can't find a software fix. It would need to be something that downloads onto the device - I already reinstalled the Hotsync software and the 'drain battery then restore from SD card' fix worked fine, so it's not on the PC side.
The only fix I know about is to replace the m515, and the only workaround is to drain the battery when it happens (twice in the last week or so).
There's an interesting book at http://www.winface.com that looks at how to re-orient a whole IT department from Windows to Unix/Linux. It's mainly about using Unix, but Linux gives the same advantages, only even more so due to improved compatibility across Linuxes compared to the various Unixes, and much lower licensing costs, lower hardware costs for Intel deployments and so on. The book has some annoying errors in places, but the guts of it are very useful for costing out complete deployments of Windows vs. Unix, for small through medium to enterprise scales.
You can download some parts of the book for free to get a flavour of what it's about. I actually bought a copy and would recommend it for anyone thinking about converting from Windows to Linux - it's only $30.
Good thing you're not massively biased against Palm, eh?
- I have a colour m515 and the screen is much clearer even for mono text than my old mono Palms/Handsprings. I don't really care too much about battery life, I just charge it every few days. As long as I don't go into the wilderness for days on end it's not a problem (and if I did, why would I need a Palm?)
- I've not had any problems with cradle drain
- wireless is dependent on roll-out of GPRS, CDMA2000, and WiFi, and on uptake of Bluetooth mobile phones. Palm can't do much about those, wireless has not taken off big-time on PocketPC either.
- SD/MMC works just fine in non-secure mode to store ordinary date - SD is about 4x faster than MMC, smaller than Compact Flash, can do I/O cards (with SDIO, like CF), and is non-proprietary and low-cost (unlike Memory Stick). I'm a technophile and I don't despise it - speak for yourself.
- m130 with non-upgradeable hardware (presumably you mean the OS is not in flash) - I prefer flashable devices myself, so here I would agree with you, but every Handspring before the Treo line was non-flash and they seemed to do OK.
I am not a huge Palm fan (currently trying to work around the sudden USB death syndrome that is not meant to affect m515s but does, stopping hotsync from working), and they have produced less exciting products than Sony, but they have done some things right, which is why I got an m515.
See http://www.ripe.net/ripencc/about/presentations/ri pencc-ietf-ec/ for a presentation about ENUM. The interesting part is that it lets you take a phone number and map it to one or more URLs of the form mailto:foo@example.com, sip:foo@example.com (for VoIP and conferencing), http://blah, etc.
Since the phone number space is relatively constrained in many countries and cities (e.g. London in the UK has changed its number space twice in the last decade), phone numbers are not an ideal solution to 'throwaway' numbers to give to potential telemarketers, but ENUM could help in theory.
My idea was that you would have a number of email and SIP addresses, some only given to friends/family, some published on websites, and some given to companies that may resell these addresses without your permission. This last set of addresses can be dropped rapidly as and when spammers get hold of them, exactly as some people do today with email addresses.
ENUM comes in as a way of mapping phone numbers to these more flexible email/SIP addresses - you have a 'private' ENUMed phone number, ideally ex directory, that maps to the friends/family address, and another for companies, and so on. You can change this mapping quite rapidly.
Where ENUM is weak is that it discloses the actual SIP and email addresses used (as it has to). So anybody who caches the old addresses can continue to spam you, which is why you need to have more then one ENUM phone number.
Overall, ENUM makes it easier to spam people (no surprise), but I thought I would at least explore if it could be used for anti-spam purposes... The weakness is that the number-to-address translation is made available to the client - this is the virtually unavoidable result of using a directory service to implement this mapping. Something like a forwarding service for SIP and email would be much more useful - i.e. it gateways from a public SIP/email address into a secret address, meaning that when the mapping changes the spammer is left with a useless address.
Overall, I think ENUM is primarily useful for legacy reasons, since so many people know about phone numbers (ditto for equipment). What would be more useful is to enable phones to understand SIP URLs and email addresses (latter is already happening with mobile phones, and SIP will arrive in later versions of UMTS 3G mobile phones in Europe/Asia), and have a forwarding service as mentioned.
There are lots of dead Wikis on the Net, just as there are lots of dead static websites. Lots of Wiki usage is within intranets, where it is often successful because people really need to share information of various types that is not highly structured. Some of these Wiki sites have upwards of five hundred users and thousands of pages.
The original Portland Patterns Repository wiki, by Ward Cunningham, is one example of a public Wiki that remains quite active.
I'm trying for a replacement phone but unfortunately I bought it on a UK network that doesn't make this easy. I usually get phones through Orange who have an excellent replacement policy as part of their insurance deal (free in the first year) - you just get a new phone by courier and send the old one back.
Since you are coming from VB, I would try Python, which is supported 'in-the-box' by wxWindows' wxPython piece. Personally, I prefer Perl, but Python has a much cleaner syntax and will be easier to get into. There is a huge array of third party modules for Python, and they are all free - however, if you are using commercial VB controls you may find some bits are missing.
The one issue to beware of is speed - however, if you prototype your application in wxPython, you can then switch to wxWindows and C++ for any parts that are performance critical (in fact they may not even be GUI related). However, if you are using VB, I'd imagine that Python give similar performance.