mahkoh

Because foo might call process::abort().

You're a single parent. Through divine intervention you know that your 5 year old child has already pressed the red button. Are you going to press the blue button and risk your child becoming an orphan in a selfish and violent world? Or do you sacrifice the lives of billions to save your child from this inconvenience?

I doubt there is anything incorrect there. See the note here: https://wayland.freedesktop.org/docs/book/Message_XML.html#a...

WebGPU seems to be enabled by default in chromium 144 on linux at least on AMD GPUs.

The point of disabling overcommit, as per the article, is that all pages in virtual memory must be backed by physical memory at all times. Therefore all virtual memory must reserve physical memory at the time of the fork call, even if the contents of the pages only get copied when they are touched.

Back when I was writing xdg-desktop-portal-hyprland, I had to use a few dbus protocols (xdg portals run on dbus) to implement some of the communication. If we go to the portal documentation, we can find the protocols.

[...]

None of the apps, I repeat, fucking none followed the spec. [...]

Fun fact: THIS IS STILL THE CASE! The spec advertises a "restore_token" string prop on SelectSources and Start, where no app does this and uses "restore_data" in "options".

Wrong. xdg-desktop-portal has a client API and a compositor API. In the client API the property is called restore_token [1]. In the compositor API the property is called restore_data [2]. Clients do not talk directly to the compositor, they talk to the xdg-desktop-portal application which then talks to the compositor. It is not surprising the the properties would not be called the same.

In the documentation the APIs for app developers and desktop developers are clearly separated on the left hand side [3]. Not only does this have nothing to do with DBus (it would apply to every API where a middleware is used to translate messages), it also shows that the author did not do his due dilligence.

[1] https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr...

[2] https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr...

[3] https://flatpak.github.io/xdg-desktop-portal/docs/

VESA makes you pay $5000 to get legal access to the DisplayPort standard. That is not the issue here.

a can be a vector of booleans.

The author frames his post to be about education:

    please correct them for me. The misinformation has been around for 20 years

    So, if you ever see somebody proposing this

    float a = mix( b, c, step( y, x ) );

    float a = mix( b, c, y > x );

    The variants of mix where a is genBType select which vector each returned component comes from. For a component of a that is false, the corresponding component of x is returned. For a component of a that is true, the corresponding component of y is returned.

That assumes that Apple's shareholders believe that Apple's privacy reputation (relative to other companies) is more valuable than access to the UK market.

All evidence that I have seen suggests that consumers by and large do not care about this kind of privacy. They do not buy iPhones instead of other phones due to the privacy properties.

Therefore Apple's shareholders could order Apple to stay in the UK market.

And if not, then Apple's customers could be compensated with money and other UK-held assets that the government could confiscate.

The problem with asciidoc is that it doesn't support nesting. Markdown allows you to nest constructs as much as you want using syntax that are easy to use for both humans and documentation-generating applications.

The asciidoc developers don't seem to consider this an important issue: https://github.com/asciidoctor/asciidoctor/issues/1121

While asciidoc has some nice constructs, this made it a no go the last time I was looking for a documentation language.

Another one is I could not find a benchmark with io_uring - this would confirm the benefit of going from epoll.

One of the advantages of io_uring, unrelated to performance, is that it supports non-blocking operations on blocking file descriptors.

Using io_uring is the only method I recall to bypass https://gitlab.freedesktop.org/wayland/wayland/-/issues/296. This issue deals with having to operate on untrusted file descriptors where the blocking/non-blocking state of the file descriptions might be manipulated by an adversary at any time.

C-f thread

0/0

We shouldn't hope for the impossible.

I've had a few hard crashes (system freezes completely, ssh does not work) over the last two weeks on 6.10.x kernels. I am hoping that it is https://gitlab.freedesktop.org/drm/amd/-/issues/3142 (and not hardware failure) but I've been unable to capture the kernel panic if it does occur.

Never had such an issue before.

The in-memory representation of bit fields is implementation-defined. Therefore, if you’re calling into an external API that takes a uint32_t like in the example without an explicit remapping, you may or may not like the results.

In practice, everything you’re likely to come across will be little endian nowadays, and the ABI you’re using will most likely order your struct from top to bottom in memory, so they will look the same most of the time.

Unfortunately it is not that simple:

https://github.com/mahkoh/repr-c/blob/0c218ac5a6f82034e649fe...

0.2 and 0.4 are different "major releases" of rust crates as you say. The major release is determined by the first non-0 component in the version number. The issue is that debian appears to only allow one version even if there are multiple major versions.

If debian is fine with packaging versions 2.0 and 4.0 but not 0.2 and 0.4, then debian does not understand rust version numbers.

If control flow statements don't require parentheses to be parseable, doesn't that mean that it is the parentheses that are completely unnecessary?

Provenance might be used as justification now but the actual rules are simpler and stricter. After freeing (or reallocing) a pointer, the application must not inspect the pointer value anymore. Even `new_pointer == old_pointer` is not allowed.

IIRC, one justification for this was to account for systems with non-flat memory where inspecting the value of the old pointer might cause a processor exception.

IPv4 only.

You'd think that sites choosing wireguard would have a more modern setup and might make heavy use of (self service) ULAs.

The linked PoC requires that the attacker already has root so that it can disable the default ptrace protection.

Adding the following to your local systemd.network configuration file should resolve the issue:

  [DHCPv4]
  UseDNS=false
  
  [DHCPv6]
  UseDNS=false

Early linux versions as a git repository are available here: https://archive.org/details/git-history-of-linux

See https://www.swift.org/platform-support/ for a list of supported distributions.

You seem to have hallucinated that I said that swift cannot be made to run on other systems. You can even make windows-only games run on linux so that is not a surprise.

What distinguishes swift from gcc, clang, python, bash, go, rust, and so on is that languages other that swift aim to support linux in general.

Isn't it good that now there is an alternative to C?

Rust has had endorsed language bindings for GTK for a long time: https://www.gtk.org/docs/language-bindings/rust

Some official Gnome applications are written in Rust.

Swift only supports a small number of linux systems (Ubuntu, CentOS, Amazon Linux) which makes unsuitable for general linux application development.

If you don't know how to build a statically linked rust binary yourself, then why bother posting about the downsides of dynamic linking?

And obviously you can also link statically against musl on glibc systems. It's just another library.

No, that's just the font I'm using. It's the same if I keep the scale at 1 and then zoom in the browser.

It works in chromium without anything I'd call blur. Here it is at 175% scale: https://i.ibb.co/DtKm69d/image.png

That is not the case on wayland. Wayland applications with support for the fractional scaling protocol can render without any blur at any fractional scale.

This is because the protocol negotiates the size of the underlying buffer. If the client and the compositor agree on the scale, then no scaling of the buffer will happen in the compositor because the client has attached a buffer that is the exact pixel size size of the window on the physical display.

It is up to the client how it implements the case you described. E.g. it could alternate between 1 black and 1 white pixel in the physical buffer or it could sometimes make two adjacent pixels the same color.

Source: I was involved in the design of this protocol and we had example clients that used this exact pattern. Chromium also supports this protocol without any blur.

The component model seems like it's just a re-invention of JBoss-like application servers.

Maybe it is explained somewhere in the paper but how do atomic updates work if at least one of the components has to be a singleton that does not support rolling upgrades?