| Author |
Message |
Guest
|
 Posted:
Fri Nov 26, 2004 5:48 pm Post subject:
Re: Systems software versus applications software definition |
|
|
In article <m33byxkjqv.fsf@lhwlinux.garlic.com>,
Anne & Lynn Wheeler <lynn@garlic.com> wrote:
| Quote: | Jan Vorbrüggen <jvorbrueggen-not@mediasec.de> writes:
I would disagree. For me system software is more or less equivalent
to being part of the trusted computing base, with the more or less
implied side effect that if something unexpected goes wrong with it,
you need to crash the system. Handling hardware is only part of
that, and there are scenarios where you can have software driving
hardware directly without being part of the TCB - rare, but it has
happened. Performance - sure, you would want that, but correctness
is top priority. As a counterpoint, how many OSs have you seen that
have been compiled with optimization for the particular processor
model they will run on?
when i did the resource manager ... there was something like 2000
(automated) tests that took 3 months elapsed time to run as part of
calibrating and verifying the resource manager.
http://www.garlic.com/~lynn/subtopic.html#bench
the standard system maint. process was monthly update (patch?)
distribution called PLC (program level change). It would ship the
cumulative source updates as well as the executable binaries.
I was asked to put out monthly PLC for the resource manager on the
same schedule as the standard system PLC. I looked at the process, and
made a counter-offer of quarterly PLC for the resource manager
.... since I would have to take all the accumulated patches (for the
whole system) and rerun some significant number of the original
validation suite .... and there just weren't the resources to do that
on a monthly basis.
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock
|
Yup. TW always said that the only way to ship bugless software was
to ship every day or not ship at all. Boy! Finding the compromise
to that one was difficult, a PITA, and different with each and every
project we ever did. And that was _without_ PHB and NIH interference.
Add the last two, and I still am amazed that we ever shipped anything
at all.
| Quote: |
reference to the original resource manager product announcement
http://www.garlic.com/~lynn/2001e.html#45
note that much of the bits & pices that was in the resource manager
had been available in earlier kernal ... but were dropped over period
years. it was eventually decided to collect them up and package them
as a separate distribution.
this was in the period of some transition from free to charged for
software. at the time, there had been soem distinction that
application software could be charged for ... but kernel/system
software (as part of supporting the machine) was free.
the resource manager got to be the guinee pig for the first charged
for kernel software component ... with a new distinction that kernel
software that was directly related to hardware software would still be
free ... but other types of kernel software could be charged for.
a interesting paradox then showed up for the next release. the
resource manager shipped with the release prior to the release that
shipped smp support.
http://www.garlic.com/~lynn/subtopic.html#smp
however much of the SMP design and implementation was predicated on
various features that were part of the resource manager. the problem
was that SMP support was obviously directly supported hardware and
therefor was free ... but now had integral dependancies on features in
the resource managere ... which was priced.
|
That's how you would make money for an SMP. Our way was to
put the "service driver" for SMP on one magtape. When the customer
paid for the support, he would automatically get the tape
containing CPNSER.MAC as a part of the distribution. Each
and every other monitor module had SMP code in it under a
feature test switch and we shipped that on our monitor
distribution tape which went to all customers.
The way JMF designed the marketing change to support three
instead of two CPUs was to very carefully never mention the
word "two", using "multi" instead. Thus, we never had to
remaster a tape, had all the testing done with the previous
release, and just change the PD-something. No documentation
mentioned two (it also said multi).
To get DEC to officially "support" more than two CPUs on a system
took nine fucking months; this was a measurement of the internal
processes of product prevention that had completely infected DEC
by 1982.
/BAH
Subtract a hundred and four for e-mail. |
|
| Back to top |
|
 |
