OSen that don't suck...
Alistair J. R. Young
However, hopefully ones that suck less than others do. And, having
been struck by the sudden urge to try putting a non-sucking one
together myself (mainly so that I can finally run something on my
machines that I can stomach for long periods), I'd like to hear
everyone's opinions on exactly what they'd like (or need) to see in
the mythical non-sucking OS.
All comments welcomed, no matter how much they contradict the
preliminary design I've got already! :)
Thanks in advance,
Alistair
--
Computational Thaumaturge -- Sysimperator, dominus retis deusque machinarum.
e-mail: avata...@arkane.demon.co.uk WWW: http://www.arkane.demon.co.uk/
"Teachers always say that [there's no such thing as a free period], unless
they've got one themselves, and then they just sit in the staffroom drinking
coffee and having sex!" -- Toyah Battersby, "Coronation Street"
Alistair J. R. Young
Joel Baker <luc...@prophecy.lightbearer.com> (== lucifer)
praised Shub-Internet thus:
> On 02 Oct 1998 07:06:23 +0000, Alistair J. R. Young
> <avatar...@arkane.demon.co.uk> wrote:
>> machines that I can stomach for long periods), I'd like to hear
>> everyone's opinions on exactly what they'd like (or need) to see in
>> the mythical non-sucking OS.
> A reasonable package system that allows for both easy "defaults"
> installation and reasonable customization. Prefferably one that can do
> a merge between your existing files, or at the very least, give you the
> chance to see the diffs between old and new and hand-integrate. (Think
> CVS source merges)
Agreed, absolutely (especially that latter feature). Of course, for
the next 0.n versions it's most likely to be a case of 'here is fdisk,
here is dd, here is tar, pray', but for 1.0, definitely.
> A well-documented and sanely structured file tree that allows for ready
> installation of across multiple machines and platforms.
Well, platforms will be pretty limited, I'm afraid, certainly at
first. I own all of one platform, and that not the best one. :(
> Yes, I know this means symlink hell or a remapping filesystem; I
> consider that an acceptable price :)
Symlinks we have in plenty. The kernel itself will create a few when
it starts up, to ensure that no matter which physical device/partition
they're on, system configuration files will always be available at
///.etc/, and so forth. I don't suppose it's much more of a stretch to
let the kernel config file and/or switch point it wherever you want them,
even across the network so you have ///.etc/ -> //bigserver/someshare/etc/,
and likewise for the rest of them. Home directories were always going
to work along those lines, which was why I'm so insistent on all
per-user configurations sitting under ~/.profile somewhere. And a good
deal of it should be handled by the Magic Distributed Naming Service,
once I get around to thinking hard about that.
I get the idea now that I've missed your point entirely, so please
correct me if I have... <sigh>
[snip]
> Upgrades should be seamless. If you have to replace a library, it should
> be done so that no reboot, relink, or other such cruft is required (this
> can be technically difficult, but if Debian can go a.out too ELF without
> a reboot, it's clearly plausible :)
Hmm. This gets rather nastily complicated by the fact that I was
planning on a semi-OO API, and so far as I've figured so far, that
implies C++ with attendant fragile base class problems, etecetera. My
(partial) solution runs along the lines of 'if you have binaries you
intend to distribute, or that you don't want to have to relink, link
them with the *specific* version of the library, i.e. libfile-1.0
rather than just libfile [1]; break this guideline at your own
risk. BTW, in these cases, *don't* use the experimental versions...'
I was also thinking of an API to let you change libraries out from
under process still using them - basically, it shoves a copy into the
swap area and switches existing processes to use that rather than the
actual library file until they terminate. Of course, if you need to
replace a library that sysserv depends on, you're pretty much stuck
until you can restart the system, but at least you're only using a
little extra memory until the next scheduled downtime rather than
having to restart the whole shebang *now*.
> Basic implementations of daemons, et al, that don't suck. Sadly, some of
> this depends on what underlying OS you choose to work off of. At least, I
> assume you're talking about "OS" as in "package of tools and kernel", and
> not "writing new kernel".
Well, both, actually. Using one of the existing kernels that are
available almost certainly means that it'd be Another Bloody Unix, and
over recent months I've developed a Unixophobia to almost match my
Windows one. No fork(), no hard links, proper threads, heaven...
> If the latter, why the hell are you asking us? :)
Well, I'm fairly new to this kernel-writing lark. I'd hate to miss a
good idea that I could, er, swipe. :)
Alistair
[1] Which would be a symlink to the latest specific-version one.
--
Computational Thaumaturge -- Sysimperator, dominus retis deusque machinarum.
e-mail: avata...@arkane.demon.co.uk WWW: http://www.arkane.demon.co.uk/
"Those who live by the sword, die by the sword. So do those who don't, but
they do it more quickly." -- me.
Tony Finch
>
>I absolutely agree that system-level rights should be mediated via
>some means other than cryptography. [...] I think the Right Solution
>is for protected kernel code to be keeping track of these things
>rather than for programs to have to keep passing around private and
>public keys.
Seconded, mostly from performance reasons -- if you're going to impose
a cryptographic penaly on every transaction that requires privilege
("Ooh! The mouse has moved! Do tell me where!") your OS will suck to a
stupendous degree.
Also, access rights do not need to be brokered entirely by kernel
code: all you need is a trusted process that can say "yes, you are
allowed to do that", allowing you to keep mechanism in the kernel and
policy in userland.
Tony.
--
gg yhf**f.a.n.finch
fa...@demon.net
d...@dotat.at
Tony Finch
>
>This gets rather nastily complicated by the fact that I was planning
>on a semi-OO API, and so far as I've figured so far, that implies C++
>with attendant fragile base class problems, etecetera.
Why do you have to base your OO design on something so crapulous as C++?
Would it not be better to brovide some more generic basis that's
appicable to as wide a range of languages as possible?
>> Sadly, some of this depends on what underlying OS you choose to
>> work off of. At least, I assume you're talking about "OS" as in
>> "package of tools and kernel", and not "writing new kernel".
>
>Well, both, actually. Using one of the existing kernels that are
>available almost certainly means that it'd be Another Bloody Unix, and
>over recent months I've developed a Unixophobia to almost match my
>Windows one. No fork(), no hard links, proper threads, heaven...
If you're starting from scratch where are you going to get the useful
software from? Linux is only popular because all the software that
makes it useful already existed. The software that makes it useful is
free and either Gnu or Unix, and each of them is both the same.
Tony.
--
f.a.n.finch**??id6890
fa...@demon.net
d...@dotat.at
Peter da Silva
Russ Allbery <r...@stanford.edu> wrote:
>Cryptography is useful for those cases where one *can't* get a stronger
>security model for one reason or another, usually because some external
>interface that crosses untrusted systems is necessary.
And there, the cryptographic information should be used by systems to
authenticate to each other (for file access, for example, or IPC), or by
applications to authenticate to each other (for communication between
untrusted domains). NT tries to combine both models...
--
This is The Reverend Peter da Silva's Boring Sig File - there are no references
to Wolves, Kibo, Discordianism, or The Church of the Subgenius in this document
> We must make sure our momentum aligns with our value-added distribution! <
Russell Nelson
> ...do not exist. I know.
>
> However, hopefully ones that suck less than others do. And, having
> been struck by the sudden urge to try putting a non-sucking one
> together myself (mainly so that I can finally run something on my
> machines that I can stomach for long periods), I'd like to hear
> everyone's opinions on exactly what they'd like (or need) to see in
> the mythical non-sucking OS.
From: nelson (Russell Nelson)
Subject: Re: more on the horror
Date: Wed, 4 Dec 96 15:19:21 EST
Lord Among Panthers writes:
> So, let's posit for a minute that the Unix user interface/operating
> environment/whatever you want to call it does in fact suck.
>
> And let's posit that someone (other than the NextStep folks, good
> answer CZ...) were interested in doing something about it.
>
> What would you have them do?
<snicker> <snicker> Let a kid loose in a candy shop, eh?
1) I'd introduce a lighter-weight GUI.
2) I'd give it a single API.
3) I'd have user-fucking-interface guidelines.
3a) These would include pie menus.
3b) The keyboard would be a peer of the mouse, not an inferior.
4) The command-line system would be able to ask the application for
its options.
5) It would have a way to ensure that Kelly isn't going to try to
redirect this thread.
6) The documentation would all be in structured HTML.
7) It would have Unix(tm) emulation libraries.
Is that enuf?
-russ <nel...@crynwr.com> http://www.crynwr.com/~nelson
Crynwr Software sells network driver support | PGP ok
521 Pleasant Valley Rd. | +1 315 268 1925 voice | The more corrupt the state,
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | the more numerous the laws.
From: nelson (Russell Nelson)
Subject: Re: more on the horror
Date: Tue, 10 Dec 96 00:22:36 EDT
Question: Are programs going to be able to assume the presence of a
GUI? What about programs that have to run when the system doesn't
have the GUI running yet? What about programs that have to run when
the system is too broken to run the GUI? Have two versions? Do you
emulate the GUI using character graphics? Maybe have a set of level-0
GUI functions with two libraries: text and graphics modes?
The GUI has to be damn lightweight if every program is going to use
it.
Andrew writes:
> >Lord Among Panthers writes:
> > > So, let's posit for a minute that the Unix user interface/operating
> > > environment/whatever you want to call it does in fact suck.
> > >
> > > And let's posit that someone (other than the NextStep folks, good
> > > answer CZ...) were interested in doing something about it.
> > >
> > > What would you have them do?
>
> In article <1996120420192...@desk.crynwr.com> Russ he say:
> >1) I'd introduce a lighter-weight GUI.
> >2) I'd give it a single API.
>
> across all programming languages, not just c-family crap.
Well, right. This is directed towards a "reduce the cost of
programming" goal, so yes, it would be the same for everything.
> >3) I'd have user-fucking-interface guidelines.
> >3a) These would include pie menus.
>
> and hopefully user-selectable look and feel for folks already
> trained on another gui.
I disagree. Make the damn thing work as best as you can, then let
people adapt. Too many options makes the system too complicated to
use.
> >3b) The keyboard would be a peer of the mouse, not an inferior.
>
> keyboard and mouse would be abstractions that the user programs
> didn't have to know or care about...
> keyboard = mouse = footpedal = harmonica...
The intent here is that menus are keystrokable as well as mousable.
> >4) The command-line system would be able to ask the application for
> >its options.
>
> command tables.
Later you said "
> command tables (paths are a crock) with full shell support for
> pop-up option choosing based on the shell grammer (filename completion
> alone does not cut it), and case-sensitivity optional,
"
That is exactly what I meant. At any point in the command line you
should be able to say "what the fuck goes here; help me enter it".
This obviously requires the cooperation of every program.
> >5) It would have a way to ensure that Kelly isn't going to try to
> >redirect this thread.
Well, we voluntarily took it off void, I guess, so this is one feature
we can strike.
> >6) The documentation would all be in structured HTML.
>
> linuxdoc. (linuxdoc is an sgml flavor that will spit html, latex, nroff
> and about anything else one might desire.)
How easy is it to write? How easy is it to fuck up?
> Decent math and stat libraries,
> decent app function libraries such as spellcheckers, date math,
> hashing functions, parsers, etc.
> a complete regex system (ie, grep should not need the -i and -v flags),
Might reasonably enough want to start with some of the modules that
have been written for Perl, and code them in C.
> SMP, MPP,
Just another library?
> threads,
> dynamic loadable and unloadable kernel modules,
> network bootable,
> disk space mappable as shared global sections,
Linux has these already.
> able to checkpoint dump and recover for a fast boot,
I don't understand what this is.
> a real filesystem (capable of transaction and user-defined record processing,
> journaling, versioning, ACLs that interface with the network filesystem and
> network file servers such as web servers, fault-tolerance with
> multiple hosts on the same scsi bus accessing the drives
> and booting off the same kernel, a defragmenter,
Apparently e2fs doesn't need defragging.
> slots like the newton objects have to tack on user info in a portable
> fashion, hinting for block allocation,
> mirror and stripe support, integral heirarchical support for media from serial
> (tape is just a disk with poor seek times; optimize for it) to ramdisk with
> sysadmin-selectable caching algorithms and hinting API, user selectable
> deletion levels from "mark as going away soon" to "frag the media",
> and for kicks object storage),
Definitely deletion levels: 5=keep it if you can, 4=delete it if you
must, 3=may have some small value in the future, 2=immediately
reusable, 1=destroy any copies extant.
> api's allowing apps to be network stack and filesystem independant without
> crocks like winsock.dll shims and without users needing to mess
> with source,
Hmmm... Sounds like Plan9. There is certain value in being able to
name all objects accessible to the system.
> an object security model something like NT's, but that actually (unlike NT's)
> gets _used_ by stuff,
Oh hell, stupid things like creating a usr for the printing subsystem
instead of fucking using root all the time.
> integrated internet patch control for the sysadmin,
Oh, like configuration management?
> full remote control capability including power management,
Power management is part of the OS; full remote just means that you
can do anything, but ANYTHING.
> no per-fucking-user licensing bs.
Of course!
-russ <nel...@crynwr.com> http://www.crynwr.com/~nelson
Crynwr Software sells network driver support | PGP ok
521 Pleasant Valley Rd. | +1 315 268 1925 voice | The more corrupt the state,
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | the more numerous the laws.
From: nelson (Russell Nelson)
Subject: Re: more on the horror
Date: Wed, 11 Dec 96 15:50:30 EDT
Okay, how about this: The UI of the system assumes that it can pop up
dialog boxes, alert boxes; all the usual stuff we've gotten used to.
The system has two dynamic libraries with identical entry points: one
graphical and the other text. It makes a link to the right one
depending on which mode it's in. Obviously there are some things that
you can't do in a text-based UI. If you can't do it, it's not part of
the level-0 UI, it's part of the level-1 UI.
If the program doesn't require interaction during its execution; if
all of its user-interface is run once before any operations, then the
program will also accept its setup on the command line.
> I'd say that expecting a vt100 is not too much to ask, and the gui
> should be able to function with that.
Right.
> > The GUI has to be damn lightweight if every program is going to use
> > it.
>
> yes and no. the gui can be pretty big as long as it is efficient.
> it has to be lightweight in terms of cpu and per-task memory loading,
> but it does not have to be a small code segment. of course, small
> is relative; the mac toolbox gui calls take about 2MB, which is about
> the right size; OTOH, the decstation that I'm sitting at uses just
> over 5MB of virtual memory for every motif/decwindows vt300 terminal
> that it has running.
Ugh. That's why I think the UI should link to a dynamic library. If
you need lightweight, you use the curses-type library.
> > I disagree. Make the damn thing work as best as you can, then let
> > people adapt. Too many options makes the system too complicated to
> > use.
>
> if one wants commercial acceptance, look and feel have to be similar
> to systems that the user base is already trained to use, ie windows, win95,
> cics, and macintosh. most gui concepts are portable across look and feels;
> there is a nice library I've seen for sunos 4 that has a look and feel
> menu on the apps it generates; you can just select windows, openlook, or motif,
Cool. Yes. The system should have different dynamic libraries for
different L&F.
> and it just works. it is not the options that make the system complicated,
> it is a poor interface for accessing the options, and having defaults
> that blow your foot off. Xdefaults is in many ways a model of how not to
> do things.
Yes, yes, yes. Xdefaults must die.
> > > >3b) The keyboard would be a peer of the mouse, not an inferior.
> > > keyboard and mouse would be abstractions that the user programs
> > > didn't have to know or care about...
> > > keyboard = mouse = footpedal = harmonica...
> > The intent here is that menus are keystrokable as well as mousable.
>
> that is mandatory, yes. however, they should also be usable by folks
> with various disabilties, and accessible to embedded i/o devices.
> of course, this is probably more a hardware issue than an os issue.
No, it's a UI design requirement that says that everything must be
selectable using a small number of on/off inputs. Like, with pie
menus, if you don't have a mouse, then you hit the "menu" key. Then
you hit the "select key", which moves the selection around the pie.
Once you've gotten your choice, you let go. Then you hit the "done"
key. Or maybe the selection also cycles through "nothing selected",
and hitting the "menu" key again picks the thing you've selected.
> > > >4) The command-line system would be able to ask the application for
> > > >its options.
> > > command tables.
> > Later you said "
> > > command tables (paths are a crock) with full shell support for
> > > pop-up option choosing based on the shell grammer (filename completion
> > > alone does not cut it), and case-sensitivity optional,
> > That is exactly what I meant. At any point in the command line you
> > should be able to say "what the fuck goes here; help me enter it".
> > This obviously requires the cooperation of every program.
>
> oh; I thought you meant having a --help flag that worked on gui apps.
No. The application has to be able to accept a partial command line,
use the UI to get the rest of the command line (start-up options),
then hand them back to the shell.
So if I was going to make up a perl script, I'd do this:
perl + <foo >bar
Then perl would give me a UI from which I would select the -e option,
which would give me a little editor (part of the UI). I'd enter my
perl script, then hit "Ok". That would throw me back to the shell,
with my perl options. Like this:
perl -e 'piffle;biff' <foo >bar
> > > >6) The documentation would all be in structured HTML.
> > > linuxdoc. (linuxdoc is an sgml flavor that will spit html, latex, nroff
> > > and about anything else one might desire.)
> > How easy is it to write? How easy is it to fuck up?
>
> I haven't written any yet, but it shouldn't be significantly harder
> than html. given a decent editor, it should be no harder to screw up.
> a decent system editor is mandatory, and probably needs to be an
> integral part of the os, ala xedit on vm/cms.
Yes. The editor would mostly be a front-end to the UI text edit box.
> > > Decent math and stat libraries,
> > > decent app function libraries such as spellcheckers, date math,
> > > hashing functions, parsers, etc.
> > > a complete regex system (ie, grep should not need the -i and -v flags),
> > Might reasonably enough want to start with some of the modules that
> > have been written for Perl, and code them in C.
>
> c. I'm not sure about coding in c.
> buffer overun lossage is just too damn easy.
> most of unixes security problems have been traceable to being
> authored in c.
That's the C library, not C. You should look at Dan Bernstein's
library. There is no such thing as a buffer overrun problem.
> > > SMP, MPP,
> > Just another library?
>
> also major kernel architecture issues,
> as well as affecting thread and IPC systems.
Oh, sorry, I thought you were talking about a parallel-processing
language. No, SMP (what's MPP?) should be included (Linux already has
it for Pentiums at least).
> > > able to checkpoint dump and recover for a fast boot,
> > I don't understand what this is.
>
> cause the OS to spit state into a file and (optionally) halt.
> this means that you can then have a fast bootstrap by just sucking
> state back in and resetting hardware dependant stuff like clock and
> keyboard scan. it also allows extensive failure mode diagnosis by
> being able to easily recreate a situation. I believe that tops20
> could do this, and I think linux on certain laptops may be able to
> as part of the power-conservation strategy.
Yes, my IBM TP500 can do this. It would take careful programming of
device drivers.
> > Apparently e2fs doesn't need defragging.
>
> Whoa! How did they manage that?
I don't know. Probably on-the-fly defragmentation. Or, if you want
to be buzzword-complient, just-in-time defragmentation.
> > > slots like the newton objects have to tack on user info in a portable
> > > fashion, hinting for block allocation,
> > > mirror and stripe support, integral heirarchical support for
> media from serial
> > > (tape is just a disk with poor seek times; optimize for it) to ramdisk with
I thought you could only append to a tape? But yes, you need to be
able to have a super-filesystem, which would migrate files between
real filesystems as it decides. Linux has the hooks to do this, but I
don't know that anyone has.
> > > an object security model something like NT's, but that
> actually (unlike NT's)
> > > gets _used_ by stuff,
> > Oh hell, stupid things like creating a usr for the printing subsystem
> > instead of fucking using root all the time.
>
> eh. having a process owned by the os itself is not inherently a problem
> if that process has its abilities limited by security objects and kernel
> runlevels. otoh, having major subsystems have their own name and control
> space can be convenient for administration.
Security has to be easy, otherwise it won't be used.
> > > full remote control capability including power management,
> > Power management is part of the OS; full remote just means that you
> > can do anything, but ANYTHING.
>
> right. no fucking console blinking "Hit F1 to continue".
I've been thinking, for quite some time now, of how you could make a
"Internet Console" for a PC. It would have to emulate an MDA, serial
port for mouse emulation, and keyboard (with an external cable to plug
into the keyboard port). It would have to have a processor, memory,
and Ethernet. Problem of course is that it would cost "too much".
Advantage is that you could access the console from any PC on site.
> oh yeah, the api also should force use of a standardized error logging
> and management facility.
Which is another way of saying that syslog must die.
-russ <nel...@crynwr.com> http://www.crynwr.com/~nelson
Crynwr Software sells network driver support | PGP ok
521 Pleasant Valley Rd. | +1 315 268 1925 voice | The more corrupt the state,
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | the more numerous the laws.
Peter da Silva
like. Really.
In article <m2k92ig...@desk.crynwr.com>,
Russell Nelson <nel...@crynwr.com> wrote:
>1) I'd introduce a lighter-weight GUI.
I don't consider a GUI to be an inherent part of the OS. But something that
talks through sockets/ports/files would be cool.
>3a) These would include pie menus.
Hell no. menus would NOT be implemented by the application, but by the server
(that is, the application says "this window owns these menus" and leaves it
up to the window system and the user's display options to render them).
>3b) The keyboard would be a peer of the mouse, not an inferior.
Extending 3a, that's up to the user.
>4) The command-line system would be able to ask the application for
>its options.
Without executing any application code.
>6) The documentation would all be in structured HTML.
Some SGML DTD anyway. HTML is too limited.
>Question: Are programs going to be able to assume the presence of a
>GUI?
No. See 3b above.
>I disagree. Make the damn thing work as best as you can, then let
>people adapt. Too many options makes the system too complicated to
>use.
I refuse to use pie menus, sorry.
>That is exactly what I meant. At any point in the command line you
>should be able to say "what the fuck goes here; help me enter it".
>This obviously requires the cooperation of every program.
Not if you have command tables. Then it just requires the tables being defined.
Even better you can do THAT now.
> > threads,
> > dynamic loadable and unloadable kernel modules,
Preferably not. Preferably the kernel doesn't do anything but handle processes
and IPC.
> > able to checkpoint dump and recover for a fast boot,
>I don't understand what this is.
Save the whole system state to disk, and then unpack it and continue
execution. Obviously this needs driver support.
> > an object security model something like NT's, but that actually (unlike NT's)
> > gets _used_ by stuff,
>Oh hell, stupid things like creating a usr for the printing subsystem
>instead of fucking using root all the time.
There's nothing in UNIX that says you have to do that. In fact I've used lpr
systems that don't run as root. You *do* have to have it run as a user that
has read access to all files, though.
>Okay, how about this: The UI of the system assumes that it can pop up
>dialog boxes, alert boxes; all the usual stuff we've gotten used to.
>The system has two dynamic libraries with identical entry points: one
>graphical and the other text.
Ick. No. The basic GUI objects are all handled by the server, so if you're
in text mode it handles them as text. That also helps with handicapped
people, they can run a braile or spoken or joystickable interface.
>Yes, yes, yes. Xdefaults must die.
You won't be able to get rid of something like Xdefaults/Registry/Data Fork.
>Then perl would give me a UI from which I would select the -e option,
>which would give me a little editor (part of the UI). I'd enter my
>perl script, then hit "Ok". That would throw me back to the shell,
>with my perl options. Like this:
>
>perl -e 'piffle;biff' <foo >bar
You can implement this *now* without having to midufy any programs.
Me, I'd like a GUI shell that involves glueing pipelines together, this
would then just be a special case.
[aside, UFS hasn't needed defragging for years.]
>I thought you could only append to a tape?
You put the metadata at the end, and when you write new stuff you append a new
metadata block. It's just like a logging file system without the cleaner.
> > oh yeah, the api also should force use of a standardized error logging
> > and management facility.
>Which is another way of saying that syslog must die.
I haven't seen one that's better than a generalized syslog. The changes I made
in the FreeBSD syslog make it a lot easier to usefully redirect specific
programs. I stopped just short of putting generalized regexps in there when
I found I didn't need them.
Alistair J. R. Young
Russell Nelson <nel...@crynwr.com> (== nelson)
praised Shub-Internet thus:
[various snippage, including misc attributions]
>> What would you have them do?
> <snicker> <snicker> Let a kid loose in a candy shop, eh?
> 1) I'd introduce a lighter-weight GUI.
Well, hopefully it will be more lightweight than X11, but then again,
that's fairly analogous to making it less painful than crucifixion.
> 3) I'd have user-fucking-interface guidelines.
Oh, those we will have. At least slightly backed up by the
uber-fascist stay-in-your-own-client-area-you-miserable-scum
window-managerFH.
> 3a) These would include pie menus.
These are menus shaped like pie charts, or something? Why?
> 3b) The keyboard would be a peer of the mouse, not an inferior.
Absolutely.
> 7) It would have Unix(tm) emulation libraries.
<wry look>
I think I'll leave them for someone who really wants them to write. I
pity the poor bastard who has to make fork() work on this system,
never mind somehow emulating all the other little misfeatu^Wquirks.
> Question: Are programs going to be able to assume the presence of a
> GUI?
Well, I for one would rather they didn't. If you're using the machine
as a server, after all, you're better off not running the
window-server process (which shouldn't, hopefully, prevent you from
displaying windowed clients remotely). On the other hand, it should be
easy enough to check (see below), and anyone who doesn't check return
codes probably deserves the consequences.
> What about programs that have to run when the system doesn't have
> the GUI running yet? What about programs that have to run when the
> system is too broken to run the GUI? Have two versions?
I think the best way to handle it (for programs that need to run
either way) is to have two different sets of UI functions depending on
what you need to do. Then you can call winInitialise (which I think
ought to go in the base library just so you can make this test even on
systems without the GUI installed) with impunity, test the return
value, and run in text mode if it turns out that the window-server
isn't running.
Either that, or stick the functionality of the program in a library
and provide two shells, one character-mode, one GUI, which call into
it. But I think I can safely leave that to the individual programmer's
discretion.
> The GUI has to be damn lightweight if every program is going to use
> it.
Well, you only need one copy of the window-server running for
everything, and with the rest of it being a shared library, it
shouldn't be *too* extreme.
>> >2) I'd give it a single API.
>>
>> across all programming languages, not just c-family crap.
> Well, right. This is directed towards a "reduce the cost of
> programming" goal, so yes, it would be the same for everything.
It would be a nice thought, if I can make it work without making the
API awkward in itself.
>> >3) I'd have user-fucking-interface guidelines.
>> and hopefully user-selectable look and feel for folks already
>> trained on another gui.
> I disagree. Make the damn thing work as best as you can, then let
> people adapt. Too many options makes the system too complicated to
> use.
I tend to agree with that, rather than with user-selectably radically
changing the look-and-feel. Apart from the fact that one random-thing
imitating another random-thing usually does it notably badly - the one
I usually point to are all the Unix ports to OS/2, which are still
*very* noticeably exactly that -, y
>> Decent math and stat libraries,
>> decent app function libraries such as spellcheckers, date math,
>> hashing functions, parsers, etc.
>> a complete regex system (ie, grep should not need the -i and -v flags),
Definitely. Most stuff that's needed by multiple applications - such
as spellcheckers, or file format translators - really ought to be part
of the OS in one way or another.
>> a real filesystem (capable of transaction and user-defined record processing,
>> journaling, versioning,
>> ACLs that interface with the network filesystem
So far as the native one is concerned, they'll be the only relevant
access control.
>> and network file servers such as web servers,
Well, it's a bit of a stretch, but possibly...
>> mirror and stripe support,
Not strictly in the filesystem. I figure it's a bit more versatile if
it's at a lower level. I hope to be able to support 'filter drivers' -
you point a mirroring driver, for example, at two identically sized
'block devices'/partitions /.dev/hda1 and /.dev/hdb1, and it uses
those two as the halves of the mirror and makes the mirrored volume
available as /.dev/mirr0 for you to mkfs, mount, whatever.
>> sysadmin-selectable caching algorithms and hinting API, user selectable
>> deletion levels from "mark as going away soon" to "frag the media",
>> and for kicks object storage),
> Definitely deletion levels: 5=keep it if you can, 4=delete it if you
> must, 3=may have some small value in the future, 2=immediately
> reusable, 1=destroy any copies extant.
What, as options to osDelete, or whatever? The last three I can
certainly see; the first two, though? Would four, say, just flag the
file as something that can be deleted if the system starts to run out
of free disc, or what?
>> api's allowing apps to be network stack and filesystem independant without
>> crocks like winsock.dll shims and without users needing to mess
>> with source,
Filesystem, hopefully. About network stacks? Ouch. I was only planning
to support one network stack, anyway...
> Oh hell, stupid things like creating a usr for the printing subsystem
> instead of fucking using root all the time.
Hopefully, it shouldn't matter if all the daemons are started running
as the system user. There's going to be a call in the security system
to create a restricted set of rights (a subset of the calling
process's, of course) and execute a process/thread with them; so, for
example, you could set up the mail daemon to have only full access to
TCP port 25, append access to /var/mail/*, and nothing else, without
having to create a special user for it to run under.
>> no per-fucking-user licensing bs.
> Of course!
Licensing will be included over my dead body. Well, over someone's
dead body, anyway...
> Okay, how about this: The UI of the system assumes that it can pop up
> dialog boxes, alert boxes; all the usual stuff we've gotten used to.
> The system has two dynamic libraries with identical entry points: one
> graphical and the other text. It makes a link to the right one
> depending on which mode it's in. Obviously there are some things that
> you can't do in a text-based UI. If you can't do it, it's not part of
> the level-0 UI, it's part of the level-1 UI.
In theory, I think it's a nice idea. In practice, on the other hand, I
tend to think there's just too much that doesn't translate well - and
by the time you've ripped that out, you've got either a text interface
that doesn't do very much, or a GUI that's limited to the point of
extreme suckage. Also, I tend to work in noticeably different ways
when doing similar things in a GUI vs. a CLI - if I'm configuring a
network interface in a GUI, for example, I'd much prefer a dialog box
with appropriate widgets to just typing a string of parameters into a
text field, but I know from experience that I find the text equivalent
of that unbelievably clunky. No thanks, and pass the ifconfig.
Shrug. Maybe that's just me. Comments?
> Oh, sorry, I thought you were talking about a parallel-processing
> language. No, SMP (what's MPP?) should be included (Linux already has
> it for Pentiums at least).
In theory. Of course, I can't test it, so... :(
>> cause the OS to spit state into a file and (optionally) halt.
>> this means that you can then have a fast bootstrap by just sucking
>> state back in and resetting hardware dependant stuff like clock and
>> keyboard scan. it also allows extensive failure mode diagnosis by
>> being able to easily recreate a situation. I believe that tops20
>> could do this, and I think linux on certain laptops may be able to
>> as part of the power-conservation strategy.
Erk. The idea I like, but it sounds like an absolute bastard to
implement. Er - probably, but probably not in the first
revision. Besides, apart from laptops, who turns machines off anyway?
>> oh yeah, the api also should force use of a standardized error logging
>> and management facility.
> Which is another way of saying that syslog must die.
So far, I'm leaning towards a built-in facility that lets programs log
their events in a nice, polished, standard format (browsable,
filterable, etc. by the user with a couple of utilities (one GUI, one
character, of course)) that they can attach chunks of random
supporting binary to if they think it'll help with debugging. That's
followed up by another utility that churns through the log database
and spits out a user-specified set of records and fields in a
user-specified format.
Then you can set that second one up to run every midnight or whatever
and then clear the log, and bingo, instant log rotation. Or you can
have it extract whatever log data, random binary chunks included, you
want in a format suited to however you need to analyse it.
Alistair
--
Computational Thaumaturge -- Sysimperator, dominus retis deusque machinarum.
e-mail: avata...@arkane.demon.co.uk WWW: http://www.arkane.demon.co.uk/
"Hey, I'm straight, but that doesn't mean I'm not interested in sex with
men." -- .sig files of the damned, #69 in a series. This contribution made
by R. James Coleman III <jim.c...@erols.com>
Peter da Silva
Russ Allbery <r...@stanford.edu> wrote:
>The piece of Unix that says you have to do this is this odd notion of
>using privileged ports as a means of passing authentication credentials.
The lpr service and the print spooler are unrelated, and the Berkeley
r-series style authentication is yet another issue.
The only privileged action the print spooler has to perform is reading the
file, and feeding it through a UNIX domain socket owned by lpd from an
unprivileged client.
The network protocols are a separate issue.
>So in specing a perfect system, do you specify your authentication
>mechanism or leave it up to user space?
Both. I think I addressed this in another message: you need authentication
between systems that share a trust domain, and application level authentication
for access to untrusted domains. The Samba attack on CIFS authentication in
Internet Explorer shows what happens when you try to combine the two.
>> I haven't seen one that's better than a generalized syslog. The changes
>> I made in the FreeBSD syslog make it a lot easier to usefully redirect
>> specific programs. I stopped just short of putting generalized regexps
>> in there when I found I didn't need them.
>But you really want to make socket writes *fast* to make syslog more
>efficient,
Since I'm promoting the idea of some port/socket/file handle/descriptor style
mechanism as the code of the system (ala Plan 9 and AmigaOS), that's sort of
assumed.
>and I think there's something to be said for allowing
>per-application listeners. I switched to using cyclog for SMTP and qmail
>logs and everything runs massively faster than when I was trying to shove
>everything through one pipe into syslog (and watching syslog sync to disk
>after every line).
This is the general problem of getting high performance from a microkernel
or message-based system. The core services have to stream quickly, with
internal threads or internal request queuing and buffering. This was the
basis of the original spat between Linus and Andy Tannenbaum, and why Linux
is a monolithic kernel. It's just so much EASIER to get good performance
that way.
>Linux syslog is substantially better than Solaris, since you can route
>things by priority specifically rather than just "everything above this"
>and you can turn off syncing to disk for specific logs,
The FreeBSD syslog routes things by program name as well as priority.
Running low priority logs non-synced is a cool idea... that's one reason
inews doesn't log through syslog, I believe.
Tony Finch
>
>This is the general problem of getting high performance from a microkernel
>or message-based system. The core services have to stream quickly, with
>internal threads or internal request queuing and buffering. This was the
>basis of the original spat between Linus and Andy Tannenbaum, and why Linux
>is a monolithic kernel. It's just so much EASIER to get good performance
>that way.
The main problem with a microkernel OS that relies on message passing
is that you have to be really cunning to avoid the sort of design
where you have to copy data umpteen times to get it from the
application to the hardware. Ideally you want no copies at all.
Tony.
--
ocmcocmcocmk**f.a.n.finch
fa...@demon.net
d...@dotat.at
Peter da Silva
You'd think that, but experience with Minix has shown that the real problem
is having commonly used components (like the file system) that are single
threaded. This leads to massive bottlenecks that totally swamp a few extra
copies.
Imagine a situation where two users call "open" at the same time.
If you have to wait for all the blocks involved in the path parsing to be
available before the filesystem handles messages from anyone else, then
the disk driver queuing algorithm becomes irrelevant, and you spend all
yor time waiting on the disk while other disk requests languish in the
message queue between the user app and the filesystem.
The alternative is to have the filesystem multi-threaded, or to have it part
out the "open file" request into a "read inode" request and a "complete
this file open" request that's triggered by the "read inode" completing.
Alistair J. R. Young
Russ Allbery <r...@stanford.edu> (== rra)
praised Shub-Internet thus:
> Sounds like VMS privileges. Which isn't a bad thing.
Could you point me to somewhere where I could get some more
(preferably reasonably in-depth) information on VMS? It certainly
sounds interesting, from what little I've picked up, but it's not
something I've ever encountered in person, as it were.
Alistair
--
Computational Thaumaturge -- Sysimperator, dominus retis deusque machinarum.
e-mail: avata...@arkane.demon.co.uk WWW: http://www.arkane.demon.co.uk/
"I learned long ago to keep my hands to myself when in a big room full of
shiny toys, unless it was my job to fuck things up."
-- Jeff Mercer, in the scary devil monastery
Tony Finch
>>
>>The main problem with a microkernel OS that relies on message passing
>>is that you have to be really cunning to avoid the sort of design
>>where you have to copy data umpteen times to get it from the
>>application to the hardware. Ideally you want no copies at all.
>
>You'd think that, but experience with Minix has shown that the real problem
>is having commonly used components (like the file system) that are single
>threaded. This leads to massive bottlenecks that totally swamp a few extra
>copies.
Given experience of single-threaded select-based unix applications,
this is probably true -- it's easier to fork that to ensure that all
event-handlers are non-blocking.
But assuming you have a decent implementation of threading, will you
get performance that's as good as on a monolithic OS? Will you be able
to run the applications that make the hardware useful as efficiently
as before?
Tony.
--
1421421**f.a.n.finch
fa...@demon.net
d...@dotat.at
Peter da Silva
>But assuming you have a decent implementation of threading, will you
>get performance that's as good as on a monolithic OS? Will you be able
>to run the applications that make the hardware useful as efficiently
>as before?
Maybe, maybe not. Maybe more: if you can speed up the IPC and process
management by removing complexity, things that involve creating a lot
of processes might be more efficient. Certainly good SMP will be easier.
If it's within 10 percent I don't think anyone will mind.
Russell Nelson
> Hell no. menus would NOT be implemented by the application, but by the server
> (that is, the application says "this window owns these menus" and leaves it
> up to the window system and the user's display options to render them).
Yeah, basically.
> >4) The command-line system would be able to ask the application for
> >its options.
>
> Without executing any application code.
>
> >6) The documentation would all be in structured HTML.
>
> Some SGML DTD anyway. HTML is too limited.
Right, I didn't know that I wanted SGML at the time.
> >Question: Are programs going to be able to assume the presence of a
> >GUI?
>
> No. See 3b above.
How do you talk to the user?
> >I disagree. Make the damn thing work as best as you can, then let
> >people adapt. Too many options makes the system too complicated to
> >use.
>
> I refuse to use pie menus, sorry.
Why? Have you tried them? Which implementation?
> > > threads,
> > > dynamic loadable and unloadable kernel modules,
>
> Preferably not. Preferably the kernel doesn't do anything but handle processes
> and IPC.
How do you drive devices without kernel-level privileges?
> > > an object security model something like NT's, but that actually (unlike NT's)
> > > gets _used_ by stuff,
>
> >Oh hell, stupid things like creating a usr for the printing subsystem
> >instead of fucking using root all the time.
>
> There's nothing in UNIX that says you have to do that.
Right, but the operating system should come that way by default.
> >Okay, how about this: The UI of the system assumes that it can pop up
> >dialog boxes, alert boxes; all the usual stuff we've gotten used to.
> >The system has two dynamic libraries with identical entry points: one
> >graphical and the other text.
>
> Ick. No. The basic GUI objects are all handled by the server, so if you're
> in text mode it handles them as text. That also helps with handicapped
> people, they can run a braile or spoken or joystickable interface.
Well, what I'm looking for is a way a program to talk to the user with
a full-screen interface. If a graphical UI can't fail, then fine, use
it. Otherwise make sure there's a workaround.
> >Yes, yes, yes. Xdefaults must die.
>
> You won't be able to get rid of something like Xdefaults/Registry/Data Fork.
Maybe not, but Xdefaults don't make me happy. Maybe if I used them
more I'd learn to like them.
> > > oh yeah, the api also should force use of a standardized error logging
> > > and management facility.
>
> >Which is another way of saying that syslog must die.
>
> I haven't seen one that's better than a generalized syslog. The changes I made
> in the FreeBSD syslog make it a lot easier to usefully redirect specific
> programs.
Perhaps the problem is not in the design but in the implementation.
For example, the syslog server should be able to inform the syslog
client that certain output can be discarded without sending it to the
client.
--
-russ nelson <rn-...@crynwr.com> http://crynwr.com/~nelson
Crynwr supports Open Source(tm) Software| PGPok | Freedom is the primary
521 Pleasant Valley Rd. | +1 315 268 1925 voice | cause of Peace, Love,
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | Truth and Justice.
Russell Nelson
< In article <m2emsnh...@desk.crynwr.com>,
< Russell Nelson <nel...@crynwr.com> wrote:
< >> >Question: Are programs going to be able to assume the presence of a
< >> >GUI?
<
< >> No. See 3b above.
<
< >How do you talk to the user?
<
< You send a structured stream describing the dialog to the display handler,
< and it decides how to render it subject to the limitations of the UI and
< the user's input.
<
< Having the UI implemented in SGML would do it.
Hmmm.... Maybe I wasn't thinking big enough.
< >> I refuse to use pie menus, sorry.
<
< >Why? Have you tried them? Which implementation?
<
< Piewm and a modified toolkit library that made apps do the pie thing.
<
< I understand the theoretical advantages, but in practice I found it
< confusing.
I've been using piewm for a while. Pie menus rock. I can select
three menus deep <<without ever seeing them>>.
< >How do you drive devices without kernel-level privileges?
<
< User-mode device drivers are not exactly a revolutionary idea. Nor user
< mode interrupt handlers.
<
< You ask the kernel for access to your I/O pages, and go from there.
Not particularly efficient on current hardware, and I'm limiting my
imagination to current hardware.
< >Perhaps the problem is not in the design but in the implementation.
< >For example, the syslog server should be able to inform the syslog
< >client that certain output can be discarded without sending it to the
< >client.
<
< Run that by me again?
I've found syslog to be rather inefficient for debugging-type output.
It's much more CPU efficient to create your own debugging system
because you can avoid a syscall by checking your own debug-level flag.
The current syslog implementations (that I've seen) have no way to
push the syslog matrix back into the client.
--
-russ nelson <rn-...@crynwr.com> http://crynwr.com/~nelson
Crynwr supports Open Source(tm) Software| PGPok | Freedom is the primary
521 Pleasant Valley Rd. | +1 315 268 1925 voice | cause of Peace, Love,
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | Truth and Justice.
Peter da Silva
>< >Why? Have you tried them? Which implementation?
>< Piewm and a modified toolkit library that made apps do the pie thing.
>< I understand the theoretical advantages, but in practice I found it
>< confusing.
>I've been using piewm for a while. Pie menus rock. I can select
>three menus deep <<without ever seeing them>>.
I'm familiar with the theory. But it doesn't work for me, and at least
as implemented in piewm it's amazingly ugly. I suspect it's like many
other things, different things work best for different people.
It'd be like having an OS where you could only use vi, or only use emacs.
>< >How do you drive devices without kernel-level privileges?
>< User-mode device drivers are not exactly a revolutionary idea. Nor user
>< mode interrupt handlers.
>< You ask the kernel for access to your I/O pages, and go from there.
>Not particularly efficient on current hardware, and I'm limiting my
>imagination to current hardware.
There are efficiency advantages to having drivers running in privileged
mode, but just because you're in privileged mode doesn't mean you're in
the kernel. It just means you have to be much more careful.
>I've found syslog to be rather inefficient for debugging-type output.
>It's much more CPU efficient to create your own debugging system
>because you can avoid a syscall by checking your own debug-level flag.
Logging and debugging aren't the same thing at all. You're right, you
shouldn't be using syslog for debugging. I tend to write code that looks
like this:
char *prog;
[...]
if(!(prog=strrchr(argv[0], '/')))
prog = argv[0];
[...]
logerr(char *msg)
{
char msgbuf[131];
sprintf(msgbuf, "%.64s: %.64s", prog, msg);
if(!daemonized)
fprintf(stderr, "%s\n", msgbuf);
else {
syslog(LOG_ERR, msgbuf);
}
}
When I'm debugging the service, it's rarely daemonized, so why mess around
with syslog at all? It's never the right thing to do.
Nick Danger
pe...@taronga.com (Peter da Silva) writes:
> An opaque object, such as a "file pointer" or "message port", that mediates
> all communications between the application and services. Everything should
> be couched in terms of sending messages to services, at the application level.
I'd like to see, in addition to this, a system with sufficiently
asynchronous design so that things like this would be possible:
When a process does a read or write or malloc or whatever, sending
the messages didn't block it unless it requested it.
write() prefixes message header onto buffer
and signals the target port that it
has an incoming message
module owning target port gets signal, wakes up,
looks at queue. If oldest message in queue
is older than x, with X being anything from
a few seconds in the case of an umimportant
processing queeue to the granularity of a
hard_clock, it processes the queue immediately,
if not, it immediately returns and sends
a 'deferred' signal to the calling process
and returns control to it, and waits to
process the queue at its next normal quantum
or signal.
original process does all other asynchronous read()s
or write()s or malloc()s or whatever,
until it requires something synchronous,
sleeps, or its quantum expires.
The module receiving the i/o or syscall request wakes up,
for whatever reason, and begins processing
requests. It runs through its queue(s) by
priority and age, and dispatches 'completed'
or 'denied' messages, or does whatever else
it needs to do to process the message.
original module may wake up again before requests
are completed. it acts accordingly.
This allows the entity with the most knowledge about its data's
function, the process using it, to determine what needs to happen
before something else does, and also has the advantage that
information can be passed synchronously or asynchronously at the
programmer's discretion through the same interface.
That's likely nothing new, but I think it would be seriously cool
:>
Russell Nelson
> I'm familiar with the theory. But it doesn't work for me, and at least
> as implemented in piewm it's amazingly ugly. I suspect it's like many
> other things, different things work best for different people.
Yes, I agree that it needs polish. I've improved them somewhat by
using shaped windows. http://www.crynwr.com/piewm.
But why doesn't it work for you? Did you give it enough time to get
"muscle memory" of the menus?
> It'd be like having an OS where you could only use vi, or only use emacs.
Well sure, but what we have now is an OS where you could only use vi (linear menus).
> There are efficiency advantages to having drivers running in privileged
> mode, but just because you're in privileged mode doesn't mean you're in
> the kernel.
If you avoid a context switch then you're in the kernel. At least as
far as *I* understand kernels and privilege levels. Feel free to correct.
> >I've found syslog to be rather inefficient for debugging-type output.
> >It's much more CPU efficient to create your own debugging system
> >because you can avoid a syscall by checking your own debug-level flag.
>
> Logging and debugging aren't the same thing at all. You're right, you
> shouldn't be using syslog for debugging.
Still, consider something like named's logging. Why generate an extra
syscall for every DNS request, just to find out that you're not
logging, which is the usual case.
Alistair J. R. Young
Tony Finch <d...@dotat.at> (== dot)
praised Shub-Internet thus:
> Alistair J. R. Young <avatar...@arkane.demon.co.uk> wrote:
>>
>> This gets rather nastily complicated by the fact that I was planning
>> on a semi-OO API, and so far as I've figured so far, that implies C++
>> with attendant fragile base class problems, etecetera.
> Why do you have to base your OO design on something so crapulous as C++?
Because I already know C, and I get the feeling that trying to learn a
new language simultaneously with the rest of the project (although I
am open to suggestions) might not be a good idea, mainly. And it's
probably easier to shoe-horn C++-style interfaces into other languages
than vice-versa.
Anyway, I'm not using the particularly crapulous features (or what I
think are they, anyway). About all I'm needing or thinking of using
from it are classes and some minimal inheritance.
> Would it not be better to brovide some more generic basis that's
> appicable to as wide a range of languages as possible?
Well, for genericity's sake I am contemplating using C+bletcherous
macros to achieve the same effect. Maybe. Depending on how ugly and
unmaintainable it promises to be.
>> Well, both, actually. Using one of the existing kernels that are
>> available almost certainly means that it'd be Another Bloody Unix, and
>> over recent months I've developed a Unixophobia to almost match my
>> Windows one. No fork(), no hard links, proper threads, heaven...
> If you're starting from scratch where are you going to get the useful
> software from?
Well, the minimal set I'll have to come up with myself; anything
beyond that I suppose will have to be ported or written from scratch -
unless someone manages to bash together a Unix compatibility
library. Not at all the best, I know, but...
> Linux is only popular because all the software that makes it useful
> already existed. The software that makes it useful is free and
> either Gnu or Unix, and each of them is both the same.
...in order to avoid that problem (everything being much the same in
most ways), you can't really not create this one. And if I was just
going to be producing another Unixalike, I wouldn't be bothering -
there are too many of them, IMO, already.
Alistair
--
Computational Thaumaturge -- Sysimperator, dominus retis deusque machinarum.
e-mail: avata...@arkane.demon.co.uk WWW: http://www.arkane.demon.co.uk/
"If raswr-j gets an external reputation for being cruel and demanding, I
think that's a good thing..." -- Michael Kozlowski, raswr-j contributor
Peter da Silva
Nick Danger <ni...@taronga.com> wrote:
>When a process does a read or write or malloc or whatever, sending
>the messages didn't block it unless it requested it.
[snip]
That seems like too complex an interface.
You would need a variety of options to "send message"... you need to specify
whether the "send" is synchronous or asynchronous, buffered or unbuffered,
and whether a response message is expected. On the Amiga, the normal "write"
message was asynchronous, buffered, with a response packet. So you would
have something like this:
sendmsg(port, respport, buffer, len, options);
(in the Amiga the response port was included in the buffer... it would make
security easier if the OS handled tracking and trading ports)
So for something like syslog(), where you don't expect a response, it would
be:
sendmsg(syslog_port, NULL, &message, len, ASYNC|BUFFER);
For something like write(), you could do it like this for streaming:
sendmsg(fd, rfd, &buffer, len, ASYNC|BUFFER);
And for a database commit:
sendmsg(fd, NULL, &buffer, len, SYNC);
To avoid redundant copies, an extra option that gets passed to the other
end telling it whether this block is pure data or contains control information
would help.
So here's a UNIX write:
write(int fd, char *buffer, int len)
{
int rfd = anon_msgport(options);
struct unix_response status;
if(!rfd) {
errno = EAGAIN;
return -1;
}
if(!sendmsg(fd, rfd, buffer, len, ASYNC|BUFFER|DATA)) {
errno = portstatus(fd);
if(!errno) errno=portstatus(rfd);
delete_msgport(rfd);
return -1;
}
if (!rcvmsg(rfd, NULL, &status, sizeof status)) {
errno = portstatus(rfd);
if(!errno) errno=portstatus(fd);
delete_msgport(rfd);
return -1;
}
delete_msgport(rfd);
errno = status.errno;
return status.nbytes;
Georg Bauer
<avatar...@arkane.demon.co.uk> wrote:
>Because I already know C, and I get the feeling that trying to learn a
>new language simultaneously with the rest of the project (although I
You are aware of the fact that C++ is a new language in regards to C, too?
Just because C++ uses many of C's idioms doesn't say it is the same
language at all ...
bye, Georg
Alistair J. R. Young
Georg Bauer <g...@hugo.westfalen.de> (== gb)
praised Shub-Internet thus:
Well, yes, but in part that depends entirely on how much of C++ you
use. I've never been a believer in 'OOP applied to everything' - what
I write is basically C with Classes, just using the class features and
limited single inheritance where it fits naturally and actually makes
the code clearer, rather than shoehorning everything into the OO
model. When that's all you're using, it's definitely close enough to C
for most work...
Although I'm tending much more towards C with strange macros attached,
now, for maximum genericity.
Alistair
--
Computational Thaumaturge -- Sysimperator, dominus retis deusque machinarum.
e-mail: avata...@arkane.demon.co.uk WWW: http://www.arkane.demon.co.uk/
"I learned all the sign language I know from television. Admittedly, that's
just 'I love you', 'I'm choking' and - oddly - 'Glasgow'; but if I'm ever
cruising for deaf rentboys in Scotland, I'll be set."
- .sigfiles of the damned, #668 in a series. Courtesy of Dave Hemming.
Tony Finch
>>
>>But assuming you have a decent implementation of threading, will you
>>get performance that's as good as on a monolithic OS? Will you be able
>>to run the applications that make the hardware useful as efficiently
>>as before?
>
>Maybe, maybe not. Maybe more: if you can speed up the IPC and process
>management by removing complexity, things that involve creating a lot
>of processes might be more efficient. Certainly good SMP will be easier.
One thing I think could improve performance is not having a different
memory space for each process, but instead having a single address
space for the whole shebang like in MacOS or the Amiga. Obviously
you'd have to augment what they have with access controls in order to
make the thing robust, but if you put message blocks in publically
readable pages then you get no copying IPC for free. You might also
get better cacheing performance if you have a virtually addressed
cache.
Tony.
--
i7yci7yci**f.a.n.finch
d...@dotat.at
fa...@demon.net
Tony Finch
Yep. It is kind-of predicated on that, although it would probably be
fine on a 32bit system, provided your memory allocation strategy is
cunning enough.
>You'd still be reloading page table entries on context switches, just
>not as many.
What would be nice is a CPU that allows you to reprogram the
protection options separately from the mapping parts of the page
tables. I don't know of any that do this, though, because most are
designed for the Unix process model.
Tony.
--
7yuc zhd2**f.a.n.finch
fa...@demon.net
d...@dotat.at
Alistair J. R. Young
Peter da Silva <pe...@taronga.com> (== peter)
praised Shub-Internet thus:
> Me, I'd like a GUI shell that involves glueing pipelines together, this
> would then just be a special case.
Me too. The problem seems to be finding a good way to represent them
visually. Then again, I do actually have an idea for how I might
implement them...
(The GUI shell is [probably] going to be very much like the OS/2
Workplace Shell, both visually and underneath, just to give everyone a
very general idea of what's going on.)
All the program reference objects have an extra couple of settings,
namely, whether they can accept input on stdin, and provide input on
stdout. When you set up a program for the GUI shell, you just tick
whatever's appropriate. (As an extra, it should come with a small
library of objects just for this purpose - cat, more, and so forth
adapted for the GUI environment).
To actually set a pipe up, you have a 'pipeline object'. When one's
open, it's basically a blank sheet onto which you can drag various
pipeline components (program references with the appropriate settings
set). Once they're dragged on there, they appear with a couple of
extra 'handles' attached to the icon, one representing the component's
input, the other its output. Drag arrows across between the handles to
represent the way you want data to flow through the pipeline (vaguely
similar to the MS Access Relationships sheet, actually), close it to
save, double-click the object to run the entire pipeline. Done!
(I suppose it would also be handy to have a way of defining one-shot
pipelines without making them persistent, but that's a secondary
issue.)
Comments?
Alistair
--
Computational Thaumaturge -- Sysimperator, dominus retis deusque machinarum.
e-mail: avata...@arkane.demon.co.uk WWW: http://www.arkane.demon.co.uk/
"Trouble is the FAQs keep organ-rejecting the newbies, or maybe vice-versa."
-- Dave DeLaney <d...@panacea.phys.utk.edu>
Alistair J. R. Young
> In article <m2emsnh...@desk.crynwr.com>,
> Russell Nelson <nel...@crynwr.com> wrote:
>> How do you talk to the user?
> You send a structured stream describing the dialog to the display handler,
> and it decides how to render it subject to the limitations of the UI and
> the user's input.
> Having the UI implemented in SGML would do it.
I have heard this idea. I am in love with this idea. I am off now to
implement this idea, or at least to write the DTD (I might stick with
XML, though) and put it to one side and on the Web site until I'm
ready to implement it...
It should improve the GUI performance a fair chunk as well, I think,
as it ought to cut down on the number of necessary calls from the app
to the window server. And with a little ingenuity (preloading common
dialogs en masse into the window server on app startup, allowing the
window server to manage enabling/disabling controls and so forth in
response to other controls being manipulated automatically, etc.),
that could add up to quite a considerable gain.
I think I might just stop short of window-server-side scripts,
though...
Alistair
--
Computational Thaumaturge -- Sysimperator, dominus retis deusque machinarum.
e-mail: avata...@arkane.demon.co.uk WWW: http://www.arkane.demon.co.uk/
"**Nobody** expects the Emacs Inquisition! Our chief weapon is Control. And
Meta. Out *two* chief weapons are Control and Meta. And Alt. Our *three* chief
weapons are Control, Meta and Alt. And Super. *Among* our chief weapons are
Control, Meta, Alt, Super and Hyper... and nice red mode-lines..."
-- me
Peter da Silva
>though...
For people working over slow links with a fast local display they'd be a big
win. Having them in SGML is the obvious way to go, but if not I'd recommend
Lisp or Forth (or maybe Postscript, but Postscript is a lot of work to get
right enough to satisfy the critics) for ease of implementation.
Mark Atwood
> implement this idea, or at least to write the DTD (I might stick with
> XML, though) and put it to one side and on the Web site until I'm
> ready to implement it...
>
> It should improve the GUI performance a fair chunk as well, I think,
> as it ought to cut down on the number of necessary calls from the app
> to the window server. And with a little ingenuity (preloading common
> dialogs en masse into the window server on app startup, allowing the
> window server to manage enabling/disabling controls and so forth in
> response to other controls being manipulated automatically, etc.),
> that could add up to quite a considerable gain.
>
> though...
NeWS for SGML instead of DPostscript is what you are describing...
--
Mark Atwood | But that's the way of the puritans - mind like a steel trap:
m...@pobox.com | you take the bait, and it snaps shut in its deathgrip.
| -- Rich Grise <rich...@entheosengineering.com>
Tony Finch
>win. Having them in SGML is the obvious way to go, but if not I'd recommend
>Lisp or Forth (or maybe Postscript, but Postscript is a lot of work to get
>right enough to satisfy the critics) for ease of implementation.
Not Java? Much as I like Lisp and Forth, I think it is worth making
use of the effort that is being put into Java to make it useful in a
windowed environment. It also has the advantage of greater type-safety.
Tony.
--
f.a.n.finch.523654357374743743747333764375697569700
fa...@demon.net
d...@dotat.at
Tony Finch
>
>Comments?
Typing is faster :-)
Tony.
--
f.a.n.finch**waster
d...@dotat.at
fa...@demon.net
Tony Finch
>>
>>Not Java?
>
>Not Java. If you want to use an object-oriented language then it would be
>better to make it a good one like Smalltalk or some of the Lisp derivitives,
>rather than a descendent of the horror known as C++.
It's semantically closer to Modula-3, but otherwise I agree with you :-)
(I still prefer typed languages.)
Tony.
--
dxoigmn**f.a.n.finch
fa...@demon.net
d...@dotat.at
r...@greenend.org.uk
a capital Y with an acute accent.)
It'd be nice to able to start with some stream of output (why stick to
just 2 when you can have 60?) going to somewhere you could look at it,
and then put some other program on the end of the pipe while the first
component is still running and have everything just work without
restarting things. When using bash &c I (and I assume most other
people) generally build up pipelines by bolting programs onto the
start or end and re-running the whole thing, until the output looks
right by visual inspection. Obviously you can avoid the repeated
execution by using temporary files, but really it's such a simple and
common task that it ought to be the computer's job, not mine.
I think the way to do this is that a program can open a pipe halfway
through its execution and tell the GUI to allow the user to connect
something to the other end. In the case of stdin/out/err, "halfway"
is actually right at the start, or maybe before the program has really
begun at all (in the UNIX world that'd be before the exec() but
perhaps after the fork()).
Being able to construct complex networks of pipes - with many outputs
and inputs from each process - sounds like fun, and may even be
useful. I wouldn't even try to do this in a command line shell with
the current syntax, but once you have a GUI that can do pipelines
sensibly at all this ought to be pretty easy.
There should be no requirement (except as imposed by policy) that the
processes that do the work run on the same machine. Pipes should be
two-way like svr4 or socketpair(); you want to be able to connect your
Expect script to telnet/ssh, for example.
--
http://www.greenend.org.uk/rjk/
NB - I have moved; see web pages for new address and phone number.
Tony Finch
>
>(What's that character in the Subject: line? My XEmacs displays it as
>a capital Y with an acute accent.)
That's what it is if you're using the right character set.
>Being able to construct complex networks of pipes - with many outputs
>and inputs from each process - sounds like fun, and may even be
>useful. I wouldn't even try to do this in a command line shell with
>the current syntax, but once you have a GUI that can do pipelines
>sensibly at all this ought to be pretty easy.
Doesn't rc (the Plan9 shell) address this sort of requirement?
>Pipes should be two-way like svr4 or socketpair()
Grr. Two-way pipes work very nicely on FreeBeard, but if you recompile
a program that makes use of this on Solaris, it Gets It Wrong. I hate
Solaris stdio.
r...@greenend.org.uk
> The main reason for selecting Lisp or Forth is because a complete
> interpreter can be built that's insanely tiny. I've used Forth
> systems that were multi- user including the interactive compiler in
> 12k of RAM. That's something you could trivially build into a ROM.
A decade or two ago there was a computer in the UK called the `Jupiter
ACE' which contained a FORTH (and very little else) in ROM ... can't
have been more than 8K or so. Not much RAM, either, but that was
normal at the time. It didn't really take off...
I retain a certain fondness for FORTH; the first language I ever used
was ZX BASIC, and while I certainly fiddled with Z80 a bit after that
I was using FORTH long before really `getting' assembly. Doubt I
could do much of use in it right now, though.
> And it's insanely complex. New exploits are being found all the
> time, beacuse of the nutty type based security. Forth and Lisp like
> languages are routinely used in environments even more hostile than
> a display [1] without people managing to break out of them.
Several people I know seem to go on about Java all the time. Its
fashionability makes me very suspicious, which is strictly irrational
I suppose, but all the same... I'm not familiar enough with the
language to make more substantive statements about it.
I don't expect to see Sun putting their marketing budget behind FORTH
or LISP any time soon.
r...@greenend.org.uk
> r...@greenend.org.uk wrote:
>> Being able to construct complex networks of pipes - with many
>> outputs and inputs from each process - sounds like fun, and may
>> even be useful. I wouldn't even try to do this in a command line
>> shell with the current syntax, but once you have a GUI that can do
>> pipelines sensibly at all this ought to be pretty easy.
>
> Doesn't rc (the Plan9 shell) address this sort of requirement?
I shall have a play some time, though not right now. Too much
unpacking and stuff still to do.
Alistair J. R. Young
> An opaque object, such as a "file pointer" or "message port", that
> mediates all communications between the application and
> services. Everything should be couched in terms of sending messages
> to services, at the application level.
That's what I'm looking at ('message ports', that is), the only
possible exceptions being process management and memory likewise. It
should work well enough for kernel services, at least - I do have a
few worries about the two copies and a context switch for calling any
services running in user-mode, but then, everyone has that problem.
Unless I let processes toss memory sections around with their
messages, of course.
> Each message should pass non-forgeable information about the identity of the
> sender, and what rights the sender is ceding to the recipient, so (for
> example) you could pass a file open request to another program and have it
> perform the open with your rights.
The handle to the access token for the sending process (or a limited
token it's manufactured) should do nicely, I think.
> I think the rights should be stored outside the processes' view,
> though, rather than being cryptographically protected as in NT...
Hidden in kernel memory. All the processes ever see are handles to
them, or answers to queries about their rights. And they can't do
anything they shouldn't with the handle, because the first thing that
the kernel does when a process tries to pass a security token handle
to it is check the pid of the process against the list of pids the
token thinks should know about it, and abort noisily if it's not
listed.
> at least the identity and the rights should be something that could
> be permanently associated with a non-volatile object (like a file)
> so that you wouldn't have the NT mess where reusable tokens are
> stored where they can be stolen.
I am not sure I fully understand this (well, the first half) - could
you clarify, please?
Alistair
--
Computational Thaumaturge -- Sysimperator, dominus retis deusque machinarum.
e-mail: avata...@arkane.demon.co.uk WWW: http://www.arkane.demon.co.uk/
Wanted: Kernel hacker to develop memory-management subsystem for new free
non-Unixalike operating system. No cash, only credit and the end result
offered. Email: <laura-...@arkane.demon.co.uk> if interested.
Peter da Silva
>> be permanently associated with a non-volatile object (like a file)
>> so that you wouldn't have the NT mess where reusable tokens are
>> stored where they can be stolen.
>I am not sure I fully understand this (well, the first half) - could
>you clarify, please?
What I mean is that you should be able to, if you have appropriate
privileges, to say "when this program (file) is executed, it should
be granted these privileges". A generalized setuid.
You could do that by giving the filesystem object the right to grant those
privileges, and have it store them away when a program with those privileges
tells it to. You can have the filesystem object require that the program
have a "privilege granting privilege" as well.
--
This is The Reverend Peter da Silva's Boring Sig File - there are no references
to Wolves, Kibo, Discordianism, or The Church of the Subgenius in this document
"The GCOS GERTS interface is so bad that a description here is inappropriate.
Anyone seeking to use this interface should seek divine guidance."
Tony Finch
>>
>>> at least the identity and the rights should be something that could
>>> be permanently associated with a non-volatile object (like a file)
>>> so that you wouldn't have the NT mess where reusable tokens are
>>> stored where they can be stolen.
>>
>>I am not sure I fully understand this (well, the first half) - could
>>you clarify, please?
>
>What I mean is that you should be able to, if you have appropriate
>privileges, to say "when this program (file) is executed, it should
>be granted these privileges". A generalized setuid.
Capabilities as opposed to ACLs. Linux looks like it is heading in
this direction, albeit in a fairly restricted, Unix-centric way.
Tony.
--
sddksuhv**f.a.n.finch
d...@dotat.at
fa...@demon.net
Tony Finch
>>
>>Capabilities as opposed to ACLs. Linux looks like it is heading in
>>this direction, albeit in a fairly restricted, Unix-centric way.
>
>tell you what rights the file itself has.
Yes. They are called capabilities.
When compsci students at Cambridge are given their Unix accounts, they
are given a lecture on the Evils Of Hacking, and How It Helps You To
Fail Your Degree. A bit different from the 70s when they were
developing the CAP OS -- then, breaking the security was likely to get
you a PhD place...
Alistair J. R. Young
> In article <c1.2b8.2NJBSs$1...@esther.arkane.net>,
> Alistair J. R. Young <avatar...@arkane.demon.co.uk> wrote:
>>> at least the identity and the rights should be something that could
>>> be permanently associated with a non-volatile object (like a file)
>>> so that you wouldn't have the NT mess where reusable tokens are
>>> stored where they can be stolen.
>> I am not sure I fully understand this (well, the first half) - could
>> you clarify, please?
> What I mean is that you should be able to, if you have appropriate
> privileges, to say "when this program (file) is executed, it should
> be granted these privileges". A generalized setuid.
Mmmh. I was originally planning on not having any sort of setuid
mechanism at all [1], following a "if you don't have the privileges to
do it, you have to ask a secure server that does to do it for you"
philosophy (largely because of the assorted potential suid secuity
holes).
More recently, I'd thought of stretching that to allow people to run
executables with a specific list of permissions [2], but interpreting
those as a subset of their own permissions (i.e. ANDing them together)
to give the actual permissions - main use, letting users run binaries
that they didn't trust. And I suppose it's only a short step from
there to the full-fledged version.
> You could do that by giving the filesystem object the right to grant those
> privileges, and have it store them away when a program with those privileges
> tells it to. You can have the filesystem object require that the program
> have a "privilege granting privilege" as well.
How does this sound: Anyone can set a capability list for an
executable that they have 'write-permissions' permission for (or
perhaps a special 'write-capabilities' permission), but can only set
it to grant access to resources that they themselves have access
to. So while the superuser can grant access to anything in a CPL, even
if jrluser can write to the executable, he can't tell it to access
anything he can't anyway.
Just to back this up, whenever the executable is moved, opened for
write, copied, etc., the CPL is automatically removed. So if someone
tries to overwrite a priviledged executable or move/copy one over from
another system, it doesn't do them any good.
I have an increasing suspicion that in a lot of cases, the fnode's
going to end up bigger than the file...
Alistair
[1] Or, to be precise, not one that doesn't require you either to have
the logon information for the user you want to impersonate, or to
be handed a token by a process already running as said user.
[2] Discovering all of two days later that I'd reinvented the
capability list.
Tony Finch
>
>I have an increasing suspicion that in a lot of cases, the fnode's
>going to end up bigger than the file...
You remember the ::$DATA bug in IIS? This was caused by NTFS's ability
to have multiple sections to a file (or whatever terminology they
used), one of which is the file's normal contents, another of which is
for the ACL information. I don't know of any other standard ones.
Tony.
--
ocmcocmcocmk**f.a.n.finch
d...@dotat.at
fa...@demon.net
Peter da Silva
>> privileges, to say "when this program (file) is executed, it should
>> be granted these privileges". A generalized setuid.
>Mmmh. I was originally planning on not having any sort of setuid
>mechanism at all [1], following a "if you don't have the privileges to
>do it, you have to ask a secure server that does to do it for you"
>philosophy (largely because of the assorted potential suid secuity
>holes).
That might provide a bit more security, but it means that instead of having
a few simple privileged programs you have to have a complex server for each
subsystem.
And they'll have to be running all the time.
Alternatively, you can have a "superserver" type approach, where you have a
program like inetd that starts up programs with the privileges granted to them
when you need them.
Now you need to have a database that tells you what privileges you grant
each program. You could do that by having a central privilege database, but
you already have one, so why not use it? You create users with those
specific privileges and with that program as the "shell". Which means you
have to have the privileges to create a new user to create a new service.
That would be interesting, making the ability to create a new user one of
the pribileges you can have... so long as that user doesn't have any
privileges that you don't have.
Or you could make that privilege-granting program the filesystem, and now
you're back to the capability model I originally suggested. There's really
not much difference in terms of security between the two approaches, and if
the filesystem doesn't have any privileges the person who mounted it didn't
you can allow setuid and user-mounts.
In either case you need to be careful what context gets passed to the
privileged service. I'd say that things like the equivalent of the environment
should NOT be automatically applied if the program doesn't have the same
privileges as the user on whose behalf it's running.
>More recently, I'd thought of stretching that to allow people to run
>executables with a specific list of permissions [2], but interpreting
>those as a subset of their own permissions (i.e. ANDing them together)
>to give the actual permissions - main use, letting users run binaries
>that they didn't trust. And I suppose it's only a short step from
>there to the full-fledged version.
I'd say that simply allowing users to discard privileges would be a more
general tool.
>How does this sound: Anyone can set a capability list for an
>executable that they have 'write-permissions' permission for (or
>perhaps a special 'write-capabilities' permission), but can only set
>it to grant access to resources that they themselves have access
>to. So while the superuser can grant access to anything in a CPL, even
>if jrluser can write to the executable, he can't tell it to access
>anything he can't anyway.
That's basically what I was thinking. The "set file capability" operation
would be mediated by the filesystem, and only set those capabilities
the setter had. And of course it could only GRANT privileges the filesystem
had, so if you as joe luser mount a disk with a set-grant-any-privileges
capability executable on it, it wouldn't give you those unless you had
them when you mounted it.
>Just to back this up, whenever the executable is moved, opened for
>write, copied, etc., the CPL is automatically removed.
That would happen automatically when the copy operation got to the "set
capability" step. If the filesystem simply prevents you from writing any
executable with more capabilities than you have privileges then there
should be no hole you could use to break security.
Tony Finch
>program like inetd that starts up programs with the privileges granted to them
>when you need them.
http://www.chiark.greenend.org.uk/~ian/userv/
Tony.
--
f.a.n.finch**??id6890
fa...@demon.net
d...@dotat.at
Kai Henningsen
> I don't expect to see Sun putting their marketing budget behind FORTH
> or LISP any time soon.
Hmm ... don't *all* newer Suns have Forth in ROM? Also all newer Macs.
Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
- Russ Allbery (r...@stanford.edu)
Kai Henningsen
> On Wed, 7 Oct 1998 18:08:43 GMT, in message
> <gb-071098...@hugo.westfalen.de>, Georg Bauer <g...@hugo.westfalen.de>
> (== gb) praised Shub-Internet thus:
>
> > In article <c1.2b8.2N7cW6$1...@esther.arkane.net>, Alistair J. R. Young
> > <avatar...@arkane.demon.co.uk> wrote:
>
> >> Because I already know C, and I get the feeling that trying to learn a
> >> new language simultaneously with the rest of the project (although I
>
> > You are aware of the fact that C++ is a new language in regards to C, too?
> > Just because C++ uses many of C's idioms doesn't say it is the same
> > language at all ...
>
> Well, yes, but in part that depends entirely on how much of C++ you
> use. I've never been a believer in 'OOP applied to everything' - what
> I write is basically C with Classes, just using the class features and
> limited single inheritance where it fits naturally and actually makes
> the code clearer, rather than shoehorning everything into the OO
> model. When that's all you're using, it's definitely close enough to C
> for most work...
In that case, why not use Objective C? It adds *far* less baggage to the
language. It's said that if you know C, you can learn it in a day or so.
> Although I'm tending much more towards C with strange macros attached,
> now, for maximum genericity.
That's another option, certainly.
Kai Henningsen
> Alistair J. R. Young <avatar...@arkane.demon.co.uk> wrote:
> >
> >I have an increasing suspicion that in a lot of cases, the fnode's
> >going to end up bigger than the file...
>
> You remember the ::$DATA bug in IIS? This was caused by NTFS's ability
> to have multiple sections to a file (or whatever terminology they
> used), one of which is the file's normal contents, another of which is
> for the ACL information. I don't know of any other standard ones.
Macintosh resource fork, when acting as a file server for Macs.
r...@greenend.org.uk
> r...@greenend.org.uk writes:
>> I don't expect to see Sun putting their marketing budget behind
>> FORTH or LISP any time soon.
>
> Hmm ... don't *all* newer Suns have Forth in ROM? Also all newer
> Macs.
They're not exactly trumpeting it as the latest thing since sliced
bread, though.
Peter da Silva
>pe...@taronga.com (Peter da Silva) wrote:
>>Alternatively, you can have a "superserver" type approach, where you have a
>>program like inetd that starts up programs with the privileges granted to them
>>when you need them.
>http://www.chiark.greenend.org.uk/~ian/userv/
Unfortunately, in UNIX, you need to be root or you need to be a setuid child
of a user process to give up the privileges (user-ID) that the server has
passed to you. This breaks the principle of least privilege, and adds a great
deal of complexity to a mechanism that *can* be used reasonably securely.
In a capability-based system you could abandon the extra privileges and
return to the non-privileged state at any time.
Alistair J. R. Young
Kai Henningsen <kaih> (== 73tuM01Xw-B)
praised Shub-Internet thus:
> avatar...@arkane.demon.co.uk (Alistair J. R. Young) wrote on 07.10.98 in <c1.2b8.2N8Brt$1...@esther.arkane.net>:
>> Well, yes, but in part that depends entirely on how much of C++ you
>> use. I've never been a believer in 'OOP applied to everything' - what
>> I write is basically C with Classes, just using the class features and
>> limited single inheritance where it fits naturally and actually makes
>> the code clearer, rather than shoehorning everything into the OO
>> model. When that's all you're using, it's definitely close enough to C
>> for most work...
> In that case, why not use Objective C? It adds *far* less baggage to the
> language. It's said that if you know C, you can learn it in a day or so.
From what I can find on it, I think it'd suit the job better -
however, could you point me at a decent source of on-line
documentation or better yet, a good book on it? It's not hard to pick
up enough of the language to get by, well enough, but given what I'm
using it for and that I'm having to rewrite and hopefully trim right
down (one version of) the run-time to fit it neatly into the kernel, I
could do with some more documentation...
The nothing supplied with the compiler does not help.
>> Although I'm tending much more towards C with strange macros attached,
>> now, for maximum genericity.
> That's another option, certainly.
Albeit a horrendously ugly one...
Alistair
Alistair J. R. Young
Tony Finch <d...@dotat.at> (== dot)
praised Shub-Internet thus:
> Alistair J. R. Young <avatar...@arkane.demon.co.uk> wrote:
>>
>> Comments?
> Typing is faster :-)
But not so much fun...
Alistair J. R. Young
> In article <c1.2b8.2N9jKd$1...@esther.arkane.net>,
> Alistair J. R. Young <avatar...@arkane.demon.co.uk> wrote:
>> On 3 Oct 1998 09:08:34 -0500, in message <6v5b52$f...@bonkers.taronga.com>,
>> Peter da Silva <pe...@taronga.com> (== peter)
>> praised Shub-Internet thus:
>>> Me, I'd like a GUI shell that involves glueing pipelines together, this
>>> would then just be a special case.
>> Me too. The problem seems to be finding a good way to represent them
>> visually. Then again, I do actually have an idea for how I might
>> implement them...
> Well, I was thinking that each program would be a box with three "taps" for
> stdin, stdout, and stderr. If you're building a new OS, I'd recommend passing
> the command line through another file descriptor (making xargs irrelevant)
> the way the old "ISIS" system (which CP/M was a cheap copy of) used
> to do.
Well, it's quite possible, I suppose, but - and maybe I'm missing
something here - but I don't see the gain? Well, not unless you're
passing very, *very* large sets of arguments, which either doesn't or
shouldn't happen that often. Plus, there's the overhead from creating
probably a named pipe to feed the command line through, which while it
isn't likely to be much compared to the rest of the process creation
is still probably worth considering.
(Not that the way the programmer gets his command-line arguments isn't
going to be somewhat different, anyway. At the moment, it's looking
more along the lines of
int main (lOsProcess * process_object)
{
...
}
and then doing [process_object getWhatever] if you want your
command-line, pid, name of the machine you're running on,
whatever. There's probably room in there to cram in all sorts of neat
command-line-parsing stuff.)
> So then you'd have two inputs and two outputs on the typical program, and a
> pull-down generator you can plug into the command port for specifying options
> and arguments that aren't synthesized.
Another random idea: How about allowing a process to pass to a child
an arbitrary number of file descriptors (say, for convenience's sake,
up to thirty-two, or so.). 0, 1, and 2 retain the standard meanings of
stdin, out and err, but the others can be used in any way the caller
and recipient agree upon. Useful?
>> To actually set a pipe up, you have a 'pipeline object'. When one's
>> open, it's basically a blank sheet onto which you can drag various
>> pipeline components (program references with the appropriate settings
>> set). Once they're dragged on there, they appear with a couple of
>> extra 'handles' attached to the icon, one representing the component's
>> input, the other its output. Drag arrows across between the handles to
>> represent the way you want data to flow through the pipeline (vaguely
>> similar to the MS Access Relationships sheet, actually), close it to
>> save, double-click the object to run the entire pipeline. Done!
> Have an option to display the resulting command-line so you can run it
> without the GUI.
If we make the storage format for the file backing-up the pipeline
object [1] a standard script, we get this for free.
Alistair
[1] Avoided problems of the Workplace Shell, #1 in the series...
Peter da Silva
Alistair J. R. Young <avatar...@arkane.demon.co.uk> wrote:
>> Well, I was thinking that each program would be a box with three "taps" for
>> stdin, stdout, and stderr. If you're building a new OS, I'd recommend passing
>> the command line through another file descriptor (making xargs irrelevant)
>> the way the old "ISIS" system (which CP/M was a cheap copy of) used
>> to do.
>Well, it's quite possible, I suppose, but - and maybe I'm missing
>something here - but I don't see the gain? Well, not unless you're
>passing very, *very* large sets of arguments, which either doesn't or
>shouldn't happen that often.
It happens often enough that the "xargs" command was created in UNIX.
>> So then you'd have two inputs and two outputs on the typical program, and a
>> pull-down generator you can plug into the command port for specifying options
>> and arguments that aren't synthesized.
>Another random idea: How about allowing a process to pass to a child
>an arbitrary number of file descriptors (say, for convenience's sake,
>up to thirty-two, or so.). 0, 1, and 2 retain the standard meanings of
>stdin, out and err, but the others can be used in any way the caller
>and recipient agree upon. Useful?
It's what UNIX does, and yes it's useful. Interpreters used to use extra file
descriptors to pass data from the stub startup code to the interpreter before
the #! hack was invented, and SPSS used extra file descriptors to pass database
pointers.
>If we make the storage format for the file backing-up the pipeline
>object [1] a standard script, we get this for free.
Not all pipelines you can buiold this way can be expressed as scripts:
cmd | tee | cmd | paste | sort
\_ | cmd | _/
rif...@cybernothing.org
>Russ Allbery <r...@stanford.edu> (== rra) praised Shub-Internet thus:
>> Sounds like VMS privileges. Which isn't a bad thing.
>Could you point me to somewhere where I could get some more
>(preferably reasonably in-depth) information on VMS? It certainly
>sounds interesting, from what little I've picked up, but it's not
>something I've ever encountered in person, as it were.
Nor are you likely to in the future. Which some say is a good thing...
>--
>"I learned long ago to keep my hands to myself when in a big room full of
> shiny toys, unless it was my job to fuck things up."
> -- Jeff Mercer, in the scary devil monastery
*blink blink*
I said that? Wha? When?
*scratches head*
rif...@afn.org : "Now Benson... I shall have to turn you into a dog for a
Jeff The Riffer : while."
Drifter... : "Thank you master."
Homo Postmortemus : --Time Bandits
Alistair J. R. Young
<rif...@cyberNOTHING.org> (== riffer)
praised Shub-Internet thus:
> Alistair J. R. Young <avatar...@arkane.demon.co.uk> wrote:
>> --
>> "I learned long ago to keep my hands to myself when in a big room full of
>> shiny toys, unless it was my job to fuck things up."
>> -- Jeff Mercer, in the scary devil monastery
> *blink blink*
> I said that? Wha? When?
Fortunately, context is at my fingertips...
[greppity-grep]
:Subject: Re: Embarrassing Luser Moments
:Author: Jeff Mercer
:Email: rif...@freenet3.afn.org
:Date: 1996/04/24
:Forums: alt.sysadmin.recovery
:
:hil...@netaxs.com (Hillary Gorman) wrote:
:>Jasmine Sailing (jsai...@netone.netonecom.net) wrote:
:>: What were your most embarrassing moments of being a luser yourself?
:
:Never happened to me. Nope. :)
:
:>easy. my first day at netaxs i walked in, walked up to the only empty
:>chair, looked at the computer in front of it, saw a button, pressed it,
:>and said "i guess this is how to turn on the monitor?"
:
:Um...
:
:>note i acted BEFORE asking....and pressing that button caused me to turn
:>off the machine running the x-client for the entire office....argh.
:
:Yeah, that's pretty bad.
:
:I refuse to say what luserish things I myself have done, but have no problem
:talking about the luserish actions of other professionals, :)
:
:One incident occured when the volunteer sysadmin for AFN was with me in the
:machine room while we were fiddling with the system (upgrading AIX? Poking
:at the Linux box? I forget). Anywho, there's a cabinet there which the linux
:Box resides on/in and which has one of those power locks. The key was hanging
:right next to the lock, on a bolt.
:So what does he do? Picks up the key, sticks it in the lock, and turns. *click*
:Off goes the linux box+monitor, and also one of the AIX boxen. Woops.
:I enjoyed laughing at him immensely, and not because I had done it myself
:earlier, noooooooooo.... ;)
:
:The other incident was when me and several other volunteers were over at
:the school board's building after a tech meeting, looking at the system setup
:for the public school system. Lots of AIX boxen, a few OS/2 PC's, tape
:backup drives, etc... And one of those terminals with monitor where turning
:off the big red monitor switch upsets the whole system.
:So of course one of the volunteers helpfully turns the monitor off. I think
:the school board systems guy nearly had a heart attack. It *did* confirm a
:few suspicions about that volunteer, though...
:
:I learned a long time ago to keep my hands to myself when in a big room full
:of shiny toys unless it was my job to fuck things up, :)
:
:
: rif...@afn.org : If you would keep a secret from an enemy, tell it not to
: Jeff The Riffer : a friend.
: Drifter... :
:Homo Postmortemus :
Alistair
Kai Henningsen
> From what I can find on it, I think it'd suit the job better -
> however, could you point me at a decent source of on-line
> documentation or better yet, a good book on it? It's not hard to pick
Have a look at Apple's web pages.
<http://developer.apple.com/techpubs/rhapsody/rhapsody.html>
"Object-Oriented Programming and the Objective-C Language", both online as
HTML and for sale as a book.
Alistair J. R. Young
> In article <c1.2b8.2NY8jX$1...@esther.arkane.net>,
> Alistair J. R. Young <avatar...@arkane.demon.co.uk> wrote:
>>> stdin, stdout, and stderr. If you're building a new OS, I'd recommend passing
>>> the command line through another file descriptor (making xargs irrelevant)
>>> the way the old "ISIS" system (which CP/M was a cheap copy of) used
>>> to do.
>> Well, it's quite possible, I suppose, but - and maybe I'm missing
>> something here - but I don't see the gain? Well, not unless you're
>> passing very, *very* large sets of arguments, which either doesn't or
>> shouldn't happen that often.
> It happens often enough that the "xargs" command was created in UNIX.
I'll think about it (after all, I've plenty of time to do *that* <g>),
but I must say that while I can see the usefulness, I'm concerned
whether xargsish things are used *enough* to justify the additional
setup overhead on every process creation - especially as one of the
Unixy things which I'm glad to copy is the lots-of-little-tools-plugged-together
model. Hence the whole pipelines-in-GUI issue, really.
[snip]
>> If we make the storage format for the file backing-up the pipeline
>> object [1] a standard script, we get this for free.
> Not all pipelines you can buiold this way can be expressed as scripts:
> cmd | tee | cmd | paste | sort
> \_ | cmd | _/
Well, that depends on the chosen scripting language and other
facilities available... At a first guess, and a horribly inefficient
one probably, the pipeline above could be written as something akin
to:
--
$ai = make_temp_named_pipe ; $ao = make_temp_named_pipe
$bi = make_temp_named_pipe ; $ao = make_temp_named_pipe
( cmd Ý tee $ai > $bi ) &
( cmd < $ai > $ao ) &
( cmd < $bi > $bo ) &
cat $ao Ý paste $bo Ý sort
rm $ai $ao $bi $bo
--
And it occurs to me that if it can't be expressed as a script, a
command-line for it could be displayed even less readily. If that
does prove to be a problem, though, there's always the option of
storing the GUIsed pipelines in a binary format with a program that
knows how to interpret it set as the default association.
Alistair
--
Computational Thaumaturge -- Sysimperator, dominus retis deusque machinarum.
e-mail: avata...@arkane.demon.co.uk WWW: http://www.arkane.demon.co.uk/
Wanted: Interested parties to join development of a free, non-Unixalike OO
operating system. Email <laura-...@arkane.demon.co.uk>.
"Customer Service: sometimes you have to give the silly bastards what they
want!" -- seen on a button
Alistair J. R. Young
> In article <6vc3c8$m...@bonkers.taronga.com>,
> Nick Danger <ni...@taronga.com> wrote:
>> When a process does a read or write or malloc or whatever, sending
>> the messages didn't block it unless it requested it.
> [snip]
> That seems like too complex an interface.
After much drafting and redrafting, I think I've got a fairly simple
interface - a total of five basic system calls:
port get_objectmanager_service_port (void)
retcode send_msg (port to, id message)
retcode receive_msg (port from, void * where, size_t buffer_size)
retcode call_method (port to, id message, void * reply_where, size_t buffer_size)
void thread_is_dying (void)
The first so that you can get somewhere to send messages to in the
first place, the second and third to talk to the rest of the world,
and the last just to make tidying up afterwards a little cleaner.
Probable additions to this are likely to be:
port get_own_session_port (void)
port get_own_process_port (void)
port get_own_thread_port (void)
just to speed up access to the things that you're likely to need to
talk to a lot. And, it avoids the unpleasant problem of needing to
know who you are before you can talk to yourself, as it were. And
possibly also:
port assign_object (lString name)
void deassign_object (port which)
to speed up access to known objects without having to search through
the entire object tree in the process.
> You would need a variety of options to "send message"... you need to specify
> whether the "send" is synchronous or asynchronous,
Easier to do it as two separate calls, I'd have thought. Most of the
possible calls I have worked out only really make sense as one or the
other (asynchronous wait_on_semaphore? synchronous set_timer?
asynchronous malloc? Ok, that last one's borderline...), and the few
exceptions seem to be only of the asynch-but-could-be-synch kind, like
read() and write() - and defining the synchronous version as 'send the
message, then block on the worker thread replying to an
only-it-can-access port' reduces the issue neatly to an earlier
problem...
> and whether a response message is expected.
Deducable from the type of message, I'd think.
> On the Amiga, the normal "write" message was asynchronous, buffered,
> with a response packet. So you would have something like this:
> sendmsg(port, respport, buffer, len, options);
> (in the Amiga the response port was included in the buffer... it would make
> security easier if the OS handled tracking and trading ports)
For security purposes, I'm going for as simple bookkeeping as
possible, for the sake of performance - ports just have a normal ACL,
like any other objects (or, rather, the objects the ports point at
have the ACL, but it's the same effect). Yes, this does allow an
unlimited capacity for the user's processes - or at least those in the
same session - to screw each other up...
Depending on how this works out while the code's still small and
experimental, of course, ripping it out and replacing it with a more
Mach-like (for example) system of port rights will of course be a
possibility. Opinions and arguments either way are of course welcomed.
> So for something like syslog(), where you don't expect a response, it would
> be:
In our (proposed) vernacular:
> sendmsg(syslog_port, NULL, &message, len, ASYNC|BUFFER);
message = [_LogMessage new ...] ;
err = send_msg (syslog_port, message) ;
[message release] ;
The idea being that _LogMessage, like all messages, are descendants of
the class _Message - and so, send_msg knows how to query it for
whatever it needs to know to send it. And syslogd will be able to take
what it gets, identify it as a _LogMessage likewise, and reconstitute
it into its parallel internal class.
> For something like write(), you could do it like this for streaming:
> sendmsg(fd, rfd, &buffer, len, ASYNC|BUFFER);
message = [_WriteMessage new: bufferToWrite ofLength: len ...] ;
send_msg (port_corresponding_to_file_descriptor, message) ;
[message release] ;
> And for a database commit:
> sendmsg(fd, NULL, &buffer, len, SYNC);
call_method (p_c_t_f_d, [[_CommitMessage new] autorelease]) ;
Of course, in actual practice, this stuff is all hidden at the bottom
of the objects making up the run-time library, so these examples would
be written as:
[syslog logEvent: ...] ;
[file write: buffer ofLength: len] ;
[file sync] ;
respectively.
Alistair
--
Computational Thaumaturge -- Sysimperator, dominus retis deusque machinarum.
e-mail: avata...@arkane.demon.co.uk WWW: http://www.arkane.demon.co.uk/
Wanted: Interested parties to join development of a free, non-Unixalike OO
operating system. Email <laura-...@arkane.demon.co.uk>.
"Teachers always say that [there's no such thing as a free period], unless
they've got one themselves, and then they just sit in the staffroom drinking
coffee and having sex!" -- Toyah Battersby, "Coronation Street"