guix and/or nix
Both are functional package managers and manage dependency trees better than flatpak IMO (also the package description languages mean you can manipulate the package definitions at install time much easier)
If you can’t find a package in guix/nix then it behooves you to use flatpak
Some additional nice things about guix:
Everything is guile. The system definition, the service definitions for shepherd, everything.
Shepherd is hands down the best init program I’ve ever used. It’s just incredibly simplistic but because it just runs the guile definition you give it, you can do some incredibly complex things that systemd etc. can do as well.
The OS documentation is built into the distro, with “info guix” you get reams of configuration information for the distro without ever needing to look it up online.
About a year and a half.
To be honest it’s not “easy” to use. The guiding principle behind mainline packages is that everything has to be built from source, so most somewhat unpopular things are missing from the mainline channels.
To use it like any other distro you’re going to need to learn how to write packages fairly quickly. Luckily the main draw of guix is the entire OS being based on guile so once you get a little under your belt you can just read the specs from other channels to see how a package is written.
Took me maybe a week to start writing guix packages.
There’s also The toybox
Guix because I love the idea behind Nix but Nixlang is the most painful language I’ve ever had to type out.
The leadership response to this and the subsequent backlash is starting to remind me of the NixOS debacle from about a year ago.
That resulted in the project being split and like 30% of the community moving off and creating Lix.
I would be disappointed, but not surprised, if we see something similar in the Kernel sometime in the next year or two…
I’m not surprised by this.
The general attitude around R4L is that it’s largely unneeded and for every 1 person actively working against the project, there are 10 saying either “waiting and seeing if it works is the right decision” or “if rust is so good they should prove it.”
So as a R4L developer you’re expected by the community to fight an uphill battle with basically no support on your side.
We will likely keep having developers on that project continue to burn out and leave until the entire thing collapses unless the decision is made ahead of time to cancel the project.
Every time I read any news about Rust for Linux I leave disappointed by the entire kernel community.
I can understand their frustration, having multiple other rust for Linux project maintainers quit over nontechnical rust aversion.
And Linus continues to (democratically?) avoid the subject with this response.
As a rust for Linux volunteer you have to be incredibly demoralized reading this mess almost every other month.
bc
It’s a simple command line calculator! I use it all the time.
I love locate! I have a cronjob that updates the db every night, then I can just find a file without having to think about where it is
Somebody hit the token chain jackpot
What’s great about lawsuits like this is you really only have to prove intent and they have a record of them asking for similar imagery.
Isn’t fusion power not as clean as people say it is?
The Practicalities of actual fusion reactors make this seem a lot less appealing than I think I grew up hearing.
I’m happy to see china continue to pump resources into their clean energy mix, but at the same time it feels like this entire concept might end up being more of a meme than we think.
They can’t form new trade unions because everyone already has to join a registered trade union.
Most data centers evaporative cooling from what I understand, and according to This
Cooling towers use water evaporation to reject heat from the data center causing losses approximately equal to the latent heat of vaporization for water, along with some additional losses for drift and blowdown. In larger data centers this on site water consumption can be significant, with data centers that have 15 MW of IT capacity consuming between 80-130 million gallons annually. n this study, on-site water consumption is estimated at 1.8 liters (0.46 gallons) per kWh of total data center site energy use for all data centers except for closet and room data centers, which are assumed to use direct expansion (air-cooled chillers).
And seeing as hyperscale data centers usually use between 20-50 megawatts per data center, and there’s three of them in Colon, that’s like at least 240 million gallons of water a year.
Yikes.
> Kinito Pet now playable
How the fuck is that gonna work
For the usability of the clock, likely nothing.
I did mention In another comment that there are a number of advantages a round clockface provides to the creation of the clock, however.
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
Did the room just get a bit colder or is it just me