Re: [PREVIEW] bsdconfig(8)

[Devin Teske]

On Mar 5, 2012, at 5:03 PM, Devin Teske wrote:

> 
> 
>> -Original Message-
>> From: Robison, Dave [mailto:david.robi...@fisglobal.com]
>> Sent: Monday, March 05, 2012 5:00 PM
>> To: freebsd-hackers@freebsd.org
>> Cc: r...@fuzzwad.org; Devin Teske
>> Subject: Re: [PREVIEW] bsdconfig(8)
>> 
>> On 03/05/2012 16:44, Devin Teske wrote:
>> 
>> 
>>> 
>>> We continue to work very hard on this every day and look forward to any/all
>>> feedback, comments, suggestions, and snide remarks.
>> 
>> 
>> When editing user info via X dialogue it doesn't prompt with a "save"
>> option like it does in ncurses.
>> 
>> Woo hoo, first to complain!
>> 
> 
> Thanks DaveR!
> 
> I'll get right on that.

Fixed in the latest download:

http://druidbsd.sf.net/download/bsdconfig/

Latest is bsdconfig.120306.txz

Preview Instructions (to get you up and running; again, requires checked-out 
src-tree):

cd /usr/src/usr.sbin
fetch http://druidbsd.sf.net/download/bsdconfig/bsdconfig.120306.txz
tar zxf bsdconfig.120306.txz
cd bsdconfig
make
sudo make install
/usr/sbin/bsdconfig -h
/usr/sbin/bsdconfig

Thanks DaveR!
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Dell R620 + H710p

[Sean Bruno]

Just a note from the "yahoo bsd" world.

In order to get the R620/720 working here, we switched out the Broadcom
ethernet device with an Intel (its a purchase option), and integrated
the project/head_mfi branch to get things working in our universe.

Sean

http://people.freebsd.org/~sbruno/r620_dmidecode.txt
http://people.freebsd.org/~sbruno/r620_pciconf.txt


signature.asc
Description: This is a digitally signed message part

Re: Graphical Terminal Environment

[Brandon Falk]

I want to learn but at the same time I want to create this graphical
terminal under the BSD license so I would be able to have an entire system
under the BSD license, with a bit better interface than 80x25 or 90x30 for
that matter. Xorg has such a large dependency base that I bet somewhere
down the line there'd be some gpl'd code, although I may be wrong.
On Mar 6, 2012 5:06 PM, "Dieter BSD"  wrote:

> Brandon writes:
> > (If you haven't noticed, I'm going to keep finding excuses to
> > write this as I really am kindof excited to learn/work on it)
>
> ideas:
>
> Display PostScript
>
> rio (from Plan 9)
>
> If you're mainly looking for a low-level graphics project,
> maybe reverse engineer something on the GPU (e.g. UVD)
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: mtree(8) reporting of file modes

[David Wolfskill]

On Tue, Mar 06, 2012 at 06:05:51PM -0500, Lowell Gilbert wrote:
> ...
> I guess the question is why do *you* find the "/set" lines to (even just
> occasionally) not be useful?
> ...

Simple: I overlooked them. :-}

Thanks for the clarification: I *thought* there might be something
fairly obvious that I had overlooked

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpLbIzaGixtJ.pgp
Description: PGP signature

Re: mtree(8) reporting of file modes

[Lowell Gilbert]

David Wolfskill  writes:

> * mode is set to the (masked) mode of the (immediately) enclosing
>   directory when it is visited in pre-order.  (This is done in statd().)

Not quite. It looks like when statd() is called on the enclosing
directory itself, it walks all of the children to find the most common
values, and issues a "/set" line to establish defaults. When it is
subsequently called for each of the children in their own right, it only
needs to list the properties that differ.

Which isn't really illogical: it substantially reduces the size of the
output (and vastly improves the readability-by-humans) in exchange for
having to traverse the list of file entries twice.

> Maybe I'm confused, but certainly for my present purposes, and likely in
> general, I'd think it would make sense to just always report the file
> mode.

> Another alternative, in case there are use cases for the existing
> behavior, would be to provide either another "key" or a command-line
> flag that says "give me all the modes".

> Am I the only one who would find such a change useful?

Well, it's definitely only useful if you're using something besides
mtree itself to parse the output file. I like having the defaults,
because most of the time all of the files in a directory have the same
permissions, and there are fewer distractions for my eye.

I guess the question is why do *you* find the "/set" lines to (even just
occasionally) not be useful?

Be well.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Graphical Terminal Environment

[Dieter BSD]

Brandon writes:
> (If you haven't noticed, I'm going to keep finding excuses to
> write this as I really am kindof excited to learn/work on it)

ideas:

Display PostScript

rio (from Plan 9)

If you're mainly looking for a low-level graphics project,
maybe reverse engineer something on the GPU (e.g. UVD)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: mtree(8) reporting of file modes

[Ian Lepore]

