Hey, I just show your project in slashdot, and I would like to say that you are doing a great job, and that I will try to get involved myself.
It's a pity that projects like yours don't have too much publicity. I am sure that would help a lot to find developers and other people to help.
Anyway nice job! :)
PS: do you know where can I find API documentation or some documentation about the, so far done job?
http://www.reactos.org/ shows you the way. Official (or MSish) doc can be found on msdn.microsoft.com
Stavros Filargiropoulos schrieb:
Hey, I just show your project in slashdot, and I would like to say that you are doing a great job, and that I will try to get involved myself.
It's a pity that projects like yours don't have too much publicity. I am sure that would help a lot to find developers and other people to help.
Anyway nice job! :)
PS: do you know where can I find API documentation or some documentation about the, so far done job? _______________________________________________ ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
i know it may be a little early in the development of ReactOS to open this particular can of worms, but i would like to sound out opinion on the way that NT/W2K/XP implements domain logons. i maintain several small school networks of mainly win9x machines with rh9 samba servers. so far so good. add xp to the equation and it all goes tits up. the standard ms implementation depends on copying all user data to the client machine on logon, and copying it all back on logoff. everone knows that this is hugely wasteful of network resources, leads to enormous amounts of user data being scattered across the network on client machine hard drives, and allows "false logons" where the impression is given that a user has logged on, (cached logons) when they haven't, because the server was bogged down with data transfers to other users who had logged on. the ms driven solution is the ridiculous Gb network cards, or hardware solutions to implementation problems. this default behaviour is almost impossible to prevent, (trust me, i have tried) could we implement a far simpler system where user data is stored on the server, (be it linux or ms) and accessed when required rather than copied back and forth on mass. this would lead to fast logons, reliable data transfers and less stressed sysadmins. does anyone else have any opinions on this?
les
We are writing a Microsoft Windows compatible operating system...this means we must do things the way windows does them...however you are more than welcome to change the way a particular thing works, and either submit it to the list for review or make it one of your own side projects/addons. Sorry if this sounds rather zealotish, but that's the way it has to be.
Besides, we aren't even remotely close to that level of networking yet and probably won't be for months, if not years, to come.
Richard
ros@xzite.fsnet.co.uk wrote:
i know it may be a little early in the development of ReactOS to open this particular can of worms, but i would like to sound out opinion on the way that NT/W2K/XP implements domain logons. i maintain several small school networks of mainly win9x machines with rh9 samba servers. so far so good. add xp to the equation and it all goes tits up. the standard ms implementation depends on copying all user data to the client machine on logon, and copying it all back on logoff. everone knows that this is hugely wasteful of network resources, leads to enormous amounts of user data being scattered across the network on client machine hard drives, and allows "false logons" where the impression is given that a user has logged on, (cached logons) when they haven't, because the server was bogged down with data transfers to other users who had logged on. the ms driven solution is the ridiculous Gb network cards, or hardware solutions to implementation problems. this default behaviour is almost impossible to prevent, (trust me, i have tried) could we implement a far simpler system where user data is stored on the server, (be it linux or ms) and accessed when required rather than copied back and forth on mass. this would lead to fast logons, reliable data transfers and less stressed sysadmins. does anyone else have any opinions on this?
les
ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
At 09:52 PM 5/31/2004 -0400, you wrote:
We are writing a Microsoft Windows compatible operating system...this means we must do things the way windows does them...
The second statement does not follow from the first. Otherwise why even bother building another OS. If we come up with a better way to maintain network client state that is compatible with existing applications then more power to us. To take the attitude you have taken above is not helpful.
however you are more than welcome to change the way a particular thing works, and either submit it to the list for review or make it one of your own side projects/addons. Sorry if this sounds rather zealotish, but that's the way it has to be.
In my opinion, it is too unyielding a stance, and I'm not convinced it is the way it has to be.
Besides, we aren't even remotely close to that level of networking yet and probably won't be for months, if not years, to come.
I think once someone takes up an interest it is more like weeks to months away. It's still interesting to discuss don't you think?
Richard
ros@xzite.fsnet.co.uk wrote:
sysadmins. does anyone else have any opinions on this?
I think keeping client information on the server is a better idea also. Perhaps the appropriate directories (like the user settings directory) can be mounted at a given directory a la unix. The mount functionality might be doable with a filter driver. Or perhaps some appropriate registry settings could be changed to support client data remotely.
les
ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
Rex Jolliff rex@osexperts.com ReactOS (www.reactos.com) -- Check it out
Rex Jolliff wrote:
I think keeping client information on the server is a better idea also. Perhaps the appropriate directories (like the user settings directory) can be mounted at a given directory a la unix. The mount functionality might be doable with a filter driver. Or perhaps some appropriate registry settings could be changed to support client data remotely.
Hi Rex,
nice to hear from you from time to time.
Keeping any kind of user information in a database (database approach) is the better thing to do, IMHO, in the long term. The database approach brings almost for free the replica concept. Why do we need replicas? Do not forget mobile devices are what is ahead (what we use today, even in Japan and Europe is just an experiment, real spread computing will be here about 2010/2020...), but even if bandwidth is not a problem (or it won't be), time will continue to be a big one, I'd say it is THE problem. How long does your Win/Lin box take to bootstrap? With replicas, user information is always available locally and can be accesses in no time. It may be in you laptop, in your pda, in your mobile phone, in the cruise control of your car or in the control panel of your washing machine... With IPv6 this need of possible spread availability of user information will even increase, because network sessions can be freezed, restored and moved among devices on the fly.
Emanuele