@moses_izumi@bojidar_bg doslinux just boots a linux kernel from dos while taking care to preserve dos memory so that it can be resumed in vm86 mode later (just like how win9x worked) It's a real linux kernel so you can do anything you could normally do under linux. The project is more of a fun hack than anything serious though, it's really crashy in practice
@moses_izumi@bojidar_bg yep heaps crashier. It doesn't attempt to virtualise much hardware like win9x does with VxDs - only really the BIOS keyboard service. DOS retains full hardware control otherwise and both OSes are sharing the hardware with basically no coordination. It's enough to make the demo video in the readme work and not much more :)
Why is USB pass-through to a VM often unreliable? Like specifically what is it about the protocol or implementations or whatever that makes it difficult to do?
+ honourable mention for SSH, a tool I haven't used but looks interesting, which can automatically generate hardening settings for you by observing what your service actually does at runtime: https://github.com/desbma/shh
another good reason to Just Use Systemd instead of containers is all the hardening knobs that are readily available. You can block entire slices of the filesystem that your service shouldn't access. You can block all network access except what your program needs. You can block whole entire categories of syscalls and kernel features your program shouldn't use.
It is literally just a few lines of config to do all that and it might just save you from getting popped and running a cryptominer or worse next time a dependency you didn't know about of some random app you've deployed has some disastrous RCE
@icing@whitequark also a symptom of neoliberal outsourcing culture imo - the pendulum has swung too hard back from NIH. if you can achieve some need by bringing in a tool or a framework then great, but cooking up a small and perfectly adapted solution in house for a "non core" business need like CI or deploys is something you have to justify. jeff bezos calls this kind of work "undifferentiated heavy lifting", but when you lose the specialisation you also tend to lose many opportunities for efficiency
@whitequark i think a lot of devs have just never known better. “CI has always been slow”, “deploys have always been slow”, “servers have always been complicated to configure and maintain”
Reading this post on Debian’s git transition and all this stuff is exactly what I had been searching for and couldn’t figure out a year or so ago omg https://diziet.dreamwidth.org/20436.html
Like holy fuck this is a game changer. Exactly what I’ve been wanting!!
> Downstreams and users can obtain the source code of any Debian package in git form. (dgit clone, 2013). They can then work with this source code completely in git, including building binaries, merging new versions, even automatically (eg Raspbian, 2016), and all without having to deal with source packages at all (eg Wikimedia 2025).
the g in gobject stands for glib, and the g in glib stands for gtk, and the g in gtk stands for gimp, however the g in gimp stands for gnu, so really the g in glib stands for gnu, but you shouldn't confuse it with gnulib, which is developed by the gnu project, who shouldn't be confused as the developers of glib, which is the gnome project, in which the g also stands for gnu