I suspect that the number of Bazel experts out there is not terribly large, but: I'm hitting github.com/bazelbuild/rul… - one of the dependencies of a go_library() target needs a specific build tag to work in my environment. Is there any way to do that at the moment?
Ok so the right thing to do here is to express the tags in the go_binary() target, but what's actually breaking things for me here is that go_repository() has "helpfully" called gazelle and generated a BUILD file that has copts set for the default tags
Which means even when I pass the correct build tags, gcc is being called with the flags set by the wrong build tags, and all the #ifdefs are wrong as a result
Ah ok the fix is to add build_tags = ["foo","bar"] to the go_repository() definition in the workspace config
• • •
Missing some Tweet in this thread? You can try to
force a refresh
It's been almost 15 years and a recent thread on LWN brought this up again so: why did we briefly have two drivers for R500 and R600 ATI chipsets under Linux (a thread)
ATI had supported development of Linux drivers for their chipsets up until the R300, and R400 was similar enough that stuff got bodged together. R500 had an entirely new display engine and so no existing code worked. Fuuuuuuuuuuu.
After a bunch of time Jerome Glisse reverse engineered enough to get modesetting working, giving us the xf86-video-avivo driver. This was made possible by the Xorg modularisation effort (previously, drivers were tied to the X11 server release schedule)
Fascinating - ClearOS, the OS used on the scammy MAGA "Freedom Phone", ships a modified version of Signal that seems to be based on Signal 5.8.10, which means it's almost exactly a year out of date: clearos.app/app/com.clearo…
I haven't been able to find the source code anywhere, so I'm working off decompiled binaries - most of the changes just seem to be branding pointing to their app store instead of the Play Store, but there's a bunch additional support for backing things up to their servers
It does seem to be using the standard Signal servers so presumably interoperates, which I suspect @signalapp might have feelings about
Thanks to a great suggestion from @dlprip, I think it's actually possible to transition Boot Guard protected systems to being able to run Coreboot while still providing strong security guarantees (note: this would still require the cooperation of the system vendor)
The @FrameworkPuter people had suggested some sort of signed shim that would satisfy Boot Guard and would then jump into user-provided firmware. Good for freedom, but what about people who want stronger guarantees that their firmware hasn't been tampered with?
In the UEFI boot shim, we use an approach @openSUSE came up with - any user-provided keys are stored in variables that can only be modified by the boot environment, which means the code running in the boot environment can trust them
Fun example of how selection pressure doesn't work the way you think! This is a male Long-tailed Widowbird. As you can see, it has a long tail. (Picture by Bernard DUPONT, CC-SA 2.0)
The long tails are unique to the males, and seem to make life more difficult for them. The longer the tail, the more visible the bird, and the harder it is to fly. Longer tails mean a higher probability of predation. So why haven't they been selected against?
Malte Andersson led an experiment that involved cutting the tails off some males and gluing them to the ends of others. The males with the unnaturally long tails had more reproductive success than both the males with the artificially shortened tails and the unmodified controls.