I'm blocking Netflix IPv6 subnets on my router with ICMPv6 no-route-to-host. Windows, Mac and Android clients all seem to immediately fall back to IPv4 and play as normal. It seems like a better solution than disabling IPv6 outright.
If you use your PC for both work and non-work activities, or anything else like that, one way to keep yourself from distracting yourself is to maintain separate logins.
For example, I have a desktop PC in my home office that I use for both work and for pleasure/gaming/etc. It's usually running Windows 7. I maintain two independent desktop logins - one for work, one for non-work. In this way when I'm on the clock for work, my whole environment says it's work time. That cool web site I was reading last night? The bookmark for it is on the other desktop; I can't see it from here. When I finish work at 5pm or whatever, I switch desktops, and now all my work-related stuff is invisible again. Likewise I have separate mailboxes and domain names, separate logins on my Linux box,... it's as if I'm two complete people. I find this helpful to avoid distractions.
Meeting you and the rest of the guys at Linuxworld '99 was a high point for me. I was working the UF booth across the aisle, my first time in San Jose. Envied your awesome inflatable furniture.
Take care of yourself and your family, and good luck in the future with whatever you do.
It can be convenient to prioritize UDP over other traffic for simple QoS at a shared broadband gateway. It catches DNS queries, VoIP, gamers, and most anything else small and sensitive.
In an attempt to avoid ISP filters the P2P users sprawl across all 64k TCP ports. Now the UDP portspace will be covered in P2P crap too. There are lots of major IP protocol numbers left... at least in my copy of/etc/protocols. I wish they'd used a new protocol for this instead of UDP.
But then again, I think we all know the real motivation for this effort is simply to make it more difficult to segregate P2P at the ISP. I don't really care about that; my problem is the collateral damage.
The article is just plain wrong. DOCSIS 1.0 modems can be provisioned with whatever maximum downstream and upstream rate the operator chooses. They can also be easily probed via SNMP to collect traffic statistics for traffic billing, ie $5/GB after the first GB or etc. So can the CMTS. Lots of providers are already doing this, and it isn't rocket science, believe me. The only really interesting thing 1.1 introduces is the ability to guarantee a certain amount of bandwidth to a customer... but as they always oversell bandwidth by 100-200 times already, there's not much use in that.
Regarding this CAT stuff, the article does point out correctly that the NAT is out of the bag. There's no turning back now, guys. As long as you want to sell IP service, people will do IP things with it.
How the hell are you supposed to learn how to read schematics when they're not to be found? I learned how to read them by presenting them to my father and asking him to explain them to me. How can I do the same for my own kids when the manufacturers treat the products as some sort of secret black box that nobody would ever want to fix?
I think the popularity of free software illustrates that some people need DIY access to the things around them, and if the manufacturers of consumer products insist on locking consumers out of the guts, then we'll just have to DIY from scratch. That or reverse-engineer the products despite them and publicise the results.
Every car *should* come with the source code for the engine computer. I've made mods to my car that would greatly benefit from minor tweeks to the code in that flash chip. No source code? No interface specs? For something I just paid you for? Fuck you too! I don't care if Mrs NineNine down the street can't read them. She could bloody well ask me to help. What does it cost them to provide this info? What do they gain by keeping internals secret? Why, exactly, do they want to get in my way? Who's making more money this way?
The newer Intel chipsets include the PIIX4 in the south bridge, which doesn't suffer from the shared-buffer problem mentioned in the Beowulf document. Most Pentium boards (ie TX chipset) and pretty much all P2/Celeron/Slot1/Socket370 boards have independant IDE channels. They also support UltraDMA, so the CPU isn't loaded down managing the drives. If you can limit yourself to one drive per IDE channel, there isn't much of a performance penalty in using IDE over SCSI. It can easily win many bang-for-the-buck contests.
Read-ahead in the drive firmware can sort-of supply some of the benefits of SCSI's bus disconnection feature too. ATA-33 and now ATA-66 can manage transfers from the drive's buffer cache to the system at more than twice the media rate, so the dual-drive channel isn't hurting for bandwidth... you just need to keep it from stalling. If the RAID chunk size is fairly small, say 4K, then while you're transfering that data from drive0 to memory drive1 will be filling it's buffer with the next 4K from automatic read-ahead. This means on purely sequential transfers the combined transfer rate approaches the sum of the media rates. The bus will still stall on random seeks of course... it's still no SCSI subsystem. But it does well enough to suprise a lot of SCSI fans.
I'd rather have a new SCSI drive than a new IDE drive, but I'd take a new IDE drive over a SCSI drive a generation behind.
I've always thought of SGI as one of the coolest companies in the industry, but this announcement has put them over the top in my book. Wow. Thankyou, thankyou, thankyou SGI. I don't care if you're really doing it for your own self-interest; you're also helping a large community in a very big way, and I hope you reap equally large rewards for it.
Slashdot Mirror
Rest in peace.
There's a great animated short by John Weldon that explores this topic. It's called To Be and can be found at this URL: http://www.nfb.ca/film/to_be/
I'm blocking Netflix IPv6 subnets on my router with ICMPv6 no-route-to-host. Windows, Mac and Android clients all seem to immediately fall back to IPv4 and play as normal. It seems like a better solution than disabling IPv6 outright.
Mikrotik RouterOS syntax:
add address=2406:da00:ff00::/48 list=netflix
add address=2600:1407:19::/48 list=netflix
add address=2607:f8b0:4001::/48 list=netflix
add address=2620:108:700f::/48 list=netflix
add address=2a01:578:3::/48 list=netflix
add chain=forward dst-address-list=netflix action=reject
SLS, then Slackware, then Redhat, then Fedora, now CentOS. But I've always had other boxes around like FreeBSD and Gentoo.
If you use your PC for both work and non-work activities, or anything else like that, one way to keep yourself from distracting yourself is to maintain separate logins.
For example, I have a desktop PC in my home office that I use for both work and for pleasure/gaming/etc. It's usually running Windows 7. I maintain two independent desktop logins - one for work, one for non-work. In this way when I'm on the clock for work, my whole environment says it's work time. That cool web site I was reading last night? The bookmark for it is on the other desktop; I can't see it from here. When I finish work at 5pm or whatever, I switch desktops, and now all my work-related stuff is invisible again. Likewise I have separate mailboxes and domain names, separate logins on my Linux box, ... it's as if I'm two complete people. I find this helpful to avoid distractions.
Meeting you and the rest of the guys at Linuxworld '99 was a high point for me. I was working the UF booth across the aisle, my first time in San Jose. Envied your awesome inflatable furniture.
Take care of yourself and your family, and good luck in the future with whatever you do.
It can be convenient to prioritize UDP over other traffic for simple QoS at a shared broadband gateway. It catches DNS queries, VoIP, gamers, and most anything else small and sensitive.
In an attempt to avoid ISP filters the P2P users sprawl across all 64k TCP ports. Now the UDP portspace will be covered in P2P crap too. There are lots of major IP protocol numbers left... at least in my copy of /etc/protocols. I wish they'd used a new protocol for this instead of UDP.
But then again, I think we all know the real motivation for this effort is simply to make it more difficult to segregate P2P at the ISP. I don't really care about that; my problem is the collateral damage.
Regarding this CAT stuff, the article does point out correctly that the NAT is out of the bag. There's no turning back now, guys. As long as you want to sell IP service, people will do IP things with it.
The only way out is usage-based billing IMO.
How the hell are you supposed to learn how to read schematics when they're not to be found? I learned how to read them by presenting them to my father and asking him to explain them to me. How can I do the same for my own kids when the manufacturers treat the products as some sort of secret black box that nobody would ever want to fix?
I think the popularity of free software illustrates that some people need DIY access to the things around them, and if the manufacturers of consumer products insist on locking consumers out of the guts, then we'll just have to DIY from scratch. That or reverse-engineer the products despite them and publicise the results.
Every car *should* come with the source code for the engine computer. I've made mods to my car that would greatly benefit from minor tweeks to the code in that flash chip. No source code? No interface specs? For something I just paid you for? Fuck you too! I don't care if Mrs NineNine down the street can't read them. She could bloody well ask me to help. What does it cost them to provide this info? What do they gain by keeping internals secret? Why, exactly, do they want to get in my way? Who's making more money this way?
The newer Intel chipsets include the PIIX4 in the south bridge, which doesn't suffer from the shared-buffer problem mentioned in the Beowulf document. Most Pentium boards (ie TX chipset) and pretty much all P2/Celeron/Slot1/Socket370 boards have independant IDE channels. They also support UltraDMA, so the CPU isn't loaded down managing the drives. If you can limit yourself to one drive per IDE channel, there isn't much of a performance penalty in using IDE over SCSI. It can easily win many bang-for-the-buck contests.
Read-ahead in the drive firmware can sort-of supply some of the benefits of SCSI's bus disconnection feature too. ATA-33 and now ATA-66 can manage transfers from the drive's buffer cache to the system at more than twice the media rate, so the dual-drive channel isn't hurting for bandwidth... you just need to keep it from stalling. If the RAID chunk size is fairly small, say 4K, then while you're transfering that data from drive0 to memory drive1 will be filling it's buffer with the next 4K from automatic read-ahead. This means on purely sequential transfers the combined transfer rate approaches the sum of the media rates. The bus will still stall on random seeks of course... it's still no SCSI subsystem. But it does well enough to suprise a lot of SCSI fans.
I'd rather have a new SCSI drive than a new IDE drive, but I'd take a new IDE drive over a SCSI drive a generation behind.
Perl? Yet another case of too much tool for the job. :)
Try this: Fire up an xterm and resize it to 15 lines long. Then 'less sw1.txt', and hold down ctrl-F.
Ok, it might go a bit fast...
I've always thought of SGI as one of the coolest companies in the industry, but this announcement has put them over the top in my book. Wow. Thankyou, thankyou, thankyou SGI. I don't care if you're really doing it for your own self-interest; you're also helping a large community in a very big way, and I hope you reap equally large rewards for it.