Hello71

  Location: Toronto, Canada
  Remote: open
  Willing to relocate: yes
  Technologies: low-level Linux (kernel, libc, init, etc), C, x86 assembly, C#, Python
  Résumé/CV: https://www.alxu.ca/resume/
  Email: see resume

Looking for senior systems, infrastructure, kernel, and low-level performance engineering roles.

  Location: Toronto, Canada
  Remote: open
  Willing to relocate: yes
  Technologies: low-level Linux (kernel, libc, init, etc), C, x86 assembly, C#, Python
  Résumé/CV: https://www.alxu.ca/resume/
  Email: see resume

Looking for senior systems, infrastructure, kernel, and low-level performance engineering roles.

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.

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

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.

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

  lscpu -C

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.

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.

  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

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

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.

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.