vrinsd

I agree with this sentiment. If someone wants to do a bunch of reverse engineering, maybe they could try to get full mainline support for older Qualcomm mobile phone/tablet SoCs and minimize/get rid of BLOBs?

All the fun of reverse engineering and we know the processors already run Linux...

I agree with your sentiment ; very likely the Fairphone people are restricted by NDAs from the SoC vendor who are the ultimate cause for lack of proper mainline Linux support.

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.

Honest question here -- for doing 3D parametric design, is the "programmatic" approach a good thing? If you compare doing a design in LuaCAD to something like Solidworks or ProE, can you get to the end result faster, and easier?

Not to negate your core points but almost all the HW engineers I've worked with who are experienced absolutely consider sourcing and availability in the decision making process.

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.

No idea what you mean by "well built OS" when Android has so many corner cases and weird "hard coded work arounds" and crazy development process that its behavior is often unpredictable and downright irrational.

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 think you are in the minority of people that feel Android is a well built "OS". Maybe from an end-user point of view it "does what you want" but its underlying architecture I think is pretty poor.

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.

Except Motorola shipped an Android phone with an x86 CPU -- RAZR i (2GHz Atom) in 2012.

I think IF they had hired embedded software engineers with 40 years of experience, those people would have delivered a UI that meets or exceeds all UI needs (even if it didn't look as visually appealing as it could). A 40-year embedded veteran knows how to write real-time code, structure the system and make it work under all conditions.

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.

Hi kens,

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?

Sadly, I think Craig might have done MORE for society by simply improving Craig's List and removing/reducing the amount of spam and junk posts it allows.

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.

Feel exactly the same way.

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".

1000% agree.

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!

I used Sailfish OS and so did several of my family members for many years. The "vanilla" Linux OS aspect (besides using rpm) makes it trivial to set up things like dnsmasq-adblocking, firewall rules, etc.

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.

Frankly, the "need" for custom silicon seems self-imposed, with the idea of appearing to be a technology company first rather than a car / vehicle company.

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).

This.

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.

If you look at modern FPGAs they have prodigous amounts of on-chip memories (BRAMs and URAM in Xilinx speak).

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.

If you're open to technical feedback your last comment, I've worked on these kinds of systems, have architected and built things even far "weirder" and these products have shipped and out in the real world, in silicon, in FPGAs and things between.

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.

Author: Thanks for taking the time to reply.

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".

I understand why someone might this this is a pay issue, but it's goes beyond that.

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.

Hi DannyW,

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.

This is really great work, but can you comment on whether or not any Google-based "safebrowsing", etc is still enabled in the code base?

Have you thought about merging your efforts with ungoogled-chromium (Android)?

There USED to be an ungoogled-chromium for Android (circa v88 chrome, the APK is still available for download) that also allowed extentions.

As a happy user of many KDE based programs (konsole, kate, dolphin, etc) it's great to see another KDE piece evangelized.

But can someone state conclusively if Bluetooth-base connectivty in KDE Connect actually works in 2025? I looked into this a few weeks ago and it seemed liked from mailing list posts until Bluetooth functionality in KDE Connect equals WiFi connectivity the feature is not enabled?

When traveling it's much easier to do "point to point" between laptop and phone and in theory Bluetooth can support this easier than WiFi via third-party access-point or having to mess with WiFi direct.

Are you saying that Plasma Mobile runs on any device that is supported by libhybris?

