Alessandro Pignotti writing on the Leaning Technologies blog:
WebVM is a full Linux environment running in the browser, client-side. It is
a complete virtual machine, with support for persistent data storage,
networking and, as of today’s release, Xorg and complete desktop
environments. In an instance of WebVM, everything executes locally within the
browser sandbox.
WebVM runs on any modern browser, including mobile ones, thanks to
WebAssembly, HTML5 and CheerpX: a novel x86 virtualization engine for
browsers, developed by us at Leaning Technologies.
You may have seen other sites that run operating systems in the browser.
Typically these compile an emulator to WebAssembly and host that in the
browser. This works quite well with the light demands of older systems but can
be a bit slow for more demanding systems.
WebVM takes a different approach. The CheerpX engine is a JIT compiler from x86
to WebAssembly and is able to run Linux binaries unmodified. WebVM adds a
browser based Linux syscall implementation that allows it to run binaries,
including graphical ones in the browser, much faster than using a whole system
emulator.
WebVM running i3 on Alpine Linux with XTerm and GVim running.
On October first, I was diagnosed with pancreatic cancer. Because of vascular
involvement, surgery is not possible. I am taking weekly chemo treatments to
shrink the tumor before surgical resection. I am tolerating the chemo pretty
well, and I am in good spirits. Every day I make a point of getting out in
the sun and walking with Cai and Poppy.
Bill Atkinson, the author of Quickdraw and the main user interface designer,
who was by far the most important Lisa implementer, thought that lines of
code was a silly measure of software productivity. He thought his goal was
to write as small and fast a program as possible, and that the lines of code
metric only encouraged writing sloppy, bloated, broken code.
This lead to a Wikipedia rabbit hole that started with Andy and Bill co-founding
General Magic along with Marc Porat, and concluded with me discovering that
the Nautilus file manager used in GNOME was created by Eazel, a company
Andy Hertzfeld founded after General Magic. Eazel didn’t succeed, but as it
laid off most of its 75 employees, 1.0 of Nautilus was released. This 1.0
version was included in GNOME 1.4, released on 13 March, 2001.
I was able to track down a virtual machine image of Red Hat running
GNOME 1.4 and after a little but of massaging was able to run it in QEMU on my
much newer Linux system. Incidently GNOME Files—Nautilus’ successor—is my file
manager of choice on Linux. Please enjoy these screenshots I took of that
surprisingly usable 23 year old system.
Start Here
About Nautilus
GNU Image Manipulation Program
Early version of the GNOME website in the Mozilla browser
Linux Orbit website in the Mozilla browser
Nautilus Help
If you’d like to try it out yourself, follow the steps below to run it with QEMU.
Alternatively, if you use Virtual Box you can import the .ova directly:
If Bluesky is your jam, the Linked List Mastodon account is now bridged to
Bluesky as: @linkedlist.org thanks to Bridgy Fed. I’m also
subscribed to the notifications feed, so I should also see any replies to that
account.
“Write JavaScript like it’s 2005” had been GitHub’s front-end team’s
guideline since its inception, until React got pushed down from Microsoft
management and most of us on the front-end team quit. If you are a user of
github.com, consider how it has changed since 2020.
This is an old practice that has gotten lost in the ways with the manufacture
of JavaScript industrial complex/ecosystems and frameworks. I hate to be the
one to tell old tales but this is just another reminder that you can
absolutely avoid dependency hell, We used to review every single dependency
that goes into GitHub Dotcom and during our time the JS bytes continuously
decreased as features were added.
That guideline was certainly evident as a user, as was the change post 2020. In
some ways, the post-2020 pages have more features and respond to interactions
faster but at the same time the new React based source view is infuriating at
times: trying to select text and having it highlight the whole symbol for the
symbol view/search, or Ctrl-f not always invoking the browser UI, for
example.
I’ve found that many systemd components are less effective in an embedded
environment than the traditional alternatives. I’ve shown some illustrative
examples in this article, but I really don’t think there’s much controversy
here: this simply isn’t the environment that systemd was designed for. But
it’s getting increasingly difficult to find a mainstream Linux distribution
that doesn’t use systemd – even Raspberry Pi distributions use it.
As systemd absorbs more functionality into itself, there’s going to be little
motivation to maintain alternatives. After all, if everybody uses systemd,
what motivation is there to support anything else? My concern is that we’re
moving towards a future where Linux is inconceivable without systemd. That
will be a problem for those environments where systemd really doesn’t shine.
Dinit fits in the middle ground between extremely simple supervision suites
and the more complex service managers.
It’s the init system used on Chimera Linux, which I’m running on a number of
systems, including the WSL2 install that I’m writing this post on. Dinit has
been great in my experience, although that’s admittedly also on desktop and
server machines. It’s a lot smaller in scope than systemd so it would allow
embedded systems to continue to use tools like Chrony and syslog-lite mentioned
in the post.
