Hello71

in most cases, on modern hardware, limiting the frequency significantly below its nominal maximum will reduce battery life. for a fixed amount of work (e.g. parsing an HTML document), it is more efficient to complete the task as quickly as possible then return to a low-power state. the picture gets somewhat murkier when considering increased voltage requirements at higher clock speeds and certain fixed-wakeup workloads, but the majority of scheduler tuning for battery-powered devices over the past decade has been towards going to sleep as quickly as possible, even if that requires a high peak frequency.

huh? this would be a severe POSIX violation, which says that for socket and accept, "The file descriptor shall be allocated as described in File Descriptor Allocation.": "All functions that open one or more file descriptors shall, unless specified otherwise, atomically allocate the lowest numbered available (that is, not already open in the calling process) file descriptor at the time of each allocation."

this is incorrect, and is relatively easy to test:

  $ strace -y -P /tmp/test.sh bash /tmp/test.sh
  ioctl(3</tmp/test.sh>, TCGETS, 0x7ffc6daea580) = -1 ENOTTY (Inappropriate ioctl for device)
  lseek(3</tmp/test.sh>, 0, SEEK_CUR)     = 0
  read(3</tmp/test.sh>, "#!/bin/sh\n", 80) = 10
  lseek(3</tmp/test.sh>, 0, SEEK_SET)     = 0
  dup2(3</tmp/test.sh>, 255)              = 255</tmp/test.sh>
  close(3</tmp/test.sh>)                  = 0
  fcntl(255</tmp/test.sh>, F_SETFD, FD_CLOEXEC) = 0
  fcntl(255</tmp/test.sh>, F_GETFL)       = 0x8000 (flags O_RDONLY|O_LARGEFILE)
  newfstatat(255</tmp/test.sh>, "", {st_mode=S_IFREG|0644, st_size=10, ...}, AT_EMPTY_PATH) = 0
  lseek(255</tmp/test.sh>, 0, SEEK_CUR)   = 0
  read(255</tmp/test.sh>, "#!/bin/sh\n", 10) = 10
  read(255</tmp/test.sh>, "", 10)         = 0

  #!/bin/sh
  main() {
  # script goes here
  }
  main

source? this is a popular theory among non-lawyers, but not, as far as I can tell, well-supported by the evidence. http://jaapl.org/content/early/2021/05/19/JAAPL.200107-20 has extensive citations including for their claim that "In theory, telling a patient about an error may make patients more likely to pursue litigation. In practice, however, bad outcomes alone are typically not reason enough for patients or their families to file malpractice claims."

[0] see the dozens of official Windows GUI frameworks: https://news.ycombinator.com/item?id=16736720 (and since then, it's gotten worse: https://www.google.com/search?hl=en&q=uwp%20deprecated)

  echo power | tee /sys/devices/system/cpu/cpufreq/policy*/energy_performance_preference

The title:

> A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux

as opposed to ELF Executables for non-Linux systems, or a.out executables for Linux. In the middle of the article, when the illegal shenanigans start:

> Unless, that is, we could change the contents of the structures to make them match even further....

> How many of these fields is Linux actually looking at, anyway? For example, does Linux actually check to see if the e_machine field contains 3 (indicating an Intel 386 target), or is it just assuming that it does?

At the end of the article:

> Of course, half of the values in this file violate some part of the ELF standard, and it's a wonder that Linux will even consent to sneeze on it, much less give it a process ID. This is not the sort of program to which one would normally be willing to confess authorship.

I don't see how the author could possibly be any clearer that this is Linux-specific and will probably not work (unmodified) on non-Linux systems.

since when does glibc run on bsd

  Location: Toronto, Canada
  Remote: Open to
  Willing to relocate: Yes
  Technologies: C, Python, shell, Linux, git
  Résumé/CV: https://www.alxu.ca/resume/
  Email: see resume

> The new biography Steve Jobs

it was a response to the new biography.

so whenever you upgrade the kernel or change CPU all your programs need manual patching? you may answer, "well uname -a was a joke, you would actually check the libc version". this worked alright in a very specific time period with a couple of big vendors with nigh-unmodifiable toolchains with well-defined release versions. it became increasingly awful when people started making their own toolchains with free software and had to patch every single piece of software to properly detect their new libc. sitting through an hour of autoconf sucks, but slogging through ten hours of patching poorly written bespoke configure scripts is a hundred times worse.

edit: not to mention cross-compiling where you can't even run uname -a, and which was almost universally broken before autoconf, which, despite being painful, made cross-compiling mostly work everywhere.

this is built in to firefox since it was netscape navigator, under view -> page style -> no style.

even the menu items have barely changed since then: http://www.alanwood.net/unicode/net7_encoding.gif

it's good practice to close extra FDs for children who are not expecting it. poorly designed applications may misbehave if provided with unexpected additional FDs. you shouldn't use /dev/null for this purpose, but instead actually close it with 3>&-.