Live data from Hacker News

Viewing profile — knz42

knz42

HN member
Joined
Sun, Nov 18, 2012, 2:29 PM UTC
HN karma
966
Public activity
231 items

About knz42

No profile information was provided.

Recent public activity

  1. comment
    Comment #48395639

    What do you think of the minimal phone? https://minimalcompany.com/

  2. comment
    Comment #47891959

    A guide for newcomers to software engineering, and for anyone curious about how LLMs are changing it. Built from interviews with senior professionals from the tech industry.

  3. story
  4. story
    Show HN: Building Community Maps

    Another story of using AI assistance and resulting in a finished software product.

  5. story
  6. comment
    Comment #45898770

    MLS (Message Layer Security) is the IETF standard (RFC 9420) derived from the Signal and Whatsapp end-to-end encryption protocols, with improvements.

  7. story
  8. comment
    Comment #43152272

    Whoosh OP was parodying JD Vance 's comments from last week.

  9. comment
    Comment #30114363

    This is a known bug in st when the default emoji font contains color emojis. Explained here: https://github.com/LukeSmithxyz/voidrice/issues/284 One of the simplest workarounds is …

  10. comment
    Comment #29417452

    Have you thought about simple iframes? For example: https://random.vodka-pomme.net/

  11. comment
    Comment #27847102

    Is there a way to simulate capital tax? Percentage of taxable investments/cash?

  12. comment
    Comment #27752476

    A lot of the complexity comes from the lack of expressivity in languages to relate variables (or data structure fields) semantically to each other. If there was a way to tell the c…

  13. comment
    Comment #27475418

    This is a hit piece. None of the angle taken there is specific to Telegram, it could be applied equally to e-mail.

  14. comment
    Comment #27445922

    The article says that BI doesn't affect employment % as if it is a bad thing. The fact that it did not decrease employment either is a wonderful thing, and should be celebrated. It…

  15. comment
    Comment #27398312

    This is the approach proposed in http://doi.org/10.1109/TPDS.2015.2492542 (preprint: https://science.raphael.poss.name/pub/poss.15.tpds.pdf )

  16. comment
    Comment #26870876

    Have you tried hosted CockroachDB, aka CockroachCloud?

  17. comment
    Comment #26841935

    > The title of the article ("My Go executable files are still getting larger") appears to be literally untrue, at least read as a critique of Go itself. If they are getting larger,…

  18. comment
    Comment #26838038

    The use case where said binary is shipped to GCE instances hundreds/thousands times per day, for stress testing and unit testing of cockroachdb.

  19. comment
    Comment #26837430

    > You said that " the article made the claim that 70% of space is wasted dark bytes" was "incorrect" with no further details I wrote this because there was no mention of "waste" an…

  20. comment
    Comment #26836969

    > a claim which is still in the article linked here. I am now supposed to argue against some revised article published elsewhere? The article linked in this thread is a syndicated …

  21. comment
    Comment #26836802

    > all that matters is the total size of binary! How bytes are organized internally is irrelevant to this metric. Not quite so if the task is to work on reducing the metric. When th…

  22. comment
    Comment #26836750

    For being somewhat familiar with the CockroachDB project, I doubt that that claimed performance difference is linked to the programming language. It's more something about mandator…

  23. comment
    Comment #26836704

    > That's not what it says [...] That claim was retracted a while ago already on the original version; the syndicated copy on the crl web site will be updated at some point.

  24. comment
    Comment #26836682

    Thanks Russ for that additional insight. > I would hope that anyone sensitive to networking costs at this level would be shipping around stripped binaries, so the growth in accurat…

  25. comment
    Comment #26836580

    > tried to blame it partly on the Go compiler producing more bloated code over time Where? The argument is _precisely_ that the growth is occurring in non-code areas. > partly on a…