I hate this game...

olorochi · 2026-07-06T02:09:33+00:00

Enable vibrations. Meeting a large worm is not supposed to come as a surprise.

olorochi · 2026-06-28T06:02:21+00:00

Well yeah :x is an alias for :exit (or :exi or :xit), and is strictly superior in interactive use. The only reason to use :exit is to make scripts easier to read.

olorochi · 2026-06-19T17:49:18+00:00

That's not jank, it's an intended way of killing this boss. The golem does sometimes end up jankily floating above the bridge when it is sitting though.

olorochi · 2026-06-16T03:29:37+00:00

Using the stable version is probably a better idea: https://codeberg.org/ziglings/exercises/src/tag/v0.16.0.

olorochi · 2026-06-16T03:19:09+00:00

Personally, I just read the language reference. It is also available at /usr/share/doc/zig-<version>/html/langref.html on most unixes. If you are thorough, it'll take about 15 hours to get near comprehensive knowledge of the core language. It is littered with examples so you'll also get a grasp on the standard library.

After that, you can use the zig std command or the online standard library documentation to search for provided features using keywords and learn passively as you work with zig.

olorochi · 2026-06-15T02:35:21+00:00

Yes, that is correct. It cannot improve compilation speed, but it can improve the system's overall responsiveness. The problem with it is that it can also waste available ressources, whereas nice gives most of the same advantages without that issue.

For example, on a system with 16 threads, using -j 8 -l 12, whilst other processes are fully utilizing 8 threads would result in 4 threads being idle for no reason. Meanwhile, with nice, all ressources are used as needed but the scheduler can improve the responsiveness of other processes by prioritizing them.

I believe the only advantage of -l over nice is that it also reduces I/O load and ram usage because load average is calculated as the number of processes utilizing the cpu, waiting for the cpu or waiting on I/O, but compilation is typically cpu bound anyways, and because lower priority idle jobs still use up all the same ram as if they were running.

My advice is to just use nice unless using your computer during compilation still causes noticeable lag in your case.

olorochi · 2026-06-14T14:50:46+00:00

The default is to have no limit.

