WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Plan 9 CPU command, in Go, for Linux  (Read 1242 times)

Offline gadget42

  • Hero Member
  • *****
  • Posts: 657
Plan 9 CPU command, in Go, for Linux
« on: July 04, 2022, 02:26:40 PM »
Plan 9 CPU command, in Go, for Linux

this was mentioned in:
http://forum.tinycorelinux.net/index.php/topic,23811.msg165318.html#msg165318
which referenced:
https://fosdem.org/2022/schedule/event/plan_9_cpu_cmd/

but i wanted to start a new thread specifically for Plan 9 CPU command

this was the presentation i viewed(the mp4 file audio didn't work for me but the webm was fine):
https://video.fosdem.org/2022/D.firmware/plan_9_cpu_cmd.webm

Ron Minnich's Github:
https://github.com/rminnich

added this from slashdot regarding github:
https://news.slashdot.org/story/22/07/01/211238/software-freedom-conservancy-quits-github

sharing is caring

20220704-1639-modified-added slashdot link regarding Software Freedom Conservancy Quits Github
« Last Edit: July 04, 2022, 02:39:28 PM by gadget42 »
The fluctuation theorem has long been known for a sudden switch of the Hamiltonian of a classical system Z54 . For a quantum system with a Hamiltonian changing from... https://forum.tinycorelinux.net/index.php/topic,25972.msg166580.html#msg166580

Offline mocore

  • Hero Member
  • *****
  • Posts: 506
  • ~.~
Re: Plan 9 CPU command, in Go, for Linux
« Reply #1 on: February 24, 2023, 11:24:30 PM »

there is also (ftr) this page about the cpu command

https://github.com/linuxboot/book/tree/master/cpu - "The u-root cpu command"

which appears (after scanning over) to includes an overview + diagrams and some examples !

Offline mocore

  • Hero Member
  • *****
  • Posts: 506
  • ~.~
Re: Plan 9 CPU command, in Go, for Linux
« Reply #2 on: March 14, 2023, 07:45:52 AM »

+ https://github.com/perpen/lx # Plan 9 - Linux as cpu server

Quote
lx is an attempt at using Linux machines as cpu servers, providing a user experience analogous to using the Plan 9 command cpu(1)

Offline mocore

  • Hero Member
  • *****
  • Posts: 506
  • ~.~
Re: Plan 9 CPU command, in Go, for Linux
« Reply #3 on: December 31, 2023, 02:13:30 AM »
"The u-root cpu command" (linked above)

is quite the lament , reading through it again ( a little more thoroughly )

the mention of pox related methods reminds me of "Cosmopolitan Libc" &
"Patching GCC to build Actually Portable Executables" https://forum.tinycorelinux.net/index.php/topic,26597.msg171445.html#msg171445

and the problem space of `shared library dependency isolation` fun afaik is something nix and guix package-managers encounter while perusing the goal of reproducible builds
"guix - "loader cache" glibc ldconfig " https://forum.tinycorelinux.net/index.php/topic,25446.msg162986.html#msg162986


Quote
Our user might use one of the many tools that package a binary and all its libraries into a single file, to be executed elsewhere. The u-root project even offers one such tool, called pox, for portable executables. Pox uses the dynamic loader to figure out all the shared libraries a program uses, and place them into the archive as well. Further, the user can specify additional files to carry along in case they are needed.

The problem here is that, if our user cares about binary size, this option is even worse. Deadcode removal won’t work; the whole shared library has to be carried along. Nevertheless, this can work, in some cases.

So our user packages up their executable using pox or a similar tool, uses scp to get it to the remote machine, logs in via ssh, and all seems to be well, until at some point there is another message about a missing shared library! How can this be? The program that packaged it up checked for all possible shared libraries.

Unfortunately, shared libraries are now in the habit of loading other shared libraries, as determined by reading text files. It’s no longer possible to know what shared libraries are used; they can even change from one run of the program to the next. One can not find them all just by reading the shared library itself. A good example is the name service switch library, which uses /etc/nsswitch.conf to find other shared libraries. If nsswitch.conf is missing, or a library is missing, some versions of the name service switch library will core dump.

Not only must our user remember to bring along /etc/nsswitch.conf, they must also remember to bring along all the libraries it might use. This is also true of other services such as Pluggable Authentication Modules (PAM). And, further, the program they bring along might run other programs, with their own dependencies. At some point, as the set of files grows, frustrated users might decide to gather up all of /etc/, /bin, and other directories, in the hope that a wide enough net might bring along all that’s needed. The remote system will need lots of spare disk or memory! We’re right back where we started, with too many files for too little space.

hny
« Last Edit: December 31, 2023, 02:17:56 AM by mocore »