Next: , Previous: , Up: Sergey Matveev’s homepage  


Harmful things

This is written by analogy with all software sucks.

Harmful thingsLess harmful alternativesOpinion
systemddaemontools, runit, s6Bloated enormously huge complicated crap with awful track of security issues and privacy concerns, that does completely unacceptable things. Look how it sucks. I do not want to say that SysV/RC-style init systems are a good thing, but at least they are less harmful. daemontools is the proper way you should start your software.
GNU/Linux*BSD, illumousThe whole GNU/Linux ecosystem is overbloated bunch of frameworks with mediocre quality. You can create something secure and working out of them, but with tons of spent time of torture and struggle. Generally those systems are technologically inferior to most BSD-based systems (of course macOS is an exception) and implement similar things many years later. If something is told to be ready to use and production ready, then wait for 5+ years to be sure that it really is. Of course there is worthy software in GNU, but in general there is a zoo of highly incompatible pieces.
Windows, macOSGNU/Linux, *BSD, illumousDoes anybody really want to run proprietary non-free closed-source backdoored DRMed software?
Permissive licenceCopyleft licenceSoftware must be free. Copyleft enforces and ensures that.
TLSIPsec, CurveCP, NoiseIf people were smart and experienced, then IPv6 would took the world a long time ago, making automatic host-to-host IPsec transport connections the reality, providing transparent secure network layer. But people are so dumb, that they protect networks by harshly breaking the communications with the NAT, not remembering what firewalls were made for. So we have got per-connection per-application user-mode transport layer security overlay. Most TLS versions, up to 1.2, suffered from serious security issues and flaws. Cryptographic protocols have to be simple and created by wise cryptographers.
OpenSSLDo not know, GnuTLS?, crypto/tlsLinus’es law claims that "given enough eyeballs, all bugs are shallow", but OpenSSL library proves that dozens of years and billions of users means nothing for security. Fatal critical and catastrophic bugs are here. OpenSSL source code is awful from architectural point of view and quantity of assumption where developer has to be precisely accurate.
PKIcertificate pinning, Web-of-TrustPKI can work on enterprise-level scale, with single definitely trusted anchor. Global scale PKI can not be secure by definition, because anyone from dozens and hundreds of imported authorities are told to be trusted for some reasons. It is business and nothing more.
DNSSECDNSCurveDNSSEC offers no privacy (no encryption) and friendly to censorship. It leaks zone contents through NSEC*. It is vulnerable to replay attacks. It requires both client and server software modification, additional DNS records and changing the registrars, greatly increasing packet sizes, requiring to work over TCP as a rule. Moreover it is PKI with single US/NATO-based trust anchor. DNSCurve has none of that problems.
DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), DNS-over-DTLS, DNS-over-QUICDNS over IPsec (any VPN), DNSCryptWhy do you need to use additional transport security protocol if you want to secure communication between two hosts? IPsec transparently offers that. If you are not able to use it, then at least there is no need in TCP-based PKI-poisoned solutions – use DNSCrypt that just slightly increases packet sizes with end-to-end encryption.
ext2/ext3/ext4XFS, ZFS, UFS2, probably JFS2GNU/Linux is known to have long history of lack of stable, high performance, reliable filesystems. ext4 is even can not keep files more than 16 TiB (4KiB blocksize), that is less than single modern LTO tape can hold. XFS, ZFS, JFS2 were created outside GNU/Linux, being much more versatile and stable ones.
BTRFS, APFSZFSBTRFS is still not stable enough, having no working RAID5/RAID6 analogue. It is just toy parody on ZFS, that can not be considered seriously. APFS even lacks checksums – only Apple fanboys can agree to use that (however it could be better that their HFS+). ZFS sucks in Linux? Well, use adequate operating system!
CISCRISC
Little-endianBig-endianEveryone used big-endian, except for Intel and some other minor companies. It is way more convenient to by used by human. There is reason that it is also known as "network-order".
DVD-R(W)DVD+R(W)+R is simpler, technologically cheaper and more reliable.
XML, JSON, YAML, TOMLHjson (for configuration files)XML and JSON are not indented to be used directly by humans. YAML is monstrous beast of complexity. Most libraries even do not implement all of its features, meaning that you can not expect your file will be working at all. TOML is simple for parsing, but completely unusable for human understanding, looking comprehensible only with tiny and trivial structures. Hjson is tiny superset over JSON, with conveniences exclusively made for human, transparently converting it to JSON as machine friendly format.
ASN.1XDREven the strictest ASN.1 DER codec has many coding rules, meaning that codec-library will be pretty complicated thing, harming the security. All that lack of clearness of being able to work with some schemaless structures and unable to work with implicitly tagged another ones is pointless complication. Either use completely schemaless solutions like MsgPack/BSON/JSON/whatever, or completely schema driven ones, like XDR, that is very trivial to implement and work with. XDR library exists in all OSes out-of-box as a rule. XDR can be encoded/decoded very fast, because of its alignment and simplicity.
JSONBencode, NetstringsJSON parser is pretty complicated thing to write. Bencode is much more simpler schemaless solution. It can be encoded/decoded very fast. JSON structure has many possible valid representations, that complicates its usage with the context where cryptography is involved. Bencode has only single valid representation.
C++, Ruby, Java, Python, RustGoComplexity is the main enemy. You can easily write complex, hardly understandable and unmaintainable code with languages giving you wide abilities to express yourself.
JavaScriptanything else, Lua, TclJavaScript is very complicated and badly designed language. Initially it was not even aimed for general purpose scripting. Lua is tiny, very very fast. Tcl is also pretty simple thing, targeted for embedding from the very beginning.
AWKPerlHardly anyone knows AWK at all. Moreover there are several dialects of it, meaning bad portability of its code. Perl is faster, has no dialects (portable), pretty compact and has way more number of features and people knowing how to program it. There is just no use-cases where AWK could be more convenient to use, even with oneliners.
BashPOSIX shell, Z shell, Korn shellBash is huge, slow, has very few features for convenient interactive usage, lacks flexibility and extensibility. It is just the lamest and stupidest shell I have ever seen, that gives literally no advantages over many other much more simpler (from code perspective) and feature rich shells. It is awful for interactive usage and awful for scripting, because it even lacks reliable variable escaping (like POSIX shell too, but at least POSIX is portable).
Make, Waf, SConsredoThere is not much I can comment there. Make is unportable in practice, completely unworking (due to mtime, recursive make issues), non-atomic thing to deal with. redo is literally better in all-cases, requiring no additional language learning, using the implementation that can be written at one day. Solutions requiring additional declarative language learning already suck with that requirement.
GNU Autotoolspkg-config, redoAutotools is completely unsupportable bloated piece of software, that was helpful when there were dozens of highly incompatible commercial Unices. Nowadays there are C-standards, POSIX, pkgconf, higher quality OSes and ability to parallelize detection tasks with redo.
dynamic linkingstatic linkingDynamic linking has damned high load time overhead. It brings various security problems and flaws. It complicates software support and maintaining because of "DLL hell". It heavily complicates debugging and profiling. In general everything is just slower with it, often consuming much more memory comparing to statically linked programs with unused sections thrown out. If you want to update statically linked pile of software, because of some dependant library, then just take all that programs and recompile, what is the problem? Are you using some closed-source one? That is the problem.
GNU Screentmuxtmux is much more lightweight and feature rich, having pretty comprehensible and easy to understand documentation.
GlibcBSD libc, musl, jemallocGlibc is bloated low code quality and slow software, having huge scalability and resource consumption issues with multithreaded applications.
maninfoInfo files are real hypertext documents. Why I prefer Texinfo+Info.
UTF-16/UTF-32UTF-8What is the point of multibyte encodings when each (user-visible) character can be made of grapheme cluster, consisting of multiple codepoints anyway? UTF-8 just greatly simplifies everything.
MP2, MP3, AAC, AC-3, EAC-3Vorbis, OpusFormats and codecs must be free and open, like software. Moreover Opus and Vorbis are just technically superior to proprietary analogues.
ALAC, Monkey’s AudioWavPack, FLAC as a fallbackFree and open formats are the only acceptable choice. Personally I love WavPack more, because of its simpler bitstream format, slightly better compression ratio and less technical restrictions.
MPEG4, H.263TheoraFree and open format is better anyway. Theora is relatively lightweight for modern hardware, so can be used for real-time tasks.
AVC, HEVC, VVCVP8, VP9, AV1VP8/VP9 have comparable quality to non-free patented H.26x codecs and are already widely used in YouTube. AV1 is superior to them.
AVI, MP4Matroska, WebM, OggMatroska has low overhead, is feature rich and can contain virtually anything, comparing to MP4 that is not friendly to free and open codecs. WebM is just its subset. Ogg is an acceptable choice comparing to non-free ones.
cpio, tar, GNU Tarpax format, that fallbacks to UStarGNU Tar is vendor-locked in. cpio and non-pax tar formats have many practical limitations on what they can store.
gzip, bzip2, xzZstandardZstandard is faster than gzip and has better compression. It is ultra-fast at decompression. Its highest compression levels are comparable and close to xz ones, but having magnitudes faster decompression.
RAR, 7ztar + ZstandardRAR is proprietary non-free format/software. 7z does not store file’s ownership, making it useless in Unix.
GNOME, KDE, Xfcedwm, awesome, i3, xmonadAll desktop environments are just completely useless resource consumption crap for Windows/macOS users. It helps user in no way. Tiling managers are much better at resources utilization (including display workspace). Experienced Unix user spent most of his time in terminals.
FHSslashpackage, GNU StowSoftware must always exist with the source code nearby (to be able to recompile it, because of yet another update). There should not be complex tracking system of port’s files location – they just should be located in isolated separate subdirectories. There should be ability to use multiple versions of the same software.
IPv4, NAT, DHCP, ARPIPv6 + SLAACIPv6 (with its supplementary protocols like ICMPv6) is beautiful, elegant and clever designed thing. IPv4 has never been intended to be used as global-scale solution. Its NAT crutch just breaks nearly all protocols (except for two or three) workability and availability. IPv6 is more lightweight, faster, easier, simpler and convenient to work with.
Forum, Social networkMaillist, FeedWith web-based solutions you have to use inconvenient (everyone has its own preferences) interface. You can not work with them offline, can not create local indexable archive. Each forum/social network is completely independent and separate user experience. MUAs are much more superior in flexibility and filtration/processing abilities.
GNU Mailman, Sympamlmmj, public-inboxmlmmj is very minimalistic, simple, written on pure C, having neither heavy dependencies, nor bloated web-interfaces. But it supports: archives, bounces handling, moderation, digests, VERP. public-inbox can act as a perfectly fine archiver with rich set of access methods.
RSSAtomMon, 06 Sep 2010-like date formats, seriously?
Thunderbird, Outlook, Apple MailMutt, mailx, s-nail, NotmuchGUI is useless for MUA. Apple Mail and Outlook even do not have ability to reply to maillist. Thunderbird probably was acceptable many years ago, but it inherently sucks as everything Mozilla does now.
EvinceZathuraZathura is much more lightweight and supports PDF, DjVu, EPUB, XPS.
WebSocketpure TCP, SCTPThis is pure insanity to create another obfuscated TCP-like layer on top of already existing one, just because browser’s API is limited.
ALSAOSS4, sndioTechnically OSS4 and sndio just superior by features and low-delay in real life experience.
PulseAudioJACK, OSS4PulseAudio is like systemd in the world of audio. Useless crap.
LXC, OpenVZjail, ContainersConvenience and simplicity are nearly always better in BSD/Solaris.
EPUBFictionBookFictionBook is made by people for people, but EPUB by companies with DRM in mind.
JPEG, PNG, HEIC, AVIF, JPEG2000JPEG XLJPEG XL is patent free, virtually has no technical limitations (like number of layers, resolution, HDR/WCG support), supports progressive decoding, has 60% better compression ratio than JPEG, 40% better than PNG, 10% than lossless JPEG2000 for photographs. At q>40 has better compression than AVIF. Its decoder is very fast (can be even faster than JPEG). Can losslessly transcode JPEG.
CRC-32, CRC-64, fletcher-*, Adler-32XXH3
MD5, SHA-1, SHA-2SHA-3 (SHAKE variant), BLAKE2, Skein, BLAKE3MD5 and SHA are already insecure/broken. SHA2 is damn slowest. SHA3 is simpler and can faster on hardware. Skein is faster than SHA2/3, having very high security margin. BLAKE2 is even more faster, not talking about BLAKE3.
AESSalsa20, ChaCha20AES has lower security margin and is pretty slow without hardware acceleration.
ECDH, DH, RSAcurve25519, Curve448Curve* are much easier to implement correctly. They are faster and much more safer in general.
ECDSA, RSAEdDSAEdDSA is much easier to implement correctly. It is much faster and has compact keys. It does not need entropy during signing. It is much more safer in general. Proper and correct side-channel resistant RSA implementation is the ultimate challenge.
Word, WriterLaTeXUsing of non textual format, that can not be diff-ed and placed in Git? Where you can not use your ordinary powerful text editors and hundreds of available tools?
MarkdownPOD, Texinfo, reStructured TextWhen people talk or note Markdown, they hardly realize that there is no Markdown! There are plenty of incompatible subsets of it. The common denominator is very tiny and completely unsatisfactory for every-day needs of documentation and websites writing.
Telegram, WhatsApp, Viber, SkypeXMPP, IRC, OMEMO, OpenPGP, OTRCentralized censored insecure solutions are always not an option. And none of them provide real end-to-end encryption you can verify.
S/MIMEOpenPGPOpenPGP (GnuPG) is included in most OS distributions out of box and is already widely used. S/MIME is made with PKI in mind.
GNU Privacy Guardage and OpenSSHage and ssh-keygen -Y sign are just magnitude times simpler, can be written from scratch for several hours. Simplicity is treasure and basis for security.
UTCTAI64UTC is non monotonous. TAI64 also suggests easily parseable long-term format for time storage.
inetdUCSPI (+daemontools)Daemonized UCSPI software is more scalable, reliable under high loads and much more flexible in general – every service is a separate daemon process with its own logging and layers of utilities like setuidgid, tcpserver, timeout, softlimit and similar.
curl ... | sudo bashFor any agency it is more convenient you to run Windows or macOScurl|bash is just a complete compromise of your computer. Too dumb and silly to be true, but unfortunately people seems to do that kind of things.

Next: Photographs, Previous: Dotfiles, Up: Sergey Matveev’s homepage