• 0 Posts
  • 7 Comments
Joined 3 years ago
cake
Cake day: June 19th, 2023

help-circle

  • It’s a weird time to live in, but not confusing. It’s obvious to see that what you really want as a vendor is control over the operating system stack itself, and relying on Microsoft has become challenging.

    In essence what NVIDIA is doing is bringing it’s entire GPU driver stack open source side, so that entire industries say go on buying tons more hardware.

    Us Linux enthusiasts get to reap the benefit, what with entire open source movements bringing libraries to Linux side first that can turn GPU hardware into whatever tool you’d like. Projects like PyTorch and ffmpeg run as first class citizens on Linux.

    Windows still relies on either shared DotNet stack (which will make a monkey out of you - cough cough) or the nearly ancient MSYS2 build environment. Microsoft of course prefers you run all that software inside their Linux container system known as WSL - and there’s a reason for that.

    The Linux graphics stack is looking more “feature complete” by the month, bringing up the question of where you actually get the best hardware support. This is a good question to have.

    Now, if only the open source desktop movements could clean house, figure out funding and get their stacks in order, we might finally, for the umpteenth time, maybe see the year of the Linux desktop.

    I grow old with anticipation, but seeing what NVIDIA did in the before time versus what they do in the now puts a smirk on this haggered face.

    Onwards to the future.


  • Say it with me now: local AI, local AI… or fuck off.

    That being said, ARM laptops and probably even workstations are the future, and so is RISC-V. I suspect we’ll see more tensor cores or AI related processing built-in to the SoC’s.

    If it’s then only a question of hardware enablement and a software companion to go along with it, I’m all for it.

    Go Mozilla…! But again: local AI, or fuck off.



  • Well technically, if you’re using BTRFS, you might want to check out subvolumes. Here’s my subvolume setup:

    • Subvolume 1, named @ (root subvol)
    • Subvolume 2, named @home (/home subvol)
    • Subvolume 3, named @srv (/srv subvol)
    • Subvolume 4, named @opt (/opt subvol)
    • Subvolume 5, named @swap (which is - you guessed it - the swap subvol)

    You then set up fstab to reflect each of the subvolumes, using the subvol= option. Here’s the kicker: they are all in one partition. Yes, even the swap. Though caveat, swap still has to be a swapfile, but in its own separate subvolume. Don’t ask me why, it’s just the way to do it.

    The great thing about subvolumes is that it doesn’t do any size provisioning, unless specified by the user. All subvolumes share the space available within the partition. This means you won’t have to do any soul searching when setting up the partitions regarding use of space.

    This also means that if I want to nuke and pave, I only need run a BTRFS command on my @ subvolume (which contains /usr, /share, /bin), because it won’t be touching the contents of @home, @srv, or @opt. What’s extra cool here is that I’ll lose 0% FS metadata or permission setup, since you’re technically just disassociating some blocks from a subvolume. You’re not really “formatting”… which is neat as hell.

    The only extra partitions I have is the EFI partition and an EXT4 partition for the /boot folder since I use LUKS2.