HN user

Hello71

1,906 karma
Posts8
Comments964
View on HN

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.

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.

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.

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.

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.

Lenticular Clock 2 years ago

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.

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

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.

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.

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.

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?

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.

your idea also doesn't work with live streaming, and may also not work with inter-frame filters (depending on implementation). nonetheless, this exists already with those limitations: av1an and I believe vapoursynth work more or less the way you describe, except you don't actually need to load every chunk into memory, only the current frames. as I understand, this isn't a major priority for mainstream encoding pipelines because gop/chunk threading isn't massively better than intra-frame threading.

dishwasher soap used to be a lot more effective before they removed phosphates

was it? https://www.consumerreports.org/media-room/press-releases/20... says that several phosphate-free formulations were "Very Good".

LED bulbs have been associated with migraine symptoms, and are all around terrible for reading.

some cheap LED bulbs have issues, but they're generally better than fluorescent bulbs which contain the horrible chemicals.

Let's not forget the clusterfuck that is lead-free solder and just ask yourself why it's banned from aircraft and space applications where reliability is of utmost importance.

is it? a Google search for "avionics lead solder" finds Boeing saying in 2005 that "consumer electronic industry trends will force aerospace to adapt to an evolving lead-free transition", a "US Tech" saying "The global aircraft and aerospace market is moving toward 100 percent lead-free solder", an "AIM Solder" which "offers many tin-lead & lead-free RMA products suitable for the military & aerospace sector", and one source saying "Tin-lead alloy solder [...] has been used to assemble the avionics of every aircraft currently flying", by... "Lead Matters".

while environmentally-friendly replacements sometimes have downsides, categorically painting them as a lot/infinitely/terribly/clusterfuck worse is just "gubmint takin away our freedoms". yes, lead-free gasoline did require some engine design improvements, but it would be insane and downright inhumane to keep using it for a small increase in octane rating.

PSI is exported by the kernel to track context switches: switch to idle process = io wait, switch to kswapd = mem wait, switch to other runnable process = cpu wait. these are already visible to the kernel, it just needs to increment some counters and expose those to userspace. you can get the perf counters with something like `perf stat -ae cache-misses sleep 60`, it doesn't need to be in /proc.

additionally, context switches are the same on everything that can run Linux, whereas PMU counters are highly CPU-specific (potentially even different in each CPU stepping), so given the current state of affairs, a generic interface would be very limited.

from the top of this thread:

Weird. I don't believe he even had an obligation to read any of it.

they're very clearly saying that they believe that under the current legal system, the "theatrics" are not allowed.

there are obviously lots of kids that had a very bad homeschooling, and also lots of kids that had very bad public schooling. many kids are bullied so badly at school that they commit suicide, and many more develop antisocial habits there. the question is whether those issues are better or worse with homeschooling, and a single anecdote doesn't help us with that.

or store the data out-of-line [...] which requires up to 2x writes

and because writes to separate sectors aren't atomic, you probably want to add journaling or some kind of CoW for crash safety, and oh look now you're actually just writing a filesystem and it's not simpler anymore.