Is FreeBSD dead? Well, not in theory... --> please take this threadsomewhere else.

[Kevin Stevens]

I am sorry, but this discussion REALLY belongs elsewhere. Please take it
to -chat or another forum where it belongs. Please?  I was not able to get
my mail all weekend and was inundated with a deluge of mail on this debate.
There is a reason there are multiple lists.
-Kevin Stevens


Kevin Stevens
Student
State University of New York at Albany
box #0926 colonial quad
albany, ny 1
518-442-0378



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

yet another cvsup server

[Joao Pedras]

Hi all

I setup a cvsup server on a machine that is always 'in the air' and besides
that it has an excelent connection to a common interchange connecting the
several isp's in my country.

Since here there is no (at least official) cvsup server , I would like to know
how could I submit this so the machine could have some alias like
cvsup.country.freebsd.org and provide a real use to the freebsd community here.

Tkx

Joao


  ^\   /^
O O
o00-(_)-00o--

Any fool can paint a picture, but it takes a wise person to be able to
sell it.

-
PGP key available upon request or may be cut at 
http://pedras.webvolution.net/pgpkey.html



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 5.0 features?

[Ted Sikora]

root wrote:
> 
> "Pedro F. Giffuni" wrote:
> >
> > FWIW,
> >
> > I downloaded the BSDI 4.1 Release notes and I was surprised by the
> > quality of the document. It goes through the basics of installing and
> > configuring BSDI.
> It is nice. I use it in our webhosting servers. Hi-Performance in my
> book.
> >
> > I think the priority will be getting BSDI binaries running on FreeBSD,
> > so I would expect:
> >
> > -New tools to complement binutils (they also use egcs), no idea if the
> > use that nasty ldconfig.
> > -Many changes to libc.
> > -Native ports of their packaging tools.
> > -Ability to mount their disks?
> >
> > Any idea if BSDI has a unified VM? They carry ISODE and several
> > unsupported goodies like LFS, the OSI stack, X25... Their floppy driver
> > also supports 2.8 M floppies, which I recall don't work on FreeBSD.
> >
> > Towards the future I would expect:
> > -More SMP stuff (and more threading)
> > -New Platforms: SPARC, PowerPC, StrongARM.
> > -Clustering: probably MOSIX.
> >
> > I am not sure if BSDI has a Motif source license, but this is something
> > I would prefer to buy from them in a future. In fact, now that there is
> > a big company to deal with, I would expect many more commercial products
> > available.
> Same here. I still prefer Motif.
> 
> How about Java support? Sun is releasing some nice tools to OpenSource
> like Forge, etc. At one point I found FreeBSD
> better suited than Linux for java development but that has
> changed with 1.2's release. Too bad we couldn't conjur up some more
> interest here. Sun uses it in some cool ways. No reason we couldn't. The
> new generation of Java apps are starting to look
> and run pretty good.
> 
> >
> > I really don't see what can be negative in this merger (in fact that
> > discussion is finally dying in -chat so please redirect new arguments
> > there :). IMHO, BSDI will probably end up being a FreeBSD with POSIX and
> > C2 certifications, and excellent support...I'm sure big companies like
> > Yahoo wouldn't care to pay some bucks for the extra support.
> >
> Future looks bright indeed! I was so preoccupied listening to everyone
> bitching I forgot about all the nice things to come.
> 
> > (And  BTW. if people are really worried about drivers perhaps it's time
> > for them to really look at the UDI project.)
> >

If anyone's interested RealPlayer7 just came out today. It's works 
excellent under Linux Emulation. Includes most of the features of the
Win/Mac versions and has a working plugin. I just installed it under
(ahem!)5.0-current with Netscape-4.72. I know some of you 
will scoff(at linux emulation) but hey It's cool. All work and no
play

--
Ted Sikora
Jtl Development Group 
[EMAIL PROTECTED]
http://powerusersbbs.com


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 5.0 features?

