Perhaps you should read what I said. A car has to make good progress as well as be safe. That means dealing with countless situations which are easy for humans to solve and virtually intractable for a computer.
For example, my car is behind a bus. The bus stops to pick up passengers. I can see from the length of queue whether I'll be there for several minutes and determine if its worth pulling out safely into the oncoming lane to pass the bus. Does the self drive car have a special bus queue length algorithm? Is it going to wait forever? Or a minute? Two minutes? Forever? Can it tell a bus from a truck? Can it tell if the bus has even stopped because it is picking up passengers or because it has broken down?
Or perhaps a road is partially flooded. There is a 50m stretch where the road is only passable by one car in each direction by travelling in the centre where the camber is highest. Drivers in each direction take turns according to how many cars there are behind and oncoming. Does the self drive car just plough through the water? Does it even see the water? Or does it nudge to the centre of the road? Does it act like an asshole and just pull out without waiting its turn? How does it know that it's turn is next? How does it signal intent to the other guy and vice versa? What happens if just starts driving when the other guy is half way up? Will it reverse back or just block the increasingly angy other guy?
Or there are two guys standing on either side of a roadworks with Stop/Go signs. Only one direction can pass at a time. Can your car figure out there are roadworks? Can it read that sign? How does it know when it is safe to go?
Or a road has a new road layout. The lanes have moved around. Perhaps a two way street has become a one way street. This is clearly signposted. Can your car read these signs? Will it just dumbly drive up the street the wrong way until someone thinks to update the map?
The answer for all these examples and hundreds of others is that it highly unlikely it will do the right thing. It has to have an override mode and a competent, unimpaired driver to extricate it from these situations. There are plenty of positives about advanced driving modes and even self drive in some situations. But the time when cars will be able to drive themselves outside of very controlled situations with no override is a long way off.
I could make a self drive car which is extremely safe - every time a leaf obscurs a sensor, or a plastic bag blows across the road, or it senses a guy standing on the road waiting for his lift, or the lane is out, or because it's lost GPS and its stuck in a tunnel. I would hit the brakes and stop or slow right down. See? Very safe. But oops, now we have a car which doesn't make good progress and stops for all kinds of dumb reasons.
So yeah Google or whomever could claim their car is really safe. It doesn't make it necessarily practical. At the very least it requires a human to extricate it from situations like those above and many more. The only way you will see a driverless vehicle with no form of controls any time soon is in controlled conditions and even then it will need some kind of override. e.g. I could imagine a transport system which used a dedicated lane in airports to move people between terminals. I can't imagine such a thing working on a public road.
So their car can interpret hand signals of a traffic cop directing traffic at a set of broken lights? That's amazing! Can it also tell the difference between a cop directing traffic and some random crazy guy doing the same?
There are any number of every day scenarios where a self drive car would stop because it had no idea what to do.
There are far too many scenarios on public roads where a self drive car wouldn't know what to do and would require human intervention. At the very least it requires an unimpaired, conscious, qualified human being with their own set of controls who can take over if the need arises or if the car does something dumb.
If these become shuttles or taxis it would have to be in carefully controlled conditions where it is highly unlikely that some event would occur that leaves the vehicle stuck and unable to move. And even there, it's possible that there would have to be a a human sitting in a booth nearby who could override the system if it became stuck.
Er what? Of course they had the authority - you as the user authorised them to do it. If you didn't want OtherOS removed, you should have refused to update your firmware when asked.
And yes it's a no brainer. It was a feature that virtually nobody used that posed a major attack threat to their platform and their revenues. Of course they were going to remove it. Anyone put in their position would have done exactly the same. Even console owners (at least the honest ones) should have been glad the hole was closed presuming they like playing good games instead of shovelware.
Nintendo may not have cared but I guarantee you 3rd party publishers did. The DS, 3DS and Wii all turned into a cesspool of shovelware because the money simply wasn't in these systems for publishers to aim any higher. It's not hard to find stories of companies with ambitious games being stung by poor sales. Think of all the good games you *might* have seen on those systems but never got to enjoy simply because the money wasn't there for them to bother.
OtherOS was removed because it was considered a viable attack vector. Someone had broken through the virtualization layer it ran on and there was a fear that from there they might be able to attack the rest of the system. It's not hard to imagine the ultimate problem - someone producing a burnable ISO for the PS3 which booted, rooted it and installed custom firmware.
That's why OtherOS was removed. It may have been put in for other reasons but I suspect it would have lasted longer if not for the imminent threat. I actually used OtherOS (I doubt many people who did the complaining ever did) and it was cool to be able to run Linux but it was a no brainer to Sony to remove it when it put billions of dollars at risk if they didn't.
Many SoCs support more features than the device they end up in. Some SoCs even require the manufacturer purchase and preload license keys onto the device in order to enable functionality so that it is locked otherwise.
I have no idea what it costs for HP to throw a antenna and bluetooth license in these devices but even if it were.30 cents, they might prefer that money be in their pockets than enable it.
Go to Alibaba.com. The place is FILLED with similar specced tablets in the sub $100 bracket. Most of them are Allwinner devices with a similar res screen and form factor. I suspect that all HP is doing is bulk ordering a bunch of these, putting its badge on the front, applying some quality control and polish to the product and throwing it out at a higher price.
The PS2 and XBox were vulnerable to modchips. The PSP suffered exploits and custom firmware took over. The 360 too was modded although Microsoft bans people from XBL to keep it under control. Nintendo seems to treat copy protection as an afterthought which may explain why their systems are all cracked.
About the only console to withstand attack is the PS3, although Sony had to shut off some features and move code into higher kernel rings to secure it. All that whining over OtherOS being removed and Geohot being prosecuted was Sony protecting their platform from piracy.
If you turned that Trabant into an electric vehicle, you'd have to rebuild the frame and suspension to cope with the weight of the batteries which could add 200-300Kg of weight. And you can bet if you drove in snow that you'd be stuck right next to that Range Rover and even more screwed because of the 2 wheel drive, high torque, and potential problems with range and cold weather.
If a headline ends with a question mark, the answer is almost always "no". e.g."Is this an image of Jesus in a Danish pastry?" No. "Does this medieval painting prove UFOs?" No. "Could red wine be the cure for cancer?" No. etc.
Says who? Other operating systems including popular dists of Linux have well defined end of lifes on their products. Why should Microsoft be expected to support their product indefinitely?
It should be pretty obvious this is what Valve is aiming with all this stuff. I'm sure some of the twitchiest games are unsuitable for streaming but the vast bulk would play just fine. If SteamOS survives at all as a platform it'll probably be as a stick like device which streams games from somewhere else.
On Windows I can login into a PC, walk over to another machine and remote login to that same session. For that you probably want the window manager to host the remote session. But if you have headless machine that is only used in a specific way then perhaps something simpler will do. I don't see that either is precluded.
Wayland is just the API and protocol for clients and servers to allocate & release buffers and pass input and display events around. It doesn't say how those buffers get shown to the user - that's the compositor's job. Weston provides a a reference implementation of remoting demonstrating it is possible. It doesn't mean it's perfect, or comes with a pile of advanced options.
I expect it will improve and there will also be dedicated compositors for headless servers and the like.
It's a reference implementation, a proof of concept to demonstrate to people complaining that yes wayland can in fact be remoted assuming a compositor provides with the support. It's not wayland's job to do the remoting, it's the compositor's. I see no reason to think that once wayland is switched on by default in a dist or two that compositors will explicitly support remoting, or there will be dedicated compositors for that purpose.
Re:Will it really go the pulseaudio way?
on
Wayland 1.5 Released
·
· Score: 3, Informative
Wayland is the protocol that clients talk with the compositor, not the compositor itself. The reference compositor Weston already implements an RDP server and does so in a remarkably small amount of source code.
As for it's performance, it will be no worse than X (or Xvnc) on modern apps because as everyone has stated, most modern apps are pushing pixmaps around anyway. If anything performance has the potential to be better because the remoting protocol can be asynchronous (unlike X) and the server doesn't have a handful of X and extensions processes with all their context switches to worry about.
Re:Will it really go the pulseaudio way?
on
Wayland 1.5 Released
·
· Score: 5, Informative
There is already a reference RDP implementation in Weston. So to answer your question, it's happened already.
It does support remote display (and not just one protocol either) and widget sets will support X backend as long as there are volunteers to maintain it.
Wayland isn't heavily criticized from a technical standpoint. Most of the "criticism" seems to be from people moaning that it's not X. As you say, X will run on top of X and QT / GTK will be have backends that support X and Wayland. It's simply Ludditism from people who think everyone should suffer under a arcane windowing system to support their esoteric (and still supported) use cases.
For example, my car is behind a bus. The bus stops to pick up passengers. I can see from the length of queue whether I'll be there for several minutes and determine if its worth pulling out safely into the oncoming lane to pass the bus. Does the self drive car have a special bus queue length algorithm? Is it going to wait forever? Or a minute? Two minutes? Forever? Can it tell a bus from a truck? Can it tell if the bus has even stopped because it is picking up passengers or because it has broken down?
Or perhaps a road is partially flooded. There is a 50m stretch where the road is only passable by one car in each direction by travelling in the centre where the camber is highest. Drivers in each direction take turns according to how many cars there are behind and oncoming. Does the self drive car just plough through the water? Does it even see the water? Or does it nudge to the centre of the road? Does it act like an asshole and just pull out without waiting its turn? How does it know that it's turn is next? How does it signal intent to the other guy and vice versa? What happens if just starts driving when the other guy is half way up? Will it reverse back or just block the increasingly angy other guy?
Or there are two guys standing on either side of a roadworks with Stop/Go signs. Only one direction can pass at a time. Can your car figure out there are roadworks? Can it read that sign? How does it know when it is safe to go?
Or a road has a new road layout. The lanes have moved around. Perhaps a two way street has become a one way street. This is clearly signposted. Can your car read these signs? Will it just dumbly drive up the street the wrong way until someone thinks to update the map?
The answer for all these examples and hundreds of others is that it highly unlikely it will do the right thing. It has to have an override mode and a competent, unimpaired driver to extricate it from these situations. There are plenty of positives about advanced driving modes and even self drive in some situations. But the time when cars will be able to drive themselves outside of very controlled situations with no override is a long way off.
So yeah Google or whomever could claim their car is really safe. It doesn't make it necessarily practical. At the very least it requires a human to extricate it from situations like those above and many more. The only way you will see a driverless vehicle with no form of controls any time soon is in controlled conditions and even then it will need some kind of override. e.g. I could imagine a transport system which used a dedicated lane in airports to move people between terminals. I can't imagine such a thing working on a public road.
There are any number of every day scenarios where a self drive car would stop because it had no idea what to do.
If these become shuttles or taxis it would have to be in carefully controlled conditions where it is highly unlikely that some event would occur that leaves the vehicle stuck and unable to move. And even there, it's possible that there would have to be a a human sitting in a booth nearby who could override the system if it became stuck.
Your Internet-of-everything lightbulb runs off batteries?
For all the praise Intel gets for supporting open source, their end user support for older graphics chipsets really sucks.
And yes it's a no brainer. It was a feature that virtually nobody used that posed a major attack threat to their platform and their revenues. Of course they were going to remove it. Anyone put in their position would have done exactly the same. Even console owners (at least the honest ones) should have been glad the hole was closed presuming they like playing good games instead of shovelware.
Nintendo may not have cared but I guarantee you 3rd party publishers did. The DS, 3DS and Wii all turned into a cesspool of shovelware because the money simply wasn't in these systems for publishers to aim any higher. It's not hard to find stories of companies with ambitious games being stung by poor sales. Think of all the good games you *might* have seen on those systems but never got to enjoy simply because the money wasn't there for them to bother.
That's why OtherOS was removed. It may have been put in for other reasons but I suspect it would have lasted longer if not for the imminent threat. I actually used OtherOS (I doubt many people who did the complaining ever did) and it was cool to be able to run Linux but it was a no brainer to Sony to remove it when it put billions of dollars at risk if they didn't.
I have no idea what it costs for HP to throw a antenna and bluetooth license in these devices but even if it were .30 cents, they might prefer that money be in their pockets than enable it.
Go to Alibaba.com. The place is FILLED with similar specced tablets in the sub $100 bracket. Most of them are Allwinner devices with a similar res screen and form factor. I suspect that all HP is doing is bulk ordering a bunch of these, putting its badge on the front, applying some quality control and polish to the product and throwing it out at a higher price.
About the only console to withstand attack is the PS3, although Sony had to shut off some features and move code into higher kernel rings to secure it. All that whining over OtherOS being removed and Geohot being prosecuted was Sony protecting their platform from piracy.
If you turned that Trabant into an electric vehicle, you'd have to rebuild the frame and suspension to cope with the weight of the batteries which could add 200-300Kg of weight. And you can bet if you drove in snow that you'd be stuck right next to that Range Rover and even more screwed because of the 2 wheel drive, high torque, and potential problems with range and cold weather.
If a headline ends with a question mark, the answer is almost always "no". e.g."Is this an image of Jesus in a Danish pastry?" No. "Does this medieval painting prove UFOs?" No. "Could red wine be the cure for cancer?" No. etc.
Says who? Other operating systems including popular dists of Linux have well defined end of lifes on their products. Why should Microsoft be expected to support their product indefinitely?
XP was supported for 13 years. A pretty generous term by any measure. At some point a line has to be drawn and further issues should be ignored.
It should be pretty obvious this is what Valve is aiming with all this stuff. I'm sure some of the twitchiest games are unsuitable for streaming but the vast bulk would play just fine. If SteamOS survives at all as a platform it'll probably be as a stick like device which streams games from somewhere else.
On Windows I can login into a PC, walk over to another machine and remote login to that same session. For that you probably want the window manager to host the remote session. But if you have headless machine that is only used in a specific way then perhaps something simpler will do. I don't see that either is precluded.
I expect it will improve and there will also be dedicated compositors for headless servers and the like.
It's a reference implementation, a proof of concept to demonstrate to people complaining that yes wayland can in fact be remoted assuming a compositor provides with the support. It's not wayland's job to do the remoting, it's the compositor's. I see no reason to think that once wayland is switched on by default in a dist or two that compositors will explicitly support remoting, or there will be dedicated compositors for that purpose.
Quite obviously yes.
As for it's performance, it will be no worse than X (or Xvnc) on modern apps because as everyone has stated, most modern apps are pushing pixmaps around anyway. If anything performance has the potential to be better because the remoting protocol can be asynchronous (unlike X) and the server doesn't have a handful of X and extensions processes with all their context switches to worry about.
There is already a reference RDP implementation in Weston. So to answer your question, it's happened already.
It does support remote display (and not just one protocol either) and widget sets will support X backend as long as there are volunteers to maintain it.
Wayland isn't heavily criticized from a technical standpoint. Most of the "criticism" seems to be from people moaning that it's not X. As you say, X will run on top of X and QT / GTK will be have backends that support X and Wayland. It's simply Ludditism from people who think everyone should suffer under a arcane windowing system to support their esoteric (and still supported) use cases.