1) Throw the MCSEs a bone: give them their MSIs and GPOs. Alternatively, bless FrontMotion's MSI and GPO projects as the "official" ways to get these things for businesses that need them.
2) From time to time (but no more frequently than once every two years), tag a release as Long-Term Support. This is exactly what it says on the tin: this release gets official support from Mozilla, including security fixes, until the next Long-Term Support release.
3) Support for a non-LTS release is not dropped until there have been at least two major releases since then. Under the current situation, that means FF5 support would not be dropped until the release of FF7, which in turn would not be dropped until the release of FF9.
I realize that long-term or even mid-term support is not sexy. Techies always want to live on the bleeding edge. But not every person or business is willing, or even able, to do that. They also need to be taken care of.
The company that advocated going CD for CD's sake, and then HD for HD's sake, and even until very recently actively campaigned for 3D for 3D's sake, is now trying to say that pretty pictures aren't everything? Yeah, right. Sony depends on pretty pictures; their whole business model is based on it. This is a calculated marketing risk in an attempt to combat the 3DS, and nothing more.
(on a related note, why does the latest graphical gimmick always have an abbreviation that ends in D?)
The choke point isn't so much the number of judges as it is the number of courtrooms. You'd have to build and fully staff more of these, so that more trials could run at the same time, which incurs not only staff and construction costs but also land costs.
Eventually the number of judges would indeed become the limiting factor, and then you'd have to hire more of them. But right now, that's not the biggest problem.
I humbly suggest the name "libcreep" named for the way parsers creep through the syntax tree and absolutely positively having no other intended meaning.
This seems to happen from time to time.
on
When Software Offends
·
· Score: 4, Interesting
I remember about 7-8 years ago, when someone coded up an emulator for the Neo-Geo Pocket Color. The supposed full name of the product (which none of the developers ever used) was "Rather A Pokemon Emulator?" and the logo was a Pikachu poorly Photoshopped for, shall we say, reasons of endowment. I don't recall if the software was open-source or not, but the naming controversy doesn't sound too different from this.
Free speech allows you to name your project whatever you want, no matter how tasteless. Free association, however, allows people to decide not to use your project based on its name. Open-source even lets someone fork it, changing little if anything but the name, and snag the userbase out from under a puerile manchild.
Yeah, this is what I'm thinking. Fork the thing with two new features: a name you can mention in a business meeting without getting nasty looks from 3/4 of your colleagues, and a lead developer who has actually matured beyond the age of fourteen.
From what I can tell, Mozilla seems to have four versions of Firefox being developed and/or maintained at any given time:
Current - Whatever is currently released. Only bugfixes usually get ported to this release. Currently FF5. Beta - Feature-frozen and reasonably stable, but not quite ready for prime time. Will be the next release. Currently FF6. Aurora - Feature-frozen, but not stable. Early QA happens here, though it gets more fleshed out in Beta. Currently FF7. Nightly - This is where the new feature development happens. Currently FF8.
When it's time for release, everything gets promoted: when FF6 is released, FF7 will become Beta, FF8 will become Aurora, and new development will start on FF9.
I kind of like the idea of putting new code through two entire cycles of public testing. All the same, I do wish that Mozilla would add a Long-Term Support cycle every few versions, akin to Ubuntu's LTS cycle, that people could count on to be supported for more than just a couple of months.
It is true that sane IT departments upgrade their browsers regularly, but not all IT departments are driven by sanity. This is a sad fact that Mozilla needs to account for, and there's a tested model out there that isn't too dissimilar to Mozilla's own. They should seriously look into adapting the differences.
The privatized system we had before worked at least as well as the TSA has ever been able to demonstrate, and did it in a far less invasive manner. This one, at least, is no arch-capitalist theory here; it's a known-working system, known working by the fact that it worked for many years.
Nintendo is wasting its time with the hardcore. They're never coming back. For crying out loud, they still haven't forgiven Nintendo for the SNES version of Mortal Kombat.
Nintendo never abandoned the hardcore with the Wii. It should have -it's a market Nintendo hasn't had any hope of reclaiming for a very long time, and frankly it's a market that has done nothing but harm to the industry since taking it over- but it didn't. Unfortunately, it seems to be abandoning the much healthier market that it was finally starting to really win over in the DS and Wii days, all for a group that not only hates Nintendo but frankly doesn't care for anything but pretty pictures and pwning the n00bs.
How about plugin developers actually maintain their plugins properly? If they tested with new versions like they should, then marking the plugin as compatible with the versions that pass would take essentially no extra effort.
Few enough games have any real replay value nowadays -they're fun to play once, but not to play again- that one fixed save slot is perhaps a bit of honest advertisement as to this game's actual value.
On the other hand, this transparent attempt at trying to kill the used game market -a market which deals in games for which Capcom has by definition already gotten all of the money it has any right to get- is underhanded and unethical.
I can't very well say that I'll boycott this game, because I wasn't interested in it anyway, so this doesn't change my decision not to buy. It might, however, affect my decision to buy other Capcom games going forward. It is probably too late to reverse the decision for this game, but I have two words for Capcom if they want to keep my business: never again.
Didn't Tesla say at one point that the cars they built were more about testing and demonstrating the technology behind electric vehicles, and that the real money was to be made in licensing the technology to other car makers?
Also, doesn't TFA state that the Model S is still going ahead as planned, even if the Roadster is not?
To some degree, yes, though there are things that could possibly be made more robust.
The issue isn't that addons have to be updated but that they break with every major version. That's right, they *will* break *everytime*, as Firefox refuses to enable add-ons that haven't been tested for the current version. At the very least, the developer has to update this information.
If that's all you mean, then frankly, I'm OK with that. A developer not serious enough about their code to test with new versions of the browser as they come out is not someone who should be developing add-ons.
The automatic-updates system could be mitigated somewhat by setting up a repository system for add-ons. This way they could be included in the auto-update setup as well.
it sounds more to me like you were talking about the create_function() function in PHP, which actually does work pretty much like you described. PHP recently got closures (with some warts, like having to explicitly specify which variables are made available to the function being specified), but for a long time create_function() was the closest thing it had.
The closest thing it has to actual classes feels like a crudely bolted on hack (like Perl, but with even less syntax support).
Most of the commonly built-in JavaScript APIs abuse developers by forcing them to use callbacks because JavaScript has no notion of blocking calls and doing work in other threads at the same time.
Worse, most JS APIs (e.g. XHR) don't provide any extra parameters for passing context data through them to your callback. This forces you to do such awful hacks as hiding program data in the DOM tree and building generated helper functions on the fly for every freaking call. Such design makes the use of those functions very, very cumbersome, to say the least.
Yep, as I thought: complaining over the lack of pet paradigms and refusing to learn new ones. You in particular also seem to prefer syntactic handholding to dynamism: an odd case since the arguments you make sound like those of someone who favors PHP. Rather than learn prototype-based OO and closures, you prefer more rigid, static techniques.
It uses the same symbol for addition and string concatenation, leading to the necessity of ugly hacks like parseInt() that could just as easily be done transparently if the two (conceptually dissimilar) operations had separate symbols.
Here you mostly have a point, though I'm not sure how much benefit changing to a dot really gains.
Microsoft has rejected interoperable technologies based on spurious "security concerns" before, only to release later a competing yet non-interoperable technology with far worse security problems than ever showed up on what they rejected. Remember browser plugins, passed over in favor of the steaming pile of fail that is ActiveX?
Look for WebDirect3D in the next version of IE, likely with every problem MS claims WebGL has and a few new ones.
IIRC, shrouds intended for burial at sea aren't watertight. The material is made to be durable in undersea conditions so that the body won't escape, but holes are cut into the fabric to let water in and escaping gases out. This speeds up decomposition and reduces the bag's buoyancy.
I'm just saying that he won't ever be able to prove that the body he found was bin Laden's, and thus will never be able to collect the reward. He won't be able to pacify the deathers either.
Note that I am not a conspiracy theorist. I believe that bin Laden was in fact killed and buried at sea, either just as the US government claims or close enough to it as makes no real difference. But lots of people get buried at sea, and bin Laden cannot possibly be the only person to have been buried at around that time and place. All it takes to keep him from getting the reward is a simple claim that he's pulled somebody else's body, and he will have no way to refute that.
IIRC, don't bodies buried at sea decay very quickly? At this point he may be able to find the shroud and weights, but the body itself must be past the point of recognizability by now, if there's anything left of it at all.
The state of the art in visual site editing tools is still in such a state of flux that there's no way to predict what will still be going in the long term and what will not. I hate to say it, but as long as you insist on visual tools you're doomed to the cycle of obsolescence for at least as long as it takes HTML5 to solidify, and probably longer.
If you want a piece of software that will let you edit Web pages (or entire sites) over the long haul, text is still your only real option. This may change at some future point, but that point is years away.
So they ran a test between two statically-compiled native-code languages and two dynamically-compiled bytecode languages, and then seem surprised when one of the native-code language wins?
I'm also noticing a marked lack of C# (not something I'm personally a fan of, but nothing if not a mainstream competitor to the languages listed) and Python (another language that gets "used for real stuff" inside Google) in the test. Why is that? Not that I'd expect Python to do very well in a performance test against languages like these, but it still seems an odd omission.
This is important. People poke fun at that one report that referred to lulz as "a corruption of LOL," but it really is, both in the linguistic sense and a wider philosophical one. It's not just about having fun, but specifically having fun at someone else's expense. Or, in a word, bullying.
Actually, now that I think about it, I'm going to have to stop using the term. A shame, that, because it really is fun to say.
Slashdot Mirror
1) Throw the MCSEs a bone: give them their MSIs and GPOs. Alternatively, bless FrontMotion's MSI and GPO projects as the "official" ways to get these things for businesses that need them.
2) From time to time (but no more frequently than once every two years), tag a release as Long-Term Support. This is exactly what it says on the tin: this release gets official support from Mozilla, including security fixes, until the next Long-Term Support release.
3) Support for a non-LTS release is not dropped until there have been at least two major releases since then. Under the current situation, that means FF5 support would not be dropped until the release of FF7, which in turn would not be dropped until the release of FF9.
I realize that long-term or even mid-term support is not sexy. Techies always want to live on the bleeding edge. But not every person or business is willing, or even able, to do that. They also need to be taken care of.
The company that advocated going CD for CD's sake, and then HD for HD's sake, and even until very recently actively campaigned for 3D for 3D's sake, is now trying to say that pretty pictures aren't everything? Yeah, right. Sony depends on pretty pictures; their whole business model is based on it. This is a calculated marketing risk in an attempt to combat the 3DS, and nothing more.
(on a related note, why does the latest graphical gimmick always have an abbreviation that ends in D?)
The choke point isn't so much the number of judges as it is the number of courtrooms. You'd have to build and fully staff more of these, so that more trials could run at the same time, which incurs not only staff and construction costs but also land costs.
Eventually the number of judges would indeed become the limiting factor, and then you'd have to hire more of them. But right now, that's not the biggest problem.
I humbly suggest the name "libcreep" named for the way parsers creep through the syntax tree and absolutely positively having no other intended meaning.
I remember about 7-8 years ago, when someone coded up an emulator for the Neo-Geo Pocket Color. The supposed full name of the product (which none of the developers ever used) was "Rather A Pokemon Emulator?" and the logo was a Pikachu poorly Photoshopped for, shall we say, reasons of endowment. I don't recall if the software was open-source or not, but the naming controversy doesn't sound too different from this.
Free speech allows you to name your project whatever you want, no matter how tasteless. Free association, however, allows people to decide not to use your project based on its name. Open-source even lets someone fork it, changing little if anything but the name, and snag the userbase out from under a puerile manchild.
Yeah, this is what I'm thinking. Fork the thing with two new features: a name you can mention in a business meeting without getting nasty looks from 3/4 of your colleagues, and a lead developer who has actually matured beyond the age of fourteen.
By the way, what does this thing even do?
From what I can tell, Mozilla seems to have four versions of Firefox being developed and/or maintained at any given time:
Current - Whatever is currently released. Only bugfixes usually get ported to this release. Currently FF5.
Beta - Feature-frozen and reasonably stable, but not quite ready for prime time. Will be the next release. Currently FF6.
Aurora - Feature-frozen, but not stable. Early QA happens here, though it gets more fleshed out in Beta. Currently FF7.
Nightly - This is where the new feature development happens. Currently FF8.
When it's time for release, everything gets promoted: when FF6 is released, FF7 will become Beta, FF8 will become Aurora, and new development will start on FF9.
I kind of like the idea of putting new code through two entire cycles of public testing. All the same, I do wish that Mozilla would add a Long-Term Support cycle every few versions, akin to Ubuntu's LTS cycle, that people could count on to be supported for more than just a couple of months.
It is true that sane IT departments upgrade their browsers regularly, but not all IT departments are driven by sanity. This is a sad fact that Mozilla needs to account for, and there's a tested model out there that isn't too dissimilar to Mozilla's own. They should seriously look into adapting the differences.
So with this, the argument is that monopsonies are as bad for free markets as monopolies are. Who'da thunk it?
The privatized system we had before worked at least as well as the TSA has ever been able to demonstrate, and did it in a far less invasive manner. This one, at least, is no arch-capitalist theory here; it's a known-working system, known working by the fact that it worked for many years.
Nintendo is wasting its time with the hardcore. They're never coming back. For crying out loud, they still haven't forgiven Nintendo for the SNES version of Mortal Kombat.
Nintendo never abandoned the hardcore with the Wii. It should have -it's a market Nintendo hasn't had any hope of reclaiming for a very long time, and frankly it's a market that has done nothing but harm to the industry since taking it over- but it didn't. Unfortunately, it seems to be abandoning the much healthier market that it was finally starting to really win over in the DS and Wii days, all for a group that not only hates Nintendo but frankly doesn't care for anything but pretty pictures and pwning the n00bs.
How about plugin developers actually maintain their plugins properly? If they tested with new versions like they should, then marking the plugin as compatible with the versions that pass would take essentially no extra effort.
Few enough games have any real replay value nowadays -they're fun to play once, but not to play again- that one fixed save slot is perhaps a bit of honest advertisement as to this game's actual value.
On the other hand, this transparent attempt at trying to kill the used game market -a market which deals in games for which Capcom has by definition already gotten all of the money it has any right to get- is underhanded and unethical.
I can't very well say that I'll boycott this game, because I wasn't interested in it anyway, so this doesn't change my decision not to buy. It might, however, affect my decision to buy other Capcom games going forward. It is probably too late to reverse the decision for this game, but I have two words for Capcom if they want to keep my business: never again.
Didn't Tesla say at one point that the cars they built were more about testing and demonstrating the technology behind electric vehicles, and that the real money was to be made in licensing the technology to other car makers?
Also, doesn't TFA state that the Model S is still going ahead as planned, even if the Roadster is not?
Like, say, addons.mozilla.org?
To some degree, yes, though there are things that could possibly be made more robust.
The issue isn't that addons have to be updated but that they break with every major version. That's right, they *will* break *everytime*, as Firefox refuses to enable add-ons that haven't been tested for the current version. At the very least, the developer has to update this information.
If that's all you mean, then frankly, I'm OK with that. A developer not serious enough about their code to test with new versions of the browser as they come out is not someone who should be developing add-ons.
The automatic-updates system could be mitigated somewhat by setting up a repository system for add-ons. This way they could be included in the auto-update setup as well.
it sounds more to me like you were talking about the create_function() function in PHP, which actually does work pretty much like you described. PHP recently got closures (with some warts, like having to explicitly specify which variables are made available to the function being specified), but for a long time create_function() was the closest thing it had.
The closest thing it has to actual classes feels like a crudely bolted on hack (like Perl, but with even less syntax support).
Most of the commonly built-in JavaScript APIs abuse developers by forcing them to use callbacks because JavaScript has no notion of blocking calls and doing work in other threads at the same time.
Worse, most JS APIs (e.g. XHR) don't provide any extra parameters for passing context data through them to your callback. This forces you to do such awful hacks as hiding program data in the DOM tree and building generated helper functions on the fly for every freaking call. Such design makes the use of those functions very, very cumbersome, to say the least.
Yep, as I thought: complaining over the lack of pet paradigms and refusing to learn new ones. You in particular also seem to prefer syntactic handholding to dynamism: an odd case since the arguments you make sound like those of someone who favors PHP. Rather than learn prototype-based OO and closures, you prefer more rigid, static techniques.
It uses the same symbol for addition and string concatenation, leading to the necessity of ugly hacks like parseInt() that could just as easily be done transparently if the two (conceptually dissimilar) operations had separate symbols.
Here you mostly have a point, though I'm not sure how much benefit changing to a dot really gains.
My guess: yet another person complaining about how JavaScript doesn't use their specific pet paradigms.
Microsoft has rejected interoperable technologies based on spurious "security concerns" before, only to release later a competing yet non-interoperable technology with far worse security problems than ever showed up on what they rejected. Remember browser plugins, passed over in favor of the steaming pile of fail that is ActiveX?
Look for WebDirect3D in the next version of IE, likely with every problem MS claims WebGL has and a few new ones.
IIRC, shrouds intended for burial at sea aren't watertight. The material is made to be durable in undersea conditions so that the body won't escape, but holes are cut into the fabric to let water in and escaping gases out. This speeds up decomposition and reduces the bag's buoyancy.
I'm just saying that he won't ever be able to prove that the body he found was bin Laden's, and thus will never be able to collect the reward. He won't be able to pacify the deathers either.
Note that I am not a conspiracy theorist. I believe that bin Laden was in fact killed and buried at sea, either just as the US government claims or close enough to it as makes no real difference. But lots of people get buried at sea, and bin Laden cannot possibly be the only person to have been buried at around that time and place. All it takes to keep him from getting the reward is a simple claim that he's pulled somebody else's body, and he will have no way to refute that.
IIRC, don't bodies buried at sea decay very quickly? At this point he may be able to find the shroud and weights, but the body itself must be past the point of recognizability by now, if there's anything left of it at all.
The state of the art in visual site editing tools is still in such a state of flux that there's no way to predict what will still be going in the long term and what will not. I hate to say it, but as long as you insist on visual tools you're doomed to the cycle of obsolescence for at least as long as it takes HTML5 to solidify, and probably longer.
If you want a piece of software that will let you edit Web pages (or entire sites) over the long haul, text is still your only real option. This may change at some future point, but that point is years away.
So they ran a test between two statically-compiled native-code languages and two dynamically-compiled bytecode languages, and then seem surprised when one of the native-code language wins?
I'm also noticing a marked lack of C# (not something I'm personally a fan of, but nothing if not a mainstream competitor to the languages listed) and Python (another language that gets "used for real stuff" inside Google) in the test. Why is that? Not that I'd expect Python to do very well in a performance test against languages like these, but it still seems an odd omission.
This is important. People poke fun at that one report that referred to lulz as "a corruption of LOL," but it really is, both in the linguistic sense and a wider philosophical one. It's not just about having fun, but specifically having fun at someone else's expense. Or, in a word, bullying.
Actually, now that I think about it, I'm going to have to stop using the term. A shame, that, because it really is fun to say.