[root]

"Pedro F. Giffuni" wrote:
> 
> FWIW,
> 
> I downloaded the BSDI 4.1 Release notes and I was surprised by the
> quality of the document. It goes through the basics of installing and
> configuring BSDI.
It is nice. I use it in our webhosting servers. Hi-Performance in my
book.
> 
> I think the priority will be getting BSDI binaries running on FreeBSD,
> so I would expect:
> 
> -New tools to complement binutils (they also use egcs), no idea if the
> use that nasty ldconfig.
> -Many changes to libc.
> -Native ports of their packaging tools.
> -Ability to mount their disks?
> 
> Any idea if BSDI has a unified VM? They carry ISODE and several
> unsupported goodies like LFS, the OSI stack, X25... Their floppy driver
> also supports 2.8 M floppies, which I recall don't work on FreeBSD.
> 
> Towards the future I would expect:
> -More SMP stuff (and more threading)
> -New Platforms: SPARC, PowerPC, StrongARM.
> -Clustering: probably MOSIX.
> 
> I am not sure if BSDI has a Motif source license, but this is something
> I would prefer to buy from them in a future. In fact, now that there is
> a big company to deal with, I would expect many more commercial products
> available.
Same here. I still prefer Motif.

How about Java support? Sun is releasing some nice tools to OpenSource
like Forge, etc. At one point I found FreeBSD 
better suited than Linux for java development but that has 
changed with 1.2's release. Too bad we couldn't conjur up some more
interest here. Sun uses it in some cool ways. No reason we couldn't. The
new generation of Java apps are starting to look 
and run pretty good. 

> 
> I really don't see what can be negative in this merger (in fact that
> discussion is finally dying in -chat so please redirect new arguments
> there :). IMHO, BSDI will probably end up being a FreeBSD with POSIX and
> C2 certifications, and excellent support...I'm sure big companies like
> Yahoo wouldn't care to pay some bucks for the extra support.
>
Future looks bright indeed! I was so preoccupied listening to everyone
bitching I forgot about all the nice things to come. 
 
> (And  BTW. if people are really worried about drivers perhaps it's time
> for them to really look at the UDI project.)
> 
> cheers,
> 
>  Pedro.
> 

--
Ted Sikora
Jtl Development Group 
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Getting CPU usage in FreeBSD

[Garance A Drosihn]

