Text 3702, 130 rader
Skriven 2005-10-07 16:06:00 av CHARLES ANGELICH (1:123/140)
     Kommentar till en text av MAURICE KINAL
Ärende: software for linspire
=============================

123c7d28c132
linux



Hello Maurice - 

CA>> Wirth wrote OBERON some years ago (over a decade?) and
CA>> after my experiences with OBERON's maintainers I'd doubt
CA>> they've updated that aspect of it. 

MK> Another dead OS. 

Seems so, yes. The maintainers like to use it because the
system file format is so unusual. They keep their 'notes' on
OBERON floppies while doing lab research and don't need to
worry about anyone taking their floppy with all their research
data on it. They'd not be able to read the files with anything
other than OBERON. Sort of a fancy encryption scheme for them
so that they really don't _want_ average people to have access
to a working OBERON install. 

CA>> Not that they couldn't - they're mainly PhDs and Master
CA>> Degrees in computer sciences. 

MK> Good for them. 

Half of them are snobs, the other half are followers of the
snobs. We didn't get along very well at all. 

CA>> Not really. I would guess some additional hardware (PIAs?)
CA>> under software control to kill power to the connector
CA>> prior to unplugging the drive would be needed. 

MK> Right. That is why I got the array as it has it's own power
MK> source (two small hotwapping power supplies) so the
MK> controller need not worry about that aspect. The trick will
MK> be to catch any changes on the array and act accordingly
MK> (mounting new ones). If nothing else, simply removing and
MK> then probing the module ought to be sufficient as far as
MK> the system is concerned. I had to do that with usb flash
MK> devices at one time to take care of hotswapping them. Seems
MK> hotplug does a good job of that now and may be evolved far
MK> enough now to also take care of this particular problem.
MK> We'll see once I get everything in place. I am confident. 

This 'hotplug' is written to inform the kernel when a device is
added/removed? 

MK>>> controls. Offhand I think it is doable, especially if the
MK>>> contoller is modular and can be unloaded on the fly. 

CA>> If by 'unloaded' you mean powered off then yes I would
CA>> guess so. 

MK> That part is simple and the offsystem array takes care of
MK> that. I meant the kernel itself. Hotplug should work for
MK> catching changes but if not then unloading the kernel
MK> module, physically swap the drives, and then probing the
MK> module for that particular contoller should work. I've had
MK> to do this before so I already have a backup plan in case
MK> hotplug has issues with my scheme. 

Ah yes, wasn't thinking about informing the kernel that a
device was no longer available. :-) 

CA>> My point being that GNU/Linux is only as good as the
CA>> supporting code regardless how good (or not good) the
CA>> kernel might be or become. The reputation of Linux depends
CA>> on my programmers or groups of programmers taking quality
CA>> seriously when writing or modifying their particular piece
CA>> of GNU/Linux. 

MK> They seem to be doing a great job in the case of the basic
MK> functionality. 

Yes, AMOF I think the GNU support for basic linux functions has
been exceptional. Linus and those who work with the kernel seem
to get all the attention but I personally feel the GNU support
is equally or even _more_ important and worthy of some
recognition. 

MK> Anything else I find lacking I always seem to be able to
MK> take care of either using what's available or writing my
MK> own for a specific purpose. 

Certainly. You would be much too limited if you could not do
that. 

MK> DOS is too outdated and needy to do an efficient job. It
MK> can't even do simple maintenance here given all the
MK> oddities here. 

DOS is notorious for it's direct access to hardware. It _could_
do many things but then why limit yourself to a single-task OS
when there is a perfectly good multitasking OS (with source)
available to work with. :-) 

MK> I like to play with ideas and Linux seems best suited to my
MK> 'cause'. Some of the BSD's weren't too bad but I found
MK> Slackware specifically to be the most adaptable. I did, and
MK> still do, have to alter some of the basic packages to get
MK> rid of unwanted and unneeded dependancies but seeing they
MK> have the least then it makes it the perfect place to start
MK> from. 

I haven't scrounged around in the source code as yet but I do
have the impression that SlackWare (in general) follows the
"keep it simple" philosophy which makes adding/removing modules
and recoding a much easier thing to do. 

I was a huge fan of small/tight coding probably because I
learned ASM first before any other languages. I have a modified
version of some of Borland's C compiler library that allows me
to compile C code into binaries almost as small as the
equivalent ASM code. Mainly by removing "printf". I only did it
too see how well it worked (was not my idea) and haven't used
it much but it is impressive (to me). :-) 

>
>        ,                          ,
>      o/      Charles.Angelich      \o       ,
>     <|                              |>  __o/
>     / >          USA, MI           < \   __\__
 

--- * ATP/16bit 2.31 * 
... DOS the Ghost in the Machine! http://www.devedia.com/dosghost/
 * Origin: Try Our Web Based QWK: DOCSPLACE.ORG (1:123/140)