This is good question...

Posted Nov 20, 2011 23:41 UTC (Sun) by dlang (guest, #313)
In reply to: This is good question... by khim
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"

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

to post comments

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 (guest, #51576) [Link]

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

$ shopt -s histappend