At 12:00 PM -0800 3/12/00, Jordan K. Hubbard wrote:
> > I'm definitely for it... If I can get permission from Jordan,
> > perhaps the attached patches can make it into upcoming release.
>
>I think it's a fine idea, I'm just not sure one day before release
>is the time to be talking about it.  It should have been raised
>before now. :(

This should probably wait until we've had a little more time to
think about it.  The original requester mentioned:

I am using FreeBSD-3.4-RELEASE/i386 for development,
and would like to code to be portable for the widest
range of FreeBSD versions possible.

Even if we did get this in for 4.0-release, it would only solve
the problem for 4.0-release.  I realize that would be nice, but
I have the feeling that it could wait until post-4.0-release.
(I should note that I would personally like to see a per-CPU
value, for those of us who have multiple-cpu systems...)


---
Garance Alistair Drosehn   =   [EMAIL PROTECTED]
Senior Systems Programmer  or  [EMAIL PROTECTED]
Rensselaer Polytechnic Institute


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Is FreeBSD dead? Well, not in theory...

[Marco van de Voort]

> > >http://home.wxs.nl/~asmodai/newbus-draft.txt comes to mind.  And when
> > >that is finished the manpages will follow.
> > >
> > >That's also why I am wasting my time slowly documenting the FreeBSD
> > >internals in my spare time.
> > 
> > "slowly" is the key word here. Real products are documented before they are
> > in commercial use. Plus by the time you're done they will be
> > outdated...another common problem.
> > 
> > Why are you arguing this point? Is there anyone that believes that Linux
> > and FreeBSD are well documented? Please. The books are out of date before
> > they hit the stores.
> 
>   This is completly pointless. The user side of the FreeBSD is very
> well documented. The kernel internals has more poor documentation. But if
> someone want or need to contribute kernel side code, he is expected to be
> clueful enough to understand kernel sources _and_ ideolgy. In fact, it is
> doesn't require too much time. When you're jump in to truck, it is not too
> hard to track related source code changes and keep your code synched up.

Sorry, but that is nonsense. It just limits developpers that don't daily work 
on the kernel.

I don't agree. Users might have to patch to get their own systems running, and
moderate docs will help. Specially in find the right source, and eliminating 
possibilities of what to look into.  Also developpers that go outside their normal 
territory, can use the docs.

I managed to patch the linux kernel once without even knowing C, so knowledge
of the kernel internals is not necesssary to make a patch which works. Since
a patch always has to pass through experts hands before being committed, I 
also see no dangers to users working on the kernel, specially not for own use.

(it was trivial though, the order of the ports for the soundblaster mixer is different 
on some clones)



Marco van de Voort ([EMAIL PROTECTED])




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Detecting ECC errors

[Jeremy McMillan]

Just how valuable *IS* it? I can come up with a test plan. 

1. Get a pile of expendable ECC DIMMS.
2. Get your hacked kernel loaded.
3. Get an LKM to do malloc(); and free(); in kernelspace.
4. Open up your case, swap your DIMMS for expendable modules. Make sure ECC
mode is on.
5. Boot, load your LKM and start having some non-corrected memory
operations.
6. (this is where it gets fun) 
   Fire up a propane (pen) torch with a low flame, and *gently* heat the
dimm.
7. Keep the tip of the flame 2-3 inches away from the DIMM, and keep it
moving!
8. Keep the flame well clear of anything else, and be mindful of the
practically invisible 
   stream of hot gases that will flow over, and past your DIMM, warming your
motherboard, 
   etc. if you aren't careful. You only want to fry a few of the weakest
components on your DIMM.
   The emphasis is on SLOWLY heat the DIMM.
9. Shampoo, rinse, repeat. YMMV: continue until you get ECC errors or your
machine crashes.
10. Replace the DIMM with known-good-DIMM and hack your kernel again if it
didn't work.
11. If you manage to burn a DIMM that works except for a predictable ECC
correction, KEEP IT!

Doug Barton wrote:
> 
> CC'ing -hackers in case we can scare up some interest . . .
> 
> Mike Smith wrote:
> >
> > >   Hi.  I took a look over the archives and noticed this ancient
> > > thread.  (1998)  However, I checked the handbook and LINT for options on
> > > how FreeBSD logs ECC errors, but I could not find anything.  Has this
> > > finally been implemented?  Or is there currently no way for the OS to
> > > detect the # of corrections / detections of errors by DIMM slot?
> >
> > You're correct; there isn't.  It's a relatively simple task that's been
> > waiting for a junior hacker to come along and take it up.  It's also
> > devillishly difficult to _test_ such code...
> 
> This would be a very valuable thing to have though (just to restate the
> obvious). We had a sun machine go down at work with no symptoms at
> all... other than the log which showed that ECC errors were being caught
> and corrected (mostly) at a furious pace. If not for that log we would
> have spent hours testing possible reasons for the crash.
> 

-- 
--- -___,,_ , , _ ,_  _ ,_ ,,_  _  _   _  _ . .__-
 -_/||_>|_|/ \|_>/_\|_>||_>/ `/ \ / `/ \|\|\-
   -__/-||  | |\_/| \\_ | \||  \_ \_/#\_ \_/| \ \__-


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Editing Kernel

[Greg Lehey]

On Monday, 13 March 2000 at 17:02:44 -0400, Rafael Gomez wrote:
> I´m trying to edit the kernel file but I don´t know where it is located. I´m
> editing a file that shows only @@@ characters. I assume that this is the
> binary file. That´s why I´m asking for help
>
> Could any of you help me wityh this?

Possibly.

1.  Ask questions like this on FreeBSD-questions.
2.  Specify exactly what you're trying to do.  The kernel is, indeed,
a binary file.  "Edit the kernel file" doesn't sound like a
useful thing to me.

Greg
--
When replying to this message, please copy the original recipients.
For more information, see http://www.lemis.com/questions.html
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Editing Kernel

[Kelly Yancey]

On Mon, 13 Mar 2000, Rafael Gomez wrote:

> I´m trying to edit the kernel file but I don´t know where it is located. I´m
> editing a file that shows only @@@ characters. I assume that this is the
> binary file. That´s why I´m asking for help
> 
> 
> Could any of you help me wityh this?
> 

  You need to have the kernel source installed. In which case, the default 
kernel config files will be in /sys/i386/conf (for i386) or
/sys/alpha/conf (for the alpha platform). In the director is the config
file for the GENERIC kernel and LINT (which lists all of the available
kernel config options). I recommend that you copy GENERIC to your own file
(for example MYKERNEL). Edit that file. And then to rebuild your kernel,
type 'config MYKERNEL' (replace "MYKERNEL" with whatever you named your
kernel config file). It config exists successfully, then cd to
../../compile/MYKERNEL, and type: 
make depend && make -j 4 && make install

  Finally, you'll need to reboot to load the new kernel. If you have any
problems booting off your new kernel, you should still able to boot using
/kernel.GENERIC (a copy of the default kernel).

  You should, however, read the FreeBSD handbook and the config(8) man
page.

  Kelly

--
Kelly Yancey  -  [EMAIL PROTECTED]  -  Richmond, VA
Analyst / E-business Development, Bell Industries  http://www.bellind.com/
Maintainer, BSD Driver Database   http://www.posi.net/freebsd/drivers/
Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Editing Kernel

[Rafael Gomez]

I´m trying to edit the kernel file but I don´t know where it is located. I´m
editing a file that shows only @@@ characters. I assume that this is the
binary file. That´s why I´m asking for help


Could any of you help me wityh this?


Rafael Gomez
[EMAIL PROTECTED]
Pager: [EMAIL PROTECTED]
Charter Communications International Venezuela

Tel: 58-2-576.60.80
Fax: 58-2-572.43.43



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: inner workings of the C compiler

[Oscar Bonilla]

On Sat, Mar 11, 2000 at 02:30:19PM +0100, Marco van de Voort wrote:
> P.s. Could you sent me a minimal C program linking to libc, and the
> commandline to compile it with -nostdlib ?
>
> I could throw all these experiences with non standard linking in a
> little tex doc.  ( --nostdlib with and without libc, pure assembler
> instead of c (no gcc), some small chapter about syscall conventions
> etc)

Here's what I have for a test program:

-
#include 
#include 
#include 

int main () {

struct passwd *password;

while ( (password = getpwent()) != NULL ) {
printf("login: %s\n", password->pw_name);
}

password = getpwnam("root");
printf("root has uid: %d\n", password->pw_uid);

password = getpwuid(0);
printf("uid 0 is %s\n", password->pw_name);

return 0;
}
-

I copied /usr/src/lib/libc and /usr/src/lib/csu to the parent dir of
this test, and thus my makefile is:

-
all: get-test

get-test.o: get-test.c
cc -g -Wall -pedantic -ansi -c -I../libc/include get-test.c

get-test: get-test.o
cc -g -nostdlib -static -L../libc -o get-test \
../csu/i386-elf/crt1.o \
../csu/i386-elf/crti.o \
../csu/i386-elf/crtbegin.o \
get-test.o \
../csu/i386-elf/crtend.o \
../csu/i386-elf/crtn.o \
-lc

clean:
rm -f nss-test get-test *.o *.core *.*~
-

The ordering above was pointed to me by Chuck Robey who got it using
the -v flag to cc (which shows you what the C compiler is doing to get
good links).

I'm not 100% sure that the -lc should be at the end... more likely it
should be right after (before?) my object file (get-test.o), but it
seems to work both ways.

regards,

-oscar

-- 
pgp public key: finger [EMAIL PROTECTED]
pgp fingerprint: 6D 18 8C 90 4C DF F0 4B  DF 35 1F 69 A1 33 C7 BC


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Onboard Intel fxp network chip, unknown PHY 17 type 2

[Milon Papezik]

David Greenman wrote:
> 
> >Hmm.  That reminds me:  I've also got a box with an onboard
> >8255X that isn't recognized.  The relevant parts of "boot -v"
> >output are:
> >
> >found-> vendor=0x8086, dev=0x1209, revid=0x09
> >class=02-00-00, hdrtype=0x00, mfdev=0
> >subordinatebus=0secondarybus=0
> >intpin=a, irq=11
> >map[10]: type 1, range 32, base ffaff000, size 12
> >map[14]: type 1, range 32, base ef00, size  6
> >map[18]: type 1, range 32, base ffac, size 17
> >
> >[...]
> >
> >pci0: unknown card (vendor=0x8086, dev=0x1209) at 14.0 irq 11
>   ^
> 
>Don't know what that is, but's not a part that is supported by the fxp
> driver. It would help if you could find out the part number (8255X isn't
> sufficient since it isn't really just one series - some of the parts are
> similar, and others are completely different).

I've run into similar problem with Compaq branded card
under 3.4R. Chip number GD82559, series(?) L933SB2.

The PCI chip ID was set to 82558, but I was able to distinguish
between 8255[89] by reading PHY revision code directly from
PHY's registers and the PHY revision code was the same as
in Intel's docs for 82559.

I can test the patch.

Hope this helps.
Milon Papezik
--
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: PXE

[Oliver Fromme]

Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote in list.freebsd-hackers:
 > -On [2313 13:55], David Yeske ([EMAIL PROTECTED]) wrote:
 > >I just got an Intel PRO/100+ Management card for a project I am working on.  I have 
 >done a little
 > >a little research and it looks like it is going to be a lot of work to netboot this 
 >thing.  Anyone
 > >gotten this to work so far?  I have tried using bootpd and dhcpd with no luck.
 > 
 > Please save your troubles.
 > 
 > I know of some committers whom are netbooting with 3Com's and Intels
 > already.  I think that this will be committed ASAP.

Over here, /usr/ports/net/etherboot works fine, after a bit of
hacking.

Regards
   Oliver

-- 
Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany
(Info: finger userinfo:[EMAIL PROTECTED])

"In jedem Stück Kohle wartet ein Diamant auf seine Geburt"
 (Terry Pratchett)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

-npx problem-

[Claude Castelluccia]

Dear all,

I am running FreeBSD 3.3 release.
I have modified the if_ethersubr.c function in order
to add some bit errors on the incoming packets (for experimentation
purposes). Since then, my system reboots periodically and
and displays the following message: 

" npxintr: npxproc =0, curproc = 0, npx_exists = 1",
"panic("npxintr from nowhere");"

any idea how to solve the problem?

thanks a lot!

PS: In my code, I am using the random() function. I don't know
if this is a hint...
  
-- 


Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Detecting ECC errors

[Robert Sexton]

On Sun, Mar 12, 2000 at 01:11:19PM -0800, Doug Barton wrote:
>   CC'ing -hackers in case we can scare up some interest . . .
> 
> Mike Smith wrote:
> > 
> > >   Hi.  I took a look over the archives and noticed this ancient
> > > thread.  (1998)  However, I checked the handbook and LINT for options on
> > > how FreeBSD logs ECC errors, but I could not find anything.  Has this
> > > finally been implemented?  Or is there currently no way for the OS to
> > > detect the # of corrections / detections of errors by DIMM slot?
> > 
> > You're correct; there isn't.  It's a relatively simple task that's been
> > waiting for a junior hacker to come along and take it up.  It's also
> > devillishly difficult to _test_ such code...

I bet a call for bad simms would dredge up a few.  I have a machine on
my desk that double bits about twice a week right now.  Any takers? :-)


