Re:KDE and Gnome are still comparable
on
The Last GUADEC?
·
· Score: 0
Mod parent up. If anything, this graph shows that KDE's downward trend is ever-so-slightly steeper, though I'm not inclined to call the difference significant.
Then when you need to scale it up, or introduce some serious data processing, you can just buy servers with larger core counts and... oh wait. It's all single-threaded. Never mind.
I prefer DERP. Delete, Edit, Read and Produce. Users are actually well ahead of the technology curve here - ask any tech support worker, customers have been DERPing for years...
I don't use KDE, but I can't help thinking that people who recommend disabling these things - and I've read a lot of similar recommendations - are somewhat missing the point. They're enabled by default because they're supposed to work. The mail client that ships as part of the application suite should not be useless.
I've had some painful experiences with Evolution on GNOME over the years*. I moaned about it, filed bugs, commented on existing bugs, and sometimes just had to give in and use a web-based front-end for email. My underlying feelings are much the same: Evolution is supposed to work, so at no point did I recommend to anyone that they just disable it and move on.
Don't sweep these things under the rug!
* What is it about mail, calendaring & contacts that seems to be so difficult for open-source software to get right?
Correction: once you have the header, you might know how large the file is. The server may neglect to provide that information, or it may be wrong (e.g. sending the uncompressed length of data which is compressed for transport - yes, I have seen this). I worked on HTTP proxies for ~7 years, so I can say with some authority that HTTP is not a pretty standard, even when implemented correctly - which, all too often, it is not.
The progress bar on the HTTP download doesn't show the amount of remaining time in the bar. It shows the number of bytes remaining in the bar; the number of bytes remaining can't go into reverse.
True, it can't go into reverse - it can be unknown, though. The Content-Length header isn't mandatory in an HTTP response. This is presumably a legacy thing pre-dating any serious HTTP standardisation, but still hangs around to account for things like dynamically generated content and streaming media. In such cases, all that is required of the server is closing the connection when the content has been sent.
Unfortunately - due either to oversight, poor configuration, or poor programming - it's not unheard of for static, known-size content to be delivered without a Content-Length.
IMHO the panel menu in GNOME 3.6 is actually *worse* than in Unity or OS X. In Unity & OS X, I believe, the menu that appears there is what would normally appear at the top level in the current window - so the implementation works for all applications which use a supported GUI toolkit, and the menu items are at least visible, albeit not attached to the application itself. In GNOME, the panel menu is not automatically populated with the application's top-level menu items; its contents are application-specific. The contents are not always visible, but appear in a pop-up menu attached to the application icon (you know, that useless-looking thing that currently just serves to show the name of the currently focussed app). Because the contents are both application-specific and hidden by default, it's not obvious at all what (if anything) is there for any given app, and when you *do* open the menu (using the mouse or the unchangeable keyboard shortcut), none of the items in the menu have accelerator keys. In short, it's a usability nightmare with no redeeming features, and I don't know why they're pushing ahead with it.
I'm always curious what people find bad about Gnome 3 - it's about the best desktop environment I've used IMHO. There are a few niggles: 1. They have removed some options for the sake of simplicity which really shouldn't have been removed, and wouldn't have made things more complex if they were there. For example, not having a "disabled" option in the DPMS timeout is a WTF, as is hiding the "Power off" option until you press the magic "Alt" key (with no visual cues that you could press Alt to get at it).
Power off is now visible by default in 3.6, so this niggle has been fixed.
3. They've abolished minimise. However, shading windows is still possible and that's almost as good.
You can re-enable the minimise button with GNOME Tweak Tool. However, because there is no taskbar work-alike, minimised windows don't visibly "go anywhere" and you have to alt-tab or use the Activities view to switch back to them.
4. Focus stealing is a problem - Compiz/Beryl did a much better job at stopping this.
Really? I have no issues in this regard.
I should mention that I thought Gnome 2 was pretty much the worst DE I've ever used - that seemed to be an exercise in copying the worst bits of Windows and removing any options that might make it tollerable. Up until Gnome 3, I was using E17, largely because it was light, fast and just got out of my way when I wanted to get stuff done.
I found GNOME 2 incredibly useful. In fact, if you liked E17 because it got out of your way, I'm surprised you're so happy with GNOME 3, where the shell forcibly takes over whenever you use the Activities view to switch windows/launch things. That doesn't fit with my definition of getting out of the way. Then again, I never stuck with the default panel layout in GNOME 2. I had a single top panel, with the application menu on the left, clock/calendar, a selection of quick launchers, the workspace switcher, and the window menu - no taskbar. So in some ways, it actually resembled GNOME 3 more than the default GNOME 2 layout, which is why the new minimise behaviour doesn't bother me. What *does* bother me in 3.6, and has me worried for the future, is the stupid application menu in the top panel. Some apps use it, some don't; for those that do, there seems to be no rhyme or reason behind what goes in menus attached to the application itself, and what goes in the menu attached to the panel. Desktop applications which aren't part of the GNOME suite will probably never use it, and it doesn't work the same way as the panel menu in Unity, so I can only imagine the fragmentation getting worse, not better. Also the keyboard shortcut for it is annoying (super-F10 or something equally unintuitive), undiscoverable and I believe unconfigurable. When I first saw mock-ups of GNOME Shell, I didn't think I would like it at all, but now it's a reality I actually do quite like it, with the exception of the panel menu. I don't like the direction they're taking the application suite, with a tendency towards hiding menus, removing the titlebar from maximised windows (so how do you un-maximise with the mouse?), and other misguided "simplifications".
If those answers are the truth, what's wrong with them? They don't say anything particularly bad about the workplace, just that the previous employee had other ideas about what they wanted to do.
I was thinking the exact same things. Identifying the hardware is fundamentally different from identifying the person currently using it, and being able to state unequivocally that they are authorising whatever action is taking place. Plus, as you said, hardware gets upgraded. Even worse, though, is that hardware also fails; particularly high-end GPUs nearing the end of a life spent being slightly too hot. Unexpected hardware failure could leave users with no overlap in the usable life of old & new components, meaning they cannot log in to existing accounts in order to register the fingerprint of the new hardware. Also, unless there's a hidden cache of documents I'm missing somewhere, I can't find any details of what these "unclonable functions" actually are, just that they exist. Are they robust against simple replay attacks?
This all smells like a bad idea to me; something cooked up by a bunch of theorists with very little grounding in practicality. Not sure what part of this could be a "good thing", to be honest.
I thought I'd take a gamble on this one, and actually read TFA - even before reading the comments. I thought there would be a nice picture or two, maybe a few links to pages about the device itself. But you know what I got instead?
France.
No pictures, no related links at the end, and only one word in the entire article itself turned into a link - the word "France."
2) There are other methods to unlock on a touch screen. For example MeeGo's double press to unlock.
Yes there are other methods, but generally speaking, once you've got a device with a touchscreen, only so many of those methods are actually practical and sensible - it's a flat, touch-sensitive screen, so they're all going to revolve around pressing it, dragging your finger across it, or some combination of the two.
Where's the patent for "double press to unlock"? Oh, wait, there isn't one, because patenting the concept probably didn't even cross the minds of the people who came up with it!
When it doesn't validate, you reject it. Or, in the case of a replacement for an "extensible" protocol, you do something more subtle - such as, accept something which is well-formed XML but contains unrecognised tags, by skipping over the unrecognised tags. Much as is done in HTML itself.
Once you've written a few programs which accept data from the public internet, you come to greatly appreciate the value of protocols whose syntax is easy to parse, and whose semantics are simple to understand. The simpler the parsing code, the less likely it is to contain exploitable bugs; the simpler the semantics, the easier it is to write standards-compliant logic, and have a wide range of client & server implementations which interoperate happily. HTTP in its modern form - i.e. augmented over the years with such features as persistent connections, pipe-lining, chunked encoding, multi-part bodies, compression, cookies & caching - is neither easy to parse, nor easy to understand once parsed. It needs to be taken out and shot, along with this whole laissez-faire attitude to standards compliance & well-formed-ness which permeates web standards.
It's caught my attention too. You're not alone. I regularly cringe - or even groan out loud - when reading pieces published online in various places; Slashdot submissions being a frequent source of offence.
But the business decision has its roots in technical issues, to a certain extent. An unstable app isn't going to get good reviews, and an app with bad reviews isn't going to sell well. We haven't seen the code, but it's entirely possible that different development practices could have lead to Android issues taking up less than 20% of their time. They use a pre-exising cross-platform framework (Unity), but still have issues with shaders and texture formats? Sounds like their shaders aren't as well written as they perhaps thought, or they're doing something fruity in their content production pipeline. Having looked at screenshots, I'm not even sure what they're using shaders or exotic texture formats *for* - perhaps they should really be targetting OpenGL ES 1.0/1.1, not 2.0. Perhaps Unity as a framework just isn't very stable on Android, in which case they need to either ditch the framework or make use of their support entitlement (assuming you get some when you purchase a license).
Given that they only support two platforms to start with, spending 20% of their time on one of them doesn't sound too unreasonable. You can't expect your product to do well on a given platform if you don't treat it as a first-class target. Of course they're painting the end result as a pure business decision, but when other developers continue to profit from Android apps, you have to wonder why they were only making 5% of their money from one of a grand total of two supported platforms.
As with so many things in the world of computing, it's a trade-off. If the OS wants to maintain an application's EGL context when the user switches applications, it either needs its own state management so it can recreate that context behind the scenes without any specific application support (I imagine this would be quite complex, if it's even possible in the general case), or it has to take RAM hit of leaving the context intact, meaning decreased performance and/or fewer concurrent applications before things start being forcibly terminated. The EGL spec has a section on power management for a reason.
I've never developed for iOS, so I don't know exactly what it does, but I can understand why Android works the way it does - developer unfriendliness aside. Applications don't terminate the moment the user switches away from them, so they don't have to be launched from scratch if the user switches back; however, if something else wants to perform accelerated rendering whilst your app doesn't have focus, your app loses its grasp on the GPU. Personally I don't think this is unreasonable. AFAIK, if your app doesn't use OpenGL, loss of focus (distinct from termination) doesn't imply anything special.
Just hook into the right events, re-upload your textures & set desired GPU state before trying to render the next frame, and you're good to go.
64-bit builds of libcurl are flaky? That's news to me. I use it at home on Gentoo and at work on Fedora, both 64-bit native, and don't have any issues. Maybe there's something "interesting" (read: not set up correctly) in the Windows parts of its build system, but I doubt it's anything inherent in the code. As for 64-bit QuickTime, does that even exist on Windows? I'm willing to accept that in your case, the lack of 64-bit builds may not be your fault, but the GP's comments still apply - just in a slightly different way. There *should* be stable, 64-bit versions of your app's dependencies by now.
Really though... QuickTime? Do people still use that on Windows?
Have you looked at the specs of modern smartphones? Dual core CPUs are increasingly commonplace, with quad core on the way - in fact, already here in some of the high-end tablets. We're talking about Android devices here, not sub-£50 "feature phones". Comparing the tricks needed on this sort of hardware with what was required to squeeze performance out of DOOM-era PCs is an insult to the ingenuity of the programmers behind the early ground-breaking titles. OpenGL ES 1.0 has been available since API level 4 (Android 1.6), and 2.0 available since API level 8 (Android 2.2).
The primary language for Android development is Java. You *can't* go "pretty deep into the guts" from so high up; that's the very reason you can run the same bytecode on x86 and ARM devices. Yes, there's always the NDK if you really want to use C/C++, but if you stray outside the realm of the supported libraries then you deserve everything you get.
MASSIVE DISCLAIMER: I'm only just getting started with Android development myself. Still, I have to wonder how many of the problems lie with the platform, and how many lie with developers not really understanding what they're working with, assuming that the size and nature of the audience automatically turns mobile game development into some sort of free lunch.
* We all know that GPUs have driver issues, but don't rule out the possibility that issues are really to do with your own code: in my limited experience with OpenGL on the desktop, it's easy to write something that only works on certain hardware because you have unintentionally violated the spec, for example by setting something outside its officially specified range of values, or assuming some default piece of state which the standards don't mandate. Unless you're writing the next Unreal, this is more likely than uncovering driver issues with your 2.5D platformer or simplistic first-person engine. Keep your rendering pipeline as simple as it can be.
* Apps published on the marketplace had (until very recently) a size limit of 50mb. Anything above that had to be installed via a follow-up download within the app itself, which adds complexity, and increases the chances of failure. This limit has now been raised to 4GB, but before that, any developer blowing the limit ought to have thought long and hard about whether they really needed to before going down that route. Even if you get it right, there will still be scores of complaints from users who just don't understand that trying to download several hundred megabytes (non-resumable) over a patchy GPRS connection is just not going to end well, no matter how much care you take to warn them up front.
* I could be missing something here, but it appears to me that Android doesn't hand-hold your application through state management, especially if you're using OpenGL. This isn't just about saving basic state such as high scores, but the much lower-level business of simply writing something which is robust in the face of how Android handles multi-tasking. Read up on what events can and cannot cause an app's EGL context to get trashed, and what exactly you need to do when that happens. Remember the bad old days not so long ago, when alt-tabbing was a good way to crash full-screen games on Windows? Well, those days are still with us, just not on the same platform.
* Another good thing to understand is how to use the manifest. Declare what screen sizes and orientations you support, what texture format support you expect from the hardware, and so on. I have no evidence of this, but it wouldn't surprise me if some devices claim support for texture formats which they can't actually handle (those pesky GPU vendors), but hey, sometimes issues are out of the developer's hands - that's what trial versions are for, right?
I'm not saying it's easy. I don't fully understand how to navigate my way around most of the above issues myself, but rather than le
By choosing TLS as the underlying transport, inspecting traffic for debugging or monitoring purposes becomes nigh on impossible. It will only be possible to capture traffic at the application level, after decryption and decapsulation (which, depending on the nature of any given bug, may be too late), or if it originates from servers you own (i.e. the server's private key is available to you). SPDY proxies will become dumb pipes, unable to perform any sort of content caching, unless users are willing to accept that the proxy may perform MITM on their traffic. For such MITM to be feasible, users need to trust a CA certificate associated with the proxy, and rely on the proxy performing upstream certificate checks on their behalf, because the browser no longer has a single end-to-end TLS session with the origin server. In corporate and other "managed" environments, people often find this acceptable in moderation*, but I would be worried if this became the norm - it creates a mind-set whereby it's acceptable to breach users' privacy, and the more proxy vendors have incentive to implement the necessary (proprietary) code, the more scope there is for them to get it wrong, completely undermining security.
Not to mention that introducing a mux/demux layer in between the network traffic and the individual requests/responses greatly increases the complexity needed to implement a proxy compared to plain-old HTTP.
Losing the functionality of caching proxies would seem counter to Google's goal of speeding up the Web. Losing the ability to monitor and filter network traffic will greatly diminish the ability of schools, employers, public hotspot providers etc. to enforce acceptable usage policies, to the extent that some - especially employers - may simply resort to blocking web access outright.
IMHO, the behaviour of SPDY proxies needs to be tightly specified, if they are going to exist. Standardise MITM behaviour, so that users and admins are aware of the pros and cons. Make it mandatory that end users are warned when MITM is taking place. Perhaps introduce new extensions, such as the ability for the proxy to establish TLS with the browser using its own certificate, but transmit a copy of any origin server certificates corresponding to proxied requests, so that the browser isn't entirely at the proxy's mercy WRT certificate verification. Perhaps introduce the ability to multiplex requests to different domains on the same connection, something a browser can't do when talking directly to distinct origin servers.
Note that similar concerns apply to reverse proxies, used by website providers themselves to speed up their own infrastructure. It may seem desirable for both front-end caching and back-end servers to use SPDY, but establishing TLS sessions between two halves of the same infrastructure, over the LAN, will be detrimental to resource usage.
* Bear in mind that currently, MITM is only necessary for HTTPS sites, which means that there are vast swathes of in-the-clear HTTP traffic for which caching doesn't introduce any inherent security concerns. By making *everything* use TLS, MITM becomes a consideration if you want to perform *any* caching/filtering at all, not just caching/filtering of secure sites. If there is no longer any distinction between secure and insecure sites, how does even a responsible admin know where to draw the line?
Yeah... the first version is never going to work through a proxy. If the proxy supports HTTP 1.1 and is well coded, it may either strip the upgrade header (in which case the server will drop down to the fall-back method), or respond with something like an error 501 (unimplemented), in which case the client could drop down to the fall-back method itself (i.e. re-send the request without the upgrade header). If the proxy only supports HTTP 1.0, it will probably send the upgrade header on to the server blindly without understanding it, in which case it will come down to how well behaved the server is: if it notices the request version is only 1.0, it should technically drop to the fall-back method, since the upgrade mechanism wasn't defined in 1.0; however it may not do so, in which case things will go wrong, most likely in the form of the server's response being truncated.
The second version is slightly less bad. Polling might not be great for resource usage, but at least it remains within the realms of valid HTTP. The fact that the server's response bodies are actually queries, and the client sends the answers as POST request bodies, is neither here nor there from the proxy's point of view. It's still a hack, but there's no reason a well-behaved proxy shouldn't handle the data.
The particular proxy I work on purposefully downgrades requests to HTTP 1.0, to get away from a variety of HTTP 1.1 "features" where support is assumed rather than negotiated, such as chunked transfer coding. This still doesn't stop the occasional broken webserver from sending a response branded as HTTP 1.0 but using features which only exist in 1.1. One thing I can say for the "protocol" you linked to is that at least it's correctly negotiated.
I think part of the problem stems from a common assumption amongst developers that "uses HTTP" equates to "works through firewalls", which is just plain wrong. I can kind of understand why HTTP abuse happens in the context of JavaScript, but when the client isn't even a browser - as is the case with the SHOUTcast/Icecast abomination, where data travels over port 80 and kinda looks like HTTP but isn't (responses begin with "ICY", for starters) - just make a new protocol, FFS!
Unfortunately, I don't have a good answer for you. However, I would like to point out that in my opinion, your question typifies what is wrong with trying to use HTML, HTTP and JavaScript as a general purpose development platform. The reason this isn't easy is because long polling is a hack, as are all "push" technologies. HTTP was only designed as a simple, one-way request/response protocol; clients make requests, and the server responds.
I'm not entirely convinced that running arbitrary code directly from the browser is a good idea, regardless of whether or not it works across many platforms; but if people really want to take application development in that direction, can we please design technologies which are up to the task, and stop abusing ones which were never intended to be used that way?
Disclaimer: at $DAYJOB I develop a web proxy; HTTP abuse makes me cry.
Slashdot Mirror
Mod parent up. If anything, this graph shows that KDE's downward trend is ever-so-slightly steeper, though I'm not inclined to call the difference significant.
Then when you need to scale it up, or introduce some serious data processing, you can just buy servers with larger core counts and... oh wait. It's all single-threaded. Never mind.
I prefer DERP. Delete, Edit, Read and Produce. Users are actually well ahead of the technology curve here - ask any tech support worker, customers have been DERPing for years...
I don't understand. What's so non-portable about a GLSL fragment shader?
I don't use KDE, but I can't help thinking that people who recommend disabling these things - and I've read a lot of similar recommendations - are somewhat missing the point. They're enabled by default because they're supposed to work. The mail client that ships as part of the application suite should not be useless.
I've had some painful experiences with Evolution on GNOME over the years*. I moaned about it, filed bugs, commented on existing bugs, and sometimes just had to give in and use a web-based front-end for email. My underlying feelings are much the same: Evolution is supposed to work, so at no point did I recommend to anyone that they just disable it and move on.
Don't sweep these things under the rug!
* What is it about mail, calendaring & contacts that seems to be so difficult for open-source software to get right?
Hmm. I wonder if I wrote an app that was nothing BUT progress bar, if people would go for it.
Like this one, you mean? http://progressquest.com/
Correction: once you have the header, you might know how large the file is. The server may neglect to provide that information, or it may be wrong (e.g. sending the uncompressed length of data which is compressed for transport - yes, I have seen this). I worked on HTTP proxies for ~7 years, so I can say with some authority that HTTP is not a pretty standard, even when implemented correctly - which, all too often, it is not.
The progress bar on the HTTP download doesn't show the amount of remaining time in the bar. It shows the number of bytes remaining in the bar; the number of bytes remaining can't go into reverse.
True, it can't go into reverse - it can be unknown, though. The Content-Length header isn't mandatory in an HTTP response. This is presumably a legacy thing pre-dating any serious HTTP standardisation, but still hangs around to account for things like dynamically generated content and streaming media. In such cases, all that is required of the server is closing the connection when the content has been sent.
Unfortunately - due either to oversight, poor configuration, or poor programming - it's not unheard of for static, known-size content to be delivered without a Content-Length.
IMHO the panel menu in GNOME 3.6 is actually *worse* than in Unity or OS X. In Unity & OS X, I believe, the menu that appears there is what would normally appear at the top level in the current window - so the implementation works for all applications which use a supported GUI toolkit, and the menu items are at least visible, albeit not attached to the application itself.
In GNOME, the panel menu is not automatically populated with the application's top-level menu items; its contents are application-specific. The contents are not always visible, but appear in a pop-up menu attached to the application icon (you know, that useless-looking thing that currently just serves to show the name of the currently focussed app). Because the contents are both application-specific and hidden by default, it's not obvious at all what (if anything) is there for any given app, and when you *do* open the menu (using the mouse or the unchangeable keyboard shortcut), none of the items in the menu have accelerator keys.
In short, it's a usability nightmare with no redeeming features, and I don't know why they're pushing ahead with it.
I'm always curious what people find bad about Gnome 3 - it's about the best desktop environment I've used IMHO. There are a few niggles:
1. They have removed some options for the sake of simplicity which really shouldn't have been removed, and wouldn't have made things more complex if they were there. For example, not having a "disabled" option in the DPMS timeout is a WTF, as is hiding the "Power off" option until you press the magic "Alt" key (with no visual cues that you could press Alt to get at it).
Power off is now visible by default in 3.6, so this niggle has been fixed.
3. They've abolished minimise. However, shading windows is still possible and that's almost as good.
You can re-enable the minimise button with GNOME Tweak Tool. However, because there is no taskbar work-alike, minimised windows don't visibly "go anywhere" and you have to alt-tab or use the Activities view to switch back to them.
4. Focus stealing is a problem - Compiz/Beryl did a much better job at stopping this.
Really? I have no issues in this regard.
I should mention that I thought Gnome 2 was pretty much the worst DE I've ever used - that seemed to be an exercise in copying the worst bits of Windows and removing any options that might make it tollerable. Up until Gnome 3, I was using E17, largely because it was light, fast and just got out of my way when I wanted to get stuff done.
I found GNOME 2 incredibly useful. In fact, if you liked E17 because it got out of your way, I'm surprised you're so happy with GNOME 3, where the shell forcibly takes over whenever you use the Activities view to switch windows/launch things. That doesn't fit with my definition of getting out of the way. Then again, I never stuck with the default panel layout in GNOME 2. I had a single top panel, with the application menu on the left, clock/calendar, a selection of quick launchers, the workspace switcher, and the window menu - no taskbar. So in some ways, it actually resembled GNOME 3 more than the default GNOME 2 layout, which is why the new minimise behaviour doesn't bother me.
What *does* bother me in 3.6, and has me worried for the future, is the stupid application menu in the top panel. Some apps use it, some don't; for those that do, there seems to be no rhyme or reason behind what goes in menus attached to the application itself, and what goes in the menu attached to the panel. Desktop applications which aren't part of the GNOME suite will probably never use it, and it doesn't work the same way as the panel menu in Unity, so I can only imagine the fragmentation getting worse, not better. Also the keyboard shortcut for it is annoying (super-F10 or something equally unintuitive), undiscoverable and I believe unconfigurable. When I first saw mock-ups of GNOME Shell, I didn't think I would like it at all, but now it's a reality I actually do quite like it, with the exception of the panel menu. I don't like the direction they're taking the application suite, with a tendency towards hiding menus, removing the titlebar from maximised windows (so how do you un-maximise with the mouse?), and other misguided "simplifications".
If those answers are the truth, what's wrong with them? They don't say anything particularly bad about the workplace, just that the previous employee had other ideas about what they wanted to do.
I was thinking the exact same things. Identifying the hardware is fundamentally different from identifying the person currently using it, and being able to state unequivocally that they are authorising whatever action is taking place. Plus, as you said, hardware gets upgraded. Even worse, though, is that hardware also fails; particularly high-end GPUs nearing the end of a life spent being slightly too hot. Unexpected hardware failure could leave users with no overlap in the usable life of old & new components, meaning they cannot log in to existing accounts in order to register the fingerprint of the new hardware. Also, unless there's a hidden cache of documents I'm missing somewhere, I can't find any details of what these "unclonable functions" actually are, just that they exist. Are they robust against simple replay attacks?
This all smells like a bad idea to me; something cooked up by a bunch of theorists with very little grounding in practicality. Not sure what part of this could be a "good thing", to be honest.
I thought I'd take a gamble on this one, and actually read TFA - even before reading the comments. I thought there would be a nice picture or two, maybe a few links to pages about the device itself. But you know what I got instead?
France.
No pictures, no related links at the end, and only one word in the entire article itself turned into a link - the word "France."
Tooltip? "Full coverage of France."
FFFFFFFUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
2) There are other methods to unlock on a touch screen. For example MeeGo's double press to unlock.
Yes there are other methods, but generally speaking, once you've got a device with a touchscreen, only so many of those methods are actually practical and sensible - it's a flat, touch-sensitive screen, so they're all going to revolve around pressing it, dragging your finger across it, or some combination of the two.
Where's the patent for "double press to unlock"? Oh, wait, there isn't one, because patenting the concept probably didn't even cross the minds of the people who came up with it!
When it doesn't validate, you reject it. Or, in the case of a replacement for an "extensible" protocol, you do something more subtle - such as, accept something which is well-formed XML but contains unrecognised tags, by skipping over the unrecognised tags. Much as is done in HTML itself.
Once you've written a few programs which accept data from the public internet, you come to greatly appreciate the value of protocols whose syntax is easy to parse, and whose semantics are simple to understand. The simpler the parsing code, the less likely it is to contain exploitable bugs; the simpler the semantics, the easier it is to write standards-compliant logic, and have a wide range of client & server implementations which interoperate happily. HTTP in its modern form - i.e. augmented over the years with such features as persistent connections, pipe-lining, chunked encoding, multi-part bodies, compression, cookies & caching - is neither easy to parse, nor easy to understand once parsed. It needs to be taken out and shot, along with this whole laissez-faire attitude to standards compliance & well-formed-ness which permeates web standards.
It's caught my attention too. You're not alone. I regularly cringe - or even groan out loud - when reading pieces published online in various places; Slashdot submissions being a frequent source of offence.
What *I* want to know is what the poor horse did wrong in all this. Why are they helping Uncle Jack to off the poor beast?
Burma-Shave
But the business decision has its roots in technical issues, to a certain extent. An unstable app isn't going to get good reviews, and an app with bad reviews isn't going to sell well. We haven't seen the code, but it's entirely possible that different development practices could have lead to Android issues taking up less than 20% of their time. They use a pre-exising cross-platform framework (Unity), but still have issues with shaders and texture formats? Sounds like their shaders aren't as well written as they perhaps thought, or they're doing something fruity in their content production pipeline. Having looked at screenshots, I'm not even sure what they're using shaders or exotic texture formats *for* - perhaps they should really be targetting OpenGL ES 1.0/1.1, not 2.0. Perhaps Unity as a framework just isn't very stable on Android, in which case they need to either ditch the framework or make use of their support entitlement (assuming you get some when you purchase a license).
Given that they only support two platforms to start with, spending 20% of their time on one of them doesn't sound too unreasonable. You can't expect your product to do well on a given platform if you don't treat it as a first-class target. Of course they're painting the end result as a pure business decision, but when other developers continue to profit from Android apps, you have to wonder why they were only making 5% of their money from one of a grand total of two supported platforms.
As with so many things in the world of computing, it's a trade-off. If the OS wants to maintain an application's EGL context when the user switches applications, it either needs its own state management so it can recreate that context behind the scenes without any specific application support (I imagine this would be quite complex, if it's even possible in the general case), or it has to take RAM hit of leaving the context intact, meaning decreased performance and/or fewer concurrent applications before things start being forcibly terminated. The EGL spec has a section on power management for a reason.
I've never developed for iOS, so I don't know exactly what it does, but I can understand why Android works the way it does - developer unfriendliness aside. Applications don't terminate the moment the user switches away from them, so they don't have to be launched from scratch if the user switches back; however, if something else wants to perform accelerated rendering whilst your app doesn't have focus, your app loses its grasp on the GPU. Personally I don't think this is unreasonable. AFAIK, if your app doesn't use OpenGL, loss of focus (distinct from termination) doesn't imply anything special.
Just hook into the right events, re-upload your textures & set desired GPU state before trying to render the next frame, and you're good to go.
64-bit builds of libcurl are flaky? That's news to me. I use it at home on Gentoo and at work on Fedora, both 64-bit native, and don't have any issues. Maybe there's something "interesting" (read: not set up correctly) in the Windows parts of its build system, but I doubt it's anything inherent in the code. As for 64-bit QuickTime, does that even exist on Windows? I'm willing to accept that in your case, the lack of 64-bit builds may not be your fault, but the GP's comments still apply - just in a slightly different way. There *should* be stable, 64-bit versions of your app's dependencies by now.
Really though... QuickTime? Do people still use that on Windows?
Have you looked at the specs of modern smartphones? Dual core CPUs are increasingly commonplace, with quad core on the way - in fact, already here in some of the high-end tablets. We're talking about Android devices here, not sub-£50 "feature phones". Comparing the tricks needed on this sort of hardware with what was required to squeeze performance out of DOOM-era PCs is an insult to the ingenuity of the programmers behind the early ground-breaking titles. OpenGL ES 1.0 has been available since API level 4 (Android 1.6), and 2.0 available since API level 8 (Android 2.2).
The primary language for Android development is Java. You *can't* go "pretty deep into the guts" from so high up; that's the very reason you can run the same bytecode on x86 and ARM devices. Yes, there's always the NDK if you really want to use C/C++, but if you stray outside the realm of the supported libraries then you deserve everything you get.
MASSIVE DISCLAIMER: I'm only just getting started with Android development myself. Still, I have to wonder how many of the problems lie with the platform, and how many lie with developers not really understanding what they're working with, assuming that the size and nature of the audience automatically turns mobile game development into some sort of free lunch.
* We all know that GPUs have driver issues, but don't rule out the possibility that issues are really to do with your own code: in my limited experience with OpenGL on the desktop, it's easy to write something that only works on certain hardware because you have unintentionally violated the spec, for example by setting something outside its officially specified range of values, or assuming some default piece of state which the standards don't mandate. Unless you're writing the next Unreal, this is more likely than uncovering driver issues with your 2.5D platformer or simplistic first-person engine. Keep your rendering pipeline as simple as it can be.
* Apps published on the marketplace had (until very recently) a size limit of 50mb. Anything above that had to be installed via a follow-up download within the app itself, which adds complexity, and increases the chances of failure. This limit has now been raised to 4GB, but before that, any developer blowing the limit ought to have thought long and hard about whether they really needed to before going down that route. Even if you get it right, there will still be scores of complaints from users who just don't understand that trying to download several hundred megabytes (non-resumable) over a patchy GPRS connection is just not going to end well, no matter how much care you take to warn them up front.
* I could be missing something here, but it appears to me that Android doesn't hand-hold your application through state management, especially if you're using OpenGL. This isn't just about saving basic state such as high scores, but the much lower-level business of simply writing something which is robust in the face of how Android handles multi-tasking. Read up on what events can and cannot cause an app's EGL context to get trashed, and what exactly you need to do when that happens. Remember the bad old days not so long ago, when alt-tabbing was a good way to crash full-screen games on Windows? Well, those days are still with us, just not on the same platform.
* Another good thing to understand is how to use the manifest. Declare what screen sizes and orientations you support, what texture format support you expect from the hardware, and so on. I have no evidence of this, but it wouldn't surprise me if some devices claim support for texture formats which they can't actually handle (those pesky GPU vendors), but hey, sometimes issues are out of the developer's hands - that's what trial versions are for, right?
I'm not saying it's easy. I don't fully understand how to navigate my way around most of the above issues myself, but rather than le
By choosing TLS as the underlying transport, inspecting traffic for debugging or monitoring purposes becomes nigh on impossible. It will only be possible to capture traffic at the application level, after decryption and decapsulation (which, depending on the nature of any given bug, may be too late), or if it originates from servers you own (i.e. the server's private key is available to you). SPDY proxies will become dumb pipes, unable to perform any sort of content caching, unless users are willing to accept that the proxy may perform MITM on their traffic. For such MITM to be feasible, users need to trust a CA certificate associated with the proxy, and rely on the proxy performing upstream certificate checks on their behalf, because the browser no longer has a single end-to-end TLS session with the origin server. In corporate and other "managed" environments, people often find this acceptable in moderation*, but I would be worried if this became the norm - it creates a mind-set whereby it's acceptable to breach users' privacy, and the more proxy vendors have incentive to implement the necessary (proprietary) code, the more scope there is for them to get it wrong, completely undermining security.
Not to mention that introducing a mux/demux layer in between the network traffic and the individual requests/responses greatly increases the complexity needed to implement a proxy compared to plain-old HTTP.
Losing the functionality of caching proxies would seem counter to Google's goal of speeding up the Web. Losing the ability to monitor and filter network traffic will greatly diminish the ability of schools, employers, public hotspot providers etc. to enforce acceptable usage policies, to the extent that some - especially employers - may simply resort to blocking web access outright.
IMHO, the behaviour of SPDY proxies needs to be tightly specified, if they are going to exist. Standardise MITM behaviour, so that users and admins are aware of the pros and cons. Make it mandatory that end users are warned when MITM is taking place. Perhaps introduce new extensions, such as the ability for the proxy to establish TLS with the browser using its own certificate, but transmit a copy of any origin server certificates corresponding to proxied requests, so that the browser isn't entirely at the proxy's mercy WRT certificate verification. Perhaps introduce the ability to multiplex requests to different domains on the same connection, something a browser can't do when talking directly to distinct origin servers.
Note that similar concerns apply to reverse proxies, used by website providers themselves to speed up their own infrastructure. It may seem desirable for both front-end caching and back-end servers to use SPDY, but establishing TLS sessions between two halves of the same infrastructure, over the LAN, will be detrimental to resource usage.
* Bear in mind that currently, MITM is only necessary for HTTPS sites, which means that there are vast swathes of in-the-clear HTTP traffic for which caching doesn't introduce any inherent security concerns. By making *everything* use TLS, MITM becomes a consideration if you want to perform *any* caching/filtering at all, not just caching/filtering of secure sites. If there is no longer any distinction between secure and insecure sites, how does even a responsible admin know where to draw the line?
Yeah... the first version is never going to work through a proxy. If the proxy supports HTTP 1.1 and is well coded, it may either strip the upgrade header (in which case the server will drop down to the fall-back method), or respond with something like an error 501 (unimplemented), in which case the client could drop down to the fall-back method itself (i.e. re-send the request without the upgrade header). If the proxy only supports HTTP 1.0, it will probably send the upgrade header on to the server blindly without understanding it, in which case it will come down to how well behaved the server is: if it notices the request version is only 1.0, it should technically drop to the fall-back method, since the upgrade mechanism wasn't defined in 1.0; however it may not do so, in which case things will go wrong, most likely in the form of the server's response being truncated.
The second version is slightly less bad. Polling might not be great for resource usage, but at least it remains within the realms of valid HTTP. The fact that the server's response bodies are actually queries, and the client sends the answers as POST request bodies, is neither here nor there from the proxy's point of view. It's still a hack, but there's no reason a well-behaved proxy shouldn't handle the data.
The particular proxy I work on purposefully downgrades requests to HTTP 1.0, to get away from a variety of HTTP 1.1 "features" where support is assumed rather than negotiated, such as chunked transfer coding. This still doesn't stop the occasional broken webserver from sending a response branded as HTTP 1.0 but using features which only exist in 1.1. One thing I can say for the "protocol" you linked to is that at least it's correctly negotiated.
I think part of the problem stems from a common assumption amongst developers that "uses HTTP" equates to "works through firewalls", which is just plain wrong. I can kind of understand why HTTP abuse happens in the context of JavaScript, but when the client isn't even a browser - as is the case with the SHOUTcast/Icecast abomination, where data travels over port 80 and kinda looks like HTTP but isn't (responses begin with "ICY", for starters) - just make a new protocol, FFS!
Unfortunately, I don't have a good answer for you. However, I would like to point out that in my opinion, your question typifies what is wrong with trying to use HTML, HTTP and JavaScript as a general purpose development platform. The reason this isn't easy is because long polling is a hack, as are all "push" technologies. HTTP was only designed as a simple, one-way request/response protocol; clients make requests, and the server responds.
I'm not entirely convinced that running arbitrary code directly from the browser is a good idea, regardless of whether or not it works across many platforms; but if people really want to take application development in that direction, can we please design technologies which are up to the task, and stop abusing ones which were never intended to be used that way?
Disclaimer: at $DAYJOB I develop a web proxy; HTTP abuse makes me cry.