- 6 Posts
- 42 Comments
20·23 days agoAs far as I know, there is no programmatic way to destroy an existing pizza. terraform destroy is implemented on the client side, by consuming the pizza.
I have a sticker of the nix one on a laptop.
2·1 month agoThis is the same technology that lets people play windows games on android with good performance. Because there is not direct access to the GPU, they have to use GPU virtualization in order to get it access to a Linux proot that runs wine inside.
I’m excited to see it being used and developed in other areas.
Familiarity instead of compatibility.
This piece of documentation from forgejo, about how their actions are mostly github actions compatible is how I feel about this or similar endeavors.
I really like KDE, because it’s familiar enough to Windows users that they can just kinda use it. Many of the shortcuts are the same. But I’ve had a bad experience with things that try to emulate Windows more completely, because people begin to expect some windows idiosyncracy or some other thing to be there. And then they get frustrated when it’s not the same.
KDE manages to be “close enough”, which results in a better experience.
Gnome used to much worse when it comes to ram usage, so the inertia of those sentiments still carry.
Kde used to be much worse, using what gnome uses now, but now kde has similar ram usage to xfce last time I tested. CPU wise it’s still much worse though.
The backdoor of the xz utils program(s) was in the tarball release, but not the main source code:
https://en.wikipedia.org/wiki/XZ_Utils_backdoor
If debian had dodged the upstream tarball, then they wouldn’t have been affected by this.
Is this because of the xz utils thing? The backdoor was included into the tarball, but it wasn’t in the git repo.
By switching away from tarballs they pribably hope to prevent that, although this article doesn’t mention that. It’s possible this shift has been happening since before the xz utils.
Did you post this right as I edited the title? Lol.
Not really? From this page, all it looks like you need is a salsa.debian.org account. They call this being a “Debian developer”, but registration on Debian Salsa is open to anybody, and you can just sign up.
Once you have an account, you can use Debian’s Debusine normally. I don’t really see how this is any different from being required to create an Ubuntu/Launchpad account for a PPA. This is really just pedantic terminology, Debian considers anybody who contributes to their distro in any way to be a “Debian Developer”, whereas Ubuntu doesn’t.
If you don’t want to create an account, you can self host debusine — except it looks like you can’t self host the server that powers PPA’s. I consider this to be a win for Debusine.
Lmao I love the opening choice used in the demo.
99.9999% of freecell games are winnable. Very nice, and one of the reasons I preferred freecell.
https://opensource.google/documentation/reference/using/agpl-policy/
WARNING: Code licensed under the GNU Affero General Public License (AGPL) MUST NOT be used at Google.
-
Corporations really, really love being admin on everybody elses devices. See kernel level anticheat.
-
I feel like people have gotten zero trust (I don’t need to trust anybody) confused with “I don’t trust anybody”.
-
I was listening to a podcast by packet pushers and they were like “So you meet a vendor, and they are like, ‘So what do you think zero trust means? We can work with that’”.
-
UWP 💀
UWP is Microsoft’s “new” app format, it’s what the windows store and the xbox use.
It also isn’t compatable with wine, and my pet theory is that this was the entire point of it. Combined with Windows S mode, which doesn’t let you install apps other than from the windows store, the goal was to lock down the windows ecosystem by having apps that can’t be made to run on linux.
I remember seeing a compatability layer for UWP apps a while ago, and I am pleased to see that it has come this far. Great work!
Edit: wait this uses a windows VM. Still good though and lets people escape the windows ecosystem.
Except debian testing doesn’t receive security updates in a timely manner.
It’s designed exclusively for testing, not really for people to actually use it.
I just installed Ciliium (another Kubernets CNI), and it also comes with a host based firewall, and an observability tool.
I didn’t have Hubble (observability tool enabled), but I previously didn’t have a firewall, and I finally decided to enable it, which caused my ceph deployment to fail. This will help me figure out where it is failing and what rules are needed to remediate it.
Share your lsblk output. It’s likely that your system still leaves the bootloader unencrypted on the disk, even if the kernels and bootloader config are being encrypted (they aren’t encrypted by default on most installs).
It is theoretically possible to have only one partition that is luks encrypted, but this requires you to store the bootloader in the UEFI, and not all motherboards support this, so distros usually just install it to an unencrypted partition. The UEFI needs to be able to read an unencrypted bootloader from somewhere. That’s why it’s somewhat absurd to claim that the ESP can be encrypted, because it simply can’t.
From your link:
One difference is that the kernel and the initrd will be placed in the unencrypted ESP,
Phoronix, you are the trolls.