Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mira.net.au!vic.news.telstra.net!act.news.telstra.net!psgrain!newsfeed.internetmci.com!iol!tank.news.pipex.net!pipex!dispatch.news.demon.net!demon!thing.demon.co.uk!not-for-mail From: malc@thing.demon.co.uk (Malc Arnold) 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: 23 Apr 1996 20:45:44 +0100 Organization: Team Limpid Lines: 129 Message-ID: <4ljc18$cia@thing.demon.co.uk> References: <NELSON.96Apr15010553@ns.crynwr.com> <31794DB6.7DE974DF@lambert.org> <y5aspdwo4fb.fsf@graphics.cs.nyu.edu> <317BEFB7.72D52E7@lambert.org> NNTP-Posting-Host: thing.demon.co.uk X-NNTP-Posting-Host: thing.demon.co.uk Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:22271 comp.unix.bsd.386bsd.misc:830 comp.unix.bsd.bsdi.misc:3498 comp.unix.bsd.netbsd.misc:3350 comp.unix.bsd.freebsd.misc:18096 comp.os.linux.advocacy:47031 In article <317BEFB7.72D52E7@lambert.org>, Terry Lambert <terry@lambert.org> wrote: >David Fox wrote: >] As a systems person who is struggling to become an applications >] person, I must strenuously disagree. "Getting the cursor to the >] right screen location" isn't less challenging, its just a very >] different sort of challenge. Finding a SCSI driver race condition >] is a well delineated, unambigouous task, you know exactly when >] you've done it. > >[Snip] >It's less challenging because you can use a source level debugger. So design the system so you can at least post-mortem it. It might take a while, but think how much easier it'll be after you've done it :-) >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... >[snip] > >] Much of applications work tends to involve aesthetic judgement, >] which is something that puts off a lot of people in the systems >] crowd, including me. > >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. 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. >] The hitch is, to do it well also requires the skills that are >] required to do good systems work. The problem we're having >] with applications is that it is done best by people who fall >] into the intersection of the two groups, and that's hardly >] any group at all. > >Free applications, certainly, fall into the intersection. I >have been amazed at the number of collegues I have had over >the years who claim they program only because it is their job, >don't program for themselves, ever, and fully intend to get >onto the management track as quickly as they possibly can. Yeah, I know plenty too. Don't understand them at all. I should point out that I'm not discussing the stuff shoved out by corporate drones at far-too-many commercial software houses, where cost is rated considerably more important than quality. I'm a bit of a purist really... >[more snippage] >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. Attention to the detail of what you're doing is just as important in producing a good application as it is in doing good systems work. What makes the difference is that you can cut corners in applications and still have it work.... most of the time. I'll refer you to all those Unix tools that don't check the return from system calls, "silently truncate lines longer than 512 characters", and other caveats from hell. These are "caveats" in apps, but "disasters" in systems. >Applications code is *significantly* more forgiving of a lack >of talent for code... at the applications level, you can treat >the computer as a black box and not have to understand the >fundamentals of how it operates. To a large extent, thanks >to modern tools, you can even fail to understand the code >that the compiler will generate, and produce working application >code. 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. >Certainly system space is not free from this intrusion... one >obvious example is ANSI C, whose prototypes render it unnecessary >to have a good memory or full knowledge of the system interfaces >with which you are working. Just like calculators have >black-boxed arithmatic for many students. But the system space >intrusion (so far, at least) has remained very small. 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. 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. >Maybe I'm just getting old? 8-). You might say that, I couldn't possibly comment :-) -- M a l c . . . | "We've checked, and it's definitely not a bug. (malc@thing.demon.co.uk) | It's fixed in the new release." -- Help line.