Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.ecn.uoknor.edu!solace!nntp.uio.no!news.cais.net!newsfeed.internetmci.com!in2.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.os.linux.development.system,comp.unix.bsd.386bsd.misc,comp.unix.bsd.bsdi.misc,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc,comp.os.linux.advocacy
Subject: Re: Historic Opportunity facing Free Unix (was Re: The Lai/Baker paper, benchmarks, and the world of free UNIX)
Date: Tue, 23 Apr 1996 19:05:17 -0700
Organization: Me
Lines: 135
Message-ID: <317D8C5D.EE043D9@lambert.org>
References: <NELSON.96Apr15010553@ns.crynwr.com> <31794DB6.7DE974DF@lambert.org> <y5aspdwo4fb.fsf@graphics.cs.nyu.edu> <317BEFB7.72D52E7@lambert.org> <4ljc18$cia@thing.demon.co.uk>
NNTP-Posting-Host: hecate.artisoft.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.1.76 i486)
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:22214 comp.unix.bsd.386bsd.misc:816 comp.unix.bsd.bsdi.misc:3482 comp.unix.bsd.netbsd.misc:3335 comp.unix.bsd.freebsd.misc:18067 comp.os.linux.advocacy:46974
Malc Arnold wrote:
[ ... Systems vs. Applications Programming: Why there are free
operating systems and tools but not free applications ... ]
] >It's less challenging because after a memory fault, you can
] >post-mortem the problem instead of having to repeat it up to
] >the point it occurs and remember what happened just before it
] >lost its mind... and then reboot. For cascade errors, reboot
] >iteratively until you find the source of the cascade.
]
] This is probably a valid view. But these don't make the actual
] coding harder, they simply make finding and solving problems
] harder (OK, a *lot* harder). I've worked on large apps with adb
] as my only debugger. Does make it more challenging...
Well, I think there is an element of "in the zone" to be
considered here. Once you are "in the zone", you are
focused on the application and not on the tools.
I think rebooting significantly interrupts the workflow...
you have to spend time waiting for the reboot, then spend
time reestablishing your environment, etc.... after which,
you're no longer "in the zone" and you have to spend time
getting back there as well.
A cognitive psychologist would call this establishing depth
of concentration.
It's no coincidence that Bill Gates rocks back and forth
with mild autistic rhythm when thinking about things...
he's *not* doing "the pee-pee dance". ;-).
] >Aesthetics are a seperate problem, and usually reflects a need
] >to include a graphic designer, or at least tools which generate
] >code in strict conformance to style guidelines.
]
] Well, either of those is a good way to produce *bad* apps.
Religiously following the style guidelines on, for instance,
A Window 95 control panel, makes the control panel look as
if it were an integrated part of Windows 95.
The same goes for installing standard fonts in shell extensions
for right-button-down, instead of picking a "more readable"
font.
For a user it is more important that the interface hang together
than if your new "click-list widget" would reduce the number
of controls he has to use. None of the training he has had
previously, and none of the books on Windows 95 would tell him
what he's supposed to do with a "click-list widget".
You could "make his life easier" by reducing the number of
controls, but how often do you have to change the address
and ports used by your video card?
] It'll probably work a lot better if it's designed by a small
] group of people, with plenty of feedback from users through the
] development process (umm, hang on, that's more-or-less how Linux
] gets developed...). The aesthetic and functional design of an
] app is most of the fun. The rest is simply getting it out of
] your head and into the computer.
8-) 8-).
Doing the guts of a program is the most fun; once you know that
your design will work, painting the box is boring.
] >I don't think writing useful applications takes the same skills
] >(or as much skill, anyway) as writing good systems code. Of
] >course, I'm a systems person, so I could be a teensy bit
] >prejudiced there. 8-).
]
] I'll take a shot at a (friendly) rejoinder (as an apps
] programmer I'm a little prejudiced too, although I plan on
] getting into some systems work at some point). I don't think
] either is particularly easy; although it's a lot easier to get
] away with doing it wrong in applications work.
Yes; this is a better way of saying it than what I said.
] On the other hand, you can ignore OS portability (as opposed to
] hardware portability, which also affects apps) in systems work.
] You don't need a fairly encyclopedic knowledge of what system
] calls and library functions you can rely on being there, which
] ones have different semantics on different systems, which ones
] you can emulate or do without, and so on. POSIX helps, but if
] you want to be *really* portable you still need to be aware of
] other platforms, including older unices.
This assumes you even intend your application to run on a platform
other than Windows 95. Most commercial products are not even
built with that intent in the background. The resulting code
will fail to operate on Windows NT for Alpha or MIPS (assuming
it operates on Windows NT for Intel), just as it will fail for
UNIX, because of architecture portability issues. API portability
is generally the least of their worries.
Which is why this subthread about the lack of UNIX applications
started in the first place. 8-).
[ ... ]
] OTOH, most system work (in a decently-designed system) tends to
] be confined to a small part of the system at a time (conceptually
] that is, not in terms of how widely the changes are spread).
] A device driver is often a relatively small chunk of code with a
] clearly-defined API to the remainder of the kernel. Yes, there are
] some issues, like interrupts, which you don't have to worry about
] when you're writing an app, but then, remember how much *bigger*
] many apps are.
Compartmentalized design and API layering works for applications
as well. It's only a problem if you skip your design phase and
go directly to code. Again, application space is more forgiving
of this type of coding.
] In summary, systems and apps work require different skills, not
] different skill levels. But the consequences of getting it
] wrong are *much* worse in systems than in apps.
I think skill is part of coming up with a good, architecture
neutral design... if it weren't, we'd have more of them.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.