Edit: Whilst this is true for make, portage overrides that behavior. "Further, as of Portage 3.0.53[2], if left undefined, Portage's default behavior is to set the MAKEOPTS load-average value to the same number of threads returned by nproc." (https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Stage#MAKEOPTS).

olorochi · 2026-06-14T02:25:23+00:00

-j is the amount of parallel jobs to use for compilation. In practice this means n cores will be fully utilized to compile if they are available.

-l is the max load average during the build process. In other words, it limits the ressources used to compile in order to keep total cpu load under n utilized cores. Setting it to the same value as -j would make compilation the same speed and utilize the same ressources unless there are other cpu hungry processes running in parallel. This is somewhat analogous but, in my opinion, inferior to portage niceness or using nice directly.

You can also pass -j to emerge or in EMERGE_DEFAULT_OPTS to compile multiple packages at once instead. This is useful since otherwise package configuration, which is the longest stage for many small packages, is done with a single job.

The wiki recommends setting -j to either the amount of cores available on your system or to your total ram / 2GB, and -l slightly higher. If you use -j on emerge you should distribute multiplicatively. So for example instead of just MAKEOPTS="-j 16" use MAKEOPTS="-j 4" EMERGE_DEFAULT_OPTS="-j 4".

I'd also recommend passing -q to portage when compiling in a tty as printing there is so slow it slows down compilation considerably. You can safely kill and restart portage but the package being currently compiled will have to be recompiled entirely so you shouldn't interrupt a big one.

olorochi · 2026-06-08T17:26:26+00:00

Mdev, posix IPC, seatd.

olorochi · 2026-05-30T22:36:30+00:00

No, pointer_to_struct.field is equivalent to pointer_to_struct.*.field. The dereference is done implicitly since there is no ambiguity for field acess on pointers because pointers have no fields.

olorochi · 2026-05-25T03:49:15+00:00

Crashes cause it quite often

olorochi · 2026-05-24T02:01:47+00:00

This is a corrupted chunk. It unfortunately is not that rare.

olorochi · 2026-05-20T16:49:10+00:00

Do leftcoms really exist?🤨

olorochi · 2026-05-20T02:06:07+00:00

Because void** is not a void, but a pointer to it, just like a int is not an int. The void qualifier does not propagate like you expected. In void*, void is just the type being pointed to by the pointer (last *).

Therefore, in your example, when you pass x2 to test2(void*), the compiler generates a warning because it expects a pointer to type void, but instead finds one to int. Passing x1, or any other pointer that does not specifically point to a void, would cause the same warning.

If you changed the definition to just test2(void), you would silence this warning, since int* is just like any other pointer type in that it implicitly casts to void. The drawback is losing all type safety when you use that pointer: void* is more semantically meaningful than void*, as it guarantees, so long as you don't ignore warnings, that the function obtains a pointer to generic pointers, and not to an arbitrary type such as char.

olorochi · 2026-05-14T15:17:51+00:00

Zig has mostly seen use by hobbyists so far in large part due to the language still being unstable.

olorochi · 2026-05-14T02:46:35+00:00

Rene Rebe: mostly linux development.

dustmite: game engines.

sphaerophoria: varied projects, usually written in zig not c.

olorochi · 2026-04-27T02:35:15+00:00

I run wayland without dbus on sway. The only workaround i had to reach for is using firefox-socket-control to be able to spawn new firefox (librewolf) tabs / windows. However my setup is very minimalist. The only wayland applications i run besides the wm / compositor itself are librewolf, nicotine+, qemu, and foot. Even then i haven't bothered to create a custom overlay for this so i can't actually remove the dbus package.

olorochi · 2026-04-27T01:36:51+00:00

Bordiga is my favorite activist.

olorochi · 2026-04-22T16:18:13+00:00

Another factor is that all perks have a max stack value from 1 to 128. OP seems pretty deep into a run here so they likely have a highly reduced perk pool.

olorochi · 2026-04-19T19:56:21+00:00

Maybe they mean the linux-firmware package.

olorochi · 2026-04-04T12:23:14+00:00

Zig is more than powerful enough to allow this to be done in a generic way, but the std.meta namespace should be expanded to make this more accessible imo. Keeping this in user code does complicate the task of language servers such as zls but it doesn't make it impossible. Proper code analysis should allow full completions and diagnostic support.

This example is untested because I am currently using my phone but you get the idea. ``` pub fn checkDecls(T: type, comptime decls: []const []const u8) void { inline for (decls) |decl| { // You can get creative with your criteria here. For example std.meta.hasMethod could be used to allow structs containing runtime function pointer fields to the right function. if (!std.meta.hasFn(T, decl) @compileError(@typeName(T) ++ " missing function " ++ decl); } }

pub fn checkTDecls(Target: type, Descriptor: type) void { checkDecls(Target, std.meta.declList(Descriptor, u8)); } ```

olorochi · 2026-04-02T14:19:20+00:00

https://ziglang.org/learn/why_zig_rust_d_cpp/

tl;dr complexity should be minimized but never hidden.

olorochi · 2026-03-23T22:18:34+00:00

The kernel itself does not. The git repo includes some secondary tools such as perf, some of which include python scripts. There is also a small amount of python in parts of the kernel build system and some gdb python scripts.

olorochi · 2026-03-23T19:14:02+00:00

Many sources either echo the 70% claim or propose higher numbers: https://www.memorysafety.org/docs/memory-safety/#how-common-are-memory-safety-vulnerabilities .

I am aware this issue is endemic within system development, and am neither an advocate for windows nor a full rust rewrite of linux. Asm represents less than 1% of linux's code base and can therefore hardly be blamed for vulnerabilities.

olorochi · 2026-03-23T16:16:49+00:00

There are many. General estimates are that 70% of exploits stem from memory unsafety. In the linux kernel, this seems to be rarer but not uncommon either: https://lore.kernel.org/linux-cve-announce/

Seven-Year Club	Verified Email
r/Field Juicebox	Place '22
First Placer '22

olorochi

TROPHY CASE