I was asking about Plasma Mobile ( https://plasma-mobile.org/get/ ) that the parent mentioned switching to and I wasn't aware that libhybris is a requirement.

The Sailfish guys are actually the creators of libhybris.

If you run SailfishOS you have to first have Android flashed onto the phone. They use the same kernel, camera drivers, GPU drivers, etc as the original OEM including the prorprietary wireless BLOBs and the Android Radio-Interface-Layer ("RIL").

I've spoken to the Sailfish guys awhile back and I get why they did this -- 10+ years ago there was basically no choice but to use the Android port of drivers + the Linux kernel the vendor shipped because there was no other way to make these hardware pieces work, thanks to the silicon vendors.

The story of not needing BLOBs and things like a libhybris-shim has slowly improved, but not 100% . We can run Debian linux on the Qualcomm Snapdragon laptop devices (Thinkpad X13s, etc) but bits and pieces are still not there (audio, full power management, Bluetooth, etc).

To current Qualcomm's credit there are people inside who are pushing for everything mainline Linux, and minimizing proprietary pieces.

Ubuntu Touch relies on libhybris as well.

I am not saying the gestures in Android and iOS (app switching, etc) are actually the value add, but in fact things like toggles for options, or a "=" where the options are available to turn on/off. Sailfish forces gestures for things inside an application as well.

No doubt Meego innovated on ideas, but just because they came up with something doesn't make it "good" and just because Apple/Google copied it doesn't prove the validity of the idea.

To that point I would prefer we used more screen real estate (Android, iOS, whatever) and REDUCED the usage of gestures, it would end up being faster. It sometimes takes me multiple attempts to swipe from the bottom on a Android/iOS to get it to do something because I have a screen protector and/or case and the way I'm interacting the with the device is different than the developers who might have worked with a "nude" device.

The screen protector/case issue made UI navigation even worse on Sailfish devices because you had to use this gesture inside a program, not just to switch between applications.

Ubuntu Touch also has a swipe, but from the side where a screen protector is slightly less likely to affect it's ability to register the gesture.

Do you use Plasma on a phone or tablet? If phone, can you say which hardware platform and how "well" it works as an actual phone, making calls, texting, etc?

I've used it for several years and the feedback from a user point of view is not positive. My sample size includes me and several members of my family who used Sony Xperia devices running SailfishOS for several years.

The Sailfish guys for some odd reason decide to invent their own "user interactions" where you click-slide ("one handed") to do certain opertaions. This makes the UI not only awkward, but NOT intuitive. You don't know what your options are until you perform this strange operation. I get why they did this, it was a way to potentially reduce swiping, etc but now that we have phones with big screens, you can actually put those options in one UI.

Further, basic things like composing a text and attaching a photo requires a round-trip to the photo app where you 'tag' the images you want ONE BY ONE rather than being able to do this inline from the SMS/MMS application. I think this has gotten better recently but for a long time it was SUPER awkward.

Two other perplexing points was how SLOW the UI felt for what should have been compiled Qt code and poor battery life on the older Xperia devices. Maybe they're using QML and it's not compiled?

The Sailfish guys have what I think is an ugly looking UI as well.

They've "dithered" certain parts of the UI so it really looks like old-school EGA/CGA graphics, even though the display is high-DPI and they have what's effectively a TUI style interface.

The only people I know who "LOVE" or claim "it's the best" UI are the same ones who LOVE Zune and Windows Phone UIs which are basically flat UI, almost monocolor nearly TUI type which is what you see pieces of in Win10 as well. Personally I dislike this UI and so do many people I know, there's a reason why UIs have icons and ideally text labels. TUIs have their place but so do GUIs.

If the Sailfish guys abandoned their weird UI ideas and frankly made it more like iOS or Android (I know, so boring, we have to re-invent the wheel just because...) it would actually be compelling.

On the very very plus side of Sailfish, as someone else pointed out, it's basically a GNU/Linux device that uses RPMs. I was able to install dnsmasq, set up DNS based adblock filtering, curate firewall rules and basically harden the device. You could SSH into the device via USB without adb stupidity and once I set it up, it stayed working until the VOLTE switch-over occured.

I think Ubuntu Touch has a better "UI" (I've also run this) but the Ubuntu guys have basically been ignoring VOLTE and since all major US carriers have switched over to VOLTE, your phone basically can't really make calls now on Ubuntu Touch (but that's OK, they've improved a bunch of other stuff! /sarcasm off).

Ubuntu Touch (not that you asked) is also a LOT slower than it should be and because the Ubuntu Touch guys are pursuing an 'Over the Air' update model, since the OS can basically be overwritten, applications aren't actually unpacked at install time but dynamically at run time. On a desktop this is OK but on a phone it leads to very slow app loading times.

I have high hopes for the current batch of Linux phone projects, Mobian, postmarketOS, etc but sadly I'm on Android until these are fully solidified.

Wow, this comment sounds like it's written by someone who's never interacted with "musicians" or thinks a musician is a person who goes on stage and plays the same song over and over. And further thinks that engineering or being an "athelete" or "musician" is a very narrowly scoped job.

Musicians, like any other "professional" have a broad range of functions from arrangers, composers to song writers, performing musicians, session musicians, touring musicians and so on.

A jazz musician (who might be performing live on stage) will likely not play the same song the same way twice. Is a jazz musician then not a musician because they aren't "repeating a set of movements over and over?"

If anything writing a CRUD type application IS something that could be automated because the patterns and the goals are largely the same but to take this example and apply to what atheletes do is pretty misguided.

Most atheletes are dynamically reacting to their environment or situation, taking into account the newest data and formulating a plan "on the fly" to meet their goals (scoring a goal, landing punches, etc).

My own credentials including multiple engineering degrees, experience designing equipment for "musicians" and "atheletes" so I don't think I'm talking out my ass here.

Anyone who wants a genuinely detailed treatment of this subject should read Allan McDonald's book "True, Lies O-rings" *. I happened to have finished this a few weeks ago and it goes on my list of all "engineers should read this".

This was really one of the most fascinating books I've read and likely the most definitive treatment of the subject by a subject matter expert. I kind of skimmed the blog article, the book explains in critical detail the issues with the original design and why the re-design (done after the disaster) was a much more robust approach.

In a nutshell the Shuttle SRB field-joint design was taken from a Titan missle design that was deemed to be "solid engineering" because none had blown up, but Allan mentions the SRB field-joint was flawed from the start and the joints suffered rotation and physically moved / flexed. (Later, it turns out a Titan missle exploded and the teardown showed the o-rings a primary point of failure).

Allan mentions it was the blowby past the o-rings that was consistently the issue and the engineers wanted to understand and address this problem for a long time.

What was striking to me, beyond the technical aspects of making these things work is the actual cover-up and attempt on NASA+Thyokol to blame McDonald and others for the resulting disaster. I knew of some parts of this, but you don't realize how messed up the situation was/is until you read the book.

Personally I'd ignore any negative reviews of the book, I think non-engineers, especially those who haven't worked in an Aerospace/Defense environment or in a big company might think Allan is arrogant or boasting, but he starts by providing the foundation for his statements before getting into the details which is a classic "engineer's engineer" way of thinking.

* https://www.goodreads.com/author/show/2101296.Allan_J_McDona...