Re: Fwd: GSOC: Qt front-ends
On Wed, Apr 24, 2013 at 5:43 AM, Lars Engels lars.eng...@0x20.net wrote: Am 24.04.2013 13:44, schrieb Chris Rees: Our kernel is actually very easy to configure, so I'm not convinced that it's needed; you may be thinking of Linux's menuconfig, but I think that is because of the complexity. It _is_ easy. But having a nice graphical tool which draws a pretty table of GENERIC and NOTES together with useful information about the possible options and devices would be a handy thing to have IMHO. Let's make FreeBSD userfriendly :-) Especially if it handles dependencies! For example, check USB Disk Support, and have scbus, da, etc enabled automatically. Or having the LIBICONV stuff enabled if you add MSDOSFS support. And so on. That part of kernel configuration (keeping track of what devices require which options and other devices) is currently the hardest part for newbies (and even for some seasoned kernel compilers!). Yes, the output of config KERNELNAME or buildkernel KERNCONF=KERNELNAME will tell you about missing dependencies, but it breaks automated compile/install processes. Having the create kernel config file step take care of dependencies would be nice. -- Freddie Cash fjwc...@gmail.com ___ 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: GSOC: Qt front-ends
On Wed, Apr 24, 2013 at 9:18 AM, Tony Li tony...@tony.li wrote: On Apr 24, 2013, at 5:43 AM, Lars Engels lars.eng...@0x20.net wrote: It _is_ easy. But having a nice graphical tool which draws a pretty table of GENERIC and NOTES together with useful information about the possible options and devices would be a handy thing to have IMHO. Let's make FreeBSD userfriendly :-) Side note: I agree that we would really, really like FreeBSD more user friendly. However, is kernel configuration where we really want to start? Just how much of the user base reconfigures their kernels, anyway? Wouldn't effort be better spent on making normal installation, maintenance and deployment clean and easy? Mostly off-topic for this thread, but improving the boot process to auto-detect hardware and auto-load kernel modules would be really nice. That way, GENERIC would be very small, with just the basic frameworks required (CAM, USB, PCI, TCP/IP, etc), and all the actual drivers would be loaded from modules. That would remove almost all requirements to compile a custom kernel in the first place. :) Granted, changing options in the kernel would require recompilation, but general use and hardware changes wouldn't. Most likely not a GSoC project. But it's still a nice dream. :) -- Freddie Cash fjwc...@gmail.com ___ 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: GSOC: Qt front-ends
On Wed, Apr 24, 2013 at 11:03 AM, Justin Edward Muniz justin.mu...@maine.edu wrote: I think the interface to pkgng and freebsd-update are still interesting; at least more worthwhile than the kernel configuration one. I think the pkgng one has the edge, since packages are updated far more often than base, and it's easier to track base. Now you are at a stage where you should make your own decision; which one looks the most interesting to you? Once you decide on an area of interest, you can just start hacking :) Chris That's good to hear. I am sure that you are right, a pkgng GUI would probably see more use in general. I am definitely close to making my decision, but this thread has been so much help, I am glad for the insight. The coding is what I look forward to the most :D You'll probably want to get in touch with the PC-BSD folks. As they are moving to pkgng for everything, they are updating their Python-based GUIs to work with it. Might be a possibility to work together, or to build off what they have, or to get ideas/inspiration for a more general tool. For example, (going from memory of my home PC-BSD install) the System Update or System Manager tool uses pkgng behind the scenes, and provides a tree-based view of PC-BSD-specific packages that can be installed via simply ticking checkboxes and hitting Install button. And, they have a ports-based GUI tool as well, although I have not used it as yet so couldn't tell you what it supports. I do my ports-based installs via a terminal. :) -- Freddie Cash fjwc...@gmail.com ___ 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: NUMA, cpuset and malloc
On Mon, Apr 22, 2013 at 8:32 AM, John Baldwin j...@freebsd.org wrote: On Saturday, April 20, 2013 6:43:26 pm Robert Waksmundzki wrote: On NUMA systems allocated memory is striped across local and non-local banks in order to have consistent performance in case the task is rescheduled to a different CPU socket. When a process is pinned to a single CPU socket with cpuset having the memory allocator prefer local banks would probably improve performance. Default system behavior would stay the same and the optimization would only be triggered on big multi socket systems when administrator used cpuset (command mostly used for performance optimization anyway). Is this something currently implemented in FreeBSD? Is this even a good idea? You can get something sort of like this by enabling NUMA in your kernel (9.0 and later) and always pinning your processes with cpuset. (The simple NUMA bits always allocate memory in the memory domain the current thread is running in at the time of the fault.) How does one enable NUMA? A grep -i numa /usr/src/sys/conf/NOTES /usr/src/sys/amd64/conf/NOTES turns up 0 hits for both 9-STABLE r248547 and 10-CURRENT (April 11, used svnup so no way to get the exact revision number, that I know of). Or, is it enabled automatically? -- Freddie Cash fjwc...@gmail.com ___ 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: GSOC 2013 project Kernel Size Reduction for Embedded System
You have to look at the in-memory sizes, not the on-disk sizes. Linux kernels are very barebones when it comes to what is compiled directly into the kernel image on disk. Everything else is loaded from modules at boot time. Especially if using distro-provided kernels. They even use ram disks / initrds to get around the can't boot without drivers for Y, but Y is a module and not loaded at boot, adding extra memory pressure that's not shown in the on-disk size of the kernel image file. FreeBSD kernels tend to be the opposite, with everything compiled directly into the kernel image on-disk, and very little actually being loaded via modules. At least GENERIC, anyway. You would need to manually compile kernels with the same sets of drivers on each system, in order to do a proper comparison of on-disk sizes. Or, look at in-memory stats for the two, once the systems are booted, all modules are loaded, and the system is ready for use. Just comparing ls output of default FreeBSD/Linux installs isn't useful in any way. -- Freddie Cash fjwc...@gmail.com ___ 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: Seeking an extended-support O/S similar to FreeBSD
I'm confused. Every other minor release of FreeBSD is supported for 2 full years, with no new features added, just security fixes (aka Extended Releases). And every major release of FreeBSD is supported for at least 4, somtimes 5, years. Canonical just shortened their support for LTS to 3 years, including server releases. And you can't get new versions of software on Ubuntu without upgrading the OS or adding random PPA repos. Sometimes you can get a backports repo, but they aren't officially supported. And only the official repos get security updates (if you're lucky). RedHat isn't much better. Sure, they'll support the core OS for 5 years, but you can't install new, up-to-date software on it unless you upgrade the entire OS (been down that road too many times to ever want to try again). We gave up on RedHat after fighting with 2.x, 3.x, and 4.x. FreeBSD isn't perfect (what OS is?), but it's amazing that you can install the newest versions of MySQL, Firefox, KDE, Postfix, etc on 7.4 (until the end of Feb, anyway), or 8.3, or 9.0, or 9.1. And can continue to get security fixes for all those releases (except 7.x now). Good luck installing any of those onto a Linux release from 2-3 years ago. What's missing from FreeBSD support? ___ 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: Is there a way to prioritize disk operations ?
man gsched On Tue, Jan 15, 2013 at 12:09 PM, Yuri y...@rawbw.com wrote: Currently one can set nice value to the process. But it only affects the CPU scheduling, so if this process is CPU bound it would yield to others. What if the process is disk-bound, like some backup operations? The backup copying large disk seriously affects performance of all other apps accessing the same disk. Is there a way to set the priority value on the process for the disk operations, so that all disk operations originating from the process will be scheduled in similar way how CPU is scheduled based on the nice value of the process? The disk-intense backup process with low disk priority won't affect the other processes at all. Yuri __**_ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackershttp://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscribe@** freebsd.org freebsd-hackers-unsubscr...@freebsd.org -- Freddie Cash fjwc...@gmail.com ___ 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: Vice versa of 'pkg_info -W'
That tells you which installed port owns /usr/local/bin/foo. It doesn't tell you which NOT-installed port would install /usr/local/bin/foo, which is what the OP is wanting. On Thu, Jan 3, 2013 at 9:23 AM, Daniel Eischen deisc...@freebsd.org wrote: On Thu, 3 Jan 2013, Lars Engels wrote: Am 02.01.2013 18:55, schrieb rank1see...@gmail.com: For example: # pkg_info -W /usr/local/bin/lynx /usr/local/bin/lynx was installed by package lynx-2.8.7.2,1 # pkg_deinstall lynx-2.8.7.2,1 # pkg_info -W /usr/local/bin/lynx pkg_info: /usr/local/bin/lynx: file cannot be found As you can figure it out, I want a reverse method, that is ... If I want to have '/usr/local/bin/lynx' installed, which port origin(s), would install it? I use porgle for that: http://www.secnetix.de/tools/**porgle/porgle.pyhttp://www.secnetix.de/tools/porgle/porgle.py For non-pkgng, what's wrong with pkgdb and pkg_which (portupgrade)? # pkgdb -o `pkg_which /usr/local/bin/foo` And for pkgng: # pkg which -o /usr/local/bin/foo Or am I missing something? -- DE __**_ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackershttp://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscribe@** freebsd.org freebsd-hackers-unsubscr...@freebsd.org -- Freddie Cash fjwc...@gmail.com ___ 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: OT: getting named to answer differently based on requester's IP
You want to set up views and IP-based ACLs. There's lots of documentation online about configuring views. Basically, they work exactly how you want: - clients with IPs in 192.168.2.x subnet get 192.168.2.x replies - all other clients get public IP replies On Wed, Jan 2, 2013 at 2:33 PM, Aryeh Friedman aryeh.fried...@gmail.comwrote: I have a local machine (say foo.example.com) that is behind a very dumb firewall (it will not honor dmz/port forwarding if the connection originates from inside the firewall [192.168.2.X]) specifically if I connect to the public IP from *OUTSIDE* of the lan it works but not from inside... I have a number of web services that depend on a specific DNS being set (specifically www/tomcat7 and the alike)... i.e. if I am at home I need to use localhost (changing it in /etc/hosts has no effect) if I am away I need to use ack.example.com)... what I want to do is make it so I can use ack.example.com for all references... this means I need to make it so local requests to ack.example.com answer 192.168.2.2 and remote ones answer the public IP.. how do I configure named to do this (I have full control of all the nameservers in question) ___ 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 -- Freddie Cash fjwc...@gmail.com ___ 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: Providing a default graphical environment on FreeBSD
On Mon, Sep 17, 2012 at 10:51 AM, Lorenzo Cogotti miciam...@hotmail.it wrote: Il 17/09/2012 19:26, Adrian Chadd ha scritto: What are you trying to achieve? Right now I was interested in creating a desktop oriented automounter, in order to experiment with devd (I don't know if something useful will actually come out of it). I then faced the problem that there are lots of GUI toolkits, lots of scenarios to take into account, lots of desktop environments available, basically the problem is the same that Linux has with its non existing userland. Have you seen this: http://forums.freebsd.org/showthread.php?t=29895 -- Freddie Cash fjwc...@gmail.com ___ 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: Providing a default graphical environment on FreeBSD
On Mon, Sep 17, 2012 at 12:50 PM, Steffen Daode sdao...@gmail.com wrote: | Hi, | I was wondering about the possibility of FreeBSD to provide an official | supported graphical environment. What i really miss compared to 4.* and 5.3 (and compared to NetBSD and OpenBSD) is that there is a single package with a known name that can be downloaded and unpacked and you have a X11 environment to go. I have not searched the archives for the when and why of the decision to drop it. But its absence really hurts me. Rant and rave to the Xorg developers. With the release of Xorg 7 they broke it up into a bazillion separate packages, each with their own development cycle, releases, packaging, etc. Xorg releases are now nothing more than a snapshot of the various sub-packages that's slightly bug/beta tested together. There's really no difference between Xorg development and Linux distro development. :( There's really nothing that FreeBSD devs can do about this unless they want to fork Xorg completely. -- Freddie Cash fjwc...@gmail.com ___ 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: Training wheels for commandline (was Re: Pull in upstream before 9.1 code freeze?)
On Thu, Jul 5, 2012 at 9:45 AM, Damien Fleuriot m...@my.gd wrote: On 7/5/12 6:38 PM, Wojciech Puchar wrote: inexperienced users. Having to enable it manually defeats its very purpose. so is FreeBSD future direction to be moron-OS just like linux is now, or is that just another stupid idea on that forum that came and... will pass? Quite important. There are still people that want normal OS. Just because you don't like the idea doesn't make it stupid, and just because it comes from linux doesn't make it bad. The -p flag to netstat comes from linux and I would dearly like to see it on BSD, for example. Well, technically FreeBSD's netstat already has -p (which can be used to get the same result as -t or -u on Linux). ;) And you can get the same info from sockstat -P tcp as Linux netstat -tp. But, yeah, netstat -antp is much easier to type than netstat -an -p tcp; sockstat -P tcp. :) -- Freddie Cash fjwc...@gmail.com ___ 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: Pull in upstream before 9.1 code freeze?
On Wed, Jul 4, 2012 at 9:51 AM, Simon L. B. Nielsen si...@freebsd.org wrote: On Tue, Jul 3, 2012 at 9:39 PM, Doug Barton do...@freebsd.org wrote: On 07/03/2012 05:39, Dag-Erling Smørgrav wrote: Doug Barton do...@freebsd.org writes: The correct solution to this problem is to remove BIND from the base altogether, but I have no energy for all the whinging that would happen if I tried (again) to do that. I don't think there will be as much whinging as you expect. Times have changed. I'm willing to import and maintain unbound (BSD-licensed validating, recursive, and caching DNS resolver) if you remove BIND. You've got a deal! Unbound requires ldns, which is a good thing. Part of this project would How's the security support for ldns / unbound? For third party software sitting in the 'frontline' that part is rather important. also be to enable drill so that we have a command-line dns lookup tool in the base, but that's trivial once you've got ldns imported. Does that means loosing host(1) ? That would be somewhat annoying. There's a version of host based on unbound. At least, there's an unbound-host package for Debian Linux: http://packages.debian.org/search?keywords=unbound-host -- Freddie Cash fjwc...@gmail.com ___ 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: Replacing rc(8) (Was: FreeBSD Boot Times)
On Wed, Jun 20, 2012 at 1:28 PM, Daniel Robbins drobb...@funtoo.org wrote: On Wed, Jun 20, 2012 at 2:22 PM, Daniel Robbins drobb...@funtoo.org wrote: This doesn't change the hard runlevel (3) but it changes the OpenRC logical runlevel. Basically, this convenient system is compatible with traditional linux numerical runlevels but does depend on them. Meant to type: does NOT depend on them. Here is a bit more info: Runlevel-specific conf.d files: http://www.funtoo.org/wiki/Funtoo_Linux_Networking#Alternate_Configs Stacked runlevels (this is a more sophisticated feature than just creating a duplicate, separately-managed runlevel): http://www.funtoo.org/wiki/Stacked_Runlevels To create a separately-managed runlevel, you would just: # mkdir /etc/runlevels/maintenance # rc-update add maintenance svc1 # rc-update add maintenance svc2 # rc-update add maintenance svc1 You could then switch by typing: # rc maintenance Anything not in the maintenance runlevel that is currently running would be stopped, and any new services in maintenance that are not running would be started. There's no need to do a wholesale replacement of the RC system in FreeBSD to support this concept. What you are describing are service profiles. And we already have a single file that describes the default service profile for FreeBSD: /etc/rc.conf. That lists every service that should be started (or stopped). All that's missing is a way to tell the RC system to use a different rc.conf file (like rc.conf.mobile, or rc.conf.wireless or rc.conf.whatever), and to run through the RC setup based on that file. Our current RC system does everything needed except: - parallel execution of items that don't depend on each other - monitor running services and restart them if they crash Compared to all the init/RC systems on Linux, ours has *many* advantages, not the least of which are: - very simple text configuration file - only 2 directories of init scripts to worry about (/etc/rc.d; /usr/local/etc/rc.d) - ability to create generic or global config file (/etc/rc.conf) with local overrides (/etc/rc.conf.local) - ability to see the exact order that things will start (or stop) via rcorder - everything is written in nice, simple, sh We don't need to replace a perfectly working system. Maybe it needs improving, but it doesn't need replacing. -- Freddie Cash fjwc...@gmail.com ___ 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: Ways to promote FreeBSD?
On Fri, Apr 27, 2012 at 2:18 PM, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: My opinion is that most important obstacle in front of FreeBSD is its installation structure : It is NOT possible to install and use a FreeBSD distribution directly as it is . In Linux distributions , when a distribution is installed , the user , NOT root , can use its facilities WITHOUT setting a ( large ) number of parameters which it is approximately ZERO . Contrary to this , when a FreeBSD is installed , an ordinary user can NOT use USB , CD/DVD , etc. , and even key board / mouse in X without setting MANY parameters in MANY files ( loder.conf , rc.conf , etc. ) . This point is a very important difficulty for the beginners and a really very tiring for experienced users . And that's a good thing. :) It forces people to learn. And it allows people to create the system *they* need, instead of being forced to use the system the project thinks everyone needs. We spend a good 2-3 hours customising Ubuntu Server and Debian Linux installs to make them work they way *we* want them to, with the software *we* want, and the configurations *we* need. Most of that time is spent undoing all the helpful abstractions that Ubuntu/Debian devs think make life simpler (and they do, *IF* you use a GUI to manage things, but CLI users are left in the cold). Just look at the horrible mess that is GRUB2 configuration on Ubuntu/Debina, with shell script snippets spread through 4 different directories. Great for GUI tools to parse and update, but a royal pain for CLI users. Compared to FreeBSD where you get a nice, barebones system where we spend some time *building up* the system we want, instead of tearing down/removing excess crud. The beauty of FreeBSD as well, is that there are other projects that build on FreeBSD to create super-simple-easy-to-use-ready-from-the-word-go setups, like PC-BSD. :) With a more than FORTY years of computing experience , my idea about PC-BSD is that it is complete failure and mentioning it in front of FreeBSD is only to create another obstacle for it . Everything you rant about is covered by PC-BSD ... yet, you don't want PC-BSD. :) Trouble for PC-BSD is that , for me , it is an untested ( as even as a simple installation on a bare hardware ) distribution . Considering how long it's been used by various people around the world, I would hardly call PC-BSD untested. Maybe it's time to fire up a VM and try it? You may be pleasantly surprised that everything you are complaining about is there, ready and waiting for you to click on it. Thank you very much . Mehmet Erol Sanliturk ___ 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 -- Freddie Cash fjwc...@gmail.com ___ 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: devd based AUTOMOUNTER
On Mon, Feb 20, 2012 at 12:43 AM, vermaden verma...@interia.pl wrote: new version with new features (and BUGs ;p) Added check if ntfsfix from sysutils/ntfsprogs is available, if Yes then try to fix the NTFS filesystem before mouting it. Added GPL3 License ... just joking ;) ... added FreeBSD License to the file. Added 'noatime' as a default mount option when possible. Added TIMEOUT so when an 'orphan' STATE file lock remains, it will be deleted after a TIMEOUT. Added /usr/local/etc/devd/automount.devd file instead of messing with the base system config at /etc/devd.conf. Added config file to be used from /usr/local/etc/automount.conf file, possible options are (these are defaults): MNTPREFIX=/media LOG=/var/log/automount.log STATE=/var/run/automount.state ENCODING=en_US.ISO8859-1 CODEPAGE=cp437 DATEFMT=%Y-%m-%d %H:%M:%S USERUMOUNT=NO Mine config currently has only these: ENCODING=pl_PL.ISO8859-2 CODEPAGE=cp852 USERUMOUNT=YES The USERMOUNT otions if set to YES (default to NO) will 'chmod +s /sbin/umount', so You can click the ^ button on the devices list in NAUTILUS. These newly mounted devices appear on NAUTILUS sidebar (only with /media prefix). But THUNAR and PCMANFM does not do that, You know any other FMs that display mounted thumb drives/devices? Konqueror (KDE 3.x and 4.x) and Dolphin (KDE 4.x mainly, but I believe there's a KDE 3.x version) also show automatically mounted and removable media in the sidebar. Works nicely with HAL. Haven't tested your script yet, but am intrigued by it. Will see if I can test it sometime this week. Native solutions are so much nicer than ported ones. :) -- Freddie Cash fjwc...@gmail.com ___ 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: 8 to 9: Kernel modularization -- did it change?
On Fri, Feb 17, 2012 at 8:04 AM, Alex Goncharov alex-goncha...@comcast.net wrote: ,--- You/matt (Fri, 17 Feb 2012 07:31:03 -0800) * | It's in the kernel in later versions of 9-CURRENT and in 9-RELEASE on. | | You can't kldload or unload it because it's not a module, but part of | the kernel. | That doesn't preclude the presence of the file, I think. | | 'kldstat -v | less' should show you what's in there. Thanks, indeed: uname -sr; echo ==; kldstat | grep hda; echo ==; kldstat -v | grep hda = FreeBSD 8.2-STABLE == 11 1 0x81039000 14580 snd_hda.ko == 11 1 0x81039000 14580 snd_hda.ko (/boot/kernel/snd_hda.ko) 456 hdac/snd_hda_pcm 457 pci/snd_hda uname -sr; echo ==; kldstat | grep hda; echo ==; kldstat -v | grep hda = FreeBSD 9.0-STABLE == == 253 pci/snd_hda 252 hdac/snd_hda_pcm But am I not screwed up then? - I need to adjust the sound card pin assignments so that the sound can be directed to the headphones when they are plugged in. With FreeBSD 8, on several machines, I had gone through somewhat painful but ultimately meaningful and manageable routine of building the device.hints file. Essentially (consider the following an non-ordered set): kldunload snd_hda.ko kenv | grep hdac sysctl hw.snd.verbose sysctl hw.snd.verbose=4 kldload snd_hda.ko cat /dev/sndstat dmesg | grep ^hdac0 kenv hint.hdac.0.cad0.nid15.config=as=1 seq=15 device=Headphones kldload snd_hda.ko I don't believe I can do it now that the snd_hda module cannot be reloaded in a modified kernel environment. So, how do I go about finding and modifying the sound card pin assignments in FreeBSD 9? (If I can't do it without temporarily installing FreeBSD 8, it would be a huge disappointment. :) Stick the hint into /boot/loader.conf and reboot. -- Freddie Cash fjwc...@gmail.com ___ 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: Speeding up the loader(8).
On Thu, Jan 26, 2012 at 10:22 AM, Artem Belevich a...@freebsd.org wrote: On Thu, Jan 26, 2012 at 6:54 AM, John Baldwin j...@freebsd.org wrote: 3. The code in bcache.c doesn't really implement an LRU - it implements 'least recently added' algorithm, i.e. a kind of queue. Not that it matters much, since it flushes the elements two seconds after caching them anyway. I replaced it with Least Frequently Used. LRU didn't behave well, as it tended to replace metadata with data used only once. These sound reasonable, though I suspect they are in part due to dealing with floppies where the user can swap out of the disk and we have no way of noticing otherwise. However, we could possibly adjust some behavior to cache the bits if the disk is not a floppy drive. 4. it flushes cache on access to a different drive which means that cache does not help on multi-disk ZFS setups. I believe this is also necessary to deal with floppies and the fact that you don't have a reliable way of knowing if a floppy has changed. Are floppies still relevant? When I attempted to address your concern about floppies that you raised when I've sent my patch, I've discovered that there's no floppy connector on any of the computers/motherboards that I have. Few years back I was amused by an Intel motherboard that came with a floppy disk with RAID drivers on it, but which had no floppy connector on the motherboard. In any case, it's easy enough to enforce old behavior for floppy drives. I will make required changes but I will not be able to test it due to lack of floppy drives. USB-based floppy drives are still common. We use them to upgrade firmware, upgrade BIOS, install drivers, etc on our servers ... none of which have floppy headers on the motherboard. But the BIOSes still support floppies, and floppies are still used a lot (unfortunately). Now, whether or not a floppy-based loader would be useful for FreeBSD ... -- Freddie Cash fjwc...@gmail.com ___ 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 has serious problems with focus, longevity, and lifecycle
2012/1/20 Gleb Smirnoff gleb...@freebsd.org: On Fri, Jan 20, 2012 at 02:43:55PM +0100, Damien Fleuriot wrote: D Don't be mistaken, I greatly appreciate the work you put into this and D the time you devoted to fixing this issue which was *a real annoyance* D in our case. D D I'm not saying you didn't merge it Gleb, I'm saying for a lng D time I had to manually patch the 8.2-RELEASE boxes, because for some D reason that I don't know/understand, the patch couldn't (and still D hasn't been, I guess) be merged with 8.2-RELEASE. D D Actually, on topic, what prevents patches from being merged with D -RELEASE, as opposed to waiting for a new -RELEASE bump ? It cannot be merged into RELEASE! RELEASE is a point on a branch, as soon as RELEASE had been released, you can't push anything into it, unless you have a time machine. I think he's asking what's the criteria to push a patch to RELENG_8_2, the security/fixes branch of -RELEASE? IOW, how does one increase the patch level (8.2-RELEASE-p5 - 8.2-RELEASE-p6, etc) of a release? I believe, and RE/security team can correct me on this, that the criteria is along the lines of security issues and major bug fixes only. Perhaps that policy should be looked at and loosened slightly to also include driver updates? Or something along those lines? Perhaps look at releasing point releases (8.2.1) like DoubB suggested? -- Freddie Cash fjwc...@gmail.com ___ 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 has serious problems with focus, longevity, and lifecycle
On Wed, Jan 18, 2012 at 12:27 PM, Doug Barton do...@freebsd.org wrote: On 01/18/2012 11:46, John Kozubik wrote: - mark 9 as the _only_ production release What I've proposed instead is a new major release every 2 1/2 years, where the new release coincides with the EOL of the oldest production release. That way we have a 5-year cycle of support for each major branch, and no more than 2 production branches extant at one time. History tells us that 2 production branches is a goal we can achieve, with the focus shifting more heavily towards only bug/security fixes in the oldest branch after the new production release branch is cut. If we combine that with the ideas that are being put forward about teams that own a production branch, and a more frequent stripped-down release process, I think this is a very workable model. This is similar to how Debian works (the other OS we use the most often). They have testing (aka -CURRENT) where all the new development takes place, that will eventually become the next major release; stable (aka production -RELEASE) which sees minor (actually, point) releases every few months; and oldstable (aka legacy -RELEASE) which sees no development beyond major security/bug fixes. There's approximately 2 years between major releases, at which time oldstable is EOL'd, stable becomes oldstable, testing becomes stable, and development continue with the new testing. I can see something like that working for FreeBSD, as you've outlined it above. It seems to work well for them, although it's not a perfect comparison since the Debian devs don't do a lot of development on their own, it's more integration and testing work with software from a bunch of other, independent projects. What would be really nice, though, to help with the above, is a branched ports tree that followed the same release schedule. Perhaps it's time to dust off my coding skills and jump back into port maintenance. -- Freddie Cash fjwc...@gmail.com ___ 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 has serious problems with focus, longevity, and lifecycle
On Tue, Jan 17, 2012 at 7:32 AM, Igor Mozolevsky i...@hybrid-lab.co.uk wrote: Actually, I don't think it's cash that's the problem. I think it is more to do with the lack of common goal: the way that releases are perceived, at least by me, are that a bunch of people play in current then at some point someone decides to take a cut of the current branch and call it a release then work toward making that release passable as stable. To illustrate that, I cannot find anywhere on the .org website what core@ see the desirable features of 10.0 to be, or what the committers are working toward. That would be because, with the multi-year debacle that 5.0-RELEASE became while they worked on the features list for 5.0 (primarily SMPng), the FreeBSD Project has moved away from features-based releases and to time-based releases (although the exact timelines are not carved in stone). You won't find a list of features for the next release of FreeBSD. You'll just find a list of things that people are working on that may or may not be ready in time for the next release. The development is much closer to Ubuntu (release whatever is ready every 6 months) than to Debian (release everything when it's ready, even if it takes 2, 3, 4+ years to make it ready, while the current release grows stale). -- Freddie Cash fjwc...@gmail.com ___ 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 has serious problems with focus, longevity, and lifecycle
Just a note before everyone goes off on wonderful things were with FreeBSD 4.x going all the way to 4.11: 4.x is an anomoly in the history of FreeBSD major versions, being the only release with more than 4? 5? minor releases. There were only a couple minor versions of 1.x; there were only a couple of minor versions of 2.x; there were only a couple minor versions of 3.x; and so on through to 8.x. IOW, the 'glory days before 5.0' is really no different than the days since 5.0. Looking at the complete history of FreeBSD releases, 4.x is the outlier that needs to be discarded for the stats to make sense. (Or something like that, I've failed stats 3 times now.) :) When I started with FreeBSD, there were two production releases available: 2.2.something and 3.1. They even came in the same box set from Walnut Creek? Forget where I ordered them online now. Shortly after, 4.0 was released, but 3.x was stil developped. The only difference between pre-5 and post-5 is the switch from feature-based releases that could take years to develop, to time-based releases that ship at mostly-regular times, with whatever features are ready. The latter is actually more useful, as you can plan ahead of time as you know the general timeframes between major versions. So, let's keep a little perspective in the discussion, and not ignore the past history of FreeBSD releases. Cheers, Freddie ___ 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: CPUTYPE and friends, from 'make.conf' benchmark
2011/12/5 rank1see...@gmail.com
I've took machine and installed binary FreeBSD(amd64 8.2-p4 GENERIC) on it.
Then I've installed 'benchmarks/unixbench' port.
So everything is a default generic binary install ('make.conf' empty - no
CPU optimization flags)
After running: '# time unixbench', final score was:
394.2
Completed in 22.8 min
Then I've recompiled everything, from src, world and kernel, with
'make.conf':
--
CPUTYPE?=core2
CFLAGS+=-march=native
NO_CPU_CFLAGS=yes
COPTFLAGS+=-march=native
NO_CPU_COPTFLAGS=yes
And, how does it do if you remove everything except the CPUTYPE line? Most
of the rest if unnecessary.
--
Freddie Cash
fjwc...@gmail.com
___
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: cron(8) mis-feature with @reboot long after system startup
On Fri, Nov 25, 2011 at 8:37 AM, Tom Evans tevans...@googlemail.com wrote: On Fri, Nov 25, 2011 at 4:09 PM, Cy Schubert cy.schub...@komquats.com wrote: Changing the behaviour by default would change the semantics of @reboot, altering the behaviour of cron jobs which rely on the brokenness. What if both behaviours are wanted on the same system? Unlikely, as I can't see anyone relying on this broken behaviour. Having said that, I'm sure there are cron jobs that do rely on the broken behaviour, so it may be best to simply deprecate the broken behaviour and make one or the other a command line option. The problem is that the behaviour is not broken, it works exactly as described in crontab(5) - it is just confusing. It's also slightly nonsensical - the command isn't run at reboot, it is run at boot. How about leaving @reboot exactly as it is, improving the docs so that it is clear what @reboot does, and add a @boot to vixie-cron which would only run at boot time. I think it isn't wise to change how one strange to use format behaves under FreeBSD when vixie-cron is a quite ubiquitous choice amongst nix variants. With regards to anything that runs at boot, I think dumbly checking that the boot time was less than N minutes ago is also sub-optimal. If cron keeps dieing and respawning close to boot time, your cronjob could trigger multiple times. I don't know the exact semantics of kern.boottime - at what point is the boot time stored? If it is before file systems are mounted, an unclean file system triggering a foreground fsck could delay boot time by hours, thereby forcing cron to not think that it is running at boot time when it is finally started. Perhaps a call to uptime(1) would be enough? -- Freddie Cash fjwc...@gmail.com ___ 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: 9-beta1 installer - partition editor
On Mon, Sep 12, 2011 at 10:59 AM, Ivan Voras ivo...@freebsd.org wrote: On 12 September 2011 18:28, Nathan Whitehorn nwhiteh...@freebsd.org wrote: This was resolved earlier -- you cannot install onto just MBR without a bsdlabel. This has never been supported, and worked only by accident before. *As it tells you* you need to create sub-partitions. I'll again note that it should be supported because a) there's no technical reason not to and b) this is how every other OS works. But I'll leave it at that, maybe the users won't mind. Well, if you look at the history of BSD Unix and the port to the PC, you'll notice that every other PC-based OS does partitioning wrong. :) Unix partitioning has always been this way: - create partition on disk for OS - create sub-partitions for filesystems And it was that way for many years (decades?) before the PC came along. IBM/MS decided to ignore the huge history of computers and partitioning that came before, instead coming up with the lame-brained primary partition MBR scheme with a limit of 4 partitions. Later extending that with the even more lame-brained concept of an extended partition and logical partitions. Don't blame FreeBSD (a member of the BSD family) for following the BSD Unix tradition for partitioning. Thankfully, the GPT partitioning standard removes the distinction between primary, extended, and logical partitions. Now, a partition is a partition is a partition. It's just too bad that they removed the concept of sub-partitions (bsdlabels) as a multi-boot system now has a giant, messy, table full of top-level partitions, with each OS jumbled together (but, it's much easier to label them all to make it easier to manage). :( -- Freddie Cash fjwc...@gmail.com ___ 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: Mapping /dev/gptid numbers to /dev/adXpY
If you disable gptid labels in /boot/loader.conf and reboot, it should display the device nodes again. Alternatively, since you are using gpt, you can just label the partitions, and 'zfs replace' each disk with the /dev/gpt/labelname node. On Sunday, July 24, 2011, Stephen Hocking stephen.hock...@gmail.com wrote: On Mon, Jul 25, 2011 at 2:15 PM, Daniel O'Connor docon...@gsoft.com.au wrote: On 25/07/2011, at 11:03, Stephen Hocking wrote: Now this is all very interesting, but I would like to be able to map that back to a /dev/adXpY device entry, so when I offline them I can then go to the appropriate physical disk. I thought that gpart show -r might help, but the numbers emitted from that don't match up. Looking at the major/minor numbers of the devices don't help either. Does anyone have an idea? If you run 'gpart list' you will see a list of device names and UUIDs. Mapping it by hand is a bit tedious though.. Both Test Rat Daniel pointed me towards gpart list. The gpart man page doesn't seem to mention the list command, which is probably why I missed it. Anyways, now all I have to do is label my hotswap drawers properly Stephen ___ 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 -- Freddie Cash fjwc...@gmail.com ___ 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: what is the RIGHT(TM) way to configure background DHCP?
On Wed, Jul 6, 2011 at 12:47 PM, deeptec...@gmail.com deeptec...@gmail.comwrote: the boot process of my FreeBSD machines takes a relatively long time. it spends 30 seconds idling at some point, because my network interface (sk0) is supposed to have an IP address assigned via DHCP, and the DHCP server on my LAN takes an extremely long time (~40 seconds) to reply to IP address requests. this is unacceptable for me; i want the FreeBSD boot process to finish 30 seconds earlier, even if i won't get the chance to use the network for ~40 seconds after the booting has finished. The simplest method would be to put into /etc/rc.conf: ifconfig_sk0=up Then into /etc/rc.local: dhclient sk0 That would bring your interface up during the boot process, then manually fire off dhclient once the normal boot process has ended (right before the login prompt appears) as a background process. By the time you login, the IP should be assigned. As for what's the correct way to do this via just rc.conf, I'll leave that up to others more in the know about how RC works. -- Freddie Cash fjwc...@gmail.com ___ 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: [RELEASE] New Boot-Loader Menu
Very nice and functional, without adding a lot of extra verbosity or steps. I really appreciated the clean install via binary package. Well done. Only question I have is whether it's possible to use the Beastie ASCII image instead of the pointy-eared blob? The beastie.4th file is still present under /boot, but I don't know how to hook it into the new menu. -- Freddie Cash fjwc...@gmail.com ___ 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: OMAP3 Question
On Wed, Apr 27, 2011 at 1:30 PM, Chris Richardson chris.richardson@gmail.com wrote: I wanna emulate OMAP3 Processor. Is it approach I can use to emulate OMAP3 without the need to any hardware? Qemu has some basic support for this: http://code.google.com/p/qemu-omap3/ No idea how good it is, or if it's even usuable. -- Freddie Cash fjwc...@gmail.com ___ 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: Add SUM sysctl
On Sat, Apr 16, 2011 at 7:24 AM, rank1see...@gmail.com wrote: After compilation of kernel and world in MUM, kernel is installed in MUM, but to install world, we reboot into SUM, then install world. (HANDBOOK) Note: You do not have to be in SUM to install the world and/or the kernel. You can install them just fine in multi-user mode. I do this all the time on remote system, as dropping to SUM would knock off the SSH connection. All you have to do is make sure no one else is logged in, stop as many services and daemons as possible, then do the installworld, and reboot. It's not recommended in the Handbook, but it's not forbidden either. So that is way, they both need to be installed in SUM, in one shot! Kernel then world! Or ... they can be installed in MUM without issue. DO YOU KNOW, what to look for, in sys that will indicate to my function, that it is in SUM? No network configured, no daemons running, just a single shell running. IOW, everything can be done manually in MUM to simulate SUM. -- Freddie Cash fjwc...@gmail.com ___ 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: src.conf(5) status/semantics
On Mon, Mar 28, 2011 at 3:03 PM, Alexander Best arun...@freebsd.org wrote: how hard would it be to change the *.mk code so the following semantics apply: - make.conf(5) == applies system-wide - src.conf(5) == applies only to /usr/src What would be really nice would be taking it to its logical conclusion: /etc/make.conf for system-wide make options (applies when make run anywhere) /etc/src.confonly applies when make run under /usr/src /etc/ports.confonly applies when make run under /usr/ports -- Freddie Cash fjwc...@gmail.com ___ 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: there is a way to avoid strict libraries linking?
On Wed, Apr 14, 2010 at 11:18 AM, Leinier Cruz Salfran salfrancl.lis...@gmail.com wrote: On Wed, Apr 14, 2010 at 1:48 PM, Dan Nelson dnel...@allantgroup.com wrote: Just because you Anyway, the FreeBSD port maintainers usually bump the revision of dependant ports when a major library like libpng gets upgraded, to force everyone to upgrade anything that depends on it. mmm .. I think it's not true because I maintain a port and i'm VERY VERY restricted to update the port because I depends on a mentor that will ONLY update the port in fbsd svn tree if I sent to him the tinderbox log of the sucessfully build of the port .. so I have not much patience to do all this things so I update the port and do ALL task including constructing the package into tinderbox ONLY when a new version of the program is available .. and I think that exists a lot of ports maintainers that are in same situation do you agree with me that it's difficult to a port maintainer to update his/her port because of this restriction The port maintainer doesn't *have to* update anything. When library ports go through a library bump like this, all the ports that depend on it get an automatic PORTREVISION bump. All the port maintainer has to do is double-check that the port compiles with the new version of the lib. Only if there are issues with that (which usually get picked up by the -exp runs on the ports cluster), then the port maintainer has to step in and fix things. 9 times out of 10, a port maintainer doesn't have to do anything with a port until a new version of the app is released. could be a good idea to plan and implement a system to allow fbsd ports maintainers to maintain easyly the own ports via web or mail ONCE a fbsd mentor have uploaded his/her port to fbsd svn tree In several years of port maintainership, I've never had a need for anything like this. A new version of an app I maintain is released, I update the port locally, test it, submit a PR with the update, someone looks at it and sends back suggestions/issues, the port is fixed locally and patches re-submitted to the PR, and then the port is committed to the tree. Overall, not a long process. If you maintain enough ports for enough time, and generate enough committed PRs to annoy people enough, you get rewarded with a commit bit. :) -- Freddie Cash fjwc...@gmail.com ___ 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: there is a way to avoid strict libraries linking?
On Wed, Apr 14, 2010 at 12:02 PM, Leinier Cruz Salfran salfrancl.lis...@gmail.com wrote: On Wed, Apr 14, 2010 at 2:50 PM, Freddie Cash fjwc...@gmail.com wrote: The port maintainer doesn't *have to* update anything. When library ports go through a library bump like this, all the ports that depend on it get an automatic PORTREVISION bump. okey maybe i didn't understood the 'bump' means .. I must to thank you because of comment about this subject All the port maintainer has to do is double-check that the port compiles with the new version of the lib. Only if there are issues with that (which usually get picked up by the -exp runs on the ports cluster), then the port maintainer has to step in and fix things. okey let me see if I understood you .. you mean that I create a 'ONE_PORT' to a specific program version and if one of the library on which the 'ONE_PORT' depends change to a major version, then the 'ports cluster' put add PORTREVISION to the 'ONE_PORT' and update the *_DEPENDS automatically Correct. The PORTVERSION doesn't change. But PORTREVISION gets bumped up by 1. That way, when user's check for updates in the ports tree, via pkg_version -vl '' or portversion -v or similar tools, then ONE_PORT will be listed as update available like so (not exact syntax, going from memory): one_port-1.0.0 = needs update (port has one_port-1.0.0_1) The _1 part is PORTREVISION. It's used to say the version hasn't changed, but something in the ports tree requires this to be re-installed or 'upgraded'. Maybe an OPTIONS line was added, or a dependent library version changed, or a build dependency changed, or a new RC script was added, or something like that. There's some good examples/explanations of PORTREVISION in the FreeBSD Porter's Handbook. -- Freddie Cash fjwc...@gmail.com ___ 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: [RFC] The official logo for logo_saver?
On Tue, Apr 6, 2010 at 3:29 PM, Jung-uk Kim j...@freebsd.org wrote: Although I really like logo_saver with Beastie, we have the official FreeBSD logo and I think it is time to say good-bye to the old logo image file. The attached file is a drop-in replacement for sys/dev/syscons/logo/logo.c. What do you think? Jung-uk Kim * PS: I couldn't find a good small 256-color image from FreeBSD.org. So, I googled and found the following icon: http://kde-look.org/CONTENT/content-m1/m112422-1.png The following URL seems to be the actual web page: http://kde-look.org/content/show.php?content=112422 Please consider renaming the existing logo_saver to something like beastie_saver, to keep it around as an option. Then replace logo_saver with the new logo. -- Freddie Cash fjwc...@gmail.com ___ 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: Request for opinions - gvinum or ccd?
: Children see ... 64 mixed workload = 1587053.33 KB/sec 64-threads: Parent sees ... 64 mixed workload = 294586.82 KB/sec 128-threads: Children see ... 128 mixed workload = 807349.95 KB/sec 128-threads: Parent sees ... 128 mixed workload = 98998.77 KB/sec 256-threads: Children see ... 256 mixed workload = 393469.55 KB/sec 256-threads: Parent sees ... 256 mixed workload = 112394.90 KB/sec -- Freddie Cash fjwc...@gmail.com ___ 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: Request for opinions - gvinum or ccd?
On Sat, Jun 6, 2009 at 12:54 PM, Ivan Vorasivo...@freebsd.org wrote: Sorry to come into the discussion late, but I just want to confirm something. The configuration below is a stripe of four components, each of which is RAIDZ2, right? If, as was discussed later in the thread, RAIDZ(2) is more similar to RAID3 than RAID5 for random performance, the given configuration can be (very roughly, in the non-sequential access case) expected to deliver performance of four drives in a RAID0 array? According to all the Sun documentation, the I/O throughput of a raidz configuration is equal to that of a single drive. Hence their recommendation to not use more than 8 or 9 drives in a single raidz vdev, and to use multiple raidz vdevs. As you add vdevs, the throughput increases. We made the mistake early on of creating a 24-drive raidz2 vdev. Performance was not very good. And when we had to replace a drive, it spent over a week trying to resilver. But the resilver operation has to touch every single drive in the raidz vdev. :( We remade the pool using 3x 8-drive raidz2 vdevs, and performance has been great (400 MBytes/s write, almost 3 GBytes/s sequential read, 800 MBytes/s random read). -- Freddie Cash fjwc...@gmail.com ___ 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: Request for opinions - gvinum or ccd?
On Sun, May 31, 2009 at 4:59 PM, xorquew...@googlemail.com wrote: There is one last thing I'd like clarified. From the zpool manpage: In order to take advantage of these features, a pool must make use of some form of redundancy, using either mirrored or raidz groups. While ZFS supports running in a non-redundant configuration, where each root vdev is simply a disk or file, this is strongly discouraged. A single case of bit corruption can render some or all of your data unavailable. Is this supposed to mean: ZFS is more fragile than most. If you don't use redundancy, one case of bit corruption will destroy the filesystem Or: Hard disks explode often. Use redundancy. Unless you specify mirror or raidz on the create/add line, zfs (in essence) creates a RAID0 stripe of all the vdevs. Hence, if a single drive dies, the whole thing dies. Just like in a normal hardware/software RAID0 array. Nothing special or new here. Just like normal RAID, unless you add redundancy (RAID1/5/6) to a stripe set, losing a single disk means losing the whole array. -- Freddie Cash fjwc...@gmail.com ___ 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: Hot swapping SATA drives
On November 25, 2008 08:53 am Peter Steele wrote: Is there any solution to this? Can a server be built around FreeBSD that supports hot swappable SATA drives? Use a real hot-swappable drive plane, attached to a good SATA controller that handles hot-swap in hardware? :) Use ZFS, which seems to work better with drives being added/removed than ata(4)? :) Sorry, the few systems we have running FreeBSD either have single IDE drives, single SATA drives, or 12-24 SATA drives attached to a hardware hot-swappable drive-plane connected to 3Ware 9550/9650 RAID controllers. The single-drive systems obviously can't do swapping, and the rest work without issues. -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Testers wanted] /dev/console cleanups
On November 20, 2008 02:42 am Nate Eldredge wrote: On Thu, 20 Nov 2008, Jeremy Chadwick wrote: On Wed, Nov 19, 2008 at 11:48:36PM -0800, Nate Eldredge wrote: On Wed, 19 Nov 2008, Jeremy Chadwick wrote: On Thu, Nov 20, 2008 at 05:39:36PM +1100, Peter Jeremy wrote: I hope that never gets committed - it will make debugging kernel problems much harder. There is already a kern.msgbuf_clear sysctl and maybe people who are concerned about msgbuf leakage need to learn to use it. And this sysctl is only usable *after* the kernel loads, which means you lose all of the messages shown from the time the kernel loads to the time the sysctl is set (e.g. hardware detected/configured). This is even less acceptable, IMHO. But surely you can arrange that the contents are written out to /var/log/messages first? E.g. a sequence like - mount /var - write buffer contents via syslogd - clear buffer via sysctl - allow user logins This has two problems, but I'm probably missing something: 1) See my original post, re: users of our systems use dmesg to find out what the status of the system is. By status I don't mean from the point the kernel finished to now, I literally mean they *expect* to see the kernel device messages and all that jazz. No, I'm not making this up, nor am I arguing just to hear myself talk (despite popular belief). I can bring these users into the discussion if people feel it would be useful. I forgot about that point. I can sympathize with those users; I feel the same way. It's a good way to learn about a system as a mere user (since usually sysadmins don't remember or bother to disable it). However, in my experience dmesg isn't really the best thing for that purpose; the kernel message buffer tends to get wiped out once the system has been up for a while. (It fills with ipfw logs, ethernet link state changes, etc.) Maybe a better approach would be to point them to /var/log/messages or whichever log file stores them permanently. I think what you are looking for is /var/run/dmesg.boot, which stores just the dmesg info from the initial boot. Nothing gets logged to this after the boot is complete. This file has been a life saver quite a few times since I discovered it, and is something I really miss when working with mis-behaving Linux systems. -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how determine all possible drivers for my system
On October 17, 2008 01:21 pm Oleg wrote: Hello maillist of my favorite WortstationServer OS May i asking: how i can determine all drivers of existing devices, but who is not present in GENERIC kernel. snippage My question: what the official FreeBSD-way for the approach similar operations? I tend to use a more trial-and-error method. Basically, it's run pciconf -vl to get a listing of all hardware in the system, and then do searches in man pages, NOTES, and google to find what drivers to test for each device listed as noneX@ (where X is a number). Most of the time, you can guess what the driver will be called based on the type off device listed in pciconf. -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ZFS boot
On 10/11/08, Matthew Dillon [EMAIL PROTECTED] wrote: With regards to the traditional BSD partitioning scheme, having a separate /usr, /home, /tmp, etc... there's no reason to do that stuff any more with ZFS (or HAMMER). As separate partitions, no. As separate filesystems, definitely. While HAMMER PFSes may not support these things yet, ZFS allows you to tailor each filesystem to its purpose. For example, you can enable compression on /usr/ports, but have a separate /usr/ports/distfilles and /usr/ports/work that aren't compressed. Or /usr/src compressed and /usr/obj not. Have a small record (block) size for /usr/src, but a larger one for /home. Give each user a separate filesystem for their /home/username, with separate snapshot policies, quotas, and reservations (initial filesystem size). Creating new filesystems with ZFS is as simple as zfs create -o mountpoint=/wherever pool/fsname. If you put a little time into planning the hierarchy/structure, you can take advantage off the properties inheritance features of ZFS as well. You just need one, and can break it down into separate management domains within the filesystem (e.g. HAMMER PFS's). Similar kind of idea. Most linux dists don't bother with multiple partitions any more. They just have '/' and maybe a small boot partition, and that's it. Heh, that's more proof of the difficulties inherent with old-school disk partitioning, compared to pooled storage setups, than an endorsement of using a single partition/filesystem. :) -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ZFS w/failing drives - any equivalent of Solaris FMA?
On September 12, 2008 02:45 am Karl Pielorz wrote: Recently, a ZFS pool on my FreeBSD box started showing lots of errors on one drive in a mirrored pair. The pool consists of around 14 drives (as 7 mirrored pairs), hung off of a couple of SuperMicro 8 port SATA controllers (1 drive of each pair is on each controller). One of the drives started picking up a lot of errors (by the end of things it was returning errors pretty much for any reads/writes issued) - and taking ages to complete the I/O's. However, ZFS kept trying to use the drive - e.g. as I attached another drive to the remaining 'good' drive in the mirrored pair, ZFS was still trying to read data off the failed drive (and remaining good one) in order to complete it's re-silver to the newly attached drive. For the one time I've had a drive fail, and the three times I've replaced drives for larger ones, the process used was: zpool offline pool old device remove old device insert new device zpool replace pool old device new device For one machine, I had to shut it off after the offline, as it didn't have hot-swappable drive bays. For the other machine, it did everything while online and running. IOW, the old device never had a chance to interfere with anything. Same process we've used with hardware RAID setups in the past. Is there anything similar to this on FreeBSD yet? - i.e. Does/can anything on the system tell ZFS This drives experiencing failures rather than ZFS just seeing lots of timed out I/O 'errors'? (as appears to be the case). Beyond the periodic script that checks for things like this, and sends root an e-mail, I haven't seen anything. -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ZFS w/failing drives - any equivalent of Solaris FMA?
On September 12, 2008 09:32 am Jeremy Chadwick wrote: For home use, sure. Since most home/consumer systems do not include hot-swappable drive bays, rebooting is required. Although more and more consumer motherboards are offering AHCI -- which is the only reliable way you'll get that capability with SATA. In my case with servers in a co-lo, it's not acceptable. Our systems contain SATA backplanes that support hot-swapping, and it works how it should (yank the disk, replace with a new one) on Linux -- there is no need to do a bunch of hoopla like on FreeBSD. On FreeBSD, with that hoopla, also take the risk of inducing a kernel panic. That risk does not sit well with me, but thankfully I've only been in that situation (replacing a bad disk + using hot-swapping) once -- and it did work. Hrm, is this with software RAID or hardware RAID? With our hardware RAID systems, the process has always been the same, regardless of which OS (Windows 2003 Servers, Debian Linux, FreeBSD) is on the system: - go into RAID management GUI, remove drive - pull dead drive from system - insert new drive into system - go into RAID management GUI, make sure it picked up new drive and started the rebuild We've been lucky so far, and not had to do any drive replacements on our non-ZFS software RAID systems (md on Debian, gmirror on FreeBSD). I'm not looking forward to a drive failing, as these systems have non-hot-pluggable SATA setups. On the ZFS systems, we just zpool offline the drive, physically replace the drive, and zpool replace the drive. On one system, this was done via hot-pluggable SATA backplane, on another, it required a reboot. -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: If not the force, what should I use? (Was: FreeBSD in Business (was Re: Idea for FreeBSD))
On Wed, Aug 13, 2008 at 1:40 AM, Vincent Hoffman [EMAIL PROTECTED] wrote:
Jonathan McKeown wrote:
On Tuesday 12 August 2008 17:51:32 Mike Meyer wrote:
On Tue, 12 Aug 2008 17:10:22 +0200 Adrian Penisoara
Ok, given that you 1) want to have both this service if it's
part of our normal runtime and this service even if it's not
part of our normal runtime as script commands, and that 2)
without a prefix gets the if it's part of our normal runtime
meaning, as we want the user to have to explicitly say Yes, I know
this looks odd, but I know what I'm doing so do it anyway to get the
even if it's not part of our normal runtime behavior, then what
would you have us use instead of force?
People keep talking about forcestart.
Unless I'm misunderstanding things horribly, forcestart does exactly that
- forces the service to start regardless of any error that may occur.
The better option for starting something as a one-off (not enabled in
rc.conf) is mnemonically named onestart - which only ignores the rcvar but
still fails on any other error.
And yes, I like having onestart/onestop distinguished from start/stop.
I believe it forces a start even though its not actually enabled (in
rc.conf) rather than regardless of errors.
If you really want a command line of onestart/onestop install the
sysutils/bsdadminscripts port which has a script called rconestart and
rconestop which do exactly that ;)
From /etc/rc.subr:
# run_rc_command argument
# Search for argument in the list of supported commands, which is:
# start stop restart rcvar status poll ${extra_commands}
# If there's a match, run ${argument}_cmd or the default method
# (see below).
#
# If argument has a given prefix, then change the operation as follows:
# Prefix Operation
# -- -
# fastSkip the pid check, and set rc_fast=yes
# force Set ${rcvar} to YES, and set rc_force=yes
# one Set ${rcvar} to YES
Further in the file:
case $rc_arg in
fast*) # fast prefix; don't check pid
rc_arg=${rc_arg#fast}
rc_fast=yes
;;
force*) # force prefix; always run
rc_force=yes
_rc_prefix=force
rc_arg=${rc_arg#${_rc_prefix}}
if [ -n ${rcvar} ]; then
eval ${rcvar}=YES
fi
;;
one*) # one prefix; set ${rcvar}=yes
_rc_prefix=one
rc_arg=${rc_arg#${_rc_prefix}}
if [ -n ${rcvar} ]; then
eval ${rcvar}=YES
fi
;;
esac
Which, if I follow things, means:
** /etc/rc.d/$script faststart won't check for existing PID files
or already running apps, and just run $script, but still checks if
$script_enable=yes is in /etc/rc.conf.
** /etc/rc.d/$script onestart sets $script_enable=yes internally,
regardless of what is in rc.conf, and runs $script. All other checks
are done as per normal.
** /etc/rc.d/$script forcestart runs $script, regardless of what's
in rc.conf, the status of the PID file, or the existence of an already
running daemon.
What most people in this thread are looking for is onestart.
--
Freddie Cash
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: Sysinstall is still inadequate after all of these years
On Tue, Jul 8, 2008 at 8:00 AM, Mike Makonnen [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Hear, hear! To be honest, this is the only bit about the current sysinstall that I really dislike: the fact that it can be used for post-installation configuration and package installation. This causes no end of trouble for newbies, who seem to view sysinstall as The One True System Admin Tool and try to use it for configuring/installing everything. Too many times, on various BSD forums, I've had to walk people through cleaning up /etc/rc.conf and showing them how to correctly install/configure things (using standard FreeBSD tools), since they used sysinstall for everything. That may be true, but sysinstall did help me do basic, essentical configuration of my very first installed system, and a few installs after that (until I learned about /etc/rc.conf et al). And I never regarded it as The One True Sysadmin Tool, because I did not use Linux distros, thus never got used to their ways. It's just that the simple configuration menu really helped me to get a useful system running in a few minutes (though menu items certainly could make use of more verbose descriptions). And then I could play with the working system and learn ways to configure it. So, IMHO, a basic curses system configuration utility is still needed, and should be run after sysinstall or it should tell the user how to run it (maybe in motd, or sysinstall itself?). Yes, I agree that such a tool is useful, but it does not belong in the installer. In fact, the BSD Installer framework can be used here also to separate the implementation details from the user interface. Exactly. There's nothing wrong with having an TUI/GUI for configuring /etc/rc.conf, or ports, or whatever. And there are pointers to the handbook and man pages in the default motd, so one can learn to do it manually via a text editor. All I'm saying is that a generic system configuration tool should not be an integral part of the installer (and all mentions of sysinstall, IMO, should be removed from the default motd). They are separate tasks. -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: Sysinstall is still inadequate after all of these years
On Sat, Jul 5, 2008 at 7:59 AM, Mike Makonnen [EMAIL PROTECTED] wrote: Also, the installer's job should only be to install a useable system. Post-installation chores like configuration, adding/removing users, etc should be done by another application. You shouldn't need the installer once you've installed the OS. Hear, hear! To be honest, this is the only bit about the current sysinstall that I really dislike: the fact that it can be used for post-installation configuration and package installation. This causes no end of trouble for newbies, who seem to view sysinstall as The One True System Admin Tool and try to use it for configuring/installing everything. Too many times, on various BSD forums, I've had to walk people through cleaning up /etc/rc.conf and showing them how to correctly install/configure things (using standard FreeBSD tools), since they used sysinstall for everything. IMO, the installer should allow you to partition the disk(s), format the partition(s), install the OS, configure a user, and reboot the system. Anything beyond that should be handled by the OS tools, from within the installed and running OS. The tricky part will be getting the disk slicing, slice partitioning, and filesystem formatting to work reliably, with all the power of FreeBSD's GEOM modules, and ZFS. -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new SATA chipsets support
On March 13, 2008 08:51 am Игорь Красносельский wrote: I am going to build my new file- and gateway server and i wish to use any of brand new motherboards for it, such as ASUS M2N-SLI deluxe (nforce 570 SLI chipset) or Gigabyte MA790X-DS4 (AMD 790X / AMD SB600 chipset), but i can't find any information of supporting that chipsets in your current 7.0 release. Are you going to include support of that chips to your next releases, and if yes, when? Or maybe i can find that drivers somewhere else? I think that drivers from ASUS (http://support.asus.com/download/download.aspx?SLanguage=en-enmodel=M 2N-SLI%20Deluxe) may not work with FreeBSD? Can't say anything about the above, but ... A really nice motherboard that works really well with FreeBSD 6.3 and FreeBSD 7.0 is the Asus M2N-LR: http://ca.asus.com/products.aspx?l1=9l2=39l3=263l4=0model=1352modelmenu=1 This is a single-socket AM2 motherboard with support for 1000-series AMD Opteron processors (single or dual-core). 4 RAM slots supports up to 4 GB of DDR-800 RAM, 2x Broadcom gigabit NICs onboard (attached to PCIe), 6 SATA connectors. Expansion slots include a 16x PCIe slot, two 64-bit/133 MHz PCI-X slots, and a 32-bit/33 MHz PCI slot. We're using these for our gateway/router/firewall boxes without any issues running FreeBSD 6.3 and FreeBSD 7.0. We installed a 4-port Intel Pro/1000 gigabit NIC, dual-core Opteron CPU, 2 GB RAM, and a single 80 GB SATA HD in ours. Beautiful little things. Haven't been able to crash it yet. And fairly inexpensive (just under $1100 CDN in short 2U rackmountable cases when we purchased them in Jan 08, for the config above). Everything except one memory controller has drivers attached to it in pciconf -vl output, even on 6.3. -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: what happened to make world?
On August 30, 2007 12:49 pm Pietro Cerutti wrote: Mike Meyer wrote: On Thu, 30 Aug 2007 21:27:18 +0200 Pietro Cerutti [EMAIL PROTECTED] wrote: Max Laier wrote: On Thursday 30 August 2007, Pietro Cerutti wrote: # make world WARNING: make world will overwrite your existing FreeBSD installation without also building and installing a new kernel. This can be dangerous. Please read the handbook, 'Rebuilding world', for how to upgrade your system. Define DESTDIR to where you want to install FreeBSD, including /, to override this warning and proceed as usual. You may get the historical 'make world' behavior by defining HISTORICAL_MAKE_WORLD. You should understand the implications before doing this. Bailing out now... *** Error code 1 Stop in /usr/src. Now, THIS is quite funny... do you really thing that a person with - root access - the knowledge of the existence of make world needs this sort of things? I didn't see anything about this new-wave-of-user-friendly-bsd going on the list.. have I missed something? And your complaint would be ... what exactly? I don't want my OS to treat me like a stupid. Yeah, we have Windows for that. Or if you hate MS, GNU/Linux. But there are valid reasons for wanting to do a make world (i.e. - you've changed make.conf options the kernel doesn't use). If it's going to be friendly, it should tell us how to do what we told it to do Even worse.. it doesn't tell you how to do what you tell him to do.. it doubts that maybe that's not what you really want to do! From the bit you quoted in your first post: -- Define DESTDIR to where you want to install FreeBSD, including /, to override this warning and proceed as usual. You may get the historical 'make world' behavior by defining HISTORICAL_MAKE_WORLD. You should understand the implications before doing this. -- Tells you right there how to work around this warning. -- Freddie Cash, LPIC-2 CCNT CCLP Network Support Technician School District 73 (250) 377-HELP [377-4357] [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: what happened to make world?
On August 30, 2007 12:41 pm Mike Meyer wrote: On Thu, 30 Aug 2007 21:27:18 +0200 Pietro Cerutti [EMAIL PROTECTED] wrote: Max Laier wrote: On Thursday 30 August 2007, Pietro Cerutti wrote: # make world WARNING: make world will overwrite your existing FreeBSD installation without also building and installing a new kernel. This can be dangerous. Please read the handbook, 'Rebuilding world', for how to upgrade your system. Define DESTDIR to where you want to install FreeBSD, including /, to override this warning and proceed as usual. You may get the historical 'make world' behavior by defining HISTORICAL_MAKE_WORLD. You should understand the implications before doing this. Bailing out now... *** Error code 1 Stop in /usr/src. Now, THIS is quite funny... do you really thing that a person with - root access - the knowledge of the existence of make world needs this sort of things? I didn't see anything about this new-wave-of-user-friendly-bsd going on the list.. have I missed something? And your complaint would be ... what exactly? I don't want my OS to treat me like a stupid. Yeah, we have Windows for that. Or if you hate MS, GNU/Linux. But there are valid reasons for wanting to do a make world (i.e. - you've changed make.conf options the kernel doesn't use). If it's going to be friendly, it should tell us how to do what we told it to do From the original post: -- Define DESTDIR to where you want to install FreeBSD, including /, to override this warning and proceed as usual. You may get the historical 'make world' behavior by defining HISTORICAL_MAKE_WORLD. You should understand the implications before doing this. -- What part in there doesn't make sense? :) It tells you right there how to do what we told it to do. Seems like a lot of whining over nothing. -- Freddie Cash, LPIC-2 CCNT CCLP Network Support Technician School District 73 (250) 377-HELP [377-4357] [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New FreeBSD package system (a.k.a. Daemon Package System (dps))
On Friday 11 May 2007 07:35 am, Mike Meyer wrote: I still think we ought to quit pretending that ports/packages aren't part of BSD, and default LOCALBASE to /usr. But if changing it is being tested, that's a big help. Personally, this is the one thing I like *most* about BSD. There is a clear separation between what ships as part of the OS, and what apps I install on it later. There's a consistency to things, that you just can't find anywhere else. / and /usr are the OS. /usr/local is what the ports tree installs. /whatever/i/want/ is where I install things from source to keep them separate. One could make the case for /usr to be the OS, /usr/pkg (or whatever) for port installs, and /usr/local for local source installs. So long as the OS is separate from the apps. With the OS and apps separate, you can upgrade them asynchronously. There's a nice feeling to running the latest version of appX on FreeBSD 5.3. Or an older version of appY on FreeBSD 6-STABLE. Try getting something similar on a Linux system. -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New FreeBSD package system (a.k.a. Daemon Package System (dps))
On Friday 11 May 2007 11:34 am, Mike Meyer wrote: In [EMAIL PROTECTED], Freddie Cash [EMAIL PROTECTED] typed: On Friday 11 May 2007 07:35 am, Mike Meyer wrote: I still think we ought to quit pretending that ports/packages aren't part of BSD, and default LOCALBASE to /usr. But if changing it is being tested, that's a big help. Personally, this is the one thing I like *most* about BSD. There is a clear separation between what ships as part of the OS, and what apps I install on it later. There's a consistency to things, that you just can't find anywhere else. / and /usr are the OS. /usr/local is what the ports tree installs. Moving the OS into the package system has been on the todo list for a long time (assuming it's still there - there are people opposed to that). What happens to your distinction in that case? This is why I think the distinction is an illusion. Hmmm, I might be misremembering things, but I always thought the plan was to break out some bits of the base OS into ports/packages (like sendmail/bind/etc) but have them installed-by-default. Either way, you are correct that the distinction between base OS and installed apps would blur or even disappear. One could make the case for /usr to be the OS, /usr/pkg (or whatever) for port installs, and /usr/local for local source installs. So long as the OS is separate from the apps. I think that would be an improvement. There's a real distinction between things installed from ports/packages and things I built and installed myself. The former I expect to reinstall from FreeBSD media; the latter I can't. Since most packages in the latter install in /usr/local, using that for the former makes life a bit more painful if you want to keep them separate. The downside is that making the default something else makes things a bit harder for people doing ports, which we promptly throw away by providing a settable LOCALBASE. With the OS and apps separate, you can upgrade them asynchronously. There's a nice feeling to running the latest version of appX on FreeBSD 5.3. Or an older version of appY on FreeBSD 6-STABLE. How would setting LOCALBASE=/usr break this? Of course, equally valid is the question what will break if I set LOCALBASE=/usr? Hmm. I think I may found out I was thinking more along the lines of how Linux distros operate, where all apps are installed under /usr, and where the only way to get the latest version of an app was to upgrade the entire OS and switch package repositories to the ones for that new version of the OS. Something that irks me to no end when using Linux systems. Not quite the same as what you were getting at, I see, so we can just ignore this entire little bit of the thread. :) Personally, what I like about FreeBSD is that it provides flexibility for things like this. If I'd rather have ports out of /usr/local, it's not really hard to do. Not as easy as doing things the default way, but not any worse than anyone else who wants to build from source. Other systems seem intent on making me do things their way, no matter what I may think of it, and trying to change something like this is a major change. Yes, flexibility and customisability is very nice, and definitely one of FreeBSD's strength. -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 64-bits platform question
On Thursday 22 February 2007 12:28 am, Oliver Fromme wrote: Aard Nerd wrote: Hi list, as far as I know Intel 64 architecture (formerly known as Intel Extended Memory 64 Technology, or Intel EM64T) Why formerly? As far as I know, intel's implementation of the AMD64 extension is _still_ called EM64T. Do not confuse it with IA64 which is something completely different. They changed the name of their 64-bit extensions to x86 to Intel64 (not to be confused with IA64) a couple months back. It doesn't seem to have taken root, though, as everywhere you look it's still referred to EM64T. There was even a thread about this on one of the FreeBSD mailing lists (although I don't feel like searching for the reference). -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LDAP integration
On Wed, January 10, 2007 2:43 pm, Lamont Granquist wrote:
On Wed, 10 Jan 2007, Doug Barton wrote:
Lamont Granquist wrote:
On Wed, 10 Jan 2007, Doug Barton wrote:
And if you're looking specifically at the /etc/rc.conf config
file, what would be more useful would be an /etc/rc.conf.d/
directory.
Good news for you, we already support that. :) I agree that it
makes a great tool for the many systems problem, and could
reasonably be used for part of the dynamic laptop problem too.
7-current feature? I'm not seeing it in rc.conf(5) on my
RELENG_6-ish
system...
It's not documented, but the code is there in /etc/rc.subr:
grep 'rc.conf\.d' /etc/rc.subr if [ -f /etc/rc.conf.d/$_name ];
then debug Sourcing /etc/rc.conf.d/${_name} .
/etc/rc.conf.d/$_name
...
If i understand that correctly its not *exactly* what i was looking
for, but its better than a monolithic /etc/rc.conf
It looks like you must put /etc/rc.d/inetd config into either
/etc/rc.conf or /etc/rc.config.d/inetd.
That means that if you've got two different orthogonal applications
runing on the same server which both need to run something orthogonal
out of inetd then they still wind up needing to do edits to the same
config file to get inetd configured correctly. I'd rather see
/etc/rc.config.d/app01 and /etc/rc.config.d/app02 both able to tweak
inetd settings. Of
course there is the possibility that app01 and app02 could drop
mutually conflicting inetd setttings, but you've got that problem
anyway in the existing scheme...
To each their own, of course. Personally, I am so sick of the way
system like Debian use dozens of config files for each app, all in
their own conf.d/ sub-directories. Some apps, like PureFTPd actually
use separate config files for each and every option it supports.
Trying to configure these apps is a royal pain of opening and editing
a dozen files. Maybe this makes it easier for automated configuration
tools and GUIs, but it makes it a *ROYAL* pain in the arse for mere
mortals using text editors to manage.
What is wrong with 1 editable text file per app? With a single
sub-directory per application for config files? Where you can
quickly, and easily view all the options at a glance?
The nicest thing about FreeBSD is /etc/rc.conf, a single configuration
file that is easily editable in any text editor. Makes managing
systems remotely so simple.
Freddie Cash, LPIC-2 CCNT CCLPHelpdesk / Network Support Tech.
School District 73(250) 377-HELP [377-4357]
[EMAIL PROTECTED] [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LDAP integration
On Thursday 11 January 2007 09:56 am, Darren Pilgrim wrote: Mike Meyer wrote: In [EMAIL PROTECTED], Vulpes Velox [EMAIL PROTECTED] typed: LDAP is nice organizing across many systems, but if you are just dealing with one computer it is complete over kill for any thing. In that situation, it's not merely overkill, it's may actually be a bad idea. Can you say AIX SDR? How about Windows registry? Those system both took the approach of putting all the configuration information in a central database. This creates problems because the tools needed to examine/fix the config database require a complex environment - at least compared to a statically linked copy of ed. LDAP may not be so bad, but it still makes me nervous. On the other hand, if you've got a flock of boxes to manage, having a way to tell the rc subsystem Go read config values from this LDAP server seems like a very attractive alternative. And to think, all these years I've been wasting my time and effort using NFS and rsync to centralize the configurations of server farms. I think (Mike will have to confirm/deny) what Mike was trying to say was that for a single system, a centralised database for configuration options was overkill and a problem. Using the Windows Registry as an example. But, using a centralised database for configuring dozens of systems (similar or otherwise) could be a good idea, and that LDAP may be good in that situation (a lot of reading going on at boot to create the configs). -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LDAP integration
On Wed, January 10, 2007 2:43 pm, Lamont Granquist wrote:
On Wed, 10 Jan 2007, Doug Barton wrote:
Lamont Granquist wrote:
On Wed, 10 Jan 2007, Doug Barton wrote:
And if you're looking specifically at the /etc/rc.conf config
file, what would be more useful would be an /etc/rc.conf.d/
directory.
Good news for you, we already support that. :) I agree that it
makes a great tool for the many systems problem, and could
reasonably be used for part of the dynamic laptop problem too.
7-current feature? I'm not seeing it in rc.conf(5) on my
RELENG_6-ish
system...
It's not documented, but the code is there in /etc/rc.subr:
grep 'rc.conf\.d' /etc/rc.subr if [ -f /etc/rc.conf.d/$_name ];
then debug Sourcing /etc/rc.conf.d/${_name} .
/etc/rc.conf.d/$_name
...
If i understand that correctly its not *exactly* what i was looking
for, but its better than a monolithic /etc/rc.conf
It looks like you must put /etc/rc.d/inetd config into either
/etc/rc.conf or /etc/rc.config.d/inetd.
That means that if you've got two different orthogonal applications
runing on the same server which both need to run something orthogonal
out of inetd then they still wind up needing to do edits to the same
config file to get inetd configured correctly. I'd rather see
/etc/rc.config.d/app01 and /etc/rc.config.d/app02 both able to tweak
inetd settings. Of
course there is the possibility that app01 and app02 could drop
mutually conflicting inetd setttings, but you've got that problem
anyway in the existing scheme...
To each their own, of course. Personally, I am so sick of the way
system like Debian use dozens of config files for each app, all in
their own conf.d/ sub-directories. Some apps, like PureFTPd actually
use separate config files for each and every option it supports.
Trying to configure these apps is a royal pain of opening and editing
a dozen files. Maybe this makes it easier for automated configuration
tools and GUIs, but it makes it a *ROYAL* pain in the arse for mere
mortals using text editors to manage.
What is wrong with 1 editable text file per app? With a single
sub-directory per application for config files? Where you can
quickly, and easily view all the options at a glance?
The nicest thing about FreeBSD is /etc/rc.conf, a single configuration
file that is easily editable in any text editor. Makes managing
systems remotely so simple.
Freddie Cash
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VMWARE-Player
On Sun, January 7, 2007 7:46 am, Bill Moran wrote: Christoph P. Kukulies [EMAIL PROTECTED] wrote: does FreeBSD provide the ability to run VMWARE-Player for Linux and run VMs in it? No. To the best of my knowledge it's not possible to run any VMWare product under FreeBSD. VMWare 3 is in the ports tree. That is the latest version of VMWare that works on FreeBSD, and a lot of people are having problems running that on -CURRENT. Runs fine on 6.x though. Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Properly controlling CFLAGS/CXXFLAGS
On Wednesday 20 December 2006 07:57 pm, Garrett Cooper wrote:
Hello,
Coming from Gentoo we were taught how to 'rice' our machines.
Based on my experience though with FreeBSD, this is an improper
methodology for one to use.
I was wondering (looking at the make.conf manpage), what's the
best way to control one's CFLAGS/CXXFLAGS. I'd prefer if only a few
ports would have optimized compiler flags, while the rest of the system
used a safe set of compiler flags.
So, I was wondering what the best course of action for setting
variables in /etc/make.conf would be? Is this proper given what I'm
trying to accomplish:
/etc/make.conf snippet:
CFLAGS= -O2 -pipe
CXXFLAGS= ${CFLAGS}
COPTFLAGS= ${CFLAGS} -msse -msse2 -mfpmath=sse,387
NO_CPU_CFLAGS=YES
NO_CPU_COPTFLAGS=YES
CPUTYPE?=pentium4
My suggestion is to leave all mention of *CFLAGS out of /etc/make.conf to
use the system defaults (-O2 -pipe -fno-strict-aliasing), set CPUTYPE
accordingly, and install sysutils/portconf.
That gives you a separate /usr/local/etc/ports.conf file where you can set
global and per-port settings that are only used when compiling things
under /usr/ports (actually $PORTSDIR).
--
Freddie Cash
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [patch] rm can have undesired side-effects
On Monday 30 October 2006 01:17 pm, Mike Meyer wrote: In [EMAIL PROTECTED], Doug Barton [EMAIL PROTECTED] typed: Simon L. Nielsen wrote: Personally I think rm should do what you ask it to do - if you ask it to overwrite a file which has multiple links, well... though luck. It's all well and good to say, tough luck, but I don't think that's what our users expect. I'm a user. It's what I expect. If I wanted an OS that protected me from myself, I wouldn't be running Unix. Please give me the rope I need to get the job done. If that happens to be enough that I can hang myself, and I sometimes do - well, I got what I asked for. When I want to be coddled, I'll run a different OS. Isn't that what the -f option is for in every command? By default, be conservative in what you do (error out with nice messages when in doubt). If the user knows what they are doing then let them specify -f. -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Email recommendations
On Mon, October 30, 2006 4:51 pm, [EMAIL PROTECTED] wrote: I get a LOT of corrupt mailboxes. Just 187 mailboxes and daily problems. It's always the same error in the log files: -ERR Unable to process From lines (envelopes), change recognition modes. I've done some research and don't know any more about where the problem lives than I did before. I know that some From: lines are missing the colon, but I don't know why. Can anyone recommend a more forgiving popper or MTA? I'm running QPOP 2.53 and Sendmail 8.13.6. If this is your own server, I'd recommend switching to Postfix and using Maildir for message storage. The problem with mbox format message stores is that only 1 process can be writing to the file, which stores *all* messages for a folder. If you are receiving a new message while deleting an existing one, all kinds of nasty things can happen. If you need POP3 (I'd recommend going with IMAP instead) then look at Courier, Dovecot, or Cyrus. They provide nice, fast, stable, Maildir-support with POP3 and IMAP daemons that access the same folders. Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LSI-MegaRAID 150-4 BTX Halted on 5.4, 5.5, 6.1
On Mon, August 21, 2006 9:12 pm, Carroll Kong wrote: I am trying to install FreeBSD on a new Intel Server SE7230NH1-E using a PCI-X riser card on the Intel S1475 chassis, pentium D 3.2 gig dual core proc 940. Whenever I try to install using the CDROM for 5.4, 5.5, and 6.1... BTX halts immediately. The second I remove the card, the system boots up fine. In fact, I was able to install 6.1 on one of the SATA disks on there. However, once I put the card back, BTX Halts. BTX Halts even if I remove all logical drives on the array (making it completely empty and it does not show up as a disk at all in the BTX Bios). I even disabled the card's BIOS mode, and it still halts. Since FreeBSD 5.4 supports the LSI Megaraid 150-4, I suspect it might be the riser card doing interesting things. We had no end of trouble getting LSI MegaRAID 150-6 cards working with Tyan K8SD (S2882) motherboards when using riser cards. Didn't matter if we used Debian (stable and testing with the 2.6.12 and 2.6.15 kernels) or FreeBSD 6.0. If we plugged the RAID controller directly into a PCI-X slot on the motherboard, no problems whatsoever. Everything installed and ran correctly. But, if we plugged the RAID controller into a riser card on the same motherboard, nothing worked. The controller would lose disks, would lose arrays, would report read and write errors, and would rarely let us complete an install of either Debian or FreeBSD. We gave up trying to get the MegaRAID cards to work with riser cards, and returned them all to the vendor in exchange for 3Ware Escalade 9550SX cards. These have been working great plugged into the same riser cards that gave the MegaRAID controllers so many problems. Considering the ATA controllers on the MegaRAID cards (they're SiI chipsets), and all the issues we had with them, my suggestion would be either not use a riser card with that controller, or get a better RAID controller. Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SATA300 Controllers
On Wed, July 5, 2006 6:02 pm, Derrick T. Woolworth wrote: Sorry for cross-posting, but these issues seem relevant for lists... Has anyone had success with SATA300 controllers with FreeBSD 6.1? I've been trying Promise and nVidia nForce4 and I'm not having any luck. Using a MSI K8NGM2-L motherboard and others, but 6.1's Considered getting a real, server-class motherboard with a server-class chipset on it? Something using an AMD 8000-series chipset, or a ServerWorks chipset, or even (as a last resort) an Intel chipset? Something other than nVidia and Ati. :) We're got several dozen servers (tower and rackmount) using Tyan S2882 motherboards, with 3Ware Escalade 9550SX RAID controllers. Running FreeBSD 6.1 on a 12x 400 GB SATA HD RAID5 array was fun. :) 4 TB of usable diskspace. Unfortunately, it was reformatted with Debian Linux before being put into production. Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Spam from NAT boxes
On Mon, March 6, 2006 3:17 pm, Julian Elischer wrote: Cesar wrote: I have some NAT boxes running FreeBSD, each of these boxes do NAT for like 100+ people. Almost everyday my IPs got blacklisted because of spam. I cant block the smtp traffic going out became some people need it to send true e-mails. Are there any tool to detect/block those spams? I tought in a program that receive the connection diverted/forwarded by ipfw and then deliver it to SpamAssassin ... I also have an e-mail server fully configurated with anti-spam, anti-virus ... I tried forward to this e-mail server all my NAT box tcp connections to port 25. ipfw add fwd xx.xx.xx.xx,25 tcp from 192.168.0.0/24 to any 25 I got some matches in this rule when I try to send an email, but I didnt get redirected to my email server. Install an SMTP server on the firewall. Configure it to listen to 127.0.0.1:25 only. Configure it to relay all messages it receives to the SMTP server that runs virus/spam filters. Then add the fwd rule to forward all outgoing messages to the local SMTP server. This is the setup we use. We have a central mail/virus SMTP gateway that handles all incoming and outgoing spam/virus filtering. All outgoing port 25 traffic at the NAT'd sites is redirected to an SMTP server on the firewall, then redirected to the mail gateway for scanning, then out to the Internet. Works like a charm. The other nice thing about this setup is that you can trace the received from: headers all the way back to the originating computer if there are problems. Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [fbsd] Re: DragonFly talk at the upcoming BAYLISA (15 December 2005)
Yah, I'm putting some slides together and will make them available after the talk. We are after the talk, have you put the slides online or do you plan to issue them after Christmas and New Year ? They're available on the DragonFlyBSD website. -- Freddie Cash, LPIC-1 CCNT CCLPHelpdesk / Network Support Tech. School District 73(250) 377-HELP [377-4357] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bash scripting -- Usage of arrays
On November 29, 2005 01:09 pm, Jayesh Jayan wrote: Today I was trying to script using arrays in FreeBSD 5.4 but it doesn't work. Below is a sample script which I used. ** #!/bin/bash array=( zero one two three four); echo Elements in array0: [EMAIL PROTECTED] ** It works fine on RedHat server. Below is the output. # sh array.sh Elements in array0: zero one two three four /bin/sh on Linux is actually /bin/bash. Below is the out put from the FreeBSD server using the same code. -bash-2.05b# sh aa.sh aa.sh: 3: Syntax error: word unexpected (expecting )) /bin/sh on FreeBSD is /bin/sh, the original Bourne shell. It doesn't use that syntax Please guide me on how to use arrays on freebsd too. Install the bash1, bash2, or bash port and use /usr/local/bin/bash to execute the script. Works correctly on my 5.4 and 6.0 systems using the bash-emulation in zsh. -- Freddie Cash, LPIC-1 CCNT CCLP Helpdesk / Network Support Tech. School District 73 (250) 377-HELP [377-4357] [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x
On October 26, 2005 10:22 am, Bill Studenmund wrote: On Mon, Oct 24, 2005 at 10:35:47PM +0200, Hans Petter Selasky wrote: Main features: - Implements FreeBSD's devfs on NetBSD. In the past, we (NetBSD folks) have talked about a devfs. One issue that has come up (I'll be honest, I've raised it a lot) is a desire to retain permission changes across boots, and to tie devices (when possible) to a device-specific attribute rather than a probe order. FreeBSD 5+ has /etc/devfs.conf and /etc/devfs.rules which include information regarding permissions and ownership for device nodes under /dev. These files can even be used for creating fancy names for devices using symlinks (like /dev/burner for CD-RW devices, or /dev/floppy and so on). At boot time, /etc/devfs.conf is read, and /etc/devfs.rules is read whenever new devices are attached to the system (I believe that's how it works, anyway). Is that what you're looking for? Does FreeBSD's devfs support locators and persistent information? Are there plans to support something like that, if not? -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: system password's file
On October 13, 2005 09:29 pm, Jayesh Jayan wrote: I would suggest you to try the below and make sure this works 1 ) Install a new freebsd server 2 ) create a user on your linux machine say with username freebsd and some password 3 ) now copy the data in your /etc/passwd file of linux machine to freebsd machine 4 ) Also copy the /etc/shadow file to freebsd server and renmae it as /etc/master.passwd Don't do this, you'll kill all the accounts on your system. 5 ) Also copy /etc/groups 6 ) Now try to login to freebsd machine with the new user created on the linux machine. If you search the OpenBSD FAQ, you'll find the correct process to take to convert Linux users to BSD users. It's a very quick awk script, and it works quite nicely. I used it to convert 500 users on a RedHat 6.2 system to a FreeBSD 5.3 system without any hiccups. -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with ath(4) and Netgear WG311T card
On August 31, 2005 10:42 am, Alexander Best wrote: I just bought myseld a new wlan card called Netgear WG311T (ath(4) lists it as being supported). Here's the ouput of `pciconf -lv`: Lots of great info follows, but you forgot the most important part: version of FreeBSD this is running on. :) There have been updates the the Atheros HAL between FreeBSD versions 5.3, 5.4, and 6.0. Each update supports more Atheros revisions. The last time I saw that message was when I purchased a new NetGEAR WG511T last August card and tried running it on FreeBSD 5.3. An update to 6-CURRENT shortly thereafter allowed it to work attach and work. -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kpdf and -march=pentium4?
I noticed that while making kdegraphics from ports, if -march=pentium4 is in the compiler flags, I will finally get a non-working kpdf. It compiles fine but when I try to open a pdf file, kdpf will core dupm. But a kpdf compiled without -march=pentium4 will work just fine. For this reason, should we put something in kdegraphics3's Makefile to prevent a bad kdpf? E.g. a patch like this: kdegraphics3 compiled with CPUTYPE=p4, CGLAGS=-Os -pipe -fno-strict-aliasing works fine here. Worked with KDE 3.3.x, and still works with KDE 3.4. I've tested it with small PDFs (2 or 3 pages) and large PDFs (30+ pages), and everything works fine for me. -- Freddie Cash, CCNT CCLPHelpdesk / Network Support Tech. School District 73 (250) 377-HELP [377-4357] [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sched_4BSD
On March 2, 2005 12:09 pm, Julian Elischer wrote: NPTL? New Pthreads Library from Library? isn't that GPL'd? Native Posix Threads Library All I know about it is the name. :) -- Freddie Cash, CCNT CCLPHelpdesk / Network Support Tech. School District 73 (250) 377-HELP [377-4357] [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to clean out old files after 'make world'?
At 10:23 PM +0300 7/20/04, Stas D.Myasnikov wrote: ... I had thought that install script removes all unneeded files, but it don't. How can I clean out this old binaries, configs, etc?.. Is there any automatic way to do this? You can: make cleanworld which does a fairly decent job of getting rid of all the old files in your build area (e.g., in /usr/obj/usr/src). That only cleans out the /usr/obj directory tree. It doesn't remove any files from anywhere else in the system. However, I am not sure if you are asking for more than that. He wants to install FreeBSD, edit make.conf and uncomment a bunch of NO_* variables to prevent them from being built/install during a world build, and wants to have a way to remove the existing files from /bin, /sbin, /usr/bin, etc. Check the How-To forum at http://www.bsdforums.org/forums/ One of the members there posted a set of scripts that will parse the NO_* variables in make.conf, and remove any and all files associated with those subsystems from an installed system. The end result is the same as building a custom release and reinstalling using that release to only get the bits you want, but without all the hassle of building a custom release. :) -- Freddie Cash, CCNT CCLPHelpdesk / Network Support Tech. School District 73 (250) 377-HELP [377-4357] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
