SF also has decent public transport, and is mostly walkable - if you stay in Silicon Valley (not in a hotel next to the conference) you pretty much have to have a car.
I was amazed to find out that ksh on Solaris 2.6 at least doesn't support {}-based globbing. I think this is ksh88, but I would hope that more recent ksh'es have this feature.
Particularly if you have to do things on a variety of different Unix boxes, managed by various organisations, you don't usually have the luxury of choosing your own shell.
Although I use bash at home, I'm trying to restrict myself to the intersection of bash, tcsh and ksh, one of which is present on most Unix/Linux boxes these days. Not pleasant, particularly since Solaris ksh doesn't support arrow keys, but better than having to use completely different key bindings everywhere. Bash deserves some credit for emulating most of the csh !$ type features.
The nicest shell I ever used was called msh, which completed whole lines from the command line history, then individual words, then files/directories, all using TAB. zsh and co can probably do this by now, I used msh back in the mid-Eighties.
Bash and case-insensitive completion
on
To Z Or Not To Z
·
· Score: 2
bash does do case-insensitive completion, at least in version 2.03 - just put 'set completion-ignore-case on' into ~/.inputrc. It's documented in the man page.
This also works on Cygwin on Windows NT, by the way, which is by far the nicest command line environment I've used on NT.
Good to hear you are working on a tool to make this simpler!
I suspect that doing all classification in iptables (formerly ipchains) is the simplest approach - this lets you do anything that the relatively mature iptables code can do, including classifying by port numbers, src or dest IP, ICMP subtypes, and so on.
Once this is done, CBQ seems to be the queuing mechanism of choice - although it may be best to support a non-hierarchical setup of CBQ to start with.
Policy rules for QoS split nicely into conditions and actions - the conditions classify packets, and mark them (either using the internal fwmark value, or a DiffServ codepoint value in the TOS byte); then the actions take the marked packets and assign these to queues. Ultimately this can be much more powerful, e.g. the actions can be to re-route the packet to another destination etc. DiffServ marking should be optional, since in some environments the markings will actually mess things up (ipmasq does, in particular).
Linux QoS does really need a tool like this to take off, otherwise it is just too complex to use. I'd also like to see text-based and web-based tools, as most Linux routers won't be running X11 - or does your tool work on remote Linux routers via ssh, perhaps?
I've been doing IP QoS for four years, starting with ATM and RSVP and ending up using DiffServ and MPLS QoS on Cisco routers.
Some reasons for slow uptake of Linux QoS, IMO:
- IP QoS is generally not well understood - few networks have actually deployed QoS.
- there are quite a few decisions to be made before you even compose a QoS setup command (e.g. how many classes of service, which applications need QoS, how much bandwidth per app, and so on - sometimes taking months for a large company).
- the Linux QoS infrastructure is very complex and powerful - it has far more features than most commercial routers, even Cisco (which has a large number of QoS features).
- the tc(1) command to control QoS setup is complicated to use, and not installed in all distros (e.g. Mandrake 7.0). Red Hat 6.2 includes tc but doesn't include the man page, at least on my setup.
- the Linux QoS docs are highly technical rather than user-oriented, e.g. the examples involve CBQ, which is a complex mechanism that many initial users of QoS will not need.
Despite my QoS background, I find the tc(1) command line examples for CBQ rather complex - CBQ is not easy to set up, because it involves a hierarchy of traffic classes, but it can be made easier than this (see Xedia's manuals at www.xedia.com, they make a successful CBQ based router).
It would be good to have some very simple docs that provide templates for Linux QoS setup corresponding to common requirements - for example:
1. Bandwidth allocation to individual servers in a web farm - use WRR (weighted round robin, no hierarchy, just guarantees bandwidth in the event of congestion).
2. Prioritise interactive applications over downloads - most Internet users could use this one. It would also use WRR, and would simply use port numbers to prioritise telnet and maybe http (ideally only certain MIME types to avoid including HTTP downloads) into a guaranteed bandwidth class (say at least 30 Kbps on a 56K modem link); all other traffic would get the rest of the bandwidth in another class.
Alternatively, a simple set of setup shell scripts (or Webmin/Linuxconf type modules) would make life a lot easier - the key point is to limit options so it would be much easier to just say 'give bandwidth X to ports A, B, C'. Is anyone working on this?
One interesting alternative, for large-scale commercial use of Linux QoS, would be to extend CISH (a Cisco CLI emulation for Linux router setup) to cover Linux QoS by emulating Cisco QoS setup. There are a lot of people who know how to do Cisco QoS, and quite a few tools to provision QoS on hundreds to thousands of routers automatically (e.g. my company's Orchestream tool, see www.orchestream.com). By emulating Cisco QoS syntax, Linux QoS could tap into a huge pool of experience and tools.
For more info on QoS in general, see www.qosforum.com - for some more links, see www.orchestream.com/support/links.html.
My 486 laptop has been running for years as a firewall - at least before the Pentium era, laptops ran quite cool, particularly since the hard disk rarely kicks in. It's always plugged in, so power consumption from batteries is not an issue, but it does consume less power than a desktop PC, of course.
I don't have enough space currently to put another desktop PC in my home office - particularly if it had a monitor and keyboard. Laptops are ideal for monitoring firewall logs, too - I just hit the control key and can check any current port scans shown by my 'tail -f' command.
With Linux 2.0 and 2.2 (Red Hat 5.2 and 6.2 distro) I got the following PC Cards to work without any problems:
- Xircom 10/100 card - CE3
- Psion Dacom Gold Card 56K modem
- Ositech Jack of Diamonds - combo V.34 modem and 10baseT modem
I was quite stunned when the latter worked first time several years ago, as it is fairly obscure.
Software companies have a number of levels of support - first line support filters calls and answers the 'turn your PC on' type ones; second line solves the more difficult problems involving some troubleshooting; and third line is often the developers, particularly in smaller companies, who debug the nastiest problems.
As Red Hat is already a fair size, I would expect it has this sort of structure already, so that Alan Cox et al only get bothered when there's a serious problem that nobody else can debug. They probably also do a lot of new development drive by particular customers, which may count as 'support' in a sense.
I was using OpenBSD 2.8 (actually a snapshot a week beforehand) - it might be something to do with the particular cards (3Com 3C574BT, which was a nightmare though meant to be supported) or the laptop.
I'm sure OpenBSD does work on laptops but I've not found it easy to get the PC Cards working - the rest of the install was fine, though.
I have an old Thinkpad 486/75 laptop, and it works fine as a Linux router/firewall. For a long time I had one ethernet card and one modem card (left over from when it was used as a laptop). I then bought another ethernet card to talk to an ADSL/ethernet router - it has no problem working at 1 Mbps and could probably go faster (many low end Cisco routers are very low powered).
It's more hassle than a dedicated firewall box to set up, but it's cheaper and I really couldn't use a 640x480 screen laptop for anything else these days. Most importantly, it's very flexible - I can write my own script to analyse logs, install extra tools for intrusion detection, and so on.
The biggest pain is trying to get OpenBSD to work with PCMCIA cards - haven't yet managed to get this working, so if you want OpenBSD you may be better off with a desktop/tower type PC.
I've recently been trying to install Solaris 8 under VMware, and after two attempts taking 5 hours have given up for the moment, despite reading gallons of Solaris FAQs and web pages. By contrast, the many Linux installs I have done are incredibly hassle free and typically take an hour.
If you want to use Forte and Java, it's not surprising that Solaris x86 works well (after all, all three come from Sun), but I find the basic Solaris install is too vanilla - I need to install bash, less, vim, and so on, just to get it usable. The Solaris package management is not too hot either - it's very hard to find out which files belong to a package (until you find a specific file under/var/sadm), and some packages are missing dependencies.
Linux does have problems, and some installs can be frustrating, but in my experience Solaris is much harder to get going. Also, there is not as much tech support info on the Net for Solaris, unless you buy a support contract for Solaris to get access to the SunSolve knowledge base. (At least Microsoft provides free Net access to its KB).
"What we really need is browsers to come with a warning before anyone submits a sixteen digit number to a form on a server running IIS"
Why not use a proxy to trap this? It's tempting to do a Junkbuster patch - just needs a separate lookup on www.netcraft.com (hopefully cacheable). Of course, non-IIS servers can have holes too, so it would be useful to generalise this to look up against server-auditing services (if there are any that can be trusted).
Re the headers - you seem to be assuming that most IPv6 packets will have hop-by-hop options headers, when in fact this should be a tiny minority of packets (most packets will not use the special IPv6 features for source routing etc). The main IPv6 header is very regular - you can have extra headers, pointed to by the next-header field, in which case you have extra overhead.
Re edge routers in software vs. hardware - I'm mainly talking about ISP's existing provider-edge routers (7500s and so on, quite often). Most of the deployed routers are software-based, so they are covered by the MPLS approach.
Of course, there are many hardware-based provider-edge routers as well, but these will be covered by hardware updates before too long (see http://www.cisco.com/warp/public/732/ipv6/IP_Vers6 _SD_0622.pdf - this is Cisco's IPv6 roadmap, which will cover IPv6 hardware acceleration in Phase II, under 'CEFv6'). Even with software-based Cisco routers, it's probably waiting for CEFv6 (Cisco Express Forwarding) in Phase II of the Cisco roadmap, as until then IPv6 is process-switched (i.e. slow path).
Once you have CEFv6, most IPv6 traffic should have the performance of IPv4 - not sure how the hop-by-hop options headers will affect this but I don't believe these will be common.
Re MPLS - it's not quite 'the terminal stage of virtual circuit networking'! It re-uses the data plane (i.e. label-based forwarding) but the control plane is normally just an IP routing process (some see this as a way of turning ATM switches into IP routers...). By default, MPLS is NOT circuit based at all - labels are assigned using LDP (label distribution protocol), which piggybacks on the IP routing protocol you are using. This lack of circuits is one reason why MPLS VPNs are very scalable (see www.orchestream.com, my company's site, for lots more info here).
You can use MPLS for traffic engineering, which requires laying down circuits, but you ONLY create circuits as the exception, to direct traffic somewhere other than the shortest-path route. Most traffic in a traffic engineered MPLS network may still be IP routed using MPLS labels that are not attached to circuits (aka label switched paths). See www.mplsforum.com.
MPLS does let you do quite a bit more than IP - it's really just a very thin encapsulation technology (i.e. a 32 bit label is the encapsulation overhead), so you can use it for VPNs (much more scalable than GRE tunnels or meshes of FR PVCs), Voice over MPLS (lower overhead than IP/UDP/RTP), Frame over MPLS (more scalable), and so on.
In particular, MPLS has a 3 bit EXP field that is used for CoS levels (i.e. DiffServ style QoS) - most MPLS edge nodes should copy the IP Precedence into the EXP field. If this is not enough, you can steer traffic onto different labels depending on CoS levels, and with MPLS traffic engineering you can reserve bandwidth for a given MPLS label switched path ('circuit') if needed.
You do need IP routing on every MPLS node, but only on the control plane - IP forwarding is only needed on edge nodes. I wouldn't suggest MPLS is necessarily the best or only way to deploy IPv6, but it is a great way to scale IPv6 backbones in the absence of IPv6-specific forwarding hardware, and it does have useful features that will apply to IPv4 and IPv6 traffic identically (hence MPLS can be justified for existing IPv4 traffic while enabling IPv6).
You are right, it's only the hop-by-hop options that matter - I was being a bit lazy in not specifying this, but the point is that these options only incur an overhead when they are there - if there's no next-header pointer, there's no extra work.
First of all, the IPv6 header is actually more regular than the IPv4 header - fewer fields, and only twice the size of IPv6 despite addresses that are four times larger. Also, the routing tables for IPv6 are supposed to be more regular, so the performance impact on software-based routers may not be that much.
The vast majority of IPv6 packets will not have options - yes, they need to be looked at if present, but in that case you just dump the packet into a slow path. Also, MPLS will help here (see below) - the packet should only hit the slow path on lower end routers.
As for core routers that use forwarding ASICs - the answer is to implement MPLS, starting on edge routers that forward IPv6 in software, and attach MPLS labels. The core routers ONLY see the 32 bit MPLS label, so there is no problem about forwarding IPv6 just as efficiently as IPv4, once it is MPLS labelled. The core routers need to run IPv6 routing processes, but that's just on the main CPU.
MPLS is already deployed in ISP and telco IP networks - it is currently used for traffic engineering (balancing traffic loads over the network) and MPLS VPNs, and the same technique will be used to carry ATM, Frame Relay, Ethernet and SONET.
In the longer term, new routers will come on the market with smart enough ASICs and network processors to handle IPv6 with no reduction in forwarding rates, but MPLS will be useful for those ISPs that want its extra features.
Many people seem to use NAT for security purposes, because it makes it harder for outsiders to connect to internal machines. Of course, NAT is not meant for this, and has potential holes (e.g. if the NAT software fails it may just forward packets straight through, as has happened on at least some NAT boxes), but that's what a lot of people think.
Until people manage their host and firewall security a lot better, many sites may just stick with NAT because it's what they know, removing a key benefit of using IPv6. So perhaps improved security processes and technology are a prerequisite for IPv6 deployments.
This is probably the biggest myth of IPv6 - it has precisely one feature beyond what IPv4 supports, the 16 bit flow label field in the IPv6 header, that relates to QoS.
Deploying IPv4 QoS is possible today - I work for a company that makes software to enable QoS in routers, amongst other things, and am helping customers do this. The key approaches are DiffServ (easy to deploy, softer QoS), and RSVP (harder to deploy, harder QoS, and I don't know any real networks that have deployed this).
The IPv6 flow label reduces the load on core routers where RSVP has been deployed, by caching the result of an earlier classification decision (i.e. matching packets against IP adddresses, port numbers, etc). However, it's hardly a big step forward for QoS if you are using DiffServ as most networks do.
What's more important for QoS is that IPv6 will (eventually) make NATs much less popular. Trying to classify NATed traffic is a nightmare, of course, and IPv6 should make things easier.
My company also does MPLS stuff - interestingly, this will help IPv6 deployment, because the big fast core routers will NOT need to have their forwarding hardware upgraded to forward IPv6 packets. MPLS labels packets near the edge of the network, and once labelled the packets are forwarded using ONLY the 32 bit MPLS label. Hence the IPv6 headers are only inspected on the edge router for the MPLS network.
The result is that the core routers only need to run IPv6 routing software, not IPv6 forwarding - hence no need to replace those ASICs. The edge routers are typically small enough that they should be able to run IPv6 forwarding in software.
Of course, as someone else already pointed out, there is still a lot of work before the ISPs' routers get fully upgraded with the entire set of add-on protocols - routing, multicast, PPP, RADIUS, IP-over-ATM, and so on.
Opera runs fine on a 486; even a 486SX/25 with 8 MB was usable (just). On a P133, Opera should just fly - see www.opera.com. It is now free if you don't mind banner ads, or $39 to register and turn them off.
Junkbuster is very useful, but it limits the browser to HTTP/1.0 in order to simplify its code. I'd like to see browsers building in this sort of functionality (ideally as a module of course) so they could make it work with HTTP/1.1 and thereby go faster.
Learning another language is a great idea, particularly if you work with computers (sys admin or programming), but it's a little harsh to expect ordinary Basque speakers to do so.
There are lots of OSs that support Basque, including MacOS, Windows and Linux - did you try looking?
I did a quick seach for Basque & Linux and found the following Basque language resources at Open Directory: http://www.dmoz.org/World/Euskara/Informatika/Linu x/. Info on other Basque localisations is at http://www.dmoz.org/World/Euskara/Informatika/
Also, KDE appears to have a Basque localised version: http://rpmfind.net/linux/rpm2html/search.php?query =kde-i18n-Basque.
'Having the same GUI everywhere' is a seductive idea, but it doesn't necessarily work - this is why Microsoft's Palm-size format (now called Pocket PC) has largely failed to get much market share. They tried valiantly to get as many Windows features, and the full GUI with Start button, into this tiny form factor, then discovered that it took far too many stylus taps to get anywhere - hence they have simplified things radically in the latest Pocket PC version of Windows CE.
By the way, Wince already runs on many different processors, and the embedded variant is not exactly new. By all accounts, though, embedded manufacturers are not leaping to use Wince - Linux and traditional RTOSs are providing some tough competition.
Slashdot Mirror
SF also has decent public transport, and is mostly walkable - if you stay in Silicon Valley (not in a hotel next to the conference) you pretty much have to have a car.
I was amazed to find out that ksh on Solaris 2.6 at least doesn't support {}-based globbing. I think this is ksh88, but I would hope that more recent ksh'es have this feature.
Particularly if you have to do things on a variety of different Unix boxes, managed by various organisations, you don't usually have the luxury of choosing your own shell.
Although I use bash at home, I'm trying to restrict myself to the intersection of bash, tcsh and ksh, one of which is present on most Unix/Linux boxes these days. Not pleasant, particularly since Solaris ksh doesn't support arrow keys, but better than having to use completely different key bindings everywhere. Bash deserves some credit for emulating most of the csh !$ type features.
The nicest shell I ever used was called msh, which completed whole lines from the command line history, then individual words, then files/directories, all using TAB. zsh and co can probably do this by now, I used msh back in the mid-Eighties.
bash does do case-insensitive completion, at least in version 2.03 - just put 'set completion-ignore-case on' into ~/.inputrc. It's documented in the man page.
This also works on Cygwin on Windows NT, by the way, which is by far the nicest command line environment I've used on NT.
Good to hear you are working on a tool to make this simpler!
I suspect that doing all classification in iptables (formerly ipchains) is the simplest approach - this lets you do anything that the relatively mature iptables code can do, including classifying by port numbers, src or dest IP, ICMP subtypes, and so on.
Once this is done, CBQ seems to be the queuing mechanism of choice - although it may be best to support a non-hierarchical setup of CBQ to start with.
Policy rules for QoS split nicely into conditions and actions - the conditions classify packets, and mark them (either using the internal fwmark value, or a DiffServ codepoint value in the TOS byte); then the actions take the marked packets and assign these to queues. Ultimately this can be much more powerful, e.g. the actions can be to re-route the packet to another destination etc. DiffServ marking should be optional, since in some environments the markings will actually mess things up (ipmasq does, in particular).
Linux QoS does really need a tool like this to take off, otherwise it is just too complex to use. I'd also like to see text-based and web-based tools, as most Linux routers won't be running X11 - or does your tool work on remote Linux routers via ssh, perhaps?
I've been doing IP QoS for four years, starting with ATM and RSVP and ending up using DiffServ and MPLS QoS on Cisco routers.
Some reasons for slow uptake of Linux QoS, IMO:
- IP QoS is generally not well understood - few networks have actually deployed QoS.
- there are quite a few decisions to be made before you even compose a QoS setup command (e.g. how many classes of service, which applications need QoS, how much bandwidth per app, and so on - sometimes taking months for a large company).
- the Linux QoS infrastructure is very complex and powerful - it has far more features than most commercial routers, even Cisco (which has a large number of QoS features).
- the tc(1) command to control QoS setup is complicated to use, and not installed in all distros (e.g. Mandrake 7.0). Red Hat 6.2 includes tc but doesn't include the man page, at least on my setup.
- the Linux QoS docs are highly technical rather than user-oriented, e.g. the examples involve CBQ, which is a complex mechanism that many initial users of QoS will not need.
Despite my QoS background, I find the tc(1) command line examples for CBQ rather complex - CBQ is not easy to set up, because it involves a hierarchy of traffic classes, but it can be made easier than this (see Xedia's manuals at www.xedia.com, they make a successful CBQ based router).
It would be good to have some very simple docs that provide templates for Linux QoS setup corresponding to common requirements - for example:
1. Bandwidth allocation to individual servers in a web farm - use WRR (weighted round robin, no hierarchy, just guarantees bandwidth in the event of congestion).
2. Prioritise interactive applications over downloads - most Internet users could use this one. It would also use WRR, and would simply use port numbers to prioritise telnet and maybe http (ideally only certain MIME types to avoid including HTTP downloads) into a guaranteed bandwidth class (say at least 30 Kbps on a 56K modem link); all other traffic would get the rest of the bandwidth in another class.
Alternatively, a simple set of setup shell scripts (or Webmin/Linuxconf type modules) would make life a lot easier - the key point is to limit options so it would be much easier to just say 'give bandwidth X to ports A, B, C'. Is anyone working on this?
One interesting alternative, for large-scale commercial use of Linux QoS, would be to extend CISH (a Cisco CLI emulation for Linux router setup) to cover Linux QoS by emulating Cisco QoS setup. There are a lot of people who know how to do Cisco QoS, and quite a few tools to provision QoS on hundreds to thousands of routers automatically (e.g. my company's Orchestream tool, see www.orchestream.com). By emulating Cisco QoS syntax, Linux QoS could tap into a huge pool of experience and tools.
For more info on QoS in general, see www.qosforum.com - for some more links, see www.orchestream.com/support/links.html.
My 486 laptop has been running for years as a firewall - at least before the Pentium era, laptops ran quite cool, particularly since the hard disk rarely kicks in. It's always plugged in, so power consumption from batteries is not an issue, but it does consume less power than a desktop PC, of course.
I don't have enough space currently to put another desktop PC in my home office - particularly if it had a monitor and keyboard. Laptops are ideal for monitoring firewall logs, too - I just hit the control key and can check any current port scans shown by my 'tail -f' command.
With Linux 2.0 and 2.2 (Red Hat 5.2 and 6.2 distro) I got the following PC Cards to work without any problems:
- Xircom 10/100 card - CE3
- Psion Dacom Gold Card 56K modem
- Ositech Jack of Diamonds - combo V.34 modem and 10baseT modem
I was quite stunned when the latter worked first time several years ago, as it is fairly obscure.
Software companies have a number of levels of support - first line support filters calls and answers the 'turn your PC on' type ones; second line solves the more difficult problems involving some troubleshooting; and third line is often the developers, particularly in smaller companies, who debug the nastiest problems.
As Red Hat is already a fair size, I would expect it has this sort of structure already, so that Alan Cox et al only get bothered when there's a serious problem that nobody else can debug. They probably also do a lot of new development drive by particular customers, which may count as 'support' in a sense.
I was using OpenBSD 2.8 (actually a snapshot a week beforehand) - it might be something to do with the particular cards (3Com 3C574BT, which was a nightmare though meant to be supported) or the laptop.
I'm sure OpenBSD does work on laptops but I've not found it easy to get the PC Cards working - the rest of the install was fine, though.
I have an old Thinkpad 486/75 laptop, and it works fine as a Linux router/firewall. For a long time I had one ethernet card and one modem card (left over from when it was used as a laptop). I then bought another ethernet card to talk to an ADSL/ethernet router - it has no problem working at 1 Mbps and could probably go faster (many low end Cisco routers are very low powered).
It's more hassle than a dedicated firewall box to set up, but it's cheaper and I really couldn't use a 640x480 screen laptop for anything else these days. Most importantly, it's very flexible - I can write my own script to analyse logs, install extra tools for intrusion detection, and so on.
The biggest pain is trying to get OpenBSD to work with PCMCIA cards - haven't yet managed to get this working, so if you want OpenBSD you may be better off with a desktop/tower type PC.
I've recently been trying to install Solaris 8 under VMware, and after two attempts taking 5 hours have given up for the moment, despite reading gallons of Solaris FAQs and web pages. By contrast, the many Linux installs I have done are incredibly hassle free and typically take an hour.
/var/sadm), and some packages are missing dependencies.
If you want to use Forte and Java, it's not surprising that Solaris x86 works well (after all, all three come from Sun), but I find the basic Solaris install is too vanilla - I need to install bash, less, vim, and so on, just to get it usable. The Solaris package management is not too hot either - it's very hard to find out which files belong to a package (until you find a specific file under
Linux does have problems, and some installs can be frustrating, but in my experience Solaris is much harder to get going. Also, there is not as much tech support info on the Net for Solaris, unless you buy a support contract for Solaris to get access to the SunSolve knowledge base. (At least Microsoft provides free Net access to its KB).
"What we really need is browsers to come with a warning before anyone submits a sixteen digit number to a form on a server running IIS"
Why not use a proxy to trap this? It's tempting to do a Junkbuster patch - just needs a separate lookup on www.netcraft.com (hopefully cacheable). Of course, non-IIS servers can have holes too, so it would be useful to generalise this to look up against server-auditing services (if there are any that can be trusted).
You must be talking about the Oracle Applications suite (which is at version 11i now), not the Oracle RDBMS and tools, which are at version 8i.
The article was asking about the RDBMS, not the Apps.
Re the headers - you seem to be assuming that most IPv6 packets will have hop-by-hop options headers, when in fact this should be a tiny minority of packets (most packets will not use the special IPv6 features for source routing etc). The main IPv6 header is very regular - you can have extra headers, pointed to by the next-header field, in which case you have extra overhead.
6 _SD_0622.pdf - this is Cisco's IPv6 roadmap, which will cover IPv6 hardware acceleration in Phase II, under 'CEFv6'). Even with software-based Cisco routers, it's probably waiting for CEFv6 (Cisco Express Forwarding) in Phase II of the Cisco roadmap, as until then IPv6 is process-switched (i.e. slow path).
Re edge routers in software vs. hardware - I'm mainly talking about ISP's existing provider-edge routers (7500s and so on, quite often). Most of the deployed routers are software-based, so they are covered by the MPLS approach.
Of course, there are many hardware-based provider-edge routers as well, but these will be covered by hardware updates before too long (see http://www.cisco.com/warp/public/732/ipv6/IP_Vers
Once you have CEFv6, most IPv6 traffic should have the performance of IPv4 - not sure how the hop-by-hop options headers will affect this but I don't believe these will be common.
Re MPLS - it's not quite 'the terminal stage of virtual circuit networking'! It re-uses the data plane (i.e. label-based forwarding) but the control plane is normally just an IP routing process (some see this as a way of turning ATM switches into IP routers...). By default, MPLS is NOT circuit based at all - labels are assigned using LDP (label distribution protocol), which piggybacks on the IP routing protocol you are using. This lack of circuits is one reason why MPLS VPNs are very scalable (see www.orchestream.com, my company's site, for lots more info here).
You can use MPLS for traffic engineering, which requires laying down circuits, but you ONLY create circuits as the exception, to direct traffic somewhere other than the shortest-path route. Most traffic in a traffic engineered MPLS network may still be IP routed using MPLS labels that are not attached to circuits (aka label switched paths). See www.mplsforum.com.
MPLS does let you do quite a bit more than IP - it's really just a very thin encapsulation technology (i.e. a 32 bit label is the encapsulation overhead), so you can use it for VPNs (much more scalable than GRE tunnels or meshes of FR PVCs), Voice over MPLS (lower overhead than IP/UDP/RTP), Frame over MPLS (more scalable), and so on.
In particular, MPLS has a 3 bit EXP field that is used for CoS levels (i.e. DiffServ style QoS) - most MPLS edge nodes should copy the IP Precedence into the EXP field. If this is not enough, you can steer traffic onto different labels depending on CoS levels, and with MPLS traffic engineering you can reserve bandwidth for a given MPLS label switched path ('circuit') if needed.
You do need IP routing on every MPLS node, but only on the control plane - IP forwarding is only needed on edge nodes. I wouldn't suggest MPLS is necessarily the best or only way to deploy IPv6, but it is a great way to scale IPv6 backbones in the absence of IPv6-specific forwarding hardware, and it does have useful features that will apply to IPv4 and IPv6 traffic identically (hence MPLS can be justified for existing IPv4 traffic while enabling IPv6).
You are right, it's only the hop-by-hop options that matter - I was being a bit lazy in not specifying this, but the point is that these options only incur an overhead when they are there - if there's no next-header pointer, there's no extra work.
IPSec is not enabled in the default install - the point is that only holes that are 'on by default' are counted by the home page statement.
First of all, the IPv6 header is actually more regular than the IPv4 header - fewer fields, and only twice the size of IPv6 despite addresses that are four times larger. Also, the routing tables for IPv6 are supposed to be more regular, so the performance impact on software-based routers may not be that much.
The vast majority of IPv6 packets will not have options - yes, they need to be looked at if present, but in that case you just dump the packet into a slow path. Also, MPLS will help here (see below) - the packet should only hit the slow path on lower end routers.
As for core routers that use forwarding ASICs - the answer is to implement MPLS, starting on edge routers that forward IPv6 in software, and attach MPLS labels. The core routers ONLY see the 32 bit MPLS label, so there is no problem about forwarding IPv6 just as efficiently as IPv4, once it is MPLS labelled. The core routers need to run IPv6 routing processes, but that's just on the main CPU.
MPLS is already deployed in ISP and telco IP networks - it is currently used for traffic engineering (balancing traffic loads over the network) and MPLS VPNs, and the same technique will be used to carry ATM, Frame Relay, Ethernet and SONET.
In the longer term, new routers will come on the market with smart enough ASICs and network processors to handle IPv6 with no reduction in forwarding rates, but MPLS will be useful for those ISPs that want its extra features.
Many people seem to use NAT for security purposes, because it makes it harder for outsiders to connect to internal machines. Of course, NAT is not meant for this, and has potential holes (e.g. if the NAT software fails it may just forward packets straight through, as has happened on at least some NAT boxes), but that's what a lot of people think.
Until people manage their host and firewall security a lot better, many sites may just stick with NAT because it's what they know, removing a key benefit of using IPv6. So perhaps improved security processes and technology are a prerequisite for IPv6 deployments.
This is probably the biggest myth of IPv6 - it has precisely one feature beyond what IPv4 supports, the 16 bit flow label field in the IPv6 header, that relates to QoS.
Deploying IPv4 QoS is possible today - I work for a company that makes software to enable QoS in routers, amongst other things, and am helping customers do this. The key approaches are DiffServ (easy to deploy, softer QoS), and RSVP (harder to deploy, harder QoS, and I don't know any real networks that have deployed this).
The IPv6 flow label reduces the load on core routers where RSVP has been deployed, by caching the result of an earlier classification decision (i.e. matching packets against IP adddresses, port numbers, etc). However, it's hardly a big step forward for QoS if you are using DiffServ as most networks do.
What's more important for QoS is that IPv6 will (eventually) make NATs much less popular. Trying to classify NATed traffic is a nightmare, of course, and IPv6 should make things easier.
My company also does MPLS stuff - interestingly, this will help IPv6 deployment, because the big fast core routers will NOT need to have their forwarding hardware upgraded to forward IPv6 packets. MPLS labels packets near the edge of the network, and once labelled the packets are forwarded using ONLY the 32 bit MPLS label. Hence the IPv6 headers are only inspected on the edge router for the MPLS network.
The result is that the core routers only need to run IPv6 routing software, not IPv6 forwarding - hence no need to replace those ASICs. The edge routers are typically small enough that they should be able to run IPv6 forwarding in software.
Of course, as someone else already pointed out, there is still a lot of work before the ISPs' routers get fully upgraded with the entire set of add-on protocols - routing, multicast, PPP, RADIUS, IP-over-ATM, and so on.
Opera makes it very easy to overide the web page's CSS settings - just click one button to flip to a user-controlled CSS.
Opera runs fine on a 486; even a 486SX/25 with 8 MB was usable (just). On a P133, Opera should just fly - see www.opera.com. It is now free if you don't mind banner ads, or $39 to register and turn them off.
Junkbuster is very useful, but it limits the browser to HTTP/1.0 in order to simplify its code. I'd like to see browsers building in this sort of functionality (ideally as a module of course) so they could make it work with HTTP/1.1 and thereby go faster.
Learning another language is a great idea, particularly if you work with computers (sys admin or programming), but it's a little harsh to expect ordinary Basque speakers to do so.
u x/. Info on other Basque localisations is at http://www.dmoz.org/World/Euskara/Informatika/
y =kde-i18n-Basque.
There are lots of OSs that support Basque, including MacOS, Windows and Linux - did you try looking?
I did a quick seach for Basque & Linux and found the following Basque language resources at Open Directory: http://www.dmoz.org/World/Euskara/Informatika/Lin
Also, KDE appears to have a Basque localised version: http://rpmfind.net/linux/rpm2html/search.php?quer
'Having the same GUI everywhere' is a seductive idea, but it doesn't necessarily work - this is why Microsoft's Palm-size format (now called Pocket PC) has largely failed to get much market share. They tried valiantly to get as many Windows features, and the full GUI with Start button, into this tiny form factor, then discovered that it took far too many stylus taps to get anywhere - hence they have simplified things radically in the latest Pocket PC version of Windows CE.
By the way, Wince already runs on many different processors, and the embedded variant is not exactly new. By all accounts, though, embedded manufacturers are not leaping to use Wince - Linux and traditional RTOSs are providing some tough competition.