I see you’re a project manager. Have you considered running the ai at 1200% for one month instead?

systemctl list-dependencies --reverse anydesk should show if any other services depend on them

Here, as linked from the article:

IMO storing Passkeys in Google Password Manager is a bad idea in general.

Pray I do not adjust it further.

Add renovate bot (self-hosted or not) or a similar not to your nixos repository to automatically update your lock file. Enable automatic system rebuilds (not live, nixos-rebuild boot…) to keep in sync with the repo.

Include multiple nixos systems in one repo, then reuse configuration or even make them reference each other (if you want that)

Find an issue to report upstream (or even add a pull request)

Fully automate your reinstall using disko and nixos-anywhere (don’t forget luks)

Be happy (optional)

Go over everything you’ve written in your repo so far, realise it’s formatted wrong and spend 2 hours fixing it until it no longer works

Build a derivation for something that doesn’t exist (also add a pull request if applicable and you’ve got time to maintain it)

Add a little nixpkgs-unstable, as a treat (use overlays)

Backups

Build a server so convoluted, kubernetes is easier to manage (I am here)

It’s a *feature*

There exists shims that are signed by Microsoft and were not revoked. Normally this would be fine but these shims had weaknesses that allowes hackers to load any code using them. Normally the shims should only run other signed/trusted code. These vulnerable shims can be used to bypass secure boot by replacing your existing bootloader with the shim and then running rootkits/hackerOS/whatever and bypass bitlocker using TPM or just running a level 0 virus that can’t be detected by the OS on any PC which trusts Microsoft’s keys (99% of all PCs)

To prevent this you’d have to not trust the vulnerable shims by either adding them manually to the exclusions list or using your own secure boot keys which would only trust the few bootloader files your pc uses and no other files.

Worst case: it behaves as if secure boot wasn’t on. Without secure boot you wouldn’t need this exploit cause then you can replace the bootloader with whatever you want anyways. With or without secure boot you need administrative permission to replace the bootloader so this is only an issue after your PC is already compromised or if someone had physical access to your PC.

tldr: Either use your own keys or don’t trust secure boot.

This is the year of the OpenAI bankruptcy.

Fair enough, I meant consumer demand as in not ai and data centers

Ram demand expected to drop another 40-50% in Q3?

All things are solved by lowering your standards far enough.

You sure it wasn’t cat?

I know you can use a root shell with cat image.ISO > /dev/[...] for disk images/ISO in disk image Format (so most ISO that aren’t Windows) but using the cp command would be news for me.

Yeah Microsoft Canonical is too quick to go all-in on new things to the depriment of the OS.

See also “The human condition” and “It’s a canon event!”

Using a lot of words to say “It won’t affect this quarter”

How about a dislike button? Maybe even a rating system where you can vote how good a video was on a range?

Small correction:

Like, copyfail and dirtyfrag would punch through containers, but also punch through SELinux.

User namespaces and optionally limited capabilities severely limit the usefulness of both of these exploits. K8s containers with user namespaces or rootless podman prevent host-root and only allow elevating to container root (host uid != 0) and cross container cache pollution (jump to other containers that use the same base image?)