Comment Re:Free Software (Score 1) 161
Quite the opposite. In the last few years, Firefox has worked harder on reducing memory use and improving performance than anyone, and it shows.
Quite the opposite. In the last few years, Firefox has worked harder on reducing memory use and improving performance than anyone, and it shows.
That's true of all browsers. Firefox uses less RAM than any other browser, with an equal number of tabs open, on any platform I've seen numbers for.
A lot of us benefit from Free Software. Android is primarily developed by Google, so it has a steady source of funding. GNU/Linux has a large community of volunteers, but is honestly developed primarily by businesses that get revenue from server support contracts (Red Hat, Intel, SuSE, IBM, Google, to name a few).
Firefox is, by a host of measures, the best browser available. If I'm reading arewefastyet properly, it's the browser with the fastest Javascript engine now. The last time I checked, it's the smallest download. It uses the least RAM. It starts fastest. It supports plugins on all platforms, including mobile.
The browser is key to practically every Internet service, and they all really should be contributing to the development of the one browser that's fully Free Software. Sadly, unlike Android and GNU/Linux, Firefox is essentially ad-supported. It's a bad situation for us, the users.
you have to reboot the server to get the changes to take effect.
No, you don't. glibc still uses
Just type "ifdown eth0 && ifup eth0" in a shell (as root). When you hit enter, the entire command is sent to the server at once, and the 2nd one is executed if the first one succeeds. The first command will kill your ssh link if it succeeds, but the second one still executes even after you've been disconnected, bringing the link back up.
That's actually not correct. If the ssh session is terminated, the shell will cease executing the command line it has. To be specific, it will receive SIGPIPE (IIRC) and exit.
You should use screen, or tmux, or nohup for this sort of thing.
Back in the good old days. We had a data format that was in essence a memory dump of the system
You mean
Chrome still has the technology edge in several cases
Some, maybe. It's getting harder to name them. Firefox is a smaller download, uses less RAM, starts faster, and (if arewefastyet is to be believed) has a faster JavaScript engine now. And the mobile version supports plugins. And I can run my own sync server if I want to.
It happens about 40 times a day on you average PC
No, it doesn't. I operate lots of machines with ECC RAM. I've seen ECC correction. Bits flip, but nowhere near that frequently. It's very rare.
The original advisory notes that "Since Drupal uses PDO, multi-queries are allowed." I can find documentation that confirms that's true of the MySQL PDO adapter. Is that also true for PDO for other databases, or is this vulnerability specific to MySQL?
Having it on WiFi whenever possible. In good implementations on modern phones it uses less power than the cell network.
Interesting note: that's not always the case. If you're on a network with a lot of broadcast traffic, WiFi will keep the phone from entering deep sleep, and your battery life will be terrible. It took me quite a while to figure out that my battery life's turn for the worse coincided with starting a new job, where the WiFi network is really big.
If you haven't used iostat before: Run "iostat -x 2" to get a report of block device utilization every two seconds. Ignore the first report; it details utilization since system boot. All subsequent reports will be for the period after the previous report.
If you can repeat your earlier tests, and want to see if there's actually a Linux bug, compare numbers when the program opens DBs before forking, and when it opens them after. If you're seeing bad latency in the former case, but similar B/s, that might indicate a bug. If you're seeing much higher %system (CPU), that might be a bug. Maybe. Otherwise, it's probably an indication that the program behaves differently in those cases, which is not a Linux bug.
so it's not the *actual* loadavg that is relevant but that the *relative* loadavg before and after that one simple change was so dramatically shifted from "completely unusable and in no way deployable in a live production environment" to a "this might actually fly, jim" level.
That's not loadavg, that's IO latency. You should probably be using iostat to get useful numbers.
loadavg is completely useless when discussing system performance, it is in no way related.
I'll start with: LMDB is awesome, and I am super SUPER impressed with OpenLDAP's benchmarks over the last several years. I do not question LMDB's worth.
I'm just not really sure that this letter is evidence thereof. The author got poor performance from a SQL database with no indexing, which degraded as the number of records grew? You don't say! A database that has to do a full scan for reads performs poorly?
Surprise about load average seems equally naive. If you fork a bunch of processes that are doing IO, of COURSE the load increases. Load is a measure of the number of processes not sleeping. That's all it is. I don't understand his surprise that a system steadily doing a great deal of IO would show a lot of time spent in IO calls in profiling.
Reading that letter made me cringe. It didn't help that it sounds like another NSA project.
In the other case the other person can't access Internet as he wants due to actively being suppressed by the first user.
I can't actually tell if that sentence describes the person using BitTorrent, or the person using BitHammer.
Tor is ineffective if Javascript is enabled
I don't know what you're talking about. Tor's FAQ notes that they leave Javascript enabled by default.
Ya'll hear about the geometer who went to the beach to catch some rays and became a tangent ?
