ptspts

The HN title is incorrect. It should contain std::move.

I have a regular Bash shell history with about 750 000 entries on an SSD on a modern laptop, and would take about 1 second for Bash to load 1 million entries. The startup delay and the memory usage is noticeable.

Storing the shell command history in a database instead of the memory of each interactive Bash shell, it would make Bash start up faster, and also use less memory.

As indicated in https://tangled.org/oppi.li/stinkpot/blob/cdf87ffcd36e96f3d4... , this software (stinkpot) still uses Bash PROMPT_COMMAND as an entry point to copy new shell history entries to its database.

PROMPT_COMMAND has the following flaw: a command gets recorded as soon as it has finished. So command which never finish (e.g. because they run for a long time, and the user closes the terminal window, or reboots the system) never get recorded. Another flaw: the users starts a long-running command in terminal window 1, and immediately they want to start a variant of it in terminal window 2, but it's not available in the history.

In fact, it's possible to set up bind mounts without root on a modern Linux system, using a user namespace and a mount namespace.

It does, so not 100% is reused. The patched parts are in different sections though, so the entire .text (code) section ends up being reused.

I hate tiling window managers. After I start a program, I move and resize its window to the perfect position, and it stays there for weeks. I don't ever want it to be moved or resized automatically, which is what tiling window managers do by default.

Does the new owner of the domain friendster.com also own the company, the patents and the other pieces of intellectual property? The article seemed to be unclear about this.

Isn't creating a Docker image containing the right version of GCC or Clang a solution to the toolchain problem?

Shameless self-promotion: I think I hold the record (83 bytes) for the shortest hello-world Linux ELF executable: https://github.com/pts/mininasm/blob/master/demo/hello/hello...

GDSL is written in C++ with use of STL, templates and lambdas, so it's 2600 lines of such C++ source code. There is no self-hosting: neither the LISP compiler nor the C compiler can compile itself. No operating system is implemented, the word kernel in the title means something else.

FYI Here is a 700-line subset-of-C compiler which can compile itself: https://github.com/valdanylchuk/xcc700 . FYI The linker and the libc are not included.

It's possible to run WebAssembly programs from the command line (without any GUI) using WASI (see e.g. https://github.com/WebAssembly/WASI). Thus if the user downloads pdfconverter.wasi , and the user already has e.g. wasmtime installed, they can run `wasmtime pdfconverter.wasi input.pdf output.pdf` from the command line (see https://github.com/bytecodealliance/wasmtime/blob/main/docs/... for details).

In addition to the web site, the Electron app and the Chrome extension, you may want to distribute a command-line version of your tools as WASI-style .wasm program files. If you do so, I would exclusively use the them this way, from the command line.

Your commands to process PDF with Ghostscript are lossy (they lose lots of metadata and in minor ways they also change how the PDF renders), and they produce very large PDF files.

It does exclude unused code. But glibc has too many inter-object-file dependencies, so too much code gets used.

Neither the article nor the README explains how it works.

How does it work? Which WASM euntime does it use? Does it use a Python jnterpreter compiled to WASM?

As a text editor user, I prefer selecting the font and the syntax highlighting independently. This font is not useful for me.

What is the advantage of this circular implementation?

Is it faster than the simple one? Does it use less memory? Is it easier to write? Is it easier to understand?

I think all of the above is false, but I have a limited understanding of Haskell. Please correct me if I'm wrong.

Why is ELF so much slower and/or more memory hungry than a.out on Linux?

Shameless plug: Some of my hobby projects written in C (e.g. https://github.com/pts/bakefat) can be built reproducibly for Linux >=1.0 (1994), FreeBSD (same ELF executable program file as for Linux) and Win32 working on all versions of Windows (Windows NT 3.1 (1993)--Windows 11). The C compiler (running on Linux i386 and amd64 host) used for the release build is self-contained and included in the project, along with the libc.

Doing such backward compatibility is definitiely possible for command-line tools. Once set up, it's automatic, and it needs extra testing after major changes.

If a text-mode process monitor is larger than about 200 KiB, then it sounds bloated to me. If it's loaded with tons of features, then my upper limit is 1 MiB.

This video doesn't explain what the project does and how it does it. Also it's deliberately misleading the viewer, for example it purposefully incorrectly states that C++ is an interpreted language.

Also the music is way is too loud and sudden.

This should have been solved in the last 30 years on Linux console, X terminal emulators and through SSH.

The correct spelling is in lowercase: shared_ptr<T> . The title of the article is correct, the title of the HN post is incorrect.

How is Areal different from Arial? Neither the article nor https://are.al.are.na/ seem to be informative and focused on this.

I find this style overy verbose, disrepectful, offensive and dumb. (See example dialogue in the screenshot on the project page.) Fortunately, it's possible to change the prompt above.

Half of the source code is colored very-light-on-white, which is impossible to read. I'm using Chrome on Android.

Supporting arbitrary image formats and compression methods in the browser is easy: just ship the decoder as a WebAssembly function.

(This is not any better solution than GIF or aPNG though for the problem in the article.)

Where are the benchmarks comparing hyperpb to other proto parsers?

The title of the post is misleading, because it is not revealed in the story how the backpack was actually lost. The short summary: ``I don't remember how I lost my backpack, because I was heavily intoxicated during those hours when I lost it.''

The Str_to_double code in the article produces inaccurate results in the last few bits. (What is the use of parsing a double inaccurately?) Accurate parsing of a double is really tricky (and memory-hungry and slow). The strtod(3) function provided by a decent libc (such as glibc and musl, and also the FreeBSD libc) can do it correctly.

Isn't `gcc -O0` (for both C and C++) even slower than `clang -O0`?