Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)T

TechNom (nobody)

@ technom @programming.dev

Posts
0
Comments
128
Joined
3 yr. ago

  • I AM SO DISAPPOINTED WITH UBUNTU 24.04 😡

    Jump

  • I have serious doubts about that due to the role of early Ubuntu in popularizing desktop Linux. For many including me, Ubuntu was the first taste of GNU/Linux and it was a breath of fresh air compared to the contemporary clumsy and cumbersome distros like Fedora. Only Ubuntu from those days has any resemblance to the experience we expect from desktop Linux today.

    The problems at Canonical seems like a systemic institutional issue, probably related to egotistic management with temper issues. That of course means that Shuttleworth is the source of those personality disorders. But still...

  • I AM SO DISAPPOINTED WITH UBUNTU 24.04 😡

    Jump

  • LXD was under the Linux containers project earlier. After the Canonical takeover of LXD, the following changes were made:

    1. The repo privileges of the original LXD developers were revoked. Those developers are driving the development of Incus now.
    2. LXD's license was changed to AGPL+CLA

    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).

  • What is the most popular Linux distribution on PC?

    Jump

  • I don't think that either of them count as 'Linux distributions'. And sadly, it matters. Even the bugs are not consistent across distros.

  • What is the most popular Linux distribution on PC?

    Jump

  • 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.

  • I AM SO DISAPPOINTED WITH UBUNTU 24.04 😡

    Jump

  • 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.

  • Some of my iterations are delightfully recursive

    Jump

  • 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.

  • Which communication protocol or open standard in software do you wish was more common or used more?

    Jump

  • Most websites still use standard back ends with RSS support. Even static site generators also do it. The only difficulty is user discovery.

  • Which communication protocol or open standard in software do you wish was more common or used more?

    Jump

  • Conduit might be an option. It's still under development. It's also lightweight due to Rust (instead of Python as in Synapse).

  • Which communication protocol or open standard in software do you wish was more common or used more?

    Jump

  • 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.

  • Which communication protocol or open standard in software do you wish was more common or used more?

    Jump

  • It really needs to significantly improve its live update capability. Typst is more capable in that regard.

  • Which communication protocol or open standard in software do you wish was more common or used more?

    Jump

  • Markdown and LaTeX are meant for entirely different purposes. It's somewhat analogous to HTML vs PDF. While it's possible to write books with Markdown, it's a vastly inferior solution compared to latex or typst (for fixed format docs like books).

  • Which communication protocol or open standard in software do you wish was more common or used more?

    Jump

  • Nobody knows about unifiedpush. Last time I checked, their Linux dbus distributor also wasn't ready. There has to be a unified push to get it adopted.

  • How the Media Treat Linux

    Jump

  • Can you tell us what you find difficult while using Linux? (After the installation).

    PS: Not a rhetoric. Just trying to understand the friction.

  • Which communication protocol or open standard in software do you wish was more common or used more?

    Jump

  • "The inside of the network stay anonymous" sounds like they are talking about internet access to the internal network.

  • Which communication protocol or open standard in software do you wish was more common or used more?

    Jump

  • Commonmark leaves some stuff like tables unspecified. That creates the need for another layer like GFM or mistletoe. Standardization is not a strong point for markdown.

  • Which communication protocol or open standard in software do you wish was more common or used more?

    Jump

  • Typst is a typesetting format - an alternative to LaTeX. Asciidoc is more of a competitor to markdown.

  • Which communication protocol or open standard in software do you wish was more common or used more?

    Jump

  • The entire purpose of Microsoft standardizing OOXML and implementing it wrongly in Office was to make other office suites irrelevant. ODF was already standardized and countries would have adopted it if MS didn't do the same with OOXML. They stuffed the ISO with members supporting them to do it.

    And now that OOXML is a viable standard, they implement it wrongly so that other office suites can't be compatible with MS Office without a lot of extra effort. Any incompatibilities with MS Office will be considered as the fault of other office suites by the general public and government officials.

    Expecting MS to do what's right for the customers is putting too much faith in their nonexistent sense of ethics.

  • When do you consider a system to be bloated?

    Jump

  • No problem!

  • When do you consider a system to be bloated?

    Jump

  • The problem I have is with the installer GUI. They often don't work well when doing complex partitioning or mounting. Theoretically, you could use fdisk/parted on the live CD to do the partitioning. But the mounting section of the GUI (the part that creates the fstab) still struggles to map these new partitions the way we want it. This happens often when using btrfs subvolumes, LVM, dmcrypt or standard/custom ESP mount points (individually or in combination).

    None of these are a problem when you are using a regular terminal shell to install the distros. You can just write fstab manually the way you like. This is a classic example of GUIs being convenient, but CLIs being more complete and powerful.

    Theoretically, it's possible to achieve CLI installation for other distros too. Debian, for example with debootstrap. However, those procedures aren't as well documented as for Arch and Gentoo, because you're expected to use the GUI installer. CLI installation just feels natural in Arch and Gentoo.

    Another issue I have is with boot loader installation. I have 2 Linux distros (for genuine uses) and a BSD installed. I use rEFInd to manage them. GUI installers replace rEFInd with their boot loader. While this can be reverted manually, it's annoying. But Grub has a CLI option to disable this (--no-nvram).

    Does Arch have other tools beyond that which are unique to Arch?

    Arch and Gentoo has additional small utilities like pacstrap and eselect. They're not big, but are very helpful when you need them.

    Is there a difference how you configure a window manager on Arch and Debian?

    I always find it easier to configure things on Arch than on Debian. There are two reasons for this. First is that Arch has an extensive wiki written with the assumption that you'll customize things (which is actually helpful even for other distros). Second is that software on distros like Debian are heavily patched for system consistency, while Arch and Gentoo provide mostly vanilla packages. This means that user documentation from the upstream software developer can be used directly on Arch and Gentoo, whereas you need to be aware of the patching in Debian.

    One interesting example of the last point is the recent xz backdoor. That backdoor wouldn't have worked if Debian and Fedora didn't patch OpenSSH to talk to systemd. While Arch and Gentoo also reverted these backdoors, their OpenSSH were never patched and didn't have this vulnerability.