Job Control, Shl (retrofitting)

[Ozan Yigit]

In article <2619 at brl-smoke.ARPA> Barry Shein writes:
>
>Not sure if this has anything to do with window systems though, I suspect
>in the end they will push for their own solutions beyond just extrapolations
>of current features, otherwise it's the tail wagging the dog. The point of
>a window system is, ultimately, to make the user's life easier, not
>to show how some current 'job control' can be pushed to its limits.
>
>	-Barry Shein, Boston University

	This is (in my opinion) a very important point: There is only
	so much *retrofitting* an operating system can take, without
	fairly major re-thinking and re-design of the kernel. If
	this is not done, the end result is various abominations UN*X
	factions love to hate: shell-layers etc. for berkefolk, and 
	signals, csh, job-control for sys-?-folk.

	Compatibility with earlier versions of UN*X is a nice ideal,
	but when it starts to exert a heavy price from the system, or
	from its users, things will have to be re-designed, perhaps
	at the expense of compatibility.

	To illustrate a point: would you write/use a filter for
	troff that handles TeX & LaTeX input, and tries to typeset
	an approximation, knowing full well troff "engine" is not
	powerful enough to handle TeX way of doing things, and it
	simply has to cludge its way ?? Does one have to live
	with restrictions like "well, we could almost do that, but
	frobotz will overflow if you do bar, and you have to include
	gawgaw to get a similar layout" ??

	This simply means that there is a *limit* to how much one
	can retrofit troff, without re-thinking major parts of its
	typesetting algorithms, and the way it handles its commands
	etc.

	The same thing applies to UN*X as far as process control,
	window management etc. considered. The berkeloids *did*
	re-think the way things are handled in the UN*X kernel,
	and added signals. While many considers this a major hack,
	it had to be done, just like kernel had to be modified to
	get vmun*x !! (would you like to implement a virtual memory
	system with pipes and forks, just so that kernel remains as
	simple as before, and somehow compatible ? :-) [note that
	I am not saying they did *the right thing*, all I am saying
	is that they were on the *right track*]

	Perhaps it is time to consider when UN*X (vanilla versions)
	stops being *as simple as possible* and becomes *simpler*.

	[and he falls from the soapbox, into the hands of the
	angry audience.. nobody yet claimed responsability for the
	resulting mayhem..]

	oZ
-- 

Usenet: [decvax|allegra|linus|ihnp4]!utzoo!yetti!oz
Bitnet: oz@[yusol|yuyetti]
	Join USAGUR [USers AGainst Un*x Retrofitting]
	and support GNU	[the alternative].