Those numbers are with hardware decoding, aren't they. I'd be more intrested in something compute-intensive that was compiled to asm.js. I bet they'll last much less.
That said, these are machines with mobile processors and an OS that is tailored for mobiles. It isn't all that suprising that they are more capable than their normal counterparts.
I always thought Tor hidden services make a great way to host your own cloud. Not only can you host on your own hardware without messing with dns, isp reps, and router settings, but you get privacy features for free.
IMO, I think local hosting is the primary usecase the Tor project should be advertizing.
Hidden services are not a primary concern of the Tor Project, or a primary use of the Tor network. They are a novel way of using a system designed for anonymous and censorship-resistant communications.
or check the variable before using it, like any other programming language:
[[ "$VAR" ]] && rm -rf "$VAR/*"
I think most of these issues stem from the fact that most developers that write shell scripts don't actually understand what they're doing, treating the script as a necessary annoyance rather than a component of the software.
If anyone understands shell scripts, it would be people writing init scripts at Red Hat :)
Anyways, that is not anything like other programming languages. Checking in that way is error prone and not really an improvement (nor equivalent to set -o).
[[ "$DAEMON_PATH" ]] && rm -rf "$DEAMON_PATH/*"
See what I did there? It's an rm -rf /* bug because "checking variables" is not the answer.
In other programming languages, if an identifier is mis-typed things will blow up. E.g., in ruby if I write:
daemon_path=1; if daemon_path; puts deamon_path; end
I get "NameError: undefined local variable or method `deamon_path`"
These issues do not always stem from bad developers. Bash's defaults are not safe in many ways and saying "people should just check the variable" isn't helpful here.
Shameless plug for my language "bish" (compiles to bash) which aims to solve many of these annoyances with shell scripting: https://github.com/tdenniston/bish
Bash has the ability to also flag use of an undefined variable an error, it is just not on by default.
set -u
Man page quote: "Treat unset variables and parameters other than the special parameters "@" and "*" as an error when performing parameter expansion. If expansion is attempted on an unset variable or parameter, the shell prints an error message, and, if not interactive, exits with a non-zero status."
Yeah, everyone always loves to shit on BAT (which is fair, it is terrible) and VBS (which is slightly less fair) but inspite of how many problems Bash has (least of all the massive security issue last year), it gets off almost scot free.
These bugs are indicative of Bash's design problems. Why is it used for init scripts? And don't even get me started on how Bash interprets filenames as part of the arguments list when using * (e.g. file named "-rf").
Say what you will about Powershell, but having a typed language that can throw a null exception is useful for bugs like these. The filename isn't relevant, and a null name on a delete won't try to clear out of the OS (just throw).
Not just scot free - during the Great systemd War of 2014 is was a talking point for the antis that using anything other than the pure, reliable simplicity of shell for service management was MADNESS!
I don't think that was the argument, as much as it was that if a shell script fouled up it was easier to get in and do field repairs because it was interpreted rather than compiled.
But sandboxing does nothing to protect information if the information resides in the sandbox (sandboxing wouldn't have stopped heartbleed).
Rust and friends would aren't going to make all securty issues go away, just as sandboxing would not. There is no one true silver bullet in securty, at least not yet.
The issue here is not GP's browsing experience. It's the fact that they failed to address such an elementry UX usecase that should not have occured in the first place; eithrr degrade gracefully or use a noscript tag. This failure is unacceptable if they are the same folks who are working on the web browser, seeing that its UVP is mostly UX.
That said, these are machines with mobile processors and an OS that is tailored for mobiles. It isn't all that suprising that they are more capable than their normal counterparts.