However, I don't know of a single Linux or BSD distribution that enables Teredo by default, or at least makes it easily accessible to the user, unlike Windows, where Teredo is enabled as soon as an application attempts to connect to an IPv6 address.
patches are welcome more then complaining.
Please try a web search for my name (not my Slashdot nick!) and IPv6.
BitTorrent is already running over IPv6. Anyone running Torrent on a recent enough version of Windows automatically uses IPv6 to cross NAT boxes using a technology known as Teredo.
The Free Software world is late with IPv6 adoption. In the words of one of the Torrent developers (Greg), "platforms which are not Windows [...] need to get their collective Teredo asses in gear."
You mean to tell me that folks who work on open source software [...] aren't allowed to talk...
This isn't about freedom of speech, this is about the acceptable use of an official platform.
Restricting the usage of an official platform is standard practice. A lecturer is usually not allowed to speak about politics in class. This doesn't mean he's not allowed to speak about politics with his students, it means that if he chooses to do so, he should meet the students outside of the lecture theater.
Do I trust Google, who has fought court orders to protect my privacy? Yes.
The question is not whether you trust Google now.
Since Google never deletes users' data, the question becomes whether you trust whoever might be in charge at Google ten years from now to still protect your privacy.
Sooner or later, freenet will become more popular,
Wanna bet?
The whole point of BitTorrent is that it is not a p2p network -- it's a file transfer protocol. How you get at the metadata (torrent search engines), how you locate peers (tracker DHT, PEX) are outside of the core protocol.
Because of that, BitTorrent is pretty much immune to the known ways of disrupting a p2p network. As soon as Freenet becomes usable, it will be dealt with in pretty much the same way as Gnutella was.
TCP will behave reasonably with a long round trip time.
This is simply not true. Performance of TCP suffers greatly when the RTT grows (the congestion window takes time to grow to high enough values).
The solution is reordering the packets, not dropping them.
Hmm, citing ``common sense'' arguments rather then relying on the published research? Are you a telecom person, perhaps?
Most research into TCP/IP performance of the last 20 years or so indicates just the opposite: it is better to provide indication of impending congestion earlier rather than later. Since in the absence of ECN TCP/IP only indicates congestion by dropping packets, one must occasionally drop packets even when router queues are still reasonable.
The difficult part, of course, is designing a so-called active queue management (AQM) algorithm that determines which packets exactly to drop, and does so without using up too much CPU time and memory on your router. The earliest such algorithm was called RED, and required a lot of manual tuning. Current algorithms are autotuning; my favourite is called SFB.
But all of that is beyond the wits of the telecom people who appear to be managing most of the world's routers, and hence AQMs are not as widely deployed as they should be.
[Hurricane Electric] are the Wal-Mart of bandwidth and offer dirt-cheap prices. [...] how dare they expect to offer the same QoS and not pay for it.
Huh? You meant that there are operators that offer actual QoS for IP traffic? If so, it's an interesting new research result, and I'd like to see the technology.
(More seriously -- unless you can show us that HE's SLA is significantly worse than other operators', I recommend that you shut up. What you're doing is called uninformed FUD.)
if a company produces a stable, reliable product with closed software and the market is willing to pay for it, what difference does it make?
You just failed Adam Smith 101. The fact that the uninformed public is willing to buy NVIDIA hardware doesn't mean that using a binary driver is a good idea.
First, you have no guarantees that the driver will continue being developed. If tomorrow some suit at NVIDIA decides that maintaining Linux drivers is not worth their while, you end up with a piece of hardware that cannot be used with recent kernels.
Second, any problems you may have while running their drivers are essentially undebuggable. This removes you from the pool of people able to submit useful debugging logs, which is bad for the whole Linux user-base.
Third, binary drivers are only available for Windows, Linux, FreeBSD and Solaris. If, for some reason, you decide that, say, NetBSD is more suitable for you, you're stuck -- you cannot switch without changing your hardware. This makes competing with Linux more difficult, and hence is bad for everyone -- including Linux users.
In short, using a binary driver is bad for you and bad for the Free Software community. Please consider spending your money in a more informed manner in the future.
Speculation: some of their binary code dynamically optimizes an FPGA on board for better performance.
A phone line is just a copper twisted pair. ADSL uses the very same copper.
64kbit/s is the rate of the ADC that the phone companies have been hooking to the telephone lines since the 90s, but that has nothing to do with the phone line itse.f
This is a physical problem. There is only so much spectrum available. Once the air is saturated on the allocated frequencies, we are done. No more room, period.
Nonsense. There's plenty of ways to make wireless networks scale.
Just off the top of my head, there are physical layer techniques, such as MIMO, that change the value of Shannon's limit by dramatically improving the signal/noise ration. There are network layer techniques, such as mesh networking, that allow you to use a larger number of less powerful radios, and hence allow more sharing of bandwidth in a given space. There are application layer techniques, such as distributed caching.
And all of that is without getting the politicians involved to give us back some of the bandwidth they have been giving away to corporations.
The original 8086 processor could address 1 megabyte of memory (20 bits) with a 16 bit processor. It used two registers (one shifted left by four bits) to address memory.
Have you ever programmed in that model?
Having pointers split into segment:offset pairs meant that you couldn't (easily) have a single array span more than 64kB. Any program that needed to access arrays above that had to split its arrays into arrays of arrays, each of which was smaller. Fun, fun, fun.
A 64 bit processor could trivially access a 128-bit address space by using the same segment:offset method.
I'll let you do the programming, this time. I'll stick to the flat memory model of today's architectures, if that's all right with you.
Slashdot Mirror
Flash is H.264.
To be entirely exact, Flash is either H.264, On2 or Sorenson Spark.
roc has explained why using DirectShow in Mozilla's Gecko won't happen in the foreseeable future.
It sounds like he's making excuses.
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil."
(Saint Matthew about digital media.)
Just because there isn't a good implementation of Teredo doesn't mean free software is late with IPv6 adoption.
There's an excellent implementation of Teredo for free Unices.
However, I don't know of a single Linux or BSD distribution that enables Teredo by default, or at least makes it easily accessible to the user, unlike Windows, where Teredo is enabled as soon as an application attempts to connect to an IPv6 address.
patches are welcome more then complaining.
Please try a web search for my name (not my Slashdot nick!) and IPv6.
I guess the question is, can a modern desktop operating system, out of the box, wire itself to an ipv6 network the same way one does with ipv4?
Yes.
Like, if Verizon decreed that FIOS shall use IPV6 addresses for everything, does that break the following operating systems:
a) Linux
No. (If using 2.4.12 or later.)
b) Mac
No. (If using 10.3 or later.)
c) Windows
No. (If using Vista or later, limited support since XPSP2.)
That should read "muTorrent", both times. The Greek letter didn't get through, for some reason.
BitTorrent is already running over IPv6. Anyone running Torrent on a recent enough version of Windows automatically uses IPv6 to cross NAT boxes using a technology known as Teredo.
The Free Software world is late with IPv6 adoption. In the words of one of the Torrent developers (Greg), "platforms which are not Windows [...] need to get their collective Teredo asses in gear."
Slides from Karsten's presentation at the CCC.
The A5/1 cracking project.
You mean to tell me that folks who work on open source software [...] aren't allowed to talk...
This isn't about freedom of speech, this is about the acceptable use of an official platform.
Restricting the usage of an official platform is standard practice. A lecturer is usually not allowed to speak about politics in class. This doesn't mean he's not allowed to speak about politics with his students, it means that if he chooses to do so, he should meet the students outside of the lecture theater.
What were Opera's alternatives?
They could have refused to do business in China, as long as the Chinese policy doesn't change.
Just like IKEA have stopped doing business in Russia, for slightly different reasons.
Do I trust Google, who has fought court orders to protect my privacy? Yes.
The question is not whether you trust Google now. Since Google never deletes users' data, the question becomes whether you trust whoever might be in charge at Google ten years from now to still protect your privacy.
It means that VeriSign will be signing the zone, while Icann will be acting as a CA and certifying the keys used by VeriSign.
You can't compare the app store and totalitarianism.
Yes I can. This is a free country.
Someone do a wikipedia article on him quick
http://en.wikipedia.org/wiki/Aleksey_Dymovsky
Do I read the article right? It's just a compression scheme for OpenType?
Sooner or later, freenet will become more popular,
Wanna bet?
The whole point of BitTorrent is that it is not a p2p network -- it's a file transfer protocol. How you get at the metadata (torrent search engines), how you locate peers (tracker DHT, PEX) are outside of the core protocol.
Because of that, BitTorrent is pretty much immune to the known ways of disrupting a p2p network. As soon as Freenet becomes usable, it will be dealt with in pretty much the same way as Gnutella was.
TCP will behave reasonably with a long round trip time.
This is simply not true. Performance of TCP suffers greatly when the RTT grows (the congestion window takes time to grow to high enough values).
The solution is reordering the packets, not dropping them.
Hmm, citing ``common sense'' arguments rather then relying on the published research? Are you a telecom person, perhaps?
Most research into TCP/IP performance of the last 20 years or so indicates just the opposite: it is better to provide indication of impending congestion earlier rather than later. Since in the absence of ECN TCP/IP only indicates congestion by dropping packets, one must occasionally drop packets even when router queues are still reasonable.
The difficult part, of course, is designing a so-called active queue management (AQM) algorithm that determines which packets exactly to drop, and does so without using up too much CPU time and memory on your router. The earliest such algorithm was called RED, and required a lot of manual tuning. Current algorithms are autotuning; my favourite is called SFB.
But all of that is beyond the wits of the telecom people who appear to be managing most of the world's routers, and hence AQMs are not as widely deployed as they should be.
[Hurricane Electric] are the Wal-Mart of bandwidth and offer dirt-cheap prices. [...] how dare they expect to offer the same QoS and not pay for it.
Huh? You meant that there are operators that offer actual QoS for IP traffic? If so, it's an interesting new research result, and I'd like to see the technology.
(More seriously -- unless you can show us that HE's SLA is significantly worse than other operators', I recommend that you shut up. What you're doing is called uninformed FUD.)
if a company produces a stable, reliable product with closed software and the market is willing to pay for it, what difference does it make?
You just failed Adam Smith 101. The fact that the uninformed public is willing to buy NVIDIA hardware doesn't mean that using a binary driver is a good idea.
First, you have no guarantees that the driver will continue being developed. If tomorrow some suit at NVIDIA decides that maintaining Linux drivers is not worth their while, you end up with a piece of hardware that cannot be used with recent kernels.
Second, any problems you may have while running their drivers are essentially undebuggable. This removes you from the pool of people able to submit useful debugging logs, which is bad for the whole Linux user-base.
Third, binary drivers are only available for Windows, Linux, FreeBSD and Solaris. If, for some reason, you decide that, say, NetBSD is more suitable for you, you're stuck -- you cannot switch without changing your hardware. This makes competing with Linux more difficult, and hence is bad for everyone -- including Linux users.
In short, using a binary driver is bad for you and bad for the Free Software community. Please consider spending your money in a more informed manner in the future.
Speculation: some of their binary code dynamically optimizes an FPGA on board for better performance.
Please mod parent as +1 Funny.
> please support the project (which also brings you OpenSSH Is it possible to support OpenSSH without the money being wasted on OpenBSD?
People read manuals?
Massive wi-fi mesh? In fact, India already does something very similar for a very long time.
Reference needed?
Phone lines have a total bandwidth of 64k
Huh?
A phone line is just a copper twisted pair. ADSL uses the very same copper.
64kbit/s is the rate of the ADC that the phone companies have been hooking to the telephone lines since the 90s, but that has nothing to do with the phone line itse.f
This is a physical problem. There is only so much spectrum available. Once the air is saturated on the allocated frequencies, we are done. No more room, period.
Nonsense. There's plenty of ways to make wireless networks scale.
Just off the top of my head, there are physical layer techniques, such as MIMO, that change the value of Shannon's limit by dramatically improving the signal/noise ration. There are network layer techniques, such as mesh networking, that allow you to use a larger number of less powerful radios, and hence allow more sharing of bandwidth in a given space. There are application layer techniques, such as distributed caching.
And all of that is without getting the politicians involved to give us back some of the bandwidth they have been giving away to corporations.
The original 8086 processor could address 1 megabyte of memory (20 bits) with a 16 bit processor. It used two registers (one shifted left by four bits) to address memory.
Have you ever programmed in that model?
Having pointers split into segment:offset pairs meant that you couldn't (easily) have a single array span more than 64kB. Any program that needed to access arrays above that had to split its arrays into arrays of arrays, each of which was smaller. Fun, fun, fun.
A 64 bit processor could trivially access a 128-bit address space by using the same segment:offset method.
I'll let you do the programming, this time. I'll stick to the flat memory model of today's architectures, if that's all right with you.