Part 30 - Dec 05 2003

[admin]

#885 From: "maglorcheaprise2003" <maglorcheaprise2003@...>
Date: Thu Dec 11, 2003 8:35 pm
Subject: Adobe Pagemaker 7.0 - ONLY $49.95 NOT $404.95. FREE SHIPPING! maglorcheapr...
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Adobe Illustrator 10 OEM. Only $49.95, Savings -$215.50.
ENHANCED! Adobe Illustrator 10 software defines the future of vector graphics
with groundbreaking creative options and powerful tools for efficiently
publishing artwork on the Web, in print, everywhere...
http://soft.alisasoft.biz/

[admin]

#886 From: Carl <carlossuss@...>
Date: Fri Dec 12, 2003 2:36 am
Subject: Re: Re: OSFREE - garbled front page carlossuss
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Yuri Prokushev wrote:

>** Reply to message from Carl <carlossuss@...> on Thu, 11 Dec 2003
>06:09:16 +0000
>
>
>>I thought I would take the opportunity to jump in here, while you are
>>arguing about the OSFree web page
>>
>>
>Hey! U a welcome!
>
Thank you

>>I can load the first page fine, but other pages have this at the bottom:
>>
>>
>[eated]
>
>
>>+++++++++++++++++++++++++++
>>
>>
>Most probably page cached somewhere in proxy or locally. Try to reload page
>(Ctrl-Reload or Shift-Reload, don't remember correctly). This bug was
>introduced when hitscounter was added. But currently all must work just fine.
>
It's working fine today. Guess it was just a glitch or cache problem
then. I did clear out my cache directory since I last visited
OSFree.org, to do a backup, so maybe that was it.

>Btw, If anyone wants to write some documentation - u a welcom.
>
What's involved? Where does the information for the documentation come
from? Sorry if the questions are a bit basic, but I've never been
involved with any software development. I get free time now and then in
"spits and spirts" if that's of any use to you?

Sadly I'm migrating away from OS/2 to Lindows as my main OS. I've had
happy, loving relationship with OS/2 since version 2, so it kinda feels
like I'm cheating on my lover when I boot up into Lindows! I have never
been able to totally delete my Windoze partition because of certain
programs I need to run, but it looks like Linux will do everything I
need to do. I see so much happening with Linux, but OS/2 seems so
stagnant when it comes to new software. There are some good programs out
there and a lot of hard working people, I know, but try using OS/2 for
capturing & editing movies or creating Flash websites.

Also the installation of Lindows is the easiest & most trouble free out
of any OS I have used, total installation takes 7 minutes to a clean
hard drive. OS/2 always needs tweaking & I have to open my PC to remove
my SCSI card to install eCS from CD. I also have 2 PC's running eCS &
both have different intermittent problems when booting up.

Anyway, I am putting together a cheap old PC to allow me to play with
OS/2 & track the progress of OSFree. I have no intention of moving my
server away from OS/2, even though it does have booting problems, it
only gets rebooted when there's a power failure so that's hardly an
issue

Don't get me wrong, I love OS/2 but I feel it's lagging behind the times
& I have work to do which I can't do with OS/2. Maybe one day with
OSFree? And what happens to OS/2 after 2006? Or eCS? I doubt OSFree will
be finished by then, or will it?

ReactOS looks like an interesting idea...

Carl.

[admin]

#887 From: menchie@...
Date: Fri Dec 12, 2003 5:52 pm
Subject: Re: Digest Number 198 thedugan
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


From: "maglorcheaprise2003" <maglorcheaprise2003@...>
> Subject: Adobe Pagemaker 7.0 - ONLY $49.95 NOT $404.95. FREE SHIPPING!

Hmmm....I use Open Office 1.1, has "output PDF"...works too!

________________________________________________________________________
From: Carl <carlossuss@...>
Subject: Re: Re: OSFREE - garbled front page
> >>I thought I would take the opportunity to jump in here, while you are
> >>arguing about the OSFree web page

I just have a different view on the nature of Web Documents, YMMV.
It's nothing personal. I get 20 mpg in the Voyager...

> Sadly I'm migrating away from OS/2 to Lindows as my main OS. I've had

Well...crap.....

> happy, loving relationship with OS/2 since version 2, so it kinda feels
> like I'm cheating on my lover when I boot up into Lindows! I have never
> been able to totally delete my Windoze partition because of certain
> programs I need to run, but it looks like Linux will do everything I
> need to do. I see so much happening with Linux, but OS/2 seems so
> stagnant when it comes to new software. There are some good programs out
> there and a lot of hard working people, I know, but try using OS/2 for
> capturing & editing movies or creating Flash websites.
>
> Also the installation of Lindows is the easiest & most trouble free out
> of any OS I have used, total installation takes 7 minutes to a clean

What kind of hardware are you running?

> hard drive. OS/2 always needs tweaking & I have to open my PC to remove
> my SCSI card to install eCS from CD. I also have 2 PC's running eCS &
> both have different intermittent problems when booting up.
>
> Anyway, I am putting together a cheap old PC to allow me to play with
> OS/2 & track the progress of OSFree. I have no intention of moving my
> server away from OS/2, even though it does have booting problems, it
> only gets rebooted when there's a power failure so that's hardly an
> issue
>
> Don't get me wrong, I love OS/2 but I feel it's lagging behind the times
> & I have work to do which I can't do with OS/2. Maybe one day with
> OSFree? And what happens to OS/2 after 2006? Or eCS? I doubt OSFree will
> be finished by then, or will it?
>
> ReactOS looks like an interesting idea...

I've placed 0.1.4 on this HD, it works, but there's little in the way of
functionality. If they stay on track, it may be my future OS. Big IF....

BUT - even if they get the core done, I *have* all the native DLL's etc
from my windoze installation.

I haven't tried to mix them yet, I just don't have the spare time to do
that. Un-arcing all those CAB files will be a pain....
-------------------------------------------------------------------------
From some member of the Dugan family
Big Bang = "Let There Be Light"

[admin]

#888 From: "Yuri Prokushev" <yuri_prokushev@mail.ru>
Date: Mon Dec 15, 2003 2:45 pm
Subject: Re: Re: OSFREE - garbled front page prokushev
Offline Offline
Send Email Send Email


** Reply to message from Carl <carlossuss@...> on Thu, 11 Dec 2003
23:36:34 +0000

> >Btw, If anyone wants to write some documentation - u a welcom.
> What's involved? Where does the information for the documentation come
> from? Sorry if the questions are a bit basic, but I've never been
> involved with any software development. I get free time now and then in
> "spits and spirts" if that's of any use to you?
Mainly documenting of command line tools. Source of information: buildin help
info, sources and notes in sources. Also talks with tool developer(s). If
automatic source documentation tools will allow to provide some information,
then source documentation.

Format of documentation: ipf (in future - xml)

> Sadly I'm migrating away from OS/2 to Lindows as my main OS. I've had
[eated]
> Don't get me wrong, I love OS/2 but I feel it's lagging behind the times
> & I have work to do which I can't do with OS/2. Maybe one day with
> OSFree? And what happens to OS/2 after 2006? Or eCS? I doubt OSFree will
> be finished by then, or will it?
Who knows?

> ReactOS looks like an interesting idea...
Most probably yes. ReactOS progress is significant. In near future expected
worked (in general) GUI. If so, then implemention of PM API is not so hard
task.

wbr,
Yuri

[admin]

#889 From: criguada@...
Date: Tue Dec 16, 2003 2:34 pm
Subject: Kernel development criguada
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Hi all,
I was reading the "eComStation future" article by Don Eitner. His
perspective does have some right points, but it doesn't convince me
completely. So I tried putting in clear my thoughts, and now I'm
sharing them with you, to see if we can come up with something.

1) It is clear that the OS/2 community isn't after the osFree project,
either because they (we) don't have the strength to follow such a big
project, either because they've lost faith to osFree due to the leaked
sources problem.

