The trouble is people who believe in alternative medicine (holistic, naturopathy, reiki, chiro etc.) think their claims are exempt from the standard of proof that applies to conventional medicine. i.e. that it be demonstrated that the outcome of a treatment is better than a placebo.
Demand evidence of this (e.g. double blinded studies) and they'll provide anecdotes. If you go to the effort of explaining why anecdotes are weak evidence and prone to confirmation bias, you'll get increasingly bizarre and unconvincing explanations why the scientific method cannot possibly test these claims. Push hard enough and inevitably the response turns into a big rant about the FDA and big pharma, about how they kill people, are suppressing natural cures etc. What you won't get at any stage is actual evidence to support their claims.
More likely Glass will find a purpose for drones working in giant warehouses fulfilling orders - go to row X and pick up item Y for order Z etc.
It reminds me a little of Segway - heralded as a social revolution that would transform the way we travel. Then it turns out that riding a segway made someone look like an asshole so it was relegated to specialist roles - oil tankers, warehouses, promenades etc.
Multinationals use Ireland in the same way called the double Irish system. Ireland allows an Irish registered company to domicile in a tax haven (so it's tax liabilities might be in Bermuda). So multinationals establish 2 Irish companies. The first is legit and employs people and runs sales & services. This company charges other subsidiaries worldwide for its work so the tax liabilities move to Ireland. Then the first company pays the second a massive chunk of its revenues as royalties. Since the second company is domiciled in a tax haven there is no tax on these royalties and the multinational only pays tax on the remainder. And Ireland has low corporation tax for that part too.
There is supposedly a double Irish Dutch sandwich variant which presumably yields similar results. Apparently the loophole is being closed since most countries are getting so pissed off with tax avoidance / evasion that they're cooperating (or being coerced) into stamping it out.
I don't see any use for the feathers on it's arm unless they unfurled to make a bigger impression.
Air braking, manoeuvrability & stabilization would be good uses. e.g. an ostrich can zig zag while running by sticking out its wings which might be useful if it's being chased by a predator or trying to catch prey.
Red Hat used to ship with Enlightenment (and employ its author) but dumped it for GNOME and Sawmill IIRC. Red Hat wanted a more conservative and familiar desktop experience and E wasn't delivering on that.
Weston has support for RDP. i.e. you establish a remote session to it via a RDP client and you see your apps. RDP has a seamless mode though I don't know if the compositor supports that although it could in theory.
It's a way for client applications to connect to a display, receive input events, and render into surfaces without using X11. The surfaces are rendered via a compositor which could push the result out to the screen or remotely. It's less complex, context switching and data duplication than X11 so it should be more efficient and yield a better desktop experience.
So what they claw back from the CPU overhead of decoding MP3, they lose by hogging the IO and increased memory use (and paging). Sounds a pretty weak rationalisation really. Besides, if it really were an issue for dual core machines, then they could decode and cache the audio on those machines rather than inflicting this stupid overhead on every machine.
You just know that Apple will continue to use a proprietary connector. I also wouldn't be surprised if they concoct some bullshit reason to put a chip into the cable that hobbles charging unless you happen to use an Apple authorised charger.
How do you think we can get through to the anti-vaxxers?
Require mandatory vaccination. The only exemption being for children who cannot receive the vaccine for medical reasons. And if an unvaccinated child is subsequently harmed by contracting measles prosecute the parents for child endangerment.
Not so much pixel scraping but pixel pushing. Most apps render themselves into a pixmap and push it around the network. They're not using X primitives. They *might* be using XRender primitives or they might not. It's still a large amount of data, and combined with the synchronous nature of X, it's horribly inefficient. A remoting enabled compositor for Wayland could probably work better than X, even for the one thing that people always go on about X being good for.
So enlighten us where I have gone wrong please. And for someone quick to call it "your pet topic", you sure as hell have quite the posting history about it yourself. It's called projection you know.
I don't see how portability is any better or worse for using Wayland than X. If I were to target a new graphics card or kernel with X then I'd have to port the code to that platform, e.g. write a new backend. X may be more accustomed to doing this but the work still has to be done. Why is this not the same for Wayland?
It may be that Wayland / Weston targets Linux in the first instance (just as Linux kernel originally targeted x86 processors) but that does not preclude it from other kernels over time. If someone were to try I suspect the problem would lie less in porting Wayland / Weston and more to do with the sorry state of GPU drivers for other kernels. In the meantime, use X. I doubt it's going away any time soon.
Linux has always featured choice. Personally I dislike KDE and I am critical of it but I'm not required to use it so I don't. Nor are you required to use Wayland. Stick with X for as long as you like. Gather a core of likeminded people and produce a dist that suits your requirements. I'm sure Amish Linux will be a huge hit.
And every software is "unstable untried" until it is. I'm quite certain Wayland will have bugs in it and will fail to function in certain configurations. And those bugs will be fixed, either in Wayland itself or in the code it depends on, e.g. Mesa or display drivers. If it bothers you, don't use it until the bugs are fixed.
And what "missing features" are you talking about? Part of X's problem is it is a veritable kitchen sink of features, most of which are obsolete, inefficient or an impediment to be worked around. And that's the point - Wayland is not attempting to reimplement everything in X. I also hope you're not going to say remoting because that's the compositor's job, not Wayland's and there is a reference remoting implementation in Weston that uses RDP.
And just "some X11 developers"? The most prominent supporters of Wayland are major X11 developers who know how broken X is. Name any prominent X11 developer who is in favour of maintaining the status quo, who thinks X is perfect in its present form or can be fixed without breaking backwards compatibility or without making a complex tangle of obsolete code and extensions even more complex.
And Mir is for Linux too. What's your point? The Linux kernel just happens to provide the event and display hooks that these display server layers need to work efficiently. I'm quite certain that this would not stop Wayland being ported to other kernels or environments should there be reason to. Or just use X. Big deal.
Wayland will still be experimental in Fedora 21 and turned on in 22. That means it will have possibly 12 months on Mr but it's still away from any sort of widespread use.
I don't see Mir as being in much competition though. Canonical have hobbled interest in it due to the restrictive licence and contributors agreement and most people regard it as divisive. I will be interested to see what the gubuntu dist do when GNOME shell is fully Wayland compatible - whether they intend to use it or if they will be constrained by Canonical and leave GNOME using X until they can port it to Mir.
There's nothing to stop you picking an OpenGL profile and using that but obviously if you expect your code to be portable then you're going to have choose very carefully. And if portable includes handheld or mobile devices then the profile has to be ES 2.x or 3.x or you have to write two backends (with all the pain that goes with that). So its not all plain sailing. If you have an existing app then porting it may involve considerable effort.
OpenGL is definitely more portable than DirectX but that's not to say it's portable with a few modifications. There are various OpenGL and OpenGL ES profiles, and while they are related they can be radically different in important ways. For example OpenGL ES 1.1 and 2.0 are totally incompatible despite what you might think - 1.1. uses a fixed function pipeline and 2.0 expects you to write shaders for basically everything. OpenGL ES 2.x is roughly but not completely a subset of OpenGL 2.1. Every version of OpenGL supports a different selection of extensions.
Aside from the differences on paper, the actual implementations can be broken, buggy or inefficient. e.g. Some older desktop drivers might not offer an ES 2.x profile, or it could be hopelessly crap.
There is no GLU / GLUT either for ES 2.x and every platform implements its own equivalent but proprietary set of APIs. So you may discover a lot of work is required to fix that. Then you may discover that one platform or language's bindings are different from another in subtle but annoying ways, e.g. there are several OpenGL ES 2.x bindings for Java and one might return a handle in an int[] array while another expects you to supply a 1-element sized IntBuffer. Annoyances which add up.
In summary, yes you can port code, and OpenGL is definitely one family of APIs that offers support across a wide selection of devices. But it's not guaranteed to be simple and probably won't be. The best bet is use a good third party library (e.g. libgdx) and let the library hide as much of the work as possible.
Never attribute to malice what can be explained by incompetence. Perhaps it was an inside job but MtGox was always a cowboy operation and it wasn't the only service to be hit with the same hack.
I wonder how many people would have had second thoughts about investing if they'd seen the corpulent greaseball they were entrusting their money to.
Slashdot Mirror
Demand evidence of this (e.g. double blinded studies) and they'll provide anecdotes. If you go to the effort of explaining why anecdotes are weak evidence and prone to confirmation bias, you'll get increasingly bizarre and unconvincing explanations why the scientific method cannot possibly test these claims. Push hard enough and inevitably the response turns into a big rant about the FDA and big pharma, about how they kill people, are suppressing natural cures etc. What you won't get at any stage is actual evidence to support their claims.
It reminds me a little of Segway - heralded as a social revolution that would transform the way we travel. Then it turns out that riding a segway made someone look like an asshole so it was relegated to specialist roles - oil tankers, warehouses, promenades etc.
And Glass is one of those those technologies.
Sorry I misworded the second sentence - I meant the dinosaur in the article.
There is supposedly a double Irish Dutch sandwich variant which presumably yields similar results. Apparently the loophole is being closed since most countries are getting so pissed off with tax avoidance / evasion that they're cooperating (or being coerced) into stamping it out.
I don't see any use for the feathers on it's arm unless they unfurled to make a bigger impression.
Air braking, manoeuvrability & stabilization would be good uses. e.g. an ostrich can zig zag while running by sticking out its wings which might be useful if it's being chased by a predator or trying to catch prey.
Red Hat used to ship with Enlightenment (and employ its author) but dumped it for GNOME and Sawmill IIRC. Red Hat wanted a more conservative and familiar desktop experience and E wasn't delivering on that.
Weston has support for RDP. i.e. you establish a remote session to it via a RDP client and you see your apps. RDP has a seamless mode though I don't know if the compositor supports that although it could in theory.
It's a way for client applications to connect to a display, receive input events, and render into surfaces without using X11. The surfaces are rendered via a compositor which could push the result out to the screen or remotely. It's less complex, context switching and data duplication than X11 so it should be more efficient and yield a better desktop experience.
Wayland is a protocol for client apps to talk with a compositor. The compositor can offer remoting if it wants to and indeed Weston does.
So what they claw back from the CPU overhead of decoding MP3, they lose by hogging the IO and increased memory use (and paging). Sounds a pretty weak rationalisation really. Besides, if it really were an issue for dual core machines, then they could decode and cache the audio on those machines rather than inflicting this stupid overhead on every machine.
You just know that Apple will continue to use a proprietary connector. I also wouldn't be surprised if they concoct some bullshit reason to put a chip into the cable that hobbles charging unless you happen to use an Apple authorised charger.
Weston supports RDP in about 1000 lines of code hooked up to FreeRDP. So yes it does remoting and any other compositor can do it too.
How do you think we can get through to the anti-vaxxers?
Require mandatory vaccination. The only exemption being for children who cannot receive the vaccine for medical reasons. And if an unvaccinated child is subsequently harmed by contracting measles prosecute the parents for child endangerment.
My understanding is that mammoths are fairly conspicuous creatures, what with them being giant hairy elephants.
Not so much pixel scraping but pixel pushing. Most apps render themselves into a pixmap and push it around the network. They're not using X primitives. They *might* be using XRender primitives or they might not. It's still a large amount of data, and combined with the synchronous nature of X, it's horribly inefficient. A remoting enabled compositor for Wayland could probably work better than X, even for the one thing that people always go on about X being good for.
So enlighten us where I have gone wrong please. And for someone quick to call it "your pet topic", you sure as hell have quite the posting history about it yourself. It's called projection you know.
It may be that Wayland / Weston targets Linux in the first instance (just as Linux kernel originally targeted x86 processors) but that does not preclude it from other kernels over time. If someone were to try I suspect the problem would lie less in porting Wayland / Weston and more to do with the sorry state of GPU drivers for other kernels. In the meantime, use X. I doubt it's going away any time soon.
Linux has always featured choice. Personally I dislike KDE and I am critical of it but I'm not required to use it so I don't. Nor are you required to use Wayland. Stick with X for as long as you like. Gather a core of likeminded people and produce a dist that suits your requirements. I'm sure Amish Linux will be a huge hit.
And every software is "unstable untried" until it is. I'm quite certain Wayland will have bugs in it and will fail to function in certain configurations. And those bugs will be fixed, either in Wayland itself or in the code it depends on, e.g. Mesa or display drivers. If it bothers you, don't use it until the bugs are fixed.
And what "missing features" are you talking about? Part of X's problem is it is a veritable kitchen sink of features, most of which are obsolete, inefficient or an impediment to be worked around. And that's the point - Wayland is not attempting to reimplement everything in X. I also hope you're not going to say remoting because that's the compositor's job, not Wayland's and there is a reference remoting implementation in Weston that uses RDP.
And just "some X11 developers"? The most prominent supporters of Wayland are major X11 developers who know how broken X is. Name any prominent X11 developer who is in favour of maintaining the status quo, who thinks X is perfect in its present form or can be fixed without breaking backwards compatibility or without making a complex tangle of obsolete code and extensions even more complex.
It's hard to see why anybody with an interest in Linux would hope it be dropped.
And Mir is for Linux too. What's your point? The Linux kernel just happens to provide the event and display hooks that these display server layers need to work efficiently. I'm quite certain that this would not stop Wayland being ported to other kernels or environments should there be reason to. Or just use X. Big deal.
I don't see Mir as being in much competition though. Canonical have hobbled interest in it due to the restrictive licence and contributors agreement and most people regard it as divisive. I will be interested to see what the gubuntu dist do when GNOME shell is fully Wayland compatible - whether they intend to use it or if they will be constrained by Canonical and leave GNOME using X until they can port it to Mir.
There's nothing to stop you picking an OpenGL profile and using that but obviously if you expect your code to be portable then you're going to have choose very carefully. And if portable includes handheld or mobile devices then the profile has to be ES 2.x or 3.x or you have to write two backends (with all the pain that goes with that). So its not all plain sailing. If you have an existing app then porting it may involve considerable effort.
Aside from the differences on paper, the actual implementations can be broken, buggy or inefficient. e.g. Some older desktop drivers might not offer an ES 2.x profile, or it could be hopelessly crap.
There is no GLU / GLUT either for ES 2.x and every platform implements its own equivalent but proprietary set of APIs. So you may discover a lot of work is required to fix that. Then you may discover that one platform or language's bindings are different from another in subtle but annoying ways, e.g. there are several OpenGL ES 2.x bindings for Java and one might return a handle in an int[] array while another expects you to supply a 1-element sized IntBuffer. Annoyances which add up.
In summary, yes you can port code, and OpenGL is definitely one family of APIs that offers support across a wide selection of devices. But it's not guaranteed to be simple and probably won't be. The best bet is use a good third party library (e.g. libgdx) and let the library hide as much of the work as possible.
I wonder how many people would have had second thoughts about investing if they'd seen the corpulent greaseball they were entrusting their money to.