[ProgClub list] So, why aren't we using Unix as god intended?

Asher Glynn asher.glynn at gmail.com
Thu Oct 27 00:05:02 AEDT 2011


> Was starting to write a blog post, but throwing an early discussion point
>> out, possibly relevant to John's courses at the moment
>>
>
> Thanks for starting a thread! :)
>
> p.s. Where's your blog?

Will send a link after I finish the post


>
>  Looking at a list of key Unix features, and the way its actually used at
>> the
>> moment, its kind of interesting how little is actually used:
>>
>> Intent: Small processes chained together to do bigger things
>> What happened: Big programs with lots of options
>>
>
> While I was learning to install and configure Postfix, I read that someone
> was upset because if an email was addressed to them and to a mailing list
> they were subscribed to they would get the message twice under Postfix,
> whereas Sendmail would have omitted the duplicate. The reason Postfix
> couldn't support this feature was because of its modular design, whereas
> Sendmail, being monolithic, was able to implement that feature. If you look
> at the design of Postfix you will see the modular spirit of Unix shining
> through.

Postfix is like ancient dude! Was thinking more recent things (and here's
looking at you Oracle)


>
>
>  Intent: Multiple users
>> What happened: Single user running a daemon process OR a single user
>>
>
> I think what happened there was computers became much faster and much
> cheaper very quickly.

Even before that I think we were moving away from it - if you look at best
practice it almost dictates one user per machine now - although see security


>
>
>  Intent: Multiple applications per machine managed by priority
>> What happened: Single application per machine, or even virtual machine
>> with
>> the hypervisor sorting priority
>>
>
> That's mostly for security reasons I would say. If one of your processes is
> exploitable it can only affect the (virtual) machine running that process.
> It also makes administration simpler and introduces a level of redundancy
> which is good.


I think thats a retcon actually - hypervisors were rejected strongly as a
good way of isolating processes for most of the Unix community for a long
time; Unix was designed to be secure - so did it fail in its security model?

It simplifying administration is an interesting one as well - possibly
points to another fail on design. If you look at Unix its clearly designed
to run as much as you can fit on a box. A simpler OS supporting a single
user level process (aka CMS) might have been the right path. Its just
interesting that its such a notable deviation from design intent.



>
>  Intent: Use process per new task
>> What happened: Use a single process with a new thread per task
>>
>
> Well processes are more expensive than threads, and threads can share data
> without duplicating it.


Threads admittedly didn't exist back in the day and had to be retrofitted to
most Unixes. Its interesting that Unix didn't evolve to be able to manage
ever lighter processes to maintain the paradigm


>
>
>  Intent: Big machines managed efficiently
>> What happened: Lots of small machines managed by scale out
>>
>
> I think that's just how the economics played out.

It does mean we're living with a design that is past its use by date.


>
>
>  I know there's lots of reasons for this - the emergence of the Internet
>> and
>> vastly different workloads to those anticipated. But even some of the no
>> brainer things like using nice and user levels for isolation we've decided
>> to user hypervisors for instead, which is interesting, because one of the
>> original selling features of unix was security.
>>
>
> I haven't quite followed your last point, what has security to do with
> hypervisors?
>

A lot of admins don't like (as you alluded to before) like running multiple
processes on a machine for "security reasons" - which is a spectacularly
crap. They will quite happily run multiple VMs on the same physical kit and
not bat an eyelid about security. The key design objective for Unix was to
be able to run multiple processes in a secure, prioritised manner on a
single instance and no system admin is brave enough to even try nowadays

Its just an interesting dilemma - on the one hand Unix is crafted and guided
by many many design decisions that actually turned out to be bollocks in the
long term, so we're living with a design that no longer fits our usage
pattern.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.progclub.org/pipermail/list/attachments/20111026/9a4e3ecb/attachment.html>


More information about the list mailing list