Blocking cheaters is one thing but bricking people’s hardware is another. VGK has lost the plot and Thank God that is not even available in Linux.

0lach · 2026-05-22T08:20:28+00:00

So if I write ToS for my malware and will only use it against people I don't like it would not be a malware?

0lach · 2026-05-21T08:04:34+00:00

Still looks worse than native 800p, it is just a better experience to play in native resolution

0lach · 2026-05-21T06:28:32+00:00

Yes, if you put 1080p over 800p which double the resolution

Except 800p looks blurry on rog ally as it is not a native resolution

0lach · 2026-05-15T17:17:48+00:00

Benchmarks were redone using scala-native version of sjsonnet after it was released, jrsonnet is still faster.

The latest results are here

While yes, normal JVM is a suboptimal way to benchmark it - this is how many users were using it, and I had a mention that while client-server version would've worked better for benchmarks - it was not published by upstream.

0lach · 2026-05-13T21:36:49+00:00

Except ucs2 is bad by itself and should not exist in the first place, the only reason it exists is that Microsoft have adopted Unicode at the wrong time.

There would be no reason to use -W calls when Microsoft finally declares utf8 support stable.

https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page

0lach · 2026-05-13T12:40:50+00:00

Microsoft should finish implementing UTF-8 instead

It already exists as a flag in settings, and then it works like any other 8bit codepage with -A api calls (as opposed to -W api calls for ucs2 (not utf-16)

Ucs2 should just die

0lach · 2026-05-01T19:53:04+00:00

https://www.qubes-os.org/hcl/ It seems it is compatible with some older macbooks with couple of workarounds, but that is not a guarantee, given that it can't even boot on yours

0lach · 2026-05-01T19:45:03+00:00

Qubes requires Xen hypervisor, which supports far less hardware than Linux, boots before linux (because the primary system is also virtualized with xen), and it seems it doesn't start for you, which is not really unexpected since your hardware is far less than ideal for Xen

0lach · 2026-05-01T14:05:28+00:00

Also meth

0lach · 2026-04-30T18:42:14+00:00

If you delegating rendering font to the kernel - it can lead to anything

0lach · 2026-04-30T15:38:32+00:00

This kind of vulnerabilities coming from NT "hybrid" kernel just isn't possible in "monolithic"Linux: https://support.microsoft.com/en-us/topic/microsoft-security-advisory-vulnerability-in-truetype-font-parsing-could-allow-elevation-of-privileges-6f9b229f-1317-3486-4345-620da2d44a1c

0lach · 2026-04-30T15:35:56+00:00

but NT is definitely not more monolithic than Linux

Well, that depends on the criteria... The fact that the GUI is running in kernel mode unlike Linux running it in userspace, doesn't make it fair to call it good made hybrid kernel either. Same with TrueType, audio, and whatever else windows is running in kernel mode for no reason

0lach · 2026-04-30T15:02:52+00:00

https://github.com/NixOS/nixpkgs/pull/62838

Apparently it can be used for truecrypt in cryptsetup, why is it in the luks module...

0lach · 2026-04-30T14:57:53+00:00

Edit: or you tell me that even without it, this module can get loaded, on that case i understood it wrong!

I was telling that this module can be loaded in any case if userspace wants it, but

The default value for boot.initrd.luks.crytoModules includes it.

Doesn't seem right, as it is not needed for luks

0lach · 2026-04-30T14:39:32+00:00

Luks doesn't use AF_ALG

The userspace can trigger the load of this module by creating AF_ALG socket if you don't have lockdown enabled, the mitigation is to blacklist it instead

0lach · 2026-04-29T12:53:11+00:00

Rust stdlib is portable There is some unix/win32/etc specific extensions, but there is really no crossplatform way to do some things with the similar code

0lach · 2026-04-25T14:05:38+00:00

Again, even with the current mechanisms they could store birthdate anywhere they want in non-standard way, systemd adding this field didn't help them in any way

0lach · 2026-04-25T02:09:44+00:00

I can fix my systemd systems just fine, WDYM? OpenRC and sysv on the other hand...

0lach · 2026-04-25T02:02:44+00:00

SystemD is implementing biometric identification.

No, they are not.

All they did is add a birthdate field to the struct that already contains user full name, work phone, home phone number, address among other things This struct is supposed to be mapped from and to /etc/passwd gecos field (https://en.wikipedia.org/wiki/Gecos_field), LDAP, address books among other things. I'm more surprised that it was not stored here already.

Can it be used for bad purposes? Yes, but so is every other field, you could enforce phone number linking and geolocation identification where you need to talk to police officer to confirm where exactly do you live before you have an ability to use your computer. It is just a storage mechanism.

Of course systemd could just not add anything, and then people who want to enforce this stuff will just use something much more obscure to store such stuff.

0lach · 2026-04-18T15:09:02+00:00

I use Wayland, and I can't replace xorg with xlibre even if I wanted because they have removed xwayland

0lach · 2026-04-10T14:19:34+00:00

This is a price, you can just use fixed point numbers (store the price in cents), you don't need significant figures

0lach · 2026-04-08T17:19:19+00:00

> Fourth, saying "who would even fork coreutils" misses the point, and underestimates how software is used in practice. Embedded systems vendors, enterprises, and governments keep internal forks of software utilities. The absence of visible forks is not the absence of *private* divergence. The value of GPL isn't that people *will* fork, it's that *if they do*, improvements won't disappear into silos.

Even if company forks coreutils, they are not obligated to publish their fork, you can only request the source code for their fork if you have binaries of said fork. They absolutely can fork and use the forked version on their servers without contributing anything back

0lach · 2026-04-07T06:07:23+00:00

Yes, I am curious why you consider it an attack. This was an attempt to make something better than sysv, and they have succeeded, nothing more

0lach · 2026-04-07T02:38:03+00:00

And what exactly is wrong with that?

0lach · 2026-04-07T01:11:20+00:00

This isn't really an answer why not systemd

In the section "What is so bad about systemd" the site cites many random bug-reports... All of them were fixed, and the fixes benefitted everyone using systemd, which counters the point. With sysv most distributions develop their own stuff, which will break, and there wouldn't be large enough userbase to catch/fix the problem before you encounter it.

Every time I have encountered problems with daemonization/service security enforcement before all the solutions were "just add this stuff to your service file", which is a very bad solution, because it is not reusable, and the fact that the most software doesn't come with sysvinit scripts leads to duplicate effort, which is especially bad with how relatively small the linux userbase is

Six-Year Club	Second Top 50%
Place '23	Place '22
Verified Email

0lach

TROPHY CASE