database64128

Interestingly this is exactly why I have to mess with brightness settings from time to time.

Has anyone else noticed the weird interaction between apps turning the brightness to the max and the system’s auto brightness? I’m not an iOS developer, so I don’t know about the relevant APIs. But every time an app changes the brightness to display a QR code, it seems to do so by retrieving the current brightness, turning it to the max, and when it’s done, setting it back to the old value. The problem is that iOS seems to register the brightness change as user initiated, and changes auto brightness behavior. After a few uses, auto brightness will no longer adjust the display to the minimum brightness, even when you’re in complete darkness.

Fixing this used to be easy. Just go to display settings and toggle auto brightness off and on. Then Apple decided to move the toggle under accessibility. Now it’s Accessibility -> Display & Text Size and scroll all the way to the bottom.

I'm new to Ubiquiti routers, but I had no problem dividing the /60 I got from my ISP and assign /64s to VLANs.

You might be interested in https://www.youtube.com/watch?v=KZpJvpm1Ris (title: Does UniFi FINALLY support IPv6 Properly? State of IPv6 with Unifi Network v9). The video is about a year old, but from the looks it's not terribly outdated.

No, having the bare minimum "HDR support" does not mean it works fine. I have a 27-inch 4K 144Hz monitor with P3 wide color gamut and HDR600. This monitor is connected to 2 PCs, one running Arch Linux with GNOME as the DE and one with Windows 11.

Since Windows 11 24H2, with the new color management feature turned on, I can get correct colors on the monitor in both SDR and HDR modes. So it ends up with HDR on at all times, and mpv can play HDR videos with no color or brightness issues.

GNOME, on the other hand, is stuck with sRGB output in SDR mode, so you get oversaturated colors. With HDR on, SDR content will no longer be oversaturated, but if you play HDR videos with mpv, the image looks darkened and wrong. I've tried setting target-peak and target-contrast to match the auto-detected values on Windows, but the video still looks off.

I don't think so. I'm on GNOME 49 and nothing has changed compared to 48.

> Every time I login using a Wayland desktop, only my main monitor is detected and it defaults to 60hz. I have to go through a whole process of unplugging the "undetected" monitors and plugging them back in.

Are you using GNOME? mutter has this problem where it does not retry commit on the next CRTC: https://gitlab.gnome.org/GNOME/mutter/-/issues/3833. If this is actually what's happening on your system, switching to KDE should solve it.

> HDR on Wayland is barely functional (in my experience)

This also sounds specific to GNOME, as mutter still doesn't have color management. You'll get a better HDR experience with KDE.

Have you actually contributed to the Go standard library?

Yes, there are people who don't work for Google and can +2 on changes, but you still need 2 Google employees to at least +1 on your change before it can be submitted. This is mentioned in the Contribution Guide [0] and is enforced by Gerrit.

> Finally, to be submitted, a change must have the involvement of two Google employees, either as the uploader of the change or as a reviewer voting at least Code-Review +1. This requirement is for compliance and supply chain security reasons.

[0] https://go.dev/doc/contribute

Yes. To land a change in the Go standard library, you'll need 2 Google employees to approve your change on their "trusted devices".

I see you use a hard-coded constant ALIGN = 512. Many NVMe drives actually allow you to raise the logical block size to 4096 by re-formatting (nvme-format(1)) the drive.

You could use something like https://github.com/database64128/swgp-go to obfuscate WireGuard traffic.

Using full-blown VPNs under such environments has the disadvantage of affecting your use of domestic web services. You might want to try something like https://github.com/database64128/shadowsocks-go, which allows you to route traffic based on domain and IP geolocation rules.

> One problem with Go is the lack of fine-grained control over allocation. In particular, no arena allocation support. How does C# compare?

Go has an experimental arena package [0], but the proposal is on hold and the code may be removed in the future.

C# does not support arenas. But it does provide the stackalloc keyword, whereas in Go you kind of need the compiler's blessing for avoiding heap allocations.

