3 ms·

> Yes I get it, you like your SSH session and Emacs/Vim blah blah but that's short-sighted. How so? I'm one of those people that like my SSH session, and in my

> Yes I get it, you like your SSH session and Emacs/Vim blah blah but that's short-sighted. How so? I'm one of those people that like my SSH session, and in my case vim and "blah blah blah". I've contributed to countless open source software packages that you likely use with this method, and so have tons of other developers. Nothing is broken here, things are working great for everyone who reads the manual and follows it. > I want my software configuration stored in a database not in a bunch of fragile files with made up syntax that are always one typo or syntax error away from being potentially silently ignored. apache, postfix, haproxy, even vim are certainly not prone to silently ignore anything, just to name a few. > The fetish for easily-editable ASCII files and escaping from structure is holding us back. Holding us back from what? I am both a developer and an administrator, and I've had all the fun with solaris/aix configurations that are often not stored in plain text that I care to have. If you also have this experience, and still feel the way you do, then I'd love to hear more. Otherwise, your rant comes off as "your way is hard, and I don't want to learn it!" Look at all the available structures available for that plain text you speak of... XML, JSON, YAML, the list goes on. You are free to use one of those, then you have that structure you crave. There are plenty of areas that could use revolution, but UNIX-like configuration files are not one of them. There is no problem here. If you are making typos or mis-configuring your software, then you have a problem of your own creation.

borplk 10y ago
> How so? As I mentioned in another comment in my view the problem is that something like the configuration is shared both by the humans and the computers. Because of this we settle on something that is not optimal for either group. We end up with something that is hostile to both the humans and the computers, just in different ways. In fact the argument of people like you for ASCII config files exactly demonstrates my point. You are fighting for your human-convenience against the machines. > Holding us back from what? By embracing and acknowledging that the humans and computers are not meant to share a language we free ourselves from this push-pull tension between human vs machine convenience. We can develop formats and tooling that respects its human audience, that doesn't punish the human for making small superficial syntax or typo errors and so on. And we can finally step the hell out of the way of computers and let them use what is suitable for them. And at that point you could still have your SSH session and Vim/Emacs and blah blah blah and you could still view and interact with stuff as plaintext if you wanted to. > apache, postfix, haproxy, even vim are certainly not prone to silently ignore anything, just to name a few. It's not always a matter of silently ignoring something but due to the nature of the task it is certainly very easy to shoot yourself in the foot doing something that isn't technically an error but wasn't your intention. For example you can silently break your cron jobs by leaving windows-newlines in them. Perfect example of humans and computers sharing a language that is hostile to the human. BAD BAD human! You stupid human why do you use bad Windows invisible characters? Use good linux invisible characters instead that are more tasty for your almighty lord Linux.
- module0000 10y ago
  > It's not always a matter of silently ignoring something but due to the nature of the task it is certainly very easy to shoot yourself in the foot doing something that isn't technically an error but wasn't your intention. I agree with you here, it's easy to write perfectly valid configurations that don't do what you intended. But throwing it all out seems like the baby going out with the bathwater to me. In all seriousness, what if it was XML all around? I hate writing XML by hand, but that's part of the problem you are describing(ie human editing of raw config). XML parses very nicely, so difficulty of coding tools to speak XML is almost non-existent. All in all, it's just a big change you are proposing. Us UNIX people are incredibly change-averse. We keep getting burned :)
  - borplk 10y ago
    > All in all, it's just a big change you are proposing. Us UNIX people are incredibly change-averse. We keep getting burned :) Well that's exactly my point. I don't propose that we deploy it tomorrow but I want to see people do it and think about it and talk about it so our grand children can have better computing. Instead of sticking to the way of our fathers for all eternity. XML as you identified has the same problem. You need a human-dedicated interface that captures the intent of the human and you then convert that to something that the computer likes and tell them here ... this is what the human has ordered. When we share the same raw input file with the computers that's when we set ourselves up for trouble. Do I have the ultimate solution? No. Can I still complain about it being a problem? Yes. One "solution" is a graphical rich interface with things like auto completion and validation and all that so it's much more capable of capturing the true intent of the humans. Basically the same way we interact with other web sites. Imagine your bank told you to append a new text line to the end of "transactions.txt" file if you wanted to transfer money. Now I put solutions in quotation marks because I know a GUI has other practical limitations and problems but you get the idea. My point is as humans eventually we have to learn to graduate from sharing a rudimentary text language with the computer for the sake of short-term convenience.
