Re: What happened to nslookup?
On Wed, 16 Oct 2013, Daniel Kalchev wrote: On 16.10.13 08:42, Kevin Oberman wrote: nslookup(1) was deprecated about a decade ago because it often provides misleading results when used for DNS troubleshooting. It generally works fine for simply turning a name to an address or vice-versa. People should really use host(1) for simple lookups. It provides the same information and does it in a manner that will not cause misdirection when things are broken. Of course, host(1) is not a replacement for nslookup(1). nslookup is interactive, while host is not. This makes for a big difference in many usage scenarios. The version of nslookup on FreeBSD systems I've used had no command line history or editing (even ntpdc has this now), gave results that were not always in line with other tools (ldns, drill, host etc.), and to do a host lookup inside the nslookup shell you had to type ... host :-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: rcs
On Tue, 8 Oct 2013, Adrian Chadd wrote: I think that's great. But, as we are increasingly finding, theres no stable ports snapshot, so unless we as a project change how packages are managed, there may not really be a stable, predictable version of things once they're moved from base to a package. A number of users and companies like that there is a very strict definition of base and that it wont change as the ports tree changes. Eg, you install 10.0 and get the rcs package from that. You then do an install of 10.0 a yeat later and install rcs. If it comes from the 10-stable pkgng set, itll pick up the latest version, not the 10.0 version. Thats the big ports vs base difference. Perhaps a perl style dual life module set of core (errm BASE?) packages/ports will emerge. It could resolve some of the perennial what is BASE? debates - or at least make it possible to have those debates in a different way :-) My understanding is that dealing with the GPLv3 issue for BASE is *necessary* for the project. Since the latest rcs releases are licensed using GPLv3, FreeBSD's BASE rcs (GPLv2) would have to be maintained exclusively by the FreeBSD project - which means more developer overhead (the same could be said for gcc I suppose). That seems to be a different type of issue than the size/completeness of BASE itself. Since rcs is a small utility, it's hooked into a script or two via rc.subr, it's useful to a lot of folks, it doesn't face the network and there's a BSD licensed equivalent sort of available, then maybe the best way to go would be to import opencvs's rcs (which is not part in the ports version of opencvs) to replace the GNU version. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: MPSAFE VFS -- update
On Mon, 22 Oct 2012, C. P. Ghost wrote: On Thu, Oct 18, 2012 at 7:51 PM, Attilio Rao atti...@freebsd.org wrote: Following the plan reported here: http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS We are now at the state where all non-MPSAFE filesystems are disconnected by the three. Sad to see PortalFS go. You've served us well here. :-( It is kinda neat. How do/did you use it? portalfs seems to have around a 10th of the LoC than MSDosFS and the changes made to make MSDosFS MPSAFE are documented on the above page: is it just that portalfs is too obscure to have a maintainer? Thanks to all for the work on MPSAFE-ty ;-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Why Are You NOT Using FreeBSD?
On Tue, 5 Jun 2012, Mark Linimon wrote: It's not particularly easy to see this on cvsweb. But let's take a look at a random Mk/bsd.*.mk file via 'cvs log': RCS file: /home/FreeBSD/pcvs/ports/Mk/bsd.apache.mk,v Working file: bsd.apache.mk head: 1.36 branch: locks: strict access list: symbolic names: RELEASE_8_3_0: 1.35 RELEASE_9_0_0: 1.33 RELEASE_7_4_0: 1.26 RELEASE_8_2_0: 1.26 RELEASE_6_EOL: 1.26 [...] RELEASE_6_1_0: 1.9 RELEASE_5_5_0: 1.9 [...] and so forth. The line RELEASE_8_3_0: 1.35 tells you the version of this file as of tag RELEASE_8_3_0 was r1.35. So that's what's on the 8.3R distribution media. Is there any way to access this information using tools like pkg_* pkgng or ports make targets? Or does one use cvs/svn? ps: Thanks all for your work on ports! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Switch from legacy ata(4) to CAM-based ATA
On 04/20/2011 05:57, Alexander Motin wrote: Hi. With 9.0 release approaching quickly, I believe it the best time now to manage migration from legacy ata(4) ATA to the new CAM-based one. New ATA code present in the tree for more then a year now, used by many people and proved it's superior functionality and reliability. The only major issue with it now is the migration process. Sooner or later we have to pass it, but due to major UI and API changes we can't do it after 9.0 release. So I propose to do it the next Sunday (April 24) to have as much time for troubleshooting as possible. I have prepared the following patch to do it: http://people.freebsd.org/~mav/ata_switch.patch I haven't added geom_raid to the kernel configurations because we have no other GEOM classes there. But tell me if you thing I should. If somebody has any problems with new ATA stack, please repeat your tests with latest HEAD code and contact me if problem is still there. Next three weeks before BSDCan I am going to dedicate to fixing possibly remaining issues. Will camcontrol replace atacontrol and somehow magically recognize the atacontrol command set (list, status, info, attach/detach,etc.)? I haven't tried CURRENT for a while but I seem to recall that when I tried switching over to using CAM-based ATA there were some tricks one had to do in order to pass atacontrol commands through CAM and it didn't always work. The subcommands for camcontrol seemed to be more SCSI-ish and passing raw commands was subject to numerous local PEBKAC issues. cheers, ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS v28 is ready for wider testing.
On 09/02/10 17:48, Pawel Jakub Dawidek wrote: On Tue, Aug 31, 2010 at 11:59:15PM +0200, Pawel Jakub Dawidek wrote: [...] Ok, now that I know you read everything carefully, here is the patch: http://people.freebsd.org/~pjd/patches/zfs_20100831.patch.bz2 Now it is even easier to test new ZFS! :) Here you can find VirtualBox Appliance (113MB) with FreeBSD 9-CURRENT and ZFSv28: http://people.freebsd.org/~pjd/misc/FreeBSD9_ZFSv28_0.1.tgz Untar it, import it (zfsv28.ovf) to VirtualBox and have fun. Wheee! Is there anyway to simulate a disk failure on VBox? Does one simply rm/mv the .vmdk files on the host system? Inside the virtual machine I'm unable to get camcontrol to do anything (the SATA drives are AHCI so we don't want atacontrol correct?) that would simulate this. Great work putting this together. Thanks. cheers ps: I'm pretty sure it worked once but now I am not having much luck with zpool split. Possibly a PEBKAC. I think there are manual page patches for all the new features include with each of Sunoracle's PSARCs but they don't all appear on the manual pages included with the vbox image (??) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