> Another problem is relatively high cost of FFI interop with C. It's gotten better, but Go still needs to switch stacks, etc. How is C#?

Async in C# is implemented as stackless coroutines. Calling into FFI is cheap.

> How does C# compilation speed compare?

In my experience, release builds are a bit slower than Go.

> Does the compiler optimize more aggressively than Go (which does very little optimization)? I've heard the C# AOT compiler is lacking, but it's not clear in what way.

Not much to say on this, but with each new .NET release, a core .NET team member posts a blog post about performance improvements in the new release. The most recent one: https://devblogs.microsoft.com/dotnet/performance-improvemen...

> Does C# have the equivalent of "go run"?

  dotnet run

> What's the package management situation like?

NuGet Gallery [1] is like a centralized DLL registry. Definitely not as good as Go.

> Can you use LINQ against databases like Postgres on Linux, without having to buy into a lot of Microsoft/.NET stuff?

Probably not. This is usually done with EF Core and the Postgres provider.

[0] https://github.com/golang/go/issues/51317

[1] https://www.nuget.org/

Shameless plug: I wrote a DDNS service in Go [0] that uses Netlink on Linux and the IP Helper API on Windows to monitor network interface addresses in the most efficient way possible. As a result of working on this project, I sent 3 separate CLs to the x/sys module.

[0] https://github.com/database64128/ddns-go

[1] https://go-review.googlesource.com/c/sys/+/597915

[2] https://go-review.googlesource.com/c/sys/+/598895

[3] https://go-review.googlesource.com/c/sys/+/603755

Raising the soft limit to the hard limit is also recommended by the author of systemd: https://0pointer.net/blog/file-descriptor-limits.html

I doubt the kernel would actually allocate the resource space upfront. Like SO_SNDBUF and SO_RCVBUF, it's probably only allocated when it's actually needed.

> In fact it’s quite common to “commit” on close, at least from what I’ve seen.

close(2) does not "commit". You have to call v.Sync() (i.e. fsync(2)) for that.

From man 2 close:

       A successful close does not guarantee that the data has been successfully saved to disk, as the kernel uses the buffer cache  to  defer  writes.   Typi‐
       cally,  filesystems  do  not flush buffers when a file is closed.  If you need to be sure that the data is physically stored on the underlying disk, use
       fsync(2).  (It will depend on the disk hardware at this point.)

This is one of the many things where Go just takes care of automatically. Since Go 1.19, if you import the os package, on startup, the open file soft limit will be raised to the hard limit: https://github.com/golang/go/commit/8427429c592588af8c49522c...

Just write `defer v.Close()`? In almost all cases, `close(2)` errors can be safely ignored. Rust also does this: https://github.com/rust-lang/rust/blob/792fc2b033aea7ea7b766...

Disable Windows Defender on your main rig and try again?

I just finished adding UDP GRO & GSO support to my WireGuard proxy software. The work involved rewriting a large part of the program.

https://github.com/database64128/swgp-go

For those who don't know, UDP Generic Receive Offload and Generic Segmentation Offload allow you to receive and send multiple same-sized UDP packets coalesced in a single buffer (or many in an iovec but you really shouldn't). Compared to calling sendmsg(2) on individual packets, sending them coalesced in one call traverses the kernel network stack exactly once, thus has significantly lower overhead.

wireguard-go and many QUIC implementations use the same trick to improve throughput. Unfortunately the in-kernel WireGuard driver does not take advantage of UDP GSO, and swgp-go had to cope with that by attempting to coalesce multiple unsegmented messages received in a single recvmmsg(2) call.

I wrote a silly Telegram bot for my group chats: https://github.com/database64128/CubicBot

It's mostly just some useless commands that say stupid things, and stats collection for earning "achievements" and displaying leaderboards.

The bot was written in C# and seriously over-engineered to be completely modular. Every command and stats collector can be turned on or off in config. A running instance with all features turned on is available as https://t.me/Cubic0Bot.