Toon Moene
Guest
|
| Posted:
Sat Nov 27, 2004 4:58 pm Post subject:
Re: Systems software versus applications software definition |
|
|
Richard Steiner wrote:
| Quote: | Here in comp.lang.c,
Juhan Leemet <juhan@logicognosis.com> spake unto us, saying:
p.s. hated octal, esp. on 8-bit byte machines like PDP-11 ! or VAX ?!?
It works very well in the 36-bit word-oriented environment I still play
in at work, though. 9-bit ASCII bytes. :-)
|
Or, for the real stuff: 60-bit words ... the original CDC Cyber series !
Real Programmers can find bugs buried in 6 Megabyte core dumps :-)
--
Toon Moene - e-mail: toon@moene.indiv.nluug.nl - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ |
|
| Back to top |
|
|
Sander Vesik
Guest
|
| Posted:
Sun Nov 28, 2004 12:17 am Post subject:
Re: Systems software versus applications software definition |
|
|
In comp.arch ptth@tom.sfc.keio.ac.jp wrote:
| Quote: | jrefactors@hotmail.com (Matt) writes:
How do we define systems programs? when we say systems programming,
does it necessary mean that the programs we write need to interact
with hardware directly? For example, OS, compiler, kernel, drivers,
network protocols, etc...? Couple years ago, yes, I understand this is
definitely true. However, as the software applications become more and
more complicated, some people try to argue that. Some people argue the
definition of systems programs depend on the level of abstractions. I
heard people saying that web server is a systems software, which I
feel confused. I think web server is an application software. Yes,
other applications run on top of web server.
Please advise and discuss. thanks!!
Well, our prof. counted couples of software to be the system level:
0. Operating Systems.
1. Sofwares which widely use system calls. (socket is a kind of system
call, and thats why we talk about web servers as system softwares)
|
This is a bad deifinition. For example, it potentialy leaves backup
software and most of system maintenance stuff out but lets web servers
and other solid application level stuff in.
| Quote: | 2. Compilers and interpreters.
hopes it helps.
|
--
Sander
+++ Out of cheese error +++ |
|
| Back to top |
|
|
glen herrmannsfeldt
Guest
|
| Posted:
Sun Nov 28, 2004 3:46 am Post subject:
Re: Systems software versus applications software definition |
|
|
| Quote: | Here in comp.lang.c,
Juhan Leemet <juhan@logicognosis.com> spake unto us, saying:
p.s. hated octal, esp. on 8-bit byte machines like PDP-11 ! or VAX ?!?
|
The VAX was DEC's first hex machine. There was a story that
around the time of the announcement they published a
calendar with the dates in hex. The Fortran compiler supported
hex constants and format codes. The instruction fields were
in groups of four bits, unlike the PDP-11 where the instruction
fields, especially register numbers, grouped in threes.
(Though I still prefer hex for the PDP-11.)
-- glen |
|
| Back to top |
|
|
Lin Mi
Guest
|
| Posted:
Sun Nov 28, 2004 9:03 pm Post subject:
Re: Systems software versus applications software definition |
|
|
Sander Vesik wrote:
| Quote: | In comp.arch ptth@tom.sfc.keio.ac.jp wrote:
jrefactors@hotmail.com (Matt) writes:
How do we define systems programs? when we say systems programming,
does it necessary mean that the programs we write need to interact
with hardware directly? For example, OS, compiler, kernel, drivers,
network protocols, etc...? Couple years ago, yes, I understand this is
definitely true. However, as the software applications become more and
more complicated, some people try to argue that. Some people argue the
definition of systems programs depend on the level of abstractions. I
heard people saying that web server is a systems software, which I
feel confused. I think web server is an application software. Yes,
other applications run on top of web server.
Please advise and discuss. thanks!!
Well, our prof. counted couples of software to be the system level:
0. Operating Systems.
1. Sofwares which widely use system calls. (socket is a kind of system
call, and thats why we talk about web servers as system softwares)
This is a bad deifinition. For example, it potentialy leaves backup
software and most of system maintenance stuff out but lets web servers
and other solid application level stuff in.
|
Plz explain your first point.
For web servers, to my opinion, they're widely using TCP/IP stack, which
is OS built-in functions. Therefore, at least they are not *such* high
level apps.
| Quote: |
2. Compilers and interpreters.
hopes it helps.
|
--
Lin Mi (Rin Fuku)
ptth@tom.sfc.keio.ac.jp
Faculty of Environmental Information
Hagino-Hattori Laboratory
Keio University, Shounan-Fujisawa Campus |
|
| Back to top |
|
|
Joe Wright
Guest
|
| Posted:
Sun Nov 28, 2004 9:37 pm Post subject:
Re: Systems software versus applications software definition |
|
|
glen herrmannsfeldt wrote:
| Quote: |
Here in comp.lang.c,
Juhan Leemet <juhan@logicognosis.com> spake unto us, saying:
p.s. hated octal, esp. on 8-bit byte machines like PDP-11 ! or VAX ?!?
The VAX was DEC's first hex machine. There was a story that
around the time of the announcement they published a
calendar with the dates in hex. The Fortran compiler supported
hex constants and format codes. The instruction fields were
in groups of four bits, unlike the PDP-11 where the instruction
fields, especially register numbers, grouped in threes.
(Though I still prefer hex for the PDP-11.)
-- glen
|
Octal (0..7) came about because of a need to 'say' binary. In the
day, the 'character' was six bits wide, all upper case and 'A' was
something like '100001' if I recall correctly. Split into groups of
3 we get '100' and '001'. Everybody could keep that much binary in
their heads and could 'see' four and one.
If asked the value of 'A' it was a blessing to say 'four one' rather
than 'one zero zero zero zero one'.
Then in the 1960's everything changed. Fairchild Semiconductor
invented the Integrated Circuit, the IC. They could now put hundreds
of transistors on one piece of silicon. The whole idea of designing
circuits from individual transisters died an almost instant death.
The new IC's were virtually circuit boards on a chip. In 1963 IBM's
new 7094 CPU was nearly the size of a city bus, required tons of air
conditioning, had 36-bit memory word, 6-bit character, 7-channel
magnetic tape, fixed record size 80 characters per record (punched
card). Perhaps the youngest (last) dinosaur.
IBM at the same time had embraced the IC and in 1964 introduced
their System 360 which was the first machine to this generation. The
old six-bit character (BCD) was severely limiting and 7-bit ASCII
was nipping at their heels. Digital Equipment, Data General, Pr1me,
etc. were giving them hell with ASCII. Hence in an attempted leap
forward, IBM uses IC's. The IC designers think 2, 4, 8 and don't
know what to do with 3 or 6.
So the new character is 8 bits and becomes Extended BCD Interchange
Code (EBCDIC). New terms, byte (the 8-bit thingy) nybble (half a
byte) were current in 1964. I'm not sure IBM did this.
The IC counters were 4-bits wide, not 3. The modulus was 16, not 8
and Octal died. Hexadecimal is born. Simply add six alpha characters
to the ten decimal ones and we have '0123456789ABCDEF' for our set.
--
Joe Wright mailto:joewwright@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein --- |
|
| Back to top |
|
|
Jim Cownie
Guest
|
| Posted:
Mon Nov 29, 2004 2:06 pm Post subject:
Re: Systems software versus applications software definition |
|
|
Nick Maclaren wrote:
| Quote: |
In article <m3ekigc1o6.fsf@averell.firstfloor.org>,
Andi Kleen <freitag@alancoxonachip.com> writes:
|> An optimizing compiler consists of many passes that talk to each other
|> using complex data structures and even a special intermediate
|> language. ...
Yes, but at least that is within a single product. It gets much
hairier (managerially and technically) when the interfaces are
between separate products, perhaps even developed by separate
organisations.
|
Tell me about it ! As someone who writes a third party debugger for a
living I certainly fell the pain of dealing with many ill specified
external interfaces. A debugger is certainly dependent on more such
interfaces than a compiler.
--
-- Jim
--
James Cownie <jcownie@etnus.com>
Etnus, LLC. +44 117 9071438
http://www.etnus.com |
|
| Back to top |
|
|
Michel Hack
Guest
|
| Posted:
Mon Nov 29, 2004 8:53 pm Post subject:
Re: Systems software versus applications software definition |
|
|
jrefactors@hotmail.com (Matt) wrote in message news:<ba8a039e.0411241600.3d00f9a1@posting.google.com>...
| Quote: | How do we define systems programs?
|
One view (certainly not the only one) distinguishes between programs that need
or expect some privilege (e.g. supervisor state) from those that don't (though
they may use privilege-requiring services through a system-call interface).
In this view, system programs *must* be written carefully, since a malfunction
can have global effects; application programs should never be able to do worse
than shoot themselves in the foot (local and bounded side-effects only). This
last assumption depends of course on a properly fenced execution environment,
which most people don't enjoy.
Michel. |
|
| Back to top |
|
|
Nick Maclaren
Guest
|
| Posted:
Mon Nov 29, 2004 9:00 pm Post subject:
Re: Systems software versus applications software definition |
|
|
In article <61706c80.0411290753.125d2246@posting.google.com>,
hack@watson.ibm.com (Michel Hack) writes:
|> jrefactors@hotmail.com (Matt) wrote in message news:<ba8a039e.0411241600.3d00f9a1@posting.google.com>...
|> > How do we define systems programs?
|>
|> One view (certainly not the only one) distinguishes between programs that need
|> or expect some privilege (e.g. supervisor state) from those that don't (though
|> they may use privilege-requiring services through a system-call interface).
|>
|> In this view, system programs *must* be written carefully, since a malfunction
|> can have global effects; application programs should never be able to do worse
|> than shoot themselves in the foot (local and bounded side-effects only). This
|> last assumption depends of course on a properly fenced execution environment,
|> which most people don't enjoy.
And which most systems don't enable :-(
Even when they do, there is the concept of programs that neither
need nor expect ANY privilege, but are likely to be used at a
relatively high privilege level. Even the proponents of that
view don't claim that a shell or basic utility need not be
implemented to the same standard as a 'system' program.
Regards,
Nick Maclaren. |
|
| Back to top |
|
|
Sander Vesik
Guest
|
| Posted:
Tue Nov 30, 2004 10:45 pm Post subject:
Re: Systems software versus applications software definition |
|
|
In comp.arch Lin Mi <ptth@tom.sfc.keio.ac.jp> wrote:
| Quote: | Sander Vesik wrote:
In comp.arch ptth@tom.sfc.keio.ac.jp wrote:
jrefactors@hotmail.com (Matt) writes:
How do we define systems programs? when we say systems programming,
does it necessary mean that the programs we write need to interact
with hardware directly? For example, OS, compiler, kernel, drivers,
network protocols, etc...? Couple years ago, yes, I understand this is
definitely true. However, as the software applications become more and
more complicated, some people try to argue that. Some people argue the
definition of systems programs depend on the level of abstractions. I
heard people saying that web server is a systems software, which I
feel confused. I think web server is an application software. Yes,
other applications run on top of web server.
Please advise and discuss. thanks!!
Well, our prof. counted couples of software to be the system level:
0. Operating Systems.
1. Sofwares which widely use system calls. (socket is a kind of system
call, and thats why we talk about web servers as system softwares)
This is a bad deifinition. For example, it potentialy leaves backup
software and most of system maintenance stuff out but lets web servers
and other solid application level stuff in.
Plz explain your first point.
For web servers, to my opinion, they're widely using TCP/IP stack, which
is OS built-in functions. Therefore, at least they are not *such* high
level apps.
|
In which case so are (n)curses text editors, as they use low level terminal
i/o a lot. You definition basicly makes any network app be systems software,
something that I don't think is a good thing.
--
Sander
+++ Out of cheese error +++ |
|
| Back to top |
|
|
George Neuner
Guest
|
| Posted:
Thu Dec 02, 2004 10:55 pm Post subject:
Re: Systems software versus applications software definition |
|
|
On Thu, 25 Nov 2004 01:44:20 +0100, Matej Barac
<matej.barac@gmail.com> wrote:
| Quote: | On 25 Nov 2004 00:26:42 GMT, Gordon Burditt wrote:
The video driver in Microsoft Windows probably calls Internet
Explorer to actually access the hardware :-( In any case, Microsoft
claims IE is so tightly bound into the OS you can't remove it.
I think they said that under oath in court, too.
Kind of off topic, but... IE can be "safely" removed from the OS.
|
You can remove the IE executable, but that program is not Internet
Explorer. What you interact with is just a thin shell around a COM
control that provides the browser functions. The IE program does
little more than instantiate that control and provide a window for it
to scribble on.
You can hunt down and remove the various incarnations of the
"WebBrowser" control, but doing so may break the Explorer shell if
"Active Desktop" functions are enabled and can render the shell
completely unusable. The help systems in 2K and XP, MS Office and
many 3rd party applications also use the browser control. And the
browser control itself relies on other controls which can't be
removed.
Microsoft exaggerated but they were not lying. Removing IE results in
reduced functionality ... that is if the system still works at all.
George
--
for email reply remove "/" from address |
|
| Back to top |
|
|
Anne & Lynn Wheeler
Guest
|
|
| Back to top |
|
|
Nick Maclaren
Guest
|
| Posted:
Sun Dec 05, 2004 12:09 am Post subject:
Re: Systems software versus applications software definition |
|
|
In article <uu0r2rp3q.fsf@mail.comcast.net>,
Anne & Lynn Wheeler <lynn@garlic.com> wrote:
| Quote: | Anne & Lynn Wheeler <lynn@garlic.com> writes:
i've frequently claimed that to take a straight forward written
application and turn it into a "service" ... it takes 4-10 times the
code and ten times the work.
|
My viewpoint is slightly different, and I dissent. If you spend
3 times the effort in design, BEFORE you start, you can reduce the
amount of code to about twofold and the amount to effort to about
threefold.
But I agree that your figures are correct if the application wasn't
designed to be a service in the first place. At at least 3 other
people (including, I think, Fred Brooks) have said the same.
Well, as I know, I agree with that. But you also know that I am
convinced that the IT world is STILL heading away from there :-(
Regards,
Nick Maclaren. |
|
| Back to top |
|
|
Anne & Lynn Wheeler
Guest
|
| Posted:
Sun Dec 05, 2004 3:46 am Post subject:
Re: Systems software versus applications software definition |
|
|
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
| Quote: | Well, as I know, I agree with that. But you also know that I am
convinced that the IT world is STILL heading away from there :-(
|
when i got to do the resource manager
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock
one of the supporting processes was an automated test & benchmarking
process
http://www.garlic.com/~lynn/subtopic.html#bench
and eventually did one sequence of 2000 benchmarks taking 3 months
elapsed time before first customer ship.
with the benchmarking process ... was able to define almost any sort
of workload characteristics ... including very stressful ones that
turned out were guarenteed to crash the system. early on as a result of
this ... one of the side-tracks was to go in and completely redesign
and rewrite the kernel serialization infrastructure ... that resulted
in the elimination of all stress-test induced system failures as well
as all observed situations of hung/zombie processes .... some of
hung/zombies as well as other fault diagnostic stuff
http://www.garlic.com/~lynn/subtopic.html#dumprx
the main product release after the release of the resource manager
included SMP support ... which had a lot of dependencies on the
resource manager code ... which then created a business problem.
http://www.garlic.com/~lynn/subtopic.html#smp
the resource manager wss the first forey into priced kernel software
with guidelines that direct hardware support kernel software was
still free. having smp "free" software dependent on priced (resource
manager) software violated those business guidelines. As a result ..
something like 80percent of code in original resource manager was
removed and incorporated into the "base, free" kernel software.
so problem reporting and fix process had a procedures that assigned
a number (that was incremented sequentially) and fixes for specific
problems were given the same number. with the very first version
of vm370, the numbering started ... and as far as i know may never
have been reset (i think i've recently seen references to sequential
numbers in the 60k range?).
Any way ... if you have to be dilligent to maintain kernel integrity
(failures because of dangling activities after processes have gone
away) and/or hung/zombie processes (waiting for some activity
to complete). A couple releases after the resource manager went out,
there was a fix introduced into the dispatcher to ignore various
kinds of events under certain circumstances; this had a fix number of
something like 15,3xx (or maybe 15,1xx?). In any case, it resulted
in re-introducing hung/zombie processes.
This occured after i had redone the i/o system to make it bullet proof
so the disk enginneering lab could do their work in an operating
system environment ... instead of doing everything with dedicated,
stand-alone machines:
http://www.garlic.com/~lynn/subtopic.html#disk
I created an update that removed the effects of the fix that
re-introduced hung/zombie processes ... and tried to find out what was
the original justification for generating it in the first place.
of course, all the ha/cmp work was pretty much trying to figure out
how to retrofit availability andd assurance to existing
infrastructures
http://www.garlic.com/~lynn/subtopic.html#hacmp
the stuff for electronic commerce was someplace in-between ... characterize
all possible failure modes anywhere in the infrastructure ... and then
define recovery and/or diagnostic processes to handle every possible
scenario. ... aka the previous electronic commerce ref
http://www.garlic.com/~lynn/2004p.html#23
however, in approx, the same electronic commerce time-frame ... we
looked at taking a more systemic approach. we had a jad with taligent
about their environment ... taking the analogy from the original
os/360 system services .... what taligent characteristics would be
needed for assurance and availability system services. we had a one
week JAD where we walked thru all of the taligent infrastructure,
specifying what needed to be added/changed for assurance and
availability. at the end, we had come up with two new
availability/assurance frameworks ... and, in addition, about a 30%
hit to the existing taligent frameworks
you would still need the up-front failure analysis ... but could
possibly reduce application code lines from a 4-10 times increase to
possibly only a 1.5 to 2.0 times increase (with some higher level
assurance and availability abstrations being provided by the taligent
infrastructure).
random past taligent references:
http://www.garlic.com/~lynn/2000e.html#46 Where are they now : Taligent and Pink
http://www.garlic.com/~lynn/2000e.html#48 Where are they now : Taligent and Pink
http://www.garlic.com/~lynn/2000.html#10 Taligent
http://www.garlic.com/~lynn/2001j.html#36 Proper ISA lifespan?
http://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
http://www.garlic.com/~lynn/2002.html#24 Buffer overflow
http://www.garlic.com/~lynn/2002i.html#60 Unisys A11 worth keeping?
http://www.garlic.com/~lynn/2002j.html#76 Difference between Unix and Linux?
http://www.garlic.com/~lynn/2002m.html#60 The next big things that weren't
http://www.garlic.com/~lynn/2003d.html#45 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003e.html#28 A Speculative question
http://www.garlic.com/~lynn/2003g.html#62 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003j.html#15 A Dark Day
http://www.garlic.com/~lynn/2004c.html#53 defination of terms: "Application Server" vs. "Transaction Server"
http://www.garlic.com/~lynn/2004l.html#49 "Perfect" or "Provable" security both crypto and non-crypto?
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ |
|
| Back to top |
|
|
Anne & Lynn Wheeler
Guest
|
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in