Gitlab is very complex and a heavy resource hog. You probably don’t need it. Most small to medium enterprises can comfortably host their projects on lightweight forgejo or gitea (speaking from experience). They even have functionality similar to github actions. If you need anything more complex, you are better off integrating another self hosted external service to the mix.
Oh man! I hate CF! The scummy gatekeepers.
He didn’t just wash off his hands. When asked in an interview about a moderator who edited a trans user’s profile to intentionally misgendering them (yup, even that’s not off limits for their mods), he justified it saying that ‘It’s not like using the N-word or something’. (For context, the n-word itself was innocuous. It gained notoriety due to its misuse by bigots like this).
There are several such examples - repeatedly even after being called out. I don’t belong to any diversity groups. But I don’t care if they make the world’s best operating system. I will stay well away from it if only to avoid any interaction with such a group. They’re a bit too happy about harassing people (not just transgenders either).
This is clearly intended as an alternative to submodules.
An alternative, not a replacement. Vdm is specifically designed to track code dependencies. There are use cases like monorepos where vdm won’t work.
Neither does Git though. I’m not really sure I follow your point.
Git does track submodule history unlike vdm.
By default, vdm sync also removes the local .git directories for each git remote, so as to not upset your local Git tree.
Git submodules don’t delete those .git directories. It uses them.
If you want to change the version/revision of a remote, just update your spec file and run vdm sync again.
This is not how git submodules or subtrees work.
vdm does depends on git being installed if you specify any git remote types
Support more than just git and file types, and make file better
Git submodules and subtrees don’t support anything other than git remotes.
Yes. I saw that. I was giving you my assessment based on the rest of the technical details in that readme. It doesn’t look like vdm is dealing with any part of the dependency repos (.git directories) other than to download them. In fact, they even mention deleting those .git directories. Please let me know if you think I misinterpreted any of those details.
Is it legal? There may be alternatives with plausible deniability.
Arch guide expanded in scope IMO. The choices are way more than in the past. However, it’s good quality and easy to read. I implore you to skim it, even if you don’t try it out.
While I understand your point, there’s a mistake that I see far too often in the industry. Using Relational DBs where the data model is better suited to other sorts of DBs. For example, JSON documents are better stored in document DBs like mongo. I realize that your use case doesn’t involve querying json - in which it can be simply stored as text. Similar mistakes are made for time series data, key-value data and directory type data.
I’m not particularly angry at such (ab)uses of RDB. But you’ll probably get better results with NoSQL DBs. Even in cases that involve multiple data models, you could combine multiple DB software to achieve the best results. Or even better, there are adaptors for RDBMS that make it behave like different types at the same time. For example, ferretdb makes it behave like mongodb, postgis for geographic db, etc.
Nvidia is a mess on Linux in general, though it’s gradually improving. They decided to neglect everything that the other GPU manufacturers and the community were doing and roll out their own buggy concepts.
This really isn’t the fault of Mint. PopOS works with it just because its developers System76 also has a line of nvidia based hardware. However, as I said before, nvidia is slowly starting to implement the standards and situation on other distros like Mint will gradually improve.
Meanwhile, I’m curious. What hardware did you try Mint on?
It didn’t look like a submodule reimplementation to me. Subtree is more of a submodule reimplementation. This is more like a language-agnostic package manager (like cargo, npm, etc) that downloads and caches source packages.
I do recommend Gentoo (haven’t tried Funtoo) for the academically inclined. It’s a beast to maintain, but you’ll soon find yourself at ease with configuring and compiling your own kernel, configuring your packages and even making some yourself.
It isn’t as hard as people make it out to be - if you gradually push your boundaries. In particular, it’s good if you already use Arch.
LXD was under the Linux containers project earlier. After the Canonical takeover of LXD, the following changes were made:
The first point means that Incus is the true successor of the original LXD. The current LXD is a jealously guarded pet project of Canonical in the same manner as Snap and Mir.
As for the second point, I’m usually a proponent of AGPL. But CLA corrupts it so much that it’s more harmful than with a permissive license. The real intention of this license change is to prevent Incus from incorporating changes from LXD (since the copyleft license of LXD code is incompatible with the permissive license of Incus). Meanwhile LXD continues to incorporate changes from Incus, although the Incus developers haven’t signed any CLA. This move by Canonical is in very bad faith, IMO.
So yes - I consider LXD to be untrustworthy. But that doesn’t cover the old LXD code, its developers or its community. Those transformed fully into the Incus project the same way OpenOffice was forked into LibreOffice. And I don’t trust the LXD name anymore in the same way nobody trusted the OpenOffice name after the fork (before it was donated to the Apache foundation).
I don’t think that either of them count as ‘Linux distributions’. And sadly, it matters. Even the bugs are not consistent across distros.
There are two components that define a Linux distribution. The first is the kernel. The other is the core user land that includes the coreutils and libc. This part is made of GNU coreutils and glibc or compatible alternatives like busybox and musl. Every Linux distro has this. The other user land software stack are also similar across distributions, like X/Wayland, QT/GTK, dbus, XDG, etc.
In Android, everything in the user land is different. It doesn’t have the same coreutils or libc unless you install it. ls and find are so common across *nixes that Android coreutils may be reimplementing it. Then you have APKs, surfaceflinger, etc that are not part of regular Linux distros.
An easy test for this is to see if a Linux program compiled for your platform runs on your OS. Linux programs easily run on alternative distros. But Linux programs won’t run on Android or vice-versa, unless you install a compatibility layer.
Mir is not a good example of distro engineering, because it’s an extreme case of NIH syndrome. Unlike what it is today, the original Mir was an alternative to Wayland.
The story started when Canonical decided that X isn’t good enough and they needed an alternative. They chose Wayland first, exciting the entire Linux desktop community. But then they dropped Wayland in favor of the new in-house Mir project, citing several drawbacks to Wayland. The Wayland community responded with several articles explaining why Canonicals concerns were unwarranted. But in typical Canonical style, they simply neglected all the replies and stuck with Mir.
This irked the entire Linux community who promised to promote Wayland and not support Mir at all. This continued for a while until Canonical realized their mistake late, like always. Then they repurposed Mir as a Wayland compositor.
Now this is a repeating story. You see this with Flatpak vs Snap, Incus vs LXD, etc. The amount of high handedness we see from Canonical is incredible.
I looked at the post again and they do talk about recursion for looping (my other reply talks about map over an iterator). Languages that use recursion for looping (like scheme) use an optimization trick called ‘Tail Call Optimization’ (TCO). The idea is that if the last operation in a function is a recursive call (call to itself), you can skip all the complexities of a regular function call - like pushing variables to the stack and creating a new stack frame. This way, recursion becomes as performant as iteration and avoids problems like stack overflow.
Most websites still use standard back ends with RSS support. Even static site generators also do it. The only difficulty is user discovery.
Conduit might be an option. It’s still under development. It’s also lightweight due to Rust (instead of Python as in Synapse).
Asciidoc is a good example of why everything should be standardized. While markdown has multiple implementations, any document is tied to just one implementation. Asciidoc has just one implementation. But when the standard is ready, you should be able to switch implementations seamlessly.
Solid state physics.