The current 'random person implements firmware that controls the this chip' practice and the 'no warranty etc etc' disclaimers will, I predict, be replaced by manufacturers who are willing to warrant their code.
The current 'random person implements firmware that controls the this chip' practice and the 'no warranty etc etc' disclaimers will, I predict, be replaced by manufacturers who are willing to warrant their code.
And there is simply NO COMPARISON in complexity to software. In physical building, you over engineer and get redundancy. You also know that almost everyone builds plumb and level, rectangular rooms, with easy span and shear calculations. You also know that wood follows a predictable strength pattern. So you put in enough nails of the right length, to enough wood of the right thickness, and you're good. How much intelligence do you think you need to follow a building code? Building materials and techniques change GLACIALLY compared to software. (A good thing!)
Whereas in software, one single bit flip will just fuck you up.
Real issue here is why such codes don't exist for for this particular problem.
There have always been fully deterministic CPUs around for that purpose. The simpler the system, the better; just hook a Forth chip to a memory without caches and you're set.
I believe that the GreenArrays people, setting aside the $450 dev board, also had some notes on making cheap breadboards with their chips or something like that. I don't have a link handy, though. ;/
I've been the guy who drives around in a truck with a lot of mobile scanning equipment to try and figure out where the rogue device is. There is no magic button like in the movies, where they can immediately triangulate the source of the interference to within a 5 cubic metre box. You basically have to rely on simple physics and boots on the ground. The device you're hunting for isn't playing nicely, so any assumptions you could normally make based on things like which base stations it's in contact with won't necessarily be valid. Things are a bit smarter in modern networks than they were back when I worked in the field, but physics is still physics.
In short, there is a legitimate justification, born of experience, for every telecommunications regulatory authority in the known universe requiring this stuff to be certified before you can legally use it. This is also why in some jurisdictions agents acting for telecommunications regulators have certain legal rights to access private property.
Of course this only affects the radio equipment. I see no reason it should be necessary or possible for such software to have any control over other integrated peripherals such as cameras, speakers, microphones or local storage. And the primary concern is people who could modify the code and break the network, not preventing any legitimate audit to prove that devices are only doing what they say they're doing.
Nobody is asking for some sort of hacker radio anarchy, here. They're asking to see the source code for machines they own, machines that reside in their pockets, machines that are responsible for storing and communicating their most sensitive personal data.
Verizon has the right to transmit on spectrum allocated to it using consumer devices as its agents. It employs engineers and QA processes to make sure that any device transmitting on its spectrum plays well with others before it is allowed to leave RF-isolated testing facilities.
The public does not and should not have the right to transmit on Verizon's spectrum, even using devices they own which are legally and technically capable, except according to Verizon's carefully vetted programming. If they were able to run their own radio firmware, you'd have the situation described in the parent.
Cellular radios necessarily cannot be open source. The source could be released for inspection and audit, but it cannot be possible or permissible for you to run modified source on "your" radios.
Dude, that's exactly what he asked for.
Parent claimed that modifying the source wouldn't hurt anything since your phone can't transmit in ways you're not licensed to, but this is incorrect.
- If Toyota (or any car manufacturer) wants to import cars into my country, then they better show us the sources of their firmware and software (and let us re-compile it and re-install it, to make sure it corresponds to the embedded code). And let the papers compare the code quality of Toyota vs. BMW.
- If Microsoft (or any software vendor) wants to import software into my country, then they better show us the sources of their systems and applications (and let us re-compile it and re-install it, to make sure it corresponds to the binary code, and doesn't contain backdoors to the NSA (or the MSI, or the MI5 or whatever).
- and so on.
And actually, citizens can do the same at their level, not letting enter their house any device or software whose code is not open source or even libre software (so they can recompile it and reinstall it on their hardware).
But a country has more weight than a few citizen that would be qualified of lunatics, and has more resources to analyse and validate the software and firmware.
This helped propel a lot of the world's best ancient thinkers, including Euclid, Archimedes and Eratosthenes.
I tried that, but at the moment it means you can't even own a cellphone, etc
hardware manufacturers should be less concerned about what their firmware reveals about their IP and more concerned with what not revealing their firmware source code reveals about their security.
the fact that you can get DMA by compromising _any_ device on the bus is a problem too. imo, none of these peripherals should have unmitigated DMA.
But yes, this only applies if the competition must also open their kimonos. That seems practical for industries where regulation is required or provides reasonable benefits to society (automotive, voting machines, medical, etc).
http://en.wikipedia.org/wiki/The_Open_Source_Definition
Making the source code visible would probably be sensible in this case though, so I think the idea is a good one even if you need to be careful with the terminology.
Consumers want the latest.
Companies want the most stable.
After some particularly huge disasters I've had to deal with coming onto new projects and with general consumer electronics, I'd go for the latter every time both as a consumer and company these days. Time is valuable and losing it to a feature packed unreliable mess is a big risk to that time.
For a company with a large workforce, the probability of something breaking is higher - many different machines being used in different ways, and the cost of a botched upgrade can run into millions, with people losing their jobs, and legal action being taken.
For consumers, the risk is typically lower and less costly if it goes wrong. If a Facebook upgrade causes the app to crash repeatedly, it means I can't post for a while, so I'll just upgrade and hope for the best. But if a personal finance or medical app goes wrong the consequences could be extremely serious, so stability is more important.
Oh, and applying pretty much any "software building codes" to the web app industry would probably kill startup culture entirely.
Not necessarily. To use the analogy with the building industry, there are different requirements depending on what the building will be used for. Startups holding or processing financial information might have one set of regulations, whereas those hosting cat pictures might be less rigorous.
To continue the (somewhat stretched) building analogy my house falling down doesn't affect yours, but someone stealing my access codes from my poorly secured building potentially could affect the security of yours.
You should run that prediction by some of your friends in the legal department and see what they think.