mrcarrot

Yeah, you definitely don't want to hang things off the wrong seams, or you'll end up with quite the blast radius

I've started using Linux recently after not touching a desktop distro for 20-odd years, and I was surprised how good both Gnome and KDE look these days.

It certainly doesn't feel like there's a trillion-dollar-company difference between those two and Tahoe.

It's available on Prime Video (at least on amazon.de). For a long while they would only sell access to season 1, but I've just checked now and all 4 seasons are available at the moment.

In a similar space, I'm pretty sure the recent remake & remaster of the two System Shock games were really well received, so that's hardly a given.

Yeah, I've been trying it recently and I'm not entirely convinced I want to keep using it.

My biggest annoyance at the moment (and this may be me missing something), is that I have two directories: "thing" and "thing-api". I'm doing work in "thing" much more often than in the "thing-api", but whenever I run "z thing", it takes me to "thing-api" first, and I have to "z thing" again to get to where I wanted to go. It ends up being more effort than if I'd just tab-completed or history searched a plain cd command.

yes

Thanks - this does make sense in isolation.

I think my actual issue is that the "most package managers do something like this" example code snippet at the start of [1] doesn't seem to quite make sense - or doesn't match what I guess would actually happen in the decompress-in-a-loop scenario?

As in, it appears to illustrate building up a buffer holding the compressed data that's being received (since the "// ... decompress from buffer ..." comment at the end suggests what we're receiving in `chunk` is compressed), but I guess the problem with the decompress-as-the-data-arrives approach in reality is having to re-allocate the buffer for the decompressed data?

[1] https://bun.com/blog/behind-the-scenes-of-bun-install#optimi...

The "Optimized Tarball Extraction" confuses me a bit. It begins by illustrating how other package managers have to repeatedly copy the received, compressed data into larger and larger buffers (not mentioning anything about the buffer where the decompressed data goes), and then says that:

> Bun takes a different approach by buffering the entire tarball before decompressing.

But seems to sidestep _how_ it does this any differently than the "bad" snippet the section opened with (presumably it checks the Content-Length header when it's fetching the tarball or something, and can assume the size it gets from there is correct). All it says about this is:

> Once Bun has the complete tarball in memory it can read the last 4 bytes of the gzip format.

Then it explains how it can pre-allocate a buffer for the decompressed data, but we never saw how this buffer allocation happens in the "bad" example!

> These bytes are special since store the uncompressed size of the file! Instead of having to guess how large the uncompressed file will be, Bun can pre-allocate memory to eliminate buffer resizing entirely

Presumably the saving is in the slow package managers having to expand _both_ of the buffers involved, while bun preallocates at least one of them?

Also not available in Austria

Or alternatively (assuming that's true) he fired the people who thought about what they commit and kept those whose commit logs look like: "push feature WiP", "fix", "more fixes", "push", "maybe this works?"...

> The POST in the README is going to send the params in the request body "url form encoded" like a form in a web page.

Is there a different POST request in the readme or are you saying that this example is going to send the "user" and "password" params in the request body?

> POST https://example.org/login?user=toto&password=1234

That seems really surprising to me - how would you then send a POST request that includes query string parameters? The documentation on form parameters [1] suggests there's an explicit syntax for sending form-encoded request parameters

[1]: https://hurl.dev/docs/request.html#form-parameters

I really enjoyed watching Jon Gjengset work through this here: https://www.youtube.com/watch?v=u0VotuGzD_w

I think the parent was agreeing with you. If the “local” SSDs _weren’t_ actually local, then presumably they wouldn’t need to be ephemeral since they could be connected over the network to whichever host your instance was launched on.

“And management’s priority for Q4 is feature Y, so we’re just going to leave feature X like it is for now”

None of those places are especially sunny in the winter though!

> And what if I don't want to have my constructor parameters as properties, maybe because I process them somehow in the constructor, and set some other properties instead?

Then you don't use property promotion. It's optional: it only happens if you add a visibility modifier before the parameter name.

Only if you're using a US keyboard layout.

Not since PHP 7.3![1] If you indent the closing identifier, then the corresponding indentation will be removed from the content of the heredoc string.

[1]: https://www.php.net/manual/en/language.types.string.php#lang...

Also not on iPad, but they do load, on a stand-alone page, if you click on them.

You could just sign up for a month of Game Pass and get the game for 1 £/€/$.

Also the default controller profiles don’t include any dead zone, so at least on my setup, the control inputs were way too sensitive. Once I added some dead zone, and reduced the sensitivity curve in the options, it became much less twitchy.

Valve have said they will (somehow) not count the time taken to download the game content against the 2 hour refund clock [1].

[1]: https://www.gamesindustry.biz/articles/2020-08-20-valve-assu...

I have "Search Engine Suggestions" and "Safari Suggestions" both enabled, Google as "Search Engine" and I see the same behaviour as you (typing "sketch" RETURN in safari address bar takes me to the Google search results).

Yeah, 400000 deaths over 4 months would be in the ballpark of the casualties from an Omaha Beach landing every day.

A postcode (or local equivalent) isn't necessarily particularly specific. For example, here in Austria the equivalent of a postcode might cover a whole city district.

Everything apart from the initial reset command in that ‘recipe’ is stuff that a command line git user would be doing all the time anyway. There’s not really anything to remember here, other than that ‘git reset’ lets me undo commits that I haven’t pushed.

This table might help explain:

          00  01  10  11
  00000   NUL Spc @   `
  00001   SOH !   A   a
  00010   STX "   B   b
  00011   ETX #   C   c
  00100   EOT $   D   d
  00101   ENQ %   E   e
  00110   ACK &   F   f
  00111   BEL '   G   g
  01000   BS  (   H   h
  01001   TAB )   I   i
  01010   LF  *   J   j
  01011   VT  +   K   k
  01100   FF  ,   L   l
  01101   CR  -   M   m
  01110   SO  .   N   n
  01111   SI  /   O   o
  10000   DLE 0   P   p
  10001   DC1 1   Q   q
  10010   DC2 2   R   r
  10011   DC3 3   S   s
  10100   DC4 4   T   t
  10101   NAK 5   U   u
  10110   SYN 6   V   v
  10111   ETB 7   W   w
  11000   CAN 8   X   x
  11001   EM  9   Y   y
  11010   SUB :   Z   z
  11011   ESC ;   [   {
  11100   FS  <   \   |
  11101   GS  =   ]   }
  11110   RS  >   ^   ~
  11111   US  ?   _   DEL

Not if you're British :)