Packet loss at the low levels is corrected for in the middle and never makes it to the top levels unless you pick top layer protocols like RTP that are designed explicitly not to correct it automatically.
Not really. TCP, for instance, will react to packet loss as an indication of congestion, and your performance will collapse. (Anything more than one packet lost per RTT, and you're dead.)
I look forward to him publishing future articles from a home-built, hand-fabricated microcomputer, or perhaps some sort of elaborate open-source mechanical turing machine, when he decides that nonfree microcode is unacceptable.;)
I'd put it somewhat differently. Somebody once said that technological progress is like a herd of pigs: it gives you bacon, so who cares if it your courtyard smells funny.
The problem that RMS is trying to tackle is how to get your bacon without being overridden with the shit.
If you agreed with RMS in principle, and wanted to create a SAAS business that is ethical, how would you do it?
[...]
Making sure your users are able to get copies of their data in a useful format that are complete enough for them to walk away from you is an obvious one.
What about data retention? You'll want your clients to have the ability to delete any data they ever stored on your servers, including logs. And you'll want to do that in a manner that is compatible with the data retention laws of your jurisdiction.
I'm trying to figure out what's different, other than the fact we now have the DMCA.
In the 80s, the media distribution industry was thriving.
In the meantime, they missed the opportunity to use the Internet as a distribution medium, and they're still trying to get us to go to shops and buy packaged disks of transparent plastic.
They're a dying industry, trying to survive by any means.
Could one day we just learn to deal with the 1000ms latency times of a completely satellite-based network?
A satellite net is suboptimal for day-to-day traffic, but it's just perfect for backup. I'm sure you'd be willing to deal with a couple seconds RTT when all the other links are broken.
But redundancy doesn't pay -- it's more economic for an operator to have no redundancy, and blame any issues it has on the trade unions.
(I'm actually amazed to hear that the emergency services went off too -- they don't even have backup for 911 service.)
It's not multiple cuts. It's just two cuts, done within two hours. The two sites are apparently within an hours' drive.
So it's not some massive conspiracy, just a single person with a saw.
Interestingly enough, while our best-beloved governments are posturing about how they need to enact even more security laws in order to fight terrorism, a single person with a chainsaw is all it takes to deprive a large area of telephone and Internet service, including emergency service.
The scenarios benefiting from Long Mode would be:...
Long mode is much faster for applications that need 64-bit arithmetic. On a core 2, I've found that many crypto operations are twice as fast in 64-bit as in 32-bit (pretty cool if you run with your disks encrypted).
Since long mode offers twice as many registers as 32-bit mode, many compilers will do a much better job allocating registers in long mode. Good C compilers tend to gain 5% to 10%, it's somewhat more than that for Lisp and ML compilers (which tend to have less finely tuned register allocators).
Finally, the large address space makes some things easier; in particular, you don't need to tune the size of your thread stacks, and you don't need to refrain from mmapping large files. And easier to code implies fewer user-visible bugs.
You're confused. There already are reverse engineered drivers for Broadcom chips, and they are included in the Linux kernel tree, no less (b43 and b43legacy). These drivers were not developed by Broadcom, who provide their own binary driver for 2.4 kernels (wl.o).
This is about the firmware -- the binary blob that is loaded into the chip's embedded CPU, and with which the drivers, whether binary or opensource, need to interact.
I, for one, welcome open source firmware, and am looking forward to using the firmware's idea of link quality in my mesh networking experiments.
the XO has a Marvell chip which implements a mesh-networking AP, so that the XO can act as a repeater even when the main power is turned off.
AFAIK, the Marvell chip has an on-board MIPS core and 64 kB of memory, so you can run whatever you can fit in 64 kB of MIPS code without CPU intervention.
Two firmwares are available, one that makes the chip act as a normal, softmac wifi chip, and one that implements parts of 802.11s in the chip -- IIRC, forwarding is done in the chip, but routing table management is done by the CPU.
The chip will not continue working when system power is off, but it will forward packets without waking the CPU. This means that the CPU can spend longer periods of time in a power-saving mode (C3, probably).
"When MP3 files are added (either manually or automatically) to either the Windows Media Player or the Windows Media Center library, or if the file metadata is edited with Windows Explorer, several seconds of audio data may be permanently removed from the start of the file. This issue occurs when files contain thumbnails or other metadata of significant size before importing or editing them."
The CBP officers asked if they could search the car[...] Jack told them to fuck off
Lucky Jack, he lives in a free country.
Over here, in France, a police officer has the right to search your car as long as he's Officier de Police Judiciaire (OPJ) or is acting under the orders of an OPJ.
The catch? Almost all French police officers are OPJ.
I don't agree w/ Eric on this one. The shift from 32-bit to 64-bit systems has been darn near seamless as compared to previous transitions. That's a far cry from the 8-to-16 jump or the 16-to-32 jump.
Honestly, most people can't tell that they've shifted from 32-bit to 64-bit. If there wasn't a dialog box or a sticker that told them they'd switched, they wouldn't know.
Initially, the switch from 16- to 32-bit was just as un-interesting. People upgraded to a 32-bit OS (VMS, or 4BSD, or 386 Xenix, or Windows 95) and their old PDP-11 or 286 binaries ran just the same, except that more of them could fit into memory at the same time.
When people started to use versions that had been recompiled for the VAX or 386, the user experience still didn't change much.
Over time, the developers started learning to program with the larger address space (128kB arrays without playing silly games with pointers!) and the larger ints (no need to check for overflow around 32000!), and only then did the user experience actually change.
Right now, we're still using programs written for 32-bit platforms that happen to have been recompiled for 64-bit pointers. Over time, developeprs will learn to program for the large address space, and at that point, the user experience is likely to change again.
On Linux (and other modern systems, perhaps now including Windows), you can turn off swap. However, the Linux kernel's memory management isn't so great at the situation you hit when you need more memory than you have, but you can't swap. Usually, the memory hog crashes as a result
Oh my... you want the full answer on this one?
Modern operating systems don't actually allocate the memory that a user-space application asks for. When the user-space application calls brk, malloc or VirtualAlloc, the calls always succeeds. The memory will be actually allocated lazily, the first time the application touches it. If the system runs out of memory, it is too late to return an error code from the memory allocation call, so the application will most likely crash with SIGSEGV. (An alternate, somewhat suboptimal, semantics is to crash the whole system.)
Obviously, not everyone is happy with this situation. Some proprietary Unices (notably AIX) deal with it by sending warnings to a process before crashing it with SIGSEGV. Under Linux, you can tune this behaviour with the vm.overcommit_memory and vm.overcommit_ratio sysctls, which tune how willingly the system will return success for memory allocations for memory it doesn't actually have. While tuning these values is something of a black art, when done correctly, it can prevent crashes of properly written applications without impairing functionality.
If there's any possible route between me and http://slashdot.org/ I want the system to find it, dammit!
But you're not alone involved. The people who provide the route between you and Slashdot, known as transit providers, want to be paid. Hence, they carefully filter what routes they advertise, and only allow those for which there is a paid agreement for.
This is known as policy routing or route filtering.
Would you stop giving the damn ISP's more reasons to slack off on implementing IPv6!!!
When their customers do their own tunnelling, ISPs loose the ability to perform their own traffic engineering, and loose money.
Once they see that they are loosing money because people are implementing their own tunnelling, ISPs will rush to implement native IPv6, in a form that they can control.
Anyway, does anyone have any sources as to know the other "big" OS's (MS Windows, Mac OS, the BSD's etc.) were able to speak IPv6
All currently shipping operating systems have full support for IPv6. This includes Linux (2.4 and 2.6), FreeBSD and NetBSD, Windows XP SP2 and Vista, Mac OS X (since at least 10.2).
IPv6 is enabled by default on all of the above except Windows XP, on which it must be enabled by the user.
Unfortunately, my ISP [...] is stuck in dark ages.
You don't need assistance from your ISP to get IPv6 connectivity. You can use a number of IPv6 transition mechanisms, such as 6to4, Teredo, or configured tunnelling, to reach the IPv6 Internet wherever you are.
I wonder if this could be used to help port OpenWRT over to the atheros chipset. Currently the only routers that OpenWRT (and conversely by that DD-WRT) really work well on are the broadcom chipsets.
Just the opposite. Broadcom-based routers work, but they use a binary driver and hence they are stuck with a 2.4 kernel. Which makes them unusable for those of us trying e.g. to build IPv6 firewalls.
The Atheros-based routers, on the other hand, are rock solid under 2.6.25. I'm running 10 of those in an experimental mesh network.
Packet loss at the low levels is corrected for in the middle and never makes it to the top levels unless you pick top layer protocols like RTP that are designed explicitly not to correct it automatically.
Not really. TCP, for instance, will react to packet loss as an indication of congestion, and your performance will collapse. (Anything more than one packet lost per RTT, and you're dead.)
I look forward to him publishing future articles from a home-built, hand-fabricated microcomputer, or perhaps some sort of elaborate open-source mechanical turing machine, when he decides that nonfree microcode is unacceptable. ;)
I'd put it somewhat differently. Somebody once said that technological progress is like a herd of pigs: it gives you bacon, so who cares if it your courtyard smells funny.
The problem that RMS is trying to tackle is how to get your bacon without being overridden with the shit.
If you agreed with RMS in principle, and wanted to create a SAAS business that is ethical, how would you do it?
[...]
Making sure your users are able to get copies of their data in a useful format that are complete enough for them to walk away from you is an obvious one.
What about data retention? You'll want your clients to have the ability to delete any data they ever stored on your servers, including logs. And you'll want to do that in a manner that is compatible with the data retention laws of your jurisdiction.
I'm trying to figure out what's different, other than the fact we now have the DMCA.
In the 80s, the media distribution industry was thriving.
In the meantime, they missed the opportunity to use the Internet as a distribution medium, and they're still trying to get us to go to shops and buy packaged disks of transparent plastic.
They're a dying industry, trying to survive by any means.
Could one day we just learn to deal with the 1000ms latency times of a completely satellite-based network?
A satellite net is suboptimal for day-to-day traffic, but it's just perfect for backup. I'm sure you'd be willing to deal with a couple seconds RTT when all the other links are broken.
But redundancy doesn't pay -- it's more economic for an operator to have no redundancy, and blame any issues it has on the trade unions.
(I'm actually amazed to hear that the emergency services went off too -- they don't even have backup for 911 service.)
It's not multiple cuts. It's just two cuts, done within two hours. The two sites are apparently within an hours' drive.
So it's not some massive conspiracy, just a single person with a saw.
Interestingly enough, while our best-beloved governments are posturing about how they need to enact even more security laws in order to fight terrorism, a single person with a chainsaw is all it takes to deprive a large area of telephone and Internet service, including emergency service.
Using the proprietary nVidia driver makes you a "newbie"?
Yes, it does. It means that you bought hardware without first checking for good Linux support.
I haven't had any problems getting it.
I stand corrected. Sorry for the mis-information.
[Broadcom] also provide a closed driver for 2.6 kernels.
I've heard there's one, but unlike the 2.4 version, it is not widely available.
The scenarios benefiting from Long Mode would be: ...
Long mode is much faster for applications that need 64-bit arithmetic. On a core 2, I've found that many crypto operations are twice as fast in 64-bit as in 32-bit (pretty cool if you run with your disks encrypted).
Since long mode offers twice as many registers as 32-bit mode, many compilers will do a much better job allocating registers in long mode. Good C compilers tend to gain 5% to 10%, it's somewhat more than that for Lisp and ML compilers (which tend to have less finely tuned register allocators).
Finally, the large address space makes some things easier; in particular, you don't need to tune the size of your thread stacks, and you don't need to refrain from mmapping large files. And easier to code implies fewer user-visible bugs.
Typically, it's MIPS32 R4000 architecture.
To be entirely pedantic, it's usually a MIPS32 4k core, which is derived from the old R4000 chip.
... no longer needing ndiswrapper
You're confused. There already are reverse engineered drivers for Broadcom chips, and they are included in the Linux kernel tree, no less (b43 and b43legacy). These drivers were not developed by Broadcom, who provide their own binary driver for 2.4 kernels (wl.o).
This is about the firmware -- the binary blob that is loaded into the chip's embedded CPU, and with which the drivers, whether binary or opensource, need to interact.
I, for one, welcome open source firmware, and am looking forward to using the firmware's idea of link quality in my mesh networking experiments.
the XO has a Marvell chip which implements a mesh-networking AP, so that the XO can act as a repeater even when the main power is turned off.
AFAIK, the Marvell chip has an on-board MIPS core and 64 kB of memory, so you can run whatever you can fit in 64 kB of MIPS code without CPU intervention.
Two firmwares are available, one that makes the chip act as a normal, softmac wifi chip, and one that implements parts of 802.11s in the chip -- IIRC, forwarding is done in the chip, but routing table management is done by the CPU.
The chip will not continue working when system power is off, but it will forward packets without waking the CPU. This means that the CPU can spend longer periods of time in a power-saving mode (C3, probably).
'To protect your MP3 files' - uhm, wtf?!
According to Computer World:
The CBP officers asked if they could search the car[...] Jack told them to fuck off
Lucky Jack, he lives in a free country.
Over here, in France, a police officer has the right to search your car as long as he's Officier de Police Judiciaire (OPJ) or is acting under the orders of an OPJ.
The catch? Almost all French police officers are OPJ.
I don't agree w/ Eric on this one. The shift from 32-bit to 64-bit systems has been darn near seamless as compared to previous transitions. That's a far cry from the 8-to-16 jump or the 16-to-32 jump.
Honestly, most people can't tell that they've shifted from 32-bit to 64-bit. If there wasn't a dialog box or a sticker that told them they'd switched, they wouldn't know.
Initially, the switch from 16- to 32-bit was just as un-interesting. People upgraded to a 32-bit OS (VMS, or 4BSD, or 386 Xenix, or Windows 95) and their old PDP-11 or 286 binaries ran just the same, except that more of them could fit into memory at the same time.
When people started to use versions that had been recompiled for the VAX or 386, the user experience still didn't change much.
Over time, the developers started learning to program with the larger address space (128kB arrays without playing silly games with pointers!) and the larger ints (no need to check for overflow around 32000!), and only then did the user experience actually change.
Right now, we're still using programs written for 32-bit platforms that happen to have been recompiled for 64-bit pointers. Over time, developeprs will learn to program for the large address space, and at that point, the user experience is likely to change again.
On Linux (and other modern systems, perhaps now including Windows), you can turn off swap. However, the Linux kernel's memory management isn't so great at the situation you hit when you need more memory than you have, but you can't swap. Usually, the memory hog crashes as a result
Oh my... you want the full answer on this one?
Modern operating systems don't actually allocate the memory that a user-space application asks for. When the user-space application calls brk, malloc or VirtualAlloc, the calls always succeeds. The memory will be actually allocated lazily, the first time the application touches it. If the system runs out of memory, it is too late to return an error code from the memory allocation call, so the application will most likely crash with SIGSEGV. (An alternate, somewhat suboptimal, semantics is to crash the whole system.)
Obviously, not everyone is happy with this situation. Some proprietary Unices (notably AIX) deal with it by sending warnings to a process before crashing it with SIGSEGV. Under Linux, you can tune this behaviour with the vm.overcommit_memory and vm.overcommit_ratio sysctls, which tune how willingly the system will return success for memory allocations for memory it doesn't actually have. While tuning these values is something of a black art, when done correctly, it can prevent crashes of properly written applications without impairing functionality.
Windows [...] is internally configured to use an LRU algorithm to aggressively page.
Are you sure about that? I was under the impression that it uses a working-set model with page stealing.
If there's any possible route between me and http://slashdot.org/ I want the system to find it, dammit!
But you're not alone involved. The people who provide the route between you and Slashdot, known as transit providers, want to be paid. Hence, they carefully filter what routes they advertise, and only allow those for which there is a paid agreement for.
This is known as policy routing or route filtering.
So why did traffic stop flowing?
Because there were no alternate routes — nobody was being paid to provide paid transit between Cogent and Sprint. Pleas see this Slashdot comment.
Would you stop giving the damn ISP's more reasons to slack off on implementing IPv6!!!
When their customers do their own tunnelling, ISPs loose the ability to perform their own traffic engineering, and loose money.
Once they see that they are loosing money because people are implementing their own tunnelling, ISPs will rush to implement native IPv6, in a form that they can control.
Anyway, does anyone have any sources as to know the other "big" OS's (MS Windows, Mac OS, the BSD's etc.) were able to speak IPv6
All currently shipping operating systems have full support for IPv6. This includes Linux (2.4 and 2.6), FreeBSD and NetBSD, Windows XP SP2 and Vista, Mac OS X (since at least 10.2).
IPv6 is enabled by default on all of the above except Windows XP, on which it must be enabled by the user.
Another smaller one here have been offering IPv6 [for] ages
Nerim, since 2002.
Unfortunately, my ISP [...] is stuck in dark ages.
You don't need assistance from your ISP to get IPv6 connectivity. You can use a number of IPv6 transition mechanisms, such as 6to4, Teredo, or configured tunnelling, to reach the IPv6 Internet wherever you are.
If you happen to be using Linux, I wrote a quick HOWTO about getting IPv6 connectivity without your ISP being involved.
I wonder if this could be used to help port OpenWRT over to the atheros chipset. Currently the only routers that OpenWRT (and conversely by that DD-WRT) really work well on are the broadcom chipsets.
Just the opposite. Broadcom-based routers work, but they use a binary driver and hence they are stuck with a 2.4 kernel. Which makes them unusable for those of us trying e.g. to build IPv6 firewalls.
The Atheros-based routers, on the other hand, are rock solid under 2.6.25. I'm running 10 of those in an experimental mesh network.