On Fri, Sep 10, 1999 at 11:15:12AM -0700, Parag Patel wrote:
Growing up programming on a KL-10, I still think the correct place for
line-editing is in the driver. Hell - it's already doing basic
erase/kill line editing as it is. Then you don't have to hack every
command-line app to get
On Fri, Sep 10, 1999 at 11:15:12AM -0700, Parag Patel wrote:
Growing up programming on a KL-10, I still think the correct place for
line-editing is in the driver. Hell - it's already doing basic
erase/kill line editing as it is. Then you don't have to hack every
command-line app to get
On Fri, Sep 10, 1999 at 11:15:12AM -0700, Parag Patel wrote:
Growing up programming on a KL-10, I still think the correct place for
line-editing is in the driver. Hell - it's already doing basic
erase/kill line editing as it is. Then you don't have to hack every
command-line app to
On 10-Sep-99 Boris Popov wrote:
mount_nwfs - similar to mount_nfs
ncplogin- creates permanent connection to a NetWare server
without an actual mount,
ncplogout - destroy permanent connection,
ncplist
On Fri, Sep 10, 1999 at 06:29:57PM +0930, Daniel O'Connor wrote:
On 10-Sep-99 Boris Popov wrote:
mount_nwfs - similar to mount_nfs
ncplogin- creates permanent connection to a NetWare server
without an actual mount,
On Fri, 10 Sep 1999, Daniel O'Connor wrote:
Is there any reason to not have it as a port?
The only possible candidate for contrib'ifying I could see would be mount_nwfs
because building it without the kernel source could be a problem, but the rest
of it could be a port I think :)
On Fri, 10 Sep 1999, Ruslan Ermilov wrote:
Is there any reason to not have it as a port?
IMHO, only the basic IPX/SPX functionality should be included into the
source tree. Anything else could be available as ports/net/nw-utils.
An IPX/SPX stack is already in the tree and past
On Fri, 10 Sep 1999, Ruslan Ermilov wrote:
An IPX/SPX stack is already in the tree and past year made it more
or less functional.
Read: I fully agree with Daniel.
Daniel also left mount_nwfs :)
Forgive me my ignorance, but I'd like a quick response: what about multiple
On Fri, Sep 10, 1999 at 05:24:00PM +0700, Boris Popov wrote:
On Fri, 10 Sep 1999, Ruslan Ermilov wrote:
An IPX/SPX stack is already in the tree and past year made it more
or less functional.
Read: I fully agree with Daniel.
Daniel also left mount_nwfs :)
All
Boris Popov wrote:
On Fri, 10 Sep 1999, Daniel O'Connor wrote:
Is there any reason to not have it as a port?
The only possible candidate for contrib'ifying I could see would be mount_n
wfs
because building it without the kernel source could be a problem, but the r
est
of it
On Fri, 10 Sep 1999, Peter Wemm wrote:
Yes, that's acceptable. But mount_nwfs require libncp.so and this
means that ncp library sources will be also required. So KLD, mount_nwfs
and libncp should go into source tree and other utilities can be a port.
Other thoughts ?
I'm
Boris Popov wrote:
Currently I'm trying to determine a reasonable set of NetWare
utilities which should be included in the source tree.
Is it possible to have utilities to query and modify NDS?
ncpurge - purge specified salvagable files,
From a user perspective, is
On Fri, 10 Sep 1999, Daniel O'Connor wrote:
On 10-Sep-99 Boris Popov wrote:
mount_nwfs - similar to mount_nfs
ncplogin- creates permanent connection to a NetWare server
without an actual mount,
ncplogout
"Matthew N. Dodd" wrote:
On Fri, 10 Sep 1999, Daniel O'Connor wrote:
On 10-Sep-99 Boris Popov wrote:
mount_nwfs - similar to mount_nfs
ncplogin- creates permanent connection to a NetWare server
without an actual mount,
On Fri, 10 Sep 1999, Marcel Moolenaar wrote:
Currently I'm trying to determine a reasonable set of NetWare
utilities which should be included in the source tree.
Is it possible to have utilities to query and modify NDS?
I'm working on this (currently only queries). NDS
On Fri, 10 Sep 1999, Daniel O'Connor wrote:
Is there any reason to not have it as a port?
The only possible candidate for contrib'ifying I could see would be mount_nwfs
because building it without the kernel source could be a problem, but the rest
of it could be a port I think :)
"Matthew N. Dodd" wrote:
The only possible candidate for contrib'ifying I could see would be
mount_nwfs because building it without the kernel source could be a
problem, but the rest of it could be a port I think :)
Thats like suggesting we make the 'ipfw' command a port and leave the
On Sat, 11 Sep 1999, Daniel O'Connor wrote:
"Matthew N. Dodd" wrote:
The only possible candidate for contrib'ifying I could see would be
mount_nwfs because building it without the kernel source could be a
problem, but the rest of it could be a port I think :)
Thats like suggesting we
On Sat, 11 Sep 1999 03:08:40 +0930, "Daniel O'Connor" wrote:
"Matthew N. Dodd" wrote:
You want to take the anti-bloatist stance you'll have to do better than
that. Try libreadline for starters. :)
Bah like I care enough to care ;)
Yow! I had no idea it was so large!
I have an (as yet
On Fri, 10 Sep 1999, Parag Patel wrote:
I have an (as yet still incomplete) full-screen text-editor library I
wrote a long time ago - in C++ even - that supports (on a terminal using
termlib but not curses) full-screen editing, simultaneous "live"
multiple overlapping windows/views of
On Fri, 10 Sep 1999 14:07:12 EDT, "Matthew N. Dodd" wrote:
Clean it up and add perl bindings to it. Thats something that perl sorely
misses. Come to think of it, libedit could use perl bindings... Hummm...
Gaah - another big line-editing library! My editor's even smaller than
libedit!
On Fri, Sep 10, 1999 at 02:07:12PM -0400, Matthew N. Dodd wrote:
Clean it up and add perl bindings to it. Thats something that perl sorely
misses. Come to think of it, libedit could use perl bindings... Hummm...
/usr/ports/devel/p5-ReadLine-Gnu
Also /usr/ports/devel/p5-ReadLine-Perl,
In message [EMAIL PROTECTED] "Daniel O'Connor" writes:
: Thats like suggesting we make the 'ipfw' command a port and leave the
: kernel bits in the tree. Since all this stuff depends on being in sync,
: the only reasonable way to do this is to put it in the tree.
:
: Why? What kernel code
And thus spake Matthew N. Dodd, on Fri, Sep 10, 1999 at 02:07:12PM -0400:
Clean it up and add perl bindings to it. Thats something that perl sorely
misses. Come to think of it, libedit could use perl bindings... Hummm...
Kevin? :)
Bleah, one thing at a time :) Once I finish with my
On Fri, 10 Sep 1999, Kris Kennaway wrote:
I tend to agree. If we bring in all of this stuff (even though I
appreciate it's very useful) we should also bring in samba into the
base tree by symmetry.
Thats the idea. Once Boris gets a chance to finish cifsfs the plan is to
import it into the
On Fri, 10 Sep 1999, Matthew N. Dodd wrote:
On Fri, 10 Sep 1999, Kris Kennaway wrote:
I tend to agree. If we bring in all of this stuff (even though I
appreciate it's very useful) we should also bring in samba into the
base tree by symmetry.
Thats the idea. Once Boris gets a chance to
On Fri, 10 Sep 1999, Kris Kennaway wrote:
Thats the idea. Once Boris gets a chance to finish cifsfs the plan is to
import it into the tree the same as the Netware client stuff.
Okay. If that's the plan, then I don't have any objections.
I do hate the idea of having to reimplement samba
On Fri, 10 Sep 1999, Matthew N. Dodd wrote:
Okay. If that's the plan, then I don't have any objections.
I do hate the idea of having to reimplement samba because of the licensing
though - it already does quite a good job at SMB serving, it seems a waste
to duplicate the effort instead
On 10-Sep-99 Boris Popov wrote:
mount_nwfs - similar to mount_nfs
ncplogin- creates permanent connection to a NetWare server
without an actual mount,
ncplogout - destroy permanent connection,
ncplist
On Fri, Sep 10, 1999 at 06:29:57PM +0930, Daniel O'Connor wrote:
On 10-Sep-99 Boris Popov wrote:
mount_nwfs - similar to mount_nfs
ncplogin- creates permanent connection to a NetWare server
without an actual mount,
On Fri, 10 Sep 1999, Daniel O'Connor wrote:
Is there any reason to not have it as a port?
The only possible candidate for contrib'ifying I could see would be mount_nwfs
because building it without the kernel source could be a problem, but the rest
of it could be a port I think :)
On Fri, 10 Sep 1999, Ruslan Ermilov wrote:
Is there any reason to not have it as a port?
IMHO, only the basic IPX/SPX functionality should be included into the
source tree. Anything else could be available as ports/net/nw-utils.
An IPX/SPX stack is already in the tree and past
On Fri, Sep 10, 1999 at 04:58:52PM +0700, Boris Popov wrote:
On Fri, 10 Sep 1999, Ruslan Ermilov wrote:
Is there any reason to not have it as a port?
IMHO, only the basic IPX/SPX functionality should be included into the
source tree. Anything else could be available as
On Fri, 10 Sep 1999, Ruslan Ermilov wrote:
An IPX/SPX stack is already in the tree and past year made it more
or less functional.
Read: I fully agree with Daniel.
Daniel also left mount_nwfs :)
Forgive me my ignorance, but I'd like a quick response: what about multiple
On Fri, Sep 10, 1999 at 05:24:00PM +0700, Boris Popov wrote:
On Fri, 10 Sep 1999, Ruslan Ermilov wrote:
An IPX/SPX stack is already in the tree and past year made it more
or less functional.
Read: I fully agree with Daniel.
Daniel also left mount_nwfs :)
All
Boris Popov wrote:
On Fri, 10 Sep 1999, Daniel O'Connor wrote:
Is there any reason to not have it as a port?
The only possible candidate for contrib'ifying I could see would be mount_n
wfs
because building it without the kernel source could be a problem, but the r
est
of it
On Fri, 10 Sep 1999, Peter Wemm wrote:
Yes, that's acceptable. But mount_nwfs require libncp.so and this
means that ncp library sources will be also required. So KLD, mount_nwfs
and libncp should go into source tree and other utilities can be a port.
Other thoughts ?
I'm
Boris Popov wrote:
Currently I'm trying to determine a reasonable set of NetWare
utilities which should be included in the source tree.
Is it possible to have utilities to query and modify NDS?
ncpurge - purge specified salvagable files,
On Fri, 10 Sep 1999, Daniel O'Connor wrote:
On 10-Sep-99 Boris Popov wrote:
mount_nwfs - similar to mount_nfs
ncplogin- creates permanent connection to a NetWare server
without an actual mount,
ncplogout
Matthew N. Dodd wrote:
On Fri, 10 Sep 1999, Daniel O'Connor wrote:
On 10-Sep-99 Boris Popov wrote:
mount_nwfs - similar to mount_nfs
ncplogin- creates permanent connection to a NetWare server
without an actual mount,
On Fri, 10 Sep 1999, Marcel Moolenaar wrote:
Currently I'm trying to determine a reasonable set of NetWare
utilities which should be included in the source tree.
Is it possible to have utilities to query and modify NDS?
I'm working on this (currently only queries). NDS
On Fri, 10 Sep 1999, Daniel O'Connor wrote:
Is there any reason to not have it as a port?
The only possible candidate for contrib'ifying I could see would be
mount_nwfs
because building it without the kernel source could be a problem, but the
rest
of it could be a port I think
Matthew N. Dodd wrote:
The only possible candidate for contrib'ifying I could see would be
mount_nwfs because building it without the kernel source could be a
problem, but the rest of it could be a port I think :)
Thats like suggesting we make the 'ipfw' command a port and leave the
On Sat, 11 Sep 1999, Daniel O'Connor wrote:
Matthew N. Dodd wrote:
The only possible candidate for contrib'ifying I could see would be
mount_nwfs because building it without the kernel source could be a
problem, but the rest of it could be a port I think :)
Thats like suggesting we
Matthew N. Dodd wrote:
Why? What kernel code does this need?
The ncpfs kernel code for one.
We're talking about less than 500k of code here.
You want to take the anti-bloatist stance you'll have to do better than
that. Try libreadline for starters. :)
Bah like I care enough to care ;)
If
On Sat, 11 Sep 1999 03:08:40 +0930, Daniel O'Connor wrote:
Matthew N. Dodd wrote:
You want to take the anti-bloatist stance you'll have to do better than
that. Try libreadline for starters. :)
Bah like I care enough to care ;)
Yow! I had no idea it was so large!
I have an (as yet still
On Fri, 10 Sep 1999, Parag Patel wrote:
I have an (as yet still incomplete) full-screen text-editor library I
wrote a long time ago - in C++ even - that supports (on a terminal using
termlib but not curses) full-screen editing, simultaneous live
multiple overlapping windows/views of buffers,
On Fri, 10 Sep 1999 14:07:12 EDT, Matthew N. Dodd wrote:
Clean it up and add perl bindings to it. Thats something that perl sorely
misses. Come to think of it, libedit could use perl bindings... Hummm...
Gaah - another big line-editing library! My editor's even smaller than
libedit!
text
On Fri, Sep 10, 1999 at 02:07:12PM -0400, Matthew N. Dodd wrote:
Clean it up and add perl bindings to it. Thats something that perl sorely
misses. Come to think of it, libedit could use perl bindings... Hummm...
/usr/ports/devel/p5-ReadLine-Gnu
Also /usr/ports/devel/p5-ReadLine-Perl, which
In message 37d93d65.627a...@dons.net.au Daniel O'Connor writes:
: Thats like suggesting we make the 'ipfw' command a port and leave the
: kernel bits in the tree. Since all this stuff depends on being in sync,
: the only reasonable way to do this is to put it in the tree.
:
: Why? What kernel
And thus spake Matthew N. Dodd, on Fri, Sep 10, 1999 at 02:07:12PM -0400:
Clean it up and add perl bindings to it. Thats something that perl sorely
misses. Come to think of it, libedit could use perl bindings... Hummm...
Kevin? :)
Bleah, one thing at a time :) Once I finish with my
On Fri, 10 Sep 1999, Ruslan Ermilov wrote:
Is there any reason to not have it as a port?
IMHO, only the basic IPX/SPX functionality should be included into the
source tree. Anything else could be available as ports/net/nw-utils.
I tend to agree. If we bring in all of this stuff (even
On Fri, 10 Sep 1999, Kris Kennaway wrote:
I tend to agree. If we bring in all of this stuff (even though I
appreciate it's very useful) we should also bring in samba into the
base tree by symmetry.
Thats the idea. Once Boris gets a chance to finish cifsfs the plan is to
import it into the
On Fri, 10 Sep 1999, Matthew N. Dodd wrote:
On Fri, 10 Sep 1999, Kris Kennaway wrote:
I tend to agree. If we bring in all of this stuff (even though I
appreciate it's very useful) we should also bring in samba into the
base tree by symmetry.
Thats the idea. Once Boris gets a chance to
On Fri, 10 Sep 1999, Kris Kennaway wrote:
Thats the idea. Once Boris gets a chance to finish cifsfs the plan is to
import it into the tree the same as the Netware client stuff.
Okay. If that's the plan, then I don't have any objections.
I do hate the idea of having to reimplement samba
On Fri, 10 Sep 1999, Matthew N. Dodd wrote:
Okay. If that's the plan, then I don't have any objections.
I do hate the idea of having to reimplement samba because of the licensing
though - it already does quite a good job at SMB serving, it seems a waste
to duplicate the effort instead
56 matches
Mail list logo
