I don't like the less serious licenses because they often don't explicitly declare that your software is distributed with no warranty.

This makes you liable to be sued in certain jurisdictions, where simply distributing software is assumed to also provide support, or you could be held responsible for damage it causes or misuse.

Of course, the chance of someone suing you is extremely slim. And courts are ran by humans, who can interpret the spirit of the law, rather than the letter, so I would hope they would be gracious and understanding of the open source model. But it's better to just not take chances.

Good practice exams will often be harder than the original test. Teachers do this in order to ensure you are prepared. If the practice test is harder, then the real test is easy. This is a pattern that I have noticed even in my college classes.

n reddit (ew) discussions are always making it like some terrifying thing.

To someone that doesn't know that they are using Windows, yes, the tests will be terrifying and difficult to study for. Often people are scared of computers and technology, and actively avoid knowing. But now, they will essentially have to cram a massive amount of information, since they are starting from scratch. And for those trying to break into cybersecurity from nothing, that is a common scenario.

For people who already know what a virus is, and how to spot phishing links, the test will be a lot less of a struggle. Now, you should study, in order to figure out gaps in your knowledge compared to what sec+ covers, but it won't be a nightmare.

clicks profile

Love computers, art, and nature.

You actively like computers instead of being scared of them. So I don't think you'll find the test terrifying.

No, it would actually be quite easy to spot.

Nixpkgs templates the source code url fro the url, and then it injects a variable

Here is an example from bash:

pname = "bash${lib.optionalString interactive "-interactive"}";
    version = "5.3${fa.patch_suffix}";
    patch_suffix = "p${toString (builtins.length upstreamPatches)}";

    src = fetchurl {
      url = "mirror://gnu/bash/bash-$%7Blib.removeSuffix fa.patch_suffix fa.version}.tar.gz";
      hash = "sha256-DVzYaWX4aaJs9k9Lcb57lvkKO6iz104n6OnZ1VUPMbo=";
    };

If the url were to be changed, it would show up as a change in git when someone is reviewing before merging.

In my testing, zram has much, much better compression than zswap.

The points about LRU inversion, cgroups, and so on are valid, but at the end of the day, I don't really care. I was able to open as many firefox tabs as I wanted with zram, but I could not do so with zswap, and that's what matters to me.

The author of a blogpost is a facebook engineer. Millions of ultra high performance Linux servers are a very different usecase than a single desktop. It's perfectly reasonable for a solution for one to not be appropriate for the other.

For maintenance I would recommend a ticketing system instead of forgejo:

https://selfh.st/apps/?search=ticket

There are a few options and they probably all work better than a git issue tracker.

Another thing I would recommend is to have centralized accounts via an identity provider. People have one username and password they can use to log into all the services, and you can reset/signup them to all connected services by managing the identity provider app.

There are a few options for this as well but I'm on my phone some imma just list the three that I find most promising for your usecase: kanidm, voidauth, authentik.

Because you can run a "rootfull xwayland" session which is essentially an X11 session but rewritten to be more maintanable.

After this, it's a lot harder to be opposed to the loss of X11, because you don't really lose it.

It actually is a language issue.

Although rust can dynamically link with C/C++ libraries, it cannot dynamically link with other Rust libraries. Instead, they are statically compiled into the binary itself.

But the GPL interacts differently with static linking than with dynamic. If you make a static binary with a GPL library or GPL code, your program must be GPL. If you dynamically link a GPL library, you're program doesn't have to be GPL. It's partially because of this, that the vast majority of Rust programs and libraries are permissively licensed — to make a GPL licensed rust library would mean it would see much less use than a GPL licensed C library, because corporations wouldn't be able to extend proprietary code off of it — not that I care about that, but the library makers often do.

https://en.wikipedia.org/wiki/GNU_General_Public_License#Libraries — it's complicated.

EDIT: Nvm I'm wrong. Rust does allow dynamic linking

Hmmmm. But it seems that people really like to compile static rust binaries, however, due to their portability across Linux distros.

EDIT2: Upon further research it seems that Rust's dynamic linking implementation lacks a "stable ABI" as compared to other languages such as Swift or C. So I guess we are back to "it is a language issue". Well thankfully this seems easier to fix than "Yeah Rust doesn't support dynamic linking at all."

Edit3: Nvm, I'm very, very wrong. The GPL does require programs using GPL libraries, even dynamically linked, be GPL. It's the LGPL that doesn't.

Use cockpit by Red Hat. It gives you a GUI to make networking changes*, and will check if the connection still works before making the change. If the connection doesn't work (like the ip addresses changed), it will undo the change and then warn you. You can then either force the change through or leave it be.

*via NetworkManager only.

Yes. It's a frontend for twitter, based on nitter.

It's similar to invidious for youtube.

How to improve Python packaging, or why fourteen tools are at least twelve too many

Still relevant.

Spent

A short questionaire game that demonstrates the difficulties of poverty.

Was watching a twitch streamer learning linux, and chat convinced them to open vim for the first time. Not a single person gave the real answer of how to exit, all joke answers like "Power off," and it was hilarious.