Tvheadend is pretty good these days. The only thing in your list that I haven't seen any evidence of is commercial skipping.
I've just migrated off mythtv onto tvheadend and kodi and because they didn't have a great legacy of old analog tuners and other crazy, the setup for a bunch of DVB-T and DVB-S tuners makes a ton more sense than the gymnastics you had to do to map different multiplexes to specific tuners.
Check out the IPv4 address space consumption graphs at http://www.potaroo.net/tools/i..., there is no new space for you in North America. In fact the only place there is still new space for you is in the African region.
See the 1/8 remaining red line, that's where most of the RIR's started their run out policy which for APNIC at least this means you can only get space if you are using it to transition to IPv6.
Noone is going to make anyone give up their old/8 IPv4 allocations and if they did it, would delay this date by a couple of months.
Please return the user interface to how it was. You are just pissing the long term userbase off.
Pulling out the read more link is like pulling the start button / menu from windows 8. It is a user interface disaster because it's not obvious w\ here you should click for the comments.
Slashdot has always been about the comments, if you minimise them by obfuscating the link to them you are left with the news stories from reddit \ a couple of days late and some obvious paid advertising plants.
Implementing aspects of the failed beta interface piecemeal with no discussion seems a bit underhanded.
If you aren't lucky you might succeed at killing slashdot which would be a shame.
The mind just boggles at how incredibly futile it is going to be googling for help on an app called 'Software'. I think the gnome guys have gone from mild contempt for the user to rabid hate and fury.
I get Sydney because that is one of the only places that is approximately 30ms away. The details on what the traceroute's actually had in them are fuzzed away by the reporter, so you can't rely on them to say anything in particular.
Anycast nodes switching about could look a whole lot like the latency just going up to the uninitiated. Most internet providers don't actually have a huge say in which anycast node for a service gets chosen by their network unless they actually have a local node in their own network.
To address the issue in the article, I expect that if Chorus / Telecom received a request to tap your connection you will never know that they have tapped it. The dark fibre circuits we have through them are provisioned on day one with an optical tap that is configured to direct a small percentage of the light to any gear that they might one day connect to it. The latency would be completely unaffected.
What makes more sense given the story is that Dotcom was on a fast fibre tail using a service that was actually in Sydney somewhere ( ~30ms away ) and for whatever reason this service switched to a node in the middle of the USA which could be 180ms away. Nothing there to do with taps or government conspiracies. They may well have been tapping his circuit as well, but the latency won't be anything to do with it. Even if they did have to divert his connection through some GCSB site, the latency would not be as high as 180ms.
As far as ping times to perth, from the same box in skytower:
[ ~ ]$ ping www.perthix.com PING www.perthix.com (203.188.158.32) 56(84) bytes of data. 64 bytes from 203.188.158.32: icmp_seq=1 ttl=120 time=81.3 ms 64 bytes from 203.188.158.32: icmp_seq=2 ttl=120 time=80.1 ms 64 bytes from 203.188.158.32: icmp_seq=3 ttl=120 time=81.2 ms ^C --- www.perthix.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 80.181/80.933/81.383/0.628 ms
I've got my own access card for Level 47 and 48 of Sky tower, I'm aware of exactly what it is and why we decided to buy co-location space up there.
Our connection from skytower has to go a way across town before it hits the southern cross landing station, so the best case latency across southern cross is a bit lower again.
My point earlier on was that you can get anywhere return trip in New Zealand on a fibre circuit in under 35ms. Add the 24ms to get across to Australia or the 120ms to get to San Jose and you still don't get to 180ms unless you are using ADSL2+ or cable. Our POP in Christchurch is 20ms from Skytower in Auckland.
At the place I work, I would accept as a fault any report from a customer of latency of 200ms to anywhere physically in New Zealand ( aside from end customer tail latency ). Most ISP's in New Zealand peer at either WIX or APE or both and we pay extortionate rates for paid peering with Telecom and TelstraClear to handle the two exceptions to that rule.
The worst case for us is that we have an end customer in Christchurch that is talking to an end customer in Christchurch of an ISP that only peers with us in Auckland. Even that only means about 40ms worst case plus the latency of the tail circuits.
If I recall correctly ( cant remember where I read it ) Mr Dotcom had fibre from his place at Coatesville to sky tower. That is something in the order of 35km, which should be like 1 or 2ms.
You would have to have a very home user grade circuit like cable or dsl to get exactly 30ms across Auckland.
If the latency figures in the article are accurate then the traffic wasn't staying in the country at all. You can get from one end of the country to the other in 35ms round trip, so even the original 30ms seems rubbish unless the circuit was DSL. The way they were making out it was a high end connection that doesn't seem likely. 180ms will easily get you too Australia and all going well will get you to San Jose from New Zealand.
What if you have run something that updates the id3 tags, album art or volume levels as I expect most people do. I ran windows media player once ( by mistake ) and I think it wanted to do this by default? Any fiddling with any of the stuff in the header is going to change the hash of the file completely.
I guess they could get more sophisticated and just hash the parts of the mp3 that aren't in the header. I'm sure you could get around that by just flipping the least significant bit somewhere in each track.
Seems like prosocuting based on that would be getting into voodoo territory for the cops in my country. I reckon equal odds of bringing in a psychic and presenting a 'strong feeling' the mp3's are the estranged child of some RIAA IP. In all seriousness they would just ask you where the originals are and hope that you don't have a plausible story about a house fire or burglary or something.
The range of a wireless link is determined by adding the strengths of the Access Point and Client antennas together. To state it another way, if someone puts a higher gain antenna on their laptop then they can connect to your AP from futher away.
Trying to secure something by diffuse or decrease your signal strength at the AP end is a great way of feeling more secure without actually being more secure.
I don't know how to say it better than I did in the post you were replying to. I'll try, but perhaps you should read it again.
You can stop almost everything you don't want coming in with a non-stateful static ACL on the upstream router or something like a 3750 switch. The web server or reverse proxy or whatever you have then only has to handle traffic destined for port 80 ( and perhaps ssh from a couple of IP's ). A switch or a router can run that ACL in hardware at the line rate of the port without operating a state table at all, and it doesn't give the attacker a new easy way of taking your site out.
Theres no reason why the host can't have local firewalling too, but it is pretty well irrelevant at that point.
Well hopefully you aren't going to be consulting on anything important that gets deployed.
A stateless ACL on a switch or router that does it in a hardware path will do just fine dropping packets destined for unintended services, and it won't act as an additional attack vector.
A firewall in front of a server farm is a 'layer' that only does harm, and does not do any good.
The article writer is just a clueless journalist but the guy he is getting the technical content from knows what he is talking about. Look up the NANOG archives for Roland Dobbins if you want to read through the flame wars along these lines before.
Any firewall that does stateful filtering is just another attack vector in a big web server deployment. Most firewalls can be either crashed or will start refusing new connections with only a few thousand packets per second of the right stuff. Either way your site is down and the DDOS successful when it happens.
If you put in non-stateful ACL's on a router or switch that does them in a hardware path in front of your web farm to filter anything other than port 80 then you can eliminate most of the cruft at line rate without giving the attacker a nice juicy state table to destroy.
Your web server has to maintain the connection state to run anyway, so why not just let it do that and have the problem distributed among all your web servers, they deal with it a heap better than any firewall.
How about putting an A or AAAA record in a reverse DNS zone, so your site ends up looking like http://2.0.192.in-addr.arpa/ or whatever. There is no registry involved with the delegation of those reverse zones, so it would be alot more difficult for anyone to interfere with it.
What will make it even more fun is if you have two branch offices of the same company connected to the different ISPs getting 172.16.32.66 and 10.0.65.88, how do you set up a VPN between them?
We have assigned 14/8's _this year_ so far, so if you magically get all of those back, you don't even get a years delay. I guess when you say 'That's a LOT of unused IP's' the missing information is that 'We go through a LOT of IP's'.
Spend that effort and money on deploying IPv6 instead.
You could go through every one of those and fight the massive legal battle to get them all back ( probably taking us well beyond the date when we are out anyway ), and you have only bought a year or two.
Save yourself the trouble and deploy IPv6, instead of making lawyers rich and then deploying IPv6.
Slashdot Mirror
Tvheadend is pretty good these days. The only thing in your list that I haven't seen any evidence of is commercial skipping.
I've just migrated off mythtv onto tvheadend and kodi and because they didn't have a great legacy of old analog tuners and other crazy, the setup for a bunch of DVB-T and DVB-S tuners makes a ton more sense than the gymnastics you had to do to map different multiplexes to specific tuners.
Get off my lawn! =)
Check out the IPv4 address space consumption graphs at http://www.potaroo.net/tools/i..., there is no new space for you in North America. In fact the only place there is still new space for you is in the African region.
See the 1 /8 remaining red line, that's where most of the RIR's started their run out policy which for APNIC at least this means you can only get space if you are using it to transition to IPv6.
Noone is going to make anyone give up their old /8 IPv4 allocations and if they did it, would delay this date by a couple of months.
It's all over man.
I'm loving the irony of you letting people know where the link is to the comments inside the comments section.
The AC braintrust has done well.
Please return the user interface to how it was. You are just pissing the long term userbase off.
Pulling out the read more link is like pulling the start button / menu from windows 8. It is a user interface disaster because it's not obvious w\
here you should click for the comments.
Slashdot has always been about the comments, if you minimise them by obfuscating the link to them you are left with the news stories from reddit \
a couple of days late and some obvious paid advertising plants.
Implementing aspects of the failed beta interface piecemeal with no discussion seems a bit underhanded.
If you aren't lucky you might succeed at killing slashdot which would be a shame.
The mind just boggles at how incredibly futile it is going to be googling for help on an app called 'Software'. I think the gnome guys have gone from mild contempt for the user to rabid hate and fury.
Amazing.
ditto regarding the badly disguised spam stuff.
I was here before there were user id's and I just happened to get in pretty early the day they opened registrations.
I get Sydney because that is one of the only places that is approximately 30ms away. The details on what the traceroute's actually had in them are fuzzed away by the reporter, so you can't rely on them to say anything in particular.
Anycast nodes switching about could look a whole lot like the latency just going up to the uninitiated. Most internet providers don't actually have a huge say in which anycast node for a service gets chosen by their network unless they actually have a local node in their own network.
To address the issue in the article, I expect that if Chorus / Telecom received a request to tap your connection you will never know that they have tapped it. The dark fibre circuits we have through them are provisioned on day one with an optical tap that is configured to direct a small percentage of the light to any gear that they might one day connect to it. The latency would be completely unaffected.
What makes more sense given the story is that Dotcom was on a fast fibre tail using a service that was actually in Sydney somewhere ( ~30ms away ) and for whatever reason this service switched to a node in the middle of the USA which could be 180ms away. Nothing there to do with taps or government conspiracies. They may well have been tapping his circuit as well, but the latency won't be anything to do with it. Even if they did have to divert his connection through some GCSB site, the latency would not be as high as 180ms.
As far as ping times to perth, from the same box in skytower:
[ ~ ]$ ping www.perthix.com
PING www.perthix.com (203.188.158.32) 56(84) bytes of data.
64 bytes from 203.188.158.32: icmp_seq=1 ttl=120 time=81.3 ms
64 bytes from 203.188.158.32: icmp_seq=2 ttl=120 time=80.1 ms
64 bytes from 203.188.158.32: icmp_seq=3 ttl=120 time=81.2 ms
^C
--- www.perthix.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 80.181/80.933/81.383/0.628 ms
I've got my own access card for Level 47 and 48 of Sky tower, I'm aware of exactly what it is and why we decided to buy co-location space up there.
Our connection from skytower has to go a way across town before it hits the southern cross landing station, so the best case latency across southern cross is a bit lower again.
My point earlier on was that you can get anywhere return trip in New Zealand on a fibre circuit in under 35ms. Add the 24ms to get across to Australia or the 120ms to get to San Jose and you still don't get to 180ms unless you are using ADSL2+ or cable. Our POP in Christchurch is 20ms from Skytower in Auckland.
I get 24ms between a host in our network physically in Skytower in Auckland and a host in a Vocus datacenter in Sydney.
[ ~ ]$ ping ns03.vocus.net.au
PING ns03.vocus.net.au (203.92.28.98) 56(84) bytes of data.
64 bytes from isv02.syd01.nsw.VOCUS.net.au (203.92.28.98): icmp_seq=1 ttl=55 time=24.8 ms
64 bytes from isv02.syd01.nsw.VOCUS.net.au (203.92.28.98): icmp_seq=2 ttl=55 time=24.6 ms
64 bytes from isv02.syd01.nsw.VOCUS.net.au (203.92.28.98): icmp_seq=3 ttl=55 time=24.7 ms
^C
--- ns03.vocus.net.au ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 24.698/24.761/24.872/0.150 ms
200 is totally awful! How much of that is made up by the last mile latency?
At the place I work, I would accept as a fault any report from a customer of latency of 200ms to anywhere physically in New Zealand ( aside from end customer tail latency ). Most ISP's in New Zealand peer at either WIX or APE or both and we pay extortionate rates for paid peering with Telecom and TelstraClear to handle the two exceptions to that rule.
The worst case for us is that we have an end customer in Christchurch that is talking to an end customer in Christchurch of an ISP that only peers with us in Auckland. Even that only means about 40ms worst case plus the latency of the tail circuits.
If I recall correctly ( cant remember where I read it ) Mr Dotcom had fibre from his place at Coatesville to sky tower. That is something in the order of 35km, which should be like 1 or 2ms. You would have to have a very home user grade circuit like cable or dsl to get exactly 30ms across Auckland.
If the latency figures in the article are accurate then the traffic wasn't staying in the country at all. You can get from one end of the country to the other in 35ms round trip, so even the original 30ms seems rubbish unless the circuit was DSL. The way they were making out it was a high end connection that doesn't seem likely. 180ms will easily get you too Australia and all going well will get you to San Jose from New Zealand.
Since about '93:
Slackware
Redhat
Suse
Ubuntu
Mint
What if you have run something that updates the id3 tags, album art or volume levels as I expect most people do. I ran windows media player once ( by mistake ) and I think it wanted to do this by default? Any fiddling with any of the stuff in the header is going to change the hash of the file completely. I guess they could get more sophisticated and just hash the parts of the mp3 that aren't in the header. I'm sure you could get around that by just flipping the least significant bit somewhere in each track. Seems like prosocuting based on that would be getting into voodoo territory for the cops in my country. I reckon equal odds of bringing in a psychic and presenting a 'strong feeling' the mp3's are the estranged child of some RIAA IP. In all seriousness they would just ask you where the originals are and hope that you don't have a plausible story about a house fire or burglary or something.
The range of a wireless link is determined by adding the strengths of the Access Point and Client antennas together. To state it another way, if someone puts a higher gain antenna on their laptop then they can connect to your AP from futher away. Trying to secure something by diffuse or decrease your signal strength at the AP end is a great way of feeling more secure without actually being more secure.
Or a 2 digit one that just turned up to tell everyone to get off his lawn =)
I don't know how to say it better than I did in the post you were replying to. I'll try, but perhaps you should read it again.
You can stop almost everything you don't want coming in with a non-stateful static ACL on the upstream router or something like a 3750 switch. The web server or reverse proxy or whatever you have then only has to handle traffic destined for port 80 ( and perhaps ssh from a couple of IP's ). A switch or a router can run that ACL in hardware at the line rate of the port without operating a state table at all, and it doesn't give the attacker a new easy way of taking your site out.
Theres no reason why the host can't have local firewalling too, but it is pretty well irrelevant at that point.
Well hopefully you aren't going to be consulting on anything important that gets deployed.
A stateless ACL on a switch or router that does it in a hardware path will do just fine dropping packets destined for unintended services, and it won't act as an additional attack vector.
A firewall in front of a server farm is a 'layer' that only does harm, and does not do any good.
The article writer is just a clueless journalist but the guy he is getting the technical content from knows what he is talking about. Look up the NANOG archives for Roland Dobbins if you want to read through the flame wars along these lines before. Any firewall that does stateful filtering is just another attack vector in a big web server deployment. Most firewalls can be either crashed or will start refusing new connections with only a few thousand packets per second of the right stuff. Either way your site is down and the DDOS successful when it happens. If you put in non-stateful ACL's on a router or switch that does them in a hardware path in front of your web farm to filter anything other than port 80 then you can eliminate most of the cruft at line rate without giving the attacker a nice juicy state table to destroy. Your web server has to maintain the connection state to run anyway, so why not just let it do that and have the problem distributed among all your web servers, they deal with it a heap better than any firewall.
How about putting an A or AAAA record in a reverse DNS zone, so your site ends up looking like http://2.0.192.in-addr.arpa/ or whatever. There is no registry involved with the delegation of those reverse zones, so it would be alot more difficult for anyone to interfere with it.
What will make it even more fun is if you have two branch offices of the same company connected to the different ISPs getting 172.16.32.66 and 10.0.65.88, how do you set up a VPN between them?
We have assigned 14 /8's _this year_ so far, so if you magically get all of those back, you don't even get a years delay. I guess when you say 'That's a LOT of unused IP's' the missing information is that 'We go through a LOT of IP's'.
Spend that effort and money on deploying IPv6 instead.
We use up almost 2 /8's every month.
You could go through every one of those and fight the massive legal battle to get them all back ( probably taking us well beyond the date when we are out anyway ), and you have only bought a year or two.
Save yourself the trouble and deploy IPv6, instead of making lawyers rich and then deploying IPv6.