On Tue, 2012-03-06 at 12:41 -0800, David Wolfskill wrote:
> As I mentioned in
> , at work,
> we're trying to use mtree(8) to do reality checks on server
> configuration/provisioning.  (We are not proposing the use of mtree to
> actually enforce a particular configuration -- we are only considering
> using it to generate specification files, then check aa given system
> against those specification files.)
> 
> I had thought it odd (after running "mtree -c") that most of the entries
> in the resulting specification file failed to mention the mode of the
> file; this was the catalyst for the above-cited message.
> 
> In the mean time, I started poking at the sources.
> 
> Caveat: I'm not really a C programmer; the  bulk of my background is in
> sysadmin-type positions (though I've been doing other stuff for the last
> 4 years).
> 
> Anyway, I fairly quickly focused my attention on
> src/usr.sbin/mtree/create.c, in particular, on the statf() function
> therein.
> 
> Most of this part of the code is barely changed since 4.4 Lite; the most
> recent change to the section in question (lines 207 - 208 from the
> version in head as of r232599) was made by rgrimes@ back in 1994.
> 
> So I presume that there's something I'm overlooking or otherwise
> missing, since the folks who have been here before were certainly more
> clueful than I am.
> 
> But the code in question:
> 
> ...
> 206 }
> 207 if (keys & F_MODE && (p->fts_statp->st_mode & MBITS) != mode)
> 208 output(indent, &offset, "mode=%#o", p->fts_statp->st_mode 
> & MBITS);
> ...
> 
> is what outputs the "mode" to standard output.
> 
> Here is (the bulk of) what I found:
> 
> * The "keys & F_MODE" term merely tests to see if we are interested
>   in reporting the file mode.  (By default, we are.)
> 
> * "p->fts_statp->st_mode" refers to the "st_mode" returned from stat()
>   for the file presently being examined.
> 
> * MBITS is a mask of "mode bits" about which we care; it is defined
>   (in mtree.h) as "(S_ISUID|S_ISGID|S_ISTXT|S_IRWXU|S_IRWXG|S_IRWXO)".
>   These are defined in sys/stat.h; MBITS, thus, works out to 000.
> 
> * mode is set to the (masked) mode of the (immediately) enclosing
>   directory when it is visited in pre-order.  (This is done in statd().)
> 
> As a result, we only report the mode of a file if it differs from the
> mode of its parent directory.
> 
> Huh??!?
> 
> 
> Maybe I'm confused, but certainly for my present purposes, and likely in
> general, I'd think it would make sense to just always report the file
> mode.
> 
> A way to do that would be to change the above excerpt to read:
> 
> ...
> 206 }
> 207 if (keys & F_MODE)
> 208 output(indent, &offset, "mode=%#o", p->fts_statp->st_mode 
> & MBITS);
> ...
> 
> 
> Another alternative, in case there are use cases for the existing
> behavior, would be to provide either another "key" or a command-line
> flag that says "give me all the modes".
> 
> Am I the only one who would find such a change useful?
> 
> Thanks for any reality checks. :-}
> 
> Peace,
> david

At a glance I think the idea here is that when it outputs the directory
entry it outputs a /set line that has the directory's mode in it, and
then as it does the files in that directory it only needs to output a
mode= clause for a file if it differs from the most recent /set line.
(This is based on studying the code for about 30 seconds, so don't take
it as gospel.)

-- Ian


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

mtree(8) reporting of file modes

[David Wolfskill]

As I mentioned in
, at work,
we're trying to use mtree(8) to do reality checks on server
configuration/provisioning.  (We are not proposing the use of mtree to
actually enforce a particular configuration -- we are only considering
using it to generate specification files, then check aa given system
against those specification files.)

I had thought it odd (after running "mtree -c") that most of the entries
in the resulting specification file failed to mention the mode of the
file; this was the catalyst for the above-cited message.

In the mean time, I started poking at the sources.

Caveat: I'm not really a C programmer; the  bulk of my background is in
sysadmin-type positions (though I've been doing other stuff for the last
4 years).

Anyway, I fairly quickly focused my attention on
src/usr.sbin/mtree/create.c, in particular, on the statf() function
therein.

Most of this part of the code is barely changed since 4.4 Lite; the most
recent change to the section in question (lines 207 - 208 from the
version in head as of r232599) was made by rgrimes@ back in 1994.

So I presume that there's something I'm overlooking or otherwise
missing, since the folks who have been here before were certainly more
clueful than I am.

But the code in question:

...
206 }
207 if (keys & F_MODE && (p->fts_statp->st_mode & MBITS) != mode)
208 output(indent, &offset, "mode=%#o", p->fts_statp->st_mode & 
MBITS);
...

is what outputs the "mode" to standard output.

Here is (the bulk of) what I found:

* The "keys & F_MODE" term merely tests to see if we are interested
  in reporting the file mode.  (By default, we are.)

* "p->fts_statp->st_mode" refers to the "st_mode" returned from stat()
  for the file presently being examined.

* MBITS is a mask of "mode bits" about which we care; it is defined
  (in mtree.h) as "(S_ISUID|S_ISGID|S_ISTXT|S_IRWXU|S_IRWXG|S_IRWXO)".
  These are defined in sys/stat.h; MBITS, thus, works out to 000.

* mode is set to the (masked) mode of the (immediately) enclosing
  directory when it is visited in pre-order.  (This is done in statd().)

As a result, we only report the mode of a file if it differs from the
mode of its parent directory.

Huh??!?


Maybe I'm confused, but certainly for my present purposes, and likely in
general, I'd think it would make sense to just always report the file
mode.

A way to do that would be to change the above excerpt to read:

...
206 }
207 if (keys & F_MODE)
208 output(indent, &offset, "mode=%#o", p->fts_statp->st_mode & 
MBITS);
...


Another alternative, in case there are use cases for the existing
behavior, would be to provide either another "key" or a command-line
flag that says "give me all the modes".

Am I the only one who would find such a change useful?

Thanks for any reality checks. :-}

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpimJTsmaGQw.pgp
Description: PGP signature

Re: Graphical Terminal Environment

[Brandon Falk]

