linux4noobs

3480 readers

43 users here now

linux4noobs

Noob Friendly, Expert Enabling

Whether you're a seasoned pro or the noobiest of noobs, you've found the right place for Linux support and information. With a dedication to supporting free and open source software, this community aims to ensure Linux fits your needs and works for you. From troubleshooting to tutorials, practical tips, news and more, all aspects of Linux are warmly welcomed. Join a community of like-minded enthusiasts and professionals driving Linux's ongoing evolution.

Seeking Support?

Mention your Linux distro and relevant system details.
Describe what you've tried so far.
Share your solution even if you found it yourself.
Do not delete your post. This allows other people to see possible solutions if they have a similar problem.
Properly format any scripts, code, logs, or error messages.
Be mindful to omit any sensitive information such as usernames, passwords, IP addresses, etc.

Community Rules

Keep discussions respectful and amiable. This community is a space where individuals may freely inquire, exchange thoughts, express viewpoints, and extend help without encountering belittlement. We were all a noob at one point. Differing opinions and ideas is a normal part of discourse, but it must remain civil. Offenders will be warned and/or removed.
Posts must be Linux oriented
Spam or affiliate links will not be tolerated.

founded 2 years ago

MODERATORS

PlutoParty@programming.dev

Hot take: Linux should standardize on JSON or TOML for its config files (lemmy.ml)

submitted 1 day ago* (last edited 1 day ago) by SubArcticTundra@lemmy.ml to c/linux4noobs@programming.dev

9 comments fedilink hide all child comments

One point of user-hostility you face when configuring Linux is all the config files in /etc. Be it crontab, fstab, or iptables, every project has its own ad-hoc config file format and as a rookie user you're left guessing what the rules for editing each one are. Must you separate entries with tabs or can it be spaces? Does the number of tabs matter? Does this file use # to comment or ;? Can you put a space after = or would that become part of the string? Some projects use their own half-baked implementation of .INI that breaks down the moment you try to escape a string. What's worse is that since it's background processes whose files you are editing, the response to a syntax error is nothing happening. The way to test whether you guessed the rules right is to wait and see 🤷

What I'm trying to say is that IMHO, the Linux Kernel and surrounding utilities should agree on a widespread, standardized config format and all migrate to it (prefarably sharing the same C library). The obvious option would be JSON, although it feels a little clunky and doesn't officially support comments. My preference would be TOML, since it's like INI which many projects kinda use already, but it's standardized and has native support for things like arrays (especially useful for fstab/crontab).

you are viewing a single comment's thread
view the rest of the comments

[–] tal@lemmy.today 5 points 1 day ago* (last edited 1 day ago)

In abstract, I guess maybe there would be some benefit, but I've been using Linux for decades, and it really hasn't been an issue for me. I've definitely had times where configuring stuff is confusing, but it's not a function of the basic input format not being JSON or XML or TOML or YAML or whatever. I think that the only time that I recall tabs being obnoxious was not with config files, but with Makefiles (they do, in fact, require tabs).

The majority of software is packaged with an "example" config file, often with comments in place. Traditionally, software will also ship with a section 5 man page for its config files. So, for example:

$ man 5 fstab

Will describe the format for /etc/fstab.

EDIT: I think that the biggest hassle I recall was in configuring a sendmail mail server, quite some years back. The issue there wasn't the basic format, but the fact that due to organic growth, even basic configurations were enormous (just to get the sort of common configuration that most users wanted) and required quite a bit of reading through the option documentation. It was common to use a frontend to generate the config files, and a number of subsequent mail servers aimed at having their default, no-configuration-options state being closer to what people wanted, dramatically reducing the number of options that had to be specified.