Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)D
Posts
0
Comments
209
Joined
3 yr. ago

  • Personally I have seen the opposite from many services. Take Jitsi Meet for example. Without containers, it's like 4 different services, with logs and configurations all over the system. It is a pain to get running, as none of the services work without everything else being up. In containers, Jitsi Meet is managed in one place, and one place only. (When using docker compose,) all logs are available with docker compose logs, and all config is contained in one directory.

    It is more a case-by-case thing whether an application is easier to set up and maintain with or without docker.

  • Saving on some overhead, because the hypervisor is skipped. Things like disk IO to physical disks can be more efficient using multikernel (with direct access to HW) than VMs (which have to virtualize at least some components of HW access).

    With the proposed "Kernel Hand Over", it might be possible to send processes to another kernel entirely. This would allow booting a completely new kernel, moving your existing processes and resources over, then shutting down the old kernel, effectively updating with zero downtime.

    It will definitely take some time for any enterprises to transition over (if they have a use for this), and consumers will likely not see much use in this technology.

  • With a custom, very restrictive license. Builds are not reproducible, and code from the project cannot be used elsewhere. For the purposes of security, transparency, and advancing development of (proper) FOSS YouTube clients, Grayjay is effectively closed source.

  • SSH in from another machine, and sudo dmesg -w. If the graphics die, it can't display new logs on the screen. If the rest of the system is fine, an open SSH session should give you more info (and allow you to troubleshoot further).

    You can also check if the kernel is still functional by using a keyboard with a caps-lock LED. If the LED starts flashing after the "freeze", it's actually a kernel panic. You'll have to figure out a way to obtain the kernel panic information (like using tty1).

    After the "freeze", try pressing the caps-lock key. If the LED turns on when pressing caps-lock, the Linux kernel is still functional. If the caps-lock key/LED does not work, the entire computer is frozen, and you are most likely looking at a hardware fault.

    From there, you basically need to make educated guesses of what to attempt in order to narrow down the issue and obtain more information. For example, try something like glxgears or vkgears to see if it happens with only one of those, or both (or neither).

  • it seems a bit pointless

    Quite the opposite. Linux is currently frequently matching Windows in performance when running games through Wine/Proton. Targeting Linux native avoids this translation layer, and can result in better performance or less CPU overhead for the same performance (which is noticable especially on devices like the Steam Deck).

    making games for Linux is ironically difficult

    Yes, because of the tooling. If you make a game in Unity, and build for Windows, ""things just work"". If you then build for Linux, you can face any number of random engine issues, like bad controller support, broken mouse grabbing, etc.

    as they can break as libraries change over time

    Valve has thought about this, and designed the Steam Linux Runtime. This does effectively the same thing as Flatpak, except it pulls in the system native graphics drivers. Steam Linux Runtime provides effectively a full (minimal) Linux distribution that game developers can target, ensuring their games keep running, even on more modern systems.


    Gaming on Linux has always been a chicken and egg problem. Gamers see there's no games on Linux, so they stick to Windows. Developers see there's no Linux gaming market, so they stick to Windows. With Valve's Proton, they interrupted this cycle. Most games now work on Linux, but game developers haven't switched yet. For them to switch, there needs to be a market of Linux users, and the tooling needs to be sufficiently developed for Linux, ensuring the same (or better) quality as the Windows versions of games. This includes game engines, common libraries (like online multiplayer frameworks or voicechat), and possibly development software, 3D modeling software like Blender, the Adobe suite, etc.

  • Security is an insanely broad topic. As an average desktop user, keep your system up to date, and don't run random programs from untrusted sources (most of the internet). This will cover almost everyones needs. For laptops, I'd recommend enabling drive encryption during installation, though note that data recovery is harder with it enabled.

  • "jellyfin isn't immune to security incidents"

    Well, no software is. The difference is that Plex just leaked data of all there users, where Jellyfin can't, because they don't have this data.

  • IRC does not have any federation, and XMPP does it in a completely different way from Matrix that has unique pros and cons.

    IRC is designed for you to connect to a specific server, with an account on that server, to talk to other people on that server. There is no federation, you cannot talk to oftc from libera.chat. Alongside that, with mobile devices being so common, you'd need to get people to host their own bouncer, or host one for nearly everyone on your network.

    XMPP federation conceptually has one major difference compared to Matrix: XMPP rooms are owned by the server that created them, whereas Matrix rooms are equally "owned" by everyone participating in it, with the only deciding factor being which users have administrator permissions.

    This makes for better (and easier) scaling on XMPP, so rooms with 50k people isn't that big of an issue for any users in that room. However, if the server owning the room goes down, the whole room is down, and nobody can chat. See Google Talk dropping XMPP federation after making a mess of most client and server implementations.

    On Matrix, scaling is a much bigger issue, as everyone connects with everyone else. Your single-person homeserver has to talk with every other homeserver you interact with. If you join a lot of big rooms, this adds up, and takes a lot of resources. However, when a homeserver goes down, only the people on that homeserver are affected, not the rooms. Just recently, matrix.org had some trouble with their database going down. Although it was a bit quieter than usual, I only properly noticed when it was explicitly mentioned in chat by someone else. My service was not interrupted, as I host my own homeserver.

    The Matrix method of federation definitely comes with some issues, some conceptually, and some from the implementation. However, a single entity cannot take down the federated Matrix network, even when taking down the most used homeservers. XMPP is effectively killed off by doing the same.

  • GNOME devs simply can't "tolerate" SSD, and force CSD in every scenario for GTK4. My machines running Wayland only have CSD for fully custom apps (like Steam) and every GTK4 app.

  • To answer the question in the title: No, because these systems inherently have different architecture. Something like OpenBSD (the OS) is relatively self-contained. Linux distributions have system components that are externally developed, but a user might rely upon.

    What exactly is the "problem" you have with Linux package managers? It's specifically extra complexity to separate "system" and "packages". This works well for *BSDs that often develop the entire OS themselves, but would pose extra challenges for Linux distributions, where the line between "OS" and "user installed package" is much more blurred.

  • This type of shit happens if you intentionally mess up your own system (or use Manjaro). pacman requires extra confirmation (instructions only found in its man page) before even allowing you to delete bash (base requires it). bash has also never been replaced, and even if you deleted it, it would still be loaded in RAM. Even still, if you deleted it and immediately rebooted, it would be a quick fix for anyone familiar with the distribution they're using, and would not require reinstalling the whole thing.

  • Since lowercase y as an option to uppercase S already exists to update the database, --noconfirm exists to continue without user confirmation.

  • Yes. -Syyu is for "Sync (repository action), database update (forced), upgrade packages", in that order (though the flags don't have to be). Doubling a lowercase character like yy or uu is to force the operation. yy in particular shouldn't be needed, as it only overrides the "is your database recent" check. Unless you're updating more than every 5 minutes, using a single y is perfectly fine.

  • Discord is one of the greedy AI companies training on your data

  • FOSS only, no proprietary spyware here. Daily driver on Android 15.

  • Being able to choose the OS and kernel is also important. I would not want my hypervisor machine to load GPU kernel modules, especially not on an older LTS kernel (which often don't support the latest hardware). Passing the GPU to a VM ensures stability of the host machine, with the flexibility to choose whatever kernel I need for specific hardware. This alongside running entirely different OSes (like *BSD, Windows :(, etc) is pretty useful for some services.

  • Same here, though more out of lack of control over the host. Libvirt works on basically any distro, and you can easily configure whatever Linux distro you like best for running it. I can't configure my boot process the way I want on Proxmox (at least not without learning/sidestepping its "convenience" tools/setup).

  • Looking at this, I'd personally delete both EFI and boot partitions, then remake them with the EFI partition significantly smaller (it should not exceed >100MB used). I have no idea what issues this would cause on Debian, and what specific configuration needs to be changed/updated. I'd guess you need to change the fstab entries, remake the initrds, and reinstall/reconfigure the bootloader.

    Any manual messing with partitions, especially rootfs/boot/efi, can easily lead to a broken system. The fix will not be a simple procedure.

    As you're considering messing with your rootfs, I'm going to assume you have a backup. It'll be significantly easier for you to wipe everything, install fresh new Debian, and copy your personal files over to the new installation.

  • If you're this unsure about running potential malware in a VM, the best method is to just not run it at all.

    You should be perfectly fine running with networking on your host, as long as you disable it in the VM configuration before running the potential malware.