On 3/6/2012 2:52 PM, b. f. wrote:
> Brandon Falk  wrote:
>
>> I've been thinking for a while about possibly making an extremely
>> lightweight environment that supports full monitor resolution, custom
>> fonts, and terminals... that's about it.
> You may also want to look at our system libvgl ( vgl(3) ),
> ports/devel/directfb ( http://directfb.org/ ), and
> ports/graphics/svgalib ( http://www.svgalib.org/ ).  Someone has
> mentioned wayland -- there was also an older X variant called tinyX
> that is still used by some minimalistic Linux distributions, and was
> loosely based on the X.org kdrive server.
>
> b,
Thanks for all the links. I'm going to have to try some of this out. I think I
am just going to end up writing a minimal NVIDIA driver that can set the video
mode, resolution, and draw some lines for now. I've never actually worked with a
video card before, only BIOS VGA functions and framebuffers.

-Brandon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Graphical Terminal Environment

[b. f.]

Brandon Falk  wrote:

> I've been thinking for a while about possibly making an extremely
> lightweight environment that supports full monitor resolution, custom
> fonts, and terminals... that's about it.

You may also want to look at our system libvgl ( vgl(3) ),
ports/devel/directfb ( http://directfb.org/ ), and
ports/graphics/svgalib ( http://www.svgalib.org/ ).  Someone has
mentioned wayland -- there was also an older X variant called tinyX
that is still used by some minimalistic Linux distributions, and was
loosely based on the X.org kdrive server.

b,
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

AMD confirms a CPU bug

[Jung-uk Kim]

[Moving the thread from amd64@ to hackers@]

http://leaf.dragonflybsd.org/mailarchive/kernel/2012-03/msg0.html

This bug actually delayed DragonFly 3.0 release.  FYI, here is Matt's 
detailed explanation and the hack to work around the issue for GCC 
4.4:

http://gitweb.dragonflybsd.org/dragonfly.git/commit/8e32ecc0a77082f1e232a3e6d12e2f163f9667a4

Jung-uk Kim
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Graphical Terminal Environment

[Yocto]

On 2012-03-06 13:08, Brandon Falk wrote:

  Although SDL is
under the GPL still and I'd love to write mine under the BSD license.


SDL 2.0  is under zlib license.
And we use it under NetBSD without X11.

www.libsdl.org/license.php

// Yocto
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Graphical Terminal Environment

[Brandon Falk]

On 3/6/2012 1:39 PM, Mike Meyer wrote:
> On Mon, 5 Mar 2012 23:39:57 -0500
> Brandon Falk  wrote:
>
>> I've been thinking for a while about possibly making an extremely
>> lightweight environment that supports full monitor resolution, custom
>> fonts, and terminals... that's about it.
>>
>> Essentially, an x11 that only supports tiling xterms all over the place. I
>> do everything through terminals, and I think it'd be a fun project to make
>> something that's only purpose is to make it so you can use your entire
>> screen to its fullest (larger resolutions, smaller fonts, etc). Just a
>> graphical tty.
> Since no one has mentioned it, if that's all you want, then all you
> really need to do is figure out how create one max-sized terminal on
> each physical screen. The screen command (ports/sysutils/screen) will
> then let you create multiple shell sessions on each screen, including
> tiling multiple sessions on the screen. It didn't interact well with
> emacs, and emacs would do pretty much everything I wanted it to do, so
> I stopped using it a while back for that kind of thing.
>
> I also find the comment that "X is quite large" amusing, because I
> wind up comparing it to the competition (the Mac UI being the only
> other current one that runs on top of Unix), and it looks quite
> compact. You might try a custom build of X, turning off all the stuff
> you don't need, and disabling the loading of any extensions you don't
> need, and see how much you can shrink it by before tackling rewriting
> it. You may even be able to lose the requirement for a pointer.
>
> I'm also curious as to why you want the ability to draw lines,
> circles, etc. to handle an array of terminals. Screen shows that can
> be done with nothing but a CGA. It might be education, though.
>
>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Graphical Terminal Environment

[Mike Meyer]

On Mon, 5 Mar 2012 23:39:57 -0500
Brandon Falk  wrote:

> I've been thinking for a while about possibly making an extremely
> lightweight environment that supports full monitor resolution, custom
> fonts, and terminals... that's about it.
> 
> Essentially, an x11 that only supports tiling xterms all over the place. I
> do everything through terminals, and I think it'd be a fun project to make
> something that's only purpose is to make it so you can use your entire
> screen to its fullest (larger resolutions, smaller fonts, etc). Just a
> graphical tty.

Since no one has mentioned it, if that's all you want, then all you
really need to do is figure out how create one max-sized terminal on
each physical screen. The screen command (ports/sysutils/screen) will
then let you create multiple shell sessions on each screen, including
tiling multiple sessions on the screen. It didn't interact well with
emacs, and emacs would do pretty much everything I wanted it to do, so
I stopped using it a while back for that kind of thing.

I also find the comment that "X is quite large" amusing, because I
wind up comparing it to the competition (the Mac UI being the only
other current one that runs on top of Unix), and it looks quite
compact. You might try a custom build of X, turning off all the stuff
you don't need, and disabling the loading of any extensions you don't
need, and see how much you can shrink it by before tackling rewriting
it. You may even be able to lose the requirement for a pointer.

I'm also curious as to why you want the ability to draw lines,
circles, etc. to handle an array of terminals. Screen shows that can
be done with nothing but a CGA. It might be education, though.

http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [PREVIEW] bsdconfig(8)

[Ron McDowell]

Not sure this will get to -hackers, I'm not on their list.  More below...

On 3/6/12 12:10 PM, Devin Teske wrote:

3) when bsdconfig starts the note regarding the packages shouldn't state
"Pascal". most people probably don't know what pascal is. ;) how about
VirtualBox or chromium? these packages are probably used by a lot more
users.

^_^ Agreed. Ron, can we change this?

Thoughts: I'm thinking that we should name some high-visibility software here.
Say... Firefox :-D


That text was snagged verbatim from sysinstall.  I'm open to any changes 
there.



4) do we really need fdisk and disklabel? hasn't freebsd moved onto gpart
and glabel?


I've been thinking about this a lot lately.

I've been thinking that we should combine the Fdisk and DiskLabel menus into a
single menu that calls sade(8).

Thoughts?


I'd agree with that for the 10.0 version.  For 9.x I'd rather see them 
separate as that's the way they are in sysinstall.  Make sense?


--
Ron McDowell
San Antonio TX

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Graphical Terminal Environment

[Tom Evans]

On Tue, Mar 6, 2012 at 6:08 PM, Brandon Falk  wrote:
> On 3/6/2012 12:30 PM, Tom Evans wrote:
>> On Tue, Mar 6, 2012 at 4:27 PM, Brandon Falk  wrote:
>>> SDL is massive to what I plan on doing, and SDL is dependent on X11.
>>
>> Incorrect. SDL has no dependency upon X. Linux users can run SDL
>> applications directly on a framebuffer device.
>>
>> Cheers
>>
>> Tom
> According to wikipedia: "On X Window System
>  platforms, including Linux
>  and OpenVMS
> , SDL uses Xlib
>  to communicate with the X11 system for
> graphics and events."
>
> I'd have to look into that if it does work without xlib/X11. Although SDL is
> under the GPL still and I'd love to write mine under the BSD license. (If you
> haven't noticed, I'm going to keep finding excuses to write this as I really 
> am
> kindof excited to learn/work on it)
>
> -Brandon

"According to wikipedia" is the worst way to start a rebuttal!

SDL can run on many backends. When it runs on an X11 backend, it does
indeed use Xlib to communicate with X11. When it runs on Windows, or
OS X, or Linux fbdev, it does not.

Cheers

Tom
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: [PREVIEW] bsdconfig(8)

[Devin Teske]

Hi Alex,

Thanks for your feedback! Thoughts inline below...

> -Original Message-
> From: Alexander Best [mailto:arun...@freebsd.org]
> Sent: Tuesday, March 06, 2012 1:10 AM
> To: Devin Teske
> Cc: freebsd-hackers@freebsd.org; Ron McDowell
> Subject: Re: [PREVIEW] bsdconfig(8)
> 
> On Mon Mar  5 12, Devin Teske wrote:
> > Hiya fellow -hackers@
> >
> > Many have complained that bsdinstall(8) does only a fraction of
sysinstall(8).
> > This complaint is generally understood to be in-relation to the "Configure"
> menu
> > of sysinstall(8).
> >
> > Some here may already know that Ron McDowell and I have been hard  at-
> work
> > developing the replacement for sysinstall(8)'s "Configure" menu -- which we
> have
> > named bsdconfig(8).
> >
> > bsdconfig(8), together with already-existing bsdinstall(8), should fill the
> > gap(s) when sysinstall(8) goes-away in FreeBSD-10.
> >
> > bsdconfig(8) is being designed with the intention of being MFC'd to 9, so
that
> > sysinstall(8) and bsdconfig(8) can co-exist side-by-side while the bugs are
> > worked out in RELENG_9.
> >
> > Later down the road, 10.0 would have only bsdinstall(8) and bsdconfig(8)
> > (sysinstall(8) would no longer be provided).
> >
> > Thus, allowing a smooth transition away from sysinstall(8).
> >
> > With all that being said, without further ado, let me introduce the latest
> > preview:
> >
> > http://druidbsd.sf.net/download/bsdconfig/
> >
> > NOTE: As of this writing, latest version is "bsdconfig.120305.txz"
obtainable
> > from the above directory
> >
> > PRE-REQUISITES:
> >
> > You need an already-checked-out version of the FreeBSD source tree
> (preferably
> > 9.0 or higher).
> >
> > INSTRUCTIONS:
> >
> > 1. cd /usr/src

Correction... cd /usr/src/usr.sbin

> > 2. fetch
> http://druidbsd.sf.net/download/bsdconfig/bsdconfig.120305.txz
> > 3. tar zxf bsdconfig.120305.txz
> > 4. cd bsdconfig
> > 5. sudo make install
> >
> > HOW TO USE:
> >
> > bsdconfig -h
> > bsdconfig
> >
> > NOTE: If sudo(8) is installed, no need to run as root (bsdconfig will handle
> > this for you -- if/when root privileges are needed, you'll be prompted for
your
> > sudo(8) credentials).
> >
> > If you have an X11 display and have xauth(1) installed, try this in an X11
> > session:
> >
> > bsdconfig -X
> >
> > Some other things to try for fun:
> >
> > bsdconfig hostname
> > # jump directly to hostname configuration
> >
> > bsdconfig users
> > # jump directly to user management
> >
> > bsdconfig networking
> > # jump directly to network management
> >
> > bsdconfig defaultrouter
> > # jump directly to defaultrouter configuration
> >
> > bsdconfig nameservers
> > # jump directly to DNS nameserver configuration
> >
> > bsdconfig docsinstall
> > # jump directly to documentation installation
> >
> > bsdconfig timezone
> > # jump directly to timezone configuration
> >
> > bsdconfig timezone -X
> > # Configure the timezone using X11 GUI
> >
> > bsdconfig timezone -h
> > # See timezone usage (for which there are many options)
> >
> > ERRATA:
> >
> > "Documentation Installation" is fully functional
> > "Network Management" is fully functional
> > "Time Zone" is fully functional
> >
> > and
> >
> > "Login/Group Management" is mostly functional (group add/edit/delete not
> done
> > yet)
> >
> > Rest of the remaining modules are not functional yet.
> >
> > We continue to work very hard on this every day and look forward to any/all
> > feedback, comments, suggestions, and snide remarks.
> 
> great work. a few questions or rather suggestions:
> 
> 1) why are there two ways to exit bsdconfig? one being "X Exit" and the other
>one being ""?

