Must be because Factorio released 2.0 and the Space Age DLC recently.

HTTP/1.1 403 UNAUTHORIZED
{
  "error": {
    "status": "UNAUTHORIZED",
    "message": "Unauthorized access",
  },
}

I would separate the status from the HTTP status.

1. The HTTP status is great for reasonable default behaviours from clients.
2. The application status can be used for adding more specific errors. (Is the access token expired, is your account blocked, is your organization blocked)

Even if you don’t need the status now, it is nice to have it if you want to add it in the future.

You can use a string or an integer as the status code, string is probably a bit more convenient for easy readability.

The message should be something that could be sent directly to the user, but mostly helpful to developers.

No negative sign on the keyboard. But you can enter 2147483647

Do you mean using PDF’s built-in signature mechanisms? I don’t think so.

If you want to do regular PGP file signing you can export the key from Thunderbird and do whatever you want with it.

a predefined set of files

…with predefined sizes located in predefined regions of storage.

I mean it isn’t even just a squiggly line, the code fails to compile. Like come on, I will clean up my unused imports and variables before sending it for review, but just let me develop in peace.

I use NixOS for this. It works wonderfully.

Immutable means different things to different people, but to me:

1. Different programs don’t conflict with each other.
2. My entire server config is stored in a versioned Git repo.
3. I can rollback OS updates trivially and pick which base OS version I want to use.

…to Lemmy.

Linters and minifers are completely different tools.

I’ve written these cycle-perfect sleep loops before.

It gets really complicated if you want to account for time spent in interrupt handlers.

Wut? This is an automated optimizer. It is not worried about accidental assignment.

I just tested and Terser will convert v === null || v === undefined to null==v. Personally I would prefer to read the code that explicitly shows that it is checking for both and let my minifier/optimizer worry about generating compact code.

JS’s == has some gotchas and you almost never want to use it. So === is what == should have been.

All examples are true:

"1" == true
[1, 2] == "1,2" 
" " == false
null == undefined 

It isn’t that insane. But some invariants that you may expect don’t hold.

"" == 0
"0" == 0
"" != "0" 

Well it does say n >= 150. But the phrasing makes it sound like it is trying to imply that this is a small number.

Car dealerships are finally useful!

Async Rust is objectively bad language feature

That is all I need to read to know that this isn’t a well-reasoned complaint.

async Rust definitely isn’t perfect, and there is definitely room for critique. But it is very clearly not objectively bad.

It may still be nice to have a reference implementation. For example maybe they can see if there are extra hardening options that they can enable or adopt the more seamless update flow.

I think that’s generally the point of a rewrite. To start from scratch with a better architecture. If you weren’t changing the architecture then you can probably just keep incrementally improving it.

Back in the day X was a great protocol that reflected the needs of the time.

1. Applications asked it to draw some lines and text.
2. It sent input events to applications.

People also wanted to customize how their windows were laid out more flexibly. So the window manager appeared. This would move all of your windows around for you and provide some global shortcuts for things.

Then graphics got more complicated. All of a sudden the simple drawing primitives of X weren’t sufficient. Other than lines, text and rectangles applications wanted gradients, rounded corners and to display rich graphics. So now instead of using all of these fancy drawing APIs they were just uploading big bitmaps to the X server. At this point 1/3 of what the X server was previously doing became obsolete.

Next people wanted fancy effects and transparency (like drop shadows). So window managers started compositing the display. This is great but now they need more control than just moving windows around on the display in case they are warped, rendered somewhere slightly differently or on a different workspace. So now all input events go first from X to the window manager, then back to X, then to the application. Also output needs to be processed by the window manager, so it is sent from the client to X, then to the window manager, then the composited output is sent to X. So another 1/3 of what X was doing became obsolete.

So now what is the X server doing:

1. Outputting the composited image to the display.
2. Receiving input from input devices.
3. Shuffling messages and graphics between the window manager and applications.

It turns out that 1 and 2 have got vastly simpler over the years, and can now basically be solved by a few libraries. 3 is just overhead (especially if you are trying to use X over a network because input and output need to make multiple round-trips each).

So 1 and 2 turned into libraries and 3 was just removed. Basically this made the X server disappear. Now the window manager just directly read input and displayed output usually using some common libraries.

Now removing the X server is a breaking change, so it was a great time to rethink a lot of decisions. Some of the highlights are:

1. Accessing other applications information (output and input capture) requires explicit permission. This is a key piece to sandboxing applications.
2. Organize the system around frames to avoid tearing except for when desired (X doesn’t really have the concept of a frame).
3. Remove lots of basically unused APIs like fonts, drawing and many others.

So the future is great. Simpler, faster, more secure and more extensible. However getting there takes time.

This was also slowed down by some people trying to resist some features that X had (such as applications being able to position themselves). And with a few examples like that it can be impossible to make a nice port of an application to Wayland. However over time these features are being added and these days most applications have good Wayland support.

Also window managers started compositing which moved 1/3 of what X was doing to the window manager. Then applications started doing their own rendering which moved another 1/3 of what X was doing to the applications. All that is left over is basically the low-level IO which had gotten greatly simpler over the years and could basically be packaged into a few libraries (mesa and libinput primarily) and some complex mutli-hop IPC which was completely unnecessary.