3 ms·

I refuse to use anything with python tooling now. I just don't. It is just so extremely rare that things work on the first try with it. I have a keyboard proje

I refuse to use anything with python tooling now. I just don't. It is just so extremely rare that things work on the first try with it. I have a keyboard project that runs on an RP2040, and the firmware is in Rust. Here are the steps to flash it if you're starting with just the repo and no Rust toolchain: (install rustup) $ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh $ rustup target add thumbv6m-none-eabi $ cargo install elf2uf2-rs * Put the keyboard in bootloader mode * $ cargo run --release This is relying on rustup and Cargo to do the heavy lifting of toolchain management and building, which they are fantastic at. Python projects don't even come close.

bborud 2y ago
That looks quite lovely. I really hope that MCU manufacturers invest in Rust and that they both manage to do so in mechanical sympathy with the Rust community and that they realize they have to cooperate on common tooling.
franga2000 2y ago
You're comparing the "traditional Linux approach" to curl-pipe-bash, not comparing the actual environments/toolchains. Platformio: curl https://.../get-platformio.py https://.../get-platformio.py | python3 && pio run Pipx: apt install pipx && pipx [build-script.py] Pipenv: pip install --user pipenv pyenv && pipenv run [build-script.py]
- bborud 2y ago
  They key isn't so much how you install the tools, since that's hopefully something you only do very occasionally, but the quality of life those tools provide once installed.
- bschwindHN 2y ago
  As mentioned already, it's not about the method of installation. In my experience python-based tools are slower and buggier than their native counterparts, and that's only after going through the installation process. Tools written in C / C++ / Go / Rust just don't have nearly as much fuss, and they run faster and are smaller too.
  - franga2000 2y ago
    Go & Rust maybe, but I've had nothing but trouble with C/C++. Bigger projects usually have their build process well documented, but smaller thing usually give you an apt-get command for Ubuntu 18 and maybe a Makefile. Good luck running that even two years later on a different distro. The package names won't match and when you find them, the new version won't be compatible and the old version won't be in the repos, so you need to build that from scratch, recursively...
    - bschwindHN 2y ago
      Building C projects from scratch usually isn't bad. I never trust debian-based distros to have anything up to date, so that's usually a lost cause anyway. C++ on the other hand...yeah those projects aren't often fun to build.
    - bborud 2y ago
      It isn't so much that it is hard to build things - it is more that it is hard to distribute software for Linux because there are so many targets to build for. It is unreasonably hard to build binaries for distribution to more than one Linux distro. So people are disinclined to even try. You can, of course, build static binaries (and people really should do that more often) and distribute tarballs, but then you might run into all manner of licensing issues. (Not to mention the tedious discussion about upgrading shared libraries under the feet of applications and praying it doesn't introduce hard to detect breakages). One direction I'd love for distro designers to explore is if Linux distributions were to abandon the traditional splatterfest style of software installs, where an application scatters lots of files across several filesystems and depends on system wide libraries, and instead puts each application in a self-contained directory. Or rather, two: one for the immutable files (binaries, libraries etc) and one for variable state. That way you could choose if you want to do static linking or dynamic. Because any shared libraries could be part of the immutable application directory. Oh yes, it'll result in a lot more disk use, but disk drives are cheap, and libraries rarely make up that much of your disk use anyway. But there is a fair chance you could address some of that with filesystem level deduplication. You could also have systems for distributing shared libraries from trusted sources so applications do not necessarily have to include the shared libraries, but that they can be fetched as part of the install system. And then manage shared libraries locally with hardlinks or some form of custom filesystem trickery. This would have a few added benefits (opportunities for supply chain security, reducing size of distributed packages etc). macOS does this only partially, but applications still depend on shared libraries and you have the horror that is the Library directories which are somewhat randomly structured, resulting in lots of leftovers when you try to remove applications. macOS has some interesting ideas, but the execution of them is....inconsistent at best. The reason package managers don't work well is that they are trying to solve a lot of problems we shouldn't be having in the first place. And because nobody wants to simplify the problem they have to solve, distribution maintainers will keep writing package management systems that are a pain in the ass.