If we change the label back to its default value of "Cancel", is it any
different? What exactly would one be cancelling (as nothing has been selected
yet)?

I rather like the renamed "Cancel" button.

Oh, and there's a lot more than 2 ways to exit bsdconfig(8):

(from the main menu)
1. Choose "Exit"
2. Select "Exit bsdconfig"
3. Press ESC on the keyboard
4. (X11-only) Click the "X" close widget
5. (bug) If TERM is set to something other than cons25, pressing SHIFT+TAB will
cause exit
6. (bug; Apple X11 only) If using X11 Forwarding to a Mac running Apple's X11
App, attempting to scroll a menu that is not scrollable with the mouse "wheel"
(including two-finger up/down gesture) will cause exit.

#5 remains as an open FreeBSD bug on the command-line and has already been filed
as PR bin/151229).

#6 remains as an open Apple bug in X11. Other bugs also exist in Apple X11 (like
the fact that pressing ENTER to dismiss a dialog causes subsequent dialogs to be
immediately dismissed as though the user is holding ENTER, though is not;
work-around is to only use the mouse when interacting with Xdialog(1) via
Apple's X11 App).

I don't see a problem with giving the user multiple w

Re: Graphical Terminal Environment

[Brandon Falk]

On 3/6/2012 12:30 PM, Tom Evans wrote:
> On Tue, Mar 6, 2012 at 4:27 PM, Brandon Falk  wrote:
>> SDL is massive to what I plan on doing, and SDL is dependent on X11.
>
> Incorrect. SDL has no dependency upon X. Linux users can run SDL
> applications directly on a framebuffer device.
>
> Cheers
>
> Tom
According to wikipedia: "On X Window System
 platforms, including Linux
 and OpenVMS
