I guess you never have a user ssh in (via keys) and run a script, like to deploy an application:
.... NOPASSWD:/sbin/service app start,/sbin/service app stop
APK: the application sounds like it does a great job of fetching the data, but it seems much more useful to stick that data inside a DNS proxy or recursive resolver. Even if the resources required to run it are prohibitive for a crappy wifi router, it could be run on a box on the local network, and the crappy router uses it as its DNS resolver.
Then when I manage my home network of varying devices (tablets, phones, mixed OS laptops & desktops, even visitors) they will all get the benefit of DNS-level filtering.
I would manage a corporate network in a similar way. During DHCP when they get some local DNS resolvers, or hard-coded, the 1-3 local resolvers do all the DNS filtering for the entire network. A unified web UI on the master DNS resolver could micro-manage the rules if necessary (unblock something, add a manual block, local dns resolution, etc).
The problems with.biz and certainly.info were massive price reductions by the registry operators. They made the registration of domains so cheap it was impossible to resist by scammers. The more expensive a domain, the less scams/spam there is from the TLD overall.
Signing doesn't affect the distributed problem. If you want.DNS and I want.DNS, we can both sign our own TLDs with different keys and we're in the same situation.
I suppose if you get your key signed by 1000 of your friends, and mine is only signed by 5, then yours becomes more popular. Until your 999th friend sends spam from your domain, and now everyone starts signing my key and it becomes more authoritative.
Even in a block chain type system, domains or TLDs would be awarded first come, first served (like today with the hierarchical system) and then transferred from one party to another (like today).
The only difference would be the cost. Should it be inverted? The first TLD on the DNS block chain would be very, very expensive, but the last million would be inconsequential.
Google has had years to implement user-chosen permissions revocation. Even hidden in Developer Tools under Settings would have at least given app developers the chance to test their apps against losing permissions.
Google's motives for removing fine-grained permission are all speculative at this point. Some argue that Google removed permission control because they don't want a user backlash against "broken apps" and don't want to slow down their marketshare growth.
I would counter that argument with those developers should get flooded with broken app messages so they can re-design their apps to still function or quit altogether if a given permission was not available to it. E.g. The shady Dictionary App should still work if geo-location fails (which it does if you've disallowed location for all apps in the global settings).
This path the FSF has taken to "create" a FLOSS system is not a bad one.
Instead of needing to manufacture a new laptop, simply "refurbish" an existing model and gauge your target market.
If the demand grows, newer models may be refurbished until it's economically viable to manufacture some.
I believe the "truly free" system here is just a model of what the FSF would like to see available in the market and not an actual business plan to compete in the marketplace to sell computers.
Isn't water vapor attributed to solar energy orders of magnitude more mass than water vapor output by combustion of fossil fuel?
The state of Florida is pretty damn humid, and I don't think it's from all the golf carts.
I don't dispute that water vapor is indeed a greenhouse gas which holds a lot of heat, but it seems like it's mostly created by the sun, or perhaps a city full of air conditioners (which act as condensers).
If she is using NoScript in a "medium" security manner -- meaning temporarily trust the parent domain of the site, but only whitelist external scripts (which means a fair amount of clicking "Temp allow akami / googleapis / disqus / some-image-service / etc") then that is MUCH better than Chome. Even NoScript in a "low" security method that temp-allows all scripts on a page but still blocks XSS, ClearClick, and anything else you choose like Java applets and iframes is still better than allowing all javascript and all plugins.
On the privacy front, try BetterPrivacy (never touch it after first time config) to flush all local Flash storage on browser start+stop. (You can of course whitelist LSOs from your bank or whatever.) Additionally, try CookieMonster in whitelist-only mode. It's just like NoScript, but for cookies so you can permanently allow all the sites she logs into, and temp allow any random page with a form.
Even just trying some extra plugins or stronger security settings will help everyone think more about security as they're learning more about security.
Slashdot Mirror
That's amazing you survived with the phone in your pocket!
Two years from now? I bet the ratio will be higher. They also learned about databases. I don't think not learning PHP is a "loss".
Or you could get an Aero Press
I guess you never have a user ssh in (via keys) and run a script, like to deploy an application:
.... NOPASSWD: /sbin/service app start, /sbin/service app stop
/sbin/service app stop /sbin/service app start
#! script:
# backup deployed app...
sudo
# deploy app...
sudo
# return whatever
What "value" did Jar Jar add?
APK: the application sounds like it does a great job of fetching the data, but it seems much more useful to stick that data inside a DNS proxy or recursive resolver. Even if the resources required to run it are prohibitive for a crappy wifi router, it could be run on a box on the local network, and the crappy router uses it as its DNS resolver.
Then when I manage my home network of varying devices (tablets, phones, mixed OS laptops & desktops, even visitors) they will all get the benefit of DNS-level filtering.
I would manage a corporate network in a similar way. During DHCP when they get some local DNS resolvers, or hard-coded, the 1-3 local resolvers do all the DNS filtering for the entire network. A unified web UI on the master DNS resolver could micro-manage the rules if necessary (unblock something, add a manual block, local dns resolution, etc).
Only 3 letter strings and longer were allowed.
Multiple applicants applied for .dot
Google: https://gtldresult.icann.org/a...
Dish: https://gtldresult.icann.org/a...
The problems with .biz and certainly .info were massive price reductions by the registry operators. They made the registration of domains so cheap it was impossible to resist by scammers. The more expensive a domain, the less scams/spam there is from the TLD overall.
Technically it was the US Dept of Commerce that didn't want .XXX (those free speech haters!)
Signing doesn't affect the distributed problem. If you want .DNS and I want .DNS, we can both sign our own TLDs with different keys and we're in the same situation.
I suppose if you get your key signed by 1000 of your friends, and mine is only signed by 5, then yours becomes more popular. Until your 999th friend sends spam from your domain, and now everyone starts signing my key and it becomes more authoritative.
Even in a block chain type system, domains or TLDs would be awarded first come, first served (like today with the hierarchical system) and then transferred from one party to another (like today).
The only difference would be the cost. Should it be inverted? The first TLD on the DNS block chain would be very, very expensive, but the last million would be inconsequential.
You should really run your own set of alternate root servers.
Then we can all just point our routers or /etc/resolv.conf to your servers, and gain all your expertise without managing shit ourselves.
And it was fair in the early days of the Internet, BEFORE you actually had to "register" a domain name.
Back then, DNS was a giant hosts file (queue APK) where one dude updated it and most people replicated it.
They chose to isolate countries based on the 2 character ISO code, and it stuck.
This app has been available since Android 2.1 or earlier, and needs root access of course:
http://www.appbrain.com/app/pe...
Google has had years to implement user-chosen permissions revocation. Even hidden in Developer Tools under Settings would have at least given app developers the chance to test their apps against losing permissions.
Google's motives for removing fine-grained permission are all speculative at this point. Some argue that Google removed permission control because they don't want a user backlash against "broken apps" and don't want to slow down their marketshare growth.
I would counter that argument with those developers should get flooded with broken app messages so they can re-design their apps to still function or quit altogether if a given permission was not available to it. E.g. The shady Dictionary App should still work if geo-location fails (which it does if you've disallowed location for all apps in the global settings).
Sad there is no linux support, even though they are powered by open source (and custom source).
I always thought the advertiser was the customer, and everyone else was the user regardless of content.
The /palm or palm pilot site was the best. (I actually read it on my palm III)
But it's nice to think about large or maximum limits of any system.
Do you drive around with your cellphone battery in? If so, you're GPS tracking yourself.
This path the FSF has taken to "create" a FLOSS system is not a bad one.
Instead of needing to manufacture a new laptop, simply "refurbish" an existing model and gauge your target market.
If the demand grows, newer models may be refurbished until it's economically viable to manufacture some.
I believe the "truly free" system here is just a model of what the FSF would like to see available in the market and not an actual business plan to compete in the marketplace to sell computers.
Do you 'set -o vi' on the command line? Emacs style keystrokes (set -o emacs) rock in Bash.
Try: M-b and M-F to move by word. (alt+b, alt+f, alt+backspace = M-^H for other readers)
Isn't water vapor attributed to solar energy orders of magnitude more mass than water vapor output by combustion of fossil fuel?
The state of Florida is pretty damn humid, and I don't think it's from all the golf carts.
I don't dispute that water vapor is indeed a greenhouse gas which holds a lot of heat, but it seems like it's mostly created by the sun, or perhaps a city full of air conditioners (which act as condensers).
If she is using NoScript in a "medium" security manner -- meaning temporarily trust the parent domain of the site, but only whitelist external scripts (which means a fair amount of clicking "Temp allow akami / googleapis / disqus / some-image-service / etc") then that is MUCH better than Chome. Even NoScript in a "low" security method that temp-allows all scripts on a page but still blocks XSS, ClearClick, and anything else you choose like Java applets and iframes is still better than allowing all javascript and all plugins.
On the privacy front, try BetterPrivacy (never touch it after first time config) to flush all local Flash storage on browser start+stop. (You can of course whitelist LSOs from your bank or whatever.) Additionally, try CookieMonster in whitelist-only mode. It's just like NoScript, but for cookies so you can permanently allow all the sites she logs into, and temp allow any random page with a form.
Even just trying some extra plugins or stronger security settings will help everyone think more about security as they're learning more about security.
Thank you for the very informative reply!