I understand the general job market, but what about lisp prevents you from pursuing personal ventures with it?

Yeah Clojure is like the monkey’s paw of Lisp weenies. It adds many modern day niceties that are lacking in standard Scheme or Common Lisp, but also changes enough things to make it feel very un-lispy. I go back and forth as to whether or not I even consider it Lisp (Richard Stallman doesn’t).

But I do know that I’d rather write Clojure than any other non-lisp language.

I’d also recommend people try ABCL, which is Common Lisp on the JVM , or Parenscript which is Common Lisp that compiles to Javascript.

Lisp

It solves so many problems new languages have been invented to try and solve, while being simultaneously simpler than most

Try Orgzly with Emacs Orgmode

emacs org-mode publish

https://orgmode.org/worg/org-tutorials/org-publish-html-tutorial.html

M-% NixOS RET Guix RET !

But yes 80% of my comment applies to Nix as well, as of course Nix is older and Guix is (conceptually) based on Nix. Though I personally use/prefer Guix.

Yes GNU Guix is a linux distro.

The package manager for Guix (also called guix) is also a portable package manager which works on any linux distro, similar to flatpak, nix, homebrew, etc.

Guix’s claim to fame is that it is a functional distro/package manager, meaning that all changes are atomic, so installing/upgrading/deleting packages never leaves your system in a broken state.

Not only that, but if you make some change to your system and it breaks for normal reasons (e.g. newest software version has a bug), you can roll back to your previous system state with all your previous packages and their versions, and this roll-back operation is also atomic.

Guix the distro not only let’s you do package management this way, but also let’s you do declarative system configuration. This means rather than manually rummaging around /etc changing files and hoping nothing breaks, there’s simply a single config file which declares all of your system configuration. From your kernel to users, partitions, system services, and just about anything else, all the configuration is declaratively done in one place with one language (Guile Scheme). Any changes you make to your system this way are also of course atomic and can be rolled back.

It even comes with a built in system called guix home which lets you bring that same level of declarative, atomic configuration to your user’s home environment, letting you manage user level packages, dotfiles, env variables, and more with a single home configuration file.

There are other goodies too, such as the ability to spawn one-off shell environments with the guix shell command, dropping you in a shell with all the packages and env variables you declare, keeping your regular user environment clean (very nice for development).

There’s even more, but at this point if you’re still interested just head over to the site and the docs.

codeberg

it’s like github but non-corporate free software

it’s very polished and featurful

it’s built upon/by the same devs as forgejo, which is open tech to self host your own git server (with federation potentially coming), so supporting one supports the other

If I understand you correctly, this is trivial in emacs:

(defun insert-text ()
  (interactive)
  (insert "your text here"))

(global-set-key your-keybind-here #'insert-text)

You could make it a format string if it relies on data specific to some file or parameter. You could also make the keybind local to certain modes/files rather than a global keybind if you don’t want to pollute your keybind space.

emacs org-mode

guix home reconfigure home-config.scm

Metroidvanias of knowledge a la Outer Wilds

Have you heard something recent? I feel Signal has been saying that for years now.

I don’t care about XMPP as a protocol versus some other messaging protocol much, but I care a fair bit about the wdespread adoption of federated XMPP

I don’t quite understand what this means, could you elaborate?

if this service using this protocol becomes very popular, will the service seek to eliminate the open role of the protocol

That is a valid concern, though the point of the article is to try and convince people why it won’t happen like it did with Google or might with Meta for structural reasons (rather than “oh but we’re different” reasons).

The main difference I see with Snikket vs Google Talk is that Snikket is not only libre client software, but libre server software as well. The point of Snikket is that individual people host it themselves, not that the Snikket devs run a bunch of Snikket servers which require their Snikket client for connection and just so happen to use xmpp to power it. Really all Snikket is (right now) is a prosody server with some pre-configurations and easy install, as well as an android/ios app which are general xmpp clients that are designed to work well when connected with Snikket servers.

Now it could still go south in a similar way to Google Talk, in that maybe a bunch of people start running Snikket servers and using Snikket clients, and then the Snikket devs start wall gardening the implementation. That would be bad, but the users (both server runners and client users) would be in a much stronger position to pivot away from those decisions.

I think it’s at least an interesting idea (hence why I posted it) for the reasons the author mentions: striking a balance between trustless freedom and interface stability/agility.

That sounds roughly correct, though I don’t see the connection with the article? Unless you’re saying that “products” (like Signal) will always exist, which is probably true but is orthogonal to whether or not other models will succeed.

As for email, I think posteo does a pretty good job, but you’re right options are few and far between. But self hosting email is just as viable as ever? Perhaps less so since e.g. gmail will instantly flag your incoming mail as spam if you’re sending it from randomsite.tld, but honestly that issue hasn’t gotten that bad (yet). Yes, whenever there’s a protocol like email or xmpp, companies will create gmails and signals and turn them into walled gardens, but that doesn’t spoil the protocol for everyone else. It just causes frustration that companies build closed products on top of open technologies, but not much to be done about that.

Interesting, what made you switch? I’ve never used nix but they are very similar.

Care to point me towards these lemmy guix posts?

Thanks! I’ve changed quite a few things in my setup over the years, but gruvbox is one of the very few mainstays (that and mpv).

Yep! If you’re applying and need a non-trivial number of locations checked/maps generated, you can check out the prgoram here.

Note that it says you can install it with guix, but it hasn’t actually been merged into master yet, so for now you do need sbcl and the dependencies (etiher via quicklisp or however else you snag them).

You can mount any directory you want as the “home” directory of a given container with distrobox, it just defaults to using your home directory.

Thanks for the response! Flathub is a fantastic project so glad to hear about your contributions. Your videos have been helpful for me as introductions to Silvelblue ideas and statuses.

I don’t have much to say about the term “cloud native” personally, it doesn’t seem too important. I think myself and others react against it because cloud tech is mostly used by businesses and “server people” to deliver products (sometimes at the cost of user freedom), and so has either a non or negative connotation in the FOSS linux desktop space. But names are names, and accuracy matters most. I don’t think etiher “cloud native” or “immutable” are really all that helpful as technical terms though, maybe something else should be used (image based, atomic, container centric, ?).

I’m not sure I understand “distros already have htop.” Distros already have everything packaged for flatpak, yet they were packaged for flatpak. The real question is why do flatpaks exist at all if you can just run programs in containers, OR why do containers exist at all if you can just run programs as flatpaks (assuming everything we wanted were available as a flatpak). That is: what are the technical / UX reasons to choose flatpak over containers and vice versa?

Podmansh looks very cool! That’s definitely the direction I’d like to see these sorts of projects moving in. The #1 issue I have at the moment with this OS model is customization/tinkering/hackability. I want to have the niceties of atomic updates and reproducible builds, and containers on their own are great. But not if it takes away my ability to make my system fit my needs. I have no interest in using a macbook.

The future of these technologies looks bright, and they are clearly functional today, but I’m not sure any of them meet my needs yet as someone who likes to have a great deal of control and understanding of my system.