, SDL uses Xlib
 to communicate with the X11 system for
graphics and events."

I'd have to look into that if it does work without xlib/X11. Although SDL is
under the GPL still and I'd love to write mine under the BSD license. (If you
haven't noticed, I'm going to keep finding excuses to write this as I really am
kindof excited to learn/work on it)

-Brandon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Graphical Terminal Environment

[Tom Evans]

On Tue, Mar 6, 2012 at 4:27 PM, Brandon Falk  wrote:
> SDL is massive to what I plan on doing, and SDL is dependent on X11.

Incorrect. SDL has no dependency upon X. Linux users can run SDL
applications directly on a framebuffer device.

Cheers

Tom
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Graphical Terminal Environment

[Brandon Falk]

On 3/6/2012 11:19 AM, Adam Vande More wrote:
> On Tue, Mar 6, 2012 at 9:55 AM, Brandon Falk  > wrote:
>
>
> I'd plan to have it do more than just lines and dots. Pretty much anything
> you'd
> need to set up a basic interface with text, boxes, maybe circles. Just an 
> API
> similar to OpenGL for 2d graphics minus shading and lighting. Think of
> anything
> you'd need for making simple 2d apps, and I'd throw it in.
>
>
> Sounds like you are reinventing SDL.
>
>
>
> -- 
> Adam Vande More

SDL is massive to what I plan on doing, and SDL is dependent on X11. I don't
plan on making it powerful enough to really do any graphics, although I'd branch
the driver, one for minimal use in a high resolution terminal environment, and
the other could be for maybe designing a whole new future for even games and 
such.

-Brandon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Graphical Terminal Environment

[Adam Vande More]

On Tue, Mar 6, 2012 at 9:55 AM, Brandon Falk  wrote:

>
> I'd plan to have it do more than just lines and dots. Pretty much anything
> you'd
> need to set up a basic interface with text, boxes, maybe circles. Just an
> API
> similar to OpenGL for 2d graphics minus shading and lighting. Think of
> anything
> you'd need for making simple 2d apps, and I'd throw it in.
>

Sounds like you are reinventing SDL.



-- 
Adam Vande More
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Graphical Terminal Environment

[Brandon Falk]

On 3/6/2012 10:49 AM, Ian Lepore wrote:
>
> With that model and your statement that the driver should support only
> primitive functions to draw lines and dots, that leaves the non-trivial
> problem of font rendering to the app.  Given your original goal, font
> rendering is pretty much the bulk of what you want to do, is the app
> layer the right place for it?
>
> -- Ian
>
>

I'd plan to have it do more than just lines and dots. Pretty much anything you'd
need to set up a basic interface with text, boxes, maybe circles. Just an API
similar to OpenGL for 2d graphics minus shading and lighting. Think of anything
you'd need for making simple 2d apps, and I'd throw it in. I completely
understand the concept of having the app do as little of the graphics processing
as possible. I'm not sure why I didn't mention the ability to draw fonts in the
previous email. Think of a mix of ncurses simplicity for text-only apps, but
with a twist of support for primitive drawing capabilities (line and dots [text
drawing is just implied]).

-Brandon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Graphical Terminal Environment

[Ian Lepore]

On Tue, 2012-03-06 at 10:24 -0500, Brandon Falk wrote:
> On 3/6/2012 11:05 AM, per...@pluto.rain.com wrote:
> > Brandon Falk  wrote:
> >
> >> I havent tried tmux yet, but on my system im only able to get
> >> 80x40 with vidcontrol on one monitor. But with xterm in xorg
> >> i can get 319x89 per monitor ...
> >
> > To get higher resolution than what vidcontrol provides, you'll most
> > likely need to run the display in graphic mode (which is what X11
> > does) rather than in text mode.  That means that you will need to
> > either use, or reinvent, the lowest levels of X (display driver,
> > window mapping) and at least part of the xterm/rxvt application
> > (terminal emulation, font rasterizing, perhaps scrolling).  You
> > could, however, eliminate the X practice of using the network to
> > connect the terminal emulator to the display; this would give you
> > an architecture resembling SunView (and its predecessor, SunTools).
> >
> > I _think_ SunTools/SunView were proprietary, although it's possible
> > that Sun released the source code at some point.  You could try
> > doing some research with Google and/or the Internet Archive.
> 
> That's pretty much my plan. To write some lower level drivers to put the 
> system
> in a graphics mode. I have 4 monitors and there is no other way to get 
> multiple
> monitors without a GPU specific driver (at least from my VGA OSDev 
> experience).
> My goal will be to make a driver that will be able to be runnable by any other
> driver easily. Instead of having to use Xorg, just calls to the video driver 
> to
> set the mode to graphics, then some primitive functions to draw lines and 
> dots.
> 
> I don't see why Xorg should dominate the drivers completely, I really wish it
> was a matter of having an open, well documented, easy to use API that you can
> just give direct commands to.
> 
> >From my understanding, this is the current model:
> 
> [  Apps   ]
> |
> v
> [  Xorg   ]
> |
> v
> [  Driver ]
> |
> v
> [  GPU]
> 
> I think it should be the following:
> 
> [ Apps ]
>|
>v
> [ Xorg ]   [ Apps ]
>|  |
>v  v
> [Driver  ]
>|
>v
> [  GPU   ]
> 
> Does this make sense to anyone else? I really want to get this idea across
> because I think it would be really beneficial.
> 
> -Brandon