bborud 2y ago
On closer inspection, I'm assuming you meant: cargo flash --release --chip <name>
- bschwindHN 2y ago
  Nope, it's exactly as written. I use a cargo runner, configured here: https://github.com/bschwind/key-ripper/blob/main/firmware/.cargo/config.toml https://github.com/bschwind/key-ripper/blob/main/firmware/.c...
  - bborud 2y ago
    Wow, that is nice.

bborud 2y ago

That looks quite lovely. I really hope that MCU manufacturers invest in Rust and that they both manage to do so in mechanical sympathy with the Rust community and that they realize they have to cooperate on common tooling.

franga2000 2y ago

You're comparing the "traditional Linux approach" to curl-pipe-bash, not comparing the actual environments/toolchains. Platformio: curl https://.../get-platformio.py https://.../get-platformio.py | python3 && pio run Pipx: apt install pipx && pipx [build-script.py] Pipenv: pip install --user pipenv pyenv && pipenv run [build-script.py]

bborud 2y ago
They key isn't so much how you install the tools, since that's hopefully something you only do very occasionally, but the quality of life those tools provide once installed.
bschwindHN 2y ago
As mentioned already, it's not about the method of installation. In my experience python-based tools are slower and buggier than their native counterparts, and that's only after going through the installation process. Tools written in C / C++ / Go / Rust just don't have nearly as much fuss, and they run faster and are smaller too.
- franga2000 2y ago
  Go & Rust maybe, but I've had nothing but trouble with C/C++. Bigger projects usually have their build process well documented, but smaller thing usually give you an apt-get command for Ubuntu 18 and maybe a Makefile. Good luck running that even two years later on a different distro. The package names won't match and when you find them, the new version won't be compatible and the old version won't be in the repos, so you need to build that from scratch, recursively...
  - bschwindHN 2y ago
    Building C projects from scratch usually isn't bad. I never trust debian-based distros to have anything up to date, so that's usually a lost cause anyway. C++ on the other hand...yeah those projects aren't often fun to build.
  - bborud 2y ago
    It isn't so much that it is hard to build things - it is more that it is hard to distribute software for Linux because there are so many targets to build for. It is unreasonably hard to build binaries for distribution to more than one Linux distro. So people are disinclined to even try. You can, of course, build static binaries (and people really should do that more often) and distribute tarballs, but then you might run into all manner of licensing issues. (Not to mention the tedious discussion about upgrading shared libraries under the feet of applications and praying it doesn't introduce hard to detect breakages). One direction I'd love for distro designers to explore is if Linux distributions were to abandon the traditional splatterfest style of software installs, where an application scatters lots of files across several filesystems and depends on system wide libraries, and instead puts each application in a self-contained directory. Or rather, two: one for the immutable files (binaries, libraries etc) and one for variable state. That way you could choose if you want to do static linking or dynamic. Because any shared libraries could be part of the immutable application directory. Oh yes, it'll result in a lot more disk use, but disk drives are cheap, and libraries rarely make up that much of your disk use anyway. But there is a fair chance you could address some of that with filesystem level deduplication. You could also have systems for distributing shared libraries from trusted sources so applications do not necessarily have to include the shared libraries, but that they can be fetched as part of the install system. And then manage shared libraries locally with hardlinks or some form of custom filesystem trickery. This would have a few added benefits (opportunities for supply chain security, reducing size of distributed packages etc). macOS does this only partially, but applications still depend on shared libraries and you have the horror that is the Library directories which are somewhat randomly structured, resulting in lots of leftovers when you try to remove applications. macOS has some interesting ideas, but the execution of them is....inconsistent at best. The reason package managers don't work well is that they are trying to solve a lot of problems we shouldn't be having in the first place. And because nobody wants to simplify the problem they have to solve, distribution maintainers will keep writing package management systems that are a pain in the ass.

bborud 2y ago

On closer inspection, I'm assuming you meant: cargo flash --release --chip <name>

bschwindHN 2y ago
Nope, it's exactly as written. I use a cargo runner, configured here: https://github.com/bschwind/key-ripper/blob/main/firmware/.cargo/config.toml https://github.com/bschwind/key-ripper/blob/main/firmware/.c...
- bborud 2y ago
  Wow, that is nice.