hvenev

(2023) judging by https://skysedge.com/telecom/RUSP/electrical.html

This blog post calls libgit2 "git's C library" as if it is in any way related to git. I don't think it is.

> In the meanwhile in raspberry pi land, you can just go to download a reasonably new OS image from their website anytime you want and it will run on all their models.

Are you saying that even with the Raspberry Pi we are still at the mercy of the hardware manufacturer when it comes to OS images?

I personally call this process of setting up a new device, whether for me or for someone else, "shit shoveling". It is something of a ritual.

In the former case the thing that needs to be removed is the entirety of the OS (and if that proves to be impossible, the device is returned or discarded), and in the latter it's a scan of all apps and removal of all unnecessary apps, my grandma does not need Samsung Galaxy Games, thank you very much.

Will you not have `~/.ssh`? If you have `.ssh .config/ssh` as a rewrite rule, `stat ~/.ssh` will still find it.

For IPv4 the graph does not start at zero, but at around 45K.

> Jeff once simultaneously reduced all binary sizes by 3% and raised the severity of a previously known low-priority Python bug to critical-priority in a single change that contained no Python code.

This sounds really plausible. A change to the C toolchain/library (for example, specialized/inlined memcpy) may affect binary sizes significantly, and may change the behavior of something the C standard leaves undefined (for example, memcpy with overlapping arguments).

Don't they already sell servers? https://www.nvidia.com/en-us/data-center/dgx-platform/

Back when my job involved using Kubernetes and Helm, the solution I found was to use `| toJson` instead: it generates one line that happens to be valid YAML as well.

From what I remember, the quality of a safe is measured in minutes, with "15-minute" safes being OK for general use.

English also changes, so the only way to be safe is to quote all identifiers.

What I personally do is

    User=per-service-user
    ExecStart=!podman-wrapper ...

where podman-wrapper passes `--user=1000:1000 --userns=auto:uidmapping=1000:$SERVICE_UID:1,gidmapping=1000:$SERVICE_GID:1` (where the UID/GID are set based on the $USER environment variable). Each container runs as 1000:1000 inside the container, which is mapped to the correct user on the host.

Our GCP VMs are also not responding (europe-west4-a and us-central1-b).

edit: Seems to be a network problem. We can't connect to them from Bulgaria, but we can connect to them from the US.

I wonder when quantum computers will be able to target post-quantum RSA [1]. Normal RSA operations (key generation, encryption, decryption) have an asymptotic advantage over Shor's algorithm, so it is not unreasonable to just use large enough keys. The advantage is similar to Merkle's puzzles [2], with the added bonus that the attacker also needs to run their attack on a quantum computer.

A while ago I generated a gigabit RSA public key. It is available at [3]. From what I remember, the format is: 4-byte little-endian key size in bytes, then little-endian key, then little-endian inverse of key mod 256**bytes. The public exponent is 3.

[1] https://eprint.iacr.org/2017/351.pdf

[2] https://dl.acm.org/doi/pdf/10.1145/359460.359473

[3] https://hristo.venev.name/pqrsa.pub

I'm struggling to understand how this has anything to do with borrow checking. Borrow checking is a way to reason about aliasing, which doesn't seem to be a concern here.

This post is about memory management and doesn't seem to be concerned much about safety in any way. In C3, does anything prevent me from doing this:

  fn int* example(int input)
  {
      @pool()
      {
          int* temp_variable = mem::tnew(int);
          *temp_variable = input;
          return temp_variable;
      };
  }

In `libnvidia-nvvm.so` the string `cutlass` appears right after `Memory Dependence Analysis` and `memdep`. Perhaps it acts as an optimization attribute of some sort, where the compiler is allowed to make assumptions about the kernel's behavior that are not valid in general?

> can be implemented in terms of `openat` + `fgetxattr`

Except for symlinks. `fgetxattr` requires a file opened for read or write, but symlinks can only be opened as `O_PATH`.

Sadly the inclination of the orbit prevents it from falling that far north.

I think git is quite nice and easy to work with once you realize one thing: git is first and foremost a filesystem. Version control is built on top.

For local communication Microsoft Visual Studio Code often uses TCP sockets (bound to localhost) even though UNIX sockets are available. What's more, old versions used to pass the authentication token as a command-line argument, exposing it to all users on the system.

I wonder how many other security disasters it contains that nobody has discovered yet.

Despite the sad context, this seems refreshing -- an alert is raised due to a real and serious concern.

I don't know, to me it just seems like a plausible interpretation:

- In GitHub, forks of public repositories are themselves public repositories.

- GitHub repositories can be cloned, which is a form of distribution.

- Therefore any fork that implements, for example, a change to the programming language itself, but still uses the name "Rust", is distributing a modified version of the programming language in a manner that is not allowed.

I sincerely hope that this is not the interpretation taken by the Rust Foundation, but I cannot know for sure. It seems very open to selective enforcement.

The part of the policy about distributing modified versions of the Rust compiler seems interesting:

> Publicly distributing a modified version of the Rust programming language, compiler, or the Cargo package manager, provided that the modifications are limited to:

> - code adjustments for the purpose of porting to a different platform, architecture, or system, or integrating the software with the packaging system of that platform

It looks like distributing a modified version with any change that isn't related to compatibility with a different platform/architecture/system is not allowed. This would probably make almost all GitHub forks of Rust non-compliant.

The demo appears too stateful for me. The real power of `jq` is its reliability and the ability to reason about its behavior, which stateful tools inherently lack.

> an obscure instruction

Come on, vpternlog* is not obscure. It subsumes _all_ bitwise instructions, even loading the constant (-1) into a register.

I've been running Hyprland for a while now. I find its window management capabilities quite good, in particular, the default 1 LHS / n RHS setting -- I lack the desire to deal with binary trees; the window manager should manage the windows, not me.

That being said, I am a W^X person so I don't really like some of the (x86_64-specific) aspects of their plugin systems. I need to publish my #ifdef-it-out-with-fire patch at some point...

Is 26 characters next? I think the number of bytestrings of length <= 26 that are also valid UTF-8 is only 0.021 * 256^24.

Yes, my original wording was "to make the CVE system burn", but that got lost during my tone-down edits.

(2024).

Assigning a CVE to every second commit and refusing to assign CVEs to unfixed issues doesn't seem like correct usage of the CVE system. I expect that most Linux CVEs will never get a proper analysis or a CVSS rating.

To me it sounds plausible that the design goal of the Linux CNA is to show that CVEs don't meaningfully apply to the Linux kernel. Given how dependent on context the impact of some kernel bugs can be, if we were assigning CVSS scores for the worst case, practically all kernel bugs would be at least a 9.8/10.

Perhaps they've decided to draw inspiration from https://bugzilla.mozilla.org/show_bug.cgi?id=647959.