The SoC vendors get Android working, get the drivers going, help do ports or modifications for major customers and hide it all behind NDAs, blobs, sometimes a bunch of hacks and all of it is closed source work.

The postmarketOS guys to their credit are trying to do "proper" mainline work which is admirable but probably frustrating, non-trivial and requires a lot of reverse engineering.

It was a reason years ago Maxim's ICs were almost always on a "never design in" list since obtaining them was near impossible in reasonable time frames.

Most "seasoned" HW engineers who are working lower volumes verify availability with distributors and for high-volume (i.e. 100K units+/yr) work with sourcing people internal to company to get commitments for key ICs.

And what do you think iOS / macOS is based on? UNIX userland from the BSDs with the Mach kernel, Mach IPC, etc. Fun note: It's easier to cross-compile standard UNIX utilities and programs for iOS/macOS than it is Android since Android effectively has its own user-land.

macOS and by extention iOS are, by comprarison to Android, actually pretty well architected. The choice of kernel (Mach, Linux) is really not the limiting factor, it's how you plumb together the layers above the kernel and that's what Android has done badly.

Lastly, just because OpenMoko may or may not have done something ideally (~20 years ago?) doesn't mean the current efforts (postmarketOS, Plasma, PHOSH, Sailfish) have done it badly. Actually most of these efforts are leveraging the fairly refined parts of a modern Linux environment and are MUCH easier to work with at the lower levels than Android.

I have spent the past 2 years off and on modifying AOSP (for "reasons") and I am constantly amazed the poor quality of the code base and badly architected the overall system is.

It's a bunch of re-inventions of the wheel (start-up daemon manager, IPC, HAL, GUI, etc) with the "upper layers" written in Java with a mix of C/C++. Mixing the metaphor of a Java "run time environment" with a Linux-based kernel results in a hodepodge of pieces and having seen it up close it makes sense why "Android" user experience varies so much device to device.

Did Android need it's own bastardized libc for example (bionic)? Did Android need to have it's own start-up daemon manager? A "HAL" in C++ (wrapping Linux kernel capability) with a bunch of bridges to Java via JNI?

Writing an application for Android is also a byztantine mess of NDK, SDKs, Java build systems (Maven, Gradle, etc), XML files, Java, Kotlin, etc. Why can't icons just be SVGs, why do these have to be in some XML-formatted resource? The list goes on.

In fact I wager the OPPOSITE happened -- that they hired or outsourced software to people who have "web technology experience" and the UI and graphics architecture is a mishmash software stacks hastily thrown together (read: not architected).

Jaguar has a similar issue with the I-PACE where the HVAC system couldn't keep up with the knobs and would lag. A real embedded engineer who worked on real-time systems would know how to properly handle a quadrature encoded knob and NOT lag. A web-technology-first person who slapped something together using nodejs and/or Python would likely not know.

