• 0 Posts
  • 16 Comments
Joined 9 months ago
cake
Cake day: December 16th, 2023

help-circle

  • WalnutLum@lemmy.mltoMemes@lemmy.mlZen Z
    link
    fedilink
    arrow-up
    4
    arrow-down
    1
    ·
    1 month ago

    It floors me just how many people in this thread feel like analog clock reading is a useless/outdated skill.

    But I’m of the opinion that there’s no such thing as a truly outdated and useless skill, so I’m not sure I have the capability to empathize with those people…


  • You can use nix alongside guix, it’ll just double-up the dependencies on disk:

    services (append (list (service nix-service-type))
                        %base-services)))
    

    Services are, in guix terms, any configuration change to a computer, so creating your own service 99% of the time is just extending etc-service-type and creating a variable interface to fill in the config file text yourself

    Creating a service as in a daemon of some kind uses shepherd and involves extending shepherd-service-type or home-shepherd-service-type with your service description, depending on whether the service runs in root or user space.

    Shepherd service configurations aren’t actually part of the guix spec(https://www.gnu.org/software/shepherd/manual/shepherd.html#Defining-Services), but still use Guile, so you can interoperate them super easily.

    It’s important in guix to understand lisp pretty thoroughly, and knowing how to program lisp is still a very useful skill to have so I’d recommend learning it even if you never touch guix.


  • I use guix because, while it has a small community, the packaging language is one of the easiest I’ve ever used.

    Every distro I’ve tried I’ve always run into having to wait on packages or support from someone else. The package transformation scheme like what nixos has is great but Nixlang sucks ass. Being able to do all that in lisp is much preferred.

    Plus I like shepherd much more than any of the other process 0’s








  • There’s a weird implicit conservancy in tech circles around the dictatorial nature of corporate leadership.

    It stems from this weird externalization of corporate decision making that just turns everything that happens at large companies into the machinations of the unknowable machine of capital.

    “Of course they were fired, they protested in a way that disrupted the business, if the business is disrupted the machine must correct itself, and it did so by releasing the corporate anti-bodies of leadership to fire the disruptive element. Thus the machine is corrected. This is all logically sound, and thus impervious to moral inquisition.”



  • This feels like the same kind of issue mesa just had around the zlib update breaking downstream user programs (viewperf). If there are significant downstream issues for users you shouldn’t upgrade, even if that is the end goal.

    Projects that are big and important get old and bloated because they need to try and span legacy issues alongside their attempts at newer paradigms. It’s just kind of the natural lifecycle of these projects.