This is good question...

Posted Nov 20, 2011 23:18 UTC (Sun) by khim (subscriber, #9252)
In reply to: Change... to what? by jmorris42
Parent article: That newfangled Journal thing

We believe in small individually replacable parts that do one task well, that are configured and communicate in human readable formats.

This is good belief, but sadly it failed "test of time".

But Plan9 should be our lodestar, not Windows, not OS X, not iOS, not Android.

This depends on your goals, I guess. Unix failed everywhere except on server. Plan9 just plain failed. Windows, OS X, iOS, Android... these things survived and currently thrive.

This Journal does not solve any actual problems, makes some things more difficult and moves us down the road to a towering mass of fail long term.

If your definition of fail is "something actually usable by mere mortals" then yes.

The problem with small individually replacable parts that do one task well, that are configured and communicate in human readable formats is that they are unusable without sysadmin. They work fine when there are competent sysadmin which can fix things when they break. And text formats are great boon for said sysadmin: s/he can tweak them in text editor, sed, awk, perl and eventually cobble up some kind of solution even in the unusual case.

When there are no such sysadmin text formats don't actually help anyone and are actually hurtful. Because in this case your only hope is self-healing system. And binary files and protocols can include as many crcs, signatures and built-in checks as you want. Sure, you can add them to text file as well, but what good it'll do? You still will need to use specialized tool to modify these files.

to post comments

This is good question...

Posted Nov 20, 2011 23:41 UTC (Sun) by dlang (guest, #313) [Link] (9 responses)

>> We believe in small individually replacable parts that do one task well, that are configured and communicate in human readable formats

> This is good belief, but sadly it failed "test of time"

and here is the fundamental disagreement. Many of us think that such systems are the ones that work best, not only in an operating system, but in an network based application as well.

Software as a Service is this same mechanism across multiple companies

people keep deciding that making everything monolithic is the only way to do anything, but then as they need to scale or interact with new things, they get trounced by solutions that are more loosely coupled.

the loosely coupled componenets allow for things to be done in ways that were never imagined by the creators of the software.

Yes, this does take a system administrator to figure out initially, but that doesn't mean that the common things can't be preconfigured or autoconfigured.

Ubuntu became as large as it is because it implemented automatic configuration of the loosely coupled pieces, it didn't require them to scrap existing tools to make it easy for people to use without separate sysadmin support

Hmm... Interesting. Where is the list?

Posted Nov 20, 2011 23:55 UTC (Sun) by khim (subscriber, #9252) [Link] (8 responses)

people keep deciding that making everything monolithic is the only way to do anything, but then as they need to scale or interact with new things, they get trounced by solutions that are more loosely coupled.

Interesting. What user-facing computer system was "trounced" by a solution which is more loosely coupled?

Sure when components are coupled too tightly it can be a liability, but so far we face the opposite problem: way too many moving parts to keep track of.

Ubuntu became as large as it is because it implemented automatic configuration of the loosely coupled pieces, it didn't require them to scrap existing tools to make it easy for people to use without separate sysadmin support

Ubuntu is still small when compared with Windows or MacOS X and even before Unity they already had quite a lot of changes in the various paclkages to better integrate them. For example Ubuntu also invented replacement for sysv init :-)

Hmm... Interesting. Where is the list?

Posted Nov 21, 2011 0:12 UTC (Mon) by dlang (guest, #313) [Link] (7 responses)

> Interesting. What user-facing computer system was "trounced" by a solution which is more loosely coupled?

I think the ultimate example of this is how the web trounced all the tightly coupled communities that existed before it. (AOL, Compuserv, Protogy, etc)

This is great example...

Posted Nov 21, 2011 7:48 UTC (Mon) by khim (subscriber, #9252) [Link] (6 responses)

Well, Web shows both sides of the coin.

1. Web essentially killed the closed alternatives (AOL, Compuserv, MSN, etc).

2. Few years after that happened web itself was overrun by packages with binary-only configs or GUI-only configs (forums, blogs, social networks, etc).

If you'll think about it then you'l see it's natural succession: geeks started the web and in the early phase the ability to mix and match was the key to success. Later, "normal" people have come and they don't need text config and protocols so they were moved to backstage (where sysadmins can still tweak them but most of the population can not).

If Linux wants to conquer user-facing devices it needs to become more robust and thus less flexible (flexibility begets uncertainty and uncertainty is primary enemy of robustness). If it wants to keep server side then it needs to keep flexibility. This is interesting dilemma, but so far it looks like only a handful developers care about robustness thus I think it's premature to start campaign for "true UNIX way". There are enough distributions which (like Gentoo or Slackware) keep UNIX traditions alive...

This is great example...

Posted Nov 21, 2011 9:48 UTC (Mon) by aleXXX (subscriber, #2742) [Link] (5 responses)

AFAIK, even those GUI-config web tools still mostly write into a config.php file or something, which is still plain text.

Alex

Nope...

Posted Nov 21, 2011 12:19 UTC (Mon) by khim (subscriber, #9252) [Link] (4 responses)

Usually you have something like setup.php which writes textual config.php with username, password, etc. But it's just a few lines of remnants of "UNIX heritage". Usually you are supposed to delete setup.php after initial configuration and never touch config.php at all.

Other configs, all the logic, etc - everything goes to the insane mess of SQL tables or (if it's modern, AppEngine-based app) is stored as a blob in Datastore.

Nope...

Posted Nov 21, 2011 21:08 UTC (Mon) by raven667 (subscriber, #5198) [Link] (3 responses)

Well, there the reason that the webapp config is in a DB rather than text files is that this is easier and safer to read/write esp. when there may be multiple users changing settings at any given time. Sure you _could_ try and deal with multiple writers modifying config files while the app is continuously parsing and rereading the config to pick up changes but implementing all the custom parsing and locking is going to be a lot more difficult than writing a few simple select/insert/update/delete transactions.

Nope...

Posted Nov 22, 2011 0:45 UTC (Tue) by dashesy (guest, #74652) [Link] (2 responses)

Very true, even for a single user.
It remembers me of trying to synchronize history across multiple open gnome terminals in a way that they do not step on each others feet!

Nope...

Posted Nov 22, 2011 16:58 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (1 responses)

Share history among *running* terminals or make sure that all history gets to the histfile? I have zsh set up to do the latter (the shell's history gets appended to the global history; it doesn't overwrite the histfile with old history plus its history (which bash does)). It's just "setopt appendhistory".

Nope...

Posted Dec 1, 2011 12:54 UTC (Thu) by nye (subscriber, #51576) [Link]

>it doesn't overwrite the histfile with old history plus its history (which bash does)).

$ shopt -s histappend

This is good question...

Posted Nov 20, 2011 23:49 UTC (Sun) by butlerm (subscriber, #13312) [Link]

>When there are no such sysadmin text formats don't actually help anyone and are actually hurtful.

No doubt there is a market for Linux servers that hold your hand and do not require any particular experience to administer. That niche is already almost completely filled by Windows server operating systems.

But if you did that to most existing Linux server setups, what you would end up would be something that is every bit as crippled as Windows server setups typically are, as in the simple things are simple, and the hard things are impossible. Can you imagine the user interface required to completely configure everything Apache can do, for example? Or Bind? or Exim? or practically anything else that does anything serious?

Without hundreds of millions of dollars in GUI configuration tool investment and automation interfaces to work around them, a text configuration file free Linux server distribution would either be a toy, or something that targets a relatively narrow market. For desktops though, it is probably great. Maybe for SOHOs as well. But not for practically everywhere where UNIX type servers dominate today.