mbakke

For those who resonate with "why might this be useful", here are "plain git" alternatives to this tool:

searching for a function I deleted

    git log -G someFunc

I use `git worktree` to "mount" long-running branches much to the same effect as Julias tool. To quickly look at a file from a non-mounted branch/commit, I use:

    git show $REF:$FILENAME

    git log --all -G someFunc

They were also tapping the private network links of the Norwegian oil company Equinor (formerly Statoil) according to the original leaks.

It's kind of odd that neither of these oil giants have put pressure on the U.S. government as a result. They are about the only "victims" big enough to pursue the case legally.

I suspect a Supreme Court case is just about the only thing that can bring some of the remaining documents to light. Anyone with access today is almost certainly under some gag order.

I have a similar workflow, but make a bunch of commits with "git commit --fixup HEAD". (Or --squash REF).

Then on the final rebase the commits are automatically ordered with s and f as appropriate.

Although I do a fair bit of amending, too.

git rerere only "automates" conflict solving after you already solved it. As in, it remembers previous merge resolutions, even if you undo the merge/rebase.

It is particularly useful when doing difficult merges regularly. Invariably I'll find a mistake in the merge and start over (before pushing, obviously); the second "git merge" remembers the previous resolutions so I don't have to solve all the same conflicts again.

Similar for difficult rebases that may need multiple attempts.

Git remembers resolutions across branches and commits, so in the rare case where (say) a conflict was solved during a cherry-pick, rerere will automatically apply the same resolution for a merge with the same conflict.

I think the reason it's not on by default is that the UI is confusing: when rerere solves for you, git still says there is a conflict in the file and you have to "git add" them manually. There is no way of seeing the resolutions, or even the original conflicts, and no hint that rerere fixed it for you.

You just get a bunch of files with purported conflicts, yet no ==== markers. Have fun with that one if you forget that rerere was enabled.

The only "enterprise" feature of RHEL is Red Hat support.

There is nothing to standardise. If anything we need more commercially backed distributions to tear down the monoculture.

Great article. Real life horror stories of life-critical software gore, with some good news at the end.

It should be illegal to sell software that someones life depends upon without giving the user the right to inspect and modify the code.

I used to work with a guy that mounted a keyboard vertically on each side of his chair, using both at once.

A true legend.

Thank you! Setting SOURCE_DATE_EPOCH to the most recent file timestamp found in the source input is a clever hack.

Guix has tooling to verify binaries:

https://guix.gnu.org/en/manual/en/html_node/Invoking-guix-ch...

"guix build --no-grafts --no-substitutes --check foo" will force a local rebuild of package foo and fail if the result is not bit-identical. "guix challenge" will compare your local binaries against multiple cache servers.

I build everything locally and compare my results with the official substitute servers from time to time.

How is that possible? Is nixpkgs an input to the Python derivation? Or do packagers "hard code" a value every time they modify the Python build code? Automated tooling that sets it after pull requests? Something else? :-)

It obviously depends on the hardware, but IIRC for me maybe 3-4 hours building from the 357 byte seed to the latest GCC.

The early binaries are not very optimized :-)

