Hacker News: Hello71

New comment by Hello71 in "Uv: Running a script with dependencies"

Hello71 — Tue, 22 Jul 2025 01:02:42 +0000

https://en.wikipedia.org/wiki/Shebang_(Unix)#Argument_splitt...

New comment by Hello71 in "Trial by Fire: The crash of Aeroflot flight 1492"

Hello71 — Tue, 13 May 2025 16:30:34 +0000

Modern commercial aviation is extremely safe because of investigators and regulators banning this "well the pilot just fucked up" explanation and instead looking at systemic factors.

As pointed out in the article, if the pilot was so incompetent, why didn't they receive further training, or if truly untrainable, fired? The airline and regulator have the responsibility for doing so, and ending the investigation at "pilot error" guarantees that another incompetent pilot will crash another plane.

New comment by Hello71 in "You might want to stop running atop"

Hello71 — Wed, 26 Mar 2025 21:27:13 +0000

https://github.com/Atoptool/atop/blob/77e658ea04f4901adf44c7...

installed by default in most distributions, e.g. https://packages.debian.org/bookworm/amd64/atop/filelist

New comment by Hello71 in "You might want to stop running atop"

Hello71 — Wed, 26 Mar 2025 00:07:32 +0000

I stopped using atop when I found it installs several hooks which automatically run code as root and deposit files around the filesystem, including a "power management" hook.

New comment by Hello71 in "A 10x Faster TypeScript"

Hello71 — Wed, 12 Mar 2025 00:38:51 +0000

> Why aren't you using this logic to argue that they should use Delphi or TurboPascal because Anders Hejlsberg created those?

as you know full well, Delphi and Turbo Pascal don't have strong library ecosystems, don't have good support for non-Windows platforms, and don't have a large developer base to hire from, among other reasons. if Hejlsberg was asked why Delphi or Turbo Pascal weren't used, he might give one or more of those reasons. the question is why he didn't use C#, for which those reasons don't apply.

New comment by Hello71 in "Google drops pledge not to use AI for weapons or surveillance"

Hello71 — Tue, 04 Feb 2025 23:59:32 +0000

the contention of your respondents and downvoters is that regardless of your intention, the extra information actually communicated is "i'm an asshole".

Modern languages and bad packaging outcomes at scale

Hello71 — Sat, 01 Feb 2025 13:46:53 +0000

Article URL: https://utcc.utoronto.ca/~cks/space/blog/sysadmin/DistributionPackagingIssues

Comments URL: https://news.ycombinator.com/item?id=42898240

Points: 3

# Comments: 0

New comment by Hello71 in "Intentrace: Strace for Everyone"

Hello71 — Fri, 08 Nov 2024 14:23:56 +0000

Yeah, it seems like it could be implemented as a postprocessor of strace --decode-fds. Knowing what each syscall does isn't really the hard part of strace, it's knowing which ones are important, which ones are part of libc itself and can usually be ignored (e.g. collecting /etc/localtime) and which are explicitly requested by the application, piecing together multi-threaded/multi-process logic, etc. strace has a lot of functions to help with that which this doesn't support, like syscall filtering, struct decoding, and stack tracing.

New comment by Hello71 in "Ireland's big school secret: how a year off-curriculum changes teenage lives"

Hello71 — Wed, 16 Oct 2024 20:08:55 +0000

I googled "quebec educational attainment" and found https://statistique.quebec.ca/en/communique/university-gradu..., which says that "Québec has the highest proportion of people aged 25 to 64 with any postsecondary certificate, diploma or degree (71.2%).". According to https://www.statista.com/statistics/467078/median-annual-fam..., Quebec's median annual family income in 2021 was 96,910, almost the same as the median 98,390. The top "provinces" are Northwest Territories and Yukon, whose ways of doing things, for better or worse, cannot be easily copied to other provinces.

New comment by Hello71 in "Lenticular Clock"

Hello71 — Tue, 20 Aug 2024 19:11:15 +0000

They're the same thing. The problem is not the container, it's the H.265 encoded video which Firefox doesn't accept. It's not a good idea to throw raw cell phone video onto a website, first because it probably won't play everywhere, and second because there's embedded high-precision location data.

New comment by Hello71 in "Second factor SMS: Worse than its reputation"

Hello71 — Thu, 11 Jul 2024 18:00:19 +0000

it would be most convenient to have no 2FA. hell, skip the password too, then nobody will forget theirs. security is tradeoffs, but NIST says "if you take security seriously, you should not use SMS 2FA".

New comment by Hello71 in "Rogers networks reliability and resiliency assessment after 2022-07-08 outage"

Hello71 — Sat, 06 Jul 2024 02:42:34 +0000

> Not for extended international use; you must reside in the U.S. and primary usage must occur on our network. Device must register on our network before international use. Service may be terminated or restricted for excessive roaming. Coverage not available in some areas; we are not responsible for our partners’ networks.

New comment by Hello71 in "Exploring How Cache Memory Works"

Hello71 — Wed, 26 Jun 2024 18:31:39 +0000

  grep . /sys/devices/system/cpu/cpu*/cache/index*/coherency_line_size

would be better, but

  lscpu -C

is more useful.

New comment by Hello71 in "In Colorado, an ambitious new highway policy is not building them"

Hello71 — Sat, 01 Jun 2024 20:50:38 +0000

the Katy Freeway already has 26 lanes since 16 years ago https://en.wikipedia.org/wiki/Interstate_10_in_Texas

New comment by Hello71 in "Speeding up ELF relocations for store-based systems"

Hello71 — Tue, 07 May 2024 00:05:50 +0000