2) I think it is time to put hands on a kernel replacement. This could
even breath new life into the project, moving it into the "serious
projects" land, and attracting new programmers. I'm specifically
thinking about Knut Stange Osmundsen (sp?) which is a great low-level
programmer, and seems attracted by "interesting, nearly impossible"
tasks

3) Like Don, I think we should NOT reinvent the wheel. It should be
better to take an already established project and build a
"compatibility layer" on it, leaving native development for later stages.

4) Unlike Don, I DON'T think we should rewrite the whole thing, not
immediately at least. Let's build a compatibility layer on top of the
_kernel_ (doscalls, etc.), and try to run original IBM code on top of
it. Then move slowly towards replacing parts and adding features (and
better using the underlying kernel capabilities).

5) In this view, I think it would be better NOT to use a _full_ OS,
with it's own established personality and tools, like *BSD is. It
would be better to build upon an open kernel that gives us the
features we need.

6) Which possibilities dows we have? Let's see:
- *BSD (like Don says)
- Darwin (this is the actual base of the new MacOS. BSD-derived)
- Linux

This are the first that come to mind. Not one of these has me
satisfied. Why?

- I am used to a desktop operating system, with a consistent look and
feel. Unices don't have a consistent look and feel.
- I don't want to fiddle with kernel recompiles, etc. I don't know
well about *BSD and Darwin; surely Linux is going towards the "kernel
loadable modules" way, but it's still a long way to go.
- I am used to a strong multitasking and multithreading kernel. Unices
lack at least in the multithreading capabiltites, and (at least in the
original Unix model) use plain round-robin scheduling.
- All of these alternatives don't fit well with point (5) above.

