SMS on a Palm is much nicer than a phone in any case, even Graffiti beats thumb-keying - I use the free GSMtool at present on a Palm + Ericsson T68 and it works well.
Do you know how many GPRS slots you get with the version you have, up and down? Failing that, do you know what data rates you get?
One key reason to get an integrated device is that the Palm to Phone link will always work - getting separate devices to work is a bit of a nightmare, even though I have IRDA working.
You can get a version without the keyboard, but I suspect I'll get the keyboard one just to make email and SMSing easier, even though I've used Graffiti for some time now. I doubt if there's any more scrolling, as Palm-compatible screens are always 160x160 (or double in some cases) - more squinting though...
I have voice dialling in my Ericsson phone and I never use it, but then being a Euroid living in LondonI don't drive as much as some people:)
As for having to activate dialup and get an ISP - that's a feature of the service, not the phone. The 9600 bps connection may also be a service issue, it depends on the GSM network I think.
GSM may not be useful where you live, but it works well around the rest of the world. I'll wait for the GPRS-enabled version (although one UK poster on this thread says he has been using that version for 2 weeks) so I can get always-on and about 40-50 Kbits/sec. Does anybody know how many GPRS slots the GPRS version has, up and down?
Really it's horses for courses - if you prefer CDMA service for where you live/travel, go for the Kyocera (though I think Handspring have a deal with Qualcomm to do a CDMA product in the future). If you prefer GSM, go for the Treo.
I'm sceptical about the compression, but it should improve things given image downscaling (Plucker and AvantGo do the same thing on Palms). As for your GPRS comment - the Pogo is a GPRS device, so it's not exactly going to be 'killed by GPRS...'
Re:Same thing, other side of the border
on
Is Hyperchip Hype?
·
· Score: 2
Quite a few vendors are emulating the Cisco IOS command line interface on completely new hardware - e.g. Unisphere and Foundry in the US, and Huawei in China (who produce Cisco clones at 10% of Cisco prices...) Emulating the CLI can be done on any size of router, of course.
I doubt there will be many bits of BeOS used in PalmOS 5.0 - as you say, Palm started working on 5.0 before buying Be, and Palm have said publicly that they bought Be for its packaging technology and its developers.
The best hope for BeOS is that Palm licenses it on reasonable terms. I'd never heard of Yellow Tab in earlier Be discussions, so I'd be interested to hear how it got a license, though.
All this excitement about licensing and the death or continued life of BeOS does go to show that if you want a dull life, you should use an open source OS - it will just be there, quietly being enhanced and bugfixed, while companies are born and die around it:)
ACKs are sent for every TCP segment received (i.e. a TCP packet) not per window. I was assuming that the window size is sufficiently large to allow transfers to go at full speed - this should be no problem with broadband connections as they are quite low latency in any case. So TCP windows are not really relevant here.
Upstream caps *will* limit TCP download speed to 4.8 Mbps in this case - maybe you mean UDP protocols in your 2nd paragraph. UDP-based protocols may or may not have congestion control (i.e. backing off when they sense packet loss or excessive delays) - the ones without congestion control and rate adaptation let you select the stream with the right rate, but this is quite unnecessary if the protocol is designed to sense bandwidth and select the correct media stream.
All this is fairly theoretical unless you are downloading from a very well-connected server that is quite close by (e.g. hosted by your ISP). I've rarely managed to get the full 1 Mbps when using real web/FTP sites with my ADSL connection.
There's no problem with using RFC1918 on internal interfaces - however, it would be better to configure the routers so they use a publicly addressable loopback interface as the source address of ICMP packets that they generate. In other words, this would prevent the 10.x address from appearing (and perhaps prevent some paranoid routers from dropping the ICMP packet from that router). Of course, the long term solution is to implement IPv6 before the combined weight of IPv4 workarounds/cruft sinks the Internet...
This sounds plausible given the limited upstream cable bandwidth per segment, explained elsewhere. If you have 128 Kbps upstream bandwidth, TCP downloads (not UDP) are limited to approx 4.8 Mbps (just multiply upstream by 37.5 to calculate the max TCP downstream bandwidth). The details are at http://slashdot.org/comments.pl?sid=25234&cid=2743 853
Doesn't have to be extra-terrestrial
on
The Euro
·
· Score: 2
You are ignoring the threat of non-state actors such as al Qa'ida, who are enough of a threat to governments all round the world that they are one driver for global cooperation and (perhaps) ultimately world governance - see http://www.nonzero.org/terror.htm for more discussion of this. As technology makes it easier and cheaper for almost anybody to kill large numbers of people, global cooperation will become essential to counteract this.
Re:Are we becoming like star trek?
on
The Euro
·
· Score: 2
The US and all other industrialised countries are highly interdependent with poorer countries, for trade reasons and more importantly because technology and suicide terrorism has made it possible for terrorists to inflict huge casualties on developed countries at a very low cost. Read www.nonzero.org - the book on which this site is based was written before Sept 11, and included the prediction that by 2020 a terrorist will be able to kill 50,000 people in a Western city using bioterrorism. Because we are so interdependent with developing countries, we simply have to pay attention to reducing the pool of disaffected haters of the US and other developing countries - only by reducing the support for terrorism will we reduce the frequency of such acts. Of course, you also need to go after the terrorists themselves, but in a way that doesn't further increase their support (see the essay about how many Afghan civilian casualties are acceptable in US eyes...).
By the way, Britain is part of the EU and is going to join the Euro in the next few years - we have no alternative really, given that inward investment is already beginning to divert to the Euro zone for economic reasons. I don't think it makes any sense for the US to join the EU, but it's quite possible that NAFTA will deepen to become somewhat like the EU, and perhaps add Latin American members as well.
Sovereign nations were invented about 500 years ago - before that, we had city states. There's no reason why they can't be (largely) superseded by larger groupings, though IMO the nation state will survive in some form for a long time, as part of supranational groupings. The protection of human rights in the US comes from the constitution, but also from the courts throwing out unconstitutional laws (which doesn't seem to be happening with recent anti-terrorism legislation). The EU has its own Human Rights legislation and a court dedicated to such cases - by joining the EU and adopting this legislation, the UK (which has no written constitution) has actually improved the human rights position for its citizens. I'm not a big fan of the EU (it tends to be overly bureaucratic, typical 'big government') but it is economically sensible and overall is doing a reasonable job.
Re:Are we becoming like star trek?
on
The Euro
·
· Score: 2
I've just read Non-Zero, by Robert Wright, which explains how the size of groupings has grown over the millenia (from hunter-gatherer bands to villages, chiefdoms, kingdoms and now nation states) - this is all driven by the benefits of cooperating with other groups for the purposes of hunting, farming, trade, etc, and by the need to defend or attack others by allying with nearby groups. His approach is to apply game theory (zero-sum vs. non-zero sum games) and a scientific outlook to explaining the big picture of history - as someone who hated history at school for its arbitrariness, I find this 'unified theory' approach very appealing. See www.nonzero.org for the author's website, which includes excerpts from most chapters.
The nation state is a relatively recent invention (about 500 years old) - since there are various free trade areas that are similar to the earlier stages of what is now the European Union (e.g. the Gulf Cooperation Council is a free-trade area that plans to have a single currency in 2010), it's not unreasonable to expect many nation states to be subsumed into something close to a 'world government'. Clearly this is something that must be done right (a despotic world government would be far worse than a similar national government, which is normally removed indirectly or directly by competition from freer nations that develop much faster), but some form of closer world governance (not necessarily a government) is probably essential to combat bioterrorism (e.g. alliances for highly detailed investigations into bioterror suspects), global warming, slave trading, abuse of workers, etc.
The way to calculate this is based on having to send one upstream TCP ACK for every downstream TCP data packet. Assuming a 1500 byte MTU (i.e. packet size = max) for the downstream packets, and a 40 byte TCP/IP ACK packet, you end up with the key ratio being 37.5 - if your upstream is >= 37.5 times faster than your downstream, TCP download sessions are limited to 37.5 * the upstream bandwidth, because you need 1/37.5 times the downstream bandwidth just to send the TCP ACKs fast enough to keep up.
So a 128 Kbps upstream limits you to at most 4.8 Mbps downstream, not 1 Mbps (latter would hold only if your MTU was 320 bytes). And if you are doing anything else in the upstream direction, you'll end up reducing download speed further.
For a canned Linux QoS/shaping setup that will work for most broadband connections, and solve the upstream ACK issue, see the Linux 2.4 Advanced Routing HOWTO. For the truly geeky, there are potential solutions to the asymmetric bandwidth issue - do a Google search for TCP ACK filtering, sender adaptation and ACK reconstruction. However, these all involve modified TCP stacks on sender and receiver, so you'd have to use some sort of proxy located upstream of the constrained link, or get the servers of the world to modify their TCP stacks...
Where to start? Last-mile bandwidth involves copper in the ground mostly (cable, xDSL), and of course routers and switches, and the DWDM kit to light dark fibre, are pretty expensive. And the people who understand how to keep a network operating are expensive - much of this is independent of bandwidth, but the more broadband users, the more last-miles and aggregation routers you have, and the more tech support calls.
Dark fibre is only cheap where it's already been laid in plentiful amounts, creating a surplus, and where the owner is willing to sell it as a commodity (most owners would rather light it themselves and sell it as a higher-priced service, getting the most out of their investment.)
Your comment about crap phone lines in apartment buildings made me think... I was recently in a hotel in Mumbai (India), where they had ADSL from the hotel room to a comms room in the hotel (i.e. re-using the existing phone wiring), and then a leased line to an ISP.
This is a great model for apartment buildings where there is no prospect of re-cabling with 100baseT or fibre - you can justify a high-bandwidth connection across a range of guests (the leased line was too small for the size of hotel, but bandwidth in India is expensive until deregulation hits the monopoly telco a bit harder), and of course you get what looks like an ADSL service to the end user. The same model would also work for older multi-tenant office buildings where there is no Ethernet cabling pre-installed. xDSL is a great way of getting decent bandwidth out of legacy copper, whether it's in-building or (more commonly) the last mile of the public phone network.
To make this slightly on-topic, the uplink to the ISP from such a building could of course be fixed wireless, which is good for rural areas or suburban areas with poor cable/xDSL coverage.
This sounds like a problem for congestion control - UDP apps frequently don't have TCP-friendly congestion control, so they can get an unfair share of the network's bandwidth, affecting other applications that use TCP or TCP-friendly UDP protocols. FLID sounds like their form of congestion control, but if they are doing better than TCP it's quite likely it is more aggressive in its network impact. However, handling long burst errors sounds like a useful thing - of course, this can mask interesting errors in network configuration, e.g. lack of FEC on a wireless/satellite link, or lack of Frame Relay traffic shaping on a router with a FR link (this happened to a customer yesterday...).
There is a lot of archived software available, e.g. various PDP-11 UNIX source code is collected at http://minnie.tuhs.org/PUPS/ (The PDP-11 Unix Preservation Society). Emulators are a big reason why this software can be more easily preserved (e.g. you can run V7 UNIX on a Linux box), although there are of course some dedicated people who keep the old hardware running.
The subscription fee can be $0, of course, just as with dynamic DNS - see www.dhs.org and many other services. However, some people will want to pay for a service to help guarantee its continued existence - of course, any paid-for service can put up its charges, but a free service can disappear...
Linux and some other OSs have good QoS features, particularly for upstream bandwidth - just allocate (say) half your bandwidth to upstream email (and the important TCP ACKs for your downstream traffic, and the P2P downloads from your machine can use the other half. In fact, you can even allocate 90% to your own traffic but let the P2P traffic 'burst' to use this when you are not using it. The only problem is that Linux QoS is quite hard to use, and most people aren't even aware of what it can do.
If there are no suitable tools available at the right price, here's an approach that may work for you - just write SQL statements, one per table, that retrieve the data from Sybase in the format of a PostgreSQL 'insert' statement. For example (may not be exactly right syntax...):
select 'insert into emp values ( "' + empname + '", "' + address1 '", "' + city + '" )'
from emp
This generates the insert statements, which can then be run against PostgreSQL.
If you have a large number of tables and columns, you could generate these queries by doing a small application (e.g. using Perl or whatever your favourite language is) that is driven by the Sybase catalogues (data dictionary).
Another approach is to just extract the data in flat file format, e.g. CSV, and generate the 'insert' statements using a small app. However, the first approach outlined avoids writing any apps and is fine for a not-too-complex database.
Whatever you do, be sure to do 'select count(*)' before and after, and consider using the flat file approach with detailed error reporting when a row can't be transferred. Things will go wrong, but typically only on a subset of the data, so make it easy to retry on that subset.
uServ only needs a central server to locate individual web servers and set up dynamic DNS accordingly - e.g. to find a replica when the master site is down, or to find a proxy that can accept incoming connections for a firewalled machine. The actual access to web servers is always done via dynamic DNS and HTTP, so there is virtually no cost to the central server (it's only used as machines log in and out of the system, or change proxying/replication relationships).
The central server (i.e. admin server and dynamic DNS service) could be very low cost - something like the cost of dynamic DNS, which can cost from $0 to $25 per year. Someone like TZO.com could easily offer this (they do a good dynDNS service already).
The reason this is better than a free hosting service is that you don't subject your readers to adverts, and you can host whatever content you want. The one thing that's missing from this is dynamic load balancing - if you could have 100 other sites replicating a popular open source software site, and have people automatically connect to a nearby low-load site, this would basically *solve the mirroring problem*. If you can make the creation and use of mirrors completely automatic, the non-corporate Web can easily scale to much higher volumes than today, without having to make mirrors visible to the user.
This does take up more of your bandwidth than central hosting, but that's the whole point of P2P - if this is a problem, apply rate limiting in the web server or the network. Most people use a lot more downstream bandwidth when surfing, so all you need to do is to reserve some bandwidth for upstream ACKs and upstream email - the remainder can be used for P2P serving without problems.
Open source hosting is very reliant on Sourceforge and on people paying for web hosting services - it would be great to see it scale through the application of standard protocols and some smart software. Freenet is a much more radical approach, of course, with some interesting features, but it requires a new client or that someone hosts an HTTP to Freenet gateway - probably both approaches will fit into different niches.
Interesting bit on DNS multi-homing - should work OK in general but some ISPs automatically increase low DNS TTLs, which might make the failover time a lot worse. See the BIND book from O'Reilly for details.
Using one provider's address space within another provider's routing tables is a valid way to multi-home, but it doesn't really reduce pressure on core routing tables (one route carried in the BGP routing table instead of two, but the main routing table has the same number of routes).
IPv6 actually simplifies this issue a bit - particularly for single-homed sites, it's much easier to transfer to another provider's address space, since you can renumber a whole IPv6 network automatically. For single-homed sites, IPv6 aggregation will be as good as, or better than, IPv4's. Unfortunately, IPv6 doesn't solve the multi-homed site issue, since you still need the routers with full Internet routing tables to carry routes for all multi-homed sites.
Exactly. Another issue is the amount of routing updates that need to be pushed over network links (although BGP only sends the differences). Most importantly, nobody is going to massively upgrade (memory and CPU) all routers carrying full Internet routing tables every year or two, as if they were PCs - it's too disruptive and expensive.
IPv6 will not solve this problem, and it is a real issue that the IETF is concerned about - existing aggregation and filtering of routes will work for an estimated 5 years, which should give time to develop better approaches by then. See http://www.ietf.org/html.charters/ptomaine-charter.html for more.
I don't know where you got your 60% figure from, but it's complete rubbish. At least in the UK, landline phones have excellent voice quality and almost never fail - last time I had a problem was 15 years ago, and BT has to compensate you for an outage over a certain amount. Europe is a big place - your figure may apply to Greece or Portugal, perhaps, but even there it's probably an exaggeration.
Europeans as well as Americans invented the computer (e.g. Charles Babbage, Konrad Zuse and the Bletchley Park people), but please don't let the facts on this and other technologies disturb your prejudices.
GPRS initially allows only 'mobile originate', i.e. the phone initiates a GPRS session to a remote network (e.g. a walled-garden WAP service) and that network sends packets back. Unsolicited packets are dropped, so as long as nobody hacks into the WAP service this is fairly unlikely. The 'mobile terminate' feature would allow unsolicited packets to be sent to the phone is not yet implemented, I believe.
This is going to become an interesting issue as GPRS networks connect to the Internet (many are WAP only on a private IP network) - perhaps the only mitigating factor is that GPRS connections to the Internet will probably go via a NAT, making it harder for unsolicited packets to get in (they'd have to spoof an active server and guess the port number on the NAT device, as well as hoping that a UDP session was in use since spoofing TCP sequence numbers is pretty hard).
Slashdot Mirror
SMS on a Palm is much nicer than a phone in any case, even Graffiti beats thumb-keying - I use the free GSMtool at present on a Palm + Ericsson T68 and it works well.
Do you know how many GPRS slots you get with the version you have, up and down? Failing that, do you know what data rates you get?
One key reason to get an integrated device is that the Palm to Phone link will always work - getting separate devices to work is a bit of a nightmare, even though I have IRDA working.
You can get a version without the keyboard, but I suspect I'll get the keyboard one just to make email and SMSing easier, even though I've used Graffiti for some time now. I doubt if there's any more scrolling, as Palm-compatible screens are always 160x160 (or double in some cases) - more squinting though...
:)
I have voice dialling in my Ericsson phone and I never use it, but then being a Euroid living in LondonI don't drive as much as some people
As for having to activate dialup and get an ISP - that's a feature of the service, not the phone. The 9600 bps connection may also be a service issue, it depends on the GSM network I think.
GSM may not be useful where you live, but it works well around the rest of the world. I'll wait for the GPRS-enabled version (although one UK poster on this thread says he has been using that version for 2 weeks) so I can get always-on and about 40-50 Kbits/sec. Does anybody know how many GPRS slots the GPRS version has, up and down?
Really it's horses for courses - if you prefer CDMA service for where you live/travel, go for the Kyocera (though I think Handspring have a deal with Qualcomm to do a CDMA product in the future). If you prefer GSM, go for the Treo.
I'm sceptical about the compression, but it should improve things given image downscaling (Plucker and AvantGo do the same thing on Palms). As for your GPRS comment - the Pogo is a GPRS device, so it's not exactly going to be 'killed by GPRS...'
Quite a few vendors are emulating the Cisco IOS command line interface on completely new hardware - e.g. Unisphere and Foundry in the US, and Huawei in China (who produce Cisco clones at 10% of Cisco prices...) Emulating the CLI can be done on any size of router, of course.
I doubt there will be many bits of BeOS used in PalmOS 5.0 - as you say, Palm started working on 5.0 before buying Be, and Palm have said publicly that they bought Be for its packaging technology and its developers.
:)
The best hope for BeOS is that Palm licenses it on reasonable terms. I'd never heard of Yellow Tab in earlier Be discussions, so I'd be interested to hear how it got a license, though.
All this excitement about licensing and the death or continued life of BeOS does go to show that if you want a dull life, you should use an open source OS - it will just be there, quietly being enhanced and bugfixed, while companies are born and die around it
ACKs are sent for every TCP segment received (i.e. a TCP packet) not per window. I was assuming that the window size is sufficiently large to allow transfers to go at full speed - this should be no problem with broadband connections as they are quite low latency in any case. So TCP windows are not really relevant here.
Upstream caps *will* limit TCP download speed to 4.8 Mbps in this case - maybe you mean UDP protocols in your 2nd paragraph. UDP-based protocols may or may not have congestion control (i.e. backing off when they sense packet loss or excessive delays) - the ones without congestion control and rate adaptation let you select the stream with the right rate, but this is quite unnecessary if the protocol is designed to sense bandwidth and select the correct media stream.
All this is fairly theoretical unless you are downloading from a very well-connected server that is quite close by (e.g. hosted by your ISP). I've rarely managed to get the full 1 Mbps when using real web/FTP sites with my ADSL connection.
There's no problem with using RFC1918 on internal interfaces - however, it would be better to configure the routers so they use a publicly addressable loopback interface as the source address of ICMP packets that they generate. In other words, this would prevent the 10.x address from appearing (and perhaps prevent some paranoid routers from dropping the ICMP packet from that router). Of course, the long term solution is to implement IPv6 before the combined weight of IPv4 workarounds/cruft sinks the Internet...
This sounds plausible given the limited upstream cable bandwidth per segment, explained elsewhere. If you have 128 Kbps upstream bandwidth, TCP downloads (not UDP) are limited to approx 4.8 Mbps (just multiply upstream by 37.5 to calculate the max TCP downstream bandwidth). The details are at http://slashdot.org/comments.pl?sid=25234&cid=2743 853
You are ignoring the threat of non-state actors such as al Qa'ida, who are enough of a threat to governments all round the world that they are one driver for global cooperation and (perhaps) ultimately world governance - see http://www.nonzero.org/terror.htm for more discussion of this. As technology makes it easier and cheaper for almost anybody to kill large numbers of people, global cooperation will become essential to counteract this.
The US and all other industrialised countries are highly interdependent with poorer countries, for trade reasons and more importantly because technology and suicide terrorism has made it possible for terrorists to inflict huge casualties on developed countries at a very low cost. Read www.nonzero.org - the book on which this site is based was written before Sept 11, and included the prediction that by 2020 a terrorist will be able to kill 50,000 people in a Western city using bioterrorism. Because we are so interdependent with developing countries, we simply have to pay attention to reducing the pool of disaffected haters of the US and other developing countries - only by reducing the support for terrorism will we reduce the frequency of such acts. Of course, you also need to go after the terrorists themselves, but in a way that doesn't further increase their support (see the essay about how many Afghan civilian casualties are acceptable in US eyes...).
By the way, Britain is part of the EU and is going to join the Euro in the next few years - we have no alternative really, given that inward investment is already beginning to divert to the Euro zone for economic reasons. I don't think it makes any sense for the US to join the EU, but it's quite possible that NAFTA will deepen to become somewhat like the EU, and perhaps add Latin American members as well.
Sovereign nations were invented about 500 years ago - before that, we had city states. There's no reason why they can't be (largely) superseded by larger groupings, though IMO the nation state will survive in some form for a long time, as part of supranational groupings. The protection of human rights in the US comes from the constitution, but also from the courts throwing out unconstitutional laws (which doesn't seem to be happening with recent anti-terrorism legislation). The EU has its own Human Rights legislation and a court dedicated to such cases - by joining the EU and adopting this legislation, the UK (which has no written constitution) has actually improved the human rights position for its citizens. I'm not a big fan of the EU (it tends to be overly bureaucratic, typical 'big government') but it is economically sensible and overall is doing a reasonable job.
I've just read Non-Zero, by Robert Wright, which explains how the size of groupings has grown over the millenia (from hunter-gatherer bands to villages, chiefdoms, kingdoms and now nation states) - this is all driven by the benefits of cooperating with other groups for the purposes of hunting, farming, trade, etc, and by the need to defend or attack others by allying with nearby groups. His approach is to apply game theory (zero-sum vs. non-zero sum games) and a scientific outlook to explaining the big picture of history - as someone who hated history at school for its arbitrariness, I find this 'unified theory' approach very appealing. See www.nonzero.org for the author's website, which includes excerpts from most chapters.
The nation state is a relatively recent invention (about 500 years old) - since there are various free trade areas that are similar to the earlier stages of what is now the European Union (e.g. the Gulf Cooperation Council is a free-trade area that plans to have a single currency in 2010), it's not unreasonable to expect many nation states to be subsumed into something close to a 'world government'. Clearly this is something that must be done right (a despotic world government would be far worse than a similar national government, which is normally removed indirectly or directly by competition from freer nations that develop much faster), but some form of closer world governance (not necessarily a government) is probably essential to combat bioterrorism (e.g. alliances for highly detailed investigations into bioterror suspects), global warming, slave trading, abuse of workers, etc.
The way to calculate this is based on having to send one upstream TCP ACK for every downstream TCP data packet. Assuming a 1500 byte MTU (i.e. packet size = max) for the downstream packets, and a 40 byte TCP/IP ACK packet, you end up with the key ratio being 37.5 - if your upstream is >= 37.5 times faster than your downstream, TCP download sessions are limited to 37.5 * the upstream bandwidth, because you need 1/37.5 times the downstream bandwidth just to send the TCP ACKs fast enough to keep up.
So a 128 Kbps upstream limits you to at most 4.8 Mbps downstream, not 1 Mbps (latter would hold only if your MTU was 320 bytes). And if you are doing anything else in the upstream direction, you'll end up reducing download speed further.
For a canned Linux QoS/shaping setup that will work for most broadband connections, and solve the upstream ACK issue, see the Linux 2.4 Advanced Routing HOWTO. For the truly geeky, there are potential solutions to the asymmetric bandwidth issue - do a Google search for TCP ACK filtering, sender adaptation and ACK reconstruction. However, these all involve modified TCP stacks on sender and receiver, so you'd have to use some sort of proxy located upstream of the constrained link, or get the servers of the world to modify their TCP stacks...
Where to start? Last-mile bandwidth involves copper in the ground mostly (cable, xDSL), and of course routers and switches, and the DWDM kit to light dark fibre, are pretty expensive. And the people who understand how to keep a network operating are expensive - much of this is independent of bandwidth, but the more broadband users, the more last-miles and aggregation routers you have, and the more tech support calls.
Dark fibre is only cheap where it's already been laid in plentiful amounts, creating a surplus, and where the owner is willing to sell it as a commodity (most owners would rather light it themselves and sell it as a higher-priced service, getting the most out of their investment.)
Your comment about crap phone lines in apartment buildings made me think... I was recently in a hotel in Mumbai (India), where they had ADSL from the hotel room to a comms room in the hotel (i.e. re-using the existing phone wiring), and then a leased line to an ISP.
This is a great model for apartment buildings where there is no prospect of re-cabling with 100baseT or fibre - you can justify a high-bandwidth connection across a range of guests (the leased line was too small for the size of hotel, but bandwidth in India is expensive until deregulation hits the monopoly telco a bit harder), and of course you get what looks like an ADSL service to the end user. The same model would also work for older multi-tenant office buildings where there is no Ethernet cabling pre-installed. xDSL is a great way of getting decent bandwidth out of legacy copper, whether it's in-building or (more commonly) the last mile of the public phone network.
To make this slightly on-topic, the uplink to the ISP from such a building could of course be fixed wireless, which is good for rural areas or suburban areas with poor cable/xDSL coverage.
This sounds like a problem for congestion control - UDP apps frequently don't have TCP-friendly congestion control, so they can get an unfair share of the network's bandwidth, affecting other applications that use TCP or TCP-friendly UDP protocols. FLID sounds like their form of congestion control, but if they are doing better than TCP it's quite likely it is more aggressive in its network impact. However, handling long burst errors sounds like a useful thing - of course, this can mask interesting errors in network configuration, e.g. lack of FEC on a wireless/satellite link, or lack of Frame Relay traffic shaping on a router with a FR link (this happened to a customer yesterday...).
There is a lot of archived software available, e.g. various PDP-11 UNIX source code is collected at http://minnie.tuhs.org/PUPS/ (The PDP-11 Unix Preservation Society). Emulators are a big reason why this software can be more easily preserved (e.g. you can run V7 UNIX on a Linux box), although there are of course some dedicated people who keep the old hardware running.
The subscription fee can be $0, of course, just as with dynamic DNS - see www.dhs.org and many other services. However, some people will want to pay for a service to help guarantee its continued existence - of course, any paid-for service can put up its charges, but a free service can disappear...
Linux and some other OSs have good QoS features, particularly for upstream bandwidth - just allocate (say) half your bandwidth to upstream email (and the important TCP ACKs for your downstream traffic, and the P2P downloads from your machine can use the other half. In fact, you can even allocate 90% to your own traffic but let the P2P traffic 'burst' to use this when you are not using it. The only problem is that Linux QoS is quite hard to use, and most people aren't even aware of what it can do.
If there are no suitable tools available at the right price, here's an approach that may work for you - just write SQL statements, one per table, that retrieve the data from Sybase in the format of a PostgreSQL 'insert' statement. For example (may not be exactly right syntax...):
select 'insert into emp values ( "' + empname + '", "' + address1 '", "' + city + '" )'
from emp
This generates the insert statements, which can then be run against PostgreSQL.
If you have a large number of tables and columns, you could generate these queries by doing a small application (e.g. using Perl or whatever your favourite language is) that is driven by the Sybase catalogues (data dictionary).
Another approach is to just extract the data in flat file format, e.g. CSV, and generate the 'insert' statements using a small app. However, the first approach outlined avoids writing any apps and is fine for a not-too-complex database.
Whatever you do, be sure to do 'select count(*)' before and after, and consider using the flat file approach with detailed error reporting when a row can't be transferred. Things will go wrong, but typically only on a subset of the data, so make it easy to retry on that subset.
uServ only needs a central server to locate individual web servers and set up dynamic DNS accordingly - e.g. to find a replica when the master site is down, or to find a proxy that can accept incoming connections for a firewalled machine. The actual access to web servers is always done via dynamic DNS and HTTP, so there is virtually no cost to the central server (it's only used as machines log in and out of the system, or change proxying/replication relationships).
The central server (i.e. admin server and dynamic DNS service) could be very low cost - something like the cost of dynamic DNS, which can cost from $0 to $25 per year. Someone like TZO.com could easily offer this (they do a good dynDNS service already).
The reason this is better than a free hosting service is that you don't subject your readers to adverts, and you can host whatever content you want. The one thing that's missing from this is dynamic load balancing - if you could have 100 other sites replicating a popular open source software site, and have people automatically connect to a nearby low-load site, this would basically *solve the mirroring problem*. If you can make the creation and use of mirrors completely automatic, the non-corporate Web can easily scale to much higher volumes than today, without having to make mirrors visible to the user.
This does take up more of your bandwidth than central hosting, but that's the whole point of P2P - if this is a problem, apply rate limiting in the web server or the network. Most people use a lot more downstream bandwidth when surfing, so all you need to do is to reserve some bandwidth for upstream ACKs and upstream email - the remainder can be used for P2P serving without problems.
Open source hosting is very reliant on Sourceforge and on people paying for web hosting services - it would be great to see it scale through the application of standard protocols and some smart software. Freenet is a much more radical approach, of course, with some interesting features, but it requires a new client or that someone hosts an HTTP to Freenet gateway - probably both approaches will fit into different niches.
Interesting bit on DNS multi-homing - should work OK in general but some ISPs automatically increase low DNS TTLs, which might make the failover time a lot worse. See the BIND book from O'Reilly for details.
Using one provider's address space within another provider's routing tables is a valid way to multi-home, but it doesn't really reduce pressure on core routing tables (one route carried in the BGP routing table instead of two, but the main routing table has the same number of routes).
IPv6 actually simplifies this issue a bit - particularly for single-homed sites, it's much easier to transfer to another provider's address space, since you can renumber a whole IPv6 network automatically. For single-homed sites, IPv6 aggregation will be as good as, or better than, IPv4's. Unfortunately, IPv6 doesn't solve the multi-homed site issue, since you still need the routers with full Internet routing tables to carry routes for all multi-homed sites.
Exactly. Another issue is the amount of routing updates that need to be pushed over network links (although BGP only sends the differences). Most importantly, nobody is going to massively upgrade (memory and CPU) all routers carrying full Internet routing tables every year or two, as if they were PCs - it's too disruptive and expensive.
r .html for more.
IPv6 will not solve this problem, and it is a real issue that the IETF is concerned about - existing aggregation and filtering of routes will work for an estimated 5 years, which should give time to develop better approaches by then. See http://www.ietf.org/html.charters/ptomaine-charte
I don't know where you got your 60% figure from, but it's complete rubbish. At least in the UK, landline phones have excellent voice quality and almost never fail - last time I had a problem was 15 years ago, and BT has to compensate you for an outage over a certain amount. Europe is a big place - your figure may apply to Greece or Portugal, perhaps, but even there it's probably an exaggeration.
Europeans as well as Americans invented the computer (e.g. Charles Babbage, Konrad Zuse and the Bletchley Park people), but please don't let the facts on this and other technologies disturb your prejudices.
GPRS initially allows only 'mobile originate', i.e. the phone initiates a GPRS session to a remote network (e.g. a walled-garden WAP service) and that network sends packets back. Unsolicited packets are dropped, so as long as nobody hacks into the WAP service this is fairly unlikely. The 'mobile terminate' feature would allow unsolicited packets to be sent to the phone is not yet implemented, I believe.
This is going to become an interesting issue as GPRS networks connect to the Internet (many are WAP only on a private IP network) - perhaps the only mitigating factor is that GPRS connections to the Internet will probably go via a NAT, making it harder for unsolicited packets to get in (they'd have to spoof an active server and guess the port number on the NAT device, as well as hoping that a UDP session was in use since spoofing TCP sequence numbers is pretty hard).