I would vote for docker as well. The last time I had to inherit a system that ran on virtual machines, it was quite a pain to figure out how the software was installed, what was where in the file system, and where all the configuration was coming from. Replicating that setup took months of preparation.

By contrast, with Docker, all your setup is documented. The commands that were used to install our software into the virtual machines and were long gone are present right there in the Docker file. And building the code? An even bigger win for Docker. In the VM project, the build environment for the C++ portion of our codebase was configured by about a dozen environment variables, none of which were documented. If it were built in Docker, all the necessary environment variables would have been right there in the build environment. Not to mention the build commands themselves would be there too, whereas with VMs, we would often have developers build locally and then copy it into the VM, which was terrible for reproducibility and onboarding new developers.

That said, this all comes down to execution - a well-managed VM system can easily be much better than a poorly managed Docker system. But in general, I feel that Docker tends to be easier to work with than a VM. While Docker is far from flawless, there are a lot more things that can make life harder with VMs, at least from my experience.

Do you know how vim has distributions like lunarvim, lazvim, nvchad, etc.? Simply installing something like lazyvim can quickly and easily convert vim from a text editor to a full blown IDE.

I think Gnome needs something like this. A curated set of plugins that are easy to install and maintain compatibility with different versions of Gnome - something that would deal with the API churn in Gnome while maintaining a stable, usable desktop environment.

I don’t know if this is feasible, because I haven’t used Gnome since 2.x, but I think it would really help make it an actual full blown DE.

Just in case this comment didn’t make it explicitly clear, you can just invoke the python binary inside your venv directly and it will automatically locate all the libraries that are installed in your virtual environment.

To show how this works, you can look at the sys.path variable to see which paths python will search for modules when you run import statements. Try running python3 -c 'import sys; print(sys.path)' using your system python, and you will only see system python library paths. Then, try running it again after replacing python3 with the full path to the python3 binary in your venv, and you will see an additional entry in the output with the lib directory in your venv, which shows that python will also look there for modules when an import statement is executed.

If I want to make a piece of software to improve people’s lives and I don’t care to do it for free, I’ll choose MIT. If it gets “stolen” by a for-profit corporation it only makes it better, because now my software has reached more people, thus (theoretically) improving their lives.

I’m not completely sure about this.

Suppose you write a library that a company like Facebook finds useful. Suppose that they incorporate it into their website. I’m sure I can skip the portion of this post where I extol the harms that Facebook has wrought on society. Do you think your software has improved people’s lives by enabling Facebook to do those sorts of things? They would not have been able to do them if you had used AGPL instead.

And I don’t want to make it seem like we should never do anything because someone might use the product of our work in a sinister way (because that would quickly devolve into nihilism). If 99 people use it for good and 1 for evil, that’s still a heavy net positive. But at the same time, I would be lying if I didn’t acknowledge that the 1 person using it for evil still would make me feel bad.

I was surprised that comment this got so many upvotes, so I’ll respond by saying that, with all due respect, I think your argument is much more fallacious than the one you are trying to debunk.

The comic author takes one specific case of an MIT licensed product being used in a commercial product, and pits it against another GPL product.

Yes, this is called an example. In this case, the author is using a particularly egregious case to make a broader conclusion: namely that if you release software under a “do whatever you want” license, it may come back to bite you in the future when it’s used in a product that you don’t like.

This comic is a warning to developers that choosing MIT/BSD without understanding this fact is a bad choice.

This ignores situations where MIT is the right answer, where GPL is the wrong one

It does not ignore those situations. All situations are multifaceted and need to take multiple considerations into account. The author is trying to argue that people should take care not to overlook the particular one to which he is trying to draw attention.

situations where legal action on GPL violations has failed

Just because legal efforts have failed does not mean that they are not worthwhile. There may be many cases where people avoided misappropriating GPL software because they did not want to deal with the license - there may be cases where people were less hesitant about doing so with MIT/BSD because they knew this risk was not there.

From that I conclude that this falls under The Cherry Picking Fallacy. While humorous, it’s a really bad argument.

Just because the author used a single example does not preclude the existence of others. That is a much more fallacious assumption that invalidates much of your argument.

and all cases where the author’s intent is considered (Tanenbaum doesn’t mind).

Just because Tanenbaum didn’t mind does not mean that other developers who mistakenly use MIT/BSD will not either. Also, it honestly shouldn’t matter what Tanenbaum thinks because we don’t know what his rationale is. Maybe he thinks malware is a good thing or that IME is not a serious issue - if that’s the case, do we still consider his sentiments relevant?

commonly referred to as “cuck licenses”

This sentiment makes the enclosing sentence an Ad-hominem fallacy

It does not, in fact. Just because the author used a slang/slanderous term to describe the licenses he doesn’t like does not mean that his logical arguments are invalid. Ad-hominem fallacies are when you say “the person who argued that is $X, therefore his logic is invalid”, not when he uses a term that may be considered in poor taste.

by attacking the would-be MIT license party as having poor morals and/or low social standing.

Misrepresentation. The author is not arguing that they have poor morals, he is arguing that they are short-sighted and possibly naive with regards to the implications of choosing MIT/BSD.

My conclusion: I appreciate the author for making this post. People should be more aware of the fact that your software could be used for nefarious purposes.

