Actually, the Palm guarantee is valid world wide, no matter where you bought your Palm. One of the good things about the device.
Re:Its not only about address space (Was: Why IPv6
on
IANA Deploying IPv6
·
· Score: 3
Certainly routing tables should be limited in size with IPv6, which is a good thing but unlikely to make packet forwarding faster.
QoS I think is in the main header (Class byte and Flow Label). As for packet spoofing, IPv6 simply makes IPsec mandatory, whereas it is optional with IPv4 - however, this is an important step. Of course, IPsec means that much traffic is encrypted (potentially) making it harder to do QoS except by letting the host do its own CoS marking and/or RSVP reservations (which let you guarantee bandwidth end to end IF the network has RSVP enabled).
The interesting stuff for Linux here is Linux-Diffserv and the Linux port of RSVPD, which enable the host to do CoS marking and RSVP reservations. However, unlike Win2000, the *nix world does not have a unified QoS API - some work to be done there for *nix to remain competitive IMO.
There is a lot of work going on in the IETF around QoS, CoS, and policy (i.e. rules that govern which apps/users get which QoS/CoS). Werner Almesberger, the Linux Diffserv guy, is at the IETF this week (as I am) and gave a presentation at the Diffserv deployment BOF.
Interestingly, Linux is way ahead of most OSs and routers in its Diffserv implementation, and apparently it can fill an OC-3 (155 Mbps optical) line while doing CBQ queuing (flexible allocation of bandwidth, see www.xedia.com for links), with 12,000 policy rultes. For those who are not in the CoS business, this performance is extremely impressive compared to some commercial routers - just buy a cheap headless PC and you have a $1000 access router with Diffserv CoS, which can also do firewalling, IPsec VPNs, etc.
If anyone's doing trials of Diffserv and wants a tool to manage policy rules for CoS efficiently, email me:)
Unicast, Anycast and Multicast; CoS and flowlabels
on
IANA Deploying IPv6
·
· Score: 3
Some confusion here:)
- Unicast is when a packet goes to exactly one destination and is what IPv4 uses most of the time (e.g. for http etc)
- Multicast is as konstant said, you send out one packet to a 'group address' and it gets replicated only where necessary - generally each link sees only one copy of each packet, so it's an efficient way to send audio, video or even files to a large audience. This is also in IPv4.
- Anycast is new in IPv6 - as I understand it, it lets you specify that any of a set of hosts can get the packet (but not all of them, as in multicast). It's useful for lots of things such as load balancing across servers - not sure if it does topologically-distant load balancing but it would be handy if it does.
One other misconception: IPv6 has two main features for class of service / quality of service, both in the IPv6 header:
- Traffic Class - single byte, equivalent to the IPv4 Type of Service byte, carries the class of service - will be a diffserv codepoint (number) once this is standardised, as is happening quite fast. Same codepoints work over IPv4 and IPv6 networks. Typically you assign different codepoints to VoIP, mission-critical apps, web browsing, etc - many apps share the same CoS.
- Flow Label - this is designed to make RSVP work better, allowing a single flow (e.g. ftp session) to be given a unique ID so that routers downstream of this label assignment can more quickly recognise (classify) packets in this flow (rather than looking at IP addresses, TCP/UDP port numbers, and IP protocol).
For more information on QoS/CoS (though not IPv6 specific) see www.qosforum.org, or the www.orchestream.com links page.
The interesting part was how one operation in the transaction (the debit) could be done even though the other operation failed. In the world of online transaction processing (OLTP), a transaction has to be atomic no matter how many operations it covers, even if they are on different systems (using two-phase commit or similar). In other words, if one operation completes and the other fails, the whole transaction is reversed out, undoing the one that completed.
Examples of systems that do this are IBM's CICS (works on *nix and mainframes) and Bea Tuxedo (www.beasys.com).
If the people doing this system had used a transaction based approach, this would never have happened.
'IPv5' was called ST2 - a connection-oriented protocol that supported QoS. However I don't think anyone really uses it now with a few specialised non-Internet exceptions.
A quick search on Google.com revealed the following beta done in Norway, so it is usable worldwide - not sure if it is just a library but it should be usable by mail program developers.
http://www.pasta.cs.uit.no/~perm/PASTA/pilot/
There was also mention of some work done in US/Canada, for those who live there, in
I agree - in the meantime, there is good shareware for PGP email integration on Windows called Mollusc, which supports Netscape and almost every Windows emailer and the author can very rapidly support off-beat email programs.
I used to use this quite a lot when I was using PGP on Windows. For attachments, the simplest thing is just to encrypt the file using PGP of course.
All very reasonable apart from the rules on installing new apps - why on earth should installing apps break an OS? With NT, this is unfortunately sometimes the case, but it shouldn't be.
We use NT systems extensively at my company, with quite competent administration, and the servers and workstations still occasionally crash (or become ultra slow and require a reboot - probably a memory leak or similar).
I have yet to see a Linux system crash, and don't even know what an 'oops' message looks like - by contrast, my mother, who is retired, has had to become horribly familiar with NT BSODs so that she can accurately report problems...
My one criticism of Linux as a server is its recovery from power failures - maybe our Linux boxes weren't set up properly, but they took a long time to be recovered after a power failure, even the one with an ICP Vortex RAID controller. However, logging/journalling filesystems a la XFS should solve this, and we probably didn't have enough UPS capacity to allow a clean shutdown, so it could probably have been avoided. I don't know all the details as I'm not a sysadmin, but we do have a very competent BSD/Linux sysadmin here.
I don't know about C'T's biases, but submitting plain text files is very common for magazine and newspaper contributions - any formatting that has been done by the author is frequently useless, and of course if they use a different version of Word or something else altogether it is just a source of conversion hassles.
There are versions of Linux in a vast array of languages, from French and German to Korean, Chinese, Japanese and Icelandic - the latter I think illustrates how open source is crucial to smaller language populations, since Microsoft very publicly refused to do an Icelandic version of Windows.
Our NT sysadmins say that MS currently recommends you stay with SP4 unless there is a particular problem with it that's fixed with SP5.
I agreed with the earlier comment that the tests should really run for many weeks at a time - I've just spent 2 weekends debugging an NT box that keeps crashing, but more to the point, if SP5 has performance features they are no use if they cause crashes during a test like this.
I think the general model will be to use ext2 by default for a while, but ultimately reiserfs looks very interesting for most 'desktop' style usage of Linux (including servers for desktop systems), e.g. mail, news, reasonable size databases, etc.)
XFS looks more appropriate for large databases with huge disk sizes and file sizes (and stringent time-to-recover requirements), as well as for huge multimedia files (which SGI of course is traditionally focused on).
I don't think a merger of reiserfs and XFS is practical or desirable. What might be very useful is a tool that takes performance logs (e.g. sar(1) output on disk I/O) and scans your filesystems, then recommends which files should be on which filesystems.
One more blue-sky idea is based on the observation that you have to move the file to a different part of the filesystem tree to change it from (say) ext2 to reiserfs. It would be very handy if some user-level daemons could automagically migrate files to different filesystems based on sizes and usage patterns - just as hierarchical storage systems move files from disk to tape etc, this would change the underlying implementation without the user having to worry about this.
However, this would require you to separate the filesystem namespace entirely from the actual underlying filesystem, on a per file basis perhaps, which introduces all sorts of complications. On a much coarser level of granularity, this is somewhat analogous to having a logical volume implemented on top of various physical disks. But this is probably a feature for Linux 5.1:)
>... There is no such thing as a DSL modem, just like there isn't such thing as > an ISDN modem. The correct name is ATU/R or Adaptive Transceiver Unit/Remote.
The IEEE Communications article, by a technical architect who is involved in the ADSL Forum, talks about 'G.Lite modems' a lot, as well as ADSL modems. It also mentions ATU-R, where R=Residential, and ATU-C, C=Central, and defines both as ADSL modems (though the latter is usually integrated into the DSLAM = DSL Access Multiplexer).
Anyway, I think the term modem is appropriate - it really does use similar DSP and analogue technologies to POTS modems, and has similar analogue problems with crosstalk, noise, etc.
G.Lite is very new and you clearly have ADSL since there was installation work at your site - although it shares the central office problems of ADSL, it does at least mean you can buy and install the G.Lite modem yourself, just plugging it into the phone socket according to this article. Although you might need installation help, at least you don't have to buy it from the local telco.
I'm not too familiar with DMDS but from a quick scan of the webpage it seems to map IP multicast onto ATM in an intelligent way. Certainly more IP-centric than the PPP over ATM approach, but it's really solving a different problem, focusing on multicast.
The use of PPP and ATM appears due to the rigid regulatory separation between layer 1&2 services (from the xDSL provider) and layer 3+ services (from a content provider, network service provider). ATM lets the xDSL provider guarantee a certain QoS from the service provider direct to the home, preventing complaints of favouring one provider over another when both serve a given home.
PPP runs over many leased lines anyway, so it's a sort of invisible tax - but I agree about the ATM cell tax. There is work going on in the IETF on something called ISSLOW, which is designed to fragment at the PPP level where needed - the idea is that you get down to ATM-like 'cell' sizes, but only need to do this on links where there is little bandwidth and you are mixing voice/video with data. The aim is to fragment the 1500 byte FTP packet so that the small voice packets can get in there without excessive delay (leading to jitter and crap voice quality).
If you run ISSLOW everywhere it is worse than ATM, but on a single slow link it makes sense - on fast links a 1500 byte packet transmits in a vanishingly small time so it won't delay the VoIP packet (as long as the VoIP stuff gets to the front of the queue so to speak).
For more details on QoS see www.qosforum.org, or the IETF site at www.ietf.org (check the diffserv, intserv, rsvp and rap efforts).
G.Lite doesn't require a truck roll (i.e. a visit from an engineer), since it doesn't have a 'splitter' that separates the POTS (Plain Old Telephone System, i.e. phones, etc.) frequencies from the xDSL frequencies.
This means you can just buy a G.Lite modem from whoever, plug it in, and start working (in theory) - the modem ideally is an analogue modem for when xDSL breaks and also so it can automagically request xDSL service for you via the modem link when first installed.
You may also be able to get G.Lite service at some speed (maybe lower than ADSL) beyond 18,000 feet from the central office.
The price you pay for this is that any POTS equipment's hook-on/off activity can disrupt the G.Lite modem (yes, it really is a modem:) and require both ends to do a 'fast retrain' lasting 1.5 seconds. Also badly-behaved POTS equipment could disrupt things even more, and in-home wiring quality is a big factor.
My prediction, FWIW: people will get sufficiently annoyed with the G.Lite data getting disrupted that they'll convert their whole house to Voice over IP - either buying IP phones and using in-home networking over the existing phone wiring. Or they can keep their existing phones and wiring and just have a VoIP card in their Linux firewall that acts as a home PABX as well - park, hold, etc. Though hopefully with a nicer user interface... The end result is that there is no POTS voice whatsoever, everything is IP data or VoIP, all on top of G.Lite, hence no disruption...
ADSL seems to be positioned as a premium service - due to the splitter being installed, it will cost more but will also enable pretty much guaranteed bandwidth independent of home wiring and on-off hook activity.
There's a good article in IEEE Communications Magazine, May 1999, called 'Residential Broadband Architecture over ADSL and G.Lite: PPP over ATM' - talks a lot about how PPP sits on top of ATM, and how the xDSL provider only goes up to layer 2, with any layer 3 services (ISPs, video, other content) being supplied via ATM links direct to the provider. Since I work for an IP QoS company, I feel somehow this should be doable with IP, but that presumes an all-IP world which this architecture does not.
Talking to support may not work well - they have an incentive to get you off their back, whereas the product manager actually controls product features such as Linux support and may listen a bit more.
Almost all product companies have product managers, who live in the Marketing dept usually. Quantitative arguments are good to use, e.g. how many X million people use Linux, how fast it's growing, as well as competitor arguments - list the names of other videocamera suppliers who support Linux (I know there's at least one).
Actually I'd really like to see moderation-type scores on packages, from real users. WINE does something like this for the application compatibility database - why not do the same thing, keyed on package name and optionally version? Sort of a distributed consumer review magazine.
You are right about privileged access being an NT weakness due to most users being setup like this. However this has nothing to do with Worm.Explore, which simply deletes user files (documents and source code) and emails itself to other users - both possible with a non-privileged user.
The only thing that Linux would prevent is corrupting the equivalent of win.ini to launch the worm on other machines, or for other users of the same machine.
Maybe you need QoS support to some degree on USB - clearly the bandwidth is somewhat limited when you put video or other time-sensitive traffic on it. Firewire (IEEE 1394) is meant to handle such traffic better. Also USB 2.0 will have a lot more bandwidth.
Since USB is somewhat like an Ethernet shared-medium segment in concept, you could perhaps use RSVP plus SBM (RSVP allocates bandwidth end to end, while SBM is the implementation for Ethernet subnets). This all seems rather heavyweight, and assumes you are running IP across USB, which is not how devices currently work.
A lighter-weight approach might be sensible - just have a mini QoS policy manager for USB that lets you allocate bandwidth and class of service (e.g. gold, silver, bronze, where gold gets to front of queues), with simple weighted-round-robin queuing (like CBQ, you get a guaranteed bandwidth for gold and silver but can burst beyond that). Then you just config this on one USB host so that (say) your video grabber gets X MBps of gold, and your keyboard/mouse get a very small amount of silver. This is basically the DiffServ model but would need implementing over USB.
The policy-based approach means that the user can decide whether video is more important than mouse input - for a video editor, it might be, whereas for general use, it might not.
Linux 2.2 has quite impressive queuing support which is already multiprotocol but I have no idea whether it makes sense in kernel terms to try to apply this to USB - probably only a very small subset of the full Linux-DiffServ stuff is required.
My company makes DiffServ focused policy-based network management tools - currently we don't support USB, but it would be cool to see this working!
For useful links, see www.orchestream.com (my company, see the Links page), http://www.qosforum.com QoS forum, check the About page), and http://lrcwww.epfl.ch/linux-diffserv/ (Linux-DiffServ).
Of course, for videoconferencing, you may well want to have the same QoS applied for a USB video camera across both USB and the IP session you are using for the videoconferencing app. This is where an RSVP and/or DiffServ approach makes sense, since they can span multiple technologies and you can just assign one QoS policy across IP, USB, and maybe FireWire etc. Really the simplest solution here is to give every USB and Firewire device its own IP stack, which is bound to happen eventually, and avoid having to port DiffServ/RSVP to different stacks.
Re:They're available -- Read Other Post Below
on
Digital VCRs
·
· Score: 1
However, under the GPL as soon as one person gets the CD they are quite free to post the changes or the whole thing on their own FTP site.
I think it would be quite possible to write a Worm.Explorer type worm for Linux - all you need is to be able to find Samba or NFS mounted drives (mount(1)), find the user's email address book (mail UI dependent), and (optionally) find a real message in their Inbox to fake a reply to (not too hard if they are using mail(1) format mailboxes, or Netscape Messenger.) Then pipe a message into sendmail or mail(1).
I'm not advocating anyone writing a worm like this, but Linux is going to be quite susceptible to this sort of problem. If sending mail requires authentication beyond just being logged in can you prevent this, but that's not very realistic.
In fact, all this could easily have been done on the mid-80s UNIX systems that I used to run.
I agree that macro viruses are based on the absence of any security controls for Office macros, but this sort of worm is not dependent on that - in fact you could write it to attack Netscape on Windows or Linux.
There are macro-enabled suites on Linux (e.g. StarOffice and WordPerfect) - however, apart from the smaller market share, there are 2 reasons why Office macros are so prevalent:
1. Office bundles the macros with the document - rather than a separate macro file, which I know some competing suites use.
2. Office enables the AutoStart macro by default - without this, macro viruses would simply not exist, and businesses could still use other types of macro safely.
Slashdot Mirror
Actually, the Palm guarantee is valid world wide, no matter where you bought your Palm. One of the good things about the device.
Certainly routing tables should be limited in size with IPv6, which is a good thing but unlikely to make packet forwarding faster.
:)
QoS I think is in the main header (Class byte and Flow Label). As for packet spoofing, IPv6 simply makes IPsec mandatory, whereas it is optional with IPv4 - however, this is an important step. Of course, IPsec means that much traffic is encrypted (potentially) making it harder to do QoS except by letting the host do its own CoS marking and/or RSVP reservations (which let you guarantee bandwidth end to end IF the network has RSVP enabled).
The interesting stuff for Linux here is Linux-Diffserv and the Linux port of RSVPD, which enable the host to do CoS marking and RSVP reservations. However, unlike Win2000, the *nix world does not have a unified QoS API - some work to be done there for *nix to remain competitive IMO.
There is a lot of work going on in the IETF around QoS, CoS, and policy (i.e. rules that govern which apps/users get which QoS/CoS). Werner Almesberger, the Linux Diffserv guy, is at the IETF this week (as I am) and gave a presentation at the Diffserv deployment BOF.
Interestingly, Linux is way ahead of most OSs and routers in its Diffserv implementation, and apparently it can fill an OC-3 (155 Mbps optical) line while doing CBQ queuing (flexible allocation of bandwidth, see www.xedia.com for links), with 12,000 policy rultes. For those who are not in the CoS business, this performance is extremely impressive compared to some commercial routers - just buy a cheap headless PC and you have a $1000 access router with Diffserv CoS, which can also do firewalling, IPsec VPNs, etc.
If anyone's doing trials of Diffserv and wants a tool to manage policy rules for CoS efficiently, email me
Some confusion here :)
- Unicast is when a packet goes to exactly one destination and is what IPv4 uses most of the time (e.g. for http etc)
- Multicast is as konstant said, you send out one packet to a 'group address' and it gets replicated only where necessary - generally each link sees only one copy of each packet, so it's an efficient way to send audio, video or even files to a large audience. This is also in IPv4.
- Anycast is new in IPv6 - as I understand it, it lets you specify that any of a set of hosts can get the packet (but not all of them, as in multicast). It's useful for lots of things such as load balancing across servers - not sure if it does topologically-distant load balancing but it would be handy if it does.
One other misconception: IPv6 has two main features for class of service / quality of service, both in the IPv6 header:
- Traffic Class - single byte, equivalent to the IPv4 Type of Service byte, carries the class of service - will be a diffserv codepoint (number) once this is standardised, as is happening quite fast. Same codepoints work over IPv4 and IPv6 networks. Typically you assign different codepoints to VoIP, mission-critical apps, web browsing, etc - many apps share the same CoS.
- Flow Label - this is designed to make RSVP work better, allowing a single flow (e.g. ftp session) to be given a unique ID so that routers downstream of this label assignment can more quickly recognise (classify) packets in this flow (rather than looking at IP addresses, TCP/UDP port numbers, and IP protocol).
For more information on QoS/CoS (though not IPv6 specific) see www.qosforum.org, or the www.orchestream.com links page.
The interesting part was how one operation in the transaction (the debit) could be done even though the other operation failed. In the world of online transaction processing (OLTP), a transaction has to be atomic no matter how many operations it covers, even if they are on different systems (using two-phase commit or similar). In other words, if one operation completes and the other fails, the whole transaction is reversed out, undoing the one that completed.
Examples of systems that do this are IBM's CICS (works on *nix and mainframes) and Bea Tuxedo (www.beasys.com).
If the people doing this system had used a transaction based approach, this would never have happened.
'IPv5' was called ST2 - a connection-oriented protocol that supported QoS. However I don't think anyone really uses it now with a few specialised non-Internet exceptions.
A quick search on Google.com revealed the following beta done in Norway, so it is usable worldwide - not sure if it is just a library but it should be usable by mail program developers.
s g01874.html
http://www.pasta.cs.uit.no/~perm/PASTA/pilot/
There was also mention of some work done in US/Canada, for those who live there, in
http://www.imc.org/ietf-open-pgp/mail-archive/m
I agree - in the meantime, there is good shareware for PGP email integration on Windows called Mollusc, which supports Netscape and almost every Windows emailer and the author can very rapidly support off-beat email programs.
I used to use this quite a lot when I was using PGP on Windows. For attachments, the simplest thing is just to encrypt the file using PGP of course.
All very reasonable apart from the rules on installing new apps - why on earth should installing apps break an OS? With NT, this is unfortunately sometimes the case, but it shouldn't be.
We use NT systems extensively at my company, with quite competent administration, and the servers and workstations still occasionally crash (or become ultra slow and require a reboot - probably a memory leak or similar).
I have yet to see a Linux system crash, and don't even know what an 'oops' message looks like - by contrast, my mother, who is retired, has had to become horribly familiar with NT BSODs so that she can accurately report problems...
My one criticism of Linux as a server is its recovery from power failures - maybe our Linux boxes weren't set up properly, but they took a long time to be recovered after a power failure, even the one with an ICP Vortex RAID controller.
However, logging/journalling filesystems a la XFS should solve this, and we probably didn't have enough UPS capacity to allow a clean shutdown, so it could probably have been avoided. I don't know all the details as I'm not a sysadmin, but we do have a very competent BSD/Linux sysadmin here.
I don't know about C'T's biases, but submitting plain text files is very common for magazine and newspaper contributions - any formatting that has been done by the author is frequently useless, and of course if they use a different version of Word or something else altogether it is just a source of conversion hassles.
There are versions of Linux in a vast array of languages, from French and German to Korean, Chinese, Japanese and Icelandic - the latter I think illustrates how open source is crucial to smaller language populations, since Microsoft very publicly refused to do an Icelandic version of Windows.
Our NT sysadmins say that MS currently recommends you stay with SP4 unless there is a particular problem with it that's fixed with SP5.
I agreed with the earlier comment that the tests should really run for many weeks at a time - I've just spent 2 weekends debugging an NT box that keeps crashing, but more to the point, if SP5 has performance features they are no use if they cause crashes during a test like this.
The 666 days (number of the Beast) should be enough of a giveaway...
I think the general model will be to use ext2 by default for a while, but ultimately reiserfs looks very interesting for most 'desktop' style usage of Linux (including servers for desktop systems), e.g. mail, news, reasonable size databases, etc.)
:)
XFS looks more appropriate for large databases with huge disk sizes and file sizes (and stringent time-to-recover requirements), as well as for huge multimedia files (which SGI of course is traditionally focused on).
I don't think a merger of reiserfs and XFS is practical or desirable. What might be very useful is a tool that takes performance logs (e.g. sar(1) output on disk I/O) and scans your filesystems, then recommends which files should be on which filesystems.
One more blue-sky idea is based on the observation that you have to move the file to a different part of the filesystem tree to change it from (say) ext2 to reiserfs. It would be very handy if some user-level daemons could automagically migrate files to different filesystems based on sizes and usage patterns - just as hierarchical storage systems move files from disk to tape etc, this would change the underlying implementation without the user having to worry about this.
However, this would require you to separate the filesystem namespace entirely from the actual underlying filesystem, on a per file basis perhaps, which introduces all sorts of complications. On a much coarser level of granularity, this is somewhat analogous to having a logical volume implemented on top of various physical disks. But this is probably a feature for Linux 5.1
> ... There is no such thing as a DSL modem, just like there isn't such thing as
> an ISDN modem. The correct name is ATU/R or Adaptive Transceiver Unit/Remote.
The IEEE Communications article, by a technical architect who is involved in the ADSL Forum, talks about 'G.Lite modems' a lot, as well as ADSL modems. It also mentions ATU-R, where R=Residential, and ATU-C, C=Central, and defines both as ADSL modems (though the latter is usually integrated into the DSLAM = DSL Access Multiplexer).
Anyway, I think the term modem is appropriate - it really does use similar DSP and analogue technologies to POTS modems, and has similar analogue problems with crosstalk, noise, etc.
G.Lite is very new and you clearly have ADSL since there was installation work at your site - although it shares the central office problems of ADSL, it does at least mean you can buy and install the G.Lite modem yourself, just plugging it into the phone socket according to this article. Although you might need installation help, at least you don't have to buy it from the local telco.
I'm not too familiar with DMDS but from a quick scan of the webpage it seems to map IP multicast onto ATM in an intelligent way. Certainly more IP-centric than the PPP over ATM approach, but it's really solving a different problem, focusing on multicast.
The use of PPP and ATM appears due to the rigid regulatory separation between layer 1&2 services (from the xDSL provider) and layer 3+ services (from a content provider, network service provider). ATM lets the xDSL provider guarantee a certain QoS from the service provider direct to the home, preventing complaints of favouring one provider over another when both serve a given home.
PPP runs over many leased lines anyway, so it's a sort of invisible tax - but I agree about the ATM cell tax. There is work going on in the IETF on something called ISSLOW, which is designed to fragment at the PPP level where needed - the idea is that you get down to ATM-like 'cell' sizes, but only need to do this on links where there is little bandwidth and you are mixing voice/video with data. The aim is to fragment the 1500 byte FTP packet so that the small voice packets can get in there without excessive delay (leading to jitter and crap voice quality).
If you run ISSLOW everywhere it is worse than ATM, but on a single slow link it makes sense - on fast links a 1500 byte packet transmits in a vanishingly small time so it won't delay the VoIP packet (as long as the VoIP stuff gets to the front of the queue so to speak).
For more details on QoS see www.qosforum.org, or the IETF site at www.ietf.org (check the diffserv, intserv, rsvp and rap efforts).
Are you saying there was no installation work done at your house? If so, perhaps you have some sort of G.Lite but it is performing rather well...
G.Lite doesn't require a truck roll (i.e. a visit from an engineer), since it doesn't have a 'splitter' that separates the POTS (Plain Old Telephone System, i.e. phones, etc.) frequencies from the xDSL frequencies.
:) and require both ends to do a 'fast retrain' lasting 1.5 seconds. Also badly-behaved POTS equipment could disrupt things even more, and in-home wiring quality is a big factor.
This means you can just buy a G.Lite modem from whoever, plug it in, and start working (in theory) - the modem ideally is an analogue modem for when xDSL breaks and also so it can automagically request xDSL service for you via the modem link when first installed.
You may also be able to get G.Lite service at some speed (maybe lower than ADSL) beyond 18,000 feet from the central office.
The price you pay for this is that any POTS equipment's hook-on/off activity can disrupt the G.Lite modem (yes, it really is a modem
My prediction, FWIW: people will get sufficiently annoyed with the G.Lite data getting disrupted that they'll convert their whole house to Voice over IP - either buying IP phones and using in-home networking over the existing phone wiring. Or they can keep their existing phones and wiring and just have a VoIP card in their Linux firewall that acts as a home PABX as well - park, hold, etc. Though hopefully with a nicer user interface... The end result is that there is no POTS voice whatsoever, everything is IP data or VoIP, all on top of G.Lite, hence no disruption...
ADSL seems to be positioned as a premium service - due to the splitter being installed, it will cost more but will also enable pretty much guaranteed bandwidth independent of home wiring and on-off hook activity.
There's a good article in IEEE Communications Magazine, May 1999, called 'Residential Broadband Architecture over ADSL and G.Lite: PPP over ATM' - talks a lot about how PPP sits on top of ATM, and how the xDSL provider only goes up to layer 2, with any layer 3 services (ISPs, video, other content) being supplied via ATM links direct to the provider. Since I work for an IP QoS company, I feel somehow this should be doable with IP, but that presumes an all-IP world which this architecture does not.
Talking to support may not work well - they have an incentive to get you off their back, whereas the product manager actually controls product features such as Linux support and may listen a bit more.
Almost all product companies have product managers, who live in the Marketing dept usually. Quantitative arguments are good to use, e.g. how many X million people use Linux, how fast it's growing, as well as competitor arguments - list the names of other videocamera suppliers who support Linux (I know there's at least one).
That's the same sort of global as the World Series - a US variant that means 'US and Canada'.
Actually I'd really like to see moderation-type scores on packages, from real users. WINE does something like this for the application compatibility database - why not do the same thing, keyed on package name and optionally version? Sort of a distributed consumer review magazine.
You are right about privileged access being an NT weakness due to most users being setup like this. However this has nothing to do with Worm.Explore, which simply deletes user files (documents and source code) and emails itself to other users - both possible with a non-privileged user.
The only thing that Linux would prevent is corrupting the equivalent of win.ini to launch the worm on other machines, or for other users of the same machine.
Maybe you need QoS support to some degree on USB - clearly the bandwidth is somewhat limited when you put video or other time-sensitive traffic on it. Firewire (IEEE 1394) is meant to handle such traffic better. Also USB 2.0 will have a lot more bandwidth.
Since USB is somewhat like an Ethernet shared-medium segment in concept, you could perhaps use RSVP plus SBM (RSVP allocates bandwidth end to end, while SBM is the implementation for Ethernet subnets). This all seems rather heavyweight, and assumes you are running IP across USB, which is not how devices currently work.
A lighter-weight approach might be sensible - just have a mini QoS policy manager for USB that lets you allocate bandwidth and class of service (e.g. gold, silver, bronze, where gold gets to front of queues), with simple weighted-round-robin queuing (like CBQ, you get a guaranteed bandwidth for gold and silver but can burst beyond that). Then you just config this on one USB host so that (say) your video grabber gets X MBps of gold, and your keyboard/mouse get a very small amount of silver. This is basically the DiffServ model but would need implementing over USB.
The policy-based approach means that the user can decide whether video is more important than mouse input - for a video editor, it might be, whereas for general use, it might not.
Linux 2.2 has quite impressive queuing support which is already multiprotocol but I have no idea whether it makes sense in kernel terms to try to apply this to USB - probably only a very small subset of the full Linux-DiffServ stuff is required.
My company makes DiffServ focused policy-based network management tools - currently we don't support USB, but it would be cool to see this working!
For useful links, see www.orchestream.com (my company, see the Links page), http://www.qosforum.com QoS forum, check the About page), and http://lrcwww.epfl.ch/linux-diffserv/ (Linux-DiffServ).
Of course, for videoconferencing, you may well want to have the same QoS applied for a USB video camera across both USB and the IP session you are using for the videoconferencing app. This is where an RSVP and/or DiffServ approach makes sense, since they can span multiple technologies and you can just assign one QoS policy across IP, USB, and maybe FireWire etc. Really the simplest solution here is to give every USB and Firewire device its own IP stack, which is bound to happen eventually, and avoid having to port DiffServ/RSVP to different stacks.
However, under the GPL as soon as one person gets the CD they are quite free to post the changes or the whole thing on their own FTP site.
I think it would be quite possible to write a Worm.Explorer type worm for Linux - all you need is to be able to find Samba or NFS mounted drives (mount(1)), find the user's email address book (mail UI dependent), and (optionally) find a real message in their Inbox to fake a reply to (not too hard if they are using mail(1) format mailboxes, or Netscape Messenger.) Then pipe a message into sendmail or mail(1).
I'm not advocating anyone writing a worm like this, but Linux is going to be quite susceptible to this sort of problem. If sending mail requires authentication beyond just being logged in can you prevent this, but that's not very realistic.
In fact, all this could easily have been done on the mid-80s UNIX systems that I used to run.
I agree that macro viruses are based on the absence of any security controls for Office macros, but this sort of worm is not dependent on that - in fact you could write it to attack Netscape on Windows or Linux.
There are macro-enabled suites on Linux (e.g. StarOffice and WordPerfect) - however, apart from the smaller market share, there are 2 reasons why Office macros are so prevalent:
1. Office bundles the macros with the document - rather than a separate macro file, which I know some competing suites use.
2. Office enables the AutoStart macro by default - without this, macro viruses would simply not exist, and businesses could still use other types of macro safely.