Comment by gorgoiler
6 years ago
Naive question, but with a commercial product like the i.MX8M from NXP Semiconductors, is there really not enough in it for them to develop Linux support for their product, rather than leaving it to other parties? Presumably some OS supported things like the i.MX8M’s accelerometer from the launch date, or are these chips shipped to OEMs on the basis that the low level functions work, but all OS support has to be created by someone else?
From what I understand they would give you a bunch of binary blobs or either have a fork of the Linux kernel with a lot of patches to get the device working.
So they may support a single old version because the effort of upstreaming the support would be expensive.
The blog post says that the Librem paid 15 developers full time for 2 years on the project.
That's a huge expense and most of all the customers of the SoC won't be demanding upstream support.
Of course also what happens is that you get into a rabbit hole of patching your fork until it becomes a huge task to reintegrate.
For some reason, every hardware company, without exception, it terrible at software development. They just can’t do it right. It’s probably a cultural difference, somehow, with the developent style and/or NDA requirements possibly having their impact.
I'm not really a hardware guy (just a hobbyist), but I've worked with a few. As far as I can tell it's typically a mix of things, largely related to managing unique difficulties of hardware bringup and treating software development as part of the hardware product development cycle instead of really having its own planning/management authority. For example:
- Doing a hard fork of the software stack for every product family/generation/platform, because it's assumed up front that hardware differences/bugs and changes in product definition will require non-portable changes throughout the stack (e.g. things like GUI element sizes and line lengths are often hardcoded to fit the layout to a particular screen, various GPIO pins/buttons/LEDs/connectors change identity/significance, hardware gains/loses capabilities needed for a feature so UI elements related to that feature need to be added/removed/altered)
- Expecting the vast majority of development effort to be on shipping new products because already-shipping products are "in the can" and the big deals have already been closed
- Management belief that hardware is hard and software is easy (which is arguably sometimes rational from the perspective of managing product-dooming risks)
- Upstream vendors wasting developers' time with shenanigans around stuff like documentation (oh, you wanted the real manual that actually says what the registers do?) and firmware (some vendors apparently forget to mention that there is firmware until you ask your SE/FAE why something isn't working)
- Uncertainty around whether a given problem ought to be fixed in hardware or software
Apple too?
Lately, Apple does kinda suck at software development.
I spent days hunting down issues in the launch iOS 13 simulator that turned out not to happen on real hardware (and had never happened worth the iOS 13 launch).
Their UX is on a downward trend for several years now, IMO.
Historically I've heard Apple described as a software company that uses hardware to achieve competitive advantage.
Apple sucking is relative, obviously - their stuff is still better than most other products, but it's not add good as it used to be, IMO.
I wonder if the iPhone's success has transformed them into more of a hardware company?
5 replies →
Isn’t Apple more of a product design company than hardware company?
But yes, they do seem to straddle the divide somewhat, and they have wavered to one side or the other in the past. But is does seem that even Apple can’t go against the stream; they either seem to do bad hardware and good software or vice versa at any given time.
1 reply →
Notable exception, most of the time.
I asked myself that very question often, but the reality is that only customers that take a small number of those chips (<1.000.000) care about mainline support.
For the first tier customers they get a custom solution developed for them, and have access to all the specs under the NDA, but since that is the case, they cannot develop stuff for mainline and just produce blobs.
The i.MX8M as I understand is a chip for car navigation/entertainment systems. I wonder whether the shift towards OTA updates will encourage manufacturers to care about mainline support. Think about all the models and versions that a car company has, they’re going to have to be maintained for a decade or more, and doing that with fractured code bases and kernel patches sounds like an immense pain.
Car manufacturers seem weirdly unmoved by immense pain in software development.