From owner-freebsd-hackers Thu Jan 29 16:04:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA22760 for hackers-outgoing; Thu, 29 Jan 1998 16:04:40 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from webserver.smginc.com (webserver.smginc.com [204.170.176.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA22320 for ; Thu, 29 Jan 1998 16:03:13 -0800 (PST) (envelope-from AdamT@smginc.com) Received: from smginc.com ([204.170.177.4]) by webserver.smginc.com (post.office MTA v2.0 0813 ID# 0-13723) with SMTP id AAA275; Thu, 29 Jan 1998 19:01:41 -0500 Received: by smginc.com with Microsoft Mail id <34D141BF@smginc.com>; Thu, 29 Jan 98 18:58:07 PST From: Adam Turoff To: hackers Cc: "'capriotti@geocities.com'" Subject: RE: /usr/src/release/sysinstall needs US. :-)) Date: Wed, 28 Jan 98 19:00:00 PST Message-ID: <34D141BF@smginc.com> X-Mailer: Microsoft Mail V3.0 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe hackers" > >TCl vs. Java, any others for the melting pot? > > > >As far as extending any 'Java' client, all you need (and I think someones > >allready mentioned this) is a system similar to SNMP MIB's, i.e. > directions to > >the client where to put check boxes, text fields, what they should contain > >(labels), how to verify them (field masks etc.) - I'll freely admit it's a > >thin line between Java, TCL, cgi & someones bound to mention Active-X > > Again, if this thin line will cause any probl;em, let's just think about > "globalization". > > Building an universal-like client (i.e. Java) Will allow Free to have a > plus in its favor, just like Novell did with NT. Novell has released > administrative tools for NetWare to run under Windows NT, in a way of > saying "OK, dolks, if you can't choose the workstation that you will run on > your company, at least be able to manage our operating system from them. > Keep the piece of junk on your desk, but at least be able to manage our > operating system". Hey, I resemble that remark! :-) The universal client is a rather nice idea. Multiple clients are a nice idea, too. Not everyone has the same needs. If I only want to add users remotely, why add on all of the complexity of managing cron or rc.conf remotely? Multiple server-side modules is also worth considering. I may want to enable multiple "admins" to play with a samba config on my site, but you may not since your box isn't behind a firewall and enabling a security hole to be exploited through another one usually isn't a good idea. Of course, why enable samba configuration if you don't have samba installed in the first place? Feel free to s/samba/(Apache|NFS|bind|cron)/g -- Adam. PS: is anyone else seeing a need to have different permissions on different remote config operations?