This is very much in violation of the spirit of Open Source, on which Google relies for its entire existence.
Actually, even holding back the development repository and just doing periodic code drops is a violation of community spirit at the very least, and probably harmful to the pace of ongoing development as well. It is clear that Google still does not "get" open source.
That should be: However, the Samba team has moved active development of the project to the more strict GPLv3 license, which prevents Apple from using the software commercially in the way they want to use it.
The way I read it is "prevents Apple from being as evil as they want to". Well, if they want to provide an inferior CIFS implementation on their products out of spite I say, let them. It's their parade.
Apple astroturfers are out and about? It's getting harder and harder to tell your tactics apart from Microsoft's.
That should be: However, the Samba team has moved active development of the project to the more strict GPLv3 license, which prevents Apple from using the software commercially in the way they want to use it.
The way I read it is "prevents Apple from being as evil as they want to". Well, if they want to provide an inferior CIFS implementation on their products out of spite I say, let them. It's their parade.
...the Samba team has moved active development of the project to the more strict GPLv3 license, which prevents Apple from using the software commercially.
Complete and utter rubbish. Who got this wrong, Apple or the submitter?
...since they actually bothered to LEARN such things as manual memory management and pointers (which really are not THAT hard of subjects despite protestations to the contrary) they have fewer and fewer issues with such.
But never zero, and the few issues that slip through tend to be doozies. BTW, if you think that memory management is an easy subject then you have not yet scratched the surface of it.
Java is immensely easier to develop with than any flavor of C because of garbage collection and lack of pointers. If you do not understand why then please do not come anywhere near my C code.
Funny, I find any flavor of C immensely easier to develop responsive applications due to pointers and the lack of garbage collection. I get the impression I don't want to see your C code.
Maybe you should consider getting into the habit of reading past the first sentence of a post. For your convenience and reading pleasure, here it is:
That said, I personally prefer to put in the extra work and develop in C++ because the result usually starts faster and performs better.
And you are not welcome to come near my C code either because an effective developer must not only possess the requisite skills and understanding, but be socially functional as well.
Java is immensely easier to develop with than any flavor of C because of garbage collection and lack of pointers. If you do not understand why then please do not come anywhere near my C code.
That said, I personally prefer to put in the extra work and develop in C++ because the result usually starts faster and performs better. And I absolutely detest JNI.
I agree that lately they have been dragging behind in most features, especially tab management.
Actually, Chromium's tab management still sucks a lot, surprising for how much effort has been put into this project. Why do new tabs open on the extreme right whereas "open link in tab" opens conveniently right next to current tab? Why can I highlight a piece of text then right click to search for it but not open it as a tab? Why do new tabs open to the right of the source tab so that unnatural and inconsistent things have to be done to return you to the tab you started on close? Why don't tabs become scrollable after reaching a certain limit instead of becoming tiny and having all the icons disappear?
The main reason I run Firefox as my principal browser is "Bookmark all tabs" which Chromium inexplicably does not have. As a result, I only use Chromium for "throwaway browsing", not web research or anything that might generate links I want to keep.
It's working just fine. Look at the price earnings, well below 11. This represents investors sending a message loud and clear: Microsoft's future earnings growth is expected to be flat. Negative is more like it. There is only so long that enterprise clients will continue to pay a stupidity tax by spending hundreds of dollars a seat every few years on Microsoft office products for unexciting bugware that can't even manage to stay compatible with itself. It's not that those stupid clients will get any smarter, they will just start biting on the new shiny things, which are cloud computing, Apple and Android. And it would be wrong to underestimate the damage that Openoffice (now Libreoffice) has already done and will continue to do in the future.
So maybe it is better this way, just let the courts sort it all out so that then either Linux developers can pay some RAND license and never have to deal with whatever the patents cover again, find a way around it even it if doesn't work as well like Theora, or just throw out everything that is covered and find new ways of doing it.
I think we will be more likely to redouble our efforts to tear down Microsoft for good. Seems to be working out pretty well so far.
You know, there are two licensing-related problems Google is facing now with Android: the Oracle lawsuit, and now this.
There is no connection between these whatsoever. Oracle is entirely at fault in launching is Java suit, which is stupid and self defeating beyond imagination even for a loose cannon like Ellison.
On the other hand, Google is stupid for not moving faster to support fully native applications on Android. So there is stupidity on both sides of the fence on this one, but evil is only on one side.
So what if it's an ex-Microsoft hand pointing it out? He still seems to be correct.. Even if he would have something in mind when pointing it out, it doesn't change the fact.
True, and if the ex-Microsoft exaggerates the issue then it is still a troll. Note that the best trolls always contain some grain of truth. I finally got around to reading the brownrudnick whitepaper-looking-thingy on this issue. It smacks of troll. It fails to convince me that Google's kernel header sanitizing process is different in nature from what is done to create libc kernel headers, without which userspace applications would have a tough time interfacing to the kernel.
On the other hand, I am convinced that Google did itself and our community a disservice by failing to do the obvious thing and consult with the kernel community on this question beforehand. Simply posting a link to the sanitized kernel headers to lkml would have done wonders. Google displays more than a small amount of arrogance in its handling of this and other important community issues. I do not think that is a good idea.
Try connecting a full HD monitor to an integrated Intel GPU and you'll see what I meant.
I have a machine set up that way right now, with a pathetic 945 chipset driving a 1920 x 1600 display at full resolution. It's amazing how much 3D framerate I can coax out of it, provided I stick to what works nicely in its fixed function pipeline. That was my 3D development box for years. We are talking Pentium M here. A Zacate chip consuming significantly less power will blow that right out of the water.
IIRC, AMD's Zacate fusion chips have 80 stream processors, same as the 4350 I normally develop for (because it is fanless and quiet). The GPU is connected to the CPU by a bus with (I think this is right) 2 ns latency, put that in your pipe at smoke it.
The writing is very clearly on the wall for integrated vs discrete.
Slashdot Mirror
This is very much in violation of the spirit of Open Source, on which Google relies for its entire existence.
Actually, even holding back the development repository and just doing periodic code drops is a violation of community spirit at the very least, and probably harmful to the pace of ongoing development as well. It is clear that Google still does not "get" open source.
But the real brains behind applications are in the specifications not the lines of code.
If you think that then you are welcome to rewrite everything from scratch, and debug it.
That should be: However, the Samba team has moved active development of the project to the more strict GPLv3 license, which prevents Apple from using the software commercially in the way they want to use it.
The way I read it is "prevents Apple from being as evil as they want to". Well, if they want to provide an inferior CIFS implementation on their products out of spite I say, let them. It's their parade.
Apple astroturfers are out and about? It's getting harder and harder to tell your tactics apart from Microsoft's.
That should be: However, the Samba team has moved active development of the project to the more strict GPLv3 license, which prevents Apple from using the software commercially in the way they want to use it.
The way I read it is "prevents Apple from being as evil as they want to". Well, if they want to provide an inferior CIFS implementation on their products out of spite I say, let them. It's their parade.
...the Samba team has moved active development of the project to the more strict GPLv3 license, which prevents Apple from using the software commercially.
Complete and utter rubbish. Who got this wrong, Apple or the submitter?
...since they actually bothered to LEARN such things as manual memory management and pointers (which really are not THAT hard of subjects despite protestations to the contrary) they have fewer and fewer issues with such.
But never zero, and the few issues that slip through tend to be doozies. BTW, if you think that memory management is an easy subject then you have not yet scratched the surface of it.
I assume that you have never worked with file handles or network sockets.
Heh, good one.
You're running my code every day most probably.
Java is immensely easier to develop with than any flavor of C because of garbage collection and lack of pointers. If you do not understand why then please do not come anywhere near my C code.
Funny, I find any flavor of C immensely easier to develop responsive applications due to pointers and the lack of garbage collection. I get the impression I don't want to see your C code.
Maybe you should consider getting into the habit of reading past the first sentence of a post. For your convenience and reading pleasure, here it is:
That said, I personally prefer to put in the extra work and develop in C++ because the result usually starts faster and performs better.
And you are not welcome to come near my C code either because an effective developer must not only possess the requisite skills and understanding, but be socially functional as well.
Java is immensely easier to develop with than any flavor of C because of garbage collection and lack of pointers. If you do not understand why then please do not come anywhere near my C code.
That said, I personally prefer to put in the extra work and develop in C++ because the result usually starts faster and performs better. And I absolutely detest JNI.
I agree that lately they have been dragging behind in most features, especially tab management.
Actually, Chromium's tab management still sucks a lot, surprising for how much effort has been put into this project. Why do new tabs open on the extreme right whereas "open link in tab" opens conveniently right next to current tab? Why can I highlight a piece of text then right click to search for it but not open it as a tab? Why do new tabs open to the right of the source tab so that unnatural and inconsistent things have to be done to return you to the tab you started on close? Why don't tabs become scrollable after reaching a certain limit instead of becoming tiny and having all the icons disappear?
The main reason I run Firefox as my principal browser is "Bookmark all tabs" which Chromium inexplicably does not have. As a result, I only use Chromium for "throwaway browsing", not web research or anything that might generate links I want to keep.
It's working just fine. Look at the price earnings, well below 11. This represents investors sending a message loud and clear: Microsoft's future earnings growth is expected to be flat. Negative is more like it. There is only so long that enterprise clients will continue to pay a stupidity tax by spending hundreds of dollars a seat every few years on Microsoft office products for unexciting bugware that can't even manage to stay compatible with itself. It's not that those stupid clients will get any smarter, they will just start biting on the new shiny things, which are cloud computing, Apple and Android. And it would be wrong to underestimate the damage that Openoffice (now Libreoffice) has already done and will continue to do in the future.
Basically, Microsoft is doomed.
Because those who can, do. Those who can't, litigate.
I doubt that Ballmer is even very good at litigating. One thing is for sure: by attacking Google directly, Ballmer is punching out of his class.
So maybe it is better this way, just let the courts sort it all out so that then either Linux developers can pay some RAND license and never have to deal with whatever the patents cover again, find a way around it even it if doesn't work as well like Theora, or just throw out everything that is covered and find new ways of doing it.
I think we will be more likely to redouble our efforts to tear down Microsoft for good. Seems to be working out pretty well so far.
Not Microsoft's Fault
Nothing is ever Microsoft's fault, according to Microsoft.
That's exactly what I thought until I tried it (a friend of mine has one). It can't be fully appreciated from screenshots.
I'd be embarrassed to pull a phone out of my pocket and have it look like that.
The interface looks seriously goofy. What is it, 8 bit square two thumbs sized buttons on the whole screen? Ugly at best.
As far as I am concerned, ZTE is exhibiting amazingly good taste.
On the face of it you are a complete moron.
Wouldn't microseconds be more relevant?
You know, there are two licensing-related problems Google is facing now with Android: the Oracle lawsuit, and now this.
There is no connection between these whatsoever. Oracle is entirely at fault in launching is Java suit, which is stupid and self defeating beyond imagination even for a loose cannon like Ellison.
On the other hand, Google is stupid for not moving faster to support fully native applications on Android. So there is stupidity on both sides of the fence on this one, but evil is only on one side.
So what if it's an ex-Microsoft hand pointing it out? He still seems to be correct.. Even if he would have something in mind when pointing it out, it doesn't change the fact.
True, and if the ex-Microsoft exaggerates the issue then it is still a troll. Note that the best trolls always contain some grain of truth. I finally got around to reading the brownrudnick whitepaper-looking-thingy on this issue. It smacks of troll. It fails to convince me that Google's kernel header sanitizing process is different in nature from what is done to create libc kernel headers, without which userspace applications would have a tough time interfacing to the kernel.
On the other hand, I am convinced that Google did itself and our community a disservice by failing to do the obvious thing and consult with the kernel community on this question beforehand. Simply posting a link to the sanitized kernel headers to lkml would have done wonders. Google displays more than a small amount of arrogance in its handling of this and other important community issues. I do not think that is a good idea.
Try connecting a full HD monitor to an integrated Intel GPU and you'll see what I meant.
I have a machine set up that way right now, with a pathetic 945 chipset driving a 1920 x 1600 display at full resolution. It's amazing how much 3D framerate I can coax out of it, provided I stick to what works nicely in its fixed function pipeline. That was my 3D development box for years. We are talking Pentium M here. A Zacate chip consuming significantly less power will blow that right out of the water.
IIRC, AMD's Zacate fusion chips have 80 stream processors, same as the 4350 I normally develop for (because it is fanless and quiet). The GPU is connected to the CPU by a bus with (I think this is right) 2 ns latency, put that in your pipe at smoke it.
The writing is very clearly on the wall for integrated vs discrete.