HN user

mrcarrot

209 karma
Posts1
Comments79
View on HN

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.

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.

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?

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 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 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.

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.

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