Publicity

[Stavros Filargiropoulos]

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?

[Robert Köpferl]

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(a)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

[Richard Campbell]

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(a)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(a)reactos.com
> http://reactos.com/mailman/listinfo/ros-general
>
>   
>

[Rex Jolliff]

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(a)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(a)reactos.com
> > http://reactos.com/mailman/listinfo/ros-general
> >
> >  
> _______________________________________________
> ros-general mailing list
> ros-general(a)reactos.com
> http://reactos.com/mailman/listinfo/ros-general 
Rex Jolliff
rex(a)osexperts.com
ReactOS (www.reactos.com) -- Check it out

[Aliberti Emanuele]

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