That's complete bollocks. There's been pages and pages of complaints, arguing and what-not when Google was making the choice between Qt and GTK.
Those aren't users, they are geeks. My parents use Linux, and they can't even tell Qt and Gtk+ applications apart. Users don't care.
Right. If you even read the comments above yours, you'd know a lot of people care about the linux port of Chrome.
See above. Geeks care, users don't.
How are you modded informative and not troll?
Well, why don't you tell us what you think are the user-visible, defining characteristics of Chrome and then we'll see whether we can match them with Linux-native browsers.
I very, very much prefer any other browser on windows compared to firefox on linux. It feels faster, and, well, as much as i love linux, I cannot stand how it performs in a desktop role.
Firefox sucks on Linux because it's an adaptation of a Windows-centric browser.
When chrome started working on linux...it felt amazing. I didn't know a linux gui application could even be that responsive.
Well, then you haven't been looking very hard. There are plenty of highly responsive Linux GUI apps.
If you want a fast, native, integrated browser on Linux, use Epiphany or Midori.
I'm having trouble believing that the only problem here is that GTK is too awesome.
Who said anything about "awesome"? The point is that the Chrome team's problems are the result of their choices and deficiencies in Windows. Objectively, they have two decent C/C++ toolkits for Linux (Gtk+, Qt) that beat anything Microsoft is offering.
And instead of their serious case of "NIH", they should have simply used Gtk+ or Qt for implementing a cross-platform browser. In the unlikely event that that would have constrained their development, they could have contributed whatever changes were necessary back to Gtk+/Qt to improve those toolkits. That's what open source means.
What is really going on is that they have wrapped a new layout engine ("views") and other tools around the "impoverished" (their words) Windows toolkits. Then, they started depending on their wrapper for features they added to Chrome. Now, when porting to Linux, they are suddenly discovering that, geez, both Gtk+ and Qt already does what "views" is doing, they just do it differently and in a way that doesn't connect well with the rest of Chrome. That's what they are complaining about.
Ben Goodger, here's a hint: pick Gtk+ or Qt as your toolkit, Linux users really don't care that much. And both of them are much better toolkits than what Windows offers. I'm sorry that the completeness of Linux GUI toolkits inconveniences you, but, well, too bad.
Or, if you like, don't port to Linux; we don't really care all that much, since there are several great browsers on Linux already that pretty much do what Chrome does.
It's not "e-ink", which is an electrophoretic display, it's an LCD that can be run in two different modes: reflective and with backlight. When it's used with a backlight, the LCD elements are colored, and when used without, they are not colored. It's kind of a hack, but it's a useful hack. In terms of resolution, it doesn't actually help much, since you can do color antialiasing on a color LCD anyway. It's good for battery life, though.
The OLPC screens already work that way. I'm not sure what they are announcing. Maybe they just needed a press release.
The question I have is: when is there going to be an EEE PC with one of these screens? That would be really useful.
I haven't read the patent, but TFA makes it sound like it applies to any kind of "WYSIWYG" editing of a document that gets saved in a structured format, not only XML
Well, you should read it. The patent is on associating properties with text without embedding the formatting codes directly. Most XML formats don't do that.
It's about saying something like "in the text, make characters 17-21 bold face" separately from the text itself, instead of "{\bf hello}"
What the patent is about is associating formatting information with text by means other than embedding it. For example, instead of "<b>foo</b>" you separately store the instructions "foo" and "make 0-3 bold"; it calls this "content" and "meta-codes". It's a bad idea, most software doesn't do it, and there should really be plenty of prior art before 1994.
I believe the reason Microsoft steps on this patent is because of their XML format, which uses such nonsense. I don't see how ODF infringes; it doesn't use such separation of content and "meta-codes" but codes everything in-line.
I hope Android can meet them half way by making Android itself more compliant with Linux standards. Android is nice what it is, but it remains a very specialized platform. Interoperating better might be good for its acceptance as well.
unix has these interfaces as a matter of historical accident, what was an excellent design at the time.
No, UNIX has these interfaces because they get the job done. People tried all sorts of other interfaces and none of them caught on.
you might find that it helps to think about these thing..even when developing important, real-world applications.
How does it "help" me to think about solutions to problems I'm not having? I've never seen the socket interface to be rate limiting in anything I care about.
why shouldn't the kernel be able to call into userspace safely and transfer ownership of a buffer? is that really so terrible to consider?
Well, if that's your biggest itch, be my guest: implement a kernel patch, make it public, convince people to use it, and if it develops a large user community, maybe Linus will pick it up and it will become a standard part of the kernel.
If nobody is willing to put in the effort, evidently the feature isn't needed.
Not conforming to someone's pipe dream of kernel design is not a flaw. It's a flaw only if it demonstrably causes problems.
i'm not going to buy into the tablets brought down from the berkeley hills.
That's why they make all kinds. You're free to use Windows Vista; those people spend billions correcting supposed "structural flaws". Don't spoil UNIX or Linux for the rest of us. We like its "structural flaws" the way they are.
the most flexible and efficient thing would be to have memory for receive frames allocated at the bottom of the stack, and use callbacks all the way up.
Sure, in the same way that the "most flexible and efficient thing" would be to write inassembly language and turn off the MMU. But UNIX is not trying to do the most flexible and efficient thing, it's trying to be a reasonable tradeoff between simplicity, safety, and efficiency. And that means that efficiency only gets optimized to the point where it stops being a limiting factor for most programs.
even if its completely academic, i think its interesting to look at the user kernel boundary and try to refactor things which have negative structural impacts.
And you think that 2009 is the first time people think about this? System call overhead used to be a much bigger issue. UNIX and Linux has the current set of interfaces because they are a good compromise between simplicity and efficiency.
And these issues are constantly being evaluated implicitly: people who write network servers benchmark their code and find the bottlenecks. If the bottleneck is some system call, they complain to the kernel mailing list and maybe roll up their sleeves and come up with something new. If that turns out to be useful, more and more people ask for it to be put into the kernel, and eventually it becomes standard.
What motivates kernel developers is real benchmarks and the needs of important, real-world applications, not fluff pieces that express generic displeasure with the way things are done.
That's easy to fix without changing the socket API: just add a system call that can return multiple packets from multiple streams simultaneously, a cross between select and readv. If there's a lot of data buffered in the kernel, it can then return that with a single system call. The user mode socket library can use that system call internally and still present every caller with the regular select/poll/socket abstraction; when callers request data, it first returns data that's already buffered in the process without another system call, and when it runs out of that, then it calls back into the kernel.
Although the addition of a single system call to a loop would not seem to add much of a burden, this is not the case
Really? For a lot of networking code that's in use these days, I don't see that the system call overhead is the bottleneck. On clients you usually have network bandwidth as the limiting step (rather than system calls). On servers, it usually seems to be disk access or HLL interpreters.
Each system call requires arguments to be marshaled and copied into the kernel, as well as causing the system to block the calling process and schedule another.
That's easy to fix without changing the socket API: just add a system call that can return multiple packets from multiple streams simultaneously, a cross between select and readv. If there's a lot of data buffered in the kernel, it can then return that with a single system call.
Solving this problem requires inverting the communication model between an application and the operating system.
Not only does it not require that, inversion of control doesn't even solve it, since you still have the context switches.
On Ursula LeGuin's web site, you find the motto: "A book is just a box of words, until a reader opens it." It's kind of ironic that a writer who uses science fiction primarily to talk about social issues is so blind to social change and the social good that actually comes from being able to share information.
It's her choice to get upset, it's our choice not to read her. I vaguely recall that I found the few things I read by her to be long-winded and boring, and I'm certain not to bother correcting that impression now.
As far as I can tell, the people who call themselves "the creative industries" are mostly recycling folk tunes and Shakespearean stories, and that's on a good day. True creativity happens in other fields, like, oh, computers, engineering, and science.
Instead of all these ridiculous restrictions and rules, I have a better idea.
(1) Convict parents for the crimes committed by their underage children; parents are the legal guardians and should be fully responsible for what their children do. (Likewise, if their underage children are crime victims, convict the parents as well, since they obviously didn't supervise them carefully enough.)
(2) If someone commits a crime with your gun, you should be an accessory to the crime. It doesn't matter whether you stored it "properly"--if it got used in a crime, it probably wasn't stored well enough.
If one company has best medicine for certain problem, it should be chosen
Sure, it should be chose... to lose its patent protection.
I don't want to think about "What drug companies have shady history?
Well, but you have to think about it, because if the company cheated on the other drug, there's a good chance that the drug that you want to take also doesn't do what the company claims.
Also, I think you're greatly overestimating the differences between drugs. Most drugs that drug companies make are useless: there are either generic equivalents that are just as good, or they are lifestyle drugs--something you could fix with nutrition and exercise.
We've gone from a society of tinkerers where the best idea wins to an increasingly IP law based profit model that stiffles innovation.
Analog was really special that way, and it may not come back: open interfaces defined by physics, plus the ability to plug components together anyway you like.
The journalists aren't idiots, however: they are going to continue to trade stories and (un)favorable coverage for benefits, like access to the rich and powerful, power trips, and book deals.
If you think that journalists at commercial newspapers have your best interests at heart, or that they give you unbiased coverage, you're a fool.
Slashdot Mirror
That's complete bollocks. There's been pages and pages of complaints, arguing and what-not when Google was making the choice between Qt and GTK.
Those aren't users, they are geeks. My parents use Linux, and they can't even tell Qt and Gtk+ applications apart. Users don't care.
Right. If you even read the comments above yours, you'd know a lot of people care about the linux port of Chrome.
See above. Geeks care, users don't.
How are you modded informative and not troll?
Well, why don't you tell us what you think are the user-visible, defining characteristics of Chrome and then we'll see whether we can match them with Linux-native browsers.
I very, very much prefer any other browser on windows compared to firefox on linux. It feels faster, and, well, as much as i love linux, I cannot stand how it performs in a desktop role.
Firefox sucks on Linux because it's an adaptation of a Windows-centric browser.
When chrome started working on linux...it felt amazing. I didn't know a linux gui application could even be that responsive.
Well, then you haven't been looking very hard. There are plenty of highly responsive Linux GUI apps.
If you want a fast, native, integrated browser on Linux, use Epiphany or Midori.
I'm having trouble believing that the only problem here is that GTK is too awesome.
Who said anything about "awesome"? The point is that the Chrome team's problems are the result of their choices and deficiencies in Windows. Objectively, they have two decent C/C++ toolkits for Linux (Gtk+, Qt) that beat anything Microsoft is offering.
And instead of their serious case of "NIH", they should have simply used Gtk+ or Qt for implementing a cross-platform browser. In the unlikely event that that would have constrained their development, they could have contributed whatever changes were necessary back to Gtk+/Qt to improve those toolkits. That's what open source means.
What is really going on is that they have wrapped a new layout engine ("views") and other tools around the "impoverished" (their words) Windows toolkits. Then, they started depending on their wrapper for features they added to Chrome. Now, when porting to Linux, they are suddenly discovering that, geez, both Gtk+ and Qt already does what "views" is doing, they just do it differently and in a way that doesn't connect well with the rest of Chrome. That's what they are complaining about.
Ben Goodger, here's a hint: pick Gtk+ or Qt as your toolkit, Linux users really don't care that much. And both of them are much better toolkits than what Windows offers. I'm sorry that the completeness of Linux GUI toolkits inconveniences you, but, well, too bad.
Or, if you like, don't port to Linux; we don't really care all that much, since there are several great browsers on Linux already that pretty much do what Chrome does.
It's not "e-ink", which is an electrophoretic display, it's an LCD that can be run in two different modes: reflective and with backlight. When it's used with a backlight, the LCD elements are colored, and when used without, they are not colored. It's kind of a hack, but it's a useful hack. In terms of resolution, it doesn't actually help much, since you can do color antialiasing on a color LCD anyway. It's good for battery life, though.
The OLPC screens already work that way. I'm not sure what they are announcing. Maybe they just needed a press release.
The question I have is: when is there going to be an EEE PC with one of these screens? That would be really useful.
I haven't read the patent, but TFA makes it sound like it applies to any kind of "WYSIWYG" editing of a document that gets saved in a structured format, not only XML
Well, you should read it. The patent is on associating properties with text without embedding the formatting codes directly. Most XML formats don't do that.
It's about saying something like "in the text, make characters 17-21 bold face" separately from the text itself, instead of "{\bf hello}"
What the patent is about is associating formatting information with text by means other than embedding it. For example, instead of "<b>foo</b>" you separately store the instructions "foo" and "make 0-3 bold"; it calls this "content" and "meta-codes". It's a bad idea, most software doesn't do it, and there should really be plenty of prior art before 1994.
I believe the reason Microsoft steps on this patent is because of their XML format, which uses such nonsense. I don't see how ODF infringes; it doesn't use such separation of content and "meta-codes" but codes everything in-line.
Great name for a patent troll company suing Microsoft.
What the hell is that supposed to mean? The APIs are already available; other people implement them.
You can only "open source" source code.
I think this is a really great effort.
I hope Android can meet them half way by making Android itself more compliant with Linux standards. Android is nice what it is, but it remains a very specialized platform. Interoperating better might be good for its acceptance as well.
unix has these interfaces as a matter of historical accident, what was an excellent design at the time.
No, UNIX has these interfaces because they get the job done. People tried all sorts of other interfaces and none of them caught on.
you might find that it helps to think about these thing..even when developing important, real-world applications.
How does it "help" me to think about solutions to problems I'm not having? I've never seen the socket interface to be rate limiting in anything I care about.
why shouldn't the kernel be able to call into userspace safely and transfer ownership of a buffer? is that really so terrible to consider?
Well, if that's your biggest itch, be my guest: implement a kernel patch, make it public, convince people to use it, and if it develops a large user community, maybe Linus will pick it up and it will become a standard part of the kernel.
If nobody is willing to put in the effort, evidently the feature isn't needed.
but in this case we have structural flaws
Not conforming to someone's pipe dream of kernel design is not a flaw. It's a flaw only if it demonstrably causes problems.
i'm not going to buy into the tablets brought down from the berkeley hills.
That's why they make all kinds. You're free to use Windows Vista; those people spend billions correcting supposed "structural flaws". Don't spoil UNIX or Linux for the rest of us. We like its "structural flaws" the way they are.
the most flexible and efficient thing would be to have memory for receive frames allocated at the bottom of the stack, and use callbacks all the way up.
Sure, in the same way that the "most flexible and efficient thing" would be to write inassembly language and turn off the MMU. But UNIX is not trying to do the most flexible and efficient thing, it's trying to be a reasonable tradeoff between simplicity, safety, and efficiency. And that means that efficiency only gets optimized to the point where it stops being a limiting factor for most programs.
even if its completely academic, i think its interesting to look at the user kernel boundary and try to refactor things which have negative structural impacts.
And you think that 2009 is the first time people think about this? System call overhead used to be a much bigger issue. UNIX and Linux has the current set of interfaces because they are a good compromise between simplicity and efficiency.
And these issues are constantly being evaluated implicitly: people who write network servers benchmark their code and find the bottlenecks. If the bottleneck is some system call, they complain to the kernel mailing list and maybe roll up their sleeves and come up with something new. If that turns out to be useful, more and more people ask for it to be put into the kernel, and eventually it becomes standard.
What motivates kernel developers is real benchmarks and the needs of important, real-world applications, not fluff pieces that express generic displeasure with the way things are done.
Oops... left out half of it...
That's easy to fix without changing the socket API: just add a system call that can return multiple packets from multiple streams simultaneously, a cross between select and readv. If there's a lot of data buffered in the kernel, it can then return that with a single system call. The user mode socket library can use that system call internally and still present every caller with the regular select/poll/socket abstraction; when callers request data, it first returns data that's already buffered in the process without another system call, and when it runs out of that, then it calls back into the kernel.
Although the addition of a single system call to a loop would not seem to add much of a burden, this is not the case
Really? For a lot of networking code that's in use these days, I don't see that the system call overhead is the bottleneck. On clients you usually have network bandwidth as the limiting step (rather than system calls). On servers, it usually seems to be disk access or HLL interpreters.
Each system call requires arguments to be marshaled and copied into the kernel, as well as causing the system to block the calling process and schedule another.
That's easy to fix without changing the socket API: just add a system call that can return multiple packets from multiple streams simultaneously, a cross between select and readv. If there's a lot of data buffered in the kernel, it can then return that with a single system call.
Solving this problem requires inverting the communication model between an application and the operating system.
Not only does it not require that, inversion of control doesn't even solve it, since you still have the context switches.
On Ursula LeGuin's web site, you find the motto: "A book is just a box of words, until a reader opens it." It's kind of ironic that a writer who uses science fiction primarily to talk about social issues is so blind to social change and the social good that actually comes from being able to share information.
It's her choice to get upset, it's our choice not to read her. I vaguely recall that I found the few things I read by her to be long-winded and boring, and I'm certain not to bother correcting that impression now.
EU funded science projects rarely lead to useful results.
As far as I can tell, the people who call themselves "the creative industries" are mostly recycling folk tunes and Shakespearean stories, and that's on a good day. True creativity happens in other fields, like, oh, computers, engineering, and science.
Instead of all these ridiculous restrictions and rules, I have a better idea.
(1) Convict parents for the crimes committed by their underage children; parents are the legal guardians and should be fully responsible for what their children do. (Likewise, if their underage children are crime victims, convict the parents as well, since they obviously didn't supervise them carefully enough.)
(2) If someone commits a crime with your gun, you should be an accessory to the crime. It doesn't matter whether you stored it "properly"--if it got used in a crime, it probably wasn't stored well enough.
If one company has best medicine for certain problem, it should be chosen
Sure, it should be chose... to lose its patent protection.
I don't want to think about "What drug companies have shady history?
Well, but you have to think about it, because if the company cheated on the other drug, there's a good chance that the drug that you want to take also doesn't do what the company claims.
Also, I think you're greatly overestimating the differences between drugs. Most drugs that drug companies make are useless: there are either generic equivalents that are just as good, or they are lifestyle drugs--something you could fix with nutrition and exercise.
We've gone from a society of tinkerers where the best idea wins to an increasingly IP law based profit model that stiffles innovation.
Analog was really special that way, and it may not come back: open interfaces defined by physics, plus the ability to plug components together anyway you like.
So, you want to subscribe to each other's newsletters. Get a room, you two!
With few exceptions, journalists are in bed with whoever is in power and whoever has money.
The journalists aren't idiots, however: they are going to continue to trade stories and (un)favorable coverage for benefits, like access to the rich and powerful, power trips, and book deals.
If you think that journalists at commercial newspapers have your best interests at heart, or that they give you unbiased coverage, you're a fool.