we're cutting funding for satellites that warn us about very real weather threats.
Maybe that's what the GOP doesn't like? These satellites keep collecting that pesky data on global warming. Obviously, their reasoning might go, if the satellites are collecting data that's FALSE and LIES that interferes with the operation of the free market, they don't need to be funded with our* tax dollars.
*our meaning the folks who pay taxes, not the big energy companies, they don't pay taxes because if they did they wouldn't be able to continue creating jobs.
Except that 'die' also happens to be German for 'the', so either a) it'll be a huge fight over who gets the name or b) ICANN will disallow registering it because it's a common word. The money, quite literally, is on ICANN giving it to whoever has the most deutschmarks.
At its simplest, the build vs. buy decision is about competitive advantage. If a company needs some commodity IT service or function, it should buy the "good enough" product. If the company is looking to support and enhance whatever it is that company does that makes it unique and better than its competitors, build it in-house and get exactly the right thing.
Most of what "the cloud" does is commodity functions.
Like a lot of open source software, it's like a lot of other open source software that attempts to do pretty much the same thing, but in a different way and with different bugs and missing features. The solution, of course, to this mess of half-finished, buggy, and abandoned OSS with horrid UIs is easy. Start another project to do the same thing, only this time, we'll do it right. It'll be feature-complete quickly and free of serious bugs because all those other developers working on similar software will immediately see how superior we are and join us.
Maybe. I wouldn't assert that, for example, reading in a large decoded & uncompressed bitmap from disk is faster than re-running the decode from an in-memory copy of the original jpeg.
240MB is a problem for you? How much ram do you have, 512MB? OK, you're a bit behind the times -- no worries, you have the right to that. But when systems are shipping with 8GB and 4 cores running over 3Ghz, the choices the FF team has made for user experience over memory usage make more sense.
FF does not leak memory -- not in the strictest since -- as bad as most programs of its size and complexity.
What it *does* do is hold onto memory it thinks it might need in the future, to reload/re-render something the user looked at recently.
Of course, explaining to the average user the difference between the technical definition of a leak and simply holding on to useable (but reachable and potentially free-able) memory more aggressively than needed is a pointless exercise. Non-technical users don't care why they are low on memory, they just see that their 100 tabs and 55 running programs all slow down.
Up to now users of FF have demanded a snappy user experience with instant response time for most interactions. The natural tradeoff to achieve that is to use and hold more memory.
For whatever reason -- be it an increase in use of low-end hardware or perception that of all the memory-sucking applications a user want, the browser should not be one of them -- people have shifted towards feeling that FF is a memory hog. When you have 8GB or RAM and a multi-core CPU, FF doesn't really look terrible. When users decide that 2GB and 2Ghz is plenty, then FF looks bad.
I'm glad that the mozilla team has decided to revisit some of the assumptions about performance vs. memory use that have driven development over the past years, but the idea that closing a page should free memory wasn't high on the wish list of most users, who really preferred to see their web pages, bloated with javascript, ads, and and widgets served up by the typical site, load and render quickly.
I'm typing this on a 1.8GHz Sempron with 1.5Gb of RAM that I use as a nettop
Ignore the rest of your comment, I'll point out that, for better or worse, Firefox has for a long time been pushed for more features/faster rendering/snappier user experience and they've made what is the standard trade-off in programming: used more RAM. Firefox is now at the point where users with 4GB or more who don't really fret at a program using 700MB are happy at the responsiveness.
Is that the right tradeoff though? Is it right to target the higher end systems and ignore the 1-2GB single core CPUs 2Ghz?
For a while, it made sense to push the high end performance, but now there's been some rethinking. The majority of users seem to have discovered that for *most* of what they do, 2GB and 2Ghz is fine. Firefox is losing in that arena, and now some folks want to address that.
Changing the mindset of the FF team is the most important aspect of this project, but also the most difficult.
Yeah, when the hardware is defective by design, the filesystem does get screwed up. It's up to the fs developers to account for this and provide tools to recover. Failure to do so and instead blaming the hardware or the sysadmin for using flawed hardware is not an acceptable stance.
The emails are probably all stored in an Exchage server somewhere. Any experts on that system want to chime in on the actual difficulty of extracting tens of thousands of individual messages, what format they'll end up in, how big the resulting dump would be?
I know as slashdotter we all keep our email in plain text format and can easily bzip -9 the whole thing down to a few hundred K, but you know Palin's email probably contains a bunch of PP presentations and other huge files.
While I agree with your position that the hardware is flawed and possibly defective by design, I disagree that this absolves the Fedora and btrfs developers from having to do anything.
The old saw "Be strict in what you send, but generous in what you accept" applies here. Because there *is* a way that the filesystem can recover -- though admittedly with some difficulty -- from a hardware fault like this. Other filesystems offer tools to deal with such hardware.
By making it the default fs, Fedora is putting the sysadmins in the difficult position of trying to determine if the hardware they have is flawed or choosing a different fs at install time anyway. Because it's virtually impossible to know if the hardware doesn't properly implement what the manufacturer claims it does, a prudent sysadmin MUST choose a different filesystem.
Granted, this is Fedora, the distribution aimed at folks who are maybe willing to be less prudent and accept some risk. Perhaps the leverage of Fedora users asking for it along with the large body of "in the wild" testing will give btrfs developers the kick needed to close this gap.
It says right here on the btrfs wiki: "While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably if your machine crashes or loses power on disks that don't handle flush requests correctly. This will be fixed when the fsck tool is ready. "
So I'd say yah, that's a pretty important piece to be missing if you're talking about making it the default for a distro, even one as free-wheeling as Fedor.
An algorithm is of mild interest, yet Van Gogh's Starry Night, a landscape, is far more interesting than his Starry Night Over the Rhone, a painting that includes a man and a woman walking arm-in-arm by the river.
I almost went to work for Ken, back around 1996. During the talks, I got set up with a free account. I had it for YEARS before someone (a while after they sold it to PrismNet) went through the old accounts and such. They found me, asked me if I wanted to become a paying customer, and I figured, what the heck, shell access, short email address, web hosting, cheap.
I had that account until December of 2010, when I decided I'd migrated all the folks that mattered to my newer email address and I wasn't getting anything but spam at the io.com address.
I wonder who is going to get the domain now, and how much they are coughing up for it.
Mac Defender just proves that Apple has finally broken the Microsoft Windows monopoly on the desktops of the sort mouth-breathing idiot who can be socially engineered into incredibly stupid actions.
You're correct, Ares V was never intended to be a launcher for humans, but the changes to the RS-68 were still substantial, and there were discussions within NASA to man-rate the engine as part of the changes anyway. I also wonder how many changes would be required in the first stage core -- essentially a shuttle ET -- to work with the RS-68 vs. the SSME.
It was OK, except it still ended up in the same obscenely expensive cost model for development that has plagued almost everything that involves continuing to work with the current batch of contractors -- Lockheed Martin and ATK (formerly Morton-Thiokol).
Another downside was the use of SSMEs -- an throwing them away every flight. Yes, there were proposals to replace them with modified RS-68 engines, but the redesign and NASA requirements for human-rating them (said requirements can be argued about, but that's another topic) would have raised the cost yet more.
NASA announced Tuesday that they will continue to blow wads of cash on a failed design for a spacecraft.
The Orion capsule, now dubbed "MPCV", in development since 2005 but not even ready for first launch, will continue to suck up money that could go to efforts that have a chance of producing something tangible well before 2015.
The bloated, overweight, and complicated capsule that has already made $5 billion disappear into a black hole will continue as a contract to fill prime contractor Lockheed Martin's coffers.
Amusingly, the PR materials show the as-yet-nothing-but-a-ground-test-article spacecraft in Mars orbit, even though it only has a 21-day mission span.
Good analysis of how they would probably foil the backtrace. As far as caving when there are warrants, I was thinking of a hosting company off in a small island country that doesn't put a lot of effort into complying with international law enforcement efforts. I don't know of such places, but I'm sure they must exist.
Considering how Amazon has become known for caving to the slightest pressure from law enforcement or even just a nosy senator, to host such an attack from EC2 seems extraordinarily stupid.
It would make much more sense to launch it from somewhere hosted by a company that doesn't have a reputation for giving up their customer's data and shutting down even legitimate stuff that happens to run afoul of their vague guidelines.
Still no official support for 64-bit platforms. That Nov 2010 release of 'Square' is the only thing that works on my Firefox 4 64-bit build with Snow Leopard.
PGO: Profile-Guided Optimization. A FF PGO build will compile an executable with with profiling on, the run that executable using an automated script that drives the browser through a suite of tests that is intended to mimic typical usage. The results of this profiling are written to a file and then a second, optimized build is done using the profiling results as a guide for the optimizer to generate better code for the hotspots.
I've been doing it with FF4 on my Mac with Snow Leopard for some time. It does make for longish build times, though.
Slashdot Mirror
Maybe that's what the GOP doesn't like? These satellites keep collecting that pesky data on global warming. Obviously, their reasoning might go, if the satellites are collecting data that's FALSE and LIES that interferes with the operation of the free market, they don't need to be funded with our* tax dollars.
*our meaning the folks who pay taxes, not the big energy companies, they don't pay taxes because if they did they wouldn't be able to continue creating jobs.
Madness? This is brand marketing and advertising we're talking about.
Except that 'die' also happens to be German for 'the', so either a) it'll be a huge fight over who gets the name or b) ICANN will disallow registering it because it's a common word. The money, quite literally, is on ICANN giving it to whoever has the most deutschmarks.
At its simplest, the build vs. buy decision is about competitive advantage. If a company needs some commodity IT service or function, it should buy the "good enough" product. If the company is looking to support and enhance whatever it is that company does that makes it unique and better than its competitors, build it in-house and get exactly the right thing.
Most of what "the cloud" does is commodity functions.
Management != Leadership.
Like a lot of open source software, it's like a lot of other open source software that attempts to do pretty much the same thing, but in a different way and with different bugs and missing features. The solution, of course, to this mess of half-finished, buggy, and abandoned OSS with horrid UIs is easy. Start another project to do the same thing, only this time, we'll do it right. It'll be feature-complete quickly and free of serious bugs because all those other developers working on similar software will immediately see how superior we are and join us.
Maybe. I wouldn't assert that, for example, reading in a large decoded & uncompressed bitmap from disk is faster than re-running the decode from an in-memory copy of the original jpeg.
240MB is a problem for you? How much ram do you have, 512MB? OK, you're a bit behind the times -- no worries, you have the right to that. But when systems are shipping with 8GB and 4 cores running over 3Ghz, the choices the FF team has made for user experience over memory usage make more sense.
FF does not leak memory -- not in the strictest since -- as bad as most programs of its size and complexity.
What it *does* do is hold onto memory it thinks it might need in the future, to reload/re-render something the user looked at recently.
Of course, explaining to the average user the difference between the technical definition of a leak and simply holding on to useable (but reachable and potentially free-able) memory more aggressively than needed is a pointless exercise. Non-technical users don't care why they are low on memory, they just see that their 100 tabs and 55 running programs all slow down.
Up to now users of FF have demanded a snappy user experience with instant response time for most interactions. The natural tradeoff to achieve that is to use and hold more memory.
For whatever reason -- be it an increase in use of low-end hardware or perception that of all the memory-sucking applications a user want, the browser should not be one of them -- people have shifted towards feeling that FF is a memory hog. When you have 8GB or RAM and a multi-core CPU, FF doesn't really look terrible. When users decide that 2GB and 2Ghz is plenty, then FF looks bad.
I'm glad that the mozilla team has decided to revisit some of the assumptions about performance vs. memory use that have driven development over the past years, but the idea that closing a page should free memory wasn't high on the wish list of most users, who really preferred to see their web pages, bloated with javascript, ads, and and widgets served up by the typical site, load and render quickly.
Ignore the rest of your comment, I'll point out that, for better or worse, Firefox has for a long time been pushed for more features/faster rendering/snappier user experience and they've made what is the standard trade-off in programming: used more RAM. Firefox is now at the point where users with 4GB or more who don't really fret at a program using 700MB are happy at the responsiveness.
Is that the right tradeoff though? Is it right to target the higher end systems and ignore the 1-2GB single core CPUs 2Ghz?
For a while, it made sense to push the high end performance, but now there's been some rethinking. The majority of users seem to have discovered that for *most* of what they do, 2GB and 2Ghz is fine. Firefox is losing in that arena, and now some folks want to address that.
Changing the mindset of the FF team is the most important aspect of this project, but also the most difficult.
Yeah, when the hardware is defective by design, the filesystem does get screwed up. It's up to the fs developers to account for this and provide tools to recover. Failure to do so and instead blaming the hardware or the sysadmin for using flawed hardware is not an acceptable stance.
The emails are probably all stored in an Exchage server somewhere. Any experts on that system want to chime in on the actual difficulty of extracting tens of thousands of individual messages, what format they'll end up in, how big the resulting dump would be?
I know as slashdotter we all keep our email in plain text format and can easily bzip -9 the whole thing down to a few hundred K, but you know Palin's email probably contains a bunch of PP presentations and other huge files.
While I agree with your position that the hardware is flawed and possibly defective by design, I disagree that this absolves the Fedora and btrfs developers from having to do anything.
The old saw "Be strict in what you send, but generous in what you accept" applies here. Because there *is* a way that the filesystem can recover -- though admittedly with some difficulty -- from a hardware fault like this. Other filesystems offer tools to deal with such hardware.
By making it the default fs, Fedora is putting the sysadmins in the difficult position of trying to determine if the hardware they have is flawed or choosing a different fs at install time anyway. Because it's virtually impossible to know if the hardware doesn't properly implement what the manufacturer claims it does, a prudent sysadmin MUST choose a different filesystem.
Granted, this is Fedora, the distribution aimed at folks who are maybe willing to be less prudent and accept some risk. Perhaps the leverage of Fedora users asking for it along with the large body of "in the wild" testing will give btrfs developers the kick needed to close this gap.
It says right here on the btrfs wiki: "While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably if your machine crashes or loses power on disks that don't handle flush requests correctly. This will be fixed when the fsck tool is ready. "
So I'd say yah, that's a pretty important piece to be missing if you're talking about making it the default for a distro, even one as free-wheeling as Fedor.
An algorithm is of mild interest, yet Van Gogh's Starry Night, a landscape, is far more interesting than his Starry Night Over the Rhone, a painting that includes a man and a woman walking arm-in-arm by the river.
I had that account until December of 2010, when I decided I'd migrated all the folks that mattered to my newer email address and I wasn't getting anything but spam at the io.com address.
I wonder who is going to get the domain now, and how much they are coughing up for it.
Mac Defender just proves that Apple has finally broken the Microsoft Windows monopoly on the desktops of the sort mouth-breathing idiot who can be socially engineered into incredibly stupid actions.
You're correct, Ares V was never intended to be a launcher for humans, but the changes to the RS-68 were still substantial, and there were discussions within NASA to man-rate the engine as part of the changes anyway. I also wonder how many changes would be required in the first stage core -- essentially a shuttle ET -- to work with the RS-68 vs. the SSME.
It was OK, except it still ended up in the same obscenely expensive cost model for development that has plagued almost everything that involves continuing to work with the current batch of contractors -- Lockheed Martin and ATK (formerly Morton-Thiokol).
Another downside was the use of SSMEs -- an throwing them away every flight. Yes, there were proposals to replace them with modified RS-68 engines, but the redesign and NASA requirements for human-rating them (said requirements can be argued about, but that's another topic) would have raised the cost yet more.
Allow me to say it more colorfully:
NASA announced Tuesday that they will continue to blow wads of cash on a failed design for a spacecraft.
The Orion capsule, now dubbed "MPCV", in development since 2005 but not even ready for first launch, will continue to suck up money that could go to efforts that have a chance of producing something tangible well before 2015.
The bloated, overweight, and complicated capsule that has already made $5 billion disappear into a black hole will continue as a contract to fill prime contractor Lockheed Martin's coffers.
Amusingly, the PR materials show the as-yet-nothing-but-a-ground-test-article spacecraft in Mars orbit, even though it only has a 21-day mission span.
Good analysis of how they would probably foil the backtrace. As far as caving when there are warrants, I was thinking of a hosting company off in a small island country that doesn't put a lot of effort into complying with international law enforcement efforts. I don't know of such places, but I'm sure they must exist.
Considering how Amazon has become known for caving to the slightest pressure from law enforcement or even just a nosy senator, to host such an attack from EC2 seems extraordinarily stupid.
It would make much more sense to launch it from somewhere hosted by a company that doesn't have a reputation for giving up their customer's data and shutting down even legitimate stuff that happens to run afoul of their vague guidelines.
Still no official support for 64-bit platforms. That Nov 2010 release of 'Square' is the only thing that works on my Firefox 4 64-bit build with Snow Leopard.
PGO: Profile-Guided Optimization. A FF PGO build will compile an executable with with profiling on, the run that executable using an automated script that drives the browser through a suite of tests that is intended to mimic typical usage. The results of this profiling are written to a file and then a second, optimized build is done using the profiling results as a guide for the optimizer to generate better code for the hotspots.
I've been doing it with FF4 on my Mac with Snow Leopard for some time. It does make for longish build times, though.
The dock was originally on the side, back when OS X was called NeXTSTEP