SSLv2, SSLv3 and TLS all support DES and 3DES (according to the installed ciphers in my copy of Opera 3.62 on Windows). So this chip will help with this bit of SSL, once the initial key exchange stuff is done; no doubt an accelerator that supported the key exchanges better would be faster.
This would be a good chip to use for IPSec VPNs with pre-shared keys - OpenBSD comes with IPSec as standard these days, so it could make a nice firewall/VPN gateway combo. I believe quite a few router manufacturers use Hi/fn chips, so it should be fairly good.
If you've ever used a broadband connection, you'll notice that response times are much better, like the man says.
Of course broadband is not necessary, neither is the Internet, or bookshops, or anything beyond basic needs - however, it's convenient and pleasant to use faster connections.
Mobile Internet is very useful, which is why people will put up with low speed connections (although with small screen and memory it's not so useful to have broadband perhaps). Once there is fairly low cost broadband to the mobile, it would be nice to listen to Internet radio, or your own MP3 collection stored at home, through a stereo headset attached to the phone.
You've just changed the problem for the worse - now you have to allocate port numbers from the already cramped port number space (see www.iana.org for the list of known port numbers, which is not necessarily those used).
When you install a new fridge, you'll have to somehow work out the port numbers it uses and then allocate them to public port numbers on your NAT. This will be a manual process, and of course if you install two appliances that want to use the same port number, you end up having to allocate different port numbers, then remember them all...
IPv6 is so much easier it's not even funny - just plug a device in, it autoconfigures itself with IP addresses, finds out the nearest router, and then maybe hooks into SLP (service location protocol) or an LDAP directory so you can query your new fridge. Spot the lack of manual configuration...
First of all, I agree IPv6 has some nice features beyond address space - however, they are not all unique to IPv6, many are also in IPv4.
> Speed (simpler headers and simpler routing)
This should happen, but all the ASICs in existing routers need to be changed (unless the designers were very far-sighted and wasted some silicon on v6 support). Headers are bigger in v6, but it should be easier to do fast silicon because they are more regular (header options are faster to process too). As it happens, Intel's IXA and similar network processors may make it easy to do very fast routers using many parallel IXA-like chips (one vendor is doing a 180-IXA-chip router), for which IPv6 is simply a software upgrade.
IPv6 does make it easier to keep the size of core Internet routing tables down, but it seems that stub networks (e.g. enterprises or mobile phone networks) will migrate to v6 first, leaving core networks till last.
Probably speed will not be a deciding factor either way.
> Mobility (mobile IPv4 has relied on all stations involved having forwarding systems)
IPv6 has some advantages for mobility, because mobile IP was built into IPv6 hosts, but I can't remember what they are...
> Autoconfiguration (no more messing with DHCP or BOOTP configuration files)
Yes, but DHCP does more than ND (Neighbour Discovery) and RADV (Router Advertisments) - e.g. it configures DNS servers, domain names, etc. So DHCPv6 will still be needed in many environments.
> Security (IPSec is mandatory)
IPSec is mandatory, but it won't be turned on as default until someone solves the scalability and performance issues of IKE (Internet Key Exchange protocol, which authenticates both parties and sets up keying material). PKI is the only scalable way to do IKE currently, and PKI is a nightmare. Also, IKE has quite long delays (in the seconds) when setting up sessions, which is perhaps why it is typically used between IPSec gateways in tunnel mode.
> Optimised Connections (anycasting allows you to locate the nearest active server of the type you want)
Anycast is very cool, but not yet implemented in the IPv6 stacks I've seen (e.g. Linux). I think the IETF is still working on how this will be implemented.
> Quality of Service (another mandatory feature)
In what sense is QoS mandatory? I have Linux IPv6 set up at home, but I don't have RSVP installed. I work for a company that does QoS provisioning software, and the only QoS feature I can see in IPv6 that is different to IPv4 is the Flow Label (a 16 bit field that optimises the classification of app to app traffic flows, for use with RSVP). The Traffic Class field in IPv6 is identical in format to the TOS byte used in IPv4, and will use DiffServ in the same way.
> Multicasting (yet another mandatory feature)
Not sure exactly which bits are mandatory here, either. Multicast has been designed in, and is probably better supported in IPv6, though I've not looked at this in detail. Multicast routing protocols are a separate issue to IPv6 vs v4, they simply need updating to be able to route IPv6 multicast traffic. There is quite a lot of practical work in network management of multicast to be done still, whether on IPv6 or IPv4, though it is seeing some deployment. QoS is probably a pre-requisite for most people to deploy multicast - until you can control multicast apps' use of your network bandwidth, it's tough to allow them to be deployed except if you control the app servers very tightly.
I think the killer apps for IPv6 are:
* Address Space - this will drag people kicking and screaming into IPv6, in order to support always-on (good point from Vint Cerf about increased duration of IP address usage), lack of massively scalable NATs (let's see someone NAT 10 million cable TV users...), cellphones/smartphones with IP, home appliances, etc.
* Getting rid of NAT hassles - trying to get applications to work through NAT is a pain and sometimes impossible by design (e.g. IPSec transport mode). This is probably not a killer reason, but will help the decision, particularly where the end host must act as a server (e.g. sending short messages or news updates to a mobile phone).
* Mergers and Automatic Network Renumbering - if two companies merge, you currently have to NAT traffic between their networks, or go through the pain of manual renumbering. IPv6 lets you auto-renumber from a single point, everything 'just works'. Since 'within the firewall' applications in a merged network would still have to cross the NAT, and many protocols such as DCOM, CORBA and so on are NAT-hostile, this may be a strong motivation.
Ultimately, address space is the single biggest reason, particularly in Asia (which was late to the Internet and got a tiny allocation, allegedly smaller than some US companies have).
http://www.ipmulticast.com/isplist.htm has a list of ISPs/ASPs supporting multicast. This site is also a good place to learn more about multicast.
The problems with multicast deployment are largely to do with it being quite hard to control (access control of senders as well as bandwidth limits on senders), and a challenge to troubleshoot. There was a good article in a recent IEEE Communications magazine about this (in fact the whole issue was about multicast).
Most routers have multicast features, but as with QoS/DiffServ features, turning them on can result in hassles if you don't have the tools to manage them properly.
Late comment, but have a look at Ogg Vorbis, an impressive sounding audio codec that is open source and patent free: http://www.xiph.org/ogg/vorbis/index.html
From a quick look at the technical specs, it is routing IP packets (unlike so-called wavelength routers, which just switch DWDM wavelengths). They talk about doing WFQ (Weighted Fair Queuing) etc.
All in all, this is a pretty impressive box - other boxes from Juniper and Cisco are already available but don't scale so high. For a good article on the benchmarketing involved in terabit routers, see http://www.lightreading.com/, which also has a great piece on how to succeed in an optical networking startup ('at all costs, stop your engineers from developing a product'...)
Access lists are not very relevant on core routers - all use of access lists, e.g. for multiple-field classification (IP addresses, port numbers, IP Protocol, URL, etc.) should be done on the edge of the network, where the available CPU power per Mbps is much higher. This is part of the standard DiffServ model (details at http://www.ietf.org/html.charters/diffserv-charter .html) which is being implemented in Linux, BSD (via AltQ), Windows 2000, and most routers.
The idea of DiffServ is that the edge routers do the hard classification, then encode this in the packet in the TOS byte in a 6-bit number called the DiffServ codepoint. From that point, all routers just have to check the TOS byte to see which queue to use for a packet, which is pretty fast and much easier to do in hardware. Linux has pretty good DiffServ support - see the Advanced Routing HOWTO for details, or the article in Linux Journal this month.
Absolutely - this is like the mainframe programmer a while back who said he always wrote portable code: 'it can run on any IBM-compatible mainframes'...
It's a DirectX issue, NT has a very old version. You might want to try running Win2000 or Win98 in a VM. However, the VMware emulated hardware is quite basic - e.g. SB16 sound - so you might still have problems.
VMware is not really intended for playing games at the moment - stick to dual booting until it gets better, or buy Linux games:)
One other datapoint - I had problems getting Active Directory to install on Win2000 RC2 native (repeatedly locked up the machine completely), so I re-installed onto a virtual disk within VMware. And of course, Active Directory ran just fine (if a little slowly, Win2000 is heavier on the machine at least compared to NT, when running on VMware).
Exactly - I suspect VMware did quite a bit of testing to find out exactly which hardware ran NT, Win98 and other OSs with high stability, then worked out which hardware was easy to emulate, and chose the intersection for their VM spec.
Of course, the corollary for this is that if you buy an AMD PCnet NIC, SB16, and so on, it should be ultra stable at running NT...
I wouldn't really recommend NT+VMware+Linux as an elegant solution for reliable applications, but if there's an app that runs only on Windows, it's not a bad approach.
For a dedicated 'Windows' workstation, you could even run VMware instead of a window manager, in full screen mode, so the system appears to boot 'right into Windows'. If you ran this on another X display (e.g.:1, leaving:0 as the main Linux+X display), you could make it easy to toggle into a full-screen Windows session. However, you would lose Linux/open source brownie points big time:)
Re SMP - see the VMware support site, I think this is covered (though you may need to re-install NT onto a virtual disk then mount the other disks as data disks).
Re BeOS - I agree, it's a matter of getting Be interested in this. BeOS 4.5 does get halfway through the boot sequence...
The pre-installed images would be delivered as virtual disk files, i.e. they could only ever be run from under VMware. Hence it would be quite easy to get the install to work reliably (after all, NT works very well on the VMware virtual hardware).
Not quite true - OS/2 guest support for VMware is now available as 'experimental', i.e. unlikely to work that well but should do something. See their website for details, probably the Support section.
Actually you are quite close to the truth - Windows NT on top of VMware on Linux never, ever BSODs, whereas a similar NT-only system at work crashes every few weeks (happened today), while my NT laptop used to crash all the time when I used it a lot.
VMware's website has a case study of a law firm who installed Linux and VMware in order to run Windows with fewer crashes - so this is not just my experience...
One useful feature in VMware 2.0 is the 'suspend to disk' feature (like some laptops but no OS APM or ACPI support required). Currently you can only suspend to disk as part of suspending the VM. However, it would be possible to save the Windows or other OS state to disk in an identical way every 5 minutes or so (the save to disk is quite fast if you have enough memory as it goes to Linux buffer cache). This would mean you could recover from any Windows/other crash, no matter how bad, back to your state as of N minutes ago.
This is similar to some Windows products that recover your state, but is much more likely to be bullet proof since it's done through the VM mechanism.
It would also be useful when testing out bleeding edge Linux kernels, of course...
The report IS identical, it's just the front page that is different - clicking on the Report link from the front page presented at http://www.echelonwatch.org/ gives you the same report as at this URL.
Luckily encryption issues have already been sorted out to implement virtual private networks over the Internet. See my post earlier at http://slashdot.org/comments.pl?sid=00/02/01/16522 10&cid=215 for details of how you might use IPSec for this.
One slightly odd implication is that the WLAN is a public network, so it should really be connected to the outside of your home firewall - otherwise you have to carefully IPSEC every host in your home, even the wired-only ones. Or you make the WLAN gateway into another firewall, but why have two firewalls?
Have a look at http://www.freeswan.org/ - this is a relatively complete implementation of IPSec for Linux - includes IKE for key exchanges but no PKI support yet.
I forgot to say that IPSec can encrypt all IP traffic on your WLAN, just about. Some things, such as broadcasts or multicasts, may have problems, but generally it just works.
You can use all your normal applications, and there's no need for SSH on the LAN.
I'd strongly recommend you implement IPSec with 3DES (168 bit keys) between all wireless LAN nodes. I think the WEP encryption has a fairly pathetic keylength (40 bits?) and in any case the usual arguments about open source crypto apply. Even if you use a closed source IPSec on Windows, at least IPSec has been publicly reviewed. Bruce Schneier has reviewed IPSec and was quite critical of its complexity and other problems, but admitted it is the 'least worst' option (see http://www.counterpane.com for his interesting paper on this).
I'd recommend using IPSec's ESP + authentication, and not bothering with AH, which cannot go through NATs or IP Masquerading. You can use ESP tunnels to go right through a NAT and support wired or other VPN access to your home network.
I'd prefer to use tunnel mode even within the LAN, which is also a Schneier recommendation - then you have a clear distinction between encrypted and unencrypted interfaces - if you see any packets between non-tunnelled IP addresses, you know at once they weren't encrypted.
I haven't got this set up at home yet (still waiting for a colleague to dig out his free Nokia WLAN card - they were giving them away at Interop last September) but I will real soon now. I did use BayStack 650 cards at the IETF last year, but these don't have Linux support.
In a sense, all wireless access is dialin, since anyone can just fake a MAC address, stand next to your house and get right in to your network, so strong VPN support is a Good Thing - you might want to make your Wireless LAN gateway sit outside your firewall perhaps.
There are IPSec implementations for Linux, *BSD (check out http://www.freeswan.org/ for Linux and http://www.openbsd.org/ for OpenBSD), and many commercial ones for Windows (I think PGPnet is a free VPN client for Windows but it's only available in US).
One other thing to think about is DSSS vs FHSS - these are two variants of spread spectrum (direct sequence and frequency hopping) - cards can be 802.11 compatible and use either, but the two types cannot communicate... DSSS appears to be winning for 802.11 (2 Mbps version) but there's some questionmark over the allocation of spectrum for 802.11b DSSS (but I could have mis-remembered that last bit).
Wireless LANs are definitely the future - the standards are a huge mess, though. Things to check out include HomeRF (includes SWAP), BRAN (formerly HiperLAN 2, from ETSI), Bluetooth, and more, including the whole mobile phone saga of HSCSD, GPRS, EDGE, UMTS, and so on. But 802.11 seems to have a fairly good niche in Wireless LANs, so it will probably do OK.
Some WLAN vendors are talking to telcos about rolling this out to hotels and airports - the idea is you just walk into the place, sign on to your existing ISP (if they serve that area) or put in a credit card number on a web page, and then you're on the Net at 2 Mbps or higher.
Many better-educated Indians do speak English and thus have access to the rest of the Internet. But why is it necessary for (say) a grandmother to learn English just to send email to her grandchildren? Learning English is a good thing for many people, but it's not an either/or - many people will learn English, many other people will use localised interfaces.
Check your facts before posting - most US modems work fine in the UK and other countries once you set them to blind dial (AT X3, i.e. ignore dialtone). They may have difficulty detecting engaged tones as well but this is not too important for hearing modem users.
The important issue is power supplies, which are always different (but a 110-240V supply will do fine, and suitable local adapters can usually be found), and telephone socket standards (there are literally tens of different ones... See http://www.teleadapt.com/ for examples).
Internal modems, probably ISA, are the best bet. As for the other hardware, any PC is better than none IMO - a 386 or above would be fine for browsing the Net with Lynx, or doing email, which is the key app for many people. However, a 486 or Pentium would be able to support a GUI better, allowing better internationalisation support normally.
First of all, the accepted term for translating a program's text and other conventions is 'localisation' - technically, internationalisation is the process of ensuring that software is very easily localised.
More importantly, why do so many people think that they should have the choice of using the Internet in their native language (which I'd guess is English for many people with this view), but that other people should not? Why don't you all learn written Chinese so *you* can benefit from an international outlook.
Just because English happens to be the language most used on the Internet does not mean that everyone should be forced to use it. In fact, I think it would do a lot of good to some anglophones to have to use another language occasionally.
On a practical note - for any Linux users who want a nicely internationalised + localised distribution - check out Mandrake 6.1 or later (7.0 is now downloadable). This has a great default setup that includes all the fonts required to surf to Japanese, Chinese, Korean and other sites using my normal Netscape 4.7 (English version). Even though I only know a few Chinese characters, it's great to at least be able to see the page and maybe send it to a friend who can read it (as an image attachment, no doubt...).
Mozilla (http://mozilla.org) has a great page on i18n and l10n, with some good resources.
Re:Eyes, ears and nose...now all we need's nerves.
on
Digital Nose
·
· Score: 3
"Added to this, modern hearing aids attach electronics directly into the inner ear, with vibration sensors outside the ear, to make people who would previously have been deaf, or almost deaf, hear perfectly again"
'Perfectly' is a significant exaggeration - assuming you are talking about cochlear implants, which are the only implant for deaf people that I've heard of, results vary significantly depending on factors such as whether the person has ever had hearing and if so, how long they ahve been deaf. There's a reasonable overview at http://www.voice-center.com/cochlear_implants.ht ml
Slashdot Mirror
SSLv2, SSLv3 and TLS all support DES and 3DES (according to the installed ciphers in my copy of Opera 3.62 on Windows). So this chip will help with this bit of SSL, once the initial key exchange stuff is done; no doubt an accelerator that supported the key exchanges better would be faster.
This would be a good chip to use for IPSec VPNs with pre-shared keys - OpenBSD comes with IPSec as standard these days, so it could make a nice firewall/VPN gateway combo. I believe quite a few router manufacturers use Hi/fn chips, so it should be fairly good.
If you've ever used a broadband connection, you'll notice that response times are much better, like the man says.
Of course broadband is not necessary, neither is the Internet, or bookshops, or anything beyond basic needs - however, it's convenient and pleasant to use faster connections.
Mobile Internet is very useful, which is why people will put up with low speed connections (although with small screen and memory it's not so useful to have broadband perhaps). Once there is fairly low cost broadband to the mobile, it would be nice to listen to Internet radio, or your own MP3 collection stored at home, through a stereo headset attached to the phone.
You've just changed the problem for the worse - now you have to allocate port numbers from the already cramped port number space (see www.iana.org for the list of known port numbers, which is not necessarily those used).
When you install a new fridge, you'll have to somehow work out the port numbers it uses and then allocate them to public port numbers on your NAT. This will be a manual process, and of course if you install two appliances that want to use the same port number, you end up having to allocate different port numbers, then remember them all...
IPv6 is so much easier it's not even funny - just plug a device in, it autoconfigures itself with IP addresses, finds out the nearest router, and then maybe hooks into SLP (service location protocol) or an LDAP directory so you can query your new fridge. Spot the lack of manual configuration...
First of all, I agree IPv6 has some nice features beyond address space - however, they are not all unique to IPv6, many are also in IPv4.
> Speed (simpler headers and simpler routing)
This should happen, but all the ASICs in existing routers need to be changed (unless the designers were very far-sighted and wasted some silicon on v6 support). Headers are bigger in v6, but it should be easier to do fast silicon because they are more regular (header options are faster to process too). As it happens, Intel's IXA and similar network processors may make it easy to do very fast routers using many parallel IXA-like chips (one vendor is doing a 180-IXA-chip router), for which IPv6 is simply a software upgrade.
IPv6 does make it easier to keep the size of core Internet routing tables down, but it seems that stub networks (e.g. enterprises or mobile phone networks) will migrate to v6 first, leaving core networks till last.
Probably speed will not be a deciding factor either way.
> Mobility (mobile IPv4 has relied on all stations involved having forwarding systems)
IPv6 has some advantages for mobility, because mobile IP was built into IPv6 hosts, but I can't remember what they are...
> Autoconfiguration (no more messing with DHCP or BOOTP configuration files)
Yes, but DHCP does more than ND (Neighbour Discovery) and RADV (Router Advertisments) - e.g. it configures DNS servers, domain names, etc. So DHCPv6 will still be needed in many environments.
> Security (IPSec is mandatory)
IPSec is mandatory, but it won't be turned on as default until someone solves the scalability and performance issues of IKE (Internet Key Exchange protocol, which authenticates both parties and sets up keying material). PKI is the only scalable way to do IKE currently, and PKI is a nightmare. Also, IKE has quite long delays (in the seconds) when setting up sessions, which is perhaps why it is typically used between IPSec gateways in tunnel mode.
> Optimised Connections (anycasting allows you to locate the nearest active server of the type you want)
Anycast is very cool, but not yet implemented in the IPv6 stacks I've seen (e.g. Linux). I think the IETF is still working on how this will be implemented.
> Quality of Service (another mandatory feature)
In what sense is QoS mandatory? I have Linux IPv6 set up at home, but I don't have RSVP installed. I work for a company that does QoS provisioning software, and the only QoS feature I can see in IPv6 that is different to IPv4 is the Flow Label (a 16 bit field that optimises the classification of app to app traffic flows, for use with RSVP). The Traffic Class field in IPv6 is identical in format to the TOS byte used in IPv4, and will use DiffServ in the same way.
> Multicasting (yet another mandatory feature)
Not sure exactly which bits are mandatory here, either. Multicast has been designed in, and is probably better supported in IPv6, though I've not looked at this in detail. Multicast routing protocols are a separate issue to IPv6 vs v4, they simply need updating to be able to route IPv6 multicast traffic. There is quite a lot of practical work in network management of multicast to be done still, whether on IPv6 or IPv4, though it is seeing some deployment. QoS is probably a pre-requisite for most people to deploy multicast - until you can control multicast apps' use of your network bandwidth, it's tough to allow them to be deployed except if you control the app servers very tightly.
I think the killer apps for IPv6 are:
* Address Space - this will drag people kicking and screaming into IPv6, in order to support always-on (good point from Vint Cerf about increased duration of IP address usage), lack of massively scalable NATs (let's see someone NAT 10 million cable TV users...), cellphones/smartphones with IP, home appliances, etc.
* Getting rid of NAT hassles - trying to get applications to work through NAT is a pain and sometimes impossible by design (e.g. IPSec transport mode). This is probably not a killer reason, but will help the decision, particularly where the end host must act as a server (e.g. sending short messages or news updates to a mobile phone).
* Mergers and Automatic Network Renumbering - if two companies merge, you currently have to NAT traffic between their networks, or go through the pain of manual renumbering. IPv6 lets you auto-renumber from a single point, everything 'just works'. Since 'within the firewall' applications in a merged network would still have to cross the NAT, and many protocols such as DCOM, CORBA and so on are NAT-hostile, this may be a strong motivation.
Ultimately, address space is the single biggest reason, particularly in Asia (which was late to the Internet and got a tiny allocation, allegedly smaller than some US companies have).
http://www.ipmulticast.com/isplist.htm has a list of ISPs/ASPs supporting multicast. This site is also a good place to learn more about multicast.
The problems with multicast deployment are largely to do with it being quite hard to control (access control of senders as well as bandwidth limits on senders), and a challenge to troubleshoot. There was a good article in a recent IEEE Communications magazine about this (in fact the whole issue was about multicast).
Most routers have multicast features, but as with QoS/DiffServ features, turning them on can result in hassles if you don't have the tools to manage them properly.
Late comment, but have a look at Ogg Vorbis, an impressive sounding audio codec that is open source and patent free:
http://www.xiph.org/ogg/vorbis/index.html
From a quick look at the technical specs, it is routing IP packets (unlike so-called wavelength routers, which just switch DWDM wavelengths). They talk about doing WFQ (Weighted Fair Queuing) etc.
r .html) which is being implemented in Linux, BSD (via AltQ), Windows 2000, and most routers.
All in all, this is a pretty impressive box - other boxes from Juniper and Cisco are already available but don't scale so high. For a good article on the benchmarketing involved in terabit routers, see http://www.lightreading.com/, which also has a great piece on how to succeed in an optical networking startup ('at all costs, stop your engineers from developing a product'...)
Access lists are not very relevant on core routers - all use of access lists, e.g. for multiple-field classification (IP addresses, port numbers, IP Protocol, URL, etc.) should be done on the edge of the network, where the available CPU power per Mbps is much higher. This is part of the standard DiffServ model (details at http://www.ietf.org/html.charters/diffserv-charte
The idea of DiffServ is that the edge routers do the hard classification, then encode this in the packet in the TOS byte in a 6-bit number called the DiffServ codepoint. From that point, all routers just have to check the TOS byte to see which queue to use for a packet, which is pretty fast and much easier to do in hardware. Linux has pretty good DiffServ support - see the Advanced Routing HOWTO for details, or the article in Linux Journal this month.
Absolutely - this is like the mainframe programmer a while back who said he always wrote portable code: 'it can run on any IBM-compatible mainframes'...
It's a DirectX issue, NT has a very old version. You might want to try running Win2000 or Win98 in a VM. However, the VMware emulated hardware is quite basic - e.g. SB16 sound - so you might still have problems.
:)
VMware is not really intended for playing games at the moment - stick to dual booting until it gets better, or buy Linux games
One other datapoint - I had problems getting Active Directory to install on Win2000 RC2 native (repeatedly locked up the machine completely), so I re-installed onto a virtual disk within VMware. And of course, Active Directory ran just fine (if a little slowly, Win2000 is heavier on the machine at least compared to NT, when running on VMware).
YMMV of course...
Exactly - I suspect VMware did quite a bit of testing to find out exactly which hardware ran NT, Win98 and other OSs with high stability, then worked out which hardware was easy to emulate, and chose the intersection for their VM spec.
:1, leaving :0 as the main Linux+X display), you could make it easy to toggle into a full-screen Windows session. However, you would lose Linux/open source brownie points big time :)
Of course, the corollary for this is that if you buy an AMD PCnet NIC, SB16, and so on, it should be ultra stable at running NT...
I wouldn't really recommend NT+VMware+Linux as an elegant solution for reliable applications, but if there's an app that runs only on Windows, it's not a bad approach.
For a dedicated 'Windows' workstation, you could even run VMware instead of a window manager, in full screen mode, so the system appears to boot 'right into Windows'. If you ran this on another X display (e.g.
Re SMP - see the VMware support site, I think this is covered (though you may need to re-install NT onto a virtual disk then mount the other disks as data disks).
Re BeOS - I agree, it's a matter of getting Be interested in this. BeOS 4.5 does get halfway through the boot sequence...
The pre-installed images would be delivered as virtual disk files, i.e. they could only ever be run from under VMware. Hence it would be quite easy to get the install to work reliably (after all, NT works very well on the VMware virtual hardware).
Not quite true - OS/2 guest support for VMware is now available as 'experimental', i.e. unlikely to work that well but should do something. See their website for details, probably the Support section.
Actually you are quite close to the truth - Windows NT on top of VMware on Linux never, ever BSODs, whereas a similar NT-only system at work crashes every few weeks (happened today), while my NT laptop used to crash all the time when I used it a lot.
VMware's website has a case study of a law firm who installed Linux and VMware in order to run Windows with fewer crashes - so this is not just my experience...
One useful feature in VMware 2.0 is the 'suspend to disk' feature (like some laptops but no OS APM or ACPI support required). Currently you can only suspend to disk as part of suspending the VM.
However, it would be possible to save the Windows or other OS state to disk in an identical way every 5 minutes or so (the save to disk is quite fast if you have enough memory as it goes to Linux buffer cache). This would mean you could recover from any Windows/other crash, no matter how bad, back to your state as of N minutes ago.
This is similar to some Windows products that recover your state, but is much more likely to be bullet proof since it's done through the VM mechanism.
It would also be useful when testing out bleeding edge Linux kernels, of course...
The report IS identical, it's just the front page that is different - clicking on the Report link from the front page presented at http://www.echelonwatch.org/ gives you the same report as at this URL.
Luckily encryption issues have already been sorted out to implement virtual private networks over the Internet. See my post earlier at http://slashdot.org/comments.pl?sid=00/02/01/16522 10&cid=215 for details of how you might use IPSec for this.
One slightly odd implication is that the WLAN is a public network, so it should really be connected to the outside of your home firewall - otherwise you have to carefully IPSEC every host in your home, even the wired-only ones. Or you make the WLAN gateway into another firewall, but why have two firewalls?
Have a look at http://www.freeswan.org/ - this is a relatively complete implementation of IPSec for Linux - includes IKE for key exchanges but no PKI support yet.
I forgot to say that IPSec can encrypt all IP traffic on your WLAN, just about. Some things, such as broadcasts or multicasts, may have problems, but generally it just works.
You can use all your normal applications, and there's no need for SSH on the LAN.
I'd strongly recommend you implement IPSec with 3DES (168 bit keys) between all wireless LAN nodes. I think the WEP encryption has a fairly pathetic keylength (40 bits?) and in any case the usual arguments about open source crypto apply. Even if you use a closed source IPSec on Windows, at least IPSec has been publicly reviewed. Bruce Schneier has reviewed IPSec and was quite critical of its complexity and other problems, but admitted it is the 'least worst' option (see http://www.counterpane.com for his interesting paper on this).
I'd recommend using IPSec's ESP + authentication, and not bothering with AH, which cannot go through NATs or IP Masquerading. You can use ESP tunnels to go right through a NAT and support wired or other VPN access to your home network.
I'd prefer to use tunnel mode even within the LAN, which is also a Schneier recommendation - then you have a clear distinction between encrypted and unencrypted interfaces - if you see any packets between non-tunnelled IP addresses, you know at once they weren't encrypted.
I haven't got this set up at home yet (still waiting for a colleague to dig out his free Nokia WLAN card - they were giving them away at Interop last September) but I will real soon now. I did use BayStack 650 cards at the IETF last year, but these don't have Linux support.
In a sense, all wireless access is dialin, since anyone can just fake a MAC address, stand next to your house and get right in to your network, so strong VPN support is a Good Thing - you might want to make your Wireless LAN gateway sit outside your firewall perhaps.
There are IPSec implementations for Linux, *BSD (check out http://www.freeswan.org/ for Linux and http://www.openbsd.org/ for OpenBSD), and many commercial ones for Windows (I think PGPnet is a free VPN client for Windows but it's only available in US).
One other thing to think about is DSSS vs FHSS - these are two variants of spread spectrum (direct sequence and frequency hopping) - cards can be 802.11 compatible and use either, but the two types cannot communicate... DSSS appears to be winning for 802.11 (2 Mbps version) but there's some questionmark over the allocation of spectrum for 802.11b DSSS (but I could have mis-remembered that last bit).
Wireless LANs are definitely the future - the standards are a huge mess, though. Things to check out include HomeRF (includes SWAP), BRAN (formerly HiperLAN 2, from ETSI), Bluetooth, and more, including the whole mobile phone saga of HSCSD, GPRS, EDGE, UMTS, and so on. But 802.11 seems to have a fairly good niche in Wireless LANs, so it will probably do OK.
Some WLAN vendors are talking to telcos about rolling this out to hotels and airports - the idea is you just walk into the place, sign on to your existing ISP (if they serve that area) or put in a credit card number on a web page, and then you're on the Net at 2 Mbps or higher.
Many better-educated Indians do speak English and thus have access to the rest of the Internet. But why is it necessary for (say) a grandmother to learn English just to send email to her grandchildren? Learning English is a good thing for many people, but it's not an either/or - many people will learn English, many other people will use localised interfaces.
Check your facts before posting - most US modems work fine in the UK and other countries once you set them to blind dial (AT X3, i.e. ignore dialtone). They may have difficulty detecting engaged tones as well but this is not too important for hearing modem users.
The important issue is power supplies, which are always different (but a 110-240V supply will do fine, and suitable local adapters can usually be found), and telephone socket standards (there are literally tens of different ones... See http://www.teleadapt.com/ for examples).
Internal modems, probably ISA, are the best bet. As for the other hardware, any PC is better than none IMO - a 386 or above would be fine for browsing the Net with Lynx, or doing email, which is the key app for many people. However, a 486 or Pentium would be able to support a GUI better, allowing better internationalisation support normally.
First of all, the accepted term for translating a program's text and other conventions is 'localisation' - technically, internationalisation is the process of ensuring that software is very easily localised.
More importantly, why do so many people think that they should have the choice of using the Internet in their native language (which I'd guess is English for many people with this view), but that other people should not? Why don't you all learn written Chinese so *you* can benefit from an international outlook.
Just because English happens to be the language most used on the Internet does not mean that everyone should be forced to use it. In fact, I think it would do a lot of good to some anglophones to have to use another language occasionally.
On a practical note - for any Linux users who want a nicely internationalised + localised distribution - check out Mandrake 6.1 or later (7.0 is now downloadable). This has a great default setup that includes all the fonts required to surf to Japanese, Chinese, Korean and other sites using my normal Netscape 4.7 (English version). Even though I only know a few Chinese characters, it's great to at least be able to see the page and maybe send it to a friend who can read it (as an image attachment, no doubt...).
Mozilla (http://mozilla.org) has a great page on i18n and l10n, with some good resources.
"Added to this, modern hearing aids attach electronics directly into the inner ear, with vibration sensors outside the ear, to make people who would previously have been deaf, or almost deaf, hear perfectly again"
t ml
'Perfectly' is a significant exaggeration - assuming you are talking about cochlear implants, which are the only implant for deaf people that I've heard of, results vary significantly depending on factors such as whether the person has ever had hearing and if so, how long they ahve been deaf. There's a reasonable overview at
http://www.voice-center.com/cochlear_implants.h
Just install Junkbuster - the version at http://www.waldherr.org/junkbuster/ works well on Windows, and it's available on Linux, etc.
You can set the user-agent to whatever you want, just point IE5.5 at it.
As a bonus it can also block cookies and adverts, but these are configurable features.