I started to think about an already existing kernel or OS that have
the capabilities we need. Again, let's see:

- There's ReactOS, like someone said here. It is going on quite well
(at least this is what it looks like). We could use its kernel, but
would it make sense? It would have more sense to join the project and
build an OS/2 personality. Personally, I'd like a cleaner approach,
but it is a possibility.

- There's OpenBeOS. The BeOS kernel traditionally had all that we
need, and it supported extended atributes on the file system like OS/2
(although this is not a kernel related thing, probably). OpenBeOS is
based on the NewOS kernel (newos.sf.net), which, in his author's
words, is designed to be easily customized.


Personally, I'd like to investigate this last possibility, and get
feedback from other group members, preferably those which (unlike me)
possess a good technical knowledge about kernel development, and are
willing to do something.

So, start adding comments, and please NO flames, this is not an
OS-War, and all that has been said is only my *personal* point of view.

Bye

Cris

[admin]

#890 From: "Yuri Prokushev" <yuri_prokushev@mail.ru>
Date: Tue Dec 16, 2003 9:03 pm
Subject: Re: Kernel development prokushev
Offline Offline
Send Email Send Email


** Reply to message from criguada@... on Tue, 16 Dec 2003 11:34:34 -0000

> I was reading the "eComStation future" article by Don Eitner. His
> perspective does have some right points, but it doesn't convince me
> completely. So I tried putting in clear my thoughts, and now I'm
> sharing them with you, to see if we can come up with something.
>
> 1) It is clear that the OS/2 community isn't after the osFree project,
> either because they (we) don't have the strength to follow such a big
> project, either because they've lost faith to osFree due to the leaked
> sources problem.
True. But things can be done step by step

> 2) I think it is time to put hands on a kernel replacement. This could
> even breath new life into the project, moving it into the "serious
> projects" land, and attracting new programmers. I'm specifically
> thinking about Knut Stange Osmundsen (sp?) which is a great low-level
> programmer, and seems attracted by "interesting, nearly impossible"
> tasks
Heh, tasks seems not too impossible if just add not lot of missed features.

> 3) Like Don, I think we should NOT reinvent the wheel. It should be
> better to take an already established project and build a
> "compatibility layer" on it, leaving native development for later stages.
Exactly. Fully agree.

> 4) Unlike Don, I DON'T think we should rewrite the whole thing, not
> immediately at least. Let's build a compatibility layer on top of the
> _kernel_ (doscalls, etc.), and try to run original IBM code on top of
> it. Then move slowly towards replacing parts and adding features (and
> better using the underlying kernel capabilities).
Yep.

