Make the main page a script with uncacheable results and give out unique session IDs in the URL. Then you have the most reliable way of tracking browser sessions with no user cooperation required. Actually, I see that Mailinator uses a Java servlet container and most containers such as Tomcat have a very, very robust session management built in and using it is straightforward.
Exchange 2010 OWA isn't completely fixed. Security on non-IE browsers sucks. They don't terminate your session properly after logging of. Instead, they show you a message to restart your browser. Not doing so allows you to reenter OWA without a login prompt. So much for proper session management. I wonder why MS can't do what Facebook, Google, your bank of choice et. al. can.
Well, there are no perfect drivers out there. All of them have bugs, but the bugs in the closed source drivers are the least annoying ones in my experience. As a developer you can generally get things to work with them given enough fiddling. Naturally, you can't let the users do that kind of fiddling around, which makes hardware compatibility such a pain.
What hardware and OS did you try WebGL on? If it was Linux with poor (read: open source) drivers then there's your explanation. I've yet to see any open source driver for 3D hardware acceleration that actually works (and being able to run desktop compositing does not count - it's not even remotely an indication of how modern 3D rendering is done). I really hate to bash the open source drivers in that fashion, even though it's true.
The one thing that is giving a little bit of credit to all of this is the fact that a while ago was a statement from an MS manager (don't remember his name - he was responsible for the department that makes Silverlight) that they do no longer envision Silverlight as the primary content delivery method and favor HTML/Javascript instead. I could search for the source, but it would be in German.
The minimalist trend is not temporary, nor should it be. But developers tend to overdo it.
There is no reason to have every last feature of a program available directly in the main UI of said program. This is especially true now that program complexity and feature-completeness has risen to enormous levels (which is not a bad thing in itself). You remember the ridiculous screenshots of MS Word with every toolbar displayed, leaving 2 lines of the actual document visible on screen amidst all those buttons?
When cleaning out the user interface, there are 3 things that you can do:
1. Remove rarely used features entirely. This is simple, but not the way to go in general. Users will generally hate you for that. 2. Rearrange features in the UI. Guess (or measure) which features the users tend to use most often and reserve the most prominent places in the UI for them. Less used features can be hidden more deeply in the user interface because the time to access those doesn't generally matter when they are rarely used. This is not very hard to do, but it has to be done exactly right or the UI will feel like it gets in your way. 3. Look at your feature set and think very very hard about ways to redesign the basic user interaction with the program. Depending on the type of program there can be ways to merge features and modes in such a way that they are perceived as a single, much more powerful and - if done correctly - much more intuitive - tool that allows a much more direct interaction. This is very hard to do, requires a lot of research and prototyping and very few teams actually do this. And some developers get this almost, but not quite right. The MS Office ribbons are an example for this latter category. Google Sketchup is an example for a program where user interaction is designed so intelligently that it feels very direct and simple although it is actually quite complex under the hood (if you don't believe me, try to build the same model in Sketchup and in Blender or Maya,...).
Right now, some developers seem to apply 1. instead of 2. or 3. far too liberally. And this will not hold up.
That's totally in line with what copy protection schemes are actually expected to provide for the publisher. No (good) manufacturer of copy protection software claims that their scheme is unbreakable. It can be done with time and effort. Their goal is to extend this time span so far that the initial release sales peak is covered as much as possible, i.e. cracks start spreading only after a majority of the copies have been sold. After that it doesn't matter if the protection stays or gets removed.
This "dumb shit" as you call it is the result of a nation-wide hysteria about nuclear energy that started in the early 80s. It has mostly been fueled mainly by environmentalists and the green party and it stuck. As a result, no new reactors have been built in Germany for decades and in addition to that, everyone is now afraid of the old ones standing everywhere. And a neat case of almost universal selective perception makes people listen to those expert naysayers who draw up the most horrible scenarios instead of the more moderate ones.
And as another direct result of the accident in Fukushima, the German green party is on an all time high in the current set of state-level elections that's going on. Unfortunately, the people aren't voting for them because of the many actual things that they can do and want to do, but only because this party is perceived as being the one most strictly opposed to nuclear energy. I'm not looking forward to the day when the people wake up and realize that the green party program has a lot more to offer that the voters didn't actually want to happen. We're heading that way and it's not going to be pretty.
Germans can be so incredibly stupid at times, it's annoying. I'm German, too, btw. Maybe it's time to think about a personal exit strategy...
There's an explanation for that: when Apple copies something, they do it quite well from the start. When MS copied something, they had a tendency in the past to deliver crap with the first two releases while they seemingly learned the ins and outs of what they were doing. But I think they have gotten better in that department.
So some gadget that does the same X that 20 others did before is not new just because that one one actually manages to *actually* do it *right*? Usability is a kind of innovation. The first iPhone did not have superior hardware. Instead, its innovation was a new and clearly superior kind of user interface for a phone - something that you can't just build over night.
Whether this statement (which in its general form covers more than just speed and location, but rather any two operators which are not commutative) does affect the measurements or not depends on the methods involved. But they will certainly have considered this before doing their experiments:).
Nevertheless, claims of kernel level hardware access via WebGL are speculative at best since WebGL shaders run on the GPU and shader compilers run in user mode.
Therefore, unless something is horribly wrong in a particular graphics driver (and Mozilla/Google were careful which companies they whitelist in this regard), the worst case is a bug in the code compiler -- which is probably about as likely as a bug in any Javascript interpreter or Adobe Flash.
You are certainly aware then that the shader compilers in the OpenGL drivers are among the buggiest compilers I've ever worked with. In my experience, a bug in any of these shader compilers is, at least at the moment, much, much more likely than one in the browser's JS interpreter.
Also, they would need the "triple-step dance" for each different buggy driver, each of which would get patched in weeks at most, and each of which probably affects 0.1% of the market due to the diversity of hardware, OS and browser -- you have to consider payoff of exploit as well.
Uhm, 0.1% of the marker? Not a chance. Especially the compilers are shared between different drivers. Again, I can't speak for ATI or Intel, but nVidia has basically exactly one driver for all their platforms and hardware variants (the current builds cover 200 series and newer at least in a single driver). That's about 20 to 30 percent of the market with one single compiler vulnerability.
Note: I do not distinguish between kernel and user mode parts of the OpenGL implementation/driver here. From a OpenGL user's perspective, there's no difference.
And having to deal with POSIX, Carbon, Win32 etc. at the same time in order build something equivalent is not nonsense? Browsers are not perfect, but at least they offer largely the same interface to develop against. Sure, you have to find workarounds, but it beats building things from scratch.
The opportunity for browsers to take over the desktop has been stronger than ever with the rise of such heterogeneous environments on phones, tablets, PCs, home appliances, gaming consoles etc. because it's a sort-of unified platform that faces the user and is simple to use with the juicy meat of the applications neatly tucked away in some server room in a totally controlled, purpose-built and professionally managed environment (for what that's worth - shrug). When you're able to target the browser you don't have to deal with half a dozen completely different system interfaces anymore on the client side, meaning you don't have to rewrite your client big time for every new platform that comes along.
And Google actually knows how to run the servers and write the software in order to make a profit. So the chances are that Google will take a considerable portion of the market with this. If this is for better or worse, only time will be able to tell.
The truly dangerous attack vector is not any shader code. It's all the half-decent shader compilers out there that are part of the OpenGL runtime. GLSL shaders always need to be compiled from source at runtime by the driver. So the Browser must pass off a big piece of code/data to the driver's compiler, a complex, non-secure and typically also annoyingly buggy piece of software. In other words: the compilers' fragile parsers are now directly exposed to remote websites. They were never intended to take potentially insecure input. I've been aware of that attack vector for at least 6 months now.
Well, continued development of an own product for Linux* would be something completely new for MS. They haven't done that before and there may even be considerable legal concerns about patent-related language in some open source licenses for libs that Skype on Linux ultimately depends on. If they happen to be very unlucky they may lose the ability to threaten with patents againt Linux. They certainly do not want that.
Plus, there are not that many customers on Linux, relatively speaking. So they'll certainly do the math. What does it cost to maintain and support the Linux client? How many of them are paying customers? How many Linux users would migrate to Windows and pay additional license fees to MS when that client is discontinued? I'd like to think that the last number is the most significant, so the client will be abandoned for sane business reasons. Business is the part where they are least stupid and most ruthless, remember?
* Okay, there is this kernel module to support the Windows Server hypervisor, but that lives inside the kernel, which has a much simpler licensing structure than the user space.
In other words just like the German translation of Microsoft products: technical terms forcefully translated into German in hideous ways so that only translating them back into English can give you hints to the originally intended meaning of the message.
Well, for what reason would they downsize Qt development? There are quite a lot important commercial customers left for Qt (e.g. Autodesk using Qt in 2 of it's products, a large one ported over only recently) and there's a commercial user community as well, so I fail to see how shutting down Qt development would make any sense economically. My current assumption is that Qt development is actually profitable for Nokia.
Thus, even if Nokia would want to rid itself of the Qt developers they wouldn't shut them down. There's still good money to be made in selling all that to a party that is more interested or in spinning it off into a separate company and get a share of the profits.
To continue that list: Does it even have support anything higher than 8 bits per channel yet? I really require that for some of my work and I always end up using Photoshop in a Windows VM. At least I've written my own little viewer for HDR images, so I can at least get by without having to fire up PS constantly.
Last I checked, the ability to handle 16 bit integer and floating point formats has been deliberately removed from Krita as well - supposedly because it was suddenly intended to be a painting program which doesn't need such fancy stuff. *sigh*
You're not getting it. At least *I* am not helping anyone with building better weapons. Not in my country, nor any other one. When you're playing this game and send in the results, you get involved in weapon development. I won't.
Slashdot Mirror
Make the main page a script with uncacheable results and give out unique session IDs in the URL. Then you have the most reliable way of tracking browser sessions with no user cooperation required. Actually, I see that Mailinator uses a Java servlet container and most containers such as Tomcat have a very, very robust session management built in and using it is straightforward.
Exchange 2010 OWA isn't completely fixed. Security on non-IE browsers sucks. They don't terminate your session properly after logging of. Instead, they show you a message to restart your browser. Not doing so allows you to reenter OWA without a login prompt. So much for proper session management. I wonder why MS can't do what Facebook, Google, your bank of choice et. al. can.
Well, there are no perfect drivers out there. All of them have bugs, but the bugs in the closed source drivers are the least annoying ones in my experience.
As a developer you can generally get things to work with them given enough fiddling. Naturally, you can't let the users do that kind of fiddling around, which makes hardware compatibility such a pain.
What hardware and OS did you try WebGL on? If it was Linux with poor (read: open source) drivers then there's your explanation. I've yet to see any open source driver for 3D hardware acceleration that actually works (and being able to run desktop compositing does not count - it's not even remotely an indication of how modern 3D rendering is done). I really hate to bash the open source drivers in that fashion, even though it's true.
This is it: http://www.heise.de/newsticker/meldung/Microsoft-bevorzugt-HTML5-statt-Silverlight-1128262.html (article is in German)
The one thing that is giving a little bit of credit to all of this is the fact that a while ago was a statement from an MS manager (don't remember his name - he was responsible for the department that makes Silverlight) that they do no longer envision Silverlight as the primary content delivery method and favor HTML/Javascript instead. I could search for the source, but it would be in German.
The minimalist trend is not temporary, nor should it be. But developers tend to overdo it.
There is no reason to have every last feature of a program available directly in the main UI of said program. This is especially true now that program complexity and feature-completeness has risen to enormous levels (which is not a bad thing in itself). You remember the ridiculous screenshots of MS Word with every toolbar displayed, leaving 2 lines of the actual document visible on screen amidst all those buttons?
When cleaning out the user interface, there are 3 things that you can do:
1. Remove rarely used features entirely. This is simple, but not the way to go in general. Users will generally hate you for that. ...).
2. Rearrange features in the UI. Guess (or measure) which features the users tend to use most often and reserve the most prominent places in the UI for them. Less used features can be hidden more deeply in the user interface because the time to access those doesn't generally matter when they are rarely used. This is not very hard to do, but it has to be done exactly right or the UI will feel like it gets in your way.
3. Look at your feature set and think very very hard about ways to redesign the basic user interaction with the program. Depending on the type of program there can be ways to merge features and modes in such a way that they are perceived as a single, much more powerful and - if done correctly - much more intuitive - tool that allows a much more direct interaction. This is very hard to do, requires a lot of research and prototyping and very few teams actually do this. And some developers get this almost, but not quite right. The MS Office ribbons are an example for this latter category. Google Sketchup is an example for a program where user interaction is designed so intelligently that it feels very direct and simple although it is actually quite complex under the hood (if you don't believe me, try to build the same model in Sketchup and in Blender or Maya,
Right now, some developers seem to apply 1. instead of 2. or 3. far too liberally. And this will not hold up.
Sounds like an ideal base for kiosk-like setups where the user needs just a little bit of control beyond navigating a single web site.
That's totally in line with what copy protection schemes are actually expected to provide for the publisher. No (good) manufacturer of copy protection software claims that their scheme is unbreakable. It can be done with time and effort. Their goal is to extend this time span so far that the initial release sales peak is covered as much as possible, i.e. cracks start spreading only after a majority of the copies have been sold. After that it doesn't matter if the protection stays or gets removed.
This "dumb shit" as you call it is the result of a nation-wide hysteria about nuclear energy that started in the early 80s. It has mostly been fueled mainly by environmentalists and the green party and it stuck. As a result, no new reactors have been built in Germany for decades and in addition to that, everyone is now afraid of the old ones standing everywhere. And a neat case of almost universal selective perception makes people listen to those expert naysayers who draw up the most horrible scenarios instead of the more moderate ones.
And as another direct result of the accident in Fukushima, the German green party is on an all time high in the current set of state-level elections that's going on. Unfortunately, the people aren't voting for them because of the many actual things that they can do and want to do, but only because this party is perceived as being the one most strictly opposed to nuclear energy. I'm not looking forward to the day when the people wake up and realize that the green party program has a lot more to offer that the voters didn't actually want to happen. We're heading that way and it's not going to be pretty.
Germans can be so incredibly stupid at times, it's annoying. I'm German, too, btw. Maybe it's time to think about a personal exit strategy...
There's an explanation for that: when Apple copies something, they do it quite well from the start. When MS copied something, they had a tendency in the past to deliver crap with the first two releases while they seemingly learned the ins and outs of what they were doing. But I think they have gotten better in that department.
So some gadget that does the same X that 20 others did before is not new just because that one one actually manages to *actually* do it *right*? Usability is a kind of innovation. The first iPhone did not have superior hardware. Instead, its innovation was a new and clearly superior kind of user interface for a phone - something that you can't just build over night.
Whether this statement (which in its general form covers more than just speed and location, but rather any two operators which are not commutative) does affect the measurements or not depends on the methods involved. But they will certainly have considered this before doing their experiments :).
Read this article from a Mozilla dev:
http://blog.jprosevear.org/2011/05/13/webgl-security/
Note the last paragraph:
Therefore, unless something is horribly wrong in a particular graphics driver (and Mozilla/Google were careful which companies they whitelist in this regard), the worst case is a bug in the code compiler -- which is probably about as likely as a bug in any Javascript interpreter or Adobe Flash.
You are certainly aware then that the shader compilers in the OpenGL drivers are among the buggiest compilers I've ever worked with. In my experience, a bug in any of these shader compilers is, at least at the moment, much, much more likely than one in the browser's JS interpreter.
Also, they would need the "triple-step dance" for each different buggy driver, each of which would get patched in weeks at most, and each of which probably affects 0.1% of the market due to the diversity of hardware, OS and browser -- you have to consider payoff of exploit as well.
Uhm, 0.1% of the marker? Not a chance. Especially the compilers are shared between different drivers. Again, I can't speak for ATI or Intel, but nVidia has basically exactly one driver for all their platforms and hardware variants (the current builds cover 200 series and newer at least in a single driver). That's about 20 to 30 percent of the market with one single compiler vulnerability.
Note: I do not distinguish between kernel and user mode parts of the OpenGL implementation/driver here. From a OpenGL user's perspective, there's no difference.
And having to deal with POSIX, Carbon, Win32 etc. at the same time in order build something equivalent is not nonsense? Browsers are not perfect, but at least they offer largely the same interface to develop against. Sure, you have to find workarounds, but it beats building things from scratch.
The opportunity for browsers to take over the desktop has been stronger than ever with the rise of such heterogeneous environments on phones, tablets, PCs, home appliances, gaming consoles etc. because it's a sort-of unified platform that faces the user and is simple to use with the juicy meat of the applications neatly tucked away in some server room in a totally controlled, purpose-built and professionally managed environment (for what that's worth - shrug). When you're able to target the browser you don't have to deal with half a dozen completely different system interfaces anymore on the client side, meaning you don't have to rewrite your client big time for every new platform that comes along.
And Google actually knows how to run the servers and write the software in order to make a profit. So the chances are that Google will take a considerable portion of the market with this. If this is for better or worse, only time will be able to tell.
The truly dangerous attack vector is not any shader code. It's all the half-decent shader compilers out there that are part of the OpenGL runtime. GLSL shaders always need to be compiled from source at runtime by the driver. So the Browser must pass off a big piece of code/data to the driver's compiler, a complex, non-secure and typically also annoyingly buggy piece of software. In other words: the compilers' fragile parsers are now directly exposed to remote websites. They were never intended to take potentially insecure input. I've been aware of that attack vector for at least 6 months now.
Well, continued development of an own product for Linux* would be something completely new for MS. They haven't done that before and there may even be considerable legal concerns about patent-related language in some open source licenses for libs that Skype on Linux ultimately depends on. If they happen to be very unlucky they may lose the ability to threaten with patents againt Linux. They certainly do not want that.
Plus, there are not that many customers on Linux, relatively speaking. So they'll certainly do the math. What does it cost to maintain and support the Linux client? How many of them are paying customers? How many Linux users would migrate to Windows and pay additional license fees to MS when that client is discontinued? I'd like to think that the last number is the most significant, so the client will be abandoned for sane business reasons. Business is the part where they are least stupid and most ruthless, remember?
* Okay, there is this kernel module to support the Windows Server hypervisor, but that lives inside the kernel, which has a much simpler licensing structure than the user space.
In other words just like the German translation of Microsoft products: technical terms forcefully translated into German in hideous ways so that only translating them back into English can give you hints to the originally intended meaning of the message.
Who said that there are only two players?
Well, for what reason would they downsize Qt development? There are quite a lot important commercial customers left for Qt (e.g. Autodesk using Qt in 2 of it's products, a large one ported over only recently) and there's a commercial user community as well, so I fail to see how shutting down Qt development would make any sense economically. My current assumption is that Qt development is actually profitable for Nokia.
Thus, even if Nokia would want to rid itself of the Qt developers they wouldn't shut them down. There's still good money to be made in selling all that to a party that is more interested or in spinning it off into a separate company and get a share of the profits.
Qt is not going down, not by a long way.
I'm certain everyone will listen to Reason once in a while.
To continue that list: Does it even have support anything higher than 8 bits per channel yet? I really require that for some of my work and I always end up using Photoshop in a Windows VM. At least I've written my own little viewer for HDR images, so I can at least get by without having to fire up PS constantly.
Last I checked, the ability to handle 16 bit integer and floating point formats has been deliberately removed from Krita as well - supposedly because it was suddenly intended to be a painting program which doesn't need such fancy stuff. *sigh*
You're not getting it. At least *I* am not helping anyone with building better weapons. Not in my country, nor any other one. When you're playing this game and send in the results, you get involved in weapon development. I won't.
So I'd be helping them with building better weapons (even unmanned killing machines!) by playing games? No thanks!