That's exactly what "properly supported" means in this context. You are intentionally being obtuse by claiming otherwise. It needs to be field updatable by the manufacturer. It does *not* need to be field updatable by the end user--that's a recipe for disaster.
I don't have any problem with the hardware device (including its code) being made subject to inspections & audits. It doesn't need to be open sourced for that to happen, the code doesn't even need to be made public--and you certainly don't need to enable any random C++ hacker to modify the firmware and upload that to the device.
What's happening with VW is what is supposed to happen, the standards and testing are becoming stricter (and may include design & code reviews) and the market is correcting and providing a strong disincentive for future tomfoolery. VW will have to pay to make their customers whole. This situation would be in no way improved by letting customers modify the firmware for the emissions control themselves.
The answer is to hold the vendors to a higher standard for compliance, not to enable end users to modify firmware for compliance. I think almost none of the energy behind the "force them vendors to make hackable hardware" movement has anything to do with enabling users to modify those devices to ensure compliance with FCC standards, and very little of it has to do with "reviewing those devices to make them more secure"--almost all of it is that software guys want to be able to hack every device because they think it's fun.
Thank god the world is run by adults and not by random software hackers.
It is a layer of 'code' which tells a processor how to execute instructions. It generally gives the processor the ability to translate one opcode in the instruction set architecture into several interal micro-operations, and it usually has very raw access to the internal processor control (in some cases directly controlling internal HW muxes and whatnot). It's frequently used to permit emulation of otherwise deprecated instructions transparently to all layers of firmware and software above it. Generally there's some way to modify or patch the microcode post-silicon and thus it's a nice way for hardware vendors to fix silicon bugs in code--well hidden from all other layers of software.
I can't imagine how this doesn't fit anyone's definition of firmware. The proposed law can't just say "firmware", it has to actually define it. How would you define firmware in such a way that microcode isn't included?
It's a layer of firmware sitting between you and the hardware, it's written by the vendor.
I never said anything about microcode being compiled from a high-level language--I said the opposite, that the existence of microcode is evidence confirming that there is some very common 'firmware' which isn't written in any soft of recognizable programming language.
I've actually designed a lot of hardware and I've written a fair amount of firmware in my life. Have you?
that hardware vendors should only be required to open-source the high-level [easily understandable and non-proprietary] parts? I wasn't claiming that all the software that runs on a given piece of hardware was deep and mysterious--but some parts of it definitely are, including parts that are of particular interest to the FCC.
It's that simple. Yes, throw out your old crappy routers and pay more for routers which are properly supported by the vendor. The vendor has the expertise it needs to modify the firmware in a safe way.
As I said elsewhere in this thread:
"Sure a router (like a PC, btw) runs Linux and C programs, but there's also a BIOS layer below that and perhaps even a microcode layer below that. What language is the microcode written in? There are also lots of device drivers that are essentially binary blobs where some HW guy has carefully tweaked settings. Sure, C & Linux can be used to deliver the binary blobs--but they are still binary blobs.
Some of the binary blobs configure very delicate internal circuitry that establish things like transmission frequencies (you know, things the FCC would care about).
My point is that there are all sorts of layers of "software" below the level of abstraction that software engineers are aware of. Smart people have concocted these layers so that you guys have a nice, relatively safe sandbox to play in. You have a clean programming model and you can't do too much damage. Firmware, however, is a different story. There are parts of firmware that are nasty and impenetrable and often require proprietary knowledge of the hardware to configure correctly and safely. There are parts of the firmware which, if misconfigured, can cause physical damage.
Unfortunately, the HW and firmware guys have done such a good job of hiding this nastiness from software guys that those software engineers have convinced themselves that the nastiness doesn't exist; and thus they lobby the government to please please force the hardware companies to give the software guys lots of rope to hang themselves with."
The fundamental problem here is that software engineers are dangerously naive.
Sure a router (like a PC, btw) runs Linux and C programs, but there's also a BIOS layer below that and perhaps even a microcode layer below that. What language is the microcode written in? There are also lots of device drivers that are essentially binary blobs where some HW guy has carefully tweaked settings. Sure, C & Linux can be used to deliver the binary blobs--but they are still binary blobs.
Some of the binary blobs configure very delicate internal circuitry that establish things like transmission frequencies (you know, things the FCC would care about).
My point is that there are all sorts of layers of "software" below the level of abstraction that software engineers are aware of. Smart people have concocted these layers so that you guys have a nice, relatively safe sandbox to play in. You have a clean programming model and you can't do too much damage. Firmware, however, is a different story. There are parts of firmware that are nasty and impenetrable and often require proprietary knowledge of the hardware to configure correctly and safely. There are parts of the firmware which, if misconfigured, can cause physical damage.
Unfortunately, the HW and firmware guys have done such a good job of hiding this nastiness from software guys that those software engineers have convinced themselves that the nastiness doesn't exist; and thus they lobby the government to please please force the hardware companies to give the software guys lots of rope to hang themselves with.
You, however, seem to be confused about what firmware is because you are comparing it to "complicated software". And this has been my experience with software engineers--it is impossible to convince them that there is knowledge in this world which is not directly mappable to some sort of software.
There are parts of firmware that are just not understandable unless you have deep knowledge the specific hardware device sitting in front of you, in some cases down to the circuit level (or below, even). It is unreasonable to insist that hardware vendors document their devices down to that level and it is dangerous to allow random idiots to muck about with that firmware.
Firmware can be extremely messy, low-level code. It may not even be written in any sort of recognizable programming language. It is frequently the digital equivalent of a set of jumper switches, just a binary blob which is meaningless if you don't have deep knowledge of the hardware it is controlling. Firmware can directly control low-level electronics and an incorrect setting can lead to physical damage to the device and potential harm to nearby humans.
It is dangerously stupid to insist that firmware be open-sourced and to allow developers to modify the firmware on devices.
Sounds like you are an expert in hardware design and you have a deep intuitive understanding of the economics of that industry. You'll be able to sell your hackable routers for pennies more per unit than the existing companies--and people will be willing to pay that because you are giving them such a valuable feature (the ability to modify the firmware).
Why are you wasting your time with me? Get to work!
And, by the way, on what planet can you purchase a separate processor with its own flash chip for "pennies"?--even in large quantities that is absurd. You are talking a couple dollars per unit.
Do you find that most of your theories end up being wrong? If so then maybe it's time to acquire some reading comprehension and critical thinking skills.
There's no way to 100% block a sufficiently motivated and skilled individual--and you don't need to. We do some due diligence to make it hard for the vast majority of people to modify the software and we call it a day. Your definition of "physically can't" is based on your personal level of skill and motivation and you are [naively] assuming that pretty much everyone on Earth is the same as you.
There are lots of good reasons to prevent the user from modifying their hardware: protecting the user's physical safety (and thus limiting liability of the manufacturer), hiding trade secrets, reducing support overhead, etc. It works like this in every industry--the computer industry doesn't get a free pass just because there's a tiny minority of entitled petulant hackers who think they should allowed to reprogram everything with a microprocessor.
It's not complicated, it's how every industry has ever worked in the history of mankind ever. You just want some special exception where the government forces companies to give you hackable hardware all subsidized by the vast majority of customers who will never hack their hardware.
but I'm not entitled to one. If the market isn't giving you what you want then you either offer more money or make it yourself, but no one is required to make the product you want for the price you want.
The hacker community wants companies to incur extra expense to make hackable hardware and then pass that cost onto the vast majority of customers who have no interest in hacking their hardware. The market's answer is, "Nope".
It leads to the simplest and cheapest hardware, the easiest-to-support software stack (no dealing with customers running third-party firmware) and it meets the FCC requirements. It annoys people who want others to subsidize their desire to fiddle with commodity hardware, but that doesn't really matter because statistically those people don't exist.
The "correct response" is for the hacker community to build their own hackable hardware or pay extra to some company that supplies hackable hardware.
There are very good reasons to make devices for which the firmware is changeable after manufacturing but only by the manufacturer. The manufacturer does a little bit of encryption and signs the binary blob with their secret key and the hardware refuses to run un-signed binaries (pretty much exactly what people are complaining about here with routers). Sure it can be defeated by people with a lot of time on their hands, but you can also re-write your mask ROM with enough effort.
Software people have an incredibly naive understanding of how the world works. It would be funny if it wasn't so scary.
Different manufacturers don't necessarily measure the same feature to give that size (i.e., minimum L1 metal width or poly width or whatever) and there are so many second-order effects which influence density, performance, and power that the difference between 14nm and 16nm is pretty meaningless.
Or perhaps this one guy's experience (with a 3+ year old phone) is not typical when compared to the hundreds of millions of people who have an iPhone with a battery that lasts well over 16 hours.
If they've made any modifications to the kernel (for example) then they should make that source available--but they aren't required to give you a way to re-compile that source and load it onto the hardware. And they are perfectly free to use binary blobs for the low-level bits that talk to the hardware, there's no GPL violation there--that's a proprietary executable that runs on top of the kernel.
If the vendor refuses to fix it, then find a different vendor. A vendor could choose to make their router software modifiable by third parties (presumably at extra expense & liability) and if that is a valuable capability then presumably customers will be willing to pay for it.
We don't allow people to rewrite the low-level software in their microwave, I don't know why we'd allow it for something like a router.
Slashdot Mirror
That's exactly what "properly supported" means in this context. You are intentionally being obtuse by claiming otherwise. It needs to be field updatable by the manufacturer. It does *not* need to be field updatable by the end user--that's a recipe for disaster.
I don't have any problem with the hardware device (including its code) being made subject to inspections & audits. It doesn't need to be open sourced for that to happen, the code doesn't even need to be made public--and you certainly don't need to enable any random C++ hacker to modify the firmware and upload that to the device.
What's happening with VW is what is supposed to happen, the standards and testing are becoming stricter (and may include design & code reviews) and the market is correcting and providing a strong disincentive for future tomfoolery. VW will have to pay to make their customers whole. This situation would be in no way improved by letting customers modify the firmware for the emissions control themselves.
The answer is to hold the vendors to a higher standard for compliance, not to enable end users to modify firmware for compliance. I think almost none of the energy behind the "force them vendors to make hackable hardware" movement has anything to do with enabling users to modify those devices to ensure compliance with FCC standards, and very little of it has to do with "reviewing those devices to make them more secure"--almost all of it is that software guys want to be able to hack every device because they think it's fun.
Thank god the world is run by adults and not by random software hackers.
Have you ever heard of Intel? Microcode is a form of firmware, by definition. In fact, IBM uses those terms interchangeably.
You are possibly the stupidest person I've ever met on /., and that's saying something.
It is a layer of 'code' which tells a processor how to execute instructions. It generally gives the processor the ability to translate one opcode in the instruction set architecture into several interal micro-operations, and it usually has very raw access to the internal processor control (in some cases directly controlling internal HW muxes and whatnot). It's frequently used to permit emulation of otherwise deprecated instructions transparently to all layers of firmware and software above it. Generally there's some way to modify or patch the microcode post-silicon and thus it's a nice way for hardware vendors to fix silicon bugs in code--well hidden from all other layers of software.
I can't imagine how this doesn't fit anyone's definition of firmware. The proposed law can't just say "firmware", it has to actually define it. How would you define firmware in such a way that microcode isn't included?
It's a layer of firmware sitting between you and the hardware, it's written by the vendor.
I never said anything about microcode being compiled from a high-level language--I said the opposite, that the existence of microcode is evidence confirming that there is some very common 'firmware' which isn't written in any soft of recognizable programming language.
I've actually designed a lot of hardware and I've written a fair amount of firmware in my life. Have you?
I'm a HW engineer--I actually know quite a bit about a lot of types of firmware and I'm extremely qualified to have these opinions.
it probably runs some form of microcode which is only modifiable by the vendor. Should that vendor be required to open-source the microcode?
that hardware vendors should only be required to open-source the high-level [easily understandable and non-proprietary] parts? I wasn't claiming that all the software that runs on a given piece of hardware was deep and mysterious--but some parts of it definitely are, including parts that are of particular interest to the FCC.
It's that simple. Yes, throw out your old crappy routers and pay more for routers which are properly supported by the vendor. The vendor has the expertise it needs to modify the firmware in a safe way.
As I said elsewhere in this thread:
"Sure a router (like a PC, btw) runs Linux and C programs, but there's also a BIOS layer below that and perhaps even a microcode layer below that. What language is the microcode written in? There are also lots of device drivers that are essentially binary blobs where some HW guy has carefully tweaked settings. Sure, C & Linux can be used to deliver the binary blobs--but they are still binary blobs.
Some of the binary blobs configure very delicate internal circuitry that establish things like transmission frequencies (you know, things the FCC would care about).
My point is that there are all sorts of layers of "software" below the level of abstraction that software engineers are aware of. Smart people have concocted these layers so that you guys have a nice, relatively safe sandbox to play in. You have a clean programming model and you can't do too much damage. Firmware, however, is a different story. There are parts of firmware that are nasty and impenetrable and often require proprietary knowledge of the hardware to configure correctly and safely. There are parts of the firmware which, if misconfigured, can cause physical damage.
Unfortunately, the HW and firmware guys have done such a good job of hiding this nastiness from software guys that those software engineers have convinced themselves that the nastiness doesn't exist; and thus they lobby the government to please please force the hardware companies to give the software guys lots of rope to hang themselves with."
The fundamental problem here is that software engineers are dangerously naive.
Sure a router (like a PC, btw) runs Linux and C programs, but there's also a BIOS layer below that and perhaps even a microcode layer below that. What language is the microcode written in? There are also lots of device drivers that are essentially binary blobs where some HW guy has carefully tweaked settings. Sure, C & Linux can be used to deliver the binary blobs--but they are still binary blobs.
Some of the binary blobs configure very delicate internal circuitry that establish things like transmission frequencies (you know, things the FCC would care about).
My point is that there are all sorts of layers of "software" below the level of abstraction that software engineers are aware of. Smart people have concocted these layers so that you guys have a nice, relatively safe sandbox to play in. You have a clean programming model and you can't do too much damage. Firmware, however, is a different story. There are parts of firmware that are nasty and impenetrable and often require proprietary knowledge of the hardware to configure correctly and safely. There are parts of the firmware which, if misconfigured, can cause physical damage.
Unfortunately, the HW and firmware guys have done such a good job of hiding this nastiness from software guys that those software engineers have convinced themselves that the nastiness doesn't exist; and thus they lobby the government to please please force the hardware companies to give the software guys lots of rope to hang themselves with.
You, however, seem to be confused about what firmware is because you are comparing it to "complicated software". And this has been my experience with software engineers--it is impossible to convince them that there is knowledge in this world which is not directly mappable to some sort of software.
There are parts of firmware that are just not understandable unless you have deep knowledge the specific hardware device sitting in front of you, in some cases down to the circuit level (or below, even). It is unreasonable to insist that hardware vendors document their devices down to that level and it is dangerous to allow random idiots to muck about with that firmware.
Firmware can be extremely messy, low-level code. It may not even be written in any sort of recognizable programming language. It is frequently the digital equivalent of a set of jumper switches, just a binary blob which is meaningless if you don't have deep knowledge of the hardware it is controlling. Firmware can directly control low-level electronics and an incorrect setting can lead to physical damage to the device and potential harm to nearby humans.
It is dangerously stupid to insist that firmware be open-sourced and to allow developers to modify the firmware on devices.
nt
Sounds like you are an expert in hardware design and you have a deep intuitive understanding of the economics of that industry. You'll be able to sell your hackable routers for pennies more per unit than the existing companies--and people will be willing to pay that because you are giving them such a valuable feature (the ability to modify the firmware).
Why are you wasting your time with me? Get to work!
And, by the way, on what planet can you purchase a separate processor with its own flash chip for "pennies"?--even in large quantities that is absurd. You are talking a couple dollars per unit.
Do you find that most of your theories end up being wrong? If so then maybe it's time to acquire some reading comprehension and critical thinking skills.
You guys have been begging Apple to do that for years. Apple's not interested in doing it, Apple's customers aren't interested.
There's no way to 100% block a sufficiently motivated and skilled individual--and you don't need to. We do some due diligence to make it hard for the vast majority of people to modify the software and we call it a day. Your definition of "physically can't" is based on your personal level of skill and motivation and you are [naively] assuming that pretty much everyone on Earth is the same as you.
There are lots of good reasons to prevent the user from modifying their hardware: protecting the user's physical safety (and thus limiting liability of the manufacturer), hiding trade secrets, reducing support overhead, etc. It works like this in every industry--the computer industry doesn't get a free pass just because there's a tiny minority of entitled petulant hackers who think they should allowed to reprogram everything with a microprocessor.
is beyond the capability of 99.999% of all customers. If that's the standard then you just proved my point for me.
It's not complicated, it's how every industry has ever worked in the history of mankind ever. You just want some special exception where the government forces companies to give you hackable hardware all subsidized by the vast majority of customers who will never hack their hardware.
but I'm not entitled to one. If the market isn't giving you what you want then you either offer more money or make it yourself, but no one is required to make the product you want for the price you want.
The hacker community wants companies to incur extra expense to make hackable hardware and then pass that cost onto the vast majority of customers who have no interest in hacking their hardware. The market's answer is, "Nope".
It leads to the simplest and cheapest hardware, the easiest-to-support software stack (no dealing with customers running third-party firmware) and it meets the FCC requirements. It annoys people who want others to subsidize their desire to fiddle with commodity hardware, but that doesn't really matter because statistically those people don't exist.
The "correct response" is for the hacker community to build their own hackable hardware or pay extra to some company that supplies hackable hardware.
There are very good reasons to make devices for which the firmware is changeable after manufacturing but only by the manufacturer. The manufacturer does a little bit of encryption and signs the binary blob with their secret key and the hardware refuses to run un-signed binaries (pretty much exactly what people are complaining about here with routers). Sure it can be defeated by people with a lot of time on their hands, but you can also re-write your mask ROM with enough effort.
Software people have an incredibly naive understanding of how the world works. It would be funny if it wasn't so scary.
Different manufacturers don't necessarily measure the same feature to give that size (i.e., minimum L1 metal width or poly width or whatever) and there are so many second-order effects which influence density, performance, and power that the difference between 14nm and 16nm is pretty meaningless.
Or perhaps this one guy's experience (with a 3+ year old phone) is not typical when compared to the hundreds of millions of people who have an iPhone with a battery that lasts well over 16 hours.
If they've made any modifications to the kernel (for example) then they should make that source available--but they aren't required to give you a way to re-compile that source and load it onto the hardware. And they are perfectly free to use binary blobs for the low-level bits that talk to the hardware, there's no GPL violation there--that's a proprietary executable that runs on top of the kernel.
If the vendor refuses to fix it, then find a different vendor. A vendor could choose to make their router software modifiable by third parties (presumably at extra expense & liability) and if that is a valuable capability then presumably customers will be willing to pay for it.
We don't allow people to rewrite the low-level software in their microwave, I don't know why we'd allow it for something like a router.