> 5) In this view, I think it would be better NOT to use a _full_ OS,
> with it's own established personality and tools, like *BSD is. It
> would be better to build upon an open kernel that gives us the
> features we need.
Again, agree.

> 6) Which possibilities dows we have? Let's see:
> - *BSD (like Don says)
> - Darwin (this is the actual base of the new MacOS. BSD-derived)
> - Linux
Ghm... From my point of view using kernel from different OS family (not so good
idea. And poll result (Linux on second place) seems very strange for me.

> This are the first that come to mind. Not one of these has me
> satisfied. Why?
>
> - I am used to a desktop operating system, with a consistent look and
> feel. Unices don't have a consistent look and feel.
Heh. Darwin is example. Problem mostly in Workplace implementation &
standartisation.

> - I don't want to fiddle with kernel recompiles, etc. I don't know
> well about *BSD and Darwin; surely Linux is going towards the "kernel
> loadable modules" way, but it's still a long way to go.
True. Recompiling kernel for any (ok, most of) new task... Grrr...

> - I am used to a strong multitasking and multithreading kernel. Unices
> lack at least in the multithreading capabiltites, and (at least in the
> original Unix model) use plain round-robin scheduling.
Again, I consider kernels of OSes from another family must not be selected
as osFree base.

> - All of these alternatives don't fit well with point (5) above.
Exactly. *nixes is instumental environmet. Just great for developers (heh,
sure?) but hell for users.

> I started to think about an already existing kernel or OS that have
> the capabilities we need. Again, let's see:
>
> - There's ReactOS, like someone said here. It is going on quite well
> (at least this is what it looks like). We could use its kernel, but
> would it make sense? It would have more sense to join the project and
> build an OS/2 personality. Personally, I'd like a cleaner approach,
> but it is a possibility.
We can join to the project. But remember - ReactOS is _Windows_ clone (read as
Win32 API). But we want to have OS/2 API. If OS/2 subsystem will be developed
as part of ReactOS project then forgot about OS/2. It's Windows NT. ReactOS
will act as NT, not OS/2. OS/2 subsystem will be just another compatability
layer. But if OS/2 subsystem will be developed as core subsystem, then Win32
will be treated as additional compatability API. Again, ReactOS project will
force to use Explorer as the shell. But we need WPS (really, I consider
SOM/CORBA must be core of osFree, not 'classic' PM API). We need REXX, ReactOS
will force with WSS (windows scripting server).

So, clear division of osFree project from ReactOS project (Win32
implementation, to be clear) can be solution. And remember, results of osFree
project can be used in ReactOS project and vice versa.

> - There's OpenBeOS. The BeOS kernel traditionally had all that we
> need, and it supported extended atributes on the file system like OS/2
> (although this is not a kernel related thing, probably). OpenBeOS is
> based on the NewOS kernel (newos.sf.net), which, in his author's
> words, is designed to be easily customized.
Know nothing about it yet.

> Personally, I'd like to investigate this last possibility, and get
> feedback from other group members, preferably those which (unlike me)
> possess a good technical knowledge about kernel development, and are
> willing to do something.
nice to hear.

> So, start adding comments, and please NO flames, this is not an
> OS-War, and all that has been said is only my *personal* point of view.
I'll try

II try to describe my criterions in kernel selection:

1) divers avalability. As for generic devices as for new devices. Most
preferrable - for any devices
2) CP/M family. Multiple filesystem roots. Example,
devicename(macos?)/driveletter(CPM/DOS/WIN/OS2) assignment for physical/logical
device/drive.
3) Fast and easy implementation of OS/2 API.
4) Dynamic-linking, not static, kernel design (as on drivers level as on
application level)
5) Easy porting from other OSes

According ReactOS (kernel):

1) I consider we will not have problems with drivers avalability. Most vendors
produce drivers for NT.
2) NT/ReactOS is CP/M family system
3) In most cases OS/2 API will be implemented as easest wrappers around Native
API functions. Also exists (public domain) implementation of OS/2 DOSCALLS API
on top of Win32 API (remember, Win32 is just easest wrappers on top Native API)
4) Dynamiclinking.
5) Porting from other OSes. Porting from Win32 OSes not a problem. ReactOS
implementing Win32. Really, no any porting. Just corresponding subsystem.
According DOS - NTVDM subsystemp. According Win16 - WoW (Windows on Windows)
subsystem. *nix applications - POSIX subsystem good base for such ports.

