DvdGiessen
Joined 11 years ago
Karma
457
Submissions
33
Member since
Jun 5
GPG key id: 7b9684b572b86c26826a8f5e342ccf7ef78b7a2c
https://github.com/DvdGiessen.gpg
View on Hacker NewsRecent submissions
Comment · 9 months ago
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. (:
Comment · 1 year ago
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.
https://docs.yivi.app/technical-overview/
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!)
Comment · 2 years ago
Copying using OSC52 is great! I have a cross-platform shell function for that in my bashrc [1], as well as an implementation that works in vim [2].
[1]: https://github.com/DvdGiessen/dotfiles/blob/2c02332b4a657690... [2]: https://github.com/DvdGiessen/dotfiles/blob/2c02332b4a657690...
Comment · 2 years ago
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!
[1]: https://github.com/DvdGiessen/virtual-clock/blob/master/src/...
Comment · 2 years ago
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).
Comment · 2 years ago
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.
Comment · 3 years ago
One I remember is [0], mostly because of the excellent accompanying blogpost about how it works [1].
[0]: https://piratehearts.itch.io/supercrt [1]: https://www.gamedeveloper.com/programming/crt-simulation-in-...
Comment · 3 years ago
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.
[1]: https://github.com/psy0rz/zfs_autobackup [2]: https://zfsbootmenu.org/
Comment · 3 years ago
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. :)
[0]: https://wiki.archlinux.org/title/Pacman#Hooks [1]: https://github.com/psy0rz/zfs_autobackup [2]: https://zfsbootmenu.org/
Comment · 3 years ago
See also the recent talk the author gave at FOSDEM last month[1] for an introduction to the tool and its use cases.
Comment · 4 years ago
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.
[1]: https://blog.mozilla.org/addons/2020/09/29/expanded-extensio...