boris

> I am still in awe of NeXT's software technology, generally. It was just so carefully and intentionally designed as a coherent whole [...]

The closest I got to experience inner workings of NeXT software is observing the boot log of Mac OS (which you can see if you boot it with Qemu/Clover). I haven't seen so many triple exclamation marks in a while. That somehow didn't leave the impression of carefully and intentionally designed software.

I find the marketing spin in the title and the article unfortunate (standing on our own feet). The simple truth is they've decided getting another cross-signature not worth their trouble so now us users must expect some breakages the scale of which doesn't appear to be well understood.

Also, while the article focuses on the Android, my first thought was about all those outdated CentOS/Debian/etc boxes/VMs/containers that silently curl something from a cron job or such and that will all of a sudden stop working. So I expect a lot of infrastructure breakages.

> Oh, also Submodules suck like a supermassive, galaxy-core black hole.

They suck like a chainsaw would sucks for cutting twigs. But they are very effective (together with symlinks) when you need to stitch an amalgamation of multiple repositories (which themselves could be stitched from multiple repositories). That's not to say you don't loose a finger or two now and again.

To plug another CI service, there is https://ci.cppget.org with focus on C/C++. It's free and unlimited for open source projects, including Windows and Mac OS.

> But your taste — the thing that got you into the game — your taste is still killer, and your taste is good enough that you can tell that what you’re making is kind of a disappointment to you, you know what I mean?

"Talent is feeling how should not be."

On the page you mention CI/CD applications and we are considering using Raspberry Pi for our CI infra (for the lack of a more powerful option). While there are various possible setups, one fairly common arrangement (especially in a more public-facing services) is to start a throw-away VM for each CI request. This is how our CI service works and you can see it here[1] in action.

And while it would have been nice to use Turing Pi, it does not appear to fit our requirements very well because we need to have high-performance storage attached to each node (where we store/run the VMs). An ideal board for us would be a network switch plus for each module a PCIe (or better yet, NVMe) slot and USB 2.0 ports (at least 2x).

[1] https://ci.cppget.org

Interesting. Does anyone have any practical performance results to share?

