Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Feb 1996 18:55:06 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        msmith@atrad.adelaide.edu.au (Michael Smith)
Cc:        muir@idiom.com, freebsd-hackers@FreeBSD.org
Subject:   Re: An ISP's Wishlist...
Message-ID:  <199602150155.SAA01323@phaeton.artisoft.com>
In-Reply-To: <199602150007.KAA18935@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Feb 15, 96 10:37:05 am

next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith writes:
> David Muir Sharnoff stands accused of saying:
> > 
> > I know you've seen such things before, so I'm sending mostly to
> > keep the feedback coming.
> 
> Wishlists are a Good Thing 8)

[ ... ]

> > Memory efficiency.  The most expensive part of putting a system
> > together at the moment is memory.  
> 
> What have you identified as the major wasters of memory?  If you're
> running 2.1 or -STABLE, bring malloc.c in from current and recompile 
> libc.  This gets you the new phkmalloc, which seems to be somewhat more
> efficient.

I'd say that the install was a hog (though this has been fixed in the
most recent SNAP, it seems).

I'd like to see space recovered for all drivers not currently in use.

> > Getty should track modem disconnect codes, reset the modem, and
> > notice incoming faxes.  I've already modified the default getty
> > to notice PPP connects, but that's needed here too.
> 
> Modem disconnect coeds are as good as impossible to catch; some modems
> emit then before dropping DCD, so there's no way of knowing that they
> _are_ disconnect codes.  To do this properly would require major 
> modifications to the serial driver(s).
> 
> mgetty does much of what else you want; it also recognises incoming FNT
> connections.

And mgetty is evil, for resons disucdded beofre at geat length (see the
list archives instead of starting this one up again... 8-)).

> > SMP.  Sometimes more CPU is needed.
> 
> This is being worked on; if you have resources, talk to Terry.

Especially if you have ICE hardware.  The current problem preventing
submission as a set of patches is processor environment setup (specifically
per processor LDT/GDT on the second processor).  Everything else is ready
to go.  I'm starting on the hierarchical lock code for FS multithreading
now.

> > Real layered filesystems.  In particular, I want to layer system 
> > configurations over a read-only root filesystem that is replicated
> > to all my computers.
> 
> Fix the unionfs 8)

It wouldn't fix it because of /etc.  It would require custom rc work,
even if unionfs were employed.

[ ... OS ABI ... ]

> > Solaris,
> 
> Dunno 8)

This is one that should be worked on...

> > WinNT,
> 
> Not likely in the short-term future.

Actually, most WinNT programs are Win32 programs, so there is some hope
on this one, though I would recommend against holding your breath.

> > Sys5.4, and SCO. 
> 
> iBCS2 and particularly SCO support is there already.

SVR4 is ELF.  SVR3 is iBCS2.  SCO is SVR3.

Add Xenix ABI to this list.

> > I would like to be able to call up Frame
> > and say, please send me a copy for ??? without worrying that it
> > won't work.
> 
> Dreaming 8)

We need an ABI-using tested software list.  I don't know how Frame tests,
but most companies use automated testing techniques for port validation.
We need to talk them into running them on BSD.

Part of the problem is that ABI includes install environments for the
apps to be loaded with.  Right now, it's hand-install or nothing.

A lot of Databases and other programs that have daemons like to drop
code into /etc/rc?.d/* files to start at the correct run level.

> > also has it).   Much less important: all the rest (Win95, WinNT,
> > OS/2, SCO, Linux native, UMSDOS)
> 
> VFAT is likely once the FAT support is fixed.  There's a readonly NTFS
> around already.  I don't recall anyone working on HPFS, SCO or UMSDOS.
> UMSDOS should be redundant (apart from for compatability reasons) once
> VFAT is done.

UMSDOS allows permissions, file ownership, and other inode data, on top
of simple long name support.  VFAT will not fix this.

> > Netware support.  Linux has it.
> 
> In what regard?  FreeBSD can route IPX as well.

Linux has client and minimal server code.  The client code is on the
SMBFS site, I believe.

The server code is from Caldera.  Youmight be able to get them to do
a port, or someone may want to talk to "Puxxle Systems" about porting
their 3.x NetWare server as a loss-leader.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602150155.SAA01323>