- wallacoloo 10y ago
  A lot of config files are already trivial for the computer to parse (by design). Most config files even follow a loose standard of some sort (e.g. INI, which is a sort of key-value system). Would it not be easier to keep this format, and then add some integration into your favorite text editor that prevents you from accidentally editing the INI keys, or warns if you create a syntax error, etc? You could even make a generic INI gui editor that replaces appropriate values with checkboxes, sliders, etc. I guess I don't see much wrong with the formats for most config files, but if you insist that there is a problem, and the problems you've outlined are caused only when editing them, then why not change the editor and preserve the format? (That cron problem does sound bad though)

borplk 10y ago

> How so? As I mentioned in another comment in my view the problem is that something like the configuration is shared both by the humans and the computers. Because of this we settle on something that is not optimal for either group. We end up with something that is hostile to both the humans and the computers, just in different ways. In fact the argument of people like you for ASCII config files exactly demonstrates my point. You are fighting for your human-convenience against the machines. > Holding us back from what? By embracing and acknowledging that the humans and computers are not meant to share a language we free ourselves from this push-pull tension between human vs machine convenience. We can develop formats and tooling that respects its human audience, that doesn't punish the human for making small superficial syntax or typo errors and so on. And we can finally step the hell out of the way of computers and let them use what is suitable for them. And at that point you could still have your SSH session and Vim/Emacs and blah blah blah and you could still view and interact with stuff as plaintext if you wanted to. > apache, postfix, haproxy, even vim are certainly not prone to silently ignore anything, just to name a few. It's not always a matter of silently ignoring something but due to the nature of the task it is certainly very easy to shoot yourself in the foot doing something that isn't technically an error but wasn't your intention. For example you can silently break your cron jobs by leaving windows-newlines in them. Perfect example of humans and computers sharing a language that is hostile to the human. BAD BAD human! You stupid human why do you use bad Windows invisible characters? Use good linux invisible characters instead that are more tasty for your almighty lord Linux.

module0000 10y ago
> It's not always a matter of silently ignoring something but due to the nature of the task it is certainly very easy to shoot yourself in the foot doing something that isn't technically an error but wasn't your intention. I agree with you here, it's easy to write perfectly valid configurations that don't do what you intended. But throwing it all out seems like the baby going out with the bathwater to me. In all seriousness, what if it was XML all around? I hate writing XML by hand, but that's part of the problem you are describing(ie human editing of raw config). XML parses very nicely, so difficulty of coding tools to speak XML is almost non-existent. All in all, it's just a big change you are proposing. Us UNIX people are incredibly change-averse. We keep getting burned :)
- borplk 10y ago
  > All in all, it's just a big change you are proposing. Us UNIX people are incredibly change-averse. We keep getting burned :) Well that's exactly my point. I don't propose that we deploy it tomorrow but I want to see people do it and think about it and talk about it so our grand children can have better computing. Instead of sticking to the way of our fathers for all eternity. XML as you identified has the same problem. You need a human-dedicated interface that captures the intent of the human and you then convert that to something that the computer likes and tell them here ... this is what the human has ordered. When we share the same raw input file with the computers that's when we set ourselves up for trouble. Do I have the ultimate solution? No. Can I still complain about it being a problem? Yes. One "solution" is a graphical rich interface with things like auto completion and validation and all that so it's much more capable of capturing the true intent of the humans. Basically the same way we interact with other web sites. Imagine your bank told you to append a new text line to the end of "transactions.txt" file if you wanted to transfer money. Now I put solutions in quotation marks because I know a GUI has other practical limitations and problems but you get the idea. My point is as humans eventually we have to learn to graduate from sharing a rudimentary text language with the computer for the sake of short-term convenience.
wallacoloo 10y ago
A lot of config files are already trivial for the computer to parse (by design). Most config files even follow a loose standard of some sort (e.g. INI, which is a sort of key-value system). Would it not be easier to keep this format, and then add some integration into your favorite text editor that prevents you from accidentally editing the INI keys, or warns if you create a syntax error, etc? You could even make a generic INI gui editor that replaces appropriate values with checkboxes, sliders, etc. I guess I don't see much wrong with the formats for most config files, but if you insist that there is a problem, and the problems you've outlined are caused only when editing them, then why not change the editor and preserve the format? (That cron problem does sound bad though)