Running a number of production services on-premise on a big machine using native zones, a few using LX zones (the built-in Linux compatibilty layer), and a single bhyve zone. Actually, years ago this machine was the very first server we set up when our company was just getting started and for the first few years it ran pretty much everything. Zones were ideal for that, also to allow us to pack more services on less hardware, while having decent separation and everything snapshotting/backupping using ZFS. Nowadays we have a bunch more servers, with varying *nix operating systems (SmartOS, Debian, FreeBSD), as well as macOS and even Windows for some specific CI functions. (:
The global zone works great as a hypervisor if you prefer working over SSH in a real shell, and being able to run a lot of services natively just makes things like memory allocation to VM's and having a birds eye view of performance easier. Being able to CoW cp/mv files between zones because it's actually the same filesystem makes certain operations much easier than with actual VM's. Bhyve works well for the things that need an actual Linux kernel or other OS, at the cost of losing some of the zone benefits mentioned earlier.
Highlighting a few things we today run on SmartOS, grouped by their technology stacks: C (haproxy, nginx, PostgreSQL, MariaDB), PHP (various web apps), Java (Keycloak), Elixir/Phoenix (Plausible, fork of Firezone), Rust (rathole, some internal glue services), Go (Grafana, Consul, Prometheus). Most of those are readily available in the package manager, and a few offer native Solaris binaries which run fine on illumos. Others we do local builds in a utility zone before copying the binary package to the where it actually runs.
On LX zones we also run a number of services without problems, usually because they have Debian packaging available but are not in pkgsrc (for example Consul/Nomad, Fabio, some internal things that was already Linux-specific and we haven't bothered to port yet).
And at home a LX zone also runs Jellyfin just fine. (:
You might also be interested in the IRMA protocol and the app implementing it, Yivi. They support a similar scheme, but using some additional cryptographic systems that provide extra security properties such as unlinkability that are very useful for privacy.
Since I learned about it I've been hoping a system providing such unlinkability would be further developed and preferably adopted as the standard for online identity by for example the EU. Unfortunately I don't think the current proposals for the eIDAS include this (although it's been a while since I read up on this and I'd love to hear from someone more familiar if I'm wrong!)
When implementing a tiny timing library in JS a few years back I found that most engines indeed seem to cast the value to an integer (effectively flooring it), so in order to get consistent behaviour in all environments I resorted to always calling Math.ceil on the timeout value first [1], thus making it so that the callbacks always fire after at least the given timeout has passed (same as with regular setTimeout, which also cannot guarantee that the engine can run the callback at exactly the given timeout due to scheduling). Also used a very similar timeout chaining technique as described here, it works well!
I haven't so far. CS:GO and now CS2 run natively on Linux, so never played those online in the VM. I hear Valorant's anticheat is trouble, but I haven't played it (and probably won't for that reason; personally I have so many other games left to play I'd probably just do that instead of having to install Windows on a separate boot drive).
When I switched to daily driving Linux I created a VFIO Windows VM that gets passed through my GPU and USB controller (and thus audio, inputs) which gives me pretty near native performance. It takes maybe 10 seconds to boot into it, and I can easily access my files from the Linux host running underneath. I recently added a VirtioFS mount so I can store my games on the Linux filesystem instead of inside the VM disk image. I've started a few games and benchmarks on it to confirm it runs great.
VM running using libvirt and virt-manager, using QEMU underneath, with custom hook script that makes passing through the hardware a bit more seamless.
Although with how awesome Wine/Proton and ecosystem are these days I have so far played almost all my games on Linux. I created the VM setup because I thought I'd need it, but turns out I didn't really. Think I've played through 20-30 games or something like that now with minimal issues on Linux, including big budget AAA games within a few days of their release, smaller indie games, all kinds of different ones. Most tinkering required was for older games that'd need similar tweaks on modern Windows as well.
In production on SmartOS (illumos) servers running applications and VM's, on TrueNAS and plain FreeBSD for various storage and backups, and on a few Linux-based workstations. Using mirrors and raidz2 depending on the needs of the machines.
We've successfully survived numerous disk failures (a broken batch of HDD's giving all kinds of small read errors, an SSD that completely failed and disappeared, etc), and were in most cases able to replace them without a second of downtime (would have been all cases if not for disks placed in hard-to-reach places, now only a few minutes downtime to physically swap the disk).
Snapshots work perfectly as well. Systems are set up to automatically make snapshots using [1], on boot, on a timer, and right before potentially dangerous operations such as package manager commands as well. I've rolled back after botched OS updates without problems; after a reboot the machine was back in it's old state. Also rolled back a live system a few times after a broken package update, restoring the filesystem state without any issues. Easily accessing old versions of a file is an added bonus which has been helpful a few times.
Send/receive is ideal for backups. We are able to send snapshots between machines, even across different OSes, without issues. We've also moved entire pools from one OS to another without problems.
Knowing we have automatic snapshots and external backups configured also allows me to be very liberal with giving root access to inexperienced people to various (non-critical) machines, knowing that if anything breaks it will always be easy to roll back, and encouraging them to learn by experimenting a bit, to the point where we can even diff between snapshots to inspect what changed and learn from that.
Biggest gotchas so far have been on my personal Arch Linux setup, where the out-of-tree nature of ZFS has caused some issues like a incompatible kernel being installed, the ZFS module failing to compile, and my workstation subsequently being unable to boot. But even that was solved by my entire system running on ZFS: a single rollback from my bootloader [2] and all was back the way it was before.
Having good tooling set up definitely helped a lot. My monkey brain has the tendency to think "surely I got it right this time, so no need to make a snapshot before trying out X!", especially when experimenting on my own workstation. Automating snapshots using a systemd timer and hooks added to my package manager saved me a number of times.
A workaround that works locally (and only locally) is to build zfs-dkms (AUR) yourself and modify it so it doesn't break on these GPL-only symbols. While the licenses would forbid distributing it as such, you can do so on your own machine just fine.
And if your root is on ZFS, make a snapshot before updating! I set up a pacman hook[0] which runs zfs_autobackup[1] which automatically manages snapshots, so I can always easily roll back to a non-broken state. The ZFSBootMenu[2] bootloader makes that extremely fast without even needing a bootable USB-drive. :)
Actually, you can use it on Android, but it does require using Firefox Nightly[1].
That does come with downsides such as Nightly being less stable and installing extensions requiring some extra setup, so it isn't the best choice for everyone. But I myself am using Stylus (which works perfectly fine) and some other not officially supported WebExtensions on mobile this way and can recommend it if you don't mind the downsides.
As a long time user of Sandboxie, I'm excited to see this announcement and am looking forward to the open source release and what the community might be able to do with it.
Sandboxie's technology works extremely well for securely isolating all kinds of interactive Windows GUI apps, and might thus be be an interesting alternative to Microsoft's own Windows Container technology which is more focussed on servers and can't really do GUI's.
I'd love to see some experiments using Sandboxie sandboxes as Docker-style images/containers. Packaging a complete GUI app including dependencies and making it easy to run on another Windows machine without polluting it, without noticeable overhead, neatly integrating like you'd expect of a Windows app with things like window management or the clipboard, and all that while being securely isolated from the rest of the machine.
You could look into streaming parsers such as Oboe.js, which specifically support the use case of parsing JSON tree's larger than the available RAM[0]. Then again, when you're loading such huge JSON files into a 32-bit instance of Chrome, it is likely you should look for a totally different solution to your problem.
I like the idea of sharing clean URL's. Actually, I use the Pure URL add-on[0] for Firefox which also removes garbage such as e-mail campaign tracking values, both for the purpose of sharing and since I prefer seeing/visiting clean URL's myself as well.
The Chrome implementation using the canonical URL has some edge cases which may be useful to handle, like adding the fragment which isn't part of the canonical URL for the resource yet can be useful to share. Given that this change is only for the share dialog and not for copying from the URL bar, that doesn't seem like a huge problem though.
Reminds me of a cleaner tool I wrote about 10+ years ago, a huge single God-class which would parse an HTML string, allowed me to do various transformations on the object tree, and rerendered the entire source code in correct and nicely indented XHTML. Back then I had unused server capacity, so I often used it to do compression of dynamically rendered pages from for example message boards. Also allowed me to place a badge bragging about my 100% W3C validator score, since the original software packages often did not produce such clean HTML. :p The code is actually still being run on every pageload for some old sites I never updated much since.
It has a tiny little webinterface a which remains online today on some underpowered server. Doesn't work well with anything except XHTML though. http://htmlcleaner.blackholestudios.nl/
Really cool, enjoyed playing it for a while. Challenges you to practise your regex golf[1] skills. :)
There seem to be some bugs with the timing mechanisms, probably some JS timeouts aren't properly reset, causing weird game behaviour like running out of time mid-game (the countdown still displaying 10+ seconds). Also correct answers aren't always acknowledged (all icons show the answer to be correct, however it doesn't result in that player winning the game). :)
For those who are looking for something similar but (being the kind of people who read HN) would like something more configurable and hackable, you might check out the products of Victron Energy[0]. They've also have an optional remote management portal[1] which allows you to set up and monitor everything remotely for years now, and most the software running locally on the devices is open source and fully modifiable (such setups are even supported!).
Full disclosure: I'm one of the developers of the mentioned Remote Management portal.
I never heard of SQRL specifically before, so I just spent some time researching it. From what I can find, it has some significant flaws[0], and it doesn't seem these can be addressed without defeating the few advantages this SQRL approuch has.
The global zone works great as a hypervisor if you prefer working over SSH in a real shell, and being able to run a lot of services natively just makes things like memory allocation to VM's and having a birds eye view of performance easier. Being able to CoW cp/mv files between zones because it's actually the same filesystem makes certain operations much easier than with actual VM's. Bhyve works well for the things that need an actual Linux kernel or other OS, at the cost of losing some of the zone benefits mentioned earlier.
Highlighting a few things we today run on SmartOS, grouped by their technology stacks: C (haproxy, nginx, PostgreSQL, MariaDB), PHP (various web apps), Java (Keycloak), Elixir/Phoenix (Plausible, fork of Firezone), Rust (rathole, some internal glue services), Go (Grafana, Consul, Prometheus). Most of those are readily available in the package manager, and a few offer native Solaris binaries which run fine on illumos. Others we do local builds in a utility zone before copying the binary package to the where it actually runs.
On LX zones we also run a number of services without problems, usually because they have Debian packaging available but are not in pkgsrc (for example Consul/Nomad, Fabio, some internal things that was already Linux-specific and we haven't bothered to port yet).
And at home a LX zone also runs Jellyfin just fine. (: