• 53 Posts
  • 1.16K Comments
Joined 3 years ago
cake
Cake day: August 10th, 2023

help-circle


  • Illuminae. It’s an epistolary novel, so it’s narrated in the standard sense. They are often told via letters from protaganists to another chatlogs, or other documents. From wikipedia about Illuminae:

    The story is told through a series of documents; including classified reports, censored emails, camera transcriptions, and interviews

    (I did not quote it in full because I’m trying to keep it as spoiler free as possible. I remember having a lot of fun when I read it without knowing anything, I just picked it up from the library and started reading.)

    This book definitely wins for uniqueness of form, although I now understand what type of book it is and how to find more like that. But I’ve only ever read one book like that.

    Although House of Leaves also counts a little bit as epistolary fiction but we’ve all heard of House of Leaves so that one doesn’t count.

    Though, 17776 - wikipedia, is even more unique and also epistolary speculative fiction, but that’s not a book, but is instead online articles (which means it can include videos!).

    You can start reading that one, right now, here: https://www.sbnation.com/a/17776-football



  • Guix does not have that same churn by any stretch, but, would still offer all the wonderful features of NixOS if you are willing to do the work of setting up any packages yourself, that do not already exist, and that is not at all removed from my to do list

    One of Guix’s strengths, and one of the things that appeals to me over Nix, is importers:

    https://guix.gnu.org/manual/1.5.0/en/html_node/Invoking-guix-import.html

    You can import packages from go, ruby, python, rust, or a few other languages really easily. Just guix import packagerepo and boom you have a package. This makes it significantly easier to get packages from those ecosystems.

    Now, Nix has unofficial equivalent functionality… but it’s a mess and spread over 30 different projects, many of which would frustratingly only work with flakes (which are “experimental” and “not officiallly supported” despite the fact their extreme popularity), or only work with channels.

    I remember this pain point when trying to import a python package with nix. The only “just works” way of doing it that only worked via channels… and was deprecated, with the repo being archived. There was this new, non deprecated way by the same group of people… that didn’t support a specific feature I needed to get the python package to work. And to the best of my understanding, still doesn’t.

    Guix may not move as fast as Nix when it comes to packaging or innovation, but they have a certain “coherency”, where everything is together, integrated, well documented, and guaranteed to work.


  • I feel obligated to give some context about why they are excited, since the article seems to be targeting people who understand. Specifically, this part:

    “blue screen of the death” or “Oops”… except that it’s just an error! It doesn’t take your whole system away with it, only the particular operations that was going on.

    There are two theoretical kernel architectures: Microkernel, and monolithic kernel.

    The primary advantage of a monolithic kernel is performance. All modern operating systems a monolithic kernels [1]. The big advantage of a microkernel is security.

    With a monolithic kernel, almost everything runs privileged, in the kernel. Hardware interactions, drivers, firewalls, various processes. The big disadvantage of this, is that if any of those components have a bug and crash, it bluescreens.

    The best example was the crowdstrike blue screen of death issues: https://en.wikipedia.org/wiki/2024_CrowdStrike-related_IT_outages . Crowdstrike runs at the kernel level (kind of like kernel level anticheat), and it had a bug, causing BSOD’s everywhere. Of course, this is a fairly drastic example. Anecdotally, I have noticed in an increase in random BSOD’s from people who have kernel level anticheat installed. Of course, the average user never whines and you have to pull this out of them, they just treat this as “normal”.

    With a microkernel, things are different. Everything is separated out, running as less privileged processes. This has big security implications since, it means that pwning one component of the Linux kernel, wouldn’t own the whole kernel. That has been how so many of the recent Linux kernel root exploits have happened, where subsystems, rather than the entire kernel are vulnerable. With a microkernel, the possibility of an exploit in say, the containerization/sandboxing features, wouldn’t lead to a root exploit on the host. SImilarly, components like device or filesystem drivers could be put in userspace as well, enabling much better security and isolation.

    [1], well, sometimes people try to argue that the difference between a microkernel and a monolithic kernel is about codebase organization, optimizing for development velocity. Windows, and Mac are called “hybrid kernels”, because the core kernel code is separated from things like drivers, enabling people to develop them separately. This used to be a bigger deal back in the day, since it enabled faster development for things like peripherals.

    But there is no security or correctness benefit, so I consider them a monolithic kernel. In addition to that, “true” monolithic kernels (like Linux) have since innovated. While being open source may not be a big deal to us today, it was an innovation on it’s own, that enabled people to include the firmware/drivers in the kernel directly (albeit, sometimes as binary blobs distributed in linux-firmware). In addition to that, there is also dkms for loading out of tree kernel modules, or epbf which enables you to run arbitrary code with ring 0 level privileges… but in such a way that it also doesn’t hard crash the system when there is a bug.


  • Yes, although there have been a few CVE’s related to escalating privileges or breaking out of the sandbox. You’re going to want to keep those updating and keep on top of those.

    There is one concern, in that the nix store (/nix/store) is world readable. It is not world writable, which is good, but there is a problem in that secrets can potentially be copied into the nix store. If you copy a file containing environment variables or the like into the nix store, it could theoretically be found it. This one is on the users of nix to be careful of.

    With Nix flakes, the entire git repo that the flake originates from is copied into the nix store. Meaning if you have a nix flake in something that is supposed to be a private repo, or contains tracked sensitive data (untracked files are not copied into the nix store), then it could be found and inspected by other users.

    My big concern with multi user in this case is not merely the Nix daemon though, but also Linux itself. Linux has been hit with a LOT of privilege escalation and container escape issues over the past few years, and many of them have been zero day’s. Given this, I no longer really have the same level of trust for Linux with regards to multi user isolation, for in cases like these.

    Of course, in academic computing, I would probably just do multi user anyways, for simplicity. If you install tracking and monitoring, then you can attach malicious actions to identities. Because every user is registered and operates within the institution, if they break the terms of use for computing equipment, then you can punish them within the institution, or pursue greater legal action.

    And then, you also would want to enforce 2FA to help minimize stolen accounts. While that can still be phished via fake login pages that ask for 2FA, it handles most of the things. Isolate the server via firewalls, and then it becomes a small enough target that doesn’t have enough value (assuming of course, your research isn’t too valuable and worth targeting), and you mostly don’t have to worry about it.

    Sure, people will root it. But then they’ll send you a nicely worded email explaining how they rooted it and how to fix it. Which is what my friend did at my school, on our shared ssh server. Just keep it updated to handle the low hanging fruit.

    However, if you are going to give it to untrusted users with unknown or temporary (not within the institution) identities, then things change, and you have to take it a lot more seriously. I no longer have confidence in just Linux’s user based isolation.

    The first line solution I would go to, is to put users in containers and mount the nix store (and nix daemon) in and out. Something like a docker/podman container or Incus container. Of course, container escapes are still possible. If you are even more concerned about those, then you would want virtual machines. It is still possible to share the nix store between virtual machines, but it is more complicated.

    In addition to that, virtual machines have a performance tradeoff (usually 95% or more of the host’s performance though), but there might be issues with sharing GPU compute resources among virtual machines, depending on the hardware you are using. Enterprise GPU’s usually support it though.







  • the physical display output is claimed by something else totally separate.

    Yes, and the above solution I laid out is a way to get around that, that potentially dodges the complexity of configuring a truly headless session. It’s possible to run two KDE sessions at once, next to eachother, and then simply put one on the main display, with the second being “headless”, and not shown.

    I started fiddling with the above setup I described, actually installing and testing sunshine. Unfortunately I hit some hiccups. I got sunshine to run, but with no input, and then then it attached to the wrong KDE, even though it was streaming the correct one initially. Now I’m running the same KDE session as a different user (since I was on the same user before), but having pairing issues, but I suspect these are because moonlight is seeing the wrong SSL cert, since the sunshine as a new user generated a new cert.





  • If you log in (preferably as another user) to another tty (Cntrl + Alt + F2/3/4/5), and then run dbus-run-session startplasma-wayland, does that work?

    Sometimes just startplasma-wayland works, which used to work for me but didn’t work for me this time.

    Then, you should be able to switch back to the original KDE session, which continues to work normally, at least it does for me. Both sessions should have shared access to the GPU, as well. You can then probably run sunshine in that second instance of KDE, while the monitor can be attached to tty1 or tty2, whichever one is the default where KDE is put.

    Then, you would probably want to configure sunshine to work even when the screen is locked, that way you can lock the second session with Win + L, but it can still be interacted with remotely via sunshine.

    EDIT: I only am somewhat confident that this setup will work, I haven’t tested it personally.


  • Debian has old software and doesn’t support some newer hardware. Even the latest version, Trixie, is still very far behind. I realize this now.

    Debian has backports, which enable you to get select versions of newer software. Relevant to your case, you can get a newer version of the kernel, drivers, and other things relevant to hardware support.


  • Might be a bug, so we can troubleshoot to try to figure it out.

    If you visit about:processes, is there any website or extension taking up a lot of system resources?

    In addition to that, you can try launching firefox in safe/troubleshooting mode. 3 bars in the top right > Help > Troubleshooting mode

    This restarts firefox with all addons, extensions, and themes disabled.

    For further troubleshooting, also try:

    Go to about:profiles, and create and launch a new one. This is a more complete reset, since it also resets all settings, about:config options, and similar.

    After creating a new profile, you can play around with rebuilding your current firefox config, adding extensions and changing settings.