The whole point about all of this, X/Wayland/MIR, is getting closer to the video card without having to yank one's hair out whilst doing it. Why would one need a little close interaction with the bare metal? If you've ever used Linux and saw tearing while moving windows around, then you've hit on one of the points for why closer to metal is a bit more ideal.
With that said, let's not fool ourselves and think, "OMG, they just want access to the direct buffers!" That wouldn't be correct. However, developers want to have an ensured level of functionality with their applications visual appearance. If the app shows whited out menus for half a second, blink, and then there is your menu options, then there is something very wrong.
It was pretty clear that with X, politically speaking, that developers couldn't fix a lot of the problems due to legacy and the foaming at the mouth hordes that would call said developer out for ruining their precious X. You can already see those hordes from all the "take X and my network transparency from my cold dead hands" comments. It is to a degree those people, and a few other reasons, that provided the impetus for Wayland. You just cannot fix X the way it should be fixed.
Toolkits understand that display servers and pretty much the whole display stack in general suck. Granted there is a few moments of awesome, but they are largely out weighted by the suck factor, usually when you code an application, you'll note that sometimes you'll gravitate to the "winning" parts of the toolkit being used versus the pure suck ones. Qt has a multitude for all the OSes/Display Servers it supports. Be that Windows, Mac, X11, and so on. Likewise for GTK+ but to a lesser extent, but that is what make GTK+ a pretty cool toolkit. Because let's face it, no display stack is perfect in delivering every single developer's wish to the monitor. Likewise, no toolkit is perfect either. The GNOME and KDE people know this, they write specific code to get around some of the "weirdness" that comes with GTK+ or Qt. Obviously, that task is made slightly easier with Wayland and the way it allows a developer to send specifics to the display stack or even to the metal itself.
Projects like KDE and GNOME have to write window managers and a lot of times those window managers have to get around some of the most sucktacular parts of the underlying display server. However, once those parts are isolated, the bulk of the work left is done in the toolkit. So display servers matter a bit to the desktop environments because they need to find all of the pitfalls of using said display server and work around them. Sometimes, it can be as simple as a patch to the toolkit or the display server upstream. Sometimes it can be as painful as a kludge that looks like it was the dream of a madman, all depends on how much upstream a patch is needed to be effective and how effective it would be for other projects all around.
That leads into the problem with MIR. MIR seems pretty gravitated to its own means. If KDE has a problem with MIR that can be easily fixed with a patch to MIR or horribly fixed by a kludge in KDE's code base, it currently seems that the MIR team wouldn't be as happy go lucky to accept the patch if it meant that could potentially delay Ubuntu or break some future unknown to anyone else outside of MIR feature. Additionally, you have the duplicated work argument as well, which I think honestly holds a bit of water. I fondly remember the debates of aRts and Tomboy. While I think it's awesome that Ubuntu is developing their own display server, I pepper that thought with, "don't be surprised if everyone finds this whole endeavor a fools errand."
I think the NIH argument gets tossed around way too much, like its FOSS McCarthyism. Every team has their own goals and by their very nature, that would classify them as NIH heretics. Canonical's idea is this mobile/desktop nexus of funafication, MIR helps them drive that in a way that is better suited to them. That being said
People who complain about having to mouse over to something, loose all nerd cred with me. Shortcut keys were invented for a reason and you just cannot call yourself a hard-core user if you keep touching your mouse.
Casual users can do, "the mouse-over to the other side of the screen of shame" to pay for their inability to sit down and read a book on how to really use the tool given to you. Not saying I agree with how they have chosen to layout the UI in the Calligra suite, but honestly, at least they haven't f'ed with the shortcut keys since the 2.x series began.
I will now accept all "get off my lawn" comments to follow.
Not just getting friendly with local government, but I'm pretty sure Google will take the always wonderful stance of "secure forever". Time is always on the government's side and given enough time, all static security is rendered useless.
Unless Google plans to review their "security" on a pretty regular basis. Someone with enough money and enough time (pretty much any country's government and a few private citizens too) will eventually break into what is pretty much the Fort Knox (having large amounts of information, not the security part) of people's information.
I totally agree that the current level of abstraction used for things like sudo leaves a lot to desire and that going all out with the man page is a bit over kill for lesser activities. However I would say that is the job of the distro and not the tool's job. But I can see the argument for the converse as well. With that then, I would say that we will just have to disagree as to who's job it is to make something user friendly, because the tool is used in many systems so the tool programmers have to hit a wide target. Distro makers know their audience and should aim for that target.
Not to diminish your argument, but I believe you're talking about the actual tool while I speak of the configuration of the tool.
I think you're argument has some merit but I believe we'd need to rethink the whole way Unix like systems work in general for it to really apply here.
I personally feel the manner in which sudo works is quite well, but I understand that some may disagree. However I think it is an entirely different discussion that I doubt that I could argue well sitting in stop and go traffic on my phone.
So I'll have to apologize if I bow out of this discussion for the time being. Maybe later today I can get back with you because I think the topic you bring up is incredibly fascinating.
I don't understand how it is broken by design? 144 pages is fairly short and compact for a security tool. Think about how many endless pages are written about the security tools in Mac or Windows. sudo is a pretty broad tool and its used for a lot of enterprise control. When it comes to the casual user, usually the distro will abstract the tool to a pretty common denominator. Much like Mac and Windows abstract the complex security layers within each of their OSes for the home user.
I mean seriously, I think someone is missing the point here. That 144 page manual is for someone who is sitting in an admin chair, who will need to properly craft the file so that a central Unix/Linux box is properly maintained. I know MCSEs that have read tomes of information related to Windows security and I'm pretty sure the same holds true for Mac people as well.
This is my take on your comment, and if I'm wrong on this feel free to catch me on that. You are expecting home users to read something that is more geared for admins. Maybe even small time admins to read that, when usually the default out-of-box is good enough for a 10~50 employee setup. The question being now, "Would you expect a home user or a small time admin to be up to the same level, when it comes to security, as say an MCSE?" I don't think so and likewise, the sudo man page (and also PAM and dbus) is mostly geared for your high level admins who are going to need to know that kind of stuff.
So I don't think it is broken by design because it works as intended for the audience that it was geared for. For the home user and small business, if the default sudoers, pam.d/*, or dbus.conf isn't secure, that's mostly a problem with the distro makers and poor choice for their target audience. Not a sign that users need to read 600+ pages of manual. Overall, ask any admin of any OS how many pages it would take them to completely describe a tool like sudo for their OS and I'm pretty sure you'll find that 144 pages is on the low end of that scale.
What surprises me the most is that the poster forgot to say that the NSA isn't the only one in this race.
Many nations allies and foes alike are in a race to decrypt each others information. Not to mention their citizens' data. First one to a computer that can break most encryption wins. The NSA is hardly the only kid on the block.
That it is a quantum computer is just a detail point that matters little. The idea is to build a computer, any computer quantum or not, that can defeat the majority of encryption. The US isn't the only one who gets bothered by a lock it can't pick.
What you speak of is a direct consequence of Intel holding its monopoly over everything. So while there may be a slight technical challenge, there is a much larger political challenge.
Nope wait, wait!! That last reply, the JSR thing not correct. I'll totally admit wrong when wrong and JSR 296 isn't Swing itself but the aborted effort to build the application framework a while back. My bad, got that wrong. All shit tossing about that you want totally justified. That is all.
Well I work with Java all the time and I find Swing great to use, but when I want to build my own user interface elements, then yes, I find it very painful indeed. I've done custom widgets in Cario/GTK,.NET, and even for Android; and Swing is pretty up there for the bar that needs to be crossed to have a custom widget. I don't find Swing all that difficult to use at face value but just mucking about AWT or even SWT is far better than trying to muck around and build custom GUIs in Swing.
In that respect, GWT is worst. GWT makes a lot of assumptions about how you want to convert Java into JavaScript. When you want to create your own web elements, not only do you have to build it using some of the worst API I've seen, you actually have to fight the assumptions that GWT tries to make right out of the box. You are literally fighting on two fronts to just make a damn clock widget or rich editor widget. It is ridiculous.
GWT on a whole is a pretty sad state. It integrates poorly with JEE frameworks and when it does, it's literally shoe-horned. You'll find that something like JSR 356 is a waaaaaay better approach to bridging the gap between server side code and client code, and I'd hope that the Java community can keep hitting excellent projects like this. Because Google isn't doing it with their idea of interoperability.
Also since you want to be mincing words between library and framework. If you happen to head over to JSR 296 you'll see that the JSR refers to it as "The Swing Application Framework". Maybe you should head over there and educated them that they should have called it "The Swing Application Library". That being said, I believe your retort to have loss any of its credibility but seriously, this is Slashdot, does anyone think anything on this site is credible? Hope you are still laughing though.
Re:Strongest pushers for EcmaScript 6? Oh Really??
on
Dart 1.0 Released
·
· Score: 1
Wait a second, are you really holding JS extensions in the Firefox experimental against Chrome stable? Really? Are we doing that now?
What? Do you mean 2.6.0 RC1? 2.6 looks to be more of a clean up of the 2.5.1 stuff rather than anything new. If anything the main thing that 2.6 brings is that they brought Java 7 into the picture. I wouldn't say that Google *has* abandon GWT, but they sure are making the common gestures of getting ready for a good old fashion keelhauling.
Now for just my opinion, GWT sucks. It's a messy looking API and lacks a ton of flexibility. For example, trying to implement custom UI for your web page is painful and totally unpleasant. More so than say making the same customer UI in Java Swing (which is pretty painful in of itself). In my opinion, and you my mod me down for it, is that anything that is worst to do in (insert framework here) than it is in Java should not exist.
Don't know about the coding side of it, but I would guess it to be pretty straight-forward process since the VM is open sourced. I think the better question would be how much political effort would it take to get a plug-in for FF and/or IE into the hands of people? Pure JavaScript folk are pretty damn hard-core about their language and Dart to them just seems like a solution to a non-existent problem. Besides, with Dart being a plug-in, you'd have websites once again going into the "check for plug-ins" hell that they are trying their best to get out of.
No, no don't mod the parent down!
on
Dart 1.0 Released
·
· Score: 2, Interesting
I think the parent has a good argument, maybe just no stated in the best of terms.
However, on the Dart site it says that Dartium, the DartVM enabled version of Chrome, will be one of the major focuses of the Dart team. Somehow, I have a sinking feeling that maybe, just maybe, Dart and NaCL are going to become *major* line items for ChromeOS and Chromebooks. Much like how ActiveX and VBScript became pretty important pillars in Microsoft's platform.
So while on the face of it, it sounds like a shrill. It actually can be rather thought provoking about the future of Chrome and Google. Just for a second think about where VBScript and ActiveX went during their lifetime and what they eventually evolved to. Granted we all now look back and see VBScript as the useless thing that it is, but in it's day, it provided a very powerful way of making offline enabled web pages and was featured heavily in WSH for admins until replaced by PowerShell. Clearly, Google hinting at Dart in the server is an indicator that Dart very may well have a life not unlike VBScript.
I think your arguments are pretty valid and I am by no stretch of the imagination a pro-Dart guy, but I believe that the "cross browser" claim comes from the olden days of cross platform languages. C/C++ had (has, just in case the past tense is a really bad choice) cross platform compilers they take C/C++ code and compile it to a language that the target platform understands. For example, C to ARM/x86/amd64/MIPS... compilers.
So my guess here, and it is just a guess, is that Google is using the same rationale to justify calling this a "cross browser" language, because the compiler can turn Dart into a language that can be understood by other browsers, much like a C compiler can compile into different paltforms. Arguments about if that is an accurate equation are totally justified and most likely will ensue hereafter. I'm just tossing up a guess as to why Google felt like that was an accurate statement.
Re:Dart2JS is faster than JS?! whatever
on
Dart 1.0 Released
·
· Score: 4, Informative
That is correct. When writing my piece for the story I wanted to ensure that I conveyed the correct idea that the Dart2JS compiler now generates up to 40% less JavaScript than previous versions of Dart2JS, not that the JavaScript itself that it generates is 40% faster.
As far as speed goes, there is all kinds of data on that facet on the Dart website. That will no less generate large amounts of debate about the figures presented by Google about Dart's performance. Just for the comedy of it, dart2js may generate less JavaScript, but will generate at least 60% more debate about its use.
If I was not clear on the whole point by this part of the story:
The new release brings a much tighter dart2js compiler reducing overall JavaScript output up to 40%
Then it was an honest mistake. I work with computers not the English language.:-)
They put it there for the casual on-lookers. For whatever people bang on it, when you say Linux in an interview and they ask you which distro, you say Slackware. If you know how to hold it together with Slackware, things like installing 3rd party drivers from the command line on Ubuntu or SuSE or knowing the entire purpose of everything in/proc is the kinds of things they know you do 300% better asleep and drunk than most admins could muster running full steam.
Here's to the release of yet another amazing version of the best Linux distro to date.
Yes blame customers. Businesses are always going to favor vendor lock in, if that comes as a surprise or vice to anyone, then they ought not be in the biz. Customer's as you say are, "dumber than dirt." They know not what markets they are creating, nor what repercussions those choices will have. Look at the uneven level of apps vs. HTML5 on any mobile device. Heck even Facebook gave HTML5 a fair shake and they just couldn't satisfy the customers, with it.
I totally understand what you are getting at, admins suck for not moving forward enough, but at the same time, they can only move as fast as the customer because at the end of the day, they still have to pay rent. The requirements for MSIE 6/7, flash, or Java plug-in are ridiculous. But customers want camera, VoIP, desktop sharing, ability to manage a printer, reset switches, animated charting, 3D effects for presentations, and so on... Customers are impossible to satisfy, which is why companies in the tech industry keep popping up, which is why different ways of doing things keep getting made. There is always something that someone isn't doing and a company's primary goal is to do that thing and make money from it (and at times they honestly just want to make people's lives easier, but, well I don't think I really need to elaborate how often that's the case).
I totally agree with you up to a particular point. Don't get me wrong, I read your post and was nodding yes to a lot of it, but the overwhelming majority of issues are because clients want their software to do more and standards be damned in the process. There are those that will stick to the standards as much as possible, and then there are those who think standards move too slowly to really address in real-time customer demands. The ones who are breaking the rules tend to have that dot-com bubble charm in my book, but it seems to be the way to get investors and gain critical mass. However, they do it because there exists a demand for it from customers. Additionally, I've enjoyed your comments quite a bit. Rarely do I find on Slashdot someone willing to talk without resorting to some childish level, bravo.
And what I'm getting at, is that servers only serve up what the customer wants. If no one gives a flip about standards, and few do, then a company changes the server to meet customer demand. Be it HTML or some crazy binary protocol.
The number of clients out there dictate what servers are dishing up. Seeing how there is still a ton of non-standard rendering browsers out there, they still need to cover those people or just go ahead and pack the bags because they won't have a lot of customers if they can't get the website to properly render on their system.
So until we invent FUCUP (Force Upgrade to Client Universal Protocol), clients are always going to lag behind standards, just because, and there is little an admin can really do about it if they want customers to keep visiting.
Which is why HTTP Client Hints were invented. User agent strings were a hack back in the day to figuring out abilities on a browser. They still are. Also, no the problem isn't the server side. That's like saying the problem with pollution is the road and not the car. "Hey look I made a car analogy! Do I win a prize!?"
That's progress!! We've implemented a target for you to be able to execute a function we've had since 95 that we removed last year! Hey, someone call up Apple and tell them to just go ahead and ditch finder and the dock. If someone wants applications they can just three finger swipe up on the touch pad, good luck if your on an iMac.
The thing to remember is that roughly about 1nm is the end of the line for the current process for chip making. It doesn't mark the end of circuits, it just means we need a different method. That could be with Silicene, nano tubes, or heck even quantum computers. This isn't the end of the progress of processors, it's just the end of Moore's Law. There might be even a 0.5nm or 0.1nm era, but there will be some serious diminishing returns for that (unless someone is really clever)
Slashdot Mirror
The whole point about all of this, X/Wayland/MIR, is getting closer to the video card without having to yank one's hair out whilst doing it. Why would one need a little close interaction with the bare metal? If you've ever used Linux and saw tearing while moving windows around, then you've hit on one of the points for why closer to metal is a bit more ideal.
With that said, let's not fool ourselves and think, "OMG, they just want access to the direct buffers!" That wouldn't be correct. However, developers want to have an ensured level of functionality with their applications visual appearance. If the app shows whited out menus for half a second, blink, and then there is your menu options, then there is something very wrong.
It was pretty clear that with X, politically speaking, that developers couldn't fix a lot of the problems due to legacy and the foaming at the mouth hordes that would call said developer out for ruining their precious X. You can already see those hordes from all the "take X and my network transparency from my cold dead hands" comments. It is to a degree those people, and a few other reasons, that provided the impetus for Wayland. You just cannot fix X the way it should be fixed.
Toolkits understand that display servers and pretty much the whole display stack in general suck. Granted there is a few moments of awesome, but they are largely out weighted by the suck factor, usually when you code an application, you'll note that sometimes you'll gravitate to the "winning" parts of the toolkit being used versus the pure suck ones. Qt has a multitude for all the OSes/Display Servers it supports. Be that Windows, Mac, X11, and so on. Likewise for GTK+ but to a lesser extent, but that is what make GTK+ a pretty cool toolkit. Because let's face it, no display stack is perfect in delivering every single developer's wish to the monitor. Likewise, no toolkit is perfect either. The GNOME and KDE people know this, they write specific code to get around some of the "weirdness" that comes with GTK+ or Qt. Obviously, that task is made slightly easier with Wayland and the way it allows a developer to send specifics to the display stack or even to the metal itself.
Projects like KDE and GNOME have to write window managers and a lot of times those window managers have to get around some of the most sucktacular parts of the underlying display server. However, once those parts are isolated, the bulk of the work left is done in the toolkit. So display servers matter a bit to the desktop environments because they need to find all of the pitfalls of using said display server and work around them. Sometimes, it can be as simple as a patch to the toolkit or the display server upstream. Sometimes it can be as painful as a kludge that looks like it was the dream of a madman, all depends on how much upstream a patch is needed to be effective and how effective it would be for other projects all around.
That leads into the problem with MIR. MIR seems pretty gravitated to its own means. If KDE has a problem with MIR that can be easily fixed with a patch to MIR or horribly fixed by a kludge in KDE's code base, it currently seems that the MIR team wouldn't be as happy go lucky to accept the patch if it meant that could potentially delay Ubuntu or break some future unknown to anyone else outside of MIR feature. Additionally, you have the duplicated work argument as well, which I think honestly holds a bit of water. I fondly remember the debates of aRts and Tomboy. While I think it's awesome that Ubuntu is developing their own display server, I pepper that thought with, "don't be surprised if everyone finds this whole endeavor a fools errand."
I think the NIH argument gets tossed around way too much, like its FOSS McCarthyism. Every team has their own goals and by their very nature, that would classify them as NIH heretics. Canonical's idea is this mobile/desktop nexus of funafication, MIR helps them drive that in a way that is better suited to them. That being said
People who complain about having to mouse over to something, loose all nerd cred with me. Shortcut keys were invented for a reason and you just cannot call yourself a hard-core user if you keep touching your mouse.
Casual users can do, "the mouse-over to the other side of the screen of shame" to pay for their inability to sit down and read a book on how to really use the tool given to you. Not saying I agree with how they have chosen to layout the UI in the Calligra suite, but honestly, at least they haven't f'ed with the shortcut keys since the 2.x series began.
I will now accept all "get off my lawn" comments to follow.
Not just getting friendly with local government, but I'm pretty sure Google will take the always wonderful stance of "secure forever". Time is always on the government's side and given enough time, all static security is rendered useless.
Unless Google plans to review their "security" on a pretty regular basis. Someone with enough money and enough time (pretty much any country's government and a few private citizens too) will eventually break into what is pretty much the Fort Knox (having large amounts of information, not the security part) of people's information.
I totally agree that the current level of abstraction used for things like sudo leaves a lot to desire and that going all out with the man page is a bit over kill for lesser activities. However I would say that is the job of the distro and not the tool's job. But I can see the argument for the converse as well. With that then, I would say that we will just have to disagree as to who's job it is to make something user friendly, because the tool is used in many systems so the tool programmers have to hit a wide target. Distro makers know their audience and should aim for that target.
Not to diminish your argument, but I believe you're talking about the actual tool while I speak of the configuration of the tool. I think you're argument has some merit but I believe we'd need to rethink the whole way Unix like systems work in general for it to really apply here. I personally feel the manner in which sudo works is quite well, but I understand that some may disagree. However I think it is an entirely different discussion that I doubt that I could argue well sitting in stop and go traffic on my phone. So I'll have to apologize if I bow out of this discussion for the time being. Maybe later today I can get back with you because I think the topic you bring up is incredibly fascinating.
I don't understand how it is broken by design? 144 pages is fairly short and compact for a security tool. Think about how many endless pages are written about the security tools in Mac or Windows. sudo is a pretty broad tool and its used for a lot of enterprise control. When it comes to the casual user, usually the distro will abstract the tool to a pretty common denominator. Much like Mac and Windows abstract the complex security layers within each of their OSes for the home user.
I mean seriously, I think someone is missing the point here. That 144 page manual is for someone who is sitting in an admin chair, who will need to properly craft the file so that a central Unix/Linux box is properly maintained. I know MCSEs that have read tomes of information related to Windows security and I'm pretty sure the same holds true for Mac people as well.
This is my take on your comment, and if I'm wrong on this feel free to catch me on that. You are expecting home users to read something that is more geared for admins. Maybe even small time admins to read that, when usually the default out-of-box is good enough for a 10~50 employee setup. The question being now, "Would you expect a home user or a small time admin to be up to the same level, when it comes to security, as say an MCSE?" I don't think so and likewise, the sudo man page (and also PAM and dbus) is mostly geared for your high level admins who are going to need to know that kind of stuff.
So I don't think it is broken by design because it works as intended for the audience that it was geared for. For the home user and small business, if the default sudoers, pam.d/*, or dbus.conf isn't secure, that's mostly a problem with the distro makers and poor choice for their target audience. Not a sign that users need to read 600+ pages of manual. Overall, ask any admin of any OS how many pages it would take them to completely describe a tool like sudo for their OS and I'm pretty sure you'll find that 144 pages is on the low end of that scale.
But you have to admit, mveloso walked into that one. :-D
What surprises me the most is that the poster forgot to say that the NSA isn't the only one in this race. Many nations allies and foes alike are in a race to decrypt each others information. Not to mention their citizens' data. First one to a computer that can break most encryption wins. The NSA is hardly the only kid on the block. That it is a quantum computer is just a detail point that matters little. The idea is to build a computer, any computer quantum or not, that can defeat the majority of encryption. The US isn't the only one who gets bothered by a lock it can't pick.
What you speak of is a direct consequence of Intel holding its monopoly over everything. So while there may be a slight technical challenge, there is a much larger political challenge.
Nope wait, wait!! That last reply, the JSR thing not correct. I'll totally admit wrong when wrong and JSR 296 isn't Swing itself but the aborted effort to build the application framework a while back. My bad, got that wrong. All shit tossing about that you want totally justified. That is all.
Well I work with Java all the time and I find Swing great to use, but when I want to build my own user interface elements, then yes, I find it very painful indeed. I've done custom widgets in Cario/GTK, .NET, and even for Android; and Swing is pretty up there for the bar that needs to be crossed to have a custom widget. I don't find Swing all that difficult to use at face value but just mucking about AWT or even SWT is far better than trying to muck around and build custom GUIs in Swing.
In that respect, GWT is worst. GWT makes a lot of assumptions about how you want to convert Java into JavaScript. When you want to create your own web elements, not only do you have to build it using some of the worst API I've seen, you actually have to fight the assumptions that GWT tries to make right out of the box. You are literally fighting on two fronts to just make a damn clock widget or rich editor widget. It is ridiculous.
GWT on a whole is a pretty sad state. It integrates poorly with JEE frameworks and when it does, it's literally shoe-horned. You'll find that something like JSR 356 is a waaaaaay better approach to bridging the gap between server side code and client code, and I'd hope that the Java community can keep hitting excellent projects like this. Because Google isn't doing it with their idea of interoperability.
Also since you want to be mincing words between library and framework. If you happen to head over to JSR 296 you'll see that the JSR refers to it as "The Swing Application Framework". Maybe you should head over there and educated them that they should have called it "The Swing Application Library". That being said, I believe your retort to have loss any of its credibility but seriously, this is Slashdot, does anyone think anything on this site is credible? Hope you are still laughing though.
Wait a second, are you really holding JS extensions in the Firefox experimental against Chrome stable? Really? Are we doing that now?
What? Do you mean 2.6.0 RC1? 2.6 looks to be more of a clean up of the 2.5.1 stuff rather than anything new. If anything the main thing that 2.6 brings is that they brought Java 7 into the picture. I wouldn't say that Google *has* abandon GWT, but they sure are making the common gestures of getting ready for a good old fashion keelhauling.
Now for just my opinion, GWT sucks. It's a messy looking API and lacks a ton of flexibility. For example, trying to implement custom UI for your web page is painful and totally unpleasant. More so than say making the same customer UI in Java Swing (which is pretty painful in of itself). In my opinion, and you my mod me down for it, is that anything that is worst to do in (insert framework here) than it is in Java should not exist.
Don't know about the coding side of it, but I would guess it to be pretty straight-forward process since the VM is open sourced. I think the better question would be how much political effort would it take to get a plug-in for FF and/or IE into the hands of people? Pure JavaScript folk are pretty damn hard-core about their language and Dart to them just seems like a solution to a non-existent problem. Besides, with Dart being a plug-in, you'd have websites once again going into the "check for plug-ins" hell that they are trying their best to get out of.
I think the parent has a good argument, maybe just no stated in the best of terms.
However, on the Dart site it says that Dartium, the DartVM enabled version of Chrome, will be one of the major focuses of the Dart team. Somehow, I have a sinking feeling that maybe, just maybe, Dart and NaCL are going to become *major* line items for ChromeOS and Chromebooks. Much like how ActiveX and VBScript became pretty important pillars in Microsoft's platform.
So while on the face of it, it sounds like a shrill. It actually can be rather thought provoking about the future of Chrome and Google. Just for a second think about where VBScript and ActiveX went during their lifetime and what they eventually evolved to. Granted we all now look back and see VBScript as the useless thing that it is, but in it's day, it provided a very powerful way of making offline enabled web pages and was featured heavily in WSH for admins until replaced by PowerShell. Clearly, Google hinting at Dart in the server is an indicator that Dart very may well have a life not unlike VBScript.
I think your arguments are pretty valid and I am by no stretch of the imagination a pro-Dart guy, but I believe that the "cross browser" claim comes from the olden days of cross platform languages. C/C++ had (has, just in case the past tense is a really bad choice) cross platform compilers they take C/C++ code and compile it to a language that the target platform understands. For example, C to ARM/x86/amd64/MIPS... compilers.
So my guess here, and it is just a guess, is that Google is using the same rationale to justify calling this a "cross browser" language, because the compiler can turn Dart into a language that can be understood by other browsers, much like a C compiler can compile into different paltforms. Arguments about if that is an accurate equation are totally justified and most likely will ensue hereafter. I'm just tossing up a guess as to why Google felt like that was an accurate statement.
That is correct. When writing my piece for the story I wanted to ensure that I conveyed the correct idea that the Dart2JS compiler now generates up to 40% less JavaScript than previous versions of Dart2JS, not that the JavaScript itself that it generates is 40% faster.
As far as speed goes, there is all kinds of data on that facet on the Dart website. That will no less generate large amounts of debate about the figures presented by Google about Dart's performance. Just for the comedy of it, dart2js may generate less JavaScript, but will generate at least 60% more debate about its use.
If I was not clear on the whole point by this part of the story:
The new release brings a much tighter dart2js compiler reducing overall JavaScript output up to 40%
Then it was an honest mistake. I work with computers not the English language. :-)
They put it there for the casual on-lookers. For whatever people bang on it, when you say Linux in an interview and they ask you which distro, you say Slackware. If you know how to hold it together with Slackware, things like installing 3rd party drivers from the command line on Ubuntu or SuSE or knowing the entire purpose of everything in /proc is the kinds of things they know you do 300% better asleep and drunk than most admins could muster running full steam.
Here's to the release of yet another amazing version of the best Linux distro to date.
Yes blame customers. Businesses are always going to favor vendor lock in, if that comes as a surprise or vice to anyone, then they ought not be in the biz. Customer's as you say are, "dumber than dirt." They know not what markets they are creating, nor what repercussions those choices will have. Look at the uneven level of apps vs. HTML5 on any mobile device. Heck even Facebook gave HTML5 a fair shake and they just couldn't satisfy the customers, with it.
I totally understand what you are getting at, admins suck for not moving forward enough, but at the same time, they can only move as fast as the customer because at the end of the day, they still have to pay rent. The requirements for MSIE 6/7, flash, or Java plug-in are ridiculous. But customers want camera, VoIP, desktop sharing, ability to manage a printer, reset switches, animated charting, 3D effects for presentations, and so on... Customers are impossible to satisfy, which is why companies in the tech industry keep popping up, which is why different ways of doing things keep getting made. There is always something that someone isn't doing and a company's primary goal is to do that thing and make money from it (and at times they honestly just want to make people's lives easier, but, well I don't think I really need to elaborate how often that's the case).
I totally agree with you up to a particular point. Don't get me wrong, I read your post and was nodding yes to a lot of it, but the overwhelming majority of issues are because clients want their software to do more and standards be damned in the process. There are those that will stick to the standards as much as possible, and then there are those who think standards move too slowly to really address in real-time customer demands. The ones who are breaking the rules tend to have that dot-com bubble charm in my book, but it seems to be the way to get investors and gain critical mass. However, they do it because there exists a demand for it from customers. Additionally, I've enjoyed your comments quite a bit. Rarely do I find on Slashdot someone willing to talk without resorting to some childish level, bravo.
And what I'm getting at, is that servers only serve up what the customer wants. If no one gives a flip about standards, and few do, then a company changes the server to meet customer demand. Be it HTML or some crazy binary protocol.
The number of clients out there dictate what servers are dishing up. Seeing how there is still a ton of non-standard rendering browsers out there, they still need to cover those people or just go ahead and pack the bags because they won't have a lot of customers if they can't get the website to properly render on their system.
So until we invent FUCUP (Force Upgrade to Client Universal Protocol), clients are always going to lag behind standards, just because, and there is little an admin can really do about it if they want customers to keep visiting.
That's like saying, "if you don't want to get arrested, don't do anything illegal!" Or am I the only one that got that vibe?
Which is why HTTP Client Hints were invented. User agent strings were a hack back in the day to figuring out abilities on a browser. They still are. Also, no the problem isn't the server side. That's like saying the problem with pollution is the road and not the car. "Hey look I made a car analogy! Do I win a prize!?"
This implies Google has special-case code for Internet Explorer.
And there is a reason why they wouldn't? I think if you use jQuery it has pretty much the code in non-IE and IE branches
That's progress!! We've implemented a target for you to be able to execute a function we've had since 95 that we removed last year! Hey, someone call up Apple and tell them to just go ahead and ditch finder and the dock. If someone wants applications they can just three finger swipe up on the touch pad, good luck if your on an iMac.
The thing to remember is that roughly about 1nm is the end of the line for the current process for chip making. It doesn't mark the end of circuits, it just means we need a different method. That could be with Silicene, nano tubes, or heck even quantum computers. This isn't the end of the progress of processors, it's just the end of Moore's Law. There might be even a 0.5nm or 0.1nm era, but there will be some serious diminishing returns for that (unless someone is really clever)