-- 
Robert Sexton - [EMAIL PROTECTED], Cincinnati OH, USA
Build a man a fire, and he's warm for the rest of the night.  Set a man
on fire, and he's warm for the rest of his life - Terry Pratchett, "Jingo"


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

need help

[Mourad Lakhdar]

hi everybody:

i need help in compiling the kernel for the freebsd 3.3 ,because when
doing that i got errors related to some headers, may be should i compile
with other compiler  options, if so what they are ,- 

i compiled with cc ip_input.c -lnsl
and i want to modify the ip layer code (inptr , ip_input.c , ip_output.c
,--) to make a load balancing of services (, and i need to 





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Is FreeBSD dead? Well, not in theory...

[Giorgos Keramidas]

On Mon, Mar 13, 2000 at 03:44:04AM -0500, Dennis wrote:
> 
> "slowly" is the key word here. Real products are documented before
> they are in commercial use.

The fact that they're documented, does not imply that their
documentation is also "good", though.

Oh, and let us not forget that some vendors think their documentation of
the system is not an essential 'part' of the whole thing, but it should
come packaged in a separate bundle, and charged extra.

- Giorgos Keramidas


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: rewrite of sysinstall

[Bruce Gingery]

In freebsd-hackers, Edward Gold wrote:

-> I was actually planning a near-complete rewrite of sysinstall anyway!
-> How about everyone throwing in whatever suggestions you would like 
-> (about anything regarding sysinstall), and I will try to incorporate them!?

-> The things I am specifically going to focus on are:

-> 1. depretzel the GUI from the logic and modularize.

  Excellent!!!

Please add vikeys as a possible option for the GUI itself.
  I've had some times running on a remote machine over bad enough
  links that cursor keys were unusable, hence it was impossible to
  use the current GUI.   Even just the hjkl  key-set would have
  made it usable.  If not enabled, make option letters non-
  case-sensitive.  If enabled, force all option selection keys
  uppercase, similar to Lynx's handling of the "h" versus "H" key. 

  At a minimum, make everything navigable by single-byte-key
  commands.

-> 2. implement scripting capability so we can control the user's path
->through the various menus from a script file of sorts.

  Yep, although one of the biggest neophyte complaints I've seen
  so far is too many navigation paths, which makes the whole
  process seem more complex than it is.

  Perhaps moving all of the post-install configuration items
  to a seemingly distinct interface would answer that.

  One thing often ignored is the presumption that /var/ will
  be the default proxy queue for Apache, and even the default
  database location for MySQL.  Running either of these with
  default configurations tend to increase the need for /var/
  space.  Logging Apache logs to /var/log/ on a popular server
  adds that much more.  Mailservers with large /var/mail or
  mail or print or fax servers with large /var/spool/ usage
  similarly.  This info should be in help when the disk is
  partitioned.

-> 3. possibly make stand alone post-install GUI based utilities for
->fdisk/disklabel and other configuration functions.

  Yes PLEASE!  By decoupling the post-install GUI from the distribution
  install (although perhaps "sharing modules"), we can look at a number
  of things:
  
* Migration assistance when installing an update.  Several
  upgrades since v2.0.x haven't been painless, and some
  have been a bit confusing.

* Less confusion in "adding distributions" without committing
  to a complete re-install.

* Make kernel builds a part of the post-install GUI (at least
  eventually).

* Even (eventually) allow non-root port/package installs part
  of the post-install GUI.  Even PIB needs to run as root, last
  I checked.   It wouldn't be all that hard to check for a
  system-wide install already in place, and change $PREFIX
  for a non-root install, so long as pkg_add and pkg_delete
  could also be directed to other than /var/db/pkg/ when run as 
  non-root.


OTHER THOUGHTS

If it's to be modular (e.g. plug-in in basic design) anyways, how
about preserving a single basic binary for the GUI, and defaulting
to a different set of "plug-ins" depending upon whether it's running
from RAMfs or /stand/sysinstall, and whether it's being run with an
EUID as root or not.  E.g:

Run to install:  Presume that it's a new install or upgrade
 unless launched with an override flag, perhaps
 -configure  That would allow post-install to
 merely re-invoke itself as an exec'd subtask.
 
/stand/sysinstall as root: Presume it's a system configuration
 unless launched with an override flag, perhaps
 -software or -upgrade
 
/stand/sysinstall non-root: Presume it's for user configuration
 or by-user ports/package install tasks, but warn 
 that for system configuration it must be run as
 root.

 Despite the gradual decrease in usefulness of diskettes, its likely
 that a user-level interface built on /stand/sysinstall should be
 available for formatting diskettes.

 Space permitting, there could be a menu option to switch from one
 to another, even if it required an exec re-launch of the GUI shell
 to get into that "other setup task".



**
You might wish to consider also, HTTP fetch capacity of these
"modules". This would allow, for example, mounting a CD on one
LAN host with a webserver, or over-the-internet installs to fetch
far more even for the basic system install and configuration, than
would ever be desirable in kern.flp or the memory filesystem root.

So long as the module has a checksum in its file format, partial
fetches could be handled fairly easily, even with a 

Re: Midnight Commander and FreeBSD

[M Pendev]

thanx bush doctor ... ;-)

but, I know how to install ports...
I want to install only mc (for txt console only) not the whole gnome pkg
because i have good working kde.

I have tryed to compile it - but some errors occur
he need the gtk and gnome libs - thats all.

thanx anyway again.

 M Pendev

e-mail: [EMAIL PROTECTED]









To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: PXE

[Jeroen Ruigrok van der Werven]

-On [2313 13:55], David Yeske ([EMAIL PROTECTED]) wrote:
>I just got an Intel PRO/100+ Management card for a project I am working on.  I have 
>done a little
>a little research and it looks like it is going to be a lot of work to netboot this 
>thing.  Anyone
>gotten this to work so far?  I have tried using bootpd and dhcpd with no luck.

Please save your troubles.

I know of some committers whom are netbooting with 3Com's and Intels
already.  I think that this will be committed ASAP.

-- 
Jeroen Ruigrok van der Werven  Network- and systemadministrator
<[EMAIL PROTECTED]>  VIA NET.WORKS The Netherlands
BSD: Technical excellence at its best  http://www.bart.nl
Here's a mirror, there's a screen, on both ways you can get in...


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

PXE

[David Yeske]

I just got an Intel PRO/100+ Management card for a project I am working on.  I have 
done a little
a little research and it looks like it is going to be a lot of work to netboot this 
thing.  Anyone
gotten this to work so far?  I have tried using bootpd and dhcpd with no luck.

Regards,
David Yeske
__
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 5.0 features?

[Gary Jennejohn]

Patryk Zadarnowski writes:
>> Mark Hittinger writes:
>> >
>> >Something that the old DEC took a few stabs at was the idea of a
>> >"checkpoint" feature where a process or a series of processes could be
>> >put in a quiesced state.  This would page out the process or processes
>> >into the swap space, allow a hardware shutdown, and after a reboot allow
>> >the restart of the checkpointed process(es).
>> >
>> 
>> I did something like this for Philips while I was at UniSoft. It
>> depended on some special hardware features (turning off/losing power
>> generated an interrupt, there was a small UPS in the box along with
>> battery-backed SRAM to save various kernel structures).
>> 
>> Turning off the power caused all memory to be saved to disk (the kernel
>> turned off the UPS after it was done). Upon a restart the kernel noticed
>> that memory had been saved, read the contents in from disk, futzed around
>> with some structures, and restarted what was curproc at the time of
>> shutdown. It even worked ;-)
>> 
>> Philips never did anything with it.
>
>Out of pure curiosity, what did you do with pending interrupts, partially
>completed DMA transfers and other such state information?
>

IIRC (this was all 13 years ago) there were hooks in the drivers
which were called on shutdown/startup so that they could DTRT.

I do remeber that some characters were lost on the serial ports.
Disk and network seemed to work fine, though.

---
Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

buffer overflow in rtm_type_name() of routed(8)

[Seigo Tanimura]

I had been experiencing routed(8) dumping core in about five minutes
after rebooting my box for several months. A string buffer in
rtm_type_name() of src/sbin/routed/table.c was overrun if the string
appropriate to the argument of rtm_type_name() was not found. The
router is a box running Solaris 2.6.

The following patch should fix this problem. With this patch routed(8)
in my box is running just fine for more than two days.



--- table.c.org Fri Sep 17 03:50:10 1999
+++ table.c Sat Mar 11 15:03:09 2000
@@ -617,6 +617,7 @@
 }
 
 
+#define NAME0_LEN 14
 static const char *
 rtm_type_name(u_char type)
 {
@@ -636,12 +637,12 @@
"RTM_DELADDR",
"RTM_IFINFO"
};
-   static char name0[10];
+   static char name0[NAME0_LEN];
 
 
if (type > sizeof(rtm_types)/sizeof(rtm_types[0])
|| type == 0) {
-   sprintf(name0, "RTM type %#x", type);
+   snprintf(name0, NAME0_LEN, "RTM type %#x", type);
return name0;
} else {
return rtm_types[type-1];




-- 
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: 5.0 features?

[Kris Kennaway]

On Sun, 12 Mar 2000, Ted Sikora wrote:

> What kind of features and additions can we expect from the merged
> systems in 5.0? It looks as though this has been in 
> the works for sometime. I think I read somewhere that SMP support would
> be much improved?

Since no-one else seems to have replied about this, 5.0 only started
development about 2 hours ago when the 5.0-CURRENT branch split from
4.0-RELEASE. I'm sure there will be lots of exciting features added during
the course of the branch, but exactly what those are remains to be seen.
I'd expect to see improved SMP support in some form however - whether that
comes from BSD/OS or internally.

Kris


In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTECTED]>




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Is FreeBSD dead? Well, not in theory...

[Boris Popov]

On Mon, 13 Mar 2000, Dennis wrote:

> At 07:32 PM 3/12/00 +0100, Jeroen Ruigrok/Asmodai wrote:
> >
> >Exactly, and it also slightly pisses me off...
> >
> >Then I guess I wrote all the manpages and documents for nothing.
> >
> >elf.5 comes to mind for a very handy resource.
> >
> >http://home.wxs.nl/~asmodai/newbus-draft.txt comes to mind.  And when
> >that is finished the manpages will follow.
> >
> >That's also why I am wasting my time slowly documenting the FreeBSD
> >internals in my spare time.
> 
> "slowly" is the key word here. Real products are documented before they are
> in commercial use. Plus by the time you're done they will be
> outdated...another common problem.
> 
> Why are you arguing this point? Is there anyone that believes that Linux
> and FreeBSD are well documented? Please. The books are out of date before
> they hit the stores.

This is completly pointless. The user side of the FreeBSD is very
well documented. The kernel internals has more poor documentation. But if
someone want or need to contribute kernel side code, he is expected to be
clueful enough to understand kernel sources _and_ ideolgy. In fact, it is
doesn't require too much time. When you're jump in to truck, it is not too
hard to track related source code changes and keep your code synched up.

--
Boris Popov
http://www.butya.kz/~bp/



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message