Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror

Comment Re:It should be 8K (Score 1) 125

Your vision is better than that of the vast majority of people.

It depends on the TV size and distance from it. If a TV is small and the viewer sits far away from it, there is no difference between 1080p and 2160p. Get far enough away and there would not even be difference from 576p.

From what I have noticed from my friends (as in - normal people, not the video equivalent of an audiophile), they sit too far from the TV, no matter the TV size. If the TV is small (maybe the person does not have space for it or whatever), then they sit about 2 meters away from it - where it would take good eyes to see the difference between 576p and 1080p. If the TV is bigger, they sit even further away from it.

I have a relatively big TV (150cm diagonal) and sit about 3 meters away from it. When I connect a PC to it, I can just barely make out the standard sized text on it, but my eyes are not that great. People who visit me usually comment that the TV is too big and I sit too close to it.

Comment Re:No, we haven't normalised it. (Score 2) 96

In some ways people normalized it.

How was it in the past? You got the program, you got its manual (whether paper or a file) and then you read the manual if you cant find some function. Try to do this with apps - users would likely complain that it's inconvenient, they don't understand how to use the program and that having to read instructions is unacceptable.

Then you get shit like the constant interruptions. After all, people love being interrupted - that's why various sites have notifications and why people actually turn them on. Sometime,s when I am talking with someone IRL, his phone goes off every few minutes with the notification sound. I ask if it's a SMS or something important and the answer is no, SMS has a different sound, this is just various news sites sending news. I get annoyed by the sound even if if's not my phone and I don't spend that much time with the guy, I have no idea how he can live with it.

Some stuff may be forced on us by the employer and so on, but a lot of it people do to themselves.

Comment Re:EEVBlog explaining why this is BS (Score 1) 58

It may be BS and really inefficient, but it could also be an awesome weapon. I they manage to put up a solar power satellite that can do, say, 1GW of useful power (probably 5GW of total power), instead of beaming power to the ground-based power plant, you can also aim it to the enemy country and some spot there gets really hot...

Comment Re: NAT killed IPv6 (Score 1) 233

I guess that's the difference between theory and practice.

Yes, in theory, a NAT router will not block incoming connections without a firewall rule to do so. In practice however, for the vast majority of people and even companies (as in, everyone who gets a single public IP from their ISP), it will be the same as if the router did block incoming connections, because those incoming connections are not possible as a consequence of using RFC1918 IPs in the LAN.

After all, the argument for IPv6 is that with it you have enough addresses to not need NAT and be able to have incoming connections.

Comment Re: NAT killed IPv6 (Score 1) 233

Yes, there is an attack, but it requires very specific circumstances:
1. Be a subscriber of the same ISP.
2. Be on the same VLAN.
3. The ISP cannot have IP filtering (ip-mac-port binding or similar) and no traffic segmentation (pvlan).
It reduces the set of potential attackers from "anyone with an internet connection" to only a few people who actually have to try to do this and not merely be infected with some worm.

If you have a brand new Windows XP installation with its firewall disabled and connect it directly to the ISP (so it gets a public IP), it will get hacked within seconds or minutes. If the same Windows XP PC is behind a NAT router and has a RFC1918 IP even if the router's firewall is set to allow all, it won't be hacked at least until one of the neighbors deliberately tries to do it.

Comment Re: NAT killed IPv6 (Score 1) 233

People say "NAT protects me" but in the end the firewall protects them.

