The thing you could do to help would be to talk to your colleagues at Mozilla, and get them to reverse the decision they made. Primarily, make it so we in the Enterprise world can have long term security patches to Firefox separately to API breakage.
I am trying to do just that. There are many people in Mozilla that think we need a long term support version (like Ubuntu) that would be enterprise-friendly. Hopefully we'll succeed. Btw, a lot of debate about this is going on at the mozilla.dev.planning mailing list which is of course public - so you don't need to be a Firefox dev to make the case for an enterprise version.
If we don't, there will at least be some third-party enterprise versions of Firefox out there. For Linux there has always been Red Hat, and there is at least one company (I forgot it's name) about to launch a product for all OSes. But again, I agree it would be better if Mozilla did it.
I don't think I have ever been arrogant about Firefox. I feel the opposite actually - typical neurotic geek over here. So it's hard for me to understand what you mean: I think it's a humbling experience to be a dev in a big open source project like Firefox, I keep trying to do my best to improve the product so users like you will like it. When that doesn't happen, it makes me sad and I doubt myself. So I don't know why you think Firefox devs are arrogant - I feel exactly the opposite.
Again, sorry that you are so upset about this. I wish I could do something to help.
I agree a corporate-friendly version is important. It's a lot of time and effort, though - Red Hat does it well, but then that is exactly Red Hat's prime mission, supporting a rock-solid OS for a long time. It might be possible for Mozilla too, but it would be a lot of effort, which worries me.
I'm not too worried about IE cornering the enterprise market, though. For one thing Apple laptops are getting very popular there. Also enterprise users are starting to do more and more browsing from smartphones and tablets. And Google is pushing Chromebooks into that market (but I have no idea if they will succeed). So overall I still think Mozilla should do more for enterprises, but regardless IE will not dominate that market more than it already does, banks will want people to be able to visit them from iPads and Android phones and MacBooks.
What's important is to have LTS release for the enterprise.
Like FF4, FF8 could be LTS. LTS means security fixes. Also have MSI packages for those lazy admins that can't create one themselves.
That's mostly all that is needed and just need ONE guy at Mozilla, not even full time, to please the internet and enterprise.
I agree 100% that Firefox should have an LTS release. Also that we need MSI packages. However, I want to clarify that it would be a lot more than one person can do: It is a lot of work to maintain a stable release, you need lots of QA for every update and for every single OS it will run on. You also need support from other parts of the organization, from build infrastructure to technical documentation. Overall it is a significant effort to really do it seriously and properly.
I am less sure how hard it is to make MSI packages, I don't run Windows and never used that stuff myself.
There are downsides to naming it FF8 and downsides to naming it FF4.5. For example, calling it FF4.5 might lead people to assume there are no API changes (point releases often mean just that). But Chrome and Firefox do change APIs and functionality with their 6-week updates. So it is technically more correct for both of those browsers to bump the major version number each time - even though it does feel odd, and I admit it annoys me personally (but I am slowly getting used to it).
I am not sure what you mean by memory stuff being tied to new UI features? Generally those things are independent, yeah - has someone said otherwise?
No reason, but it wouldn't solve much either. Whether we called 5 something like 4.1, doesn't affect the fact that 5/4.1 does have some incompatibilities with 4.0 (new APIs, deprecated APIs, bugfixes to existing APIs, etc.). So calling it 4.1 would not have solved the real issue, and would have potentially made things worse by making some addons think they would work when they won't (but it would have made some addons work that currently don't, that's true).
Personally I am not a fan of the major number bump every 6 weeks. Just because I am used to other ways of numbering releases. But, I do understand the reasoning for it: To be consistent with Chrome, which already does that, and to be clear that these 6-week updates do change APIs and functionality, which they do (I assume that's why Chrome started with it in the first place).
The problem is that Chrome and Firefox 6-week updates can and do change functionality and break internal APIs. Regardless of whether those browsers raise the major version number, addons can break.
Chrome deals with this by having a limited addon API that does remain stable. This limits what addons you can write for Chrome, but it does make 80% of addons possible and with less upgrade hassle.
Firefox is moving to allow that approach with the jetpack SDK. However addons that don't use that SDK are relying on internal Firefox APIs, and the power and flexibility that that gives does mean they are at risk for breaking. Note that Mozilla's addons website will automatically check the code of addons hosted on it for actual API incompatibilities, and auto-mark as compatible addons that are not at risk. So a lot of addons 'just work' because of that. But still, some addons do rely on changing APIs, and some addons are not hosted on addons.mozilla.org, so the authors need to manually update them.
I can understand companies not being in touch with their customers, but does Mozilla not even read tech sites like Slashdot? Every story about Firefox lately is filled with exactly how negatively people feel about this version number fiasco.
Chrome was able to get away with bumping version numbers because it was a very new product and nobody was depending on it yet. Even though they removed the "beta" tag surprisingly early on (for a Google product), I think many people STILL consider Chome as "beta".
On the other hand large corporate type applications were just beginning to support Firefox and depended on long term support of major versions. Well, that has just been stomped in the face. Sadly, from a corporate stand point the only browser that really seems stable, viable, and "corporate friendly" now is IE.
Hi, I'm a Firefox dev. Yes, we read Slashdot:)
There is a big tradeoff here, with downsides both ways. You correctly point out that some people are having problems with the new fast release schedule. That's a fact, and we are doing all we can, but the problems are hard (addons, enterprise users, etc.).
On the other hand, the alternative is to continue with a slow release schedule, which we feel has bigger problems and would annoy more users. For example, FF8 will have much better memory usage than Firefox 4. Releasing new versions quickly lets users get that benefit quicker - fewer users will have memory problems because we ship the fixes faster. As another example, when IE9 and FF4 came out, at roughly the same time, they had comparable performance on some canvas benchmarks (in which they outperformed all other browsers due to their being the only browsers to use Direct2D). Meanwhile Firefox has released twice (counting FF6 on next Tuesday), and as a consequence, Firefox users have better performance than IE users, simply because IE users are still on IE9 while Firefox users can run FF5 and FF6 which include a lot more performance improvements that were committed after FF4.
Another major issue is new web standards. For standards to evolve quickly, browsers need to ship new versions with new implementations of those standards. Firefox and Chrome are now leading that, by releasing every 6 weeks. As one example, both support the new (safe) version of web sockets. That pushes the web forward, letting developers use it quicker, and eventually let all of us benefit from those new features. Chrome began this push, and I think Google was right to do it, and Firefox is joining that.
Is the new release schedule perfect? Of course not. It has problems for both browsers doing it, Chrome and Firefox. Both are probably not seen very favorably among enterprise users. And Firefox has some additional challenges, what with transitioning a previous release schedule to this one. But still, both Chrome and Firefox feel it is worthwhile. So again, I realize that there are problems. But overall I think the fast release schedule of Chrome and Firefox is a good thing.
If your code does this:
a = alloca(4)
b = alloca(4)
[..]
d = load64(a)
Then the results there will depend on the endianness of the platform. And if that alloca wasn't 64-bit aligned, it might fail on some platforms, etc. It's very difficult to generate a fast, low-level assembly that doesn't limit you. That's why LLVM doesn't even try. Whether PNaCl will succeed is a big questions.
Yes. But what if the arch you are on is 64-bit big endian? And it does 32-bit loads/stores slowly - or even faults on lack of 64-bit alignment? You have a LOT of challenges in even running that 32-bit little endian code there at all, let alone fast.
If you don't like the FF UI design choices, that's your opinion, and you are entitled to it. But why the anger? Plenty of other people do like those choices, and they are entitled to their opinion too.
Me, I don't care. I only care that my browser is 100% open source regardless of UI (well, within reason. But so far nothing every truly annoyed me).
I suppose it's no surprise to anyone who's been paying attention to Firefox development for the past several years, but for fuck's sake, listen to your users and stop with the version number inflation!
A few stories under this is a story about Chrome 14. I am sure the comments there are saying the same thing. But can we move on already?
Yes, Chrome and Firefox release a major version every 6 weeks. Chrome and Firefox raise the major version number every such time. And here on Slashdot people complain about those browsers doing it. But the vast majority of Chrome and Firefox users just use the browser, and don't care.
If you don't like what Chrome and Firefox are doing, feel free to use another browser. Opera is good too.
Can you skip version 6, or are they going to pull another asshole "Firefox 5 is EOLed because v6 is out" like they did to Firefox 4?
Chrome and Firefox only support a single stable version at a time. Every time a new version of Chrome or Firefox comes out, future security fixes apply only to that version - there are no further updates to previous versions.
So you can skip a version of Chrome or Firefox, but you will be running a browser that isn't getting security updates. It would just be for 6 weeks, but I wouldn't risk it.
If you don't like that, your other options are the slower release schedules of IE, Opera and Safari.
Actually for both of those cases, a lot of the intensive stuff would end up being in a shader on the GPU anyhow, so it would be fine in JS (using WebGL). But there are other things, like AI or physics, that is true, which are more problematic. NaCl might not be a solution for them though - it's sandboxing introduces overhead.
NaCl is not, in my view, a replacement for JavaScript, its a tool for certain purposes for which JavaScript is problematic (one might be re-use of substantial legacy code bases that aren't in JavaScript
You definitely do not need NaCl for that. emscripten lets you compile C or C++ into JavaScript (see the demos in that link for examples). There are similar projects for other languages (but C/C++ is the most important case, since you can even compile the C code of CPython and run Python on the web using that).
For now; though with NaCl now in a non-dev version of Chrome (its been in dev versions since 7 or so, I think) that probably means that there is going to be more focus on getting PNaCl (Portable Native Client) ready for public consumption, which will see code deployed on the web as LLVM bitcode and compiled to native code at the client, at which point you'll have real portability.
It is still not clear how much portability PNaCl will give, and at what performance cost.
Let's say that it supports x86, x86_64 and ARM. Is that enough? I would argue not, because it puts a big limitation on what future architectures can look like - because LLVM bitcode is not truly portable, it still encodes many assumptions about current architectures.
Of course JavaScript does as well - everything does. But JavaScript has far fewer such assumptions, making it much easier for someone to invent a new CPU and have it run the web well. With NaCl, we might lose that.
The argument is that NaCl is needed because otherwise performance will suck. But JavaScript is already almost as fast as languages like Java and C#, which are considered 'fast enough'.
First, I've already admitted this was the wrong use in terminology (see above), and you are absolutely right.
As to this patent being absurdly generic, I disagree. If it is so generic, then why haven't you, or anyone else (according to the patent office search) invented/implemented/patented this product, using each and every step/element of the claims in this patent. To that point, would you have done that before 2007, which is when this was filed? Remember, only PRIOR art, i.e. that which existed before 2007, is what matters.
It may be bogus in your view, but technically, it is not.
I am not sure if you are kidding or not. Do you really think something is not obvious if it isn't already patented? The vast, vast majority of ideas are too trivial to be worth a patent, so they aren't already patented. This is one such idea.
Looking at the actual patent, what they're doing is figuring out based on historical delivery information a more accurate estimated time of day for the delivery and sending an email to the recipient with that information *on the day of delivery*.
Basically it saves the recipient having to constantly check the tracking page for the courier.
Not earthshaking, but more than is currently offered.
I looked at the actual patent and I don't think you can be more wrong. Do you seriously believe that is novel and patentworthy? It's an obvious idea. Should Google be given a monopoly on it simply because they wrote it down and paid the filing fee for the patent office?
We should blast Google for patenting something this obvious, just like we would have blasted Microsoft or Apple for doing so.
The point is that Google has a novel idea here, and has defined it as such. [..] To infringe a patent, one has to infringe on all claims. While some claims may be obvious, it is the (sometimes few) non-obvious ones that actually matter. Google has provided some of those non-obvious, novel claims (at least it appears to have) and it seems to have a valid patent.
No, you need to infringe at least 1 of the claims. Not all of them. (You do need to infringe on all the elements in a single claim, though.)
Claim #1 here is absurdly generic. This is yet another example of the patent office granting a ridiculously obvious patent.
So then how is your comment modded to +5 informative? Can it be that here on Slashdot we are so pro-Google that we praise them for filing and receiving bogus patents? Please tell me it hasn't really come to that!
90 comments so far, and none of the top ones are bashing Google for Chrome's new version number. Have we finally moved past bashing Chrome and Firefox for increasing the major version number every 6 weeks? Please let it be so:)
During the Shinkansen's 45-year, nearly 7 billion-passenger history, there have been no passenger fatalities due to derailments or collisions,[13] despite frequent earthquakes and typhoons.
This is obviously a big tragedy, many lives were lost. But it's hard not to see something symbolic in this as well - China's economy moving forward too fast, ignoring safety warnings, and ending in catastrophe. That last part hasn't happened yet, but the first has, and more and more people are starting to worry about some sort of bust. Hopefully that won't happen, but if it does, this train derailment may end up as a metaphor in the history books.
I'm not sure I understand. Prism still exists, and it sounds like what you want, so I don't understand why you say it "turned into Chromeless."
I think he meant this announcement, that focus is shifting from Prism to Chromeless.
But, OP is wrong about "[Chromeless] seems to have died [Note: last update was May 31]" - yes, the last blogpost was May 31, but the last source code commit on github was less than a month ago. That doesn't sound 'dead' to me.
So Chromeless sounds like the way to go here, for what OP is looking for.
Whether or not you think Mono has value, granting a perpetual license to it to someone who will do something with it was the right thing to do.
Just to clarify, this isn't a free perpetual license, it's a partnership. Attachmate is getting something in return, I presume a percentage of revenue.
Not that there's anything wrong with that. But the headline makes it sound like Attachmate is doing this to be fair or nice. This is just business. But it does make perfect sense for everyone involved.
I am not sure why you think Flash is a reason Mozilla doesn't officially support 64-bit builds.
I don't think Flash has much to do with that. The issue, as I said, is that it is already a lot of work for us to QA 32-bit builds. QAing 64-bit builds as well would be double the work. I realize it might not sound that way, but in practice you do need to run the entire set of automatic and manual tests on every build, even if the difference is just 32 vs 64 bit.
Mozilla has limited resources, and we have to make choices what to spend time on.
Slashdot Mirror
The thing you could do to help would be to talk to your colleagues at Mozilla, and get them to reverse the decision they made. Primarily, make it so we in the Enterprise world can have long term security patches to Firefox separately to API breakage.
I am trying to do just that. There are many people in Mozilla that think we need a long term support version (like Ubuntu) that would be enterprise-friendly. Hopefully we'll succeed. Btw, a lot of debate about this is going on at the mozilla.dev.planning mailing list which is of course public - so you don't need to be a Firefox dev to make the case for an enterprise version.
If we don't, there will at least be some third-party enterprise versions of Firefox out there. For Linux there has always been Red Hat, and there is at least one company (I forgot it's name) about to launch a product for all OSes. But again, I agree it would be better if Mozilla did it.
I'm sorry you are so upset about this.
I don't think I have ever been arrogant about Firefox. I feel the opposite actually - typical neurotic geek over here. So it's hard for me to understand what you mean: I think it's a humbling experience to be a dev in a big open source project like Firefox, I keep trying to do my best to improve the product so users like you will like it. When that doesn't happen, it makes me sad and I doubt myself. So I don't know why you think Firefox devs are arrogant - I feel exactly the opposite.
Again, sorry that you are so upset about this. I wish I could do something to help.
I agree a corporate-friendly version is important. It's a lot of time and effort, though - Red Hat does it well, but then that is exactly Red Hat's prime mission, supporting a rock-solid OS for a long time. It might be possible for Mozilla too, but it would be a lot of effort, which worries me.
I'm not too worried about IE cornering the enterprise market, though. For one thing Apple laptops are getting very popular there. Also enterprise users are starting to do more and more browsing from smartphones and tablets. And Google is pushing Chromebooks into that market (but I have no idea if they will succeed). So overall I still think Mozilla should do more for enterprises, but regardless IE will not dominate that market more than it already does, banks will want people to be able to visit them from iPads and Android phones and MacBooks.
What's important is to have LTS release for the enterprise. Like FF4, FF8 could be LTS. LTS means security fixes. Also have MSI packages for those lazy admins that can't create one themselves. That's mostly all that is needed and just need ONE guy at Mozilla, not even full time, to please the internet and enterprise.
I agree 100% that Firefox should have an LTS release. Also that we need MSI packages. However, I want to clarify that it would be a lot more than one person can do: It is a lot of work to maintain a stable release, you need lots of QA for every update and for every single OS it will run on. You also need support from other parts of the organization, from build infrastructure to technical documentation. Overall it is a significant effort to really do it seriously and properly.
I am less sure how hard it is to make MSI packages, I don't run Windows and never used that stuff myself.
There are downsides to naming it FF8 and downsides to naming it FF4.5. For example, calling it FF4.5 might lead people to assume there are no API changes (point releases often mean just that). But Chrome and Firefox do change APIs and functionality with their 6-week updates. So it is technically more correct for both of those browsers to bump the major version number each time - even though it does feel odd, and I admit it annoys me personally (but I am slowly getting used to it).
I am not sure what you mean by memory stuff being tied to new UI features? Generally those things are independent, yeah - has someone said otherwise?
No reason, but it wouldn't solve much either. Whether we called 5 something like 4.1, doesn't affect the fact that 5/4.1 does have some incompatibilities with 4.0 (new APIs, deprecated APIs, bugfixes to existing APIs, etc.). So calling it 4.1 would not have solved the real issue, and would have potentially made things worse by making some addons think they would work when they won't (but it would have made some addons work that currently don't, that's true).
Personally I am not a fan of the major number bump every 6 weeks. Just because I am used to other ways of numbering releases. But, I do understand the reasoning for it: To be consistent with Chrome, which already does that, and to be clear that these 6-week updates do change APIs and functionality, which they do (I assume that's why Chrome started with it in the first place).
The problem is that Chrome and Firefox 6-week updates can and do change functionality and break internal APIs. Regardless of whether those browsers raise the major version number, addons can break.
Chrome deals with this by having a limited addon API that does remain stable. This limits what addons you can write for Chrome, but it does make 80% of addons possible and with less upgrade hassle.
Firefox is moving to allow that approach with the jetpack SDK. However addons that don't use that SDK are relying on internal Firefox APIs, and the power and flexibility that that gives does mean they are at risk for breaking. Note that Mozilla's addons website will automatically check the code of addons hosted on it for actual API incompatibilities, and auto-mark as compatible addons that are not at risk. So a lot of addons 'just work' because of that. But still, some addons do rely on changing APIs, and some addons are not hosted on addons.mozilla.org, so the authors need to manually update them.
I can understand companies not being in touch with their customers, but does Mozilla not even read tech sites like Slashdot? Every story about Firefox lately is filled with exactly how negatively people feel about this version number fiasco.
Chrome was able to get away with bumping version numbers because it was a very new product and nobody was depending on it yet. Even though they removed the "beta" tag surprisingly early on (for a Google product), I think many people STILL consider Chome as "beta".
On the other hand large corporate type applications were just beginning to support Firefox and depended on long term support of major versions. Well, that has just been stomped in the face. Sadly, from a corporate stand point the only browser that really seems stable, viable, and "corporate friendly" now is IE.
Hi, I'm a Firefox dev. Yes, we read Slashdot :)
There is a big tradeoff here, with downsides both ways. You correctly point out that some people are having problems with the new fast release schedule. That's a fact, and we are doing all we can, but the problems are hard (addons, enterprise users, etc.).
On the other hand, the alternative is to continue with a slow release schedule, which we feel has bigger problems and would annoy more users. For example, FF8 will have much better memory usage than Firefox 4. Releasing new versions quickly lets users get that benefit quicker - fewer users will have memory problems because we ship the fixes faster. As another example, when IE9 and FF4 came out, at roughly the same time, they had comparable performance on some canvas benchmarks (in which they outperformed all other browsers due to their being the only browsers to use Direct2D). Meanwhile Firefox has released twice (counting FF6 on next Tuesday), and as a consequence, Firefox users have better performance than IE users, simply because IE users are still on IE9 while Firefox users can run FF5 and FF6 which include a lot more performance improvements that were committed after FF4.
Another major issue is new web standards. For standards to evolve quickly, browsers need to ship new versions with new implementations of those standards. Firefox and Chrome are now leading that, by releasing every 6 weeks. As one example, both support the new (safe) version of web sockets. That pushes the web forward, letting developers use it quicker, and eventually let all of us benefit from those new features. Chrome began this push, and I think Google was right to do it, and Firefox is joining that.
Is the new release schedule perfect? Of course not. It has problems for both browsers doing it, Chrome and Firefox. Both are probably not seen very favorably among enterprise users. And Firefox has some additional challenges, what with transitioning a previous release schedule to this one. But still, both Chrome and Firefox feel it is worthwhile. So again, I realize that there are problems. But overall I think the fast release schedule of Chrome and Firefox is a good thing.
If your code does this: a = alloca(4) b = alloca(4) [..] d = load64(a) Then the results there will depend on the endianness of the platform. And if that alloca wasn't 64-bit aligned, it might fail on some platforms, etc. It's very difficult to generate a fast, low-level assembly that doesn't limit you. That's why LLVM doesn't even try. Whether PNaCl will succeed is a big questions.
Game consoles are also big-endian last I heard.
Yes. But what if the arch you are on is 64-bit big endian? And it does 32-bit loads/stores slowly - or even faults on lack of 64-bit alignment? You have a LOT of challenges in even running that 32-bit little endian code there at all, let alone fast.
If you don't like the FF UI design choices, that's your opinion, and you are entitled to it. But why the anger? Plenty of other people do like those choices, and they are entitled to their opinion too.
Me, I don't care. I only care that my browser is 100% open source regardless of UI (well, within reason. But so far nothing every truly annoyed me).
I suppose it's no surprise to anyone who's been paying attention to Firefox development for the past several years, but for fuck's sake, listen to your users and stop with the version number inflation!
A few stories under this is a story about Chrome 14. I am sure the comments there are saying the same thing. But can we move on already?
Yes, Chrome and Firefox release a major version every 6 weeks. Chrome and Firefox raise the major version number every such time. And here on Slashdot people complain about those browsers doing it. But the vast majority of Chrome and Firefox users just use the browser, and don't care.
If you don't like what Chrome and Firefox are doing, feel free to use another browser. Opera is good too.
Can you skip version 6, or are they going to pull another asshole "Firefox 5 is EOLed because v6 is out" like they did to Firefox 4?
Chrome and Firefox only support a single stable version at a time. Every time a new version of Chrome or Firefox comes out, future security fixes apply only to that version - there are no further updates to previous versions.
So you can skip a version of Chrome or Firefox, but you will be running a browser that isn't getting security updates. It would just be for 6 weeks, but I wouldn't risk it.
If you don't like that, your other options are the slower release schedules of IE, Opera and Safari.
Java and C#, which are considered 'fast enough'.
Not for games or video processing.
Actually for both of those cases, a lot of the intensive stuff would end up being in a shader on the GPU anyhow, so it would be fine in JS (using WebGL). But there are other things, like AI or physics, that is true, which are more problematic. NaCl might not be a solution for them though - it's sandboxing introduces overhead.
NaCl is not, in my view, a replacement for JavaScript, its a tool for certain purposes for which JavaScript is problematic (one might be re-use of substantial legacy code bases that aren't in JavaScript
You definitely do not need NaCl for that. emscripten lets you compile C or C++ into JavaScript (see the demos in that link for examples). There are similar projects for other languages (but C/C++ is the most important case, since you can even compile the C code of CPython and run Python on the web using that).
For now; though with NaCl now in a non-dev version of Chrome (its been in dev versions since 7 or so, I think) that probably means that there is going to be more focus on getting PNaCl (Portable Native Client) ready for public consumption, which will see code deployed on the web as LLVM bitcode and compiled to native code at the client, at which point you'll have real portability.
It is still not clear how much portability PNaCl will give, and at what performance cost.
Let's say that it supports x86, x86_64 and ARM. Is that enough? I would argue not, because it puts a big limitation on what future architectures can look like - because LLVM bitcode is not truly portable, it still encodes many assumptions about current architectures.
Of course JavaScript does as well - everything does. But JavaScript has far fewer such assumptions, making it much easier for someone to invent a new CPU and have it run the web well. With NaCl, we might lose that.
The argument is that NaCl is needed because otherwise performance will suck. But JavaScript is already almost as fast as languages like Java and C#, which are considered 'fast enough'.
First, I've already admitted this was the wrong use in terminology (see above), and you are absolutely right.
As to this patent being absurdly generic, I disagree. If it is so generic, then why haven't you, or anyone else (according to the patent office search) invented/implemented/patented this product, using each and every step/element of the claims in this patent. To that point, would you have done that before 2007, which is when this was filed? Remember, only PRIOR art, i.e. that which existed before 2007, is what matters.
It may be bogus in your view, but technically, it is not.
I am not sure if you are kidding or not. Do you really think something is not obvious if it isn't already patented? The vast, vast majority of ideas are too trivial to be worth a patent, so they aren't already patented. This is one such idea.
Looking at the actual patent, what they're doing is figuring out based on historical delivery information a more accurate estimated time of day for the delivery and sending an email to the recipient with that information *on the day of delivery*.
Basically it saves the recipient having to constantly check the tracking page for the courier.
Not earthshaking, but more than is currently offered.
I looked at the actual patent and I don't think you can be more wrong. Do you seriously believe that is novel and patentworthy? It's an obvious idea. Should Google be given a monopoly on it simply because they wrote it down and paid the filing fee for the patent office?
We should blast Google for patenting something this obvious, just like we would have blasted Microsoft or Apple for doing so.
The point is that Google has a novel idea here, and has defined it as such. [..] To infringe a patent, one has to infringe on all claims. While some claims may be obvious, it is the (sometimes few) non-obvious ones that actually matter. Google has provided some of those non-obvious, novel claims (at least it appears to have) and it seems to have a valid patent.
No, you need to infringe at least 1 of the claims. Not all of them. (You do need to infringe on all the elements in a single claim, though.)
Claim #1 here is absurdly generic. This is yet another example of the patent office granting a ridiculously obvious patent.
So then how is your comment modded to +5 informative? Can it be that here on Slashdot we are so pro-Google that we praise them for filing and receiving bogus patents? Please tell me it hasn't really come to that!
While I appreciate this new print preview functionality, I am not impressed that:
This is what I mean: I would like to adjust margins on the fly as I can do with Firefox.
What I find more annoying about the new print preview is that it isn't open source. It is in Chrome but not Chromium.
90 comments so far, and none of the top ones are bashing Google for Chrome's new version number. Have we finally moved past bashing Chrome and Firefox for increasing the major version number every 6 weeks? Please let it be so :)
http://en.wikipedia.org/wiki/Shinkansen#Safety_record
Definitely a good comparison.
This is obviously a big tragedy, many lives were lost. But it's hard not to see something symbolic in this as well - China's economy moving forward too fast, ignoring safety warnings, and ending in catastrophe. That last part hasn't happened yet, but the first has, and more and more people are starting to worry about some sort of bust. Hopefully that won't happen, but if it does, this train derailment may end up as a metaphor in the history books.
I'm not sure I understand. Prism still exists, and it sounds like what you want, so I don't understand why you say it "turned into Chromeless."
I think he meant this announcement, that focus is shifting from Prism to Chromeless.
But, OP is wrong about "[Chromeless] seems to have died [Note: last update was May 31]" - yes, the last blogpost was May 31, but the last source code commit on github was less than a month ago. That doesn't sound 'dead' to me.
So Chromeless sounds like the way to go here, for what OP is looking for.
Whether or not you think Mono has value, granting a perpetual license to it to someone who will do something with it was the right thing to do.
Just to clarify, this isn't a free perpetual license, it's a partnership. Attachmate is getting something in return, I presume a percentage of revenue.
Not that there's anything wrong with that. But the headline makes it sound like Attachmate is doing this to be fair or nice. This is just business. But it does make perfect sense for everyone involved.
I am not sure why you think Flash is a reason Mozilla doesn't officially support 64-bit builds.
I don't think Flash has much to do with that. The issue, as I said, is that it is already a lot of work for us to QA 32-bit builds. QAing 64-bit builds as well would be double the work. I realize it might not sound that way, but in practice you do need to run the entire set of automatic and manual tests on every build, even if the difference is just 32 vs 64 bit.
Mozilla has limited resources, and we have to make choices what to spend time on.