Typically part of a "version string":

    $ python3
    Python 3.10.7 (main, Jan  1 1970, 00:00:01) [GCC 11.3.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>>

Indeed time stamps are probably the most common sources of indeterminism. So common that a de-facto standard variable to fake a timestamp has been implemented in many compilers:

https://reproducible-builds.org/docs/source-date-epoch/

Very impressive milestone, congrats to those who made this possible!

[...] actually rebuilding the ISO still introduced differences. This was due to some remaining problems in the hydra cache and the way the ISO was created.

Can anyone shed some light on the fix for "how the ISO was created"? I attempted making a reproducible ISO a while back but could not make the file system create extents in a deterministic fashion.

I had similar thoughts about VMware (large installations) back in the day. Weird proprietary OS to run other operating systems? Yet they turned out fine.

This appears to be a much better system than VMware, is free as in software, and it builds upon a free software operating system with lineage that predates Linux.

I say this in the most critical way possible, as someone who has built multiple Linux-based "cloud systems", and as a GNU/Linux distribution developer: I love it!

If everyone had this mindset we would be running our workloads on Microsoft Windows by now.

GNU/Linux was also "risky" at some point.

No sarcasm. Less snark than an average Slashdot comment. Cowboy Neal.

No wireless. Less space than a nomad. Lame.

The sister comment appears to be somewhat confused. The "virality" of GPL is that if you "link" a GPL program then your license must be compatible and the combination as a whole becomes GPL. Importing a library may count as a derived work/linking.

The LGPL was created to avoid this limitation and is a natural choice for programming languages and interpreters.

As an example, GNU Guile, an interpreter for the Scheme language, is LGPL licensed. Writing any nontrivial Scheme script requires importing code from Guile. If it was GPL then all scripts had to be GPL compatible; but since it's LGPL, programs using Guile modules can have any license (even proprietary).

The "tree" command will output JSON on fd3 (which it dubs 'stddata') when available.

If more programs adopt that pattern we could use stdout (fd1) only for interactive programs.

Ah, the irony of scale!

As far as I know, Google does not actually use k8s for their public facing services (or anything at all?). I would love to be corrected on this.

Google was able to scale quickly back in the day by keeping things as simple as possible. "1 hard drive per server" level simple. Center everything around one massive job scheduler (Borg).

Of course a lot has changed since that time, but I can't see Google upending a established infrastructure by making k8s plugins for their network requirements, tying k8s into Borg, etc. It would give less visibility and debugability for little gain.

(But again I have zero inside knowledge here)

At scale there is no one size fits all. Kubernetes can fit a lot, but will always fall short of a tailor made solution.

For more unsolicited advice from an armchair infrastructure hyperscale expert, please subscribe to my newsletter.

Red Hat (and other) EULAs have always been "against" the GPL. For example by limiting the amount of nodes you can run the software on. What they did now was close a loophole that implicitly said "if you repackage our software and distribute it separately you can ignore everything else in this agreement".

They explicitly acknowledge that the EULA does not impose restrictions on rights granted by the software licenses[0]:

1.4 End User and Open Source License Agreements. [...] This Agreement establishes the rights and obligations associated with Subscription Services and is not intended to limit your rights to software code under the terms of an open source license.

So users are still free to fork and redistribute any code obtained through the subscription. Red Hat just may refuse to do further business if you do so.

To me the "spirit" of the GPL is in collaboration. All of Red Hats software projects are still available in public forges for anyone to fork and contribute. An evil or antisocial move would be to take Ceph, Podman, systemd, etc behind closed doors and require a subscription that terminates if you exercise GPL rights. But that is not what is happening here.

[0] https://www.redhat.com/licenses/Appendix_1_Global_English_20...

I think we, as free software consumers, have become spoiled by the sheer amount of quality software and distros available for no charge, with all the freedoms, over the past couple decades.

In my eyes this move is perfectly within the spirit of the GPL, which explicitly allows charging for the program. Crucially it makes no promise about future updates.

Red Hat can terminate a subscription for a variety of reasons, not limited to taking all their software to make a competing distribution. However even if they do cancel it, you are still entitled to get the source code of all (GPL) software you aquired up to that point.

It will be funny if RH in a further crackdown decides to not publish sources for non-GPL (MIT/Apache/etc) in the public channels that Rocky et.al. use. Would spark a new fire in the permissive vs copyleft debate.

I actually think this move is beneficial for the free software movement overall. Most/all the sources Red Hat use are still available in upstream repositories, and many other distros package it without Red Hats handcuffs.

You're right I did miss the details. Sorry for the inaccurate rant. Good for them. We all benefit from more players in this space, instead of just a bunch of RHEL clones.

Making a RHEL clone from CentOS stream is absolutely using "Red Hat code".

Also, isn't CentOS stream already ABI compatible? Just occasionally ahead of RHEL?

I really don't understand the outrage from RH cracking down on clones. With entitled CentOS users going "I don't want stream, despite it being a rock solid gratis platform; I want the 10 year support battle tested code, but without giving you any money".

I do understand some users of RHEL/CentOS-of-yore rely on other vendors that only support specific versions of RHEL (looking at you, Infiniband drivers..), but those vendors could (and should) be encouraged to support Stream and other distributions (if only at the source level), not contribute further to the RHEL monoculture.

With Rocky and Alma we're right back where we started. Sad panda.

I think what's really needed is a competitor to RHEL in the scientific computing/HPC space. Though it's a difficult market to penetrate. SuSE has tried for ages, and Ubuntu just isn't up for it (also making custom deb repos are much harder than RPM).

After following a couple of links I learned that Rocky gets their sources from spinning up RHEL cloud VMs and similar shenanigans. Could they not just buy a single subscription and get direct access to everything?

In fact I'm glad Red Hat cracked down to prevent predators like Oracle to just rebrand the distro and call it "unbreakable Linux" as if they built it. Well they still can if they pay for it. This monoculture, and especially focus on bug-for-bug compatibility is just ridiculous. Alma is doing something different by simply focusing on ABI compatibility and can otherwise aim for security or performance, but I'm afraid most people will flock to Rocky just because nobody ever got fired because of a RHEL bug.

Thanks for coming to my TED rant.

Here is the full list of this (and previous) years winners:

https://improbable.com/ig/winners/

And here is the full (virtual) ceremy, possibly even cheesier than the live ones that used to be held on the Harvard campus:

https://youtu.be/P9UQi0ORXv4

uBO works fine on Firefox for Android.

So selling GPL software is unethical, but selling proprietary software is? That's an unusual point of view!

I don't have WP experience and don't understand what "splits up the repos which messes with the upgrade structure" means. I can sort of understand the argument that not buying a new license can prevent upgrades, but, I still think it's within the spirit of the GPL. As a user of said plugin, you can choose to make the necessary changes yourself (or hire someone for it). Or look for a gratis alternative.

To me it sounds like the GPL is doing exactly what it was designed for.

My primary issue with the WP ecosystem is how folks end up paying for GPL software.

Why is that a an issue? Sounds like WP has solved a problem that an entire industry has wanted to achieve since the invention of the GPL.

Red Hat also sells GPL software. The problem for them is that customers are simply rebranding Red Hat at a cheaper price point, becoming competitors.

I'm kind of surprised this is not happening in WordPress land.

They explicitly mention that in the famous article, but concede that they are not mature enough for that.