Day Brown wrote: > [...] And this kernel is without a GUI interface?
The kernel has NO interface. That's the function of other programs, such as the shell (CLI) or X. The only function of the kernel is to control the other programs (user, system and drivers.) > But to judge by the driver install menus, with ANSI color. Depending on who's putting together a system (distribution), they may elect to use menus or not for installs. But again, that's not the kernel! > Why do you need Linux on a SURVPC other than to run a PPP driver and > browser? Because it's VERY WELL suited to what (today) passes for Surv-class hardware. Older distributions can work, but the article pointed out that the new kernel is as small as a VERY old kernel. And the new kernel provides many enhanced new capabilities. So smaller and enhanced... why NOT? Take an old PC, bring it up to date in terms of capabilities, and one of the last arguments to throw it out goes away. > I dont think of folks trying to run a network with a SURVPC; Many do! I knew quite a few folks who used a 386 with Linux as a firewall and home server just fine. While an old kernel may be asking for trouble for such a device, a new (equally small) kernel should be as robust as any other modern configuration. > I expect folks want to continue to run text editors and small > business database tools, like what they've been doing in DOS. So... > how do the Linux tools stack up on a SURVPC with the DOS-OS/2 tools > folks have been using? Perhaps they have an ISP that requires PPP options not available under DOS or OS/2? Or they want spam filtering capabilities not available under either? If an old PC can be made to run current software, it makes a GREAT surv-gateway along the lines of what's been discussed on this list many times! Use the "high horsepower" machine for DOS, windows or whatever old software you love, while using a small, fast and modern Linux on the "old" box to talk to that ISP or do other things your beloved stuff can't. Not to mention that there a lot of people who'd love to run Linux but simply don't have the appropriate hardware. This may be a good solution for them. Not everybody with an old PC is necessarily unwilling to replace DOS with Linux. > What'd be neat, an could prolly be done in less than 10k of assy, > would be for the kernel to understand the dos command set, so that it > wouldnt bitch on the CLI if you forgot which OS you were running. That shouldn't be in the kernel, but it COULD be done easily enough as a shell to replace sh/bash/ksh if desired. Keep in mind, such a shell will probably need to call OTHER programs to be useful, just as COMMAND.COM does under DOS. If you'll recall, a while back, I mentioned the lsh shell, which is described thusly: "Lsh is especially useful for users who have had some DOS experience and are now supposed to do something under UNIX. This shell will ease the transition and make the usage of dialup services extremely easy for them." That package weighs in at about 40K (although it does use other libraries) but could no doubt be trimmed back. Then again, someone has to have the drive and incentive to do that, so it would be a great "do it yourself" project. > Be nice if it had a BATCH compiler also. For the kind of stuff I do > on my own desktop, curses is like using a yacht to go trout fishing. > It's too big, too fast, and cant get in the kind of backwaters I > like to fish in. Uhm, curses has nothing to do with scripts or batch files! More like using a locomotive to go trout fishing! > Is there a Linux tool which can convert DOS binaries to run on the > Linux CLI? Two things come to mind: 1. DOSemu to run dos under dos. 2. A shell or scripts to make underlying commands look like DOS equivalents. You'd have to be more specific about WHICH DOS programs you want though. Some will have no equivalents. > Is there a Linux verion of Ralf Brown? Assuming you mean the interrupt list (and not that there's a DOS program called Ralf Brown -- which supports my troll perl script theory -- there are certainly documents covering system calls, yes. Those are typically done by means of a library, but you COULD code up your own. Just as Ralf's list alone doesn't DO anything on DOS, a list of calls doesn't either. > Or is the whole 9 yards in C? Much of the kernel source is, yes. But you can CALL it from other languages. > And where do the routines C calls come from? The system libraries typically. Or add-on libraries that the developer creates (if nothing suitable pre-exists.) > I find the whole idea of a tiny kernel interesting, but full of > questions. Tiny means fast dont it? 16 bit? Fast, yes. As to 16 bit, I think just the opposite. From: http://www.selenic.com/tiny-about/Reprint-Mackall-OLS2004.pdf "4.2 Optional interfaces For systems with well-defined application requirements, many of the kernel’s APIs are unnecessary. Cutting-edge, obsolete, or obscure features are obvious candidates for con- figurable removal. [...] uid16, vm86: Some of the many legacy interfaces in the kernel. Modern applications and libraries use 32-bit user and group IDs and vm86 support is used to run 16-bit code for emulators like DOSEMU and Wine and for some video drivers used by X." So it sounds like it's being made smaller partly by REMOVING 16 bit (legacy) interfaces. My understanding is that it'll be ONLY "current" software compatible. Seeing as how this list is for "Older PCs" and NOT only DOS, I think this is a great alternative! I hope development proceeds quickly, as I'd like to give it a shot. Nice catch, James! - Bob