This review suggests that a passive heatsink should be sufficient to prevent throttling (probably with a caveat that it's not in an enclosure):

https://downey.io/blog/raspberry-pi-4-heatsinks-and-fans/

Nice review, thanks. One thing in it that I believe is incorrect (or confusing) is PoE support: I don't believe it is built into the IO board but rather the board is compatible with the PoE hat.

There is build2[1] and libcurl is available[2] from cppget.org, its package repository.

[1] https://build2.org

[2] https://cppget.org/libcurl

Yes, that's me. If/when you give it a try, feel free to ping me[1] with any questions or issues.

[1] boris@build2.org, berium on reddit, boris-kolpackov on internals.rust-lang.

In your case it would be more like "adding" a make-like tool to tie all the steps together rather than "switching away" from anything.

The tool I have in mind is buid2[1] (full disclosure: I work on the project). In this context you would be using it as a portable (and saner) make replacement (though we do have a Rust module in the works but that is geared more toward multi-language C/C++ and Rust builds).

In fact, if you are interested, I am prepared to put my money where my mouth is and code up a demo/prototype for you (without any expectations that the result will be used).

[1] https://build2.org

Quoting from the linked discussion:

> The issue with Makefiles is that well, they're not portable. I'm on Windows, and 99% of this stuff Just Works really really nicely, but that means that "just use Make" isn't a real option. I love that Rust's tooling is so cross-platform, and this is just a final pain point. The problem is hard, but it's mostly about fiddly details.

> I'm trying to figure out how good I can make this without throwing it all out and doing something else. If we never push Cargo's boundaries, it will never grow into being a good fit for these projects.

The fundamental problem with Cargo is that it's not a general-purpose build system (like, say, make). It's a black box with a bunch of hooks for achieving certain common things that the black box itself doesn't handle. As a result, every time you step out of the "supported area", it will be yet another "final pain point" & "mostly about fiddly details".

I agree make is not a good fit for a cross-platform project (nor is Meson, IMO, due to the Python dependency). But there are good (IMO) options in this area that meet your requirements (cross-platform, no external dependencies, etc). I can elaborate if you are interested.

Exactly, IBM is a company run by finance, not technical people. They survive despite, not because of what they do.

Let's be specific, then, and exclude any software that is built with GNU make? First thing that goes is the Linux kernel (which can only be built with GNU make). As far as I know, Alpine still relies on the Linux kernel, so that's out.

And while at it, stop using all the "typical GNU bullshit". Let's see how far you will get.

Real-world usage of Clang modules (by Google) and preliminary/synthetic benchmarks of C++20 modules in GCC both show about 3x speedup. This might not be "much" for everyone, buy I will take it.

Nobody in their right mind will use `shared_ptr` in this context. It will be `string_view` in and out with lifetime management left as an exercise to the programmer.

It may not be fundamentally different but it may only use a subset of features (e.g., no exceptions in C++ code) and/or target a subset of platforms. Without pointing fingers, I am sitting on (what looks to be) a codegen bug in Clang that is not of a high priority I am pretty sure due to the above reasons.

This is not to say that I am not appreciative of all the work Google/Apple/etc engineers do in LLVM (I will be eternally grateful for the Clang targeting MSVC work).

Having contributed to both (nothing major but not trivial one-liners either), my feeling is GCC definitely has a higher quality codebase and a more rigorous review process. While the latter doesn't always translate to the ease of contribution, I found that if you are persistent enough, your patches to GCC will be reviewed. On the other hand, I had my patches to LLVM ignored forever. Just my 2c based on experience.

> they're sufficiently general and easiest to maintain by releasing back upstream (where Apple, Google, and Microsoft will pay a small army of compiler engineers to keep them working).

...keep them working for their use-cases.

Thanks. With "widely-used/public" I was hoping for something open source that runs on many people's machines (like a web browser) or at least on many company's servers (like qemu) as opposed to running on a single company's servers in a controlled and uniform environment.

If Servo is a dead end (by the sound of it), what is the new "halo project" that showcases Rust's use in something non-trivial and widely-used/public? (Not trying to rub salt in the wound, geniunly interested.)

Not bad, we might steal some of these ideas for build2 if you don't mind.

> other community members should be allowed to apply to take over that name. Of course, existing releases would stay untouched, but if I stopped maintaining my JSON library at 1.3.7, someone else should be allowed to take that over and publish 1.3.8 or later.

This part is iffy: if you release a patch, it implies that it has backwards-compatible interface. So this will realistically only work for taking over the maintenance of the old package, not for replacing it with something entirely new. I think a version epoch might work for the latter.

As the person you are replying to suggestes, a version epoch could be a solution.

> I've found Bazel and rules_rust provide a good alternative to Cargo, since Bazel can twist your build into any DAG you want, but most Rust users are unlikely to be excited about injecting 50MB of Java build system into the middle of their workflow.

If anyone is interested in another alternative to Cargo that doesn't involve Java, there is build2[1] and it's libbuild2-rust[2] module. It's a general-purpose build system so you can have mixed-language projects, etc.

[1] https://build2.org

[2] https://github.com/build2/libbuild2-rust

What if it were a single source-available version (that also allowed you to, say, get third-party support/customizations)?

This is essentially embedding bits and pieces of a makefile into source code as ad hoc comments. Which is what happens when you don't have a proper, general-purpose build system.

Actually, rustc produce a crate metadata (those .rmeta files) which is all that's needed to start compiling dependent crates. Producing this metadata is pretty quick compared to producing the finished crate.

> There'd been a number of spectacular C++ project failures...

And the most successful company of that era (Google) went ahead and implemented their product (the search engine) in C++...