NAT protects even without the drop/reject rule, because the LAN IPs are not publicly routable or the ISP does not have a route to the LAN subnet (in most cases it's both). As such, without an explicit port forwarding rule (or something like uPnP), no incoming connections can be made to devices behind NAT.

Comment Re: NAT killed IPv6 (Score 1) 233

Yeah, it's working, just my internet connection isn't working without that rule. Apparently, my ISP does not accept packets from 10.0.0.2, it only accepts packets from the public IP it assigned my router. Weird. Maybe its because multiple subscribers may have a device with 10.0.0.2 IP and the ISP cannot distinguish which one the packets came from or something.

Comment Re: NAT killed IPv6 (Score 1) 233

Yes, the packets arrived without issue because it's an outgoing connection, so the router can forward the reply packets back to the device which originated them.
However, there is no way to initiate a connection to a device behind NAT unless there is a port forwarding rule. Without such rule, even if the firewall is set to allow everything, there is no real way to initiate a connection to a device behind NAT.

Alternatively, maybe there is an easy way to do that, in that case why do we need IPv6 at all? IPv4 and NAT works just as well, right?

Comment Re: NAT killed IPv6 (Score 1) 233

How does the router know not to work before you've even added the masquerade rule?

Because my LAN uses RFC1918 IPs, which are not routable over the internet. You cannot connect to 10.0.0.2 on my LAN.
Similarly, without the masquerade/snat rule the router passes an outgoing packet with source IP 10.0.0.2, which then gets dropped by the ISP because the ISP has IP filtering or, if the ISP allows the outgoing packet, a reply packet will not come.

So, let's say I have a typical home internet connection. My router gets a public IP and my LAN is one of the RFC1918 subnets. My ISP does not have a static route to my LAN.

With just ip.forward enabled and no iptables rules (allow all), in theory my LAN would be accessible from outside, but for that the ISP would have to have a route to my LAN and even then, my LAN would only be accessible from my ISP, not the rest of the internet.
A subscriber to my ISP could add a static route to his router to access my LAN, but for that he would need to be on the same VLAN as me and the ISP has to not have IP filtering or something similar implemented.

Comment Re: NAT killed IPv6 (Score 1) 233

It's not that difficult to forget it when writing the rules.

On a default Debian installation, iptables are set to allow everything. So, I enable ip.forward and immediately my router starts forwarding everything without me explicitly setting iptables -P FORWARD DROP or adding a drop rule.

With NAT (does not matter, v4 or v6). I enable ip.forward, nothing works. I then add the masquerade rule, now outgoing connections work and incoming ones are dropped (excluding the case mentioned in my previous post), even with -P FORWARD ACCEPT.

To make a non-nat router/firewall pass all packets, I just need to forget/remove the drop all rule.
To make a nat router/firewall pass all packets, I need to explicitly add a NAT rule and even then packets would be forwarded to only one internal host.

Comment Re: NAT killed IPv6 (Score 1) 233

So, how will you or some hacker be able to access 10.0.0.2 on my LAN from outside without me adding a specific rule to forward some port to it?

If a packet comes to my external IP and there is no NAT rule matching it (and no service runs on that port on the router) the router will just discard or reject it, because it does not know where to forward that packet.

Comment Re: NAT killed IPv6 (Score 1) 233

Yes, -P ACCEPT and then the masquerade rule.

How does that allow anyone from other countries to connect to 10.0.0.2 on my network?

I am not saying this is perfect and I would rather ad a rule that allows outgoing connections and drops incoming, but even without those rules, just the fact that my LAN is on a RFC1918 subnet would make it pretty difficult to access anything inside.
The only way to do it probably is:
1. be a subscriber of my ISP
2. be on the same VLAN as me
3. the ISP to not have IP filtering on switches and no traffic segmentation (pvlan).
4. route add -net 10.0.0.0/24 gw my_wan_ip
Now you would be able to access my LAN.
This reduces the set of potential attackers from "anyone anywhere, including automated systems" to "depending on the ISP some of my neighbors who know how to do this or got hacked and the hacker is deliberately trying to attack me or the ISP employees".

As I said, not perfect (it would be much better to have actual firewall rules), but much better than my LAN having publicly routeable IPs and forgetting the "drop all" rule on the end.

Slashdot Top Deals

((lambda (foo) (bar foo)) (baz))

Working...