People don't usually understand that apt allows you to configure multiple sources across versions simultaneously, so you can e.g. run stable, but also selectively install from backports or unstable.
To do so, add the sources for trixie-backports and unstable, and add the following configuration (e.g. /etc/apt/preferences.d/trixie-sid-pin) so that the system knows which sources your prefer:
# Default to trixie
Package: *
Pin: release n=trixie
Pin-Priority: 990
# Very low priority for sid
Package: *
Pin: release n=unstable
Pin-Priority: 100
# Give backports medium priority
Package: *
Pin: release n=trixie-backports
Pin-Priority: 500
Now the system can access the latest kernel from unstable (and backports), while keeping everything else on stable:
> People don't usually understand that apt allows you to configure multiple sources across versions simultaneously, so you can e.g. run stable, but also selectively install from backports or unstable.
Which is just as well, because that's not generally a good idea unless you really know what you're doing:
Granted, the kernel is probably the best thing to do it with, on account of their aggressive stance on compatibility and the narrowness of impact (no .so files in play).
Backports are meant to work well along stable packages, but I agree it's definitely not a good idea to start pulling from sid from trixie (for regular packages, kernel is fine), this is asking for a ruined system.
Chaing priority wholesale is not needed just to install kernel image and might break other packages. Just install kernel image from backports after enabling backports.
> apt install linux-image-amd64/stable-backports
Somehow installing with `trixie-backports` isn't picking up latest kernel for me. Used what is being displayed in `apt search linux-image-7`
Live patching production kernels makes sense when there is an imminent threat/timeline and rebooting is throttled due to underlying throttling mechanisms that are guarding the health of distributed systems running a-top the systems. Here's a real example I am familiar with:
Consider a hyper-converged cluster with many nodes serving distributed block storage, say at N=3 replication. This can tolerate exactly one N=1 node of outage for the reboot. It would seem preferable to drain the nodes in a way that allows for more parallelism in the per-node kernel-reboot process, but draining is expensive and its cheaper to reboot and hope the data comes back to the pool within some period of time after the reboot. This gets worse linearly as the cluster grows.
A non-trivial size cluster facing this can have a reboot rollout easily stretch from hours into days and even weeks. It is further made slower when the roll-out itself is repeatedly paused when any other production issue is detected, or some other in-cluster event is happening and distributed storage health is degraded or unavailable. If a single (additional) node goes out during the reboot roll-out, data goes unavailable and storage must wait and heal. It also simply takes time for the cluster to reconcile when the storage eventually comes back from reboot to make sure it is all still there.
If your systems are large enough, things will go so slow that things fall into the trap where the target release changes mid-deployment: to benefit from everything learned in the last many days or weeks, security, performance, crashes, whatever! There is benefit because the fixes you cared about most got onto a portion of the cluster sooner than later. There is also penalty, as this resets the time it takes to deploy, elongating the perceived end-to-end deployment time. This negatively affects OKRs and similarly displaces the release of anything that was queued for upcoming releases.
So yeah, live patching is great to get priority fixes out in a matter of minutes or hours. I also think it is the best tool to get oneself out of this rollout-reset trap and onto the next release sooner. Faster than rollback or rollover.
> I wonder how long these sorts of games will play before the law applies itself.
Perhaps roughly as long as the law turns a blind eye to AI corps flagrantly violating the attribution requirements of software licenses that apply to their training data, as well as basically ignoring other copyright requirements at scale. Fair use, my eye.
It's Antropic defrauding people here, the person using it for fighting anti-social behavior (or even a troll doing the anti-social behavior themselves) isn't guilty of it.
if someone is trying to use LLM tools in a project that explicitly forbids the use of LLM tools, they are not innocent.
if someone is blinding slurping up content to feed to LLMs, without checking to see if a particular source is OK with that, they are arguably not innocent either.
Neither situation is analogous to a booby-trapped shotgun door blowing off the face of a would-be burglar.
I'm not leaving boody traps. I have the right to talk about OpenClaw or even to write the anti antropic string. I didn't delete you token usage or charge you extra boxes. Antropic did.
If tomorrow Antropic decide to charge you extra if you interact with someone who talked badly about them, I'm still in my right to talk shit about them.
This is the same logic of 'not a booby trap' booby trap,s which sometimes do work out in the favor of the one setting them if they weren't too open about it. If your commit message is that you are talking about OpenClaw just to booby trap your repo, then I suspect it wouldn't fly, where as if you gave it some plausible deniability, a lawyer would be able to get any suit or charges dismissed.
This is all under the assumption we eventually live in a world where booby trapping repositories becomes a legal issue. On one hand that feels silly. On the other hand, we have had far less sensible cases make it to court and there is a small kernel of similarity which the legal system might latch onto.
If someone doesn't want you to use AI on their repository, they state it.
And if they want to "booby trap" (Antropic logic), them it's they right, you have been warned.
I can't see how you rights to use AI is prevalent on the right of anybody to write the string "OpenClaw" or any string forbidden by your AI provider.
Seriously, if the author hides it and trick your AI agent to check it, well maybe. But otherwise, it's not even a question.
This is extremely naive. If you are in Germany and I am in the US and you get a default judgement against me (which would cost you money to get), good luck getting it enforced internationally. Hint: it's way, way harder than you think.
The "runtime" is a google internal distribution of libc + binutils that is used for linking binaries within the monolithic repo, "google3".
This decoupling of system libraries from the OS itself is necessary because it otherwise becomes unmanageable to ensure "google3 binaries" remain runnable on both workstations and production servers. Workstations and servers each have their own Linux distributions, and each also needs to change over time.
IIRC Google has a policy whereby all google3 binaries must be rebuilt within a 6-month window. This allows teams to age-out support for old versions of things, including glibc. grte supports having multiple multiple versions of itself installed side-by-side to allow for transition periods ("v5" in the article).
Given that this strategic reserve is to be built from all the various civil and criminal asset forfeitures, and not actually buying any crypto currency, how exactly is this considered a "wealth transfer"?
This is centralizing governance of forfeited assets from across the many agencies that are currently holding wallets with no direction, into a single place: the Treasury. This seems far favorable to letting various (430+) agencies manage these valuable assets on their own where they can easily be lost, stolen, etc.
Being a baggie for bitcoin begs the question that it’s necessarily going to increase over time. Given that Blackrock recently published a video reiterating the ground truth that there is no ultimate guarantee that the finite supply of bitcoin could not be increased, there are signs maybe this isn’t so bulletproof.
No one will ever persuade me to or vast swathes of other bitcoin node runners, to run a version of bitcoin with a higher cap. It devalues our bitcoin. It devalues bitcoin full-stop.
Sure, a new fork can be, and in fact are, created with a higher cap, but why would people choose it over a harder system with a lower issuance?
Even if it somehow took hold, the old harder version of bitcoin would beat the newer softer version just like it's beating the soft fiat money we currently use.
I think the unspoken rationale is that governments can compel you to destroy a market. Look at when the US seized all of the gold in May of 1933. Blackrock operates in time scales where this sort of risk awareness is relevant.
Sure. But how does a government, or even governments, compel bitcoiners all around the world to stop running a version of bitcoin core on their nodes (likely running over TOR)?
Well considering the feds have charged and sentenced people for the activity of their exit nodes (CSAM), to which tor project has no response, I wouldn’t bother with Tor.
I’m sure the feds could force funding attached to crypto accounts to be verified by a trusted version of the bitcoin network or they are not legal to trade. They don’t have to physically stop the mining or validation, just the on/off ramps and banks who use it as collateral.
> Well considering the feds have charged and sentenced people for the activity of their exit nodes (CSAM), to which tor project has no response, I wouldn’t bother with Tor.
I'm certainly not a Tor expert, but I don't think bitcoin nodes running over Tor require an exit node. Even if they did they don't need to be located in the US.
> I’m sure the feds could force funding attached to crypto accounts to be verified by a trusted version of the bitcoin network or they are not legal to trade. They don’t have to physically stop the mining or validation, just the on/off ramps and banks who use it as collateral.
We could debate the details on a per-nation basis, but ultimately it's pointless. Even if it is possible for a nation to completely suppress bitcoin use within its borders, there will always be some country somewhere that embraces bitcoin and value looking to be stored will always migrate to the best store of value (bitcoin), just as air moves to the lowest-pressure volume, bitcoin miners move to areas with wasted, unwanted energy and electrons travel to less negatively-charged parts of a circuit.
CSM is required for tools that aren't UEFI enabled. memtest86+ for example can't use a UEFI GOP and requires a BIOS capable VGA. Can't be used with a UEFI-only video card (e.g. recent ryzen igpu).
Also, there is still plenty of hardware out there that only comes with BIOS-capable option roms. These still require CSM if you want them to be be visible at boot.
To do so, add the sources for trixie-backports and unstable, and add the following configuration (e.g. /etc/apt/preferences.d/trixie-sid-pin) so that the system knows which sources your prefer:
Now the system can access the latest kernel from unstable (and backports), while keeping everything else on stable: I believe the kernel in backports gets updated only after it is live in unstable for at least a week, which lately still feels like forever.