Multicasting isn't easy. Multicasting is not something that just needs to be implemented, it is still a subject of research, trying to find efficient ways to handle millions of endpoints on the Internet. The current experimental implementation (MBone) implements some experimental multicasting algorithms - some of them involve flooding to find out who wants something.
The question is who should manage receiver lists - the server, ISP's routers or multiple levels of routers - and how to do that without creating megabyte sized lists that can't be handled by routers without slowing them down immensely. Another question is how should the start/stop of a stream receive be handled - regularily initiated by server/router or by the client.
It's not for ecoonomic reasons that multicast hasn't caught on (hell, there'd be lots of economic reasons to push it on everyone!), it's that there really isn't any widely usable multicast mechanism ready yet.
Any software that isn't free software cannot be Open Source. A simple look at the Open Source Definition will show you that.
I know that. They can't be Open Source, but they are still open source. The OSI has no control over that use since they weren't able to get the trademark and now anyone publishing some parts of their sources under restrictive terms can shout "open source! open source!".
That's why it's bad to use the way too generic term "open source" when referring to free software. It throws free software and restricted commercial software together. That many Slashdot readers know the distinction is not of much use when the general public and the decision makers don't (the point being that the free software works so well because it's free and not because it's just open source).
I also remember an object oriented programming model in the recent versions of AmigaOS, what was that called?
BOOPSI - Basic Object Oriented Programming System for Intuition. First appeared in AmigaOS 2.0, I think. Compared with the rest of the OS this one was a relatively inefficient design: methods were passed up through every classes' method handler even if they had no intention to handle them, ever. Nothing like a table lookup anywhere in sight.
"To use it in a commercial product, you have to pay us a royalty, but, you know, absolutely free for enthusiasts to use."
That means it won't be free. It probably can not be distributed on CDs because these can be considered commercial products (you usually pay for them). The code can not be reused in GPL programs since it adds restrictions which is not allowed by the GPL (for good reasons). Using code in any program under another license can be problematic since probably redistribution will be either explicitly or implicitly (through the non-commercial clause) restricted.
Still, it is "open source", since the source is open. That should give some insight why some people rather dislike using this term when referring to free software (especially RMS does, of course). "Open source" has a rather positive association with free software to the wider masses now. So now companies can publish non-free software and get an automatic market boost by claiming they are open source. They even made it to a Slashdot story, though they don't have anything the free software community might profit from (which the story poster consequently didn't realize, in order to support my point).
But since they were designed in the late seventies it is likely that they are hardly more powerful than a 68000/7
The 68000 came out in the late seventies. IIRC one 68000 controls each of the shuttle's 3 main engines. They are mounted on the engines to avoid long control cables (and have to endure lots of g's due to vibration) and make sure that the engines don't explode in operation.
The shuttle's engines are used to nearly maximum of their power unlike earlier engines like Saturn's for example. Before engines had to be seriously oversized to be driven at a fraction of their available power just because of the danger of an explosion.
3) Since a calling program can run with any library containing the correct functions, then calling programs are an "identifiable section of that work" that is "not derived from the Program" (capital-P Program, meaning the GPL'd library, quoting the GPL itself) "and can be reasonably considered independent and separate works in themselves"
That's fine, if you can show that your program indeed works with a different, non-GPL library. Otherwise it depends on a GPL library and is therefore derived work (if you take the source code into your program or if you compile the GPL code to separate object files and link it with your program doesn't make a difference).
Let's take programs compiled with lesstif for example (I don't think lesstif is GPL but rather LPGL or something else, let's just assume it were GPL). Programs using this library wouldn't need to be GPL since they could just as well be used with commercial Motif (which lesstif tries to emulate).
If there is no replacement for the GPL library however then you are bound to GPL rules. The program obiously combines GPL code, which it depends on, into its own code. "It could theoretically run with a different library" doesn't count IMHO if there is no different library. If that were a valid point anyone could take GPL code into their proprietary programs since they just could have theoretically written it themselves.
In fact, the UDI driver code can be simpler, because it doesn't deal with interrupt masks, task switching, synchronization, etc. (Since the environment has to deal with these issues, the environment implementation is probably harder, but it only has to be done once for all drivers on that OS.)
If they don't handle anything it will create very ineffective results. Don't have to handle synchronization? Implementation on SMP then means that the Big Driver Lock must be held whenever the driver code is executing on one CPU, whether it needs it or not. Goodbye scalability.
Surely the kernel would be more manageable if this mass of code wasn't so tightly coupled with kernel internals?
Only if you don't care about enhancing the Linux kernel. An API set in stone means that this has to be supported as written, no matter if you have to work around five corners to support it because it doesn't fit your kernel.
Linux sometimes breaks driver interfaces and adds different ones during the development kernel cycle. Do they do it to annoy driver writers? No, they do it because the new interface is cleaner, more effective or fits better another updated part of the kernel. UDI means at least for hardware drivers stopping development and watch performance going down the drain. Or it means designing the kernel to fit UDI, which certainly won't happen.
Why aren't the Linux/BSD communities driving UDI? UDI can be good for everyone but Microsoft.
UDI is mainly good for hardware vendors who don't want to release driver sources or specs. Why should the free software community support that? If the driver specs are available then drivers can be developed and maintained for every OS, no problem.
How much hardware with available specs is unsupported?
This allowed for a smaller memory footprint for the kernel boot image, without requiring any of the drivers to be removed from the system.
But modules have a higher memory footprint on running kernels. Statically compiled, the functions of all drivers follow each other one after the other. Modules on the other hand are loaded into full memory pages (4kB on x86) and some of the memory in the last page may be left unused.
People, we had such stuff developed before and it was rightfully not used by Linux kernel. The only thing that got some discussion was a sort of standardized kernel API for drivers (called UDI, I think). The problem with such generalizations is that they hit performance and that they don't fit everywhere. The latter adds to the former, because some standard semantics have to be emulated in an ineffective manner (where there would have been simpler and aggressively optimized operations available natively).
That were just the problems of good frameworks. Now this KRFTech thing on the other hand... First it's not a real kernel driver development kit, it's an interface for user space drivers. This has more speed problems and big problems with interrupt handling: an IRQ stays asserted until the hardware is told to clear it, and only the driver knows how to do that (if the IRQ isn't cleared the system will infinitely reenter the IRQ handler). Now when the driver is in user space, there is a definite problem, since it can not handle the IRQ directly... So they probably do some heavy kludging to get around that.
Then, their so called "advantages":
Simple - No operating system or kernel knowledge needed.
Stable / Safe - Keeps unexperienced developers AWAY from the Linux kernel.
Advantages? Would you really want to use a driver on your Linux box that is written by someone without a clue of the Linux kernel? I know what they mean with keep unexp. developers away from kernel (they don't see the API), but since they access the hardware they have the same chances of causing big trouble as a real driver programmer. It's actually the opposite since it really invites clueless programmers to write drivers. The Visual Basic of driver programming.
There are even more problems. The drivers using this system require a non-free kernel module to work. The source of which won't be publically available, judging from the web page. Sure, the developers get a copy of the source so that they can modify it for different Linux versions (how generous - we may even choose ourselves on which Linux kernel we want to run this on). The problem is that the end user of the driver needs this module to run on her kernel, not only the developer. Compiled with the same compiler and options as the rest of the kernel.
Other things: does it support SMP, architectures other than x86, the latest developer kernel?
This stuff is not worth the bytes it is written on. Don't bother reporting on it in the future.
FireWire is NOT A BUS PROTOCOL. FireWire is a SERIAL protocol.
FireWire is a serial bus (but see below). So is Ethernet, unless it's completely built using hubs or switches.
A bus transmits multiple bits at the same time, a serial connection transmits one bit at a time.
A bus connects multiple devices through the same wires. A port connects to only one device (note: PCI bus but AGP port). This definition is not dependent on whether there is one data line (serial) or more (parallel).
Actually FireWire is physically not a bus, it only looks like that to the software (all data sent is seen by all nodes), i.e. it's a logical bus. Physically a device has one or more ports which each can connect to one other device. If a device has more than one port it repeats all information it receives on one port to all other ports and therefore acts as a hub.
First of all, everything should be moved over to optical. AFAIK it's far faster than anything and can go the distance, so why argue over 100bT and ieee 1394.
Sorry, but that's a stupid statement. You can not replace 1394 or Ethernet with optical lines because you'd need some standard specifying the physical connections and the protocol to be run over those.
Guess which standards there are? You can do Ethernet over optical lines (until recently the only way to get Gigabit-Ethernet) and the 1394.b standard is also supposed to specify optical connections allowing 3.2 Gbit/s over 100m lengths (and 3.2 Gbit/s over 4.5m shielded electrical cable).
Your email host is probably in the ORBS database of public relays (which are happily used by spammers to hide their traces). In this case vger ignores you. See http://www.orbs.org/ to find out if you're in the blacklist.
Disclaimer: I don't know details about netrek authentication, everything I say is mostly based on what I read and common sense.
Oh I get it! So the authorized client's source is different from the publically available source (the difference being the key). Well IMHO that doesn't count, because it's not/totally/ open source...
It is open source, except that the private keys aren't made public. What more do you want? You could plug in your own keys, only the servers wouldn't accept it as a trusted authentication (well, start your own server with your own trusted keys list).
Unfortunately, it's still security through obscurity.
Having everything except for the private keys is not security by obscurity. You have the code, you have the algorithms. There's nothing obscured. By your definition all cryptography would be security by obscurity.
Somebody will disassemble the binary and find the keys, then plug them into a modified client.
This shouldn't be that easy. I think there could be a few tricks to avoid including it in the clear (mostly making it dependend on the rest of the code so that it really authenticates the binary and not the key alone).
There is also a probably not so well known network game called netrek and its descendants (it's been around for a long time, starship combats in 2-D). Most clients for that game are free software and can be modified and compiled by anyone.
The way they guard against bots (it's server policy, not all do) is to accept connections only from authenticated binaries. Some trusted parties compile, sign and distribute binaries which authenticate themselves via RSA to game servers. Open source and very difficult to cheat, both at once.
P.S. the sukyest thing about the Palm is that a buggy app can not only crash the whole machine, it can destroy data (since it is all in RAM, and there is no MMU). Hopefully the ARM Samsung chose has a MMU, and they use it.
Of course it has, otherwise it wouldn't be possible to run a standard Linux on it (you'd need something like ucLinux which more or less isn't a real Linux anymore - it just uses the well-tested standard Linux code). The MMU is handled by Linux, you get memory protection just like on your desktop box.
I don't think there are StrongARMs without MMUs anyway. They don't have a FPU, though.
the fun part is that the "code-morphing software" is supposed to be self-optimizing. It caches frequently used instructions, performing them faster the next time they come up.
It is not "self-optimizing". The code morpher translates x86 code to native code for execution and also stores that. When the code is executed again it optimizes that, true. But the code morpher itself obviously is already compiled to Crusoe code, so it doesn't translate and optimize itself.
There was an analysis on a distributed DoS software on Bugtraq somewhat recently. It's called Stacheldraht, is designed to be installed on many unsecure machines on the net (i.e. they get cracked and don't notice it, it's not a voluntary network). There's also another package of which I don't remember the name.
The design is quite well thought-out, with multiple layers where DoS servers are responsible for a bunch of slaves which do the actual DoS work. These servers can then be controlled from a central point. Massive bandwidth to DoS at the cracker's hands.
I guess this incident shows that it or a similar package is in use. This is a new way of attacking, so I think it was worth a news item.
[1] Does compiling proprietary code with gcc make it GPL? How do you know which libraries are okay to link in (if any)?
It doesn't. gcc creates output from input, that doesn't make any output a derivative work of gcc. The only problem would be the init code / libgcc.a which are linked in automatically in the process of creating an executable, but these are not under GPL licenses allowing linking with anything.
For other libraries it's simple as that: you can't link a GPL library to a non-GPL application. LGPL and other licenses however allow this.
[2] Does including some GPL tool with your proprietary package put the *whole* package under GPL?
Not at all. Derivative works are required to be under GPL, putting independent files on the same medium is not a derivation. No problem as long as the usual rules are followed: explicitly state that it is / what is under GPL and include source or include written offer to send source on request.
[3] Does using GPLed software to write *nix drivers for some piece of hardware mean that the the hardware specs/design have to be made "open" now?
"using GPLed software": see [1].
Another thing is using the created non-free drivers with a GPL kernel like Linux. You can't link them in, so can only distribute them as modules. Linus made a special exception to the GPL that allows binary modules to be used in a Linux kernel (standard GPL wouldn't allow that, it's comparable to dynamic linking).
The only things I know of with a firewire interface is digital cameras and some storage solutions.. I guess there are no Linux drivers for the utilities, even if the kernel supports firewire..
The 1394 subsystem includes a raw1394 driver and there is the libraw1394. This is enough to control digital cameras and to receive the data with a user space program without additional kernel drivers. This has already been done successfully (but there are no finished apps yet).
Storage solutions usually use the SBP-2 protocol. This has to be done in the kernel, mainly because it's a service to the kernel in form of block devices. That is already worked on, but there is no working code yet.
So you are saying, that we are getting often files slower than we could on the same connection for some reason that is in stack?
This is wrong. You get them as fast as your connection can handle it. At least after the current max speed is found, a new TCP connection starts slow and then speeds up (sending one Megabyte in a second to a client that can handle only one Kilobyte per second will mean 1023kB of bandwidth wasted only to find out that it is in fact wasted). This is one of the reasons HTTP/1.1 adds persistant connections as opposed to one connection per file as in HTTP/1.0.
Most people don't realize that the reason there are six crewmembers on a shuttle mission is that until the mid-90s, all of the computer instructions were stored on punched paper tape! The "mission specialists" had the job of feeding the paper tape into the vintage 1970 computer while the Flying Winnebago did laps around the Earth for a week.
You're kidding. They sure use tested and reliable computers in their machines, but punched paper tape is simply stupid. They need to reload the memory of the control computers a few times with the required software for the current mission stage, but they use magnetic tapes (like they already did back in the Apollo missions).
Re:Functionality Makes It To A Linux GUI
on
The ROX Desktop
·
· Score: 2
Gnome has got a long way to go in useability, particularly in the window manager department.
Gnome is neither a window manager nor does it contain/depend on any single window manager. So what do you mean?
Slashdot Mirror
Multicasting isn't easy. Multicasting is not something that just needs to be implemented, it is still a subject of research, trying to find efficient ways to handle millions of endpoints on the Internet. The current experimental implementation (MBone) implements some experimental multicasting algorithms - some of them involve flooding to find out who wants something.
The question is who should manage receiver lists - the server, ISP's routers or multiple levels of routers - and how to do that without creating megabyte sized lists that can't be handled by routers without slowing them down immensely. Another question is how should the start/stop of a stream receive be handled - regularily initiated by server/router or by the client.
It's not for ecoonomic reasons that multicast hasn't caught on (hell, there'd be lots of economic reasons to push it on everyone!), it's that there really isn't any widely usable multicast mechanism ready yet.
Huh? 2.2 and even the latest 2.4 test kernels run on a wide variety of ARM systems. Development happens mainly on 2.4 test.
I know that. They can't be Open Source, but they are still open source. The OSI has no control over that use since they weren't able to get the trademark and now anyone publishing some parts of their sources under restrictive terms can shout "open source! open source!".
That's why it's bad to use the way too generic term "open source" when referring to free software. It throws free software and restricted commercial software together. That many Slashdot readers know the distinction is not of much use when the general public and the decision makers don't (the point being that the free software works so well because it's free and not because it's just open source).
BOOPSI - Basic Object Oriented Programming System for Intuition. First appeared in AmigaOS 2.0, I think. Compared with the rest of the OS this one was a relatively inefficient design: methods were passed up through every classes' method handler even if they had no intention to handle them, ever. Nothing like a table lookup anywhere in sight.
That means it won't be free. It probably can not be distributed on CDs because these can be considered commercial products (you usually pay for them). The code can not be reused in GPL programs since it adds restrictions which is not allowed by the GPL (for good reasons). Using code in any program under another license can be problematic since probably redistribution will be either explicitly or implicitly (through the non-commercial clause) restricted.
Still, it is "open source", since the source is open. That should give some insight why some people rather dislike using this term when referring to free software (especially RMS does, of course). "Open source" has a rather positive association with free software to the wider masses now. So now companies can publish non-free software and get an automatic market boost by claiming they are open source. They even made it to a Slashdot story, though they don't have anything the free software community might profit from (which the story poster consequently didn't realize, in order to support my point).
The 68000 came out in the late seventies. IIRC one 68000 controls each of the shuttle's 3 main engines. They are mounted on the engines to avoid long control cables (and have to endure lots of g's due to vibration) and make sure that the engines don't explode in operation.
The shuttle's engines are used to nearly maximum of their power unlike earlier engines like Saturn's for example. Before engines had to be seriously oversized to be driven at a fraction of their available power just because of the danger of an explosion.
That's fine, if you can show that your program indeed works with a different, non-GPL library. Otherwise it depends on a GPL library and is therefore derived work (if you take the source code into your program or if you compile the GPL code to separate object files and link it with your program doesn't make a difference).
Let's take programs compiled with lesstif for example (I don't think lesstif is GPL but rather LPGL or something else, let's just assume it were GPL). Programs using this library wouldn't need to be GPL since they could just as well be used with commercial Motif (which lesstif tries to emulate).
If there is no replacement for the GPL library however then you are bound to GPL rules. The program obiously combines GPL code, which it depends on, into its own code. "It could theoretically run with a different library" doesn't count IMHO if there is no different library. If that were a valid point anyone could take GPL code into their proprietary programs since they just could have theoretically written it themselves.
If they don't handle anything it will create very ineffective results. Don't have to handle synchronization? Implementation on SMP then means that the Big Driver Lock must be held whenever the driver code is executing on one CPU, whether it needs it or not. Goodbye scalability.
Surely the kernel would be more manageable if this mass of code wasn't so tightly coupled with kernel internals?
Only if you don't care about enhancing the Linux kernel. An API set in stone means that this has to be supported as written, no matter if you have to work around five corners to support it because it doesn't fit your kernel.
Linux sometimes breaks driver interfaces and adds different ones during the development kernel cycle. Do they do it to annoy driver writers? No, they do it because the new interface is cleaner, more effective or fits better another updated part of the kernel. UDI means at least for hardware drivers stopping development and watch performance going down the drain. Or it means designing the kernel to fit UDI, which certainly won't happen.
Why aren't the Linux/BSD communities driving UDI? UDI can be good for everyone but Microsoft.
UDI is mainly good for hardware vendors who don't want to release driver sources or specs. Why should the free software community support that? If the driver specs are available then drivers can be developed and maintained for every OS, no problem.
How much hardware with available specs is unsupported?
And it has already been decided that UDI won't be accepted into the official Linux releases.
But modules have a higher memory footprint on running kernels. Statically compiled, the functions of all drivers follow each other one after the other. Modules on the other hand are loaded into full memory pages (4kB on x86) and some of the memory in the last page may be left unused.
People, we had such stuff developed before and it was rightfully not used by Linux kernel. The only thing that got some discussion was a sort of standardized kernel API for drivers (called UDI, I think). The problem with such generalizations is that they hit performance and that they don't fit everywhere. The latter adds to the former, because some standard semantics have to be emulated in an ineffective manner (where there would have been simpler and aggressively optimized operations available natively).
That were just the problems of good frameworks. Now this KRFTech thing on the other hand... First it's not a real kernel driver development kit, it's an interface for user space drivers. This has more speed problems and big problems with interrupt handling: an IRQ stays asserted until the hardware is told to clear it, and only the driver knows how to do that (if the IRQ isn't cleared the system will infinitely reenter the IRQ handler). Now when the driver is in user space, there is a definite problem, since it can not handle the IRQ directly... So they probably do some heavy kludging to get around that.
Then, their so called "advantages":
- Simple - No operating system or kernel knowledge needed.
- Stable / Safe - Keeps unexperienced developers AWAY from the Linux kernel.
Advantages? Would you really want to use a driver on your Linux box that is written by someone without a clue of the Linux kernel? I know what they mean with keep unexp. developers away from kernel (they don't see the API), but since they access the hardware they have the same chances of causing big trouble as a real driver programmer. It's actually the opposite since it really invites clueless programmers to write drivers. The Visual Basic of driver programming.There are even more problems. The drivers using this system require a non-free kernel module to work. The source of which won't be publically available, judging from the web page. Sure, the developers get a copy of the source so that they can modify it for different Linux versions (how generous - we may even choose ourselves on which Linux kernel we want to run this on). The problem is that the end user of the driver needs this module to run on her kernel, not only the developer. Compiled with the same compiler and options as the rest of the kernel.
Other things: does it support SMP, architectures other than x86, the latest developer kernel?
This stuff is not worth the bytes it is written on. Don't bother reporting on it in the future.
FireWire is a serial bus (but see below). So is Ethernet, unless it's completely built using hubs or switches.
A bus transmits multiple bits at the same time, a serial connection transmits one bit at a time.
A bus connects multiple devices through the same wires. A port connects to only one device (note: PCI bus but AGP port). This definition is not dependent on whether there is one data line (serial) or more (parallel).
Actually FireWire is physically not a bus, it only looks like that to the software (all data sent is seen by all nodes), i.e. it's a logical bus. Physically a device has one or more ports which each can connect to one other device. If a device has more than one port it repeats all information it receives on one port to all other ports and therefore acts as a hub.
Sorry, but that's a stupid statement. You can not replace 1394 or Ethernet with optical lines because you'd need some standard specifying the physical connections and the protocol to be run over those.
Guess which standards there are? You can do Ethernet over optical lines (until recently the only way to get Gigabit-Ethernet) and the 1394.b standard is also supposed to specify optical connections allowing 3.2 Gbit/s over 100m lengths (and 3.2 Gbit/s over 4.5m shielded electrical cable).
Your email host is probably in the ORBS database of public relays (which are happily used by spammers to hide their traces). In this case vger ignores you. See http://www.orbs.org/ to find out if you're in the blacklist.
Disclaimer: I don't know details about netrek authentication, everything I say is mostly based on what I read and common sense.
Oh I get it! So the authorized client's source is different from the publically available source (the difference being the key). Well IMHO that doesn't count, because it's not /totally/ open source...
It is open source, except that the private keys aren't made public. What more do you want? You could plug in your own keys, only the servers wouldn't accept it as a trusted authentication (well, start your own server with your own trusted keys list).
Unfortunately, it's still security through obscurity.
Having everything except for the private keys is not security by obscurity. You have the code, you have the algorithms. There's nothing obscured. By your definition all cryptography would be security by obscurity.
Somebody will disassemble the binary and find the keys, then plug them into a modified client.
This shouldn't be that easy. I think there could be a few tricks to avoid including it in the clear (mostly making it dependend on the rest of the code so that it really authenticates the binary and not the key alone).
Info on Netrek in general can be found on the Netrek Continuum.
There is also a probably not so well known network game called netrek and its descendants (it's been around for a long time, starship combats in 2-D). Most clients for that game are free software and can be modified and compiled by anyone.
The way they guard against bots (it's server policy, not all do) is to accept connections only from authenticated binaries. Some trusted parties compile, sign and distribute binaries which authenticate themselves via RSA to game servers. Open source and very difficult to cheat, both at once.
Of course it has, otherwise it wouldn't be possible to run a standard Linux on it (you'd need something like ucLinux which more or less isn't a real Linux anymore - it just uses the well-tested standard Linux code). The MMU is handled by Linux, you get memory protection just like on your desktop box.
I don't think there are StrongARMs without MMUs anyway. They don't have a FPU, though.
It is not "self-optimizing". The code morpher translates x86 code to native code for execution and also stores that. When the code is executed again it optimizes that, true. But the code morpher itself obviously is already compiled to Crusoe code, so it doesn't translate and optimize itself.
And, of course, there is the Freedom CPU project.
There was an analysis on a distributed DoS software on Bugtraq somewhat recently. It's called Stacheldraht, is designed to be installed on many unsecure machines on the net (i.e. they get cracked and don't notice it, it's not a voluntary network). There's also another package of which I don't remember the name.
The design is quite well thought-out, with multiple layers where DoS servers are responsible for a bunch of slaves which do the actual DoS work. These servers can then be controlled from a central point. Massive bandwidth to DoS at the cracker's hands.
I guess this incident shows that it or a similar package is in use. This is a new way of attacking, so I think it was worth a news item.
It doesn't. gcc creates output from input, that doesn't make any output a derivative work of gcc. The only problem would be the init code / libgcc.a which are linked in automatically in the process of creating an executable, but these are not under GPL licenses allowing linking with anything.
For other libraries it's simple as that: you can't link a GPL library to a non-GPL application. LGPL and other licenses however allow this.
[2] Does including some GPL tool with your proprietary package put the *whole* package under GPL?
Not at all. Derivative works are required to be under GPL, putting independent files on the same medium is not a derivation. No problem as long as the usual rules are followed: explicitly state that it is / what is under GPL and include source or include written offer to send source on request.
[3] Does using GPLed software to write *nix drivers for some piece of hardware mean that the the hardware specs/design have to be made "open" now?
"using GPLed software": see [1].
Another thing is using the created non-free drivers with a GPL kernel like Linux. You can't link them in, so can only distribute them as modules. Linus made a special exception to the GPL that allows binary modules to be used in a Linux kernel (standard GPL wouldn't allow that, it's comparable to dynamic linking).
The 1394 subsystem includes a raw1394 driver and there is the libraw1394. This is enough to control digital cameras and to receive the data with a user space program without additional kernel drivers. This has already been done successfully (but there are no finished apps yet).
Storage solutions usually use the SBP-2 protocol. This has to be done in the kernel, mainly because it's a service to the kernel in form of block devices. That is already worked on, but there is no working code yet.
This is wrong. You get them as fast as your connection can handle it. At least after the current max speed is found, a new TCP connection starts slow and then speeds up (sending one Megabyte in a second to a client that can handle only one Kilobyte per second will mean 1023kB of bandwidth wasted only to find out that it is in fact wasted). This is one of the reasons HTTP/1.1 adds persistant connections as opposed to one connection per file as in HTTP/1.0.
You're kidding. They sure use tested and reliable computers in their machines, but punched paper tape is simply stupid. They need to reload the memory of the control computers a few times with the required software for the current mission stage, but they use magnetic tapes (like they already did back in the Apollo missions).
Gnome is neither a window manager nor does it contain/depend on any single window manager. So what do you mean?