nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyd968gmewwp6kyqpq05gxtz00vfxzdela6xrhyvtqxmaxqz65d9hws3d56e72trqgcmvsxk52hs x86 is something I know very well. I don't see how mere opcode set is the problem. C...
@nprofile1q... I understand the sentiment, but I think this is not quite the right way of looking at it. There are some things you need to be ultra secure. Think communications between two locations. You don't need 32GB of ram for that, you don't need 4GB of ram for that, hell, you probably don't even need 128MB of ram and a 600Mhz MIPS SoC for it even if you want to go to the extreme.
I haven't tested our USB video adapter on our TPE-R1300 as it would involve rebuilding the kernel and enabling some components. However I have hooked one of these up to a TPE-R1500 with 4Gb of ram and it would also work on our TPE-R1400 if I had built Trisquel 11 images for it.
The point being is there are different solutions to different problems and in some instances it might be sufficient to simply keep an x86 system offline if your looking to improve the security situation.
I tend to avoid running proprietary code as much as possible as there is an inherent danger in accepting the status quo. If everyone does it and we end up being unable to design and manufacture devices that aren't backdoor'd then we also risk losing an ability to defend ourselves as well. It's not that there is an issue now- but there will be at some point down the road.
It's also a slippery slope. Accepting proprietary bits led to having to enter serial numbers into software to "activate it". A minor headache. Then we got more complicated "activation schemes" where you had to be online all the time. Even more of a headache. In some instances you didn't have to be online, but an application crash could lead to 24 hours of down time until you could get support at a company to resolve your issue (assuming they even would).
Then locked down music & movies! And now it's all a service.
I haven't tested our USB video adapter on our TPE-R1300 as it would involve rebuilding the kernel and enabling some components. However I have hooked one of these up to a TPE-R1500 with 4Gb of ram and it would also work on our TPE-R1400 if I had built Trisquel 11 images for it.
The point being is there are different solutions to different problems and in some instances it might be sufficient to simply keep an x86 system offline if your looking to improve the security situation.
I tend to avoid running proprietary code as much as possible as there is an inherent danger in accepting the status quo. If everyone does it and we end up being unable to design and manufacture devices that aren't backdoor'd then we also risk losing an ability to defend ourselves as well. It's not that there is an issue now- but there will be at some point down the road.
It's also a slippery slope. Accepting proprietary bits led to having to enter serial numbers into software to "activate it". A minor headache. Then we got more complicated "activation schemes" where you had to be online all the time. Even more of a headache. In some instances you didn't have to be online, but an application crash could lead to 24 hours of down time until you could get support at a company to resolve your issue (assuming they even would).
Then locked down music & movies! And now it's all a service.