This is interesting, but I'm not sure it actually makes much difference for realistic workloads. ffmpeg probably has the most link-time dynamic linking of any Linux package, and ffmpeg -loglevel quiet takes only ~40 ms on Alpine and ~60 ms on Debian. Other programs using ffmpeg tend to either statically link it (Chromium) or link it at run-time (Firefox, most video editors), neither of which would be improved by this optimization.

Would it be nice to shave 60 ms off of every ffmpeg/mpv invocation? In isolation, sure, but considering the maintenance burden and potential inconsistencies I don't think it's worth it. Nix is supposed to ensure that the dependencies are always the same, but currently if something breaks somehow, the wrong version will be loaded or an error will be emitted, whereas with this optimization, it will crash or silently invoke the wrong functions which seems extremely difficult to debug.

New comment by Hello71 in "Does the American Diabetes Association work for patients or companies?"

Hello71 — Sat, 04 May 2024 19:39:28 +0000

> pre-diabetes [...] is rather close to the median level

but according to the NIH, 30.7% of Americans are overweight, and 42.4% are obese. as the median American is overweight, it doesn't seem a stretch to claim that the median American is also pre-diabetic? I don't know whether it's true or not, but your evidence seems a bit thin.

New comment by Hello71 in "Tell HN: Bypass Paywalls repository is gone"

Hello71 — Sat, 13 Apr 2024 00:48:25 +0000

this is basically the "computer scientist" view of the world in https://ansuz.sooke.bc.ca/entry/23, especially the Monolith bit. spoofing UA could be legal in general or when done for interoperability but illegal when done with intent to bypass access control.

New comment by Hello71 in "Pack: A new container format for compressed files"

Hello71 — Sat, 30 Mar 2024 03:33:30 +0000

This sounds like a Windows problem, plus compression settings. Your wlog is 24 instead of 21, meaning decompression will use more memory. After adjusting those for a fair comparison, pack still wins slightly but not massively:

  Benchmark 1: tar -c ./linux-6.8.2 | zstd -cT0 --zstd=strat=2,wlog=24,clog=16,hlog=17,slog=1,mml=5,tlen=0 > linux-6.8.2.tar.zst
    Time (mean ± σ):      2.573 s ±  0.091 s    [User: 8.611 s, System: 1.981 s]
    Range (min … max):    2.486 s …  2.783 s    10 runs
   
  Benchmark 2: bsdtar -c ./linux-6.8.2 | zstd -cT0 --zstd=strat=2,wlog=24,clog=16,hlog=17,slog=1,mml=5,tlen=0 > linux-6.8.2.tar.zst
    Time (mean ± σ):      3.400 s ±  0.250 s    [User: 8.436 s, System: 2.243 s]
    Range (min … max):    3.171 s …  4.050 s    10 runs
   
  Benchmark 3: busybox tar -c ./linux-6.8.2 | zstd -cT0 --zstd=strat=2,wlog=24,clog=16,hlog=17,slog=1,mml=5,tlen=0 > linux-6.8.2.tar.zst
    Time (mean ± σ):      2.535 s ±  0.125 s    [User: 8.611 s, System: 1.548 s]
    Range (min … max):    2.371 s …  2.814 s    10 runs
   
  Benchmark 4: ./pack -i ./linux-6.8.2 -w
    Time (mean ± σ):      1.998 s ±  0.105 s    [User: 5.972 s, System: 0.834 s]
    Range (min … max):    1.931 s …  2.250 s    10 runs
   
  Summary
    ./pack -i ./linux-6.8.2 -w ran
      1.27 ± 0.09 times faster than busybox tar -c ./linux-6.8.2 | zstd -cT0 --zstd=strat=2,wlog=24,clog=16,hlog=17,slog=1,mml=5,tlen=0 > linux-6.8.2.tar.zst
      1.29 ± 0.08 times faster than tar -c ./linux-6.8.2 | zstd -cT0 --zstd=strat=2,wlog=24,clog=16,hlog=17,slog=1,mml=5,tlen=0 > linux-6.8.2.tar.zst
      1.70 ± 0.15 times faster than bsdtar -c ./linux-6.8.2 | zstd -cT0 --zstd=strat=2,wlog=24,clog=16,hlog=17,slog=1,mml=5,tlen=0 > linux-6.8.2.tar.zst

Another machine has similar results. I'm inclined to say that the difference is probably mainly related to tar saving attributes like creation and modification time while pack doesn't.

> it is done in two steps: first creating tar and then compression

Pipes (originally Unix, subsequently copied by MS-DOS) operate in parallel, not sequentially. This allows them to process arbitrarily large files on small memory without slow buffering.

New comment by Hello71 in "Pack: A new container format for compressed files"

Hello71 — Sat, 23 Mar 2024 06:25:24 +0000

My apologies, the text color is barely legible on my machine. Those details are still minimal though; what versions of software? How much RAM is installed? Why is 7-Zip set to maximum compression but zstd is not? Why is tar.zst not included for a fair comparison of the Pack-specific (SQLite) improvements on top of from the standard solution?

New comment by Hello71 in "Pack: A new container format for compressed files"

Hello71 — Fri, 22 Mar 2024 21:13:42 +0000

Also, 4.7 seconds to read 1345 MB in 81k files is suspiciously slow. On my six-year-old low/mid-range Intel 660p with Linux 6.8, tar -c /usr/lib >/dev/null with 2.4 GiB in 49k files takes about 1.25s cold and 0.32s warm. Of course, the sales pitch has no explanation of which hardware, software, parameters, or test procedures were used. I reckon tar was tested with cold cache and pack with warm cache, and both are basically benchmarking I/O speed.