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.
technom
joined 1 year ago
It really needs to significantly improve its live update capability. Typst is more capable in that regard.
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).
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.
Can you tell us what you find difficult while using Linux? (After the installation).
PS: Not a rhetoric. Just trying to understand the friction.
"The inside of the network stay anonymous" sounds like they are talking about internet access to the internal network.
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.
Typst is a typesetting format - an alternative to LaTeX. Asciidoc is more of a competitor to markdown.
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.
No problem!
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.
Conduit might be an option. It's still under development. It's also lightweight due to Rust (instead of Python as in Synapse).