Since there's too much horizontal space anyway on those widescreen displays, why not use it for wider menus? As an added bonus, you can fir more top-level menu items in them, so you don't need deeply nested menus even for many options.
An A(n+1) page is what you get if you cut an An page in halves.
If additionally I tell you that all An pages have the same shape, and an A0 page has an area of 1 square meter, you now can calculate what A4 looks like.
But a bot cannot send spam over port 80 or 443. The only malicious action I can imagine which can be done over those ports is DDoS attacks (but if the provider also reduces the bandwidth of compromised hosts, the impact is at least reduced (and the user is much more likely to notice something went wrong), or to infect web servers (but maybe at least for port 80 a proxy can filter out certain types of attacks, e.g. by blocking everything which looks like SQL injection).
Well, that one would be simple: Have port 25 blocked by default, but have a way to enable it (protected by both password and captcha, so a bot cannot automatically enable it). That way, if you don't want to run a mail server (and especially if you have no idea about mail servers), your computer cannot be misused to send spam, and if you want to run a mail server, all you have to do is to go to the web interface and enable the port. The same could be done for other rarely used ports. Basically it would be an user-controlled firewall at the provider's end of the line, preconfigured for typical user behaviour.
pass in on $ext_if inet proto tcp from any to ($ext_if) \
port $tcp_services flags S/SA keep state pass in on $ext_if inet proto tcp from any to $comp3 port 80 \
flags S/SA synproxy state
The only thing you can know for sure (more or less), is the traffic statistics on *your* site, which, to the developer, should be pretty much the only ones that matter.
But your own site's statistics may be biased as well: For example, if you have an IE only page, that fact by itself will make IE the dominant browser on your page. However that doesn't tell you about the statistics you would get if your site would not be IE only. You cannot distinguish between hits you don't get because the user isn't interested in your site, and hits you don't get because the user can't access your site (or because your site looks ugly in his browser).
Well, the point is that GUIs have a better initial learning curve. Therefore with such a GUI, you could get the first steps quickly, and then study the generated scripts to learn how to do it on the command line, so you have the full power. Your scripts writing scripts also require that you already know the CLI. The point of the GUI with script output is that you could use the discoverability of the GUI to learn the CLI.
I think it basically acts as NAT router: It makes your browser send the encrypted data to GoogleSharing, then GoogleSharing just replaces the IP addresses so that the destination is Google and the source is GoogleSharing. For the return packets the IP addresses are changed the other way, so you get the packet back from GoogleSharing. All other functionality (like not sending any information from your cookies or manipulating User Agent) can be implemented locally at your browser by the extension.
Disclaimer: I didn't read the code (nor did I see any good description on the page), so this is basically how I think it works. Maybe I'm completely wrong (but I cannot think of another way how it could work).
OTOH, I'd say if there's an important security setting, and it's not set to the secure value by default (or, if that is not possible, gives an error when not set explicitly), that's a design error in the application. Also, empty configuration files IME are rare nowadays; usually they are pre-filled with (mostly commented-out) example-settings with explanations in comments. Which often allows you to just uncomment the settings you want, instead of writing the complete command by hand.
BTW, comments are another advantage of config files vs. GUIs. Not only because you can state the reason why you put a certain setting right at the setting itself, but also because when you change a setting you can just comment out the previous setting, and therefore easily undo whatever you changed (another option for that is, of course, to make a backup copy of the original config file). I don't see how you can do that with a GUI.
GUI's are better for reporting and displaying information
In my experience, GUIs tend to display less information (probably to not "confuse" users). But from the basic ability to provide useful information, I don't see why one should have an advantage over the other. After all, the information is just text; if that text is shown on the console or in a window with "OK" button doesn't matter. What does matter is whether the text is informative (e.g. "foo.cfg: file not found") or uninformative (e.g. "unable to change configuration" as only error message).
What would be nice is if the GUI could automatically create a shell script doing the change. That way you could (a) learn about how to do it per CLI by looking at the generated shell script, and (b) apply the generated shell script (after proper inspection, of course) to other computers.
Slashdot Mirror
And most web pages are completely uninteresting. Therefore I conclude people use the web mostly to look at uninteresting pages.
Make it appear when pressing Alt?
If your monitor dies, how are you supposed to view the web site to order a new one?
Since there's too much horizontal space anyway on those widescreen displays, why not use it for wider menus? As an added bonus, you can fir more top-level menu items in them, so you don't need deeply nested menus even for many options.
Well, 1920x1080 would be an up from my current 1280x1024.
An A(n+1) page is what you get if you cut an An page in halves.
If additionally I tell you that all An pages have the same shape, and an A0 page has an area of 1 square meter, you now can calculate what A4 looks like.
You hold the laptop with the left hand and type with the right hand.
Didn't they tell you to use both uppercase and lowercase letters? Had you used "Passw0rd" instead, nobody would have found out!
So you propose that as soon as an ISP detects an infected computer, they send someone to wipe the computer and install Ubuntu? :-)
But a bot cannot send spam over port 80 or 443. The only malicious action I can imagine which can be done over those ports is DDoS attacks (but if the provider also reduces the bandwidth of compromised hosts, the impact is at least reduced (and the user is much more likely to notice something went wrong), or to infect web servers (but maybe at least for port 80 a proxy can filter out certain types of attacks, e.g. by blocking everything which looks like SQL injection).
Well, that one would be simple: Have port 25 blocked by default, but have a way to enable it (protected by both password and captcha, so a bot cannot automatically enable it). That way, if you don't want to run a mail server (and especially if you have no idea about mail servers), your computer cannot be misused to send spam, and if you want to run a mail server, all you have to do is to go to the web interface and enable the port. The same could be done for other rarely used ports. Basically it would be an user-controlled firewall at the provider's end of the line, preconfigured for typical user behaviour.
pf example:
pass in on $ext_if inet proto tcp from any to ($ext_if) \
port $tcp_services flags S/SA keep state
pass in on $ext_if inet proto tcp from any to $comp3 port 80 \
flags S/SA synproxy state
iptables example:
iptables -A INPUT -i $ext_if -p tcp --dport $tcp_services --syn -j ACCEPT
iptables -A FORWARD -i $ext_if -p tcp -d $comp3 --dport 80 --syn -j ACCEPT
Personally I find the pf format much easier to read/remember/use/debug.
Read into it you will find out it is pretty neat.
With proper line breaks, your post also becomes readable :-)
But your own site's statistics may be biased as well: For example, if you have an IE only page, that fact by itself will make IE the dominant browser on your page. However that doesn't tell you about the statistics you would get if your site would not be IE only. You cannot distinguish between hits you don't get because the user isn't interested in your site, and hits you don't get because the user can't access your site (or because your site looks ugly in his browser).
In Germany, IE dropped below 25%.
And the open VoIP protocols don't?
Well future generations will just be genetically engineered to have the polarization filters right in their eyes.
Well, the point is that GUIs have a better initial learning curve. Therefore with such a GUI, you could get the first steps quickly, and then study the generated scripts to learn how to do it on the command line, so you have the full power. Your scripts writing scripts also require that you already know the CLI. The point of the GUI with script output is that you could use the discoverability of the GUI to learn the CLI.
Google is your god? :-)
Well, you also have to trust the Firefox extension (or read and understand the code, and trust your ability to find issues if there are any).
Not if you block JavaScript.
Except in the browser extension, I guess ...
I think it basically acts as NAT router: It makes your browser send the encrypted data to GoogleSharing, then GoogleSharing just replaces the IP addresses so that the destination is Google and the source is GoogleSharing. For the return packets the IP addresses are changed the other way, so you get the packet back from GoogleSharing. All other functionality (like not sending any information from your cookies or manipulating User Agent) can be implemented locally at your browser by the extension.
Disclaimer: I didn't read the code (nor did I see any good description on the page), so this is basically how I think it works. Maybe I'm completely wrong (but I cannot think of another way how it could work).
OTOH, I'd say if there's an important security setting, and it's not set to the secure value by default (or, if that is not possible, gives an error when not set explicitly), that's a design error in the application.
Also, empty configuration files IME are rare nowadays; usually they are pre-filled with (mostly commented-out) example-settings with explanations in comments. Which often allows you to just uncomment the settings you want, instead of writing the complete command by hand.
BTW, comments are another advantage of config files vs. GUIs. Not only because you can state the reason why you put a certain setting right at the setting itself, but also because when you change a setting you can just comment out the previous setting, and therefore easily undo whatever you changed (another option for that is, of course, to make a backup copy of the original config file). I don't see how you can do that with a GUI.
In my experience, GUIs tend to display less information (probably to not "confuse" users). But from the basic ability to provide useful information, I don't see why one should have an advantage over the other. After all, the information is just text; if that text is shown on the console or in a window with "OK" button doesn't matter. What does matter is whether the text is informative (e.g. "foo.cfg: file not found") or uninformative (e.g. "unable to change configuration" as only error message).
What would be nice is if the GUI could automatically create a shell script doing the change. That way you could (a) learn about how to do it per CLI by looking at the generated shell script, and (b) apply the generated shell script (after proper inspection, of course) to other computers.