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 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 Exit bsdconfig? 2) the highlighted first letters suggest that these are shortcuts. they work great for the actual menu items, but for OK and Exit bsdconfig, 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
Re: Graphical Terminal Environment
Brandon Falk bfalk_...@brandonfa.lk 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: Graphical Terminal Environment
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
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: watching for a directory with kqueue
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
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: Graphical Terminal Environment
On Tue, Mar 06, 2012 at 08:05:40AM -0800, per...@pluto.rain.com wrote: Brandon Falk bfalk_...@brandonfa.lk 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
On 3/6/2012 11:05 AM, per...@pluto.rain.com wrote: Brandon Falk bfalk_...@brandonfa.lk 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: CPUID and CPU STATE
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 j...@freebsd.org 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: FreeBSD-9 crash at swapctl -d
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: watching for a directory with kqueue
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: Graphical Terminal Environment
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 bfalk_...@brandonfa.lk 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: Graphical Terminal Environment
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
On Tue, Mar 6, 2012 at 9:55 AM, Brandon Falk bfalk_...@brandonfa.lk 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
On 3/6/2012 11:19 AM, Adam Vande More wrote: On Tue, Mar 6, 2012 at 9:55 AM, Brandon Falk bfalk_...@brandonfa.lk mailto:bfalk_...@brandonfa.lk 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
On Tue, Mar 6, 2012 at 4:27 PM, Brandon Falk bfalk_...@brandonfa.lk 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
On 3/6/2012 12:30 PM, Tom Evans wrote: On Tue, Mar 6, 2012 at 4:27 PM, Brandon Falk bfalk_...@brandonfa.lk 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 https://en.wikipedia.org/wiki/X_Window_System platforms, including Linux https://en.wikipedia.org/wiki/Linux and OpenVMS https://en.wikipedia.org/wiki/OpenVMS, SDL uses Xlib https://en.wikipedia.org/wiki/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: [PREVIEW] bsdconfig(8)
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 Exit bsdconfig? 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 ways out (and labeling each correctly as such). 2) the highlighted first letters suggest that these are shortcuts. they work great for the actual menu items, but for OK and Exit bsdconfig, pressing O and E doesn't work. in
Re: Graphical Terminal Environment
On Tue, Mar 6, 2012 at 6:08 PM, Brandon Falk bfalk_...@brandonfa.lk wrote: On 3/6/2012 12:30 PM, Tom Evans wrote: On Tue, Mar 6, 2012 at 4:27 PM, Brandon Falk bfalk_...@brandonfa.lk 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 https://en.wikipedia.org/wiki/X_Window_System platforms, including Linux https://en.wikipedia.org/wiki/Linux and OpenVMS https://en.wikipedia.org/wiki/OpenVMS, SDL uses Xlib https://en.wikipedia.org/wiki/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)
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
On Mon, 5 Mar 2012 23:39:57 -0500 Brandon Falk bfalk_...@brandonfa.lk 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. mike -- Mike Meyer m...@mired.org 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: Graphical Terminal Environment
On 3/6/2012 1:39 PM, Mike Meyer wrote: On Mon, 5 Mar 2012 23:39:57 -0500 Brandon Falk bfalk_...@brandonfa.lk 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. mike You seem to understand exactly want I want. Just small font terminals on all screens, and I was actually thinking `screen` would do the trick for the splitting/management of them. As for stripping down X, I might do so as a proof of concept, but in the end I want to develop my own for my own learning. When I mention lines, circles, etc I was thinking moreso at the very low level of fonts being drawn by lines and dots (although I would like to branch it eventually to support 2d graphics where people could maybe make some 2d games, but keep the high-res terminal on the side to keep it minimal). I also may want to draw some lines to border terminal windows (screen would eliminate this obviously). -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
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
AMD confirms a CPU bug
[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
Brandon Falk bfalk_bsd at brandonfa.lk 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
Re: Graphical Terminal Environment
On 3/6/2012 2:52 PM, b. f. wrote: Brandon Falk bfalk_bsd at brandonfa.lk 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
mtree(8) reporting of file modes
As I mentioned in http://docs.FreeBSD.org/cgi/mid.cgi?20120306000520.GS1519, 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: mtree(8) reporting of file modes
On Tue, 2012-03-06 at 12:41 -0800, David Wolfskill wrote: As I mentioned in http://docs.FreeBSD.org/cgi/mid.cgi?20120306000520.GS1519, 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
Re: Graphical Terminal Environment
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
David Wolfskill da...@catwhisker.org 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: mtree(8) reporting of file modes
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: Graphical Terminal Environment
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 dieter...@engineer.com 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
Dell R620 + H710p
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: [PREVIEW] bsdconfig(8)
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
