Re: Linux Future
Russ Allbery wrote:
> Adam Borowski <kilobyte@angband.pl> writes:
>
> > There are two ways to design a system:
> > * a monolithic well-integrated system, granting features and efficiency at
> > the cost of portability and hackability
> > * the traditional Unix way, with a stress on replaceable tools that do only
> > one thing, granting freedom to tinker, using the system in a way not
> > envisioned by its creators
>
> ...at the cost of occasional complex, difficult-to-debug interactions
> between the separate components, and a larger total code base to support
> fallbacks and alternatives to provide loose coupling between the
> components.
>
> Just to complete both sides of the picture. (I'm more of a second camp
> person myself, but they both have drawbacks.)
>
> The traditional UNIX way is great if everyone can agree on a clean and
> minimal API between the components that enables thorough independent
> testing of the components and minimizes complex multi-component
> interactions. Were that this were always the case.... Most of the places
> where people reach for other strategies are places where it's not clear
> those conditions hold.
>
> Whenever you have a complex programming problem, break it into a client
> and a server. Now you have two complex programming problems, a protocol
> design problem, and a security vulnerability.
I'd add to this that the appropriate approach to the same problem can
change over time. Using modular components can be a good strategy when
you're trying to get the basic functionality working and it's likely it
turns out you need to completely redo parts of the approach. However,
when increasing the quality of something, it's natural for integration
level to go up. Few real problems are truly modular. At a basic level
you have can just have independent "parser for file format X" and "IO
layer", but when you get closer to optimal program behavior, "parse file
format X when input comes from disk" and "parse file format X when input
comes from network stream" may no longer be the same task.
You could build a basic browser from components like UI for displaying
bitmaps and relaying mouse clicks, an IO layer, and a HTML renderer that
lists required extra resource files, then after getting the contents of
those returns a rendered bitmap of the page. These could have simple
APIs and could be developed by different people with little interaction.
But when you move to higher-quality browsers, you'll at least need APIs
with hundreds of elements. Those will require the developers to
cooperate much more closely, and it won't be easy to switch to an
"equivalent" component.
Reply to: