I really think their is a more of a "politcal" reason for not supporting OGG files anymore (not sure what it is, but for some reason companies don't want OGG files catching on).
So, are you saying there is some sort of conspiracy between music player makers and the fraunhofer institute to keep ogg support off players? I don't buy that for a second. For me there can be no doubt that ogg is more expensive to support, or all players would support it.
The article mentions the fact that bugzilla's release manager wants to see it rewritten in some other language because in his opinion perl is no longer a good language to be writing large applications in. I expected to go into the comments and see nothing but outraged reactions from perl lovers, because that's what I would have seen 5 years ago.
Bugzilla's 9-year-road to 3.0 is a good example of why code should very rarely been rewritten from scratch and even if, then never the whole codebase. The more ambitious the goal one tries to achieve by that the harder the task - especially if one needs to keep updating the old codebase. There is no code which cannot be iteratively improved to achieve whatever the fresh code is suppose to.
So, if you had a bug tracker written in assembly you'd keep iteratively improving the assembly instead of rewriting it in a higher-level language? Different programming environments don't have equal productivity levels, so if you want to add features to an application it sometimes can help you to rewrite it to get where you need to be going faster.
I agree though that in bugzilla's case a rewrite probably doesn't make sense. The benefit of other languages over perl is probably marginal at best, and to think that a man alone could rewrite bugzilla, without defects, in 18 months, like the developer in the article proposes, is a bit naive to say the least.
Come to think of it, I could say that against many of the projects(FOSS in particular)... A bit more effort on UI could make a world of difference. Been testing office 2007 last few weeks and I'm very impressed. Just one of the apps in recent times whose UI made me feel why didn't I think of it.
It's not a matter of effort, it's a matter of vision. The nature of how OSS works (many eyeballs) is counter to how good GUI's are designed (central visionary designer). To make matters worse, in most OSS projects the core developers are engineers, not designers, and so even if they have a centralized concept of the GUI, it's built targeted towards engineers, not towards the actual userbase.
The funny thing is that with scientology you can actually track its progress from money-making scam, to becoming a self-perpetuating cult, to living beyond the founding scammer / cult leader, to reaching critical mass and becoming a full-blown religion. We've never had that with the other religions, where the early years are shrouded in mystery.
This implies that its acceptable to picket Scientogoly(a fake church) while it is wrong to picket a "real" church, ie real as in christian? Just what kind of bigoted ridiculousness is this, no matter what church it is, it is acceptable(ie constitutionaly protected) to picket and protest its presence.
Just because you call something a religion doesn't mean it is. Scientology is a money-making scam, nothing more. That is not to say that there aren't any believers, but every scam has its believers.
But, yes, fake religions, real religions, real presidents, it doesn't matter, you should be allowed to protest it unless you are being a danger to the public safety (which this guy wasn't). For a nation that protects freedom of faith to such a degree the US is pretty poor at protecting freedom of protesting/speech.
it's fair to say that the French right is roughly equivalent to the American left.
Actually, it's fair to say that there is no american left. In most countries the political spectrum runs from near-communism on the left to near-fascism on the right. In the US, however, communism is such a political taboo that anything that even remotely sounds like it (like socialism) is a politically bad idea as well, resulting in left-wing ideas that are commonplace everywhere else (like universal health-care) getting branded as somehow "outlandish".
Perhaps more importantly, PHP drags the speed of other things down (like Apache), since even though the core is supposedly thread-safe, nobody seems to know which extensions are and aren't, so eg. Apache needs to be run in prefork mpm instead of using a threaded mpm.
This is my main beef with PHP. They have their head in the sand with regards to server configuration.
Case in point: the company I work for sells PHP-based service center and reservations systems to large companies. These companies generally have windows-based server infrastructures, so we have to deploy on windows/IIS. If you look at the suggested configuration for PHP on IIS in the PHP manual, you'll find this page, which explains regular CGI and ISAPI (multi-threaded) configurations. What the manual doesn't tell you is that neither of these configurations actually work in production environments. Regular CGI configurations are too slow (on windows), and ISAPI is too unreliable (customers that deployed with ISAPI configurations suffered daily server hangs).
The only viable configuration for production IIS servers, as it turns out, is FastCGI, which is not documented in PHP's manual section on IIS configuration. Their documentation actively misinforms people on how to configure PHP. That's bad.
The raw speed of PHP isn't very relevant. It's a language for low to mid-range web apps that is flexible enough to do high-end web apps as well. If your PHP app is slow it's probably due to poor programming or poor database indexing or design. PHP usually takes request data, gathers a database result, shuffles around some data, then displays an HTML page. It's easily fast enough for its purpose.
What's also important is that PHP is meant to be parallelized, which lets it scale better to higher traffic. The larger web applications can't be run on a single box anymore, the performance requirements are too high. The difference between PHP and other solutions performance-wise is simply a matter of how many machines are in your server pool.
Anyway, the simplest counter-argument to claims that PHP can't handle high loads is the fact that wikipedia runs on PHP.
Seriously, there's pretty much only three things these are used for: advertising, low-quality DRM, and toys and games. Exceptions like the Java applets at Greg Egan's site are far and few between, and Google has shown us with Maps and Gmail that you don't *need* these plugins to produce rich content.
You can't do video-, sound- or advanced graphics-based web apps (by advanced I mean high performance) without flash or java.
That you haven't seen any apps that build on top of the flash or java platform that impress you is mostly because these are commercial applications. My company sells a flash-based AutoCAD floorplan viewer / editor. Fauxto.com is a nice example of what's possible, but you can do better still than that.
I've always thought google maps demonstrated exactly why you did in fact need flash and java. It is the pinnacle of javascript-based tech, and yet it is a lot less usable than the new yahoo maps and the older java-based map systems.
This is an example of capitalism failing due to poorly-informed consumers. But I can think of no way to solve the problem (a security quantifier???), so the industry will continue along as it does today: cheap software and band-aid security.
This isn't restricted to software. If you look around you'll notice this happens everywhere. And it's not always about security either. Like how the gas mileage in cars could be a lot better but it isn't profitable to make it so. Or how our foods could be a lot healthier but it would price them right out of the market.
The counter argument is that it takes more effort to build all software to be secure than it takes to handle the fall-out of insecure software. Just like everyone could go live in a fortified underground bunker to protect themselves against burglars, but it is far more feasible on a society-wide level to just deal with the occasional burglary.
Utopia is a pretty cool place. I'd like to go there too.
You make it sound like building software that is secure by nature is impossible. It isn't. SELinux is secure by nature. Qmail is secure by nature. Qmail is guaranteed by the programmer to not have security bugs, with a $500 bounty for the reporter of the first exploit.
Modern desktop operating systems have mediocre to poor design from a security perspective. They could be built a lot better, only they're not because it is far more profitable to not improve the security and focus on features instead (flashy window animations sell better than being bulletproof).
Heck, even the software I build for a living is far less secure than it could be, because I have feature-pressure forcing my hand.
Actually, from a completely CEO point of view, supporting Linux for free is pointless. It requires more effort to produce a bunch of binaries to run on all distributions than a single binary for Windows or Mac. Even then people will carp that the source code isn't available, and probably won't bother to go through the much harder process of installing it. Once again it's a minority of minority thing - Linux has a minority market share, and only a small minority of Linux users will bother with a binary only flash player.
It doesn't matter about how much marketshare you win by making a linux player, it matters how much mindshare you win. If flash can be perceived as "the cross-platform solution", then it will see much more adoption.
How about the ability to visit any website from any browser on any platform? I know it is a lot to ask, but why should we go from a huge rate of growth with a totally open standard (pure HTML) to a stagnant level of growth with closed source proprietary technologies (HTML + Flash)?
Modern web apps are only guaranteed to run in IE. Almost all also run in firefox. Most run in opera and safari. However, to say that all html-based web apps run in all browsers is a gross mirepresentation.
I consider flash a tool to use when building web apps. You look at the target market, you look at what functionality is needed, and sometimes flash is the best answer. Now, Free Software advocates would likely shudder if they hear that, but it's up to them to build a better mouse trap. Build me something that works as well as flash but is standards-based and browser-native, and I will use it. As it stands, for graphics or sound, flash is the only sensible choice (canvas and svg show promise, but they're not useful enough yet, and they only cover graphics, not video and sound).
However, what I think adobe should do is standardize flash and cooperate with firefox, opera and safari to make it browser-native. How they can do that and not have microsoft destroy flash by creating an enemy fork and bundling it with windows I have no idea.
Yeah, because if you pay a load of people to develop something, you obviously want to release the source code to the whole world to make absolutely sure that if you ever try to charge for it in future, someone else can undercut you.
Except that adobe's best way to kill flash adoption would be to charge for the player. Profit is not a factor in the decision to keep it closed, control is. They're afraid that if they open source it, an enemy fork will kill it, and given the history if client-side java I can't really say they're wrong to fear that.
The problem is that Flash doesn't integrate in with anything ASP or.NET . XML is good in some ways for this, but no.NET developer wants to learn ActiveScript, buy FlashMX, learn a whole new way of creating UIs, and learn about AJAX to get Flash integrating with their current systems.
1. Obviously you have no experience with flex (flex is flash for web app development) 2. Flash/flex integrates extremely well with both javascript and any and all server-side platforms 3. ActionScript 3 corresponds to JavaScript 2 (they're both based on the same ECMAScript revision), so anyone who knows javascript knows actionscript. 4. You don't need to buy anything, the flex sdk is a free download from adobe's site and contains everything you need (compiler, debugger, framework, documentation, getting started guides,...). The flex sdk is what adobe open-sourced by the way.
I think if Adobe invested more in Flash, and specifically getting more developers into Flash, they'd have a solid niche. But they've made Flash development more difficult to get into than it needs to be, and I think that based on that alone you can predict that Silverlight will probably fight a downhill battle and win over Flash.
The flex sdk is easier to learn than most ajax libraries (like yui or gwt). I would find it very difficult to design a framework that is more sensibly structured than flex 2. I used to hate flash also, but having seen what it can do I consider it a must-know technology for any serious web app developer.
Silverlight feels like a shameless flex rip-off. Until it has a unique selling point other than fitting well into a.NET dev workflow it won't see much adoption outside of.NET shops.
I would cheerfully pay Adobe for their userland apps that are supported on Linux, opensource or not.
Maybe you would, but if there were in fact droves of developers waiting to hand over cash to adobe, adobe would be all over that market.
The reality is that linux users are less likely to pay for software because paid software generally involves non-open source components, and they just don't like that.
Adobe has no morals or principles, they have a bottom line. If it was profitable to release apps for linux, they would.
I haven't had a chance to really read the specifics of this yet, but does this mean that the action script 3 compiler/vm/etc is open sourced as part of this? As in, can it be embedded for example as a scripting language for a game, like lua, squirrel, etc.
The actionscript 3 compiler was open sourced before as tamarin (the mozilla project will base the next javascript engine on it). They've now open sourced the rest of the development tools (aside from the visual GUI designer, which you don't need anyway).
What Adobe has done by throwing an "open source" SDK bone is made it appear like they're leaning toward open-source Flash without actually giving away any of the crown jewels. Adobe's move is very much like the gigabyes of "open source" code samples Microsoft makes available in its extensive MSDN library: you can use and modify them for free, but you still need Microsoft's core (and proprietary) software to make them work.
The new situation with flex/flash is no different from the java situation as it existed for years and years, and that didn't stop java from embedding itself deeply in the open source world. This is the complete development toolchain. You don't need anything else to develop flex applications (the flex builder GUI designer is nice, but you can easily do without).
For flash/flex developers this is a big deal. This basically is adobe saying that they want flex to become the browser-side java.
As I said, if you're one of those people who doesn't mind rolling a service call/result parser/object creator by hand, sure, call whatever you want on the backend. I don't think that's a real attractive option for bigger shops trying to search/update/manipulate large data sets thought.
Bigger shops pay for their tools.
Besides, there's a strong open source flash community, and whatever tools are needed will be built on top of what adobe released pretty quickly.
A little vegetable oil is not going to make a big difference. Over the last decade or two they have snuck palm oil in, and sometimes even wax, and most consumers didn't notice. Most of you won't notice the vegtable oil either, and those of us who do already read the labels.
I'm Belgian. Belgium has great chocolate. When I visited NYC this was something that I noticed a lot. The chocolate sold in stores there was awful. Even the absolute best tasting brand (according to the US friend I was staying with) tasted worse than average belgian chocolate.
I guess the US chocolate manufacturers went for profit at the expense of quality.
beter than expected? Isn't MS-ie7 now part of the standard MS windows update system and has been for a couple of months now? I doubt it is optional so I'm surprised it's not a higher number.
IE is used most often in corporate settings, where the normal automatic updates system isn't used.
Subversion also counts as a daily backup, but at work we have a policy that you only check in working code (with reason), so daily checkins aren't realistic in some cases. I could work on a branch of course, but I don't see enough benefit in using a branch versus simply making local backups of my dev folder at the end of the day.
Anyway, at the time of the events I was a poor student, subversion didn't exist, and we couldn't install cvs on the server in question, nor did we have any spare server to install it on. The only backups we could make were to floppy, and we kind of got lazy with those.
Ah, the fun of wiping away a week's worth of code of an entire team just by a misguided "rm *.bkp" right before the day's end. They were surprisingly placid about it.
Ever since I take daily backups of anything I'm working on. Good habits are learned through pain.
Slashdot Mirror
I really think their is a more of a "politcal" reason for not supporting OGG files anymore (not sure what it is, but for some reason companies don't want OGG files catching on).
So, are you saying there is some sort of conspiracy between music player makers and the fraunhofer institute to keep ogg support off players? I don't buy that for a second. For me there can be no doubt that ogg is more expensive to support, or all players would support it.
The article mentions the fact that bugzilla's release manager wants to see it rewritten in some other language because in his opinion perl is no longer a good language to be writing large applications in. I expected to go into the comments and see nothing but outraged reactions from perl lovers, because that's what I would have seen 5 years ago.
Where has all the perl love gone?
Bugzilla's 9-year-road to 3.0 is a good example of why code should very rarely been rewritten from scratch and even if, then never the whole codebase. The more ambitious the goal one tries to achieve by that the harder the task - especially if one needs to keep updating the old codebase. There is no code which cannot be iteratively improved to achieve whatever the fresh code is suppose to.
So, if you had a bug tracker written in assembly you'd keep iteratively improving the assembly instead of rewriting it in a higher-level language? Different programming environments don't have equal productivity levels, so if you want to add features to an application it sometimes can help you to rewrite it to get where you need to be going faster.
I agree though that in bugzilla's case a rewrite probably doesn't make sense. The benefit of other languages over perl is probably marginal at best, and to think that a man alone could rewrite bugzilla, without defects, in 18 months, like the developer in the article proposes, is a bit naive to say the least.
Come to think of it, I could say that against many of the projects(FOSS in particular)... A bit more effort on UI could make a world of difference. Been testing office 2007 last few weeks and I'm very impressed. Just one of the apps in recent times whose UI made me feel why didn't I think of it.
It's not a matter of effort, it's a matter of vision. The nature of how OSS works (many eyeballs) is counter to how good GUI's are designed (central visionary designer). To make matters worse, in most OSS projects the core developers are engineers, not designers, and so even if they have a centralized concept of the GUI, it's built targeted towards engineers, not towards the actual userbase.
The funny thing is that with scientology you can actually track its progress from money-making scam, to becoming a self-perpetuating cult, to living beyond the founding scammer / cult leader, to reaching critical mass and becoming a full-blown religion. We've never had that with the other religions, where the early years are shrouded in mystery.
This implies that its acceptable to picket Scientogoly(a fake church) while it is wrong to picket a "real" church, ie real as in christian? Just what kind of bigoted ridiculousness is this, no matter what church it is, it is acceptable(ie constitutionaly protected) to picket and protest its presence.
Just because you call something a religion doesn't mean it is. Scientology is a money-making scam, nothing more. That is not to say that there aren't any believers, but every scam has its believers.
But, yes, fake religions, real religions, real presidents, it doesn't matter, you should be allowed to protest it unless you are being a danger to the public safety (which this guy wasn't). For a nation that protects freedom of faith to such a degree the US is pretty poor at protecting freedom of protesting/speech.
it's fair to say that the French right is roughly equivalent to the American left.
Actually, it's fair to say that there is no american left. In most countries the political spectrum runs from near-communism on the left to near-fascism on the right. In the US, however, communism is such a political taboo that anything that even remotely sounds like it (like socialism) is a politically bad idea as well, resulting in left-wing ideas that are commonplace everywhere else (like universal health-care) getting branded as somehow "outlandish".
Perhaps more importantly, PHP drags the speed of other things down (like Apache), since even though the core is supposedly thread-safe, nobody seems to know which extensions are and aren't, so eg. Apache needs to be run in prefork mpm instead of using a threaded mpm.
This is my main beef with PHP. They have their head in the sand with regards to server configuration.
Case in point: the company I work for sells PHP-based service center and reservations systems to large companies. These companies generally have windows-based server infrastructures, so we have to deploy on windows/IIS. If you look at the suggested configuration for PHP on IIS in the PHP manual, you'll find this page, which explains regular CGI and ISAPI (multi-threaded) configurations. What the manual doesn't tell you is that neither of these configurations actually work in production environments. Regular CGI configurations are too slow (on windows), and ISAPI is too unreliable (customers that deployed with ISAPI configurations suffered daily server hangs).
The only viable configuration for production IIS servers, as it turns out, is FastCGI, which is not documented in PHP's manual section on IIS configuration. Their documentation actively misinforms people on how to configure PHP. That's bad.
The raw speed of PHP isn't very relevant. It's a language for low to mid-range web apps that is flexible enough to do high-end web apps as well. If your PHP app is slow it's probably due to poor programming or poor database indexing or design. PHP usually takes request data, gathers a database result, shuffles around some data, then displays an HTML page. It's easily fast enough for its purpose.
What's also important is that PHP is meant to be parallelized, which lets it scale better to higher traffic. The larger web applications can't be run on a single box anymore, the performance requirements are too high. The difference between PHP and other solutions performance-wise is simply a matter of how many machines are in your server pool.
Anyway, the simplest counter-argument to claims that PHP can't handle high loads is the fact that wikipedia runs on PHP.
Seriously, there's pretty much only three things these are used for: advertising, low-quality DRM, and toys and games. Exceptions like the Java applets at Greg Egan's site are far and few between, and Google has shown us with Maps and Gmail that you don't *need* these plugins to produce rich content.
You can't do video-, sound- or advanced graphics-based web apps (by advanced I mean high performance) without flash or java.
That you haven't seen any apps that build on top of the flash or java platform that impress you is mostly because these are commercial applications. My company sells a flash-based AutoCAD floorplan viewer / editor. Fauxto.com is a nice example of what's possible, but you can do better still than that.
I've always thought google maps demonstrated exactly why you did in fact need flash and java. It is the pinnacle of javascript-based tech, and yet it is a lot less usable than the new yahoo maps and the older java-based map systems.
This is an example of capitalism failing due to poorly-informed consumers. But I can think of no way to solve the problem (a security quantifier???), so the industry will continue along as it does today: cheap software and band-aid security.
This isn't restricted to software. If you look around you'll notice this happens everywhere. And it's not always about security either. Like how the gas mileage in cars could be a lot better but it isn't profitable to make it so. Or how our foods could be a lot healthier but it would price them right out of the market.
The counter argument is that it takes more effort to build all software to be secure than it takes to handle the fall-out of insecure software. Just like everyone could go live in a fortified underground bunker to protect themselves against burglars, but it is far more feasible on a society-wide level to just deal with the occasional burglary.
Utopia is a pretty cool place. I'd like to go there too.
You make it sound like building software that is secure by nature is impossible. It isn't. SELinux is secure by nature. Qmail is secure by nature. Qmail is guaranteed by the programmer to not have security bugs, with a $500 bounty for the reporter of the first exploit.
Modern desktop operating systems have mediocre to poor design from a security perspective. They could be built a lot better, only they're not because it is far more profitable to not improve the security and focus on features instead (flashy window animations sell better than being bulletproof).
Heck, even the software I build for a living is far less secure than it could be, because I have feature-pressure forcing my hand.
Actually, from a completely CEO point of view, supporting Linux for free is pointless. It requires more effort to produce a bunch of binaries to run on all distributions than a single binary for Windows or Mac. Even then people will carp that the source code isn't available, and probably won't bother to go through the much harder process of installing it. Once again it's a minority of minority thing - Linux has a minority market share, and only a small minority of Linux users will bother with a binary only flash player.
It doesn't matter about how much marketshare you win by making a linux player, it matters how much mindshare you win. If flash can be perceived as "the cross-platform solution", then it will see much more adoption.
How about the ability to visit any website from any browser on any platform? I know it is a lot to ask, but why should we go from a huge rate of growth with a totally open standard (pure HTML) to a stagnant level of growth with closed source proprietary technologies (HTML + Flash)?
Modern web apps are only guaranteed to run in IE. Almost all also run in firefox. Most run in opera and safari. However, to say that all html-based web apps run in all browsers is a gross mirepresentation.
I consider flash a tool to use when building web apps. You look at the target market, you look at what functionality is needed, and sometimes flash is the best answer. Now, Free Software advocates would likely shudder if they hear that, but it's up to them to build a better mouse trap. Build me something that works as well as flash but is standards-based and browser-native, and I will use it. As it stands, for graphics or sound, flash is the only sensible choice (canvas and svg show promise, but they're not useful enough yet, and they only cover graphics, not video and sound).
However, what I think adobe should do is standardize flash and cooperate with firefox, opera and safari to make it browser-native. How they can do that and not have microsoft destroy flash by creating an enemy fork and bundling it with windows I have no idea.
Yeah, because if you pay a load of people to develop something, you obviously want to release the source code to the whole world to make absolutely sure that if you ever try to charge for it in future, someone else can undercut you.
Except that adobe's best way to kill flash adoption would be to charge for the player. Profit is not a factor in the decision to keep it closed, control is. They're afraid that if they open source it, an enemy fork will kill it, and given the history if client-side java I can't really say they're wrong to fear that.
The problem is that Flash doesn't integrate in with anything ASP or .NET . XML is good in some ways for this, but no .NET developer wants to learn ActiveScript, buy FlashMX, learn a whole new way of creating UIs, and learn about AJAX to get Flash integrating with their current systems.
...). The flex sdk is what adobe open-sourced by the way.
.NET dev workflow it won't see much adoption outside of .NET shops.
1. Obviously you have no experience with flex (flex is flash for web app development)
2. Flash/flex integrates extremely well with both javascript and any and all server-side platforms
3. ActionScript 3 corresponds to JavaScript 2 (they're both based on the same ECMAScript revision), so anyone who knows javascript knows actionscript.
4. You don't need to buy anything, the flex sdk is a free download from adobe's site and contains everything you need (compiler, debugger, framework, documentation, getting started guides,
I think if Adobe invested more in Flash, and specifically getting more developers into Flash, they'd have a solid niche. But they've made Flash development more difficult to get into than it needs to be, and I think that based on that alone you can predict that Silverlight will probably fight a downhill battle and win over Flash.
The flex sdk is easier to learn than most ajax libraries (like yui or gwt). I would find it very difficult to design a framework that is more sensibly structured than flex 2. I used to hate flash also, but having seen what it can do I consider it a must-know technology for any serious web app developer.
Silverlight feels like a shameless flex rip-off. Until it has a unique selling point other than fitting well into a
I would cheerfully pay Adobe for their userland apps that are supported on Linux, opensource or not.
Maybe you would, but if there were in fact droves of developers waiting to hand over cash to adobe, adobe would be all over that market.
The reality is that linux users are less likely to pay for software because paid software generally involves non-open source components, and they just don't like that.
Adobe has no morals or principles, they have a bottom line. If it was profitable to release apps for linux, they would.
Open sourcing Flex is nice and all
It would be, if we knew what it was.
Basically, flex is to flash what yui, dojo and gwt are to javascript.
I haven't had a chance to really read the specifics of this yet, but does this mean that the action script 3 compiler/vm/etc is open sourced as part of this? As in, can it be embedded for example as a scripting language for a game, like lua, squirrel, etc.
The actionscript 3 compiler was open sourced before as tamarin (the mozilla project will base the next javascript engine on it). They've now open sourced the rest of the development tools (aside from the visual GUI designer, which you don't need anyway).
What Adobe has done by throwing an "open source" SDK bone is made it appear like they're leaning toward open-source Flash without actually giving away any of the crown jewels. Adobe's move is very much like the gigabyes of "open source" code samples Microsoft makes available in its extensive MSDN library: you can use and modify them for free, but you still need Microsoft's core (and proprietary) software to make them work.
The new situation with flex/flash is no different from the java situation as it existed for years and years, and that didn't stop java from embedding itself deeply in the open source world. This is the complete development toolchain. You don't need anything else to develop flex applications (the flex builder GUI designer is nice, but you can easily do without).
For flash/flex developers this is a big deal. This basically is adobe saying that they want flex to become the browser-side java.
As I said, if you're one of those people who doesn't mind rolling a service call/result parser/object creator by hand, sure, call whatever you want on the backend. I don't think that's a real attractive option for bigger shops trying to search/update/manipulate large data sets thought.
Bigger shops pay for their tools.
Besides, there's a strong open source flash community, and whatever tools are needed will be built on top of what adobe released pretty quickly.
A little vegetable oil is not going to make a big difference. Over the last decade or two they have snuck palm oil in, and sometimes even wax, and most consumers didn't notice. Most of you won't notice the vegtable oil either, and those of us who do already read the labels.
I'm Belgian. Belgium has great chocolate. When I visited NYC this was something that I noticed a lot. The chocolate sold in stores there was awful. Even the absolute best tasting brand (according to the US friend I was staying with) tasted worse than average belgian chocolate.
I guess the US chocolate manufacturers went for profit at the expense of quality.
beter than expected? Isn't MS-ie7 now part of the standard MS windows update system and has been for a couple of months now? I doubt it is optional so I'm surprised it's not a higher number.
IE is used most often in corporate settings, where the normal automatic updates system isn't used.
Subversion also counts as a daily backup, but at work we have a policy that you only check in working code (with reason), so daily checkins aren't realistic in some cases. I could work on a branch of course, but I don't see enough benefit in using a branch versus simply making local backups of my dev folder at the end of the day.
Anyway, at the time of the events I was a poor student, subversion didn't exist, and we couldn't install cvs on the server in question, nor did we have any spare server to install it on. The only backups we could make were to floppy, and we kind of got lazy with those.
Ah, the fun of wiping away a week's worth of code of an entire team just by a misguided "rm * .bkp" right before the day's end. They were surprisingly placid about it.
Ever since I take daily backups of anything I'm working on. Good habits are learned through pain.