So unless you really don’t care about enabling evil people, you should be defaulting to using GPL. If people really want to use your copyleft software in a proprietary way, then it is easily within their means (and resources) to get an exemption from you. The fact that there is so much non-GPL software out there makes the GPL itself weaker and makes it easier for nefarious interests to operate freely.

(Not that I would ever release software under GPL myself. I think software licenses are stupid. But no license basically has the same non-derivative limitation as GPL so it doesn’t matter as far as I’m aware.)

This is quite cool and a very interesting read. I’m not sure if it’s something I would want to use in a real project, because it looks like you’re basically inventing a new language within Python’s type system itself, which is a little weird. That said, I feel like I learned a lot from reading this, and it was a very interesting demonstration of what you can do with Python’s type-checking system.

There is no way to make a network request faster than a function call.

Apologies in advance if this it too pedantic, but this isn’t necessarily true. If you’re talking about an operation call that takes ~seconds to run, then the network overhead is negligible. And if you need specialized hardware for it, then it definitely could be delegate it out to a separate machine over the network. Examples could include requiring a GPU, more RAM, or even a faster CPU if your main application is running on more power-efficient CPUs.

I’m not saying that this is true in every case - they are definitely niche cases. But I definitely wouldn’t say that network requests are never faster than local function calls.

Agreed. Objects are nice and a great way to program. Composition is great. Traits/interfaces are great. Namespaces are great. Objects are a really nice way to reap the benefits of principles like these.

But then there are aspects of OOP that absolutely suck, like inheritance. I hate inheritance. The rules get very confusing very quickly. For example, try understanding overriding of methods. Do I need to call the superclass method or not? If not, does it get called automatically? If so, in what order? How do these rules change for the constructor? Now repeat this exercise for every OOP language you use and try not to mix them up… Java, C++, Python, etc.

Fortunately, it feels like we rely on inheritance less and less these days. As an example, I really like how Java allows you to implement Runnable these days. Before, if you wanted to run a thread, you needed a separate object that inherited Thread. And what if that object needs to inherit from another one too? Things would get out of hand quickly. (This is a very old example, but with lambdas and other new features, things are getting even better now.)

Anyway, long story short, I think OOP is a complicated way to achieve good principles, and there are simpler ways to achieve those principles than a full OOP implementation.

I’m really curious to know which version of KDE Microsoft was copying that gave them the idea to insert ads in the first place…

Win98 had themes, and they were absolutely fantastic!!

Opt in??! Before you know it, you’re going to suggest that we start to respect our users!!

Yeah, I knew someone was going to say that. Usually it’s more likely that Python is installed than jq - especially on servers. But yes, that would definitely work too.

I use json.tool a lot to format JSON directly in vim. Simply highlight the text you want to format and run :!python3 -m json.tool. There are probably plugins to do this too, but doing it this way is probably the simplest, unless vim has a built-in for it.

Same here. Sure, KDE and Gnome may have great Wayland support by now, but what about other DEs? The situation in XFCE seems to be pretty grim:

It is not clear yet which Xfce release will target a complete Xfce Wayland transition (or if such a transition will happen at all).

MATE seems to have piecemeal support. No idea what the status of LXDE/LXQT are. And there are plenty of other window managers that don’t have the manpower to support wayland either.

The deprecation of X is going to leave a lot of dead software in its wake.

I would say the biggest advantage is that OpenBSD is a very security-focused distribution, in a way that I don’t think any Linux-based distro has adopted.

The other advantage is ZFS. 10-20 years ago, there was no equivalent, and btrfs was in its infancy. These days, btrfs has proven that it is pretty stable and resilient. There might still be some advantages of ZFS over btrfs, but I haven’t used either one at all, so I can’t really be sure.

Outside of that, the BSDs are basically just different distros. Back in the 90s, when there was a lot more diversity in Unix, a lot of people just started out with *BSD because there was no clear choice at the time. People just like to use what they are more comfortable with - but most new users pick Linux over BSD these days, and a lot of people who started out on BSD have assimilated onto Linux.

Still, diversity is a good, nice thing, especially with the advent of systemd. So I’m glad we still have the BSDs around, even if I disagree with their stance toward the GPL.

Another problem is that there is (or was, I don’t follow these things) friction between the Kernel and systemd, as systemd developers did not respect certain development philosophies.

More information on this here:

When systemd sees “debug” as part of the kernel command-line, it will spit out so much informaiton about the system that it fails to boot… The init system just collapses the system with too much information being sent to the dmesg when seeing the debug option as part of the kernel command-line parameter. Within the systemd bug report it was suggested for systemd not to look for a simple “debug” string to go into its debug mode but perhaps something like “systemd.debug” or other namespaced alternatives. The debug kernel command-line parameter has been used by upstream Linux kernel developers for many years. However, upstream systemd developers don’t agree about changing their debug code detection. Kay Sievers of Red Hat wrote, “Generic terms are generic, not the first user owns them.”

tl;dr: systemd parsed kernel command line information; when “debug” was present, systemd enabled logging that was so verbose that it would cause the system to become unbootable. systemd developers were notified of the issue and started acting passive aggressive instead of fixing the issue.

Or to put it more simply: if you make changes that cause Linus Torvalds’ system to stop booting properly, you’re probably gonna have a bad time.