Language Selection

English French German Italian Portuguese Spanish

Parallel emerge versus parallel make

Filed under

I’d like to provide a public, extended answer to a friend of mine who asked me earlier today why I’m not using Portage 2.2’s parallel emerge feature.

Well, first of all, parallel emerge is helpful on SMP system during a first install, a world rebuild (which is actually what I’m doing now) or in a long update after some time spent offline; it is of little help when doing daily upgrades, or when installing a new package.

The reason is that you can effectively only merge in parallel packages that are independent of each other. And this is not so easy to ensure, to avoid breaking stuff, I’m sure portage is taking the safe route and rather serialise instead of risking brokenness. But even this, expects the dependency tree to be complete. You won’t find it complete because packages building with GCC are not going to depend on it. The system package set is not going to be put in the DEPEND variables of each ebuilds, as it is, and this opens the proverbial vase to a huge amount of problems, in my view. (Now you can also look up an earlier proposal of mine, and see if it had sense then already).

More Here

More in Tux Machines

NATS Messaging Project Joins Cloud Native Computing Foundation

The Cloud Native Computing Foundation (CNCF) voted on March 14 to accept the NATS messaging project as its newest hosted effort. The NATS project is an open-source distributed messaging technology that got its start seven years ago and has already been deployed by multiple organizations including Ericsson, Comcast, Samsung and General Electric (GE). "NATS has room to grow as cloud native adds more use cases and grows adoption, driven by Kubernetes and containers," Alexis Richardson, Chair of the Technical Oversight Committee (TOC) at the CNCF told eWEEK. "CNCF provides a way to scale community and education so that adopters can engage faster and at all levels." Read more

The 'New' (and 'Improved') Microsoft

lkml: remove eight obsolete architectures

In the end, it seems that while the eight architectures are extremely different, they all suffered the same fate: There was one company in charge of an SoC line, a CPU microarchitecture and a software ecosystem, which was more costly than licensing newer off-the-shelf CPU cores from a third party (typically ARM, MIPS, or RISC-V). It seems that all the SoC product lines are still around, but have not used the custom CPU architectures for several years at this point. Read more

If you hitch a ride with a scorpion… (Coverity)

I haven’t seen a blog post or notice about this, but according to the Twitters, Coverity has stopped supporting online scanning for open source projects. Is anybody shocked by this? Anybody? [...] Not sure what the story is with Coverity, but it probably has something to do with 1) they haven’t been able to monetize the service the way they hoped, or 2) they’ve been able to monetize the service and don’t fancy spending the money anymore or 3) they’ve pivoted entirely and just aren’t doing the scanning thing. Not sure which, don’t really care — the end result is the same. Open source projects that have come to depend on this now have to scramble to replace the service. [...] I’m not going to go all RMS, but the only way to prevent this is to have open tools and services. And pay for them. Read more