Some Pi dists already come in different flavours for different versions of the Pi. E.g. OpenElec has a Pi 1 and Pi 2 version. Conversely Fedora and Ubuntu come in ARM dists that work across some extremely disparate hardware - boards, tablets, laptops etc. I assume a bootloader and a config file could take care of most of the differences in hardware or memory providing the instruction set is the same.
So I don't necessarily see backwards compatibility being an issue - either ship separate dists or put code in which supports both. I expect most Pi projects are running at the application level anyway where it is largely irrelevant what SoC is under it all making stuff run. Providing the high level interfaces such as GPIO function the same way it's probably all the same for most projects.
And as a general point, backwards compatibility is a good thing but it can also be a poisoned chalice. A balance has to be struck which doesn't impact on the state of the art. If something has to be broken in order to make a significant performance gains then it should be allowed to break.
There are soft power switches for the Pi but they're pretty ugly things, normally a separate board sits between the USB power line and the Pi with a notification line that you plug into the GPIO. The idea is some process would monitor the pins for a shutdown signal, suspend the OS and then signal the power board to cut the juice. I think it could be incorporated into the board itself. As for IR receiver, it's not hard to add in itself, but it'd be nice to have an official IR on the board itself, or dedicated pins.
I reckon they could charge $10 for the enhanced model and cover their costs (and more). It'd be well suited for the many number of people who use the Pi for multimedia and emulation purposes. The foundation could even sell an official remote to go with the board.
The funny bit is that whenever a suggestion is made that the Pi could do with something or other there will always be someone to be harumph that it is quite sufficient in its current form. That because it's okay as-is for them it must be okay as-is for everyone else even when the changes required to cover some other use case are modest and could be incorporated into a premium model.
It's only "plenty" if it does what you need. If version 2 satisfies your needs then stick with it. Or even with the original version, or even a chopped down zero. For some uses the Pi Zero is "plenty", for others it isn't. I expect everyone appreciates the choice and exercises their choice to pick a model that does what they want it to do.
And proposing people use a $600 NUC instead is hardly a credible response. The Pi is a quite good for a range of tasks but providing a model C that cost ten bucks more would make it useful for so many more.
What it has is largest the development community and the benefits that goes with that - more tutorials / articles, better dev tools, better peripherals, more dists etc.
I've always felt the hardware to be underwhelming though. Perhaps that can be explained by their relationship to Broadcom who traditionally sell SoCs that go into bluray players, satellite receivers etc. These chips are perfectly fine for supporting a single app running over a kernel but they struggle when they're asked to run a desktop, or even an app with lots of graphics.
If they were allowed to shop around for other SoCs they'd get a lot more bang for their buck. Given how many people want more performance, perhaps they should add a model C to their lineup which provides it. Throw $5-10 on the price and put in a better CPU, memory and stuff like IR & soft power button that would prove popular with people running Kodi or similar software.
If North Korea pre-emptively attacked the South, either with an artillery / missile barrage or used a nuke, it might as well kiss its existence goodbye. At least as far as the regime and a large portion of its army was concerned. Even China would probably be on the side of those looking to wipe them off the face of the earth.
They could do that too. They have blacklist functionality which I'm sure includes the ability to block apks. And who's to say they won't use it if the add-on is a malware vector.
Pioneering is not the same as inventing. And these "inventions" are so vague and meta that they're virtually meaningless. Are IBM seriously claiming that interactive screens did not exist before Prodigy? Or that banner ads didn't?
I'm sure there is plenty of precedent in BBS services like Compuserve, Oracle, Minitel, Prestel etc.
The flip side is that whatever you save by going to consoles you lose by paying through the nose for the same game. And certain kinds of games simply don't travel well to consoles.
Human drivers aren't perfect but they can solve problems which are intractible to computers. Problems that they encounter every single day. I'm sure in most cases, the computer would just do something stupid and slow to a crawl, or block traffic. But there may be times where it does something downright dangerous and putting the occupant at risk.
The most sensible solution would be for car manufacturers to stop peddling the autonomous vehicle snake oil and instead put systems into vehicles which provide emergency braking, collision avoidance, skid control, fuel management (based on route etc.), parallel park, cruise / distance / lane tracking etc. into cars. Things that allow the humans to drive but provide benefit and safety to the experience.
Yes ordinarily I would use std:string and a bunch of useful classes from boost. But in this case it wouldn't have helped because a) I didn't write the code and if I had done I would have known to use the buffer length in the struct to control the copy and b) a std:string still has to be partially copied into a buffer so it is prone the same issue - something would have to copy the chars from the c_str() and that could trigger a problem.
Another point is that many of the so-called "safe" methods, e.g. strncpy_s are certainly safer from the point of view that they won't do anything if the dest cannot receive the src but they're less safe from another in that the apis are more complex and to use them properly you need to check for failure and handle that. So it makes the code more complex which adds its own risk of bugs.
Ideally stick with C++ classes but it's not possible when dealing with C APIs like Win32.
I've spent a lot of time tracking down bugs which turn out to be stupid coding errors. e.g. one recent example was a piece of code doing a strcpy on a string into a tooltip struct without limiting the length. The copy overran the struct and caused heap corruption and a crash on exit. So the bug happened in one place, the crash happened somewhere else.
I ran the VS2015 built-in code analysis tools, which didn't find the issue but did highlight some dubious looking code in other places which I fixed while I was at it. So there is merit in code analysis, even if it didn't help me in this instance. I eventually found the issue by plastering crt heap debug calls all over until I isolated the place where the corruption happened.
And some code analysis tools have proven to be a total waste of time. I recall using Purify / Quantify in one workplace hoping to isolate a runtime issue where it put so much instrumentation over the code that it took 10x as long to build and ended up crashing for its own reasons. It wasted more of my time than it would have taken to fix the issue without its "help". In my experience the more expensive a development tool is, the more bugs and the less benefit it will bestow from its use - and if it's from IBM then it will be massively expensive and bestow zero benefit.
Apple will "win" if the device withstands attack even when they're compelled to assist in decrypting it. People will applaud their technical prowess. But on the flip side the iPhone might find itself banned in countries who don't like phones that can retain their secrets. Countries like China & India who are major markets for the iPhone and who've strongarmed other providers to let them in.
Apple will "lose" if the device doesn't withstand attack with their help. Then we'll know that their security, however good it might look on paper isn't that great in practice and they'll roll over in any case that has a court order behind it. In addition those countries which might ban the iPhone will instead be demanding the knowledge to break the phone for themselves. And Apple's reputation will be tarnished.
Windows 10 is still a moving target. And my experience of using ReactOS 0.4 suggests it is about W2K at present. It's impressive how much has changed between 0.3 and 0.4 but it's never going to reach Windows 7 let alone 10. Better to stabilize it and think about pitching it as a container solution for apps which don't need the bloat / baggage / licensing that goes with real windows.
During setup Google sticks a popup asking if it can scan all your apps for security. I assume any stat gathering falls out of that. It should be straightforward for them to figure out if an apk comes from their store by comparing the hash, signatures etc.
Some people use 3rd party app stores in order to obtain warez. They search for some app which costs a fortune on Play and find a dubious place to obtain it for free. e.g. type "final fantasy apk" and various hits come up.
It doesn't so much follow that Play is safer (although it probably is for other reasons), but that there are determined idiots out there who'll put their phone, privacy and security at risk to save a few dollars.
BTW, there are many reputable 3rd party app stores who either curate or proactively monitor their submissions but Google probably doesn't make the distinction. It probably just scans apks on infected phones and determines if they came from their store or "somewhere else" which means Amazon's appstore, F-droid and all the rest are lumped in with the warez sites.
That's the issue with chasing a moving target, particular when you're in a pedal car and the target is a bullet train.
ReactOS will never catch up to windows. The best it could hope for is that one day it might be roughly analogous to W2K or XP which might be enough for a lot applications which don't need any more. Then it might gain a reputation akin to FreeDOS as something you can throw on old hardware, or a VM to get some software going without worrying about OS licenses. Maybe it could even serve as some kind of docker for Windows - bundle up a Windows application and run it from anywhere with its own environment.
The solution is to melt down lego bricks to provide the plastic filament to print out your own. Aside from electricity it's the price is very competitive with actual lego.
All of these FDM printers are deficient. Even the best of them is slow as hell to run, they stink, they have limitations on what they can print (e.g. overhangs, slopes) and the models the make have a terrible surface texture. And flaws like like warping, shrinkage, misalignments, skewing, missing sections, strings etc. are commonplace.
None of this probably matters if you're trying to print out parts that are utilitarian, where appearances are no big deal or you have the time to finish the piece. It matters a lot of you expect it to produce things like toys, decorations etc. I expect Mattel's printer will sidestep this by being "cheap and cheerful", producing things where there is little expectation of high quality.
Perhaps in an attempt to get out ahead of the consumer 3D printing market, which has allowed popular toys such as Legos to be replicated
Even the best fused filament printers on their finest, highest detail settings produce something whose quality can be best described as ass. Aside from the atrocious surface finish they suck at producing sharp corners and fine details. You might produce something approximating LEGO but it would be terrible quality.
That said I'm somewhat surprised that LEGO haven't produced their own printer. It'd be no good for precision parts but I'm sure they could produce something that integrates with models - allows kids to print exoskeletons, trees or whatever to go with some set.
The DRM may be trivially removed but you're certainly not supposed to remove it and they've made a criminal of you by even requiring you do so. I'm sure that Amazon can and occasionally do change the DRM and proprietary format as they see fit.
Same issue, only more so for loaning, selling, transferring the book too. You've bought a license to view a book, not the actual book. In some countries like the UK this even means paying extra taxes because you've bought a software licence (incurs VAT) instead of a book (does not incur VAT).
IMO, all portable digital media should have the same rights as physical property. Even if that means there is an escrow or distributed blockchain that tracks ownership and provides the facility for media to transfer permanently or temporarily to another owner. e.g. perhaps the media file is encrypted with a token. The token can change owners and whoever owns the token has the means to view book / movie. Will there be piracy? Yes of course, but there is today too. And besides, the blockchain could be used in conjunction with the content to develop some practical countermeasures.
Cardboard is pretty impressive but that soon gives way to a sense that it's just some fancy tech demos than anything worth repeat viewing. For me, it took a couple of days to mess around with it before I couldn't be bothered to take the phone out of its bumper, start the Cardboard app, stick it in headset and do run it any more. Yeah it's cool to take a 3D tour and there is that initial wow. But after a while wow transforms to why.
I expect the same issue will arise with PS4 and PC versions. Initial excitement will be replaced by the feeling that clearing a space, untangling the wires, calibrating the controllers etc. becomes more effort than its worth for the experience delivered. This shouldn't be unexpected either - look how other console peripherals have quickly outstayed their welcome. Kinect draws obvious parallels.
As I said I think VR will find niches. For example playing IL Sturmovik with VR would be so incredible. It's just the whole $80 billion prediction above I find questionable. That requires mainstream use and I don't see it, at least not the way it's launching. Perhaps if someone produces a wireless headset where you can just be put it on, and be immersed in some enormous multiplayer game hosted in the cloud within seconds then yeah. But as an expensive peripheral to an already expensive PC / console. Nope.
People will quickly tire of VR when it becomes apparent how much bother and effort it is to set up and get going and for such limited experiences. I expect AR will suffer a similar fate.
It won't mean these technologies don't have their uses but they'll probably occupy a niche for a long time to come. VR might be useful for playing racing / flight sims and so on but hardly mainstream uses.
Slashdot Mirror
So I don't necessarily see backwards compatibility being an issue - either ship separate dists or put code in which supports both. I expect most Pi projects are running at the application level anyway where it is largely irrelevant what SoC is under it all making stuff run. Providing the high level interfaces such as GPIO function the same way it's probably all the same for most projects.
And as a general point, backwards compatibility is a good thing but it can also be a poisoned chalice. A balance has to be struck which doesn't impact on the state of the art. If something has to be broken in order to make a significant performance gains then it should be allowed to break.
I reckon they could charge $10 for the enhanced model and cover their costs (and more). It'd be well suited for the many number of people who use the Pi for multimedia and emulation purposes. The foundation could even sell an official remote to go with the board.
The funny bit is that whenever a suggestion is made that the Pi could do with something or other there will always be someone to be harumph that it is quite sufficient in its current form. That because it's okay as-is for them it must be okay as-is for everyone else even when the changes required to cover some other use case are modest and could be incorporated into a premium model.
And proposing people use a $600 NUC instead is hardly a credible response. The Pi is a quite good for a range of tasks but providing a model C that cost ten bucks more would make it useful for so many more.
I've always felt the hardware to be underwhelming though. Perhaps that can be explained by their relationship to Broadcom who traditionally sell SoCs that go into bluray players, satellite receivers etc. These chips are perfectly fine for supporting a single app running over a kernel but they struggle when they're asked to run a desktop, or even an app with lots of graphics.
If they were allowed to shop around for other SoCs they'd get a lot more bang for their buck. Given how many people want more performance, perhaps they should add a model C to their lineup which provides it. Throw $5-10 on the price and put in a better CPU, memory and stuff like IR & soft power button that would prove popular with people running Kodi or similar software.
If North Korea pre-emptively attacked the South, either with an artillery / missile barrage or used a nuke, it might as well kiss its existence goodbye. At least as far as the regime and a large portion of its army was concerned. Even China would probably be on the side of those looking to wipe them off the face of the earth.
They could do that too. They have blacklist functionality which I'm sure includes the ability to block apks. And who's to say they won't use it if the add-on is a malware vector.
Pioneering is not the same as inventing. And these "inventions" are so vague and meta that they're virtually meaningless. Are IBM seriously claiming that interactive screens did not exist before Prodigy? Or that banner ads didn't? I'm sure there is plenty of precedent in BBS services like Compuserve, Oracle, Minitel, Prestel etc.
The flip side is that whatever you save by going to consoles you lose by paying through the nose for the same game. And certain kinds of games simply don't travel well to consoles.
The most sensible solution would be for car manufacturers to stop peddling the autonomous vehicle snake oil and instead put systems into vehicles which provide emergency braking, collision avoidance, skid control, fuel management (based on route etc.), parallel park, cruise / distance / lane tracking etc. into cars. Things that allow the humans to drive but provide benefit and safety to the experience.
Another point is that many of the so-called "safe" methods, e.g. strncpy_s are certainly safer from the point of view that they won't do anything if the dest cannot receive the src but they're less safe from another in that the apis are more complex and to use them properly you need to check for failure and handle that. So it makes the code more complex which adds its own risk of bugs.
Ideally stick with C++ classes but it's not possible when dealing with C APIs like Win32.
I ran the VS2015 built-in code analysis tools, which didn't find the issue but did highlight some dubious looking code in other places which I fixed while I was at it. So there is merit in code analysis, even if it didn't help me in this instance. I eventually found the issue by plastering crt heap debug calls all over until I isolated the place where the corruption happened.
And some code analysis tools have proven to be a total waste of time. I recall using Purify / Quantify in one workplace hoping to isolate a runtime issue where it put so much instrumentation over the code that it took 10x as long to build and ended up crashing for its own reasons. It wasted more of my time than it would have taken to fix the issue without its "help". In my experience the more expensive a development tool is, the more bugs and the less benefit it will bestow from its use - and if it's from IBM then it will be massively expensive and bestow zero benefit.
Apple will "lose" if the device doesn't withstand attack with their help. Then we'll know that their security, however good it might look on paper isn't that great in practice and they'll roll over in any case that has a court order behind it. In addition those countries which might ban the iPhone will instead be demanding the knowledge to break the phone for themselves. And Apple's reputation will be tarnished.
So basically Apple are fucked either way.
Windows 10 is still a moving target. And my experience of using ReactOS 0.4 suggests it is about W2K at present. It's impressive how much has changed between 0.3 and 0.4 but it's never going to reach Windows 7 let alone 10. Better to stabilize it and think about pitching it as a container solution for apps which don't need the bloat / baggage / licensing that goes with real windows.
During setup Google sticks a popup asking if it can scan all your apps for security. I assume any stat gathering falls out of that. It should be straightforward for them to figure out if an apk comes from their store by comparing the hash, signatures etc.
It doesn't so much follow that Play is safer (although it probably is for other reasons), but that there are determined idiots out there who'll put their phone, privacy and security at risk to save a few dollars.
BTW, there are many reputable 3rd party app stores who either curate or proactively monitor their submissions but Google probably doesn't make the distinction. It probably just scans apks on infected phones and determines if they came from their store or "somewhere else" which means Amazon's appstore, F-droid and all the rest are lumped in with the warez sites.
Where did you read anything I wrote which implied it did?
ReactOS will never catch up to windows. The best it could hope for is that one day it might be roughly analogous to W2K or XP which might be enough for a lot applications which don't need any more. Then it might gain a reputation akin to FreeDOS as something you can throw on old hardware, or a VM to get some software going without worrying about OS licenses. Maybe it could even serve as some kind of docker for Windows - bundle up a Windows application and run it from anywhere with its own environment.
It should really focus on those uses.
The solution is to melt down lego bricks to provide the plastic filament to print out your own. Aside from electricity it's the price is very competitive with actual lego.
How much would it cost to print a RealDoll-type sex toy on one of these?
Not as much as it costs for firefighters to cut you free from it and the trip to ER afterwards.
None of this probably matters if you're trying to print out parts that are utilitarian, where appearances are no big deal or you have the time to finish the piece. It matters a lot of you expect it to produce things like toys, decorations etc. I expect Mattel's printer will sidestep this by being "cheap and cheerful", producing things where there is little expectation of high quality.
Typo - First sentence was supposed to have been quoted - mixed up my tags.
That said I'm somewhat surprised that LEGO haven't produced their own printer. It'd be no good for precision parts but I'm sure they could produce something that integrates with models - allows kids to print exoskeletons, trees or whatever to go with some set.
Same issue, only more so for loaning, selling, transferring the book too. You've bought a license to view a book, not the actual book. In some countries like the UK this even means paying extra taxes because you've bought a software licence (incurs VAT) instead of a book (does not incur VAT).
IMO, all portable digital media should have the same rights as physical property. Even if that means there is an escrow or distributed blockchain that tracks ownership and provides the facility for media to transfer permanently or temporarily to another owner. e.g. perhaps the media file is encrypted with a token. The token can change owners and whoever owns the token has the means to view book / movie. Will there be piracy? Yes of course, but there is today too. And besides, the blockchain could be used in conjunction with the content to develop some practical countermeasures.
I expect the same issue will arise with PS4 and PC versions. Initial excitement will be replaced by the feeling that clearing a space, untangling the wires, calibrating the controllers etc. becomes more effort than its worth for the experience delivered. This shouldn't be unexpected either - look how other console peripherals have quickly outstayed their welcome. Kinect draws obvious parallels.
As I said I think VR will find niches. For example playing IL Sturmovik with VR would be so incredible. It's just the whole $80 billion prediction above I find questionable. That requires mainstream use and I don't see it, at least not the way it's launching. Perhaps if someone produces a wireless headset where you can just be put it on, and be immersed in some enormous multiplayer game hosted in the cloud within seconds then yeah. But as an expensive peripheral to an already expensive PC / console. Nope.
It won't mean these technologies don't have their uses but they'll probably occupy a niche for a long time to come. VR might be useful for playing racing / flight sims and so on but hardly mainstream uses.