With that model and your statement that the driver should support only
primitive functions to draw lines and dots, that leaves the non-trivial
problem of font rendering to the app.  Given your original goal, font
rendering is pretty much the bulk of what you want to do, is the app
layer the right place for it?

-- Ian


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: watching for a directory with kqueue

[John Baldwin]

On Monday, March 05, 2012 1:12:55 pm Sergey Matveychuk wrote:
> Hi.
> 
> I've met a problem with the subj. Could you help?
> 
> I'm watching for a directory:
>  EV_SET(kq_change_list, fd, EVFILT_VNODE,
>  EV_ADD | EV_ENABLE | EV_ONESHOT,
>  NOTE_DELETE | NOTE_WRITE | NOTE_EXTEND | NOTE_ATTRIB,
>  0, 0);
> 
> When the directory changed, I read its contens with opendir, like that:
> struct kq_event kq_event[1000];
> ...
> while(1) {
>  n = kevent(kq, kq_change_list, chlist_used, kq_event, 1000, NULL);
>   for(i = 0; i < n; i++) {
>   if(kq_event[i].fflags & NOTE_EXTEND || kq_event[i].fflags & 
NOTE_WRITE) {
>   opendir(.)
> 
> It works when I create a few files (1-3), but when I create 10 files 
> with touch(1) I see only 3-6 files with opendir. I've got only one event 
> with kevent() (n=1). Looks like I should got a few events, but I did 
> not. Could you give an advice how to get all created files?

The problem is your kevent can fire after just one file is created, so you
can run opendir() before all 10 files are created.  If you want the keven to 
keep firing, you need to not use EV_ONESHOT.  Instead, you probably want to
use EV_CLEAR.  That would let you get multiple events for the directory, and 
by the last one, all 10 files should be present.

-- 
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD-9 crash at swapctl -d

[John Baldwin]

On Monday, March 05, 2012 3:32:22 am Wojciech Puchar wrote:
> repeatable crash when turning off my 9GB swap partition (of which 0 bytes 
> was used):
> 
> Dump header from device /dev/ada0b
>   Architecture: amd64
>   Architecture Version: 2
>   Dump Length: 198971392B (189 MB)
>   Blocksize: 512
>   Dumptime: Mon Mar  5 09:29:41 2012
>   Hostname: wojtek.tensor.gdynia.pl
>   Magic: FreeBSD Kernel Dump
>   Version String: FreeBSD 9.0-STABLE #0: Sun Mar  4 22:58:17 CET 2012
> r...@wojtek.tensor.gdynia.pl:/usr/src/sys/amd64/compile/wojtek
>   Panic String: blist_meta_fill: allocation too large
>   Dump Parity: 606467164
>   Bounds: 0
>   Dump Status: good

Can you fire up kgdb on the crash dump and get a stack trace?  Can you also go 
to the frame for 'blist_meta_fill' and do 'p count' and 'p radix'?

-- 
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: CPUID and CPU STATE

[John Baldwin]

On Tuesday, March 06, 2012 2:16:03 am Maninya M wrote:
> Thank you.
> How do we get hardware cpuid?
> Can we change the number of CPUs available to the scheduler (in the
> scheduler code) dynamically, say completely cutting off a specific cpu core
> from being used at all?

The hardware cpuid is machine-dependent.  If you are in the kernel, you can 
use PCPU_GET(apic_id) on x86 to get the local APIC ID.  Other platforms have a 
similar per-CPU variable.  As far as getting it from userland, we do not have 
a good way of getting it currently aside from scraping /var/run/dmesg.boot or 
using libkvm to grovel around in kernel variables.

As far as offlining a CPU, we do not have a way to do that currently (though
you can take it out of the default cpuset which will prevent user threads from
using it).
 
> On 5 March 2012 22:51, John Baldwin  wrote:
> 
> > On Friday, March 02, 2012 2:20:00 am Maninya M wrote:
> > > I was unable to get this information about the cpuid variable in the
> > > scheduler source code.
> > > How does cpuid get its value from the hardware?
> >
> > The cpuid is a software ID value assigned during boot.  It is not
> > directly related to any specific hardware IDs.
> >
> > > How is the CPUSTATES value obtained/changed with  hardware in the source
> > > code?
> >
> > Do you mean, does cp_time[] handle hardware changes (hotplug CPUs, etc.)?
> > Currently that isn't supported, the kernel assumes the set of CPUs is
> > static for a given boot's lifetime.
> >
> > --
> > John Baldwin
> >
> 
> 
> 
> -- 
> Maninya
> 

-- 
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Graphical Terminal Environment

[Brandon Falk]

On 3/6/2012 11:05 AM, per...@pluto.rain.com wrote:
> Brandon Falk  wrote:
>
>> I havent tried tmux yet, but on my system im only able to get
>> 80x40 with vidcontrol on one monitor. But with xterm in xorg
>> i can get 319x89 per monitor ...
>
> To get higher resolution than what vidcontrol provides, you'll most
> likely need to run the display in graphic mode (which is what X11
> does) rather than in text mode.  That means that you will need to
> either use, or reinvent, the lowest levels of X (display driver,
> window mapping) and at least part of the xterm/rxvt application
> (terminal emulation, font rasterizing, perhaps scrolling).  You
> could, however, eliminate the X practice of using the network to
> connect the terminal emulator to the display; this would give you
> an architecture resembling SunView (and its predecessor, SunTools).
>
> I _think_ SunTools/SunView were proprietary, although it's possible
> that Sun released the source code at some point.  You could try
> doing some research with Google and/or the Internet Archive.

That's pretty much my plan. To write some lower level drivers to put the system
in a graphics mode. I have 4 monitors and there is no other way to get multiple
monitors without a GPU specific driver (at least from my VGA OSDev experience).
My goal will be to make a driver that will be able to be runnable by any other
driver easily. Instead of having to use Xorg, just calls to the video driver to
set the mode to graphics, then some primitive functions to draw lines and dots.

I don't see why Xorg should dominate the drivers completely, I really wish it
was a matter of having an open, well documented, easy to use API that you can
just give direct commands to.

>From my understanding, this is the current model:

[  Apps   ]
|
v
[  Xorg   ]
|
v
[  Driver ]
|
v
[  GPU]

I think it should be the following:

[ Apps ]
   |
   v
[ Xorg ]   [ Apps ]
   |  |
   v  v
[Driver  ]
   |
   v
[  GPU   ]

Does this make sense to anyone else? I really want to get this idea across
because I think it would be really beneficial.

-Brandon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Graphical Terminal Environment

[Kurt Lidl]

On Tue, Mar 06, 2012 at 08:05:40AM -0800, per...@pluto.rain.com wrote:
> Brandon Falk  wrote:
> 
> > I havent tried tmux yet, but on my system im only able to get
> > 80x40 with vidcontrol on one monitor. But with xterm in xorg
> > i can get 319x89 per monitor ...
> 
> To get higher resolution than what vidcontrol provides, you'll most
> likely need to run the display in graphic mode (which is what X11
> does) rather than in text mode.  That means that you will need to
> either use, or reinvent, the lowest levels of X (display driver,
> window mapping) and at least part of the xterm/rxvt application
> (terminal emulation, font rasterizing, perhaps scrolling).  You
> could, however, eliminate the X practice of using the network to
> connect the terminal emulator to the display; this would give you
> an architecture resembling SunView (and its predecessor, SunTools).
> 
> I _think_ SunTools/SunView were proprietary, although it's possible
> that Sun released the source code at some point.  You could try
> doing some research with Google and/or the Internet Archive.

I don't think they ever released that code.

If you want re-use the lowest levels of the X11 drivers, you ought
to check out the "Wayland" project.  http://wayland.freedesktop.org

-Kurt

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Graphical Terminal Environment

[Alex Kozlov]

On Tue, Mar 06, 2012 at 12:37:32PM +, RW wrote:
> BTW does anyone know what the character at the end of the size field is
> in the "vidcontrol -i mode" output, I'm seeing "D","P" or "4" on the
> graphics modes.
It's video memory model:
$num - planar, $num - number of planes
C- GCA graphics
D- Direct 15/16/24 bit
H- Hercules Graphics
P- Packed pixels
V- VGA mode X


--
Adios
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: watching for a directory with kqueue

[Sergey Matveychuk]

06.03.2012 0:57, Markiyan Kushnir wrote:

On 05.03.2012 20:12, Sergey Matveychuk wrote:

Hi.

I've met a problem with the subj. Could you help?

I'm watching for a directory:
EV_SET(kq_change_list, fd, EVFILT_VNODE,
EV_ADD | EV_ENABLE | EV_ONESHOT,
NOTE_DELETE | NOTE_WRITE | NOTE_EXTEND | NOTE_ATTRIB,
0, 0);

When the directory changed, I read its contens with opendir, like that:
struct kq_event kq_event[1000];
...
while(1) {
n = kevent(kq, kq_change_list, chlist_used, kq_event, 1000, NULL);
for(i = 0; i < n; i++) {
if(kq_event[i].fflags & NOTE_EXTEND || kq_event[i].fflags & NOTE_WRITE) {
opendir(.)

It works when I create a few files (1-3), but when I create 10 files
with touch(1) I see only 3-6 files with opendir. I've got only one event
with kevent() (n=1). Looks like I should got a few events, but I did
not. Could you give an advice how to get all created files?


Try to put some delay (~10ms) after your call to kevent().



Not enough smooth for me, but works.

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Graphical Terminal Environment

[RW]

On Tue, 6 Mar 2012 10:31:49 +0100
Björn Oelke wrote:

> Am 06.03.2012 um 06:48 schrieb Brandon Falk:
> > I havent tried tmux yet, but on my system im only able to get 80x40
> > with vidcontrol on one monitor. But with xterm in xorg i can get
> > 319x89 per monitor. Until i get about half of that, i wont be
> > convinced to use something existing. Anyways, I'm off to sleep.
> 
> 
> Have you tried VESA's SC_PIXEL_MODE? It's a kernel option and IIRC it
> works on amd64 since 8.1. `vidcontrol MODE_282` gave me 1280x1024
> pixels. But to be honest, this was about two years ago.

Since I did this recently, you need to build with 

options VESA
options SC_PIXEL_MODE

Then run vidcontrol -i mode to get a list of modes. Choose one and
then run vidcontrol with something like:

-g 160x64 MODE_283

where 160x64 comes from dividing the mode's font size into its
resolution. You can make that automatic by adding

allscreens_flags="-h 2000 -g 160x64 MODE_283"

to rc.conf

BTW does anyone know what the character at the end of the size field is
in the "vidcontrol -i mode" output, I'm seeing "D","P" or "4" on the
graphics modes.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Graphical Terminal Environment

[Björn Oelke]

Am 06.03.2012 um 06:48 schrieb Brandon Falk:
> I havent tried tmux yet, but on my system im only able to get 80x40 with
> vidcontrol on one monitor. But with xterm in xorg i can get 319x89 per
> monitor. Until i get about half of that, i wont be convinced to use
> something existing. Anyways, I'm off to sleep.


Have you tried VESA's SC_PIXEL_MODE? It's a kernel option and IIRC it works on 
amd64 since 8.1.
`vidcontrol MODE_282` gave me 1280x1024 pixels. But to be honest, this was 
about two years ago.

-- 
BO .. http://kbct.de
PS: Moin.

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Graphical Terminal Environment

[perryh]

Brandon Falk  wrote:

> I havent tried tmux yet, but on my system im only able to get
> 80x40 with vidcontrol on one monitor. But with xterm in xorg
> i can get 319x89 per monitor ...

To get higher resolution than what vidcontrol provides, you'll most
likely need to run the display in graphic mode (which is what X11
does) rather than in text mode.  That means that you will need to
either use, or reinvent, the lowest levels of X (display driver,
window mapping) and at least part of the xterm/rxvt application
(terminal emulation, font rasterizing, perhaps scrolling).  You
could, however, eliminate the X practice of using the network to
connect the terminal emulator to the display; this would give you
an architecture resembling SunView (and its predecessor, SunTools).

I _think_ SunTools/SunView were proprietary, although it's possible
that Sun released the source code at some point.  You could try
doing some research with Google and/or the Internet Archive.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [PREVIEW] bsdconfig(8)

[Alexander Best]

On Mon Mar  5 12, Devin Teske wrote:
> Hiya fellow -hackers@
> 
> Many have complained that bsdinstall(8) does only a fraction of sysinstall(8).
> This complaint is generally understood to be in-relation to the "Configure" 
> menu
> of sysinstall(8).
> 
> Some here may already know that Ron McDowell and I have been hard  at-work
> developing the replacement for sysinstall(8)'s "Configure" menu -- which we 
> have
> named bsdconfig(8).
> 
> bsdconfig(8), together with already-existing bsdinstall(8), should fill the
> gap(s) when sysinstall(8) goes-away in FreeBSD-10.
> 
> bsdconfig(8) is being designed with the intention of being MFC'd to 9, so that
> sysinstall(8) and bsdconfig(8) can co-exist side-by-side while the bugs are
> worked out in RELENG_9.
> 
> Later down the road, 10.0 would have only bsdinstall(8) and bsdconfig(8)
> (sysinstall(8) would no longer be provided).
> 
> Thus, allowing a smooth transition away from sysinstall(8).
> 
> With all that being said, without further ado, let me introduce the latest
> preview:
> 
> http://druidbsd.sf.net/download/bsdconfig/
> 
> NOTE: As of this writing, latest version is "bsdconfig.120305.txz" obtainable
> from the above directory
> 
> PRE-REQUISITES:
> 
> You need an already-checked-out version of the FreeBSD source tree (preferably
> 9.0 or higher).
> 
> INSTRUCTIONS:
> 
>   1. cd /usr/src
>   2. fetch http://druidbsd.sf.net/download/bsdconfig/bsdconfig.120305.txz
>   3. tar zxf bsdconfig.120305.txz
>   4. cd bsdconfig
>   5. sudo make install
> 
> HOW TO USE:
> 
>   bsdconfig -h
>   bsdconfig
> 
> NOTE: If sudo(8) is installed, no need to run as root (bsdconfig will handle
> this for you -- if/when root privileges are needed, you'll be prompted for 
> your
> sudo(8) credentials).
> 
> If you have an X11 display and have xauth(1) installed, try this in an X11
> session:
> 
>   bsdconfig -X
> 
> Some other things to try for fun:
> 
>   bsdconfig hostname
>   # jump directly to hostname configuration
> 
>   bsdconfig users
>   # jump directly to user management
> 
>   bsdconfig networking
>   # jump directly to network management
> 
>   bsdconfig defaultrouter
>   # jump directly to defaultrouter configuration
> 
>   bsdconfig nameservers
>   # jump directly to DNS nameserver configuration
> 
>   bsdconfig docsinstall
>   # jump directly to documentation installation
> 
>   bsdconfig timezone
>   # jump directly to timezone configuration
> 
>   bsdconfig timezone -X
>   # Configure the timezone using X11 GUI
> 
>   bsdconfig timezone -h
>   # See timezone usage (for which there are many options)
> 
> ERRATA:
> 
> "Documentation Installation" is fully functional
> "Network Management" is fully functional
> "Time Zone" is fully functional
> 
> and
> 
> "Login/Group Management" is mostly functional (group add/edit/delete not done
> yet)
> 
> Rest of the remaining modules are not functional yet.
> 
> We continue to work very hard on this every day and look forward to any/all
> feedback, comments, suggestions, and snide remarks.

great work. a few questions or rather suggestions:

1) why are there two ways to exit bsdconfig? one being "X Exit" and the other
   one being ""?
2) the highlighted first letters suggest that these are shortcuts. they work
   great for the actual menu items, but for "" and "",
   pressing O and E doesn't work. in fact E is already taken by "Startup".
3) when bsdconfig starts the note regarding the packages shouldn't state
   "Pascal". most people probably don't know what pascal is. ;) how about
   VirtualBox or chromium? these packages are probably used by a lot more
   users.
4) do we really need fdisk and disklabel? hasn't freebsd moved onto gpart
   and glabel?

cheers.
alex

> -- 
> Cheers,
> Devin
> 
> _
> The information contained in this message is proprietary and/or confidential. 
> If you are not the intended recipient, please: (i) delete the message and all 
> copies; (ii) do not disclose, distribute or use the message in any manner; 
> and (iii) notify the sender immediately. In addition, please be aware that 
> any message addressed to our domain is subject to archiving and review by 
> persons other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"