Thanks so much for the information. I am familair with the voting logic (I've worked on systems that implemented the same thing, odd-number of processor cores and the majority wins).

One question, were any "misbehaving" processor or actuation requests ever logged? As in, were there examples where one actuator or CPU didn't agree in the Shuttle flights?

I can't claim the changes would be easy to implement, but if they made a FEW small changes the result would be 1000x better.

For example if you want to sell something on Craig's List they do some "you can't make this post because it looks too similar to a previous posting" kind of thing AND you might need a mobile number but somehow someone can stuff 1000 random keywords into a for-sale posting that's not at all about the item? So if you're looking for a "Miata" you'll end up getting listing for a bunch of other cars since someone is gaming the system?

Or it's an option to "reject duplicates" -- why do duplicates or clone postings even show up if they have their "this is too similar to another posting" capability?

Or, Craig's List lets AutoTrader and other "commercial" sites post items but if you want to actually message someone now on AutoTrader you need to upload your DRIVERS LICENSE just to send them a message? So Craig's List is OK with a reciprocal arrangement with a vendor who does not honor the same "equality" rules Craig's List was built on?

Sadly, many years ago I would send feedback to Craig's List and Craig himself would reply. I don't know if he's completely checked out of his site now, but if you're out there Craig a few simple changes could restore the utility of the service which you created. People like me would even PAY to see these improvements.

All of the public money spent on going to the moon is really just a way to funnel $$ to a few sub-contractors the actual science value of going BACK to the moon is pretty low.

It takes such a huge amount of people time, effort, resources AND has an environmental impact to launch a payload into space, we should be expending these resources to help solve our societal/environmental issues, not for "showboat science".

Sadly, this view is considered antiquated and anti-technology by a younger generation of people who think what we see in sci-fi shows should be reality (good or bad). And if you don't get that vision then you're some dumb luddite who should be banished from society.

What's kind of remarkable is the onslaught of vehicles, many EV, which have critical functionality issues that are being ignored, but they have WiFi + hotspot on board! And if you want to do basic things with your own vehicle, like get the climate control ready before you leave on a trip you now need an app, a smartphone, and Internet connection and a subscription...to do things that could easily be done via some local BLE or WiFi connection.

I see a lot of car companies rush to make "immersive" driving experiences while neglecting the basics. The Ioniq 5 / EV6 have ICCU issues that are not addressed which can leave the car stranded and the replacement parts have the same mysterious failure modes, the Jaguar I-Pace had numerous failures including a UI that would lag for basic things like changing air conditioning settings, the last generation Leaf (just prior to the current re-design) has battery issues that have forced people to do lemon-law buy backs, the Ford Mach E has a Tesla-style iPad center display that can't be turned off at night so it's a distraction (among other issues with the poor concept), but it has OTA so awesome!

Unfortunately, the Sailfish UI itself feels "different for the sake of different" and not because it's functionally more useful. I think the UI is pretty ugly and difficult to navigate. Anyone who "loved" Win8 tiles and/or Windows Mobile flat monochrome UI always praises the SailfishOS UI but outside of that small group I don't think the UI is that functional. It's definitely eschewed it's MeeGo / Nokia N9 UI heritage.

What always surprised me about SFOS is despite running on some pretty decent hardware, the UI always felt sluggish, especially given it's kind of reversed-big-text UI paradigm which shouldn't take much work to render.

I'm glad there's an alternative, but sad it's hasn't seen a reasonable set of UI improvements despite its age.

Cruise automation was also for years working on custom silicon, I knew people there. Many people working on the custom devices didn't really believe in the mission statement either, but they were paid well, and got to do fun work, so they took the job.

What makes Rivian, or Tesla better at making the "normal" car pieces compared to Toyota, or Honda? The answer is they're really not better at those things and quite worse typically ; bad fit and finish, rattles, corroding suspension components, difficult to buy replacement parts, etc.

If these companies were truly about making electric cars available to all, a partnership with a car company that knows how to do the "regular car stuff" makes a LOT more sense.

Instead you have these companies that might be innovative in the drive train, electronics, batteries, and co-packaging who have to learn all the "hard" stuff normal car companies have been doing for a 100-years.

Now, instead of moving into a partnership with a regular car company, they're becoming hardware/software organizations making custom silicon with custom software.

Even doing custom silicon and the associated software takes YEARS of expertise to do it and not have a 1000 warts, not withtsanding going into a MOVING VEHICLE where the risks of making mistakes is life and limb.

So, my conclusion is this is more fancy smoke and mirrors to impress investors and the general public, but not in the best interest of end-users (people who buy vehicles to use as transportation).

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.

You can buy Xilinx FPGAs on PCIe cards that could easily handle THOUSANDS of RISC-V cores.

Almost all FPGA dev boards include DDR memory so you could also put code there if you needed to.

The reason an FPGA is a more suitable platform is you can translate "physical effort of making PCBs" into "creating a design in an infinitely re-programmable platform" and change your design as needed to your hearts content.

In fact, the original design of RISC-V included a bus called 'TileLink' to enable 'Many core' arrays of RISC-V processors.

Translation: You can pare-down open-source RISC-V cores and use TileLink and emulate CM or build something more complex as you see fit since that was built into the original open-source RISC-V specs.

FPGAs are their own joy and pain for sure and it's not as "cool" to re-program a blackbox on a PCB as it might be to make your own thing, so all depends on your goals.

I read the write-up with a LOT of interest, this is really amazing work, there's not a lot of good options for auto-routing with open-source PCB tools (i.e. KiCad). I have also used the other autorouter you mentioned for "low-complexity" boards in KiCad and it helped do the job but was painful.

In my career I've also used the autorouter built into the "high-end" PCB tools and they could handle the complexity of boards you outlined WITHOUT needing a massive GPU, but they also paid people to improve this stuff over 15-to-20-years and development happened when single-core computers with limited RAM were the norm.

On the technical side, somewhat more recent FPGA 'placement' algorithms used a simulated annealing algorithm, while what you didn't isn't about placement, that approach could posisbly help with 'net cross-over reduction' type of passes, and maybe help with designs where you can do port swap / pin swap.

I'm amused you made a RISC-V array with discrete parts -- I'm sure you considered using an FPGA? Jan Gray has done > 1000+ RISC-V cores (https://fpga.org/grvi-phalanx/) in "older" Xilinx FPGAs.

If you're trying to emulate Thinking Machines / CM-x or anything else, frankly I think a "mondo" FPGA is still the way to go.

Job-wise: A suggestion might be to reach out to the guys at AllSpice ( allspice.io ) who make revision control software for Altium and possibly KiCad. The work you did to enable IPC, etc seems like exactly the type of skillset these guys might need (contractor, maybe full-time?) to interoperate with KiCad.

If I see anything that might be up your alley I'd also reach out. I'm not in a position to hire anyone and while "some companies" may not be impressed by what you did, the right organization WOULD be.

I share your sentiment that the likes of "modern" companies like Apple, MSFT, etc the hiring process is really taylored to "I want a guy who can do X" and rarely "I want a guy who's shown he can learn Y and Z so he can certainly do X".

Culturually, doing something "well"(quality oriented, mindful of end-users) vs. "got it done" (transaction, pragmatic way of looking at things) is the heart of why outsourcing to many different geographical areas (India included) often results in something different than expected.

Also condemning every one in one part of the world as thinking one way is certainly not fair or true, but there are definitely unmistakable trends.

I think it's super cool that you work at Canva and are taking the time to interact with your customer base.

Maybe this isn't the right venue (I didn't see an e-mail address in your profile so I'm just asking here) but can you pass along feedback to the UI team for Affinity?

I personally think most programs, especially audio / video editors are improved by:

A) Optionally having icons that have text labels in-addition to the image (i.e. the word "Cut" + scissors, "Paste" + paintbucket, etc) ; doesn't have to be full on MSFT 'Ribbon' UI either!

B) Giving users the ability to choose how big or small the icons (and associated text) are (i.e. 16-pix, 32-pix, 64-pix or small, medium, large)

For point A:

I am aware this creates a challenge when you make a release of a program for other languages, so it's a burden on the translation and software validation teams.

Use-case: I work between so many different programs when doing photo editing and learning the pictogram icons for each application is mentally burdensome that it's VERY helpful having labels as well. Otherwise I constantly find myself hovering on an icon and reading the tooltip, that text might as well be integrated into the icon!

I end up using CaptureOne for image processing, DxO for noise reduction, Affinity for pixel editing and that's just in dealing with RAW photos for one type of photography, I might use others as well depending on the subject matter.

For point B:

Our monitors now are super high DPI and squinting at tiny icons designed when we had limited real-estate is a real tax on the eyes.

Thank you again for reply on this public forum and many us who are paying customers are happier to give you guys money over companies like Adobe who now only offer subscription software.