Really, support of base OS/2 API (doscalls) can be done easely and very fast.
For this: a) LX loader b) port OS/2 on top of Win32 implementation to OS/2 on
top of Native c) write missed functions.

Native API contains most of required functions. Or, may be, all required
functions.

And we can easely configure OS to load any preffered shell and any prefferred
subsystem by default.

I consider ReactOS (kernel) is the best (or one of the best) solution. And main
argument it is very quick implementation in comparation with other kernels.

No problems with drivers (ideally), with support of 'mainstream'
applications/fileformats, with kernel development {}.

BTW, PM can be implemented via Win32k part of Win32 subsystem. Result - shared
desktop with windows applications.

wbr,
Yuri

[admin]

#891 From: Josщ Francisco Garcэa Martэnez <correo@...>
Date: Tue Dec 16, 2003 9:24 pm
Subject: Re: Kernel development jfgarcia_mx
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Hi.

I agree in all points with Cris.

At least we have an important subject in the list.


Yuri Prokushev wrote:

> ** Reply to message from criguada@... on Tue, 16 Dec 2003
> 11:34:34 -0000
>
> > I was reading the "eComStation future" article by Don Eitner. His
> > perspective does have some right points, but it doesn't convince me
> > completely. So I tried putting in clear my thoughts, and now I'm
> > sharing them with you, to see if we can come up with something.
> >
> > 1) It is clear that the OS/2 community isn't after the osFree project,
> > either because they (we) don't have the strength to follow such a big
> > project, either because they've lost faith to osFree due to the leaked
> > sources problem.
> True. But things can be done step by step
>
> > 2) I think it is time to put hands on a kernel replacement. This could
> > even breath new life into the project, moving it into the "serious
> > projects" land, and attracting new programmers. I'm specifically
> > thinking about Knut Stange Osmundsen (sp?) which is a great low-level
> > programmer, and seems attracted by "interesting, nearly impossible"
> > tasks
> Heh, tasks seems not too impossible if just add not lot of missed
> features.
>
> > 3) Like Don, I think we should NOT reinvent the wheel. It should be
> > better to take an already established project and build a
> > "compatibility layer" on it, leaving native development for later
> stages.
> Exactly. Fully agree.
>
> > 4) Unlike Don, I DON'T think we should rewrite the whole thing, not
> > immediately at least. Let's build a compatibility layer on top of the
> > _kernel_ (doscalls, etc.), and try to run original IBM code on top of
> > it. Then move slowly towards replacing parts and adding features (and
> > better using the underlying kernel capabilities).
> Yep.
>
> > 5) In this view, I think it would be better NOT to use a _full_ OS,
> > with it's own established personality and tools, like *BSD is. It
> > would be better to build upon an open kernel that gives us the
> > features we need.
> Again, agree.
>
> > 6) Which possibilities dows we have? Let's see:
> > - *BSD (like Don says)
> > - Darwin (this is the actual base of the new MacOS. BSD-derived)
> > - Linux
> Ghm... From my point of view using kernel from different OS family
> (not so good
> idea. And poll result (Linux on second place) seems very strange for me.
>
> > This are the first that come to mind. Not one of these has me
> > satisfied. Why?
> >
> > - I am used to a desktop operating system, with a consistent look and
> > feel. Unices don't have a consistent look and feel.
> Heh. Darwin is example. Problem mostly in Workplace implementation &
> standartisation.
>
> > - I don't want to fiddle with kernel recompiles, etc. I don't know
> > well about *BSD and Darwin; surely Linux is going towards the "kernel
> > loadable modules" way, but it's still a long way to go.
> True. Recompiling kernel for any (ok, most of) new task... Grrr...
>
> > - I am used to a strong multitasking and multithreading kernel. Unices
> > lack at least in the multithreading capabiltites, and (at least in the
> > original Unix model) use plain round-robin scheduling.
> Again, I consider kernels of OSes from another family must not be
> selected
> as osFree base.
>
> > - All of these alternatives don't fit well with point (5) above.
> Exactly. *nixes is instumental environmet. Just great for developers (heh,
> sure?) but hell for users.
>
> > I started to think about an already existing kernel or OS that have
> > the capabilities we need. Again, let's see:
> >
> > - There's ReactOS, like someone said here. It is going on quite well
> > (at least this is what it looks like). We could use its kernel, but
> > would it make sense? It would have more sense to join the project and
> > build an OS/2 personality. Personally, I'd like a cleaner approach,
> > but it is a possibility.
> We can join to the project. But remember - ReactOS is _Windows_ clone
> (read as
> Win32 API). But we want to have OS/2 API. If OS/2 subsystem will be
> developed
> as part of ReactOS project then forgot about OS/2. It's Windows NT.
> ReactOS
> will act as NT, not OS/2. OS/2 subsystem will be just another
> compatability
> layer. But if OS/2 subsystem will be developed as core subsystem, then
> Win32
> will be treated as additional compatability API. Again, ReactOS
> project will
> force to use Explorer as the shell. But we need WPS (really, I consider
> SOM/CORBA must be core of osFree, not 'classic' PM API). We need REXX,
> ReactOS
> will force with WSS (windows scripting server).
>
> So, clear division of osFree project from ReactOS project (Win32
> implementation, to be clear) can be solution. And remember, results of
> osFree
> project can be used in ReactOS project and vice versa.
>
> > - There's OpenBeOS. The BeOS kernel traditionally had all that we
> > need, and it supported extended atributes on the file system like OS/2
> > (although this is not a kernel related thing, probably). OpenBeOS is
> > based on the NewOS kernel (newos.sf.net), which, in his author's
> > words, is designed to be easily customized.
> Know nothing about it yet.
>
> > Personally, I'd like to investigate this last possibility, and get
> > feedback from other group members, preferably those which (unlike me)
> > possess a good technical knowledge about kernel development, and are
> > willing to do something.
> nice to hear.
>
> > So, start adding comments, and please NO flames, this is not an
> > OS-War, and all that has been said is only my *personal* point of view.
> I'll try
>
> II try to describe my criterions in kernel selection:
>
> 1) divers avalability. As for generic devices as for new devices. Most
> preferrable - for any devices
> 2) CP/M family. Multiple filesystem roots. Example,
> devicename(macos?)/driveletter(CPM/DOS/WIN/OS2) assignment for
> physical/logical
> device/drive.
> 3) Fast and easy implementation of OS/2 API.
> 4) Dynamic-linking, not static, kernel design (as on drivers level as on
> application level)
> 5) Easy porting from other OSes
>
> According ReactOS (kernel):
>
> 1) I consider we will not have problems with drivers avalability. Most
> vendors
> produce drivers for NT.
> 2) NT/ReactOS is CP/M family system
> 3) In most cases OS/2 API will be implemented as easest wrappers
> around Native
> API functions. Also exists (public domain) implementation of OS/2
> DOSCALLS API
> on top of Win32 API (remember, Win32 is just easest wrappers on top
> Native API)
> 4) Dynamiclinking.
> 5) Porting from other OSes. Porting from Win32 OSes not a problem. ReactOS
> implementing Win32. Really, no any porting. Just corresponding subsystem.
> According DOS - NTVDM subsystemp. According Win16 - WoW (Windows on
> Windows)
> subsystem. *nix applications - POSIX subsystem good base for such ports.
>
> Really, support of base OS/2 API (doscalls) can be done easely and
> very fast.
> For this: a) LX loader b) port OS/2 on top of Win32 implementation to
> OS/2 on
> top of Native c) write missed functions.
>
> Native API contains most of required functions. Or, may be, all required
> functions.
>
> And we can easely configure OS to load any preffered shell and any
> prefferred
> subsystem by default.
>
> I consider ReactOS (kernel) is the best (or one of the best) solution.
> And main
> argument it is very quick implementation in comparation with other
> kernels.
>
> No problems with drivers (ideally), with support of 'mainstream'
> applications/fileformats, with kernel development {}.
>
> BTW, PM can be implemented via Win32k part of Win32 subsystem. Result
> - shared
> desktop with windows applications.
>
> wbr,
> Yuri
>
>
> To unsubscribe from this group, send an email to:
> osFree-unsubscribe@yahoogroups.com
>
>
>
>
> *Yahoo! Groups Sponsor*
>
<http://rd.yahoo.com/SIG=12cvrkqe2/M=259 ... egroupweb/
S=1705006559:HM/EXP=1071684249/A=1524963/R=0/*http://hits.411web.com/cgi-bin/aut
oredir?camp=556&lineid=3614674&prop=egroupweb&pos=HM>
>
>
>
> ------------------------------------------------------------------------
> *Yahoo! Groups links*
>
> * To visit your group on the web, go to:
> http://groups.yahoo.com/group/osFree/
>
> * To unsubscribe from this group, send an email to:
> osFree-unsubscribe@yahoogroups.com
> <mailto:osFree-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service <http://docs.yahoo.com/info/terms/>.
>
>

[admin]

#892 From: "Michal Necasek" <michaln@...>
Date: Wed Dec 17, 2003 7:59 am
Subject: Re: Kernel development michalnec
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


On Tue, 16 Dec 2003 11:34:34 -0000, criguada@... wrote:

>Personally, I'd like to investigate this last possibility, and get
>feedback from other group members, preferably those which (unlike me)
>possess a good technical knowledge about kernel development, and are
>willing to do something.
>
A super duper kernel will do you no good if you don't have device
support. Lack of drivers is what helped kill OS/2.


Michal

[admin]

#893 From: Davey Brain <dsbrain@...>
Date: Wed Dec 17, 2003 2:47 pm
Subject: Re: Kernel development dsbrain2001
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Michal Necasek wrote thusly:
> On Tue, 16 Dec 2003 11:34:34 -0000, criguada@... wrote:
>
>
>>Personally, I'd like to investigate this last possibility, and get
>>feedback from other group members, preferably those which (unlike me)
>>possess a good technical knowledge about kernel development, and are
>>willing to do something.
>>
>
> A super duper kernel will do you no good if you don't have device
> support. Lack of drivers is what helped kill OS/2.
>
>
> Michal

OS/2 may be on life-support, but it's sure not dead. I just got my
18-year-old Linux geek best friend to give Warp 4 a try. He loves it and
is actually considering buying eCS 1.1 to upgrade. But device support is
a big issue. I have a Dell with Win98SE on my SOHO network just to use a
USB scanner and 2 very cheap cameras for eBay items.

I'm trying to learn how to write drivers right now. Problem is I come
from the days of BASIC, Cobol and Pascal. C isn't bad I'm hitting a
block with but C++. I just can't make the jump from procedural to OOP.
--
Davey Brain
dsbrain@NOSPAM!neosplice.com or
dsbrain2001@...!com

"In times of universal deceit, telling the truth becomes a revolutionary
act."-George Orwell

Gigabyte 7VKML AMD Athlon 1700XP+ Savage 4 AGP 4X 32M
This eCS-OS/2 system uptime is 18 days 18 hrs 50 mins and 20 secs

[admin]

#894 From: tomleem@...
Date: Wed Dec 17, 2003 4:26 pm
Subject: Re: Kernel development bigwarpguy
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


--- In osFree@yahoogroups.com, "Michal Necasek" <michaln@p...> wrote:
> On Tue, 16 Dec 2003 11:34:34 -0000, criguada@l... wrote:
>
> >Personally, I'd like to investigate this last possibility, and get
> >feedback from other group members, preferably those which (unlike me)
> >possess a good technical knowledge about kernel development, and are
> >willing to do something.
> >
> A super duper kernel will do you no good if you don't have device
> support. Lack of drivers is what helped kill OS/2.
>
>
> Michal

A lack of device driver might not have helped OS/2 but it
did not kill it since OS/2 is not dead (IMHO).

BigWarpGuy