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.
I will offer that you can resize/move/float in most tiling managers. Remembering your modifications is usually possible too. It's the default behavior that separates the experience.
I can't see a practical world where the OS doesn't need to take control of window positioning in certain situations. As a core example, there is full screen. Minimize is another, but that doesn't have a clean analogue in the tiled universe.
There's a natural strong reaction folks have to window managers, because it forces you to mentally remap at such a foundational level.
I prefer tiled managers because the user offloads most responsibility. Open something and by default it uses as much space as is available. If you have a special need, you can float or resize, but the vast majority of cases it makes the right call.
At heart, it's offloading cognitive load. They're more predictable and require less faffing around.
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.
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.
Kernel as used in the title means shared processing core, not necessarily an OS kernel, which probably deserves clarification. As for Lisp and C, those are meant to be subset demonstrations not yet full compilers, thus the phrasing. The compiler you linked is also a subset of C with only what's needed for a minimal compiler.
I’ve been working towards making it self hosting eventually, which is why there’s the start of code for generics in GDSL-C, though that’s a significant project which will take significant time. Add to that, a lot of people would prefer to write handlers in C++ rather than learn a new language. So it may stay as a C++ project for a while.
That being said, I was also hesitant to post this until I had it self hosting, but I decided that being able to implement even the demonstrated subsets was interesting enough to be worth sharing. This is a project in progress, and I hope to expand it massively in the months to come.
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.
reply