So many chipmakers and development board manufacturers see software/driver support as some kind of necessary evil--a chore that they grudgingly do because they have to, and they will do the absolute minimum amount of work, with barely enough quality to sell their hardware.

▲

makeitdouble 4 hours ago | parent | next [-]

Come to think of it, for them it is basically customer support.

Most will want to outsource it as cheap as possible and/or push it to the community. They won't care if it takes an eternity for the customer to get their issues solved as long as new customers keep buying.

And a few companies will see an opportunity to bring better customer care as an advantage and/or integrate it in their philosophy.

▲

LtWorf 2 hours ago | parent [-]

And it's the reason why for several years I didn't consider buying anything that had an AMD card (not now, but for many many years it was insanity).

	▲	doubled112 21 minutes ago \| parent [-]
		Are you talking about the FGLRX drivers on Linux desktops? Or their Windows driver quality back then? I remember them both being pretty brutal.

▲

ozarkerD 6 hours ago | parent | prev | next [-]

It bewilders me. Software's gotta be easier than hardware right? Not that either is easy but as a software engineer, the engineering that goes into modern hardware mystifies me.

▲

bri3d 5 hours ago | parent | next [-]

It's different definitions of "easy."

With hardware, you have about one billion validation tests and QA processes, because when you're done, you're done and it had better work. Fixing an "issue" is very very expensive, and you want to get rid of them. However, this also makes the process more of, to stereotype, an "engineer's engineering" practice. It's very rules based, and if everything follows the rules and passes the tests, it's done. It doesn't matter how "hacky" or "badly architected" or "nasty" the input product is, when it works, it works. And, when it's done, it's done.

On the other hand, software is highly human-oriented and subjective, and it's a continuous process. With Linux working the way it does, with an intentionally hostile kernel interface, driver software is even more so. With Linux drivers you basically chose to either get them upstreamed (a massive undertaking in personality management, but Valve's choice here), deal with maintaining them in perpetuity at enormous cost as every release will break them (not common), or give up and release a point in time snapshot and ride into the sunset (which is what most people do). I don't really think this is easier than hardware, it's just a different thing.

	▲	generativenoise 3 hours ago \| parent [-]
		From the outside looking in. It really seems like both fields are working around each other in weird ways, somewhat enforced by backwards compatibility and historical path dependence. The transition from more homogeneous architectures to the very heterogeneous and distributed architectures of today has never really been all that well accounted for, just lots of abstractions that have been papered over and work for the most part. Power management being the most common place these mismatches seem to surface. I do wonder if it will ever be economical to "fix" some of these lower level issues or if we are stuck on this path dependent trajectory like the recurrent laryngeal nerve in our bodies.

▲

OneDeuxTriSeiGo 6 hours ago | parent | prev | next [-]

Software is easier than hardware in general but companies generally pay their hardware guys 25-50% less than their software counterparts

▲

Melatonic 5 hours ago | parent | prev | next [-]

Software can always ship a new update for bugs or features.

Hardware not so much

▲

IshKebab 5 hours ago | parent | prev [-]

I've done both. There are difficulties with both but overall I would say software is significantly more difficult than hardware.

Most hardware is actually relatively simple (though hardware engineers do their best to turn it into an incomprehensible mess). Software can get pretty much arbitrarily complex.

In a way I suspect it's because hardware engineers are mostly old fogies stuck in the 80s using 80s technologies like Verilog. They haven't evolved the tools that software developers have that enable them to write extremely complicated programs.

I have hope for Veryl though.

▲

vrinsd 2 hours ago | parent | next [-]

Wow, super hard disagree, comment here sounds like the typical arrogance hardware engineers face from people in software who've never really done the job or have some superficial experiences.

I won't blindly state "software is easier" but software is definitely easier to modify, iterate and fix, which is why sofware tools and resulting applications can evolve so fast.

I have done both HW & SW, routinely do so, and switch between deep hardware jobs and deep software so I'm qualified to speak.

If you're blinking a light or doing something with Bluetooth you can buy microcontrollers that have this capability and yes that hardware is simple.

But have you ever DESIGNED a microcontroller, let alone a modern processor or complex system ?

Getting something "simple" like a microcontroller to reliably start-up involves complex power sequencing, making sure an oscillator works, a phase-locked-loop that behaves correctly and that's just "to make a clock signal run at a frequency" we're not talking about implementing PCIe Gen5 or RDMA over 100Gbps Ethernet.

Hardware engineers definitely welcome better tools but the cost of using an unproven tool or tool that might have "a few" corner cases resulting in your $5-million SoC not working is a hard risk to tolerate, so sadly(and to our pain) we end up using proven but arcane infrastructure.

Software in contrast can evolve faster because you can "fix it in software". New tools can be readily tested, iterated on and deployed.

▲

poly2it 4 hours ago | parent | prev [-]

What do you think about Atopile? I'm not a hardware person yet, but these seem similar.

https://atopile.io/

	▲	bri3d 4 hours ago \| parent [-]
		PCB and RTL are completely separate disciplines.

▲

andyferris 5 hours ago | parent | prev [-]

But - doesn’t open sourcing it kinda make it someone else’s chore?

Obviously it has to “work” at sale but ongoing maintenance could be shared with the community.