Hi folks,
a very general question:
why are you developing a completely new kernel instead of using an existing one like linux or hurd and running reactos just as a subsystem, perhaps with some kernel improvements.
For example: linux brings very good memory management and filesystem. If you want to use Xwindow, you can use a direct graphics backend for the UI. Console applications could run directly on stdio as all unix console applications do.
Doing so lets you run the windows applications within a another host operating system and integrating both together.
So what are the advantages of another own kernel against a subsystem in another host operating system ?
cu
We want API and even ABI compatibility. And also semantic compatibility, which is very hard do gain with an emulation layer. ABI = binary compatible
Enrico Weigelt schrieb:
Hi folks,
a very general question:
why are you developing a completely new kernel instead of using an existing one like linux or hurd and running reactos just as a subsystem, perhaps with some kernel improvements.
For example: linux brings very good memory management and filesystem. If you want to use Xwindow, you can use a direct graphics backend for the UI. Console applications could run directly on stdio as all unix console applications do.
Doing so lets you run the windows applications within a another host operating system and integrating both together.
So what are the advantages of another own kernel against a subsystem in another host operating system ?
cu
* Robert Köpferl rob@koepferl.de [2004-02-15 16:51:31 +0100]:
Hi,
We want API and even ABI compatibility. And also semantic compatibility, which is very hard do gain with an emulation layer.
what's exactly the difference to an approach like win from this point ? since NT has a microkernel, it shoulnd be so hard to get a wide range of drivers running in an emulation.
+ printer drivers (IMHO) normally operate as a GDI device and produce output for the interface devices (call appr. functions) --> should be runnable in a libwine-like environment
+ codecs, etc are (IMHO) normal userland dlls which already work in some gnu or x-platform players.
+ video hardware drivers are a bit more trickier, but they mostly do some IO-ops and operate in a framebuffer or somthing similar. IMHO they also have to allocate their resources from the kernel instead of doing hard direct hardware access (manipulatoing CPU, etc) so it should be possible to emulate this.
So what exactly makes the emulation so bad that you decided to write a completely new kernel, which means rewriting most functionality of existing and heavily tested kernels like linux ?
(dont get me wrong - i dont want to call you stupid, but I just wanna understand the reeasons why you start such a huge project instead of imporoving other quite good working ones)
cu
Same reason many companies don't bother to support Linux. Linux kernel-mode APIs change very often and Linux APIs are usually not backwards compatible.
From kernel 2.6 you even need to compile your driver with the same compiler
that is used to compile the kernel. So, if you want to support two Linux distributions which are compiled with different compilers, then you need to distribute two binaries of your driver. If you want to support SMP configuration (in addition to UP configuration), you need to distribute two additional binaries.
Casper
-----Original Message----- From: ros-general-bounces@reactos.com [mailto:ros-general-bounces@reactos.com] On Behalf Of Enrico Weigelt Sent: 15. februar 2004 16:31 To: ros-general@reactos.com Subject: [ros-general] why folks
Hi folks,
a very general question:
why are you developing a completely new kernel instead of using an existing one like linux or hurd and running reactos just as a subsystem, perhaps with some kernel improvements.
For example: linux brings very good memory management and filesystem. If you want to use Xwindow, you can use a direct graphics backend for the UI. Console applications could run directly on stdio as all unix console applications do.
Doing so lets you run the windows applications within a another host operating system and integrating both together.
So what are the advantages of another own kernel against a subsystem in another host operating system ?
cu
* Casper Hornstrup chorns@users.sourceforge.net [2004-02-15 17:16:50 +0100]:
Same reason many companies don't bother to support Linux. Linux kernel-mode APIs change very often and Linux APIs are usually not backwards compatible.
Well, that's one reason where it gets its performance and flexibility from.
BTW: the APIs for things which are interesting for hardware vendors dont change very much (normally in one major release, the things stay the same - and they dont change in less than a year) Binary interfaces may change several times, but it just takes a recompile to make it work. At least you have to ship two builds, one for smp + no-smp. Also different builds for several architectures are required.
So you want to set up a buildfarm for those different targets. Once we have one, it doesnt really matter if we have distinctions between kernel versions.
And if you really _need_ binary compatibility, its possible to plug in an ABI-adaptor, which allows running third-party binary modules. This of course, takes away all these optimizations for those modules, but they're working.
So it doesnt need to develop a new kernel just to have a consitent driver ABI.
<snip>
So, if you want to support two Linux distributions which are compiled with different compilers, then you need to distribute two binaries of your driver. If you want to support SMP configuration (in addition to UP configuration), you need to distribute two additional binaries.
What's the problem ? Some hardware vendors are already doing it.
If you really, really want one binary module (i.e. you feel you cannot publish sourcecode due some contracts) you can write a very small wrapper which loads the real binary driver. This wrapper will be opensource and built against the current kernel.
Have a look at nvidia's binary drivers. They went this way.
cu
At 23.23 16/02/2004, you wrote:
Well, that's one reason where it gets its performance and flexibility from.
[...]
don't insist. ReactOS is going South, and it's not heading back. We don't give a damn about the wonders and rivers of mead and fields of gold that lie North, everyone knows about those. We want to know what lies South. We really, positively, definitely do
Don't waste your time and ours, it's not like rationalizing yet more will make us change our minds after years of dedicated hard work. In fact, rationalizing _never works_ - either you get the concept right on the first shot, or you find yourself stuck in an exercise of dead horse dragging: not so fun to begin with, and it only gets worse
Yea, our KJK. Don't be so hard to guests. However you are right. Guest: If we decided to do so for years, we will not make a 180° turn due to your apearing.
KJK::Hyperion schrieb:
At 23.23 16/02/2004, you wrote:
Well, that's one reason where it gets its performance and flexibility from.
[...]
don't insist. ReactOS is going South, and it's not heading back. We don't give a damn about the wonders and rivers of mead and fields of gold that lie North, everyone knows about those. We want to know what lies South. We really, positively, definitely do
Don't waste your time and ours, it's not like rationalizing yet more will make us change our minds after years of dedicated hard work. In fact, rationalizing _never works_ - either you get the concept right on the first shot, or you find yourself stuck in an exercise of dead horse dragging: not so fun to begin with, and it only gets worse _______________________________________________ ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
* Robert Köpferl rob@koepferl.de [2004-02-17 01:09:07 +0100]:
Yea, our KJK. Don't be so hard to guests. However you are right.
Guest: If we decided to do so for years, we will not make a 180° turn due to your apearing.
I never wanted you to do so. I just wanted to know your reasons.
cu
You seem to have the impression that the architecture of a kernel doesn't matter for the apps you want to run on it. "Just plug in a subsystem". It simply doesn't work that way. What you are suggesting is taking a Harley Davidson motor cycle and a Ferrari and swap the engines. "Hey, they're just engines, right?". Although you could maybe make it work, the end result will be rather disappointing.
Gé van Geldorp.
* KJK::Hyperion noog@libero.it [2004-02-17 00:45:02 +0100]:
At 23.23 16/02/2004, you wrote:
Well, that's one reason where it gets its performance and flexibility from.
[...]
don't insist. ReactOS is going South, and it's not heading back. We don't give a damn about the wonders and rivers of mead and fields of gold that lie North, everyone knows about those. We want to know what lies South. We really, positively, definitely do
What do you want to say with this ?
<snip>
Don't waste your time and ours, it's not like rationalizing yet more will make us change our minds after years of dedicated hard work. In fact,
You completely misunderstood me. I dont want to change your mind, I just wanted to know you reasons for your decisions. I'd just like to know, what existing OS'es dont have what you require.
cu
* Patrick Mauritz oxygene@studentenbude.ath.cx [2004-02-17 14:53:26 +0100]:
On Tue, Feb 17, 2004 at 02:31:35PM +0100, Enrico Weigelt wrote:
I'd just like to know, what existing OS'es dont have what you require.
a post-1980 OS architecture, for a start.
You didnt really answer the question.
BTW the architecture of the Linux kernel is newer than 1980, although it provides a unix-style userland vm. I dont see whats wrong with this, yet - but I'd like to hear your arguments.
cu
Am Dienstag, 17. Februar 2004 19:47 schrieb Enrico Weigelt:
You didnt really answer the question.
sorry, I guess there were too many, hidden in too many mails
BTW the architecture of the Linux kernel is newer than 1980, although it provides a unix-style userland vm. I dont see whats wrong with this, yet - but I'd like to hear your arguments.
people tend to joke about the change in WinNT4 where parts of the graphic driver were moved to kernelspace and point to the "superior" design of linux.
let's see: - fbdev: reduced functionality, unstable graphic drivers with a real management problem - DRM/DRI+agpgart: kernelguard with userspace module, 3D only - XFree86: drivers in userspace that get access to ring0 instructions (inb/outb), enumerate the pci bus by themselves (code duplication, bad design, potential problems), directly interact with hardware (which needs synchronization with the kernel in more than one way) - btw: these inb/outb things are accessible to each and every process running as root (and can program every hardware you have, read out your keyboard controller, rape your cat...) - directfb: works on top of fbdev, inherits its problems and needs root+ring0 accessors, combining both the worst parts of fbdev and XFree86 (while solving the problems of its authors, so I guess that's ok)
what exactly is superior with that?
similar reasons apply to most other parts of the linux kernel: they're either _inferior_ to the WinNT design (maybe not in implementation but that's one of the things ReactOS must do different, by design) or plain incompatible. and before you start with "how about improving linux": with a strong "benevolent dictator" it might be hard to get architectural improvements into linux, look for project UDI on lkml as reference what happens to people suggesting this... also, reactos started with "real code" in 1997 or 1998 - what was the state of linux back then? finally, the last 6 months were about the most successful months in the existance of ReactOS - a good reason to move on, instead of retargetting, or not?
there are a lot of things that went pretty good with linux, but using a remotely modern design (where are personalities, when you need them?) and subscribing to API contracts (see UDI discussions or the problems nvidia has to catch up with their drivers) are definitely not on their agenda.
grow up
patrick mauritz
* Patrick Mauritz oxygene@studentenbude.ath.cx [2004-02-17 20:45:49 +0100]:
<snip>
BTW the architecture of the Linux kernel is newer than 1980, although it provides a unix-style userland vm. I dont see whats wrong with this, yet - but I'd like to hear your arguments.
people tend to joke about the change in WinNT4 where parts of the graphic driver were moved to kernelspace and point to the "superior" design of linux.
If you dont like it, why not writing something better for the linux kernel ?
similar reasons apply to most other parts of the linux kernel: they're either _inferior_ to the WinNT design (maybe not in implementation but that's one of the things ReactOS must do different, by design) or plain incompatible. and before you start with "how about improving linux": with a strong "benevolent dictator" it might be hard to get architectural improvements into linux, look for project UDI on lkml as reference what happens to people suggesting this...
Why not a new kernel branche / inofficial patches ? If the code is good, they'll someday take it into the official distro.
Many good kernel projects were developed outside of the main tree for a very long time, i.e. isdn4linux, capi4linux, alsa, ...
also, reactos started with "real code" in 1997 or 1998 - what was the state of linux back then?
Okay.
<snip>
there are a lot of things that went pretty good with linux, but using a remotely modern design (where are personalities, when you need them?) and
personalities ?
cu
Am Mittwoch, 18. Februar 2004 20:57 schrieb Enrico Weigelt:
people tend to joke about the change in WinNT4 where parts of the graphic driver were moved to kernelspace and point to the "superior" design of linux.
If you dont like it, why not writing something better for the linux kernel
kgi-wip.sf.net, #kgi on irc.freenode.org
also take a look for mentions of kgi on the linux-kernel mailing list. the situation is similar to UDI (you'll get _roasted_ from all sides)
Why not a new kernel branche / inofficial patches ? If the code is good, they'll someday take it into the official distro.
where "someday" might be when epoch equals infinity, depending on who's toes you step on. (see kgi on lkml)
Many good kernel projects were developed outside of the main tree for a very long time, i.e. isdn4linux, capi4linux, alsa, ...
in which way is that different to writing your own kernel, if you have to redesign or improve most of it, anyway - except for bootstrapping a working ReactOS system, which is done by now? this discussion takes place at least two years too late for any constructive outcome.
personalities ?
like on WinNT: Posix+, Win32, OS/2, DOS - all of them are different personalities of the OS in the way that they represent a different interface to client applications, yet building on the same foundation.
patrick mauritz
* Patrick Mauritz oxygene@studentenbude.ath.cx [2004-02-18 21:25:32 +0100]:
<snip>
kgi-wip.sf.net, #kgi on irc.freenode.org
also take a look for mentions of kgi on the linux-kernel mailing list. the situation is similar to UDI (you'll get _roasted_ from all sides)
Well, I know such things, i.e. when I was recently talking on the mplayer-dev-eng about moving out codecs to a general-purpose codec-lib. (there's now such a project, called media-api, where matroska people and some mplayer folks live peacefully ;-))
You shouldn't really care about this.
At least you've got a killfile ;-)
Why not a new kernel branche / inofficial patches ? If the code is good, they'll someday take it into the official distro.
where "someday" might be when epoch equals infinity, depending on who's toes you step on. (see kgi on lkml)
Well, for me it doesnt matter. I've no trouble with patching the kernel. On many larger projects it is quite normal (i.e. the MUA mutt has many "inofficial" patches, which are good but not yet included in the main distributions). Often it is because the maintainers feel the patches are not "good enought" for getting into main branch. Thats no problem for me - and no real reason for starting completely from scratch :)
<snip>
Many good kernel projects were developed outside of the main tree for a very long time, i.e. isdn4linux, capi4linux, alsa, ...
in which way is that different to writing your own kernel, if you have to redesign or improve most of it, anyway - except for bootstrapping a working
What's wrong with the memory management and the vm subsystem ? What's wrong with the filesystem ? What's wrong with the socket interface and the networking stuff ?
I can understand, if you dont like Xwindow - for just local applications its perhaps a little bit bloated, but if you gonna use remote displays, you dont really want RDP ...
<snip>
personalities ?
like on WinNT: Posix+, Win32, OS/2, DOS - all of them are different personalities of the OS in the way that they represent a different interface to client applications, yet building on the same foundation.
Ah, several different vm subsystems. There was something for some other unices, but I dont know if its still in the kernel.
On Linux those things are normally done in userland, but this doesn't necessarily have to be optimal ... that's what I meant with kernel support for wine.
cu
Am Mittwoch, 18. Februar 2004 21:55 schrieb Enrico Weigelt:
You shouldn't really care about this [flaming].
I care about it, if I intend to eventually get improvements in (which was the prerogative of the 'improve linux then' idea). as for kgi, I just ignore linux - other XFree86-using systems are interested in jumping ship and eventually linux will need to face the decision again - under different circumstances. that option wouldn't exist for NT-on-Linux though due to its linux-specific nature.
Well, for me it doesnt matter. I've no trouble with patching the kernel. On many larger projects it is quite normal (i.e. the MUA mutt has many "inofficial" patches, which are good but not yet included in the main distributions). Often it is because the maintainers feel the patches are not "good enought" for getting into main branch. Thats no problem for me - and no real reason for starting completely from scratch :)
they just want to extend some parts of the MUA. ReactOS otoh couldn't rely on stable behaviour (or APIs) within linux to build a feature-by-feature, API-by-API copy of WinNT - quite a difference. and not being able to follow the kernel in its track is a bad thing, too - see the 2.6.3/2.4.25 release with patches for exploits as example - do you really want to isolate all these all the time as you're unable to just merge with it? that's a lot of work :)
What's wrong with the memory management and the vm subsystem ?
hmm.. rewritten way to often to rely on it? (even within "stable" kernel series)
What's wrong with the filesystem ?
different semantics from NT filesystems. where are streams, OIDs, ...?
What's wrong with the socket interface and the networking stuff ?
no problem, which is why it might be copied over.
I can understand, if you dont like Xwindow - for just local applications its perhaps a little bit bloated, but if you gonna use remote displays, you dont really want RDP ...
X isn't bloated, au contraire, it lacks quite a bunch of features. it's client/server design is pretty solid (and damn fast) though.
what I have a problem with is the architecture of their (and kernel's) drivers
Ah, several different vm subsystems. There was something for some other unices, but I dont know if its still in the kernel.
icbs, and no, it should be gone. also, show me that it's semantically similar to the way NT does it
the current ROS design is pretty much modelled after NT - which makes further compatibility easier. that wouldn't have been possible with a linux based system (except if it would look the same by now, which means that only bootstrapping were affected)
patrick mauritz
Hi there!
<quote> people tend to joke about the change in WinNT4 where parts of the graphic driver were moved to kernelspace and point to the "superior" design of linux.
let's see: - fbdev: reduced functionality, unstable graphic drivers with a real management problem - DRM/DRI+agpgart: kernelguard with userspace module, 3D only - XFree86: drivers in userspace that get access to ring0 instructions (inb/outb), enumerate the pci bus by themselves (code duplication, bad design, potential problems), directly interact with hardware (which needs synchronization with the kernel in more than one way) - btw: these inb/outb things are accessible to each and every process running as root (and can program every hardware you have, read out your keyboard controller, rape your cat...) - directfb: works on top of fbdev, inherits its problems and needs root+ring0 accessors, combining both the worst parts of fbdev and XFree86 (while solving the problems of its authors, so I guess that's ok) what exactly is superior with that? </quote>
Quite truthfull comments. No doubts. Just don't make them to Linux, make those comments about *nix in general. *nix wasn't made for graphics. X was an add-on. People are trying to put a client/server architecture working fast. That needs hacking. But... Isn't Windows hacked in the same way? It surely does not have these problems! It has some others.
I would say both systems are *equivalent* in this matter...
<quote> similar reasons apply to most other parts of the linux kernel: they're either _inferior_ to the WinNT design (maybe not in implementation but that's one of the things ReactOS must do different, by design) or plain incompatible. and before you start with "how about improving linux": with a strong "benevolent dictator" it might be hard to get architectural improvements into linux, look for project UDI on lkml as reference what happens to people suggesting this... also, reactos started with "real code" in 1997 or 1998 - what was the state of linux back then? finally, the last 6 months were about the most successful months in the existance of ReactOS - a good reason to move on, instead of retargetting, or not? there are a lot of things that went pretty good with linux, but using a remotely modern design (where are personalities, when you need them?) and subscribing to API contracts (see UDI discussions or the problems nvidia has to catch up with their drivers) are definitely not on their agenda.
grow up patrick mauritz </quote>
Inferior in design? LOL! I will *not* comment that part...
Continuing...
The binary driver thing "problem" is one and one only. The whole system is open. Why should it be closed for drivers? Those drivers would use code written with the hard work of others... It's not fair. Why shouldn't they give the driver's code?
You seem to hate Linux with all your nerves. You grow up. No system is perfect! Some are better on some respects... Some are better on others. We should all learn with what others do.
Some people here are immensely *arrogant*! That's NOT good for the project. Regardless of the quality of their work.
Sorry if I offended someone.
Just my 2 cents,
Ricardo
Am Mittwoch, 18. Februar 2004 21:14 schrieb Ricardo Ramalho:
Quite truthfull comments. No doubts. Just don't make them to Linux, make those comments about *nix in general. *nix wasn't made for graphics. X was
unix in general has proper solutions to this problem: X with proper hardware abstraction in kernel. that just won't work right on x86 without strong support by hardware vendors .
an add-on. People are trying to put a client/server architecture working fast. That needs hacking. But... Isn't Windows hacked in the same way? It
the client/server part of X11 is actually solved pretty nice and clean. it's the driver side (which is entirely unrelated to the client/server part) which is a mess. driver side, as in "kernel related". this discussion started out with "why not use linux as base of reactos" (moved to some past form later-on), so of course, I'll only argue about kernel issues.
surely does not have these problems! It has some others.
I would say both systems are *equivalent* in this matter...
do they have a different set of problems or are they equivalent? I'm confused now.
Inferior in design? LOL! I will *not* comment that part...
lack of arguments?
The binary driver thing "problem" is one and one only. The whole system is open. Why should it be closed for drivers? Those drivers would use code written with the hard work of others... It's not fair. Why shouldn't they give the driver's code?
because they have contractual obligations that prevent them from doing it?
see, nvidia looks for me like a company that bought most of its "intellectual property" and thus _can't_ release specs or drivers under a half-way free license, even if they wanted (and there are claims that some of their technicians really, really want to do that) - just as an example.
still, their driver hugely boosts linux on the market, including the contributions of other people - why make it harder for them than necessary?
I'm _not_ talking about copying code verbatim, just about some reliable long term API/ABI contracts for drivers.
You seem to hate Linux with all your nerves. You grow up. No system is
look at the headers of my mails: mailer on kde/linux, mail server on netbsd, smarthost on linux - just to get the facts straight, I have _no_ win32 installation here because I find the user accessible side of win32 inconvenient (unlike the linux GUIs), while I can ignore the kernel weaknesses of linux as I don't need to do kernel hacking every day.
perfect! Some are better on some respects... Some are better on others. We should all learn with what others do.
linux is good on methodology (which leads to a solid implementation), so ReactOS roughly models it. fine. WinNT is good when employing a pretty solid, half-way modern design, so ReactOS models it, closely. also, fine.
so ReactOS learned, and I'm happy (even if I'm not a developer for ROS, due to other priorities). In the end, ROS is able to get a good development method, a solid implementation based on a working, reliable design - isn't that the goal?
Some people here are immensely *arrogant*! That's NOT good for the project. Regardless of the quality of their work.
I gather that in your opinion Linux Fanboyism is not arrogant, yes? _that_ is NOT good for the deployment of the project as it make linux people look like zealots instead of reasonable people (which most of them are, but you now - guilty by association etc)
patrick mauritz
(if any of you consider this subtread offtopic, tell me off-list and I'll shut up)
* Patrick Mauritz oxygene@studentenbude.ath.cx [2004-02-18 21:51:59 +0100]:
<snip>
I'm _not_ talking about copying code verbatim, just about some reliable long term API/ABI contracts for drivers.
Why not ? This could be done quite easily on top of the current architecture. A small opensource stub could be used to load/link the drivers and dispatch some api calls which are probably not binary compatible. The ABI-loader could be build so that it links those functions which match to the current kernel directly and put small stubs between those which dont. (i.e. a module i386-smp could directly match into a kernel built for i386-smp, but i686-nosmp perhaps wouldnt match and so has to be wrapped)
<snip>
WinNT is good when employing a pretty solid, half-way modern design, so ReactOS models it, closely. also, fine.
What exactly on winnt do you consider "modern design" ?
cu
* Ricardo Ramalho rjsr@netcabo.pt [2004-02-18 20:14:31 -0000]:
<snip>
The binary driver thing "problem" is one and one only. The whole system is open. Why should it be closed for drivers? Those drivers would use code written with the hard work of others... It's not fair. Why shouldn't they give the driver's code?
100% ACK.
But I can understand companies, which are forced to publish only binary drivers because of domestic contracts with third parties (i.e. nvidia is in this bad situation). I dont like the idea of propretiary kernel drivers or root-only applications - for example they're big security problems.
btw: nvidia has found a moderate way of the trouble: they've written a small opensource stub driver, which loads the real binary driver and dispatches the calls to its own binary interface.
You could also write generic driver interfaces / ABIs for many device types if you like / feel you require them. Of course this forbids many compiler optimizations and so slows down a little bit in comparison with "native" opensource drivers - but winnt has the same problem.
<snip>
You seem to hate Linux with all your nerves. You grow up. No system is perfect! Some are better on some respects... Some are better on others. We should all learn with what others do.
Some people here are immensely *arrogant*! That's NOT good for the project. Regardless of the quality of their work.
ACK. We've got the same problems in the mplayer project ... seems to be a quite normal illness of coders ;-)
cu
Am Mittwoch, 18. Februar 2004 22:05 schrieb Enrico Weigelt:
btw: nvidia has found a moderate way of the trouble: they've written a small opensource stub driver, which loads the real binary driver and dispatches the calls to its own binary interface.
which needs to be adapted for more or less each single kernel revision. how many kernel revisions appeared over the lifetime of Win2K? does the windows version of exactly the same driver (the linux binary stub models parts of the windows registry, so it's _really_ the same one) change for each of these revisions, too?
You could also write generic driver interfaces / ABIs for many device types if you like / feel you require them. Of course this forbids many compiler optimizations and so slows down a little bit in comparison with "native" opensource drivers - but winnt has the same problem.
driver code (esp for hardware) usually is not the bottleneck - much time is spent in loops, waiting for the hardware, anyway.
ACK. We've got the same problems in the mplayer project ... seems to be a quite normal illness of coders ;-)
no, maybe these people are just tired explaining things over and over again and fighting the same battles uphill all the time.. it's easy to stand on top and laughing about those coming up to you while kicking yet another stone in their direction - even when they might be right (but you're only pretending to be interested in listening)
_that_ is why I'm getting pretty aggressive when I encounter behaviour that is similar to that of (linux) fanboys (no idea about hyperion's motives to react the way he does)
patrick mauritz
Hi there again,
I said what I said about arrogance because of I read on this ml. Some people are arrogant in the way they answer some questions. Some of the questions may be somehow boring or even stupid at times, *but* in those cases it's best to ignore them and not answer...
And I repeat what I said on my other mail. I'm really sorry if I offended anyone.
As for being a "Linux Fanboy"... Wich I'm not! ;) I am a "OS fanboy". I like to learn. I like to experiment. Each OS has negative and positive points. There's no holy grail of OS's.
BTW: ROS is looking cool. It's a bit on the slow side, but it's cool! :)
Stay cool people,
--------------- Ricardo Ramalho In Reply to:
-----Original Message----- From: ros-general-bounces@reactos.com [mailto:ros-general-bounces@reactos.com] On Behalf Of Patrick Mauritz Sent: quarta-feira, 18 de Fevereiro de 2004 21:47 To: weigelt@metux.de; ros-general@reactos.com Subject: Re: [ros-general] why folks
Am Mittwoch, 18. Februar 2004 22:05 schrieb Enrico Weigelt:
btw: nvidia has found a moderate way of the trouble: they've written a small opensource stub driver, which loads the real binary driver and dispatches the calls to its own binary interface.
which needs to be adapted for more or less each single kernel revision. how many kernel revisions appeared over the lifetime of Win2K? does the windows version of exactly the same driver (the linux binary stub models parts of the windows registry, so it's _really_ the same one) change for each of these revisions, too?
You could also write generic driver interfaces / ABIs for many device types if you like / feel you require them. Of course this forbids many compiler optimizations and so slows down a little bit in comparison with "native" opensource drivers - but winnt has the same problem.
driver code (esp for hardware) usually is not the bottleneck - much time is spent in loops, waiting for the hardware, anyway.
ACK. We've got the same problems in the mplayer project ... seems to be a quite normal illness of coders ;-)
no, maybe these people are just tired explaining things over and over again and fighting the same battles uphill all the time.. it's easy to stand on top and laughing about those coming up to you while kicking yet another stone in their direction - even when they might be right (but you're only pretending to be interested in listening)
_that_ is why I'm getting pretty aggressive when I encounter behaviour that is similar to that of (linux) fanboys (no idea about hyperion's motives to react the way he does)
patrick mauritz _______________________________________________ ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
At 22.46 18/02/2004, you wrote:
(no idea about hyperion's motives to react the way he does)
Normally here I'd spew some witticisms, collect the applause, bow and go home. I'll try, instead, to (gasp!) rationalize. Let's say I ask you "are you eterosexual?", and after you reply I ask you, with the straightest face, "why?", and won't take "because" as a reply (because, hey, you've invested your whole life on your sexual orientation, and you're telling me you put no planning or risk assessment in the choice?). How would *you* react?
On Wed, 2004-02-18 at 20:11, KJK::Hyperion wrote:
At 22.46 18/02/2004, you wrote:
(no idea about hyperion's motives to react the way he does)
<snip>
face, "why?", and won't take "because" as a reply (because, hey, you've invested your whole life on your sexual orientation, and you're telling me you put no planning or risk assessment in the choice?). How would *you* react?
Stuff like this is the reason i haven't procmailed this thread into the bit bucket. :-)
KJK::Hyperion wrote:
At 22.46 18/02/2004, you wrote:
(no idea about hyperion's motives to react the way he does)
Normally here I'd spew some witticisms, collect the applause, bow and go home. I'll try, instead, to (gasp!) rationalize. Let's say I ask you "are you eterosexual?", and after you reply I ask you, with the straightest face, "why?", and won't take "because" as a reply (because, hey, you've invested your whole life on your sexual orientation, and you're telling me you put no planning or risk assessment in the choice?). How would *you* react?
LOL! Oh my!
Everyone leave Hyperion alone, James
Am Donnerstag, 19. Februar 2004 03:11 schrieb KJK::Hyperion:
At 22.46 18/02/2004, you wrote:
(no idea about hyperion's motives to react the way he does)
that wasn't a question, just a small factoid that the explanation I wrote before might or might not apply to you, as I just don't know what your motives are.
patrick mauritz
At 09.02 19/02/2004, you wrote:
(no idea about hyperion's motives to react the way he does)
that wasn't a question, just a small factoid that the explanation I wrote before might or might not apply to you, as I just don't know what your motives are.
my reply stands nevertheless :-)
At 16.30 15/02/2004, you wrote:
why are you developing a completely new kernel instead of using an existing one like linux or hurd and running reactos just as a subsystem, perhaps with some kernel improvements.
because we feel like it. Each of us for different reasons
For example: linux brings very good memory management and filesystem.
(both of which happen to be completely incompatible with those of Windows. You picked bad examples. The whole of Linux is a bad example of how Windows can be implemented)
So what are the advantages of another own kernel against a subsystem in another host operating system ?
it makes us 63.2% cooler
* KJK::Hyperion noog@libero.it [2004-02-16 22:46:21 +0100]:
<snip>
At 16.30 15/02/2004, you wrote:
why are you developing a completely new kernel instead of using an existing one like linux or hurd and running reactos just as a subsystem, perhaps with some kernel improvements.
because we feel like it. Each of us for different reasons
I'd like to hear what reasons that are.
For example: linux brings very good memory management and filesystem.
(both of which happen to be completely incompatible with those of Windows.
Where are the (conceptional) differences ?
example 1: filesystem windows also brings an API for filesystem access. it uses \ instead of / as path delimiter, but most of the functions are quite the same.
example 2: memory mangement on both systems each process has its own memory range (thats just the concept of the protected mode) and the application may request more memory from the kernel, and those memory areas are layign on some address.
win16 had the distinction between "local" and "global" memory - IMHO local memory will be freed when a task dies, global one doesnt. does winnt also have this ?
<snip>
You picked bad examples. The whole of Linux is a bad example of how Windows can be implemented)
Why bad example ? And why implement _Windows_ and not a good system which allows running old windows applications ?
<snip>
So what are the advantages of another own kernel against a subsystem in another host operating system ?
it makes us 63.2% cooler
ah, no rational reason, just for fun.
cu
At 23.17 16/02/2004, you wrote:
because we feel like it. Each of us for different reasons
I'd like to hear what reasons that are.
for me it's finally and actually learning Windows. Just giving up and using another system? _how convenient_. And it's not like just for wanting to develop an open source operating system you *must* contribute to Linux - what makes people think that? I hate Linux, why should I care?
Where are the (conceptional) differences ?
you really *don't want* to get in a discussion with *me* about differences between Windows and Linux. I'm pretty much doomed to be always right about the topic, having spent countless hours of my life studying it. Let's put it this way: they are roughly *equivalent*, but in no way *interchangeable*
And why implement _Windows_ and not a good system which allows running old windows applications ?
ReactOS *is* meant as "a good system which allows running old windows applications"
So what are the advantages of another own kernel against a subsystem in another host operating system ?
it makes us 63.2% cooler
ah, no rational reason, just for fun.
no, I'm just saying it to confuse you
On Mon, 2004-02-16 at 17:33, KJK::Hyperion wrote:
So what are the advantages of another own kernel against a subsystem in another host operating system ?
it makes us 63.2% cooler
ah, no rational reason, just for fun.
no, I'm just saying it to confuse you
Hyperion for president.
At 23.17 16/02/2004, you wrote:
because we feel like it. Each of us for different reasons
I'd like to hear what reasons that are.
well, my main reason is that i use linux for servers in schools, but there is a vast amount of specialist educational software that needs to run on desktop windows, on fairly low spec machines. what i want is something i can plug in as a direct, free replacement for windows that looks the same, works the same, and does not need high spec (expensive) machines to cope with a bloaty os + subsystem.
don't get me wrong, i love linux/samba, it saves the schools i work for a fortune in server licences, but it is geting bigger and more demanding in terms of hardware.
les
* ros@xzite.fsnet.co.uk ros@xzite.fsnet.co.uk [2004-02-17 02:24:07 -0000]:
<snip>
well, my main reason is that i use linux for servers in schools, but there is a vast amount of specialist educational software that needs to run on desktop windows, on fairly low spec machines.
Okay, you need a slim operating system which can run windows applications. (but a new kernel ?)
what i want is something i can plug in as a direct, free replacement for windows that looks the same, works the same, and does not need high spec (expensive) machines to cope with a bloaty os + subsystem.
Why has underlying OS and a subsystem to be expensive ?
cu
* KJK::Hyperion noog@libero.it [2004-02-17 00:33:47 +0100]:
Hi folks,
for me it's finally and actually learning Windows. Just giving up and using another system? _how convenient_. And it's not like just for wanting to develop an open source operating system you *must* contribute to Linux - what makes people think that?
Well, I just thought about GNU/Linux since its one of the most used opensource operating systems.
I personally migrated to GNU/Linux some years ago, because its architecture is much better for my tasks than windows - for me windows is too desktop-centric But I also like to run many windows applications on my system, as long as they're not available for GNU/Linux.
I hate Linux, why should I care?
Why exactly do you hate it ?
<snip>
Where are the (conceptional) differences ?
you really *don't want* to get in a discussion with *me* about differences between Windows and Linux. I'm pretty much doomed to be always right about the topic, having spent countless hours of my life studying it. Let's put it this way: they are roughly *equivalent*, but in no way *interchangeable*
For me the differences are important since I'd like to use windows applications on other platforms like GNU/Linux or BSD.
And why implement _Windows_ and not a good system which allows running old windows applications ?
ReactOS *is* meant as "a good system which allows running old windows applications"
Perhaps it was a misunderstanding. I meant a "good operating system" which can be used for many tasks, not just running windows applications. So this would end up in a windows subsystem.
Well, let me ask the question in a diffrent way:
What are the existing kernels/operating systems are missing that you require a completely new kernel. Writing a good operating system from scratch is a very huge job - i.e. linux has taken many years to come to the point where it is.
<snip>
So what are the advantages of another own kernel against a subsystem in another host operating system ?
it makes us 63.2% cooler
ah, no rational reason, just for fun.
no, I'm just saying it to confuse you
*lol*
cu
Enrico Weigelt wrote:
And why implement _Windows_ and not a good system which allows running old windows applications ?
ReactOS *is* meant as "a good system which allows running old windows applications"
Perhaps it was a misunderstanding. I meant a "good operating system" which can be used for many tasks, not just running windows applications. So this would end up in a windows subsystem.
Well, let me ask the question in a diffrent way:
What are the existing kernels/operating systems are missing that you require a completely new kernel. Writing a good operating system from scratch is a very huge job - i.e. linux has taken many years to come to the point where it is.
You can also see this in a different way: We are working together with the Wine project. This project is already quite old and it's still in it's alpha phase, so developments aren't really going hard... This project has a good potential of becoming a very fast developing project since there are a lot of windows developers outthere. Now the situation is that the ReactOS project hugely consumes of the knowledge of the Wine project, but in a year or so the situation could have changed in the other way around! Then it is time to finally build a _good_ windows subsystem for linux! From my point of view the ReactOS project is no more then a step between the situation now and having a good Windows subsystem in Linux. Hope that that cleared something.
Emil
* ROS@Q-collective.org ROS@q-collective.org [2004-02-17 16:54:30 +0100]:
Hi,
From my point of view the ReactOS project is no more then a step between the situation now and having a good Windows subsystem in Linux. Hope that that cleared something.
so we could state, that reactos is a native kernel for a windows-style environment, while wine is a emulation layer on top of another OS. Much of the code could be used in both projects, so perhaps someday we could have three projects: + native kernel (reactos) + subsystem/emulation (wine) + userland applications
cu
Have you read Windows 2000 inside by David Solomon and Russinovic. I can recommend it to you. NT and linux are different.
Enrico Weigelt schrieb:
- ROS@Q-collective.org ROS@q-collective.org [2004-02-17 16:54:30 +0100]:
Hi,
From my point of view the ReactOS project is no more then a step between the situation now and having a good Windows subsystem in Linux. Hope that that cleared something.
so we could state, that reactos is a native kernel for a windows-style environment, while wine is a emulation layer on top of another OS. Much of the code could be used in both projects, so perhaps someday we could have three projects: + native kernel (reactos) + subsystem/emulation (wine) + userland applications
In reality the ros-kernel is a kernel for no apps and it is also a unofficial project ( kernel to build sub system ontop) We have the win32 sub system as the win-app server
cu
Much of the code could be used in both projects, so perhaps someday we could have three projects: + native kernel (reactos) + subsystem/emulation (wine) + userland applications
Yes, IMO this would be the ideal solution!
The current situation where we port/borrow/fork code from wine is really bad. Much work is done twice. The ideal solution would be to work with the Wine project (where possible) instead of forking it into ros. Keeping shell32 in synch seem to work well thou, but most shared components are not synched.
My dream is to move/merge most of ros umode stuff into Wine. This includes everything inside the ros\lib source tree. Differences between ros and wine would be put into libraries, create a ntoskrnl.dll and win32k.dll wrapper for wine etc.
-Gunnar
--- Gunnar_Andr�_Dalsnes hardon@online.no wrote:
My dream is to move/merge most of ros umode stuff into Wine. This includes everything inside the ros\lib source tree. Differences between ros and wine would be put into libraries, create a ntoskrnl.dll and win32k.dll wrapper for wine etc.
I want to do this sometime soon but Alexandre just things it will be to much work. I think keeping things in sync is more work than writting wrappers for Win32k/Ntoskrnl and using winehq release built for Mingw directly.
I am planning on getting Mingw binarys setup soon from Winehq for each new WINE release. Maybe we can look at working more with them and not forking the code around 0.3 or something. For the time being it is better to fork and get ReactOS up to the current state WINE is.
Thanks Steven
__________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html
* Gunnar André Dalsnes hardon@online.no [2004-02-17 20:32:25 +0100]:
<snip>
The current situation where we port/borrow/fork code from wine is really bad. Much work is done twice. The ideal solution would be to work with the Wine project (where possible) instead of forking it into ros. Keeping shell32 in synch seem to work well thou, but most shared components are not synched.
Where are the problems ? Did you ever talk to them or do you fear being hit in the back ? ;-)
I'll subscribe to the wine list(s) and have a look at the code. Perhaps you could tell me, which parts are used by both projects.
<snip>
My dream is to move/merge most of ros umode stuff into Wine. This includes everything inside the ros\lib source tree. Differences between ros and wine would be put into libraries, create a ntoskrnl.dll and win32k.dll wrapper for wine etc.
Yes, this sounds ideal. There should be a core module (either ros kernel or wine in userland), which provides generic kernel interfaces, loads binaries, memory mangement, ... i.e. the ros-kernel could be configured to support .so-libraries or not (for windows-only environments they're not needed, but perhaps its useful someday), also the wine core could support several binary formats.
On top of this core the should sit several services, like device handling window manager, widget libraries, ... Each interface (from within the win-env seen as one dll) could be provided by several module - at least one pure-win32 implementation (i.e. widgets) and others which work as adapters to other stuff, especially in the wine-environment (i.e uses gtk for widget rendering).
An interesting setup where both projects share much stuff would be a console-wine: it could use a simple framebuffer or libsvga output device and widget rendering/window manager from the shared codebase. (whether the code comes from windows-dlls or .so's doesnt really matter at this point).
This would be "windows on console" - something very interesting for me.
cu
Want your reasons? go ask linus why he wrote linux.
Enrico Weigelt wrote:
- KJK::Hyperion noog@libero.it [2004-02-16 22:46:21 +0100]:
<snip>
At 16.30 15/02/2004, you wrote:
why are you developing a completely new kernel instead of using an existing one like linux or hurd and running reactos just as a subsystem, perhaps with some kernel improvements.
because we feel like it. Each of us for different reasons
I'd like to hear what reasons that are.
For example: linux brings very good memory management and filesystem.
(both of which happen to be completely incompatible with those of Windows.
Where are the (conceptional) differences ?
example 1: filesystem windows also brings an API for filesystem access. it uses \ instead of / as path delimiter, but most of the functions are quite the same.
example 2: memory mangement on both systems each process has its own memory range (thats just the concept of the protected mode) and the application may request more memory from the kernel, and those memory areas are layign on some address.
win16 had the distinction between "local" and "global" memory - IMHO local memory will be freed when a task dies, global one doesnt. does winnt also have this ?
<snip>
You picked bad examples. The whole of Linux is a bad example of how Windows can be implemented)
Why bad example ? And why implement _Windows_ and not a good system which allows running old windows applications ?
<snip>
So what are the advantages of another own kernel against a subsystem in another host operating system ?
it makes us 63.2% cooler
ah, no rational reason, just for fun.
cu
-
Casper Hornstrup -
Enrico Weigelt -
Ge van Geldorp -
Gunnar André Dalsnes -
James Tabor -
KJK::Hyperion -
Patrick Mauritz -
Ricardo Ramalho -
Richard Campbell -
Robert Köpferl -
ROS＠Q-collective.org -
ros＠xzite.fsnet.co.uk -
Steven Edwards -
Vizzini