|
BeOS and UNIX Compatibility |
RICO TUDOR: Okay. Well, my name is Rico Tudor. This is a discussion about POSIX, UNIX compatibility on the BeOS and what we've been doing in DR9 to bring you the best there is.
I'm going to depart from our normal format here at the conference and I'll take questions after each of these three sections, so that way if you have something on your mind you don't have to wait all the way to the end, by which point you've forgotten what you wanted to say.
First thing, there's multiple versions of
UNIX. I'm sure that everyone in here, since you are
in here, have some experience with UNIX: you know
there's AT&T, there is BSD and there's also numerous
compatible versions of UNIX, like Linux or free BSD or
something, which represent even more fragmentation of
the world of UNIX.
We've adopted the POSIX standard and I feel that it represents a good compromise from all the flavors. It's more SystemV than not. The other thing, it's a standard which we all can get our hands on. It's not owned, so to speak, by any one company, vendor of equipment, whatever.
It may be strange that here we are in the '90s and we have this fine up-to-date multithreaded, multiprocessing operating system, BeOS, and you discover that POSIX is lurking around on the system. Well, I don't have to preach to the converted. We know that UNIX is great, POSIX is great, all of this stuff is just passing in the wind will remain. Graphics user interfaces, they get all the glory, but in this world the UNIX apps do all the work... and COBOL.
In the first section, which I'll go into now, I'd like to talk about the nature of our implementation a little bit. Basically, you'll have different vendors saying we support POSIX, another vendor will say we support POSIX 2, so there are, particularly if we want to go and split hairs, different versions of POSIX even.
We're kind of shooting for the first and most dated version of POSIX, just for the moment. Obviously, we can improve and also expand outside of POSIX. We don't consider POSIX the law, we can take that as our base.
So in the first section I'll talk about what we do in terms of POSIX support and in what ways it's lacking or different from other versions of UNIX. It's a work-in-progress, like the rest of the system. The GUI people have a lot of work to do and so do we. DR9 is a huge improvement over DR8. We have addressed matters of robustness, of finding standard files in standard places, of being able to compile programs. Even if we don't have the support, your program should compile and then if you look at the fine print you'll discover, hmmm, this program doesn't seem to do all the things that I want it to do.
An example might be the contents of /bin. We seem to have a fictitious user named "ethyl". That's not the right user normally for the ownership of these kinds of files and we do not have a password file. However, the POSIX API says we have to have stat(), we have to have user IDs, there's even ways to map the user ID to a name that might imply it as a password file. Well, it's all faked out. Why? Because BeOS doesn't have multiple users, but we don't want that to stop people from compiling, say, "ls.c" and having plausible output. So we faked out the users and the groups.
I don't consider this to be a problem because in some ways we're slaves to the BeOS and what its capabilities are. Part of what I would like to see is for POSIX, which some people would say is marginalized on our system, take a more central role and I think that's already happening. Things like fork() are a real system call now instead of sort of a user library level emulation of the real thing.
So pieces of POSIX in one form or another are migrating into the so-called microkernel and once I've taken over the scheduler, I think we'll have it made. We'll see who's running this show. I hope there's no marketing people in here. Anyway, the gist of what I'm trying to say is we like POSIX, the company is supporting POSIX, we have a POSIX faction in the company. It's not a transitory or transitional strategy where we bring you people in.
A SPEAKER: We get you to go.
RICO TUDOR: And get you to convert your apps to go native. Some of you are dyed-in-the-wool UNIX types. You like it the way it is. You want to have your fun, but you want to get some work done. So the idea is that POSIX should be a real and enduring part of BeOS and no one's going to push you to convert everything over into C++ and use kits and do everything the way you don't want to do it.
Okay. So as I'm saying, we're talking about POSIX compatibility. I'm not going to discuss point by point everything that we do and everything that we don't do yet. POSIX is pretty big. If you have specific questions you can ask me later about, like do we support select() and, you know, what are all those flags to open(), in the system call, and so on. What I'll do is simply give the highlights of our achievements and a few words of warning, warnings about what we're not supporting: bugs. What Intel would call errata. We have our own errata list, but I'm just going to go over the main points. So firstly, I think one of the best achievements for DR9 is fork(). We've lived with a limping version for a long time and I pushed for us to have a real version of fork() and basically there were some minor political issues about fork(), because to do it right and to do it fast you have to get into the kernel and get your hands around all those lovely kernel resources, which you can't do outside.
So the result of that is certain problems. I've had to defend the miserable DR8 fork() on the Net and say what it can't do. I wrote it. It's now been replaced by someone else's fork() which is in the kernel, much better performance with correct semantics.
This is a brief demo of that. It's hard to
show correctness, but I think I can show you
performance. And, of course, we do it with a shell;
slap me if you see me using a GUI during this.
Oh, I've been instructed to use a larger
font, so I guess 3 is out. Let's try 40. All right.
Well, that kind of wraps the line a little bit but
basically what I'm going to do is redirect this to /dev/null
and we don't have a "time" command, I apologize, so
I'm going to wrap this "date" here and put a "date" at the
beginning.
Okay. Two seconds to do 100 calls of "date" and that's on a machine which is pretty fast. It's a Pentium -- sorry, it's an equivalent of a Pentium Pro 200. Of course, it is better than a Pentium Pro 200, both in performance and in political correctness. So that wasn't a slip of the tongue really, because I have a Pentium Pro for my own development, I admit it, running Linux. This performance here of 100 calls to "date" in two seconds, so 50 a second, is within a power of two of Linux, my equivalent machine, which I consider really good for a first cut.
So another area, maybe possibly the second most important area is signals, which are more and more real all the time. I think right now we're --
Sound? Hello.
Okay. Signals, which we had the beginnings of signals in DR8. DR9, well, first you can do something like sleep for a long time, hit interrupt, things which work a lot better than they used to. We have Magnify. It's a BApp, you know, not a UNIX app, but we can send interrupts data also.
A SPEAKER: It's like a GUI.
RICO TUDOR: Well, at least I typed its name. There's a control-C to get rid of it. So in addition to having more robust signals we also have more signals. We have SIGHUP, we have process groups which allow you to do things like send signals to the whole group. We have SIGWINCH, so for example, we have "bash" here, "bash" knows about -- well, let me just go like this. I'm going to set this font now a little bit smaller.
Can you read that? Is that readable?
A SPEAKER: Yes.
RICO TUDOR: Okay. Here we have rows 23, columns 64. It's part of the "stty" command. If we resize this window, something twitches, "bash" got a SIGWINCH. There's an update now, rows 11, okay, all that kind of stuff.
For people who want to do text editor scrollers, whatever, anything in bolding, resizing windows, that all works. It's also the case that this SIGWINCH goes across the network so people that are telnet'ing into the box will get a shell and be able to resize "emacs" or, you know, whatever's running on the BeBox that they want to run.
Now, in the matter of UNIX, POSIX, the presentation of your output, how you get stuff into the program is -- your application, is traditionally done with a terminal, God's gift for input and output, and even if you're running X Windows or something like that, you're still going to be using a terminal emulator of some kind. We have, in a sense, two faces of POSIX at the moment. We have "telnetd", so that allows you to "telnet" into the box. We've had it before, it works a lot better now. It's actually a pleasure to use. I find myself logging into the BeBox from X Windows or another machine and not really even noticing the fact that -- that I've done that and that I should be worried or something. Everything works fine.
We all know about the "terminal" app, we probably use it a lot around here. That also is the other face into the POSIX world. Improvements to that, lot of complaints about the escape sequence, ANSI standard, behavior. That is an ongoing thing. I apologize for any bugs that are detected by you people in the coming weeks. The idea is that it will be an ANSI standard terminal emulation in all forms. In the meantime, it's well on the way. You should probably be able to find all your applications, editors and so on, work.
The only thing I would warn you about is if you are -- if you are, in fact, logging in -- sorry, if you're telnet'ing out of the box, not into the box but out of the box into the UNIX system, you've got "curses", "termcap", "terminfo", that kind of stuff, you'll find sometimes a failure of my emulation. In that case, just fool around with your setting, your TERM variable. Sometimes "ansi" works, sometimes "vt100" works, sometimes "xterm" works. Unfortunately, again, because of fragmentation of the UNIX world, there are different versions of these databases and actually, some of them are wrong. Some of them have incorrect entries. There's been too much hacking. There isn't a central authority coordinating the terminal descriptions the way there used to be back when Bill Joy entered them himself. So that's what I have to say about the ANSI terminal emulation.
Other things that have been done: We have the point sizes, thanks to Pierre, who has done a truly excellent job in rendering of fonts, so we're fully scalable and using some tricks. They look good and so I've entered font settings as large as 120 point, more for effect or shock value. Also 3 point. Some people might want to do something in a window over here and when they see a twitch they'll say well, I can't read it but I know my job finished.
Smallest point size that's readable is 8. I can read it, I don't know if you can. Okay. We have line wrap. That's actually part -- that was my notion of chopping off the lines, wasn't really a very popular one, so...
Okay. Now, in a related area, the matter of terminals... the API, back to the API. We have "termio", is SystemV kind of stuff. "termios" is the POSIX stuff. You're probably familiar with it. "stty" command uses it, if you want to control your erase and kill characters, your baud rate, just about everything. The input, the output, the face of POSIX is in the hands of this layer of software, which in UNIX is the tty layer.
You people probably don't even think about it too much, but it's actually a component in the system which lies between POSIX application and any kind of terminal-related device. It could even set up ttys. So you've got ptys, which is how you implement windowing systems and network access like "rsh" and "telnet", and the tty layer is also sitting between you and all the hardware which claims to be serial-oriented, modems, hard wire, URTs, that kind of thing.
This area is being addressed by me vigorously, but I cannot finish everything I want to do for DR9. The idea is to unify what was a highly fragmented part of our own implementation of serial line support. So far "terminal" and the network-related access to our POSIX system is working. It's incomplete, but it's now under an actual layer of software which is again in the kernel tty layer. The one area which is not being addressed right now, and which is therefore still DR8, is the serial device hardware. /dev/serial1, /dev/com4, that kind of stuff on the BeBox; serial1, serial2 on the Mac. Those are still under the auspices of the old software, which was a bit hacky. However, even then you were able to use "stty" and set baud rates and so, you know, it's certainly as usable as it was.
The pseudo tty support, for those of you who are interested in pseudo ttys, is very close to UNIX; although, again, there are different versions of pseudo ttys even in UNIX, but I'll leave that. If anyone's interested in that come up to me afterwards and I can give you the gory details. We've organized the file system to be more along the lines of what UNIX people would recognize. So in slash we have the things like system and boot, which don't look very recognizable, but we have these things called symlinks, therefore, suddenly we have now /bin and /tmp and /dev.
And those are symbolic links to where? Well, in BeOS we put the volume names at the top, so the POSIX faction has to live with that and in /boot, which is our boot hard disk, we now see -- did I mistype that? Oh, sorry. Okay. We see all the files that we know and love and there's where the bin really is, for example. And as you can see, people have been hard at work. We have to commend Fred Fish for being a guinea pig, a pioneer of the GNU and related UNIX application porting effort. He's out there in Arizona, isn't he? Yeah. Basically, I think he probably knows more about porting UNIX applications now than anybody, to the BeOS.
There's an awful lot of stuff here. I'll just leave you guys to look it over. It's pretty impressive. Anyway, the file system -- going to talk about /dev -- looks reorganized. There's fewer files in here than there used to be. What we've done, at Dominic's request, is -- request?
BRAD TAYLOR: Behest.
RICO TUDOR: -- behest is to put more things in subdirectories, so this is the way /dev looks these days, but at least you should be able to navigate around and find useful devices. For those of you writing device drivers, you'll soon be putting your own stuff in there. Pseudo ttys, for example, are all stuffed away in "pt", "tt", but that's -- I don't think we have a "who" command yet. Anyway, one day you'll see those in your "who" command.
I talked about process groups. It's how we implement signals when you're logging into the BeOS and shell and you run stuff and you can interrupt and it kills things off that are in the foreground. Does this mean we have a background? Well, you can detach stuff and then it won't be interruptible so I could, for example, type Magnify. Now that's detached. You notice the interrupt does not have any effect on Magnify. It's still there. I can say "kill" the last thing. Some commands can't take a hint. So I can "kill" things that are detached, but notice that it was not paying any attention to the foreground activities. Does this mean we have job control? No, that's one of our things that we would want to put in for DR10.
Job control, for those of you who don't know, allows you to run multiple groups of things from the same terminal, just have them running in the background and then if something interesting happens you can join it back to your keyboard and interact with it. It's a -- it's defined in POSIX so we want to put it in.
Other things, file system, pipes we have. Pipes are now working pretty good. We have -- I think I've measured around 8 megabytes per second from the machine here, which is 225 megahertz 604e. Not the fastest pipes in the universe but pretty good and I would say don't hesitate to use them. They're great.
Environmental variables. Well, I think we all know what those look like. Some of these are related to the Be integrated development system. You can also get to the Metrowerks compiler from the command line, "mwcc". Some of these are fascisms. I think we also have a shell which works, by the way, if you have any applications that you shell. I think we have some ourselves on the system. TERM is important if we're working locally. "TERM=ansi" is the way we get to "terminfo", or "termcap", I'm not quite sure. TERM -- I think we're using "termcap". I think if you set USER you can have the name of your user, your default user on the system be whatever you want, if you don't like "ethyl".
A SPEAKER: Will it change all of the listings?
RICO TUDOR: Yes. We do not have select() but I believe, correct me if I'm wrong, Brad, but we want that for DR10.
BRAD TAYLOR: Some future release.
RICO TUDOR: We want it but we don't know how we're going to get it quite yet. We have to go into the kernel again so we have to send in the commando team, because select() in its full glory it's not just a networking thing that we can solve in the net circle. We have to go into the kernel and say pipes, serial devices, all of that kind of stuff. However, that's on our list, that's on our hit list.
We do not have POSIX threads. The version of POSIX which I use to -- well, actually, which we all use at the moment, is Dominic's $100 copy advice of POSIX, called POSIX.1. It does not have threads. There are two or three versions after this and they don't have either. I don't really know what we want to do about that policy decision. Personally I think it sucks. I mean, sorry, POSIX threads suck and we don't need them or want them. However --
DOMINIC GIAMPAOLO: Rico, they're actually not that hard to thread. A number of people have started looking into it --
RICO TUDOR: Oh, we have a volunteer in the back. There we go.
Okay. User ID and group ID. We've gone over this. I think there's a pretty strong push to have multiple users, multiple group protection like let's get with it, you know, if a fossilized operating system can do it right, let's make the other side do it right. And it's not a big deal. I believe hooks are already going in, I believe there are places in the file system where owners are already being recorded. It's really just a matter of we have to write "login", we have to make a password file, we have to set up some administration, point and click, add user, that kind of thing. I see that as being essential. That's my take on it.
A SPEAKER: So it is on the list of things to do for users?
RICO TUDOR: Yes. Yes. I hope there's no marketing around here, but I'm saying it now. Since we're -- I'll just stop now and take some questions in the area of POSIX compatibility. Just like five minute's worth. Yeah.
A SPEAKER: Will kill, if given to a BApp, be converted into a BMessage?
RICO TUDOR: And the answer to that is no.
Yes?
A SPEAKER: Stack space?
RICO TUDOR: Stack space is finite. 256K at the moment. So if you're in the habit -- sometimes I'm in the habit of putting a megabyte buffer on the stack... oops.
A SPEAKER: Is that several per application?
DOMINIC GIAMPAOLO: It's per thread.
RICO TUDOR: Yes?
A SPEAKER: Is NIS being supported at some point?
RICO TUDOR: INS?
A SPEAKER: NIS.
RICO TUDOR: NIS? Brad?
BRAD TAYLOR: I have no current plans to do it.
RICO TUDOR: No current plans to do NIS.
A SPEAKER: Net info?
RICO TUDOR: Net info? What is net info?
A SPEAKER: It was a joke. Be careful, Brad.
A SPEAKER: Why was the name "ethyl" used as the default?
RICO TUDOR: I have no idea. Ethyl?
A SPEAKER: It used to be Baron.
RICO TUDOR: It used to be one of our engineer's names. Okay.
A SPEAKER: It was Elvis I thought.
RICO TUDOR: It used to be Elvis, that's true.
Yes?
A SPEAKER: What is /dev/hack?
RICO TUDOR: Dev --
A SPEAKER: Like in your device files. Hack?
RICO TUDOR: /dev/hack?
DOMINIC GIAMPAOLO: It's a holdover back from when we were first bringing up the new file system we needed a way to get serial shell, so it's just a hack serial driver.
RICO TUDOR: Yes.
A SPEAKER: Kind of fuzzy. Were you actually using like /devs to get things as opposed to --
RICO TUDOR: /dev I believe is -- works. I don't know if that's a symlink. Let me take a look.
Looks like the real McCoy.
In our operating system the -- the device directory, which is seen by POSIX and is also seen by BApplications is, in fact, its own file system. That's how we implement it. So it's not implemented in the UNIX way, where you have regular files and then you have funny i-nodes in those directories. We actually -- it permits people to add device drivers and the names that that device driver wants to be known as are published by the device driver and then simply appear in /dev. It also allows, if you don't have a device, like you plug in a SCSI card and if you don't have all your SCSI IDs in use, then those SCSI IDs will not appear in /dev.
Yes?
A SPEAKER: You mentioned you were going to change the default user by setting the user environment.
RICO TUDOR: Default user, yes.
A SPEAKER: Is the uname -s going to work to change the machine's name?
RICO TUDOR: Yeah, I think so. Why not?
A SPEAKER: Because it didn't.
RICO TUDOR: I'm not sure -- I think the only way the machine in BeOS has a name at all is through the network interface, at the moment anyway. I don't think there's any way to tag your machine, but there should be, sure.
A SPEAKER: You name the term as a name, but there's some -- I have a machine that's not on the network, but it's called trantor.
BRAD TAYLOR: If you set the host name the network preferences it. Whether you're on the network or not, it sets the host name of your machine.
A SPEAKER: Ah. Thank you.
RICO TUDOR: Okay. I'm going to go back into the talk.
Second item of the agenda is POSIX and BApp interaction. Now, this gets pretty squirrely. If you start feeling frightened don't worry, it frightens me too.
What do you want to do once you have a BeBox, you're loaded with your POSIX applications, maybe you're running your business off of it, maybe you want to sell software, maybe you already sell software and you want to sort of add BeOS to your collection of scalps. In that case you might be tempted to start adding some local capabilities. For example, as I said, our implementation of POSIX and most versions of UNIX do not have threads. It's not something that UNIX does. However, BeOS does it and one of the decisions that was taken, matter of policy, was we did not separate POSIX emulation from the BeOS native execution model, so we do not have two separate execution models. It's a unified model.
Now, what that means is that all the calls in BeOS, the kits, the kernel calls and so on, are as accessible to you POSIX writers as the POSIX calls. It's all in one big pool.
What are the semantics of throwing various kinds of calls together? Answer: Unknown. If you do it, and we do it also, you're going to be treading on thin ice and it's also ice that's in the very stages of change because our architecture is also undergoing change.
DOMINIC GIAMPAOLO: There's one clarification there. The only real difficulty and the thing that we actually disallow is calling fork(), having call load_image() and calling a fork(). That's explicitly disallowed. Otherwise, "ethyl" and open(); those are fully usable and there are no unknown semantics using those in the APIs. In fact, we encourage people to use them because in some cases it's much simpler, much more straightforward to use them than the compiler.
So most calls, such as, you know, like I said, "ethyl" and open(), gettimeofday(), et cetera, are going to work just fine. It's when you get into some POSIX functions, say, where the semantics are less clear, tend to thread over each other, have threads, other time functions, for example, static.
RICO TUDOR: Okay. Our operating system guy corrects me. He says the semantics are clear and that fork() is not permitted to be called when you are a BApp or are using BeOS calls.
DOMINIC GIAMPAOLO: The system works just fine, for example, on the application.
RICO TUDOR: So those are the -- the laws are clarified, the semantics are there. Now I'm going to say that for implementational reasons all the fear is there, so continue to be afraid. One of the problems is we have nasty interactions between, say, signals and the kits. Why? Because the kits go off to the servers. BeOS is a server-based system and just implementation there's some problems, things blow up and signals are definitely a problem in that area. That's just one example of some of the nasty interactions.
Signals are much better in POSIX, don't worry about that. You know you're running a POSIX app if you do "ps" and you see one thread; by definition that's a POSIX app. If you see multiple threads, that's a BApp. If you decide to go into the matter of mixing the calls, obviously you're going to reduce your portability for that particular application. You may nonetheless desire to do it. I'll be giving some examples -- an example at the end of this section about how you can sort of wed the two worlds with a maximum flexibility.
Once again, in the area of problems, errata, in the hybrid app, I like to use printf(). printf() is callable from a BApp. It's part of the C standard library, it's not a POSIX kind of a thing. However, we were having a bit of problems. There's the matter of threads and thread-safe printf(), so if you're using printf() to files or even to standard output and you're using it for diagnostic purposes, printf() sometimes lies. It's got buffering, it gets confused.
Okay. What about, say, malloc()? malloc(), rock solid. If malloc() wasn't thread-safe we'd all be dead. So these are just examples of things that are working, things that are not working, but according to Dominic should work. The semantics are clear he says, but I can tell you implementationally we have some ways to go. If you want to rock and roll into the hybrid applications, that's fine, but you're going to be playing around with some combinations that haven't been tested and so that's just a -- just a word of warning for the hybrid users.
Nonetheless, we have a lot of applications which are just hybrid. They make calls to all the stdio, of course. You say well, that's kind of odd. They make calls to open() and close() and lseek(), which are POSIX calls and yet they're BApplications, they put windows on the screen, so yes, those kinds of things work.
We also have an awful lot of redundancy because once you've joined everything together in this way you start having multiple ways of locking data structures, multiple ways of doing I/O, multiple ways of accessing devices. You can open a device by saying the POSIX call open( "/dev/SCSIdevice"), read(), write(), close(). No problem there.
Conversely, you could use the kit form of accessing devices. We have things like BSerialPort. If you don't want to open a serial device, you instantiate a BSerialPort and now you can do everything with method calls. So some of this -- some of these decisions you'll make just based on what you feel like doing.
If you're a POSIX purist, and there are reasons for doing that, perhaps you want your program to run on other operating systems, you want to be able to put in your investment of work into BeOS, but still be able to maintain that portability. Then you will not want to actually take your application and start putting BeOS native calls in it. So what I think I'll do now is show you briefly something that I've been doing. It's on DR9. I think it's a happy union of both the POSIX world and BeOS native programming.
Why do you want to do this? Well, let's face it, when you're writing your POSIX application you get all green with envy with the other guy's user interface. It might be X, it might be BeOS's graphics user interface and in addition to wanting such a thing and having a mouse, for example, to provide input to a POSIX application, you might once again have portability issues. You want to be able to write some kind of a program that has a user interface and you want the hard work, the back end, so to speak, to be just one copy, but you'll write multiple front ends to provide different, you know, visuals for different platforms.
So here's one approach which I put together for today. It's actually on the DR9 distribution.
Okay. This file here, "Calah", it's a game. It looks like a document, but what it actually is is a BApplication. You can say what difficulty game you want, make your move. You'll notice that sometimes I'm moving, sometimes the machine is moving. I'll point and click various bits of information.
Okay. Much nicer than looking at ASCII output, I'll admit. You can also pop up more windows, you've got scroll bars.
Okay. So the idea there is that perhaps you've already written this program and it's already running on UNIX systems or wherever it may be, in the form of POSIX, and you've put a lot of work into it. We all know that in that program there you could spend a lot of time writing a clever chess program. Maybe you want to take on DeepBlue now that it's the master of the world and you don't want to have to port that kind of stuff.
So what is "Calah". Well, I'm going to actually take it and dump it on "StyleEdit", which is a way of looking at files, editing files and you'll observe that this isn't a BApplication at all; in fact, it's a shell command file. So that's another capability, thanks to Peter Potrebic and the kernel team for being able to launch shell command files and to be able to launch them from the tracker. Double-click and you're on your way.
That's the meat of the whole application. So it just cd's to a private area where "Calah" has its auxiliary files, we then execute "calah", little "calah", that's the front end, and we pipe it into the engine. So "calah", which I can actually run...
Okay. So this is this private directory. If I double click on "calah", well, doesn't have much to say. So that's the front end and it's a pure BApp, it uses all the kit stuff, so on. The engine looks like that and I can play it so things are moving around and, you know, it's no big deal. So the output from engine in a normal shell pipeline goes right up to standard output or redirects to a file or something -- something not useful. What we need is to get the output, which is in ASCII, engine is ASCII out, ASCII in, it's POSIX, we want it to go back into "calah". Well, the trivial command "feedback", source available on request, simply takes the output of engine and dumps it back into "calah", which is the front end.
A SPEAKER: So it's kind of a reverse pipe.
RICO TUDOR: So there you go. Yes, it's a circular pipe. It's what you can't do in "bash", in the shell. It's a circular pipe. This is the most trivial form of plumbing using pipes. Pipes are good, we like pipes. Pipes are fast, use them. And you can do things with circularities, you can do things with multiple -- this is the simplest form of feedback.
Okay. You can make much more complicated feedback circuits, so to speak, and put all kinds of stuff in there. I mean, this "calah" -- sorry, the engine, it may not be written in C, it could be written in a different language, you know, the functional -- COBOL or functional programming language. It doesn't have to be running on our machine. You can just "rsh" that or "telnet" that or TCP that off to your Cray, so it's nice to have that flexibility. I know when I use my Cray I don't want to log into it, but I like --
So I would much rather have BeOS as the face and have the back end be BeOS if that's all you can afford, or your Cray. So this way you have double-clickable application, it looks all-natural. The fact that this thing looks like a document is just -- we just got this going, we were -- the "Tracker" was undergoing great changes. We have these MIME style name -- typing system, so we just don't have an icon for it, but obviously we should have an icon and then just double click on it.
It's just as in UNIX. We have first-class citizens, namely, shell command files, you know, you type a command, we don't know if it's an executable or a shell command. Similarly, with BeOS if you see something like this, you double click on it and it runs. We don't care what it is. In this case, it's pretty spiffy.
Then for those of you who have your invested or your personal desire, philosophical desire to remain POSIX purists, you will write your application as a POSIX, pure POSIX program and then you can just whip together a front end and go native where you need to be native and stay pure where you want to stay pure.
Okay. That's the end of the section here. I'll take some questions.
A SPEAKER: Will it be back on the Web site or soon?
RICO TUDOR: Sure. Yes?
A SPEAKER: Are you including named pipes in pipes? Are name pipes also supported?
RICO TUDOR: Dominic?
DOMINIC GIAMPAOLO: Go to shell and "ls /pipe". There's a pipe file system which --
A SPEAKER: It's empty right now.
DOMINIC GIAMPAOLO: We did this on the file system yesterday. You create two shells. You can "cat" out to a named pipe one shell and then the other shell you can redirect the input from that named pipe and excerpt it a lot better.
RICO TUDOR: Okay. So Cyril is looking at named pipes for us. Any other questions?
Yes?
A SPEAKER: Does fork'ing off a BApplication?
DOMINIC GIAMPAOLO: No, you can fork() with the BApplication.
RICO TUDOR: Next question? Yes?
A SPEAKER: Will "Tracker" support dropping on documents onto shell strips?
RICO TUDOR: Oh, that's a good question: Will tracker allow you to drop documents on POSIX applications.
A SPEAKER: Get $1, $2, whatever?
RICO TUDOR: I would say no, because as a POSIX app there is no API for that.
A SPEAKER: Yahoo.
RICO TUDOR: However, if it's something you can drop onto, then it should be a BApplication and you could construct using these methods --
A SPEAKER: So you don't have RCRV?
RICO TUDOR: Oh, we have RCRV, sure.
A SPEAKER: That's what I mean, mapping dropped on documents at least at launch time.
RICO TUDOR: Oh, at least at launch time, yeah, sure, we already have that. Of course.
Yes?
A SPEAKER: You mentioned possible problems with using printf(), in any application that is also using the GUI and the Be interface.
A SPEAKER: It's not a problem, it's an errata. No, I mean it's a small issue, we're probably going to address it. I don't see any reason why this should be allowed to continue. If you have two threads and both threads -- so this is not a POSIX app, you understand, this is a BApp. If you have two threads, they both call printf(), printf() goes to its buffer, there's a mixup in the buffer, because it's not thread safe.
A SPEAKER: Okay.
RICO TUDOR: And any output will be wrong.
A SPEAKER: Okay. Would this also happen if you're using sprintf(), to just print, format into a local script and then call something?
RICO TUDOR: No, if you're going to call printf() of the sprintf() buffer, then yes.
A SPEAKER: No, but if you use --
RICO TUDOR: If you call system call write, then you avoid this printf() bug or standard I/O bug.
A SPEAKER: If you're using sprint to do the formatting and after that you use something else that --
RICO TUDOR: Then you have a private -- I don't think there's a bug there.
A SPEAKER: Okay. Thank you.
RICO TUDOR: And it is a bug, believe me. As Dominic says, semantically we support things like the standard I/O library within BApplications, so this shouldn't be happening.
Yes?
A SPEAKER: Will the POSIX support ever extend into remote displays similar to the X protocol?
RICO TUDOR: Okay. Will we have --
A SPEAKER: Where you could launch an app, where you could use -- where you could fire up something and network into another box and start an app and have that display remote be used?
RICO TUDOR: Okay. As far as -- it's a network-related question you ask.
BRAD TAYLOR: It's actually an AppServer question.
RICO TUDOR: It's an AppServer question?
BRAD TAYLOR: I think you might be asking if you'd like the AppServer to be -- in addition to being based on sort of the proprietary local interface that we have to go over network transport, so that application running remotely could have the graphics rendered --
RICO TUDOR: The graphics rendered in the display remote processing.
BRAD TAYLOR: Is Benoit here?
DOMINIC GIAMPAOLO: There's been some discussion of it. I don't know that we have any particular plans right now.
RICO TUDOR: In theory, the AppServer will -- only in theory -- I think Benoit may have done crazy experiments at midnight. The AppServer being data driven just like X windows, you send a data stream to it and it talks back to a data stream, you should be able to set up the plumbing to extrude the communication from a kit to the AppServer, but it's not in DR9.
A SPEAKER: Nice.
RICO TUDOR: Yes.
Okay. Well, then I'll just go over quickly the future developments, which you pretty much covered already. Like I said, job control. I think that's going to be in DR10. I think that's just too important.
In addition to that, we'll unify and improve the "termios", that's terminal API POSIX, to encompass all of the serial devices, not just serial ttys and "terminal", but also the hardware serial devices and that will give us a great deal of flexibility in things like for those of you who are going to be using, say, BSerialPort, the kit side of the world, all of that stuff is going to be funneled through "termios". So we're on the kernel side of that one.
ANSI terminal, the idea is to just make it ANSI, ANSI compliant. I have the standard, it's just a matter of doing the work. In the meantime, like I said, try different settings of "TERM=" where you log into a UNIX system. If one doesn't seem to be working for you, just try another one.
Brad, who's our network expert here, I know he wants to do select().
BRAD TAYLOR: Select does work on sockets.
RICO TUDOR: Yeah, select() on sockets, but we have the issue where we want sockets to become file descriptors. I think if you've attended his meetings you'll know what the issues are. We want to do it and in the full generalization of select() we want the select() system call. It's not POSIX, but whereas we want to implement POSIX fully, we're not afraid to add additional things and select() is one of those things which I think is going to happen.
In order to be done properly it will involve sockets, sockets turning into file scriptors so they can be inherited across fork()/exec() and we want select() to work with all file scriptors, whether you're opening pipes or serial devices or anything where the select() system call is defined in the B -- in the BSD standards to -- to work.
That's all I have to say. Thanks for attending.
Oh, questions. Yes?
A SPEAKER: Are you going -- is the documentation going to make it to all the POSIX calls and all the weaknesses of how they interact? Right now it's pretty sketchy.
RICO TUDOR: It's pretty sketchy and I don't know if our -- our overworked documentation team has the energy to track every single function and what we're doing right and what, you know, I think we're going to have to defer to you guys to do a little bit of experimentation. You'll discover what does and doesn't work. We are accessible via the Net. If you just send mail to me, Rico@be.com, I'll give you personalized service.
Yes?
A SPEAKER: I've very impressed by your presentation. I was wondering if you support punch card reader?
RICO TUDOR: Punch card reader. I may be the retro man, but I'm not that retro.
A SPEAKER: What about paper tape?
RICO TUDOR: Okay. Thank you very much.
Home | About Be | Be Products | BeWare | Purchase | Events | Developers | Be User Groups | Support