Re: donation : money : small amount : recurring
A DragonFly BSD Paypal account has been established at pay...@dragonflybsd.org, Matthew Dillon will maintain primary ownership of the account. Some pre-existing funds that were earmarked for DragonFly are being moved into this account, which will be used to fund future hardware acquisitions by the project, code bounties and/or contract development and potentially to defer other ongoing costs. The project is not able to accept tax-deductible donations at this time (as pointed out elsewhere in this thread) but I will continue to investigate our options and opportunities in this regard. There has been ongoing discussion about organizing the DragonFly finances in some fashion for some time but I am not sure we realized until this thread that there was some interest by end-users in making monetary contributions (as opposed to code and documentation), so thanks all for bringing this front and center. Sam On Tue, Jun 26, 2012 at 5:24 AM, Mayuresh Kathe wrote: > > how to? > >
Re: Failure to allocate contiguous memory
On Fri, Mar 23, 2012 at 7:41 PM, Kyuupi wrote: > I have jerky window dragging where repainting is very slow. > > I believe it is because DRI is not working with my graphics card, in turn > because of a failure to allocate contiguous memory. > > Relevant snippets of dmesg below. Is there something I can do to fix this? > > I'm using kernel source as of about 48 hours ago. > > Neil. > > DragonFly v2.13.0.381.gca541-DEVELOPMENT #0: Sun Nov 27 12:27:02 JST 2011 > r...@athlon2.akihabara.co.uk:/usr/obj/usr/src/sys/X86_64_GENERIC > > CPU: AMD Athlon(tm) Dual Core Processor 5050e (2600.16-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 > > Features=0x178bfbff MOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> > Features2=0x2001 > AMD Features=0xea500800 > AMD Features2=0x11f > real memory = 4025809920 (3839 MB) > avail memory = 3718107136 (3545 MB) > > DMA space used: 2540k, remaining available: 16384k > Mounting devfs > drm0: on vgapci0 > vgapci0: child drm0 requested pci_enable_busmaster > info: [drm] Initialized radeon 1.31.0 20080613 > contigmalloc_map: failed size 16777216 low=0 high= align=4096 > boundary=0 flags=0102 > contigmalloc_map: failed size 16777216 low=0 high= align=4096 > boundary=0 flags=0102 > pid 27585 (conftest), uid 0: exited on signal 11 > Warning: busy page 0xffe0036c39a8 found in cache > > >From the drm(4) manpage: If Xorg(1) acceleration fails to initialize with a ``contigmalloc_map: failed size...'' error in dmesg, the reserve of memory for DMA ran out early and should be increased to a sufficiently high value by setting the vm.dma_reserved loader tunable. A read only sysctl(8) variable of the same name is provided for obtaining its current value. Sam
Re: upgrade i386 --> x86_64?
> > On a related note, I found a GSoC project to implement a i386 ABI for > x86_64 kernel. I wonder what is the status of this? > > Peeter > No students have attempted it. Sam
Re: upgrade i386 --> x86_64?
On Mon, Mar 19, 2012 at 10:25 AM, peeter (must) wrote: > On Mon, Mar 19, 2012 at 2:26 PM, Nikolai Lifanov > wrote: > > On 3/19/2012 6:54 AM, peeter (must) wrote: > >> > >> Hi all > >> > >> I wonder if there's a way to (cross) compile an x86_64 system on a > >> i386 one, ie upgrade 2.10_i386 to 3.0_x86_64? > >> > >> Thanks, Peeter > >> > >> -- > > > > From what I understand, it's not trivial to perform this upgrade. You > should > > be very careful when clobbering your userland. Neither kernel can run the > > other world. > > > > Thanks, seems better avoid this. > > Peeter > > -- > Probably the best/fastest/safest way would be to boot an x86-64 installation image and install over the top of the existing system, then you will have to rebuild all packages, you can get started by pkg_radd'ing git and friends. Sam
Re: cross-Compiling DFBSD on an Ubuntu machine.
On Sun, Mar 11, 2012 at 1:32 PM, Alex Hornung wrote: > On 11/03/12 18:14, karim.allah.ah...@gmail.com wrote: > > I've an Ubuntu machine ( oneiric ), Is it possible to cross-compile > DFBSD ? > > In a nutshell: no, it isn't possible. > > Cheers, > Alex > To clarify: the build infrastructure would probably support it, perhaps with minor modifications -- IF you had a properly working cross-compiler and you were able to bootstrap all of the dependencies up through the cross-tools build stage with that compiler on Linux. Nobody has done this to my knowledge, so probably it would be a fair amount of work to actually get it all working. Best, Sam
Re: Raspberry Pi
On Mon, Mar 5, 2012 at 6:30 PM, Pierre Abbat wrote: > How hard would it be to port DragonFly to the ARM and run it on a Raspberry > Pi? > > Pierre > -- > ve ka'a ro klaji la .romas. se jmaji > I have never ported an operating system kernel, so this is merely educated speculation based on the amount of time I have seen other ports take. I would say given someone who is familiar with the ARM ISA and is comfortable with BSD kernel internals and using the FreeBSD/NetBSD arm ports as a reference -- count on something like 1200-2000 man hours. Again, that's just a rough guess, but it's definitely not a small or easy project. Sam
Re: 3.0 release this weekend
> > > I don't know if it [KDE] installed completely in 2.10, come to think of it. > > The KDE versions in pkgsrc are grossly out of date. Users should actually have better luck compiling newer KDE version by hand from the KDE repo's directly, because of work Alex H. did getting DragonFly patches into upstream. Sam
Re: -mpreferred-stack-boundary=2 is not between 4 and 12 on RELEASE_3_0
On Mon, Jan 23, 2012 at 10:39 PM, Siju George wrote: > /usr/src/sys/platform/pc32/i386/genassym.c:1: error: > -mpreferred-stack-boundary=2 is not between 4 and 12 > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/GENERIC. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > You have new mail. > dfly-bkpsrv1# uname -a > DragonFly dfly-bkpsrv1.hifx.local 2.13-DEVELOPMENT DragonFly > v2.13.0.332.g9855a4-DEVELOPMENT #0: Sun Nov 20 09:45:34 UTC 2011 > r...@pkgbox64.dragonflybsd.org:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64 > You have new mail. > dfly-bkpsrv1# git branch > * DragonFly_RELEASE_3_0 > master > > You have reported this before, it isn't a bug. You need to build X86_64 kernel config's on X86_64. Sam
ISDN
All, Do you, as one of DragonFly's users or developers, currently use our ISDN support or have _specific_ plans to use our ISDN support in the not-handwavy-distant future? Thanks, Sam
Re: Request for suggestion for setting up a server with 4 HDDs
Mirror, slightly dated it seems: http://dragonflyweb.evilprojects.net/ Sam On Tue, Dec 27, 2011 at 1:54 AM, Zenny wrote: > Thanks for the pointer, but again the dragonflybsd site is down (GMT > 08:53:45 Decemeber 27, 2011) to access the link Justin pointed to: > leaf.dragonflybsd.org/mailarchive/commits/2009-12/msg00068.html. :-( > > On 12/26/11, Siju George wrote: > > On Fri, Dec 23, 2011 at 5:18 PM, Zenny wrote: > >> I could figure out how to create > >> a Master and Mirror between 2 HDDs, but could not figure out with 4 > >> HDDs (2TB of each) with SATA interfaces. > >> > > > > if you are talking about pfs mirroring then you can add the other hard > > disks to the master and mirror using > > > > hammer volume-add > > > > http://www.shiningsilence.com/dbsdlog/2009/12/09/5142.html > > > > Thanks > > > > --Siju > > >
Re: What is the minimal memory requirement for HAMMER?
On Tue, Dec 20, 2011 at 10:39 AM, Zenny wrote: > Hi: > > I am trying to experiment with HAMMER with a spare PIII/500Mhz old > machine with 256MB of RAM. I installed the RELEASE-2.10 version of > DFBSD. But when I try to execute "hammer cleanup", it spits out an > error that reads: > > "hammer: System has insufficient buffers to rebalance the tree. nbuf < > 3969" > > However, when I checked in the archive of the mailinglist > (http://leaf.dragonflybsd.org/mailarchive/users/2010-03/msg00057.html), > it states that 128MB is the minimal requirement, right?! > > In that case the hw that I am using exceeds the minimal requirement > and still spits out the error, which reportedly due to the low memory > (http://leaf.dragonflybsd.org/mailarchive/users/2011-05/msg00074.html) > > Please throw some light! (Very dark here in Scandinavia during winters > like this) ;-) > That isn't an error, just a warning. You do not have enough memory to rebalance the tree, but this will not greatly affect your HAMMER experience. Sam
Re: dragonfly bsd and vkernels
On Thu, Dec 8, 2011 at 1:51 AM, Joe Gain wrote: > Hi everyone, > > this is a really general question, but I'm just starting my bachelor thesis, > which is going to have something to do with virtualization (probably network > virtualization) and I was just wondering how dragonfly bsd's kernel > virtualization fit's into the virtualization scene? How would vkernels fit > into categories like full-virtualization (Qemu), paravirtualization (Xen), > and O/S virtualization (Jails)? Also, are vkernels mainly for kernel > development (and sandboxing), or do people also use them to create virtual > machines for running servers, routers, clustering etc.? > > The Wikipedia article about User-mode Linux says: > >> User-mode Linux is generally considered to have lower performance than >> some competing technologies, such as Xen and OpenVZ[citation needed]. Future >> work in adding support for x86 virtualization to UML may reduce this >> disadvantage. >> >> Often cited as a strength of Xen (a competing technology) is support for >> Thread Local Storage (TLS). This is now also supported in the latest UML >> kernels. Xen concentrates on virtualizing the whole machine, and thus all >> systems running on a Xen machine are really virtual machines. In UML, the >> host machine is not virtualized in any way, and only guest systems are true >> virtual machines. > > > And the Wiki article about dragonfly bsd says: >> >> The virtual kernel is run in completely isolated environment with emulated >> network and storage interfaces, thus simplifying testing the drivers, kernel >> subsystems and clustering features. > > > And in an article from 2007, on the Kernel Trap site, one of the major goals > of dragonfly bsd is said to be: >> >> My primary goal is to eventually have a fully cross-machine coherent and >> transparent cluster OS capable of migrating processes (and thus the work >> load) on the fly. Doing this properly requires direct, integrated support in >> the kernel. We are probably two years away from accomplishing this goal. > > > Can anyone say how this part of the project is developing? What are the > competing products and how would dragonfly bsd like to fit into this market? > > Thanks, > > Joe > > PS. I'd be happy to update the wiki page with any relevant new information! > > -- > joe gain > > jacob-burckhardt-str. 16 > 78464 konstanz > germany > > +49 (0)7531 60389 > > (...otherwise in ???) These two articles on LWN cover the vkernel architecture in detail and will probably answer a lot of your questions. http://lwn.net/Articles/228404/ http://lwn.net/Articles/230658/ In terms of where it sits compared to other technologies, it is most similar to UML, but also Xen PVM, minus all the actual hardware emulation aspects of Xen PVM. Vkernels are mostly used for kernel development and testing, but also certainly for isolation. SSI aka "fully cross-machine coherent and transparent clustering" is not being actively pursued, but filesystem clustering is. There is no ETA. Competing products? I do not believe the project as a whole has any commercial aspirations, we're just trying to build a system that is stable, useful and highly performing. A clustering file-system is believed to fill the useful aspect. Sam
Re: Is anyone still using gcc 4.1 on master?
On Mon, Nov 7, 2011 at 9:04 PM, Juan Francisco Cantero Hurtado wrote: > On 11/07/2011 10:50 PM, Samuel J. Greear wrote: >> >> Our C++ dependencies would not be that difficult to overcome and I >> do not see why the system compiler should necessarily have to >> support pkgsrc directly. > > What C++ software or dependencies has DragonFly? I'm curious. > > Answered in the context of, "What C++ dependencies does DragonFly have and how hard would it be to remove them?" devd(8), groff(1) and binutils gold, we have a C binutils as well though so that is not a hard requirement. mdoc is already staged up to replace groff, someone just needs to put in the labor to get it done. devd is 1200-1300 lines of C++, only part of which is "classy", it should be a straightforward port to C. If someone really wanted to rid DragonFly of its C++ dependencies, it would be fairly easy to do so given how things sit right now. Sam
Re: Is anyone still using gcc 4.1 on master?
On Mon, Nov 7, 2011 at 12:51 PM, John Marino wrote: > On 11/7/2011 8:03 PM, Samuel J. Greear wrote: >>> >>> pcc is not a candidate. >> >> Sorry, I disagree, although I understand if you aren't going to be the >> one to port it. >> >> Sam > > I don't understand that sentence. Are you saying you or somebody else is > going to port pcc into base? A compiler that don't do c++? > Our C++ dependencies would not be that difficult to overcome and I do not see why the system compiler should necessarily have to support pkgsrc directly. If you account for the entire history of DragonFly there have been long periods where the compiler was not updated, and not for lack of need but for lack of knowledge and/or manpower. _I_ feel that the best approach for the overall long-term health of the project would be to kill off our (very minimal) C++ dependencies and use a small, simple and easy to reason about C compiler that most or all of the C developers which DragonFly attracts can work on and fix. There are numerous options for distributing/bootsrapping GCC, clang or $othercompiler to support pkgsrc. I do not expect everyone to agree, but I do not think the position of the project as a whole is against someone working in support of pcc and I wanted to make sure that your comment was not construed as being the concrete position of the project. Sam
Re: Is anyone still using gcc 4.1 on master?
> pcc is not a candidate. Sorry, I disagree, although I understand if you aren't going to be the one to port it. Sam
Re: onboard sound
On Mon, Oct 31, 2011 at 10:33 AM, Alex Hornung wrote: > Devices are automatically created by devfs. MAKEDEV is obsolete. > > If you don't know which sound driver is the one you need, there is a > pseudo-driver that depends on all others (sound.ko, iirc). If you load > that, and you still don't get /dev/dsp and family, then odds are we > don't support your card. > > Cheers, > Alex > kldload snd_driver for the pseudo-driver. Sam
FreeNAS Port? (Was: Re: Does something like nanobsd.sh exist or in the making for DF?)
On Fri, Oct 28, 2011 at 10:02 PM, Gonzalo Nemmi wrote: > Pretty much on spot .. yesterday I was on #dragonflybsd asking it > there was any interest on working on a DragonFlyBSD version of FreeNAS > ... The first thing someone would want to do is fully implement and get working well a couple of raid modes, the only real actual use-able software option in the tree at the moment is vinum. Until such time I don't know if it makes a lot of sense to port FreeNAS over. Sam
Re: kqueue does not set EV_EOF flag
2011/9/6 Andrey N. Oktyabrski : > Good day. > > I have some problems between nginx and backends. Nginx can not see when the > backend closed connection. The nginx developers said there is a kqueue > problem. They wrote test program (attached), which works well under the > FreeBSD and NetBSD, but do not work properly under DragonFly. > > Using "select" or "poll" methods in the nginx solves the problem, but kqueue > is preferred. > > $ uname -iprs > DragonFly 2.10-RELEASE x86_64 X86_64_GENERIC_SMP > Andrey, Thank you very much for providing a test case, I will follow up on this as time permits. Sam
Re: Linux ldconfig segfaults
On Sun, Aug 7, 2011 at 10:59 PM, Pierre Abbat wrote: > I just tried to run a Linux program on DragonFly. I got the following: > > -bash-4.1$ /usr/pkg/emul/linux/bin/bash > ELF interpreter /lib/ld-linux.so.2 not found > Abort trap: 6 > > I then checked the man page and found that I need to run ldconfig. So I did > and got this: > > # /compat/linux/sbin/ldconfig > Segmentation fault (core dumped) > > kldstat shows that the Linux module is loaded: > > # kldstat > Id Refs Address Size Name > 1 17 0xc010 88a9d4 kernel > 2 1 0xc098b000 26ce4 linux.ko > 3 1 0xc09b2000 78d04 acpi.ko > 4 1 0xc0a2b000 134cc ahci.ko > 5 1 0xc0a3f000 97cc ehci.ko > 6 2 0xc0a49000 b9f8 dm.ko > 7 1 0xcc6ad000 a000 linprocfs.ko > 8 1 0xcd05 9000 i915.ko > 9 1 0xcd059000 13000 drm.ko > 10 1 0xcd44 18000 dm_target_crypt.ko > 11 1 0xd3a5d000 12000 ext2fs.ko > > So what's wrong? Here's my uname: > > DragonFly darner.ixazon.lan 2.11-DEVELOPMENT DragonFly > v2.11.0.203.g0e5ac-DEVELOPMENT #2: Mon May 16 09:57:06 UTC 2011 > r...@darner.ixazon.lan:/usr/obj/usr/src/sys/GENERIC_SMP i386 > > Pierre > -- > lo ponse be lo mruli po'o cu ga'ezga roda lo ka dinko > Probably caused by a bug in linux ldconfig, possibly tickled by something we do not implement or that we implement differently. The easiest way to find out what is wrong is to debug it like any other program and see why it crashed and/or what it was doing right before it crashed. Sam
Re: HEADS UP: GENERIC and X86_64_GENERIC now have 'options SMP'
On Tue, May 24, 2011 at 6:17 PM, Venkatesh Srinivas wrote: > Have there been any measurements as to performance penalties with > 'options SMP' on uniprocessor systems? > > -- vs > Not AFAIK, but quantifying the damage should be a definite prerequisite before eliminating the SMP option altogether -- though that is not on the table for at least another release. Sam
HAMMER/Samba shadow copy module
I started on this, but probably won't have time to go any further with it for at least several weeks -- if anyone wanted to pick it up and run with it, it should be pretty self-explanatory. https://github.com/thesjg/samba3_hammer_shadow_copy Best, Sam
DragonFly BSD / Google Code-In 2010 final report
During the Recent Google Code-In there were a total of 2167 tasks successfully completed by the 13-18 year old students. DragonFly's portion of these amounted to 72 successfully completed tasks, or around 3.3% of the total. Slightly lower than a perfect proportion considering there were 20 projects participating. In my estimation, however, we did quite well considering that tailoring tasks of the caliber required in order to benefit an operating system to 13-18 year old minds is quite challenging. That said, a number of students were able to tackle reasonably large and complex tasks that many of us (mentors) would not have thought feasible, if even possible, at the start of the program. Overall, I believe the outcome of the program is as good as any of us could have hoped. As mentioned in previous status emails, the documentation tasks received a wholly underwhelming response. When the program opened DragonFly had around 35-40 tasks, roughly half of these were documentation work, with the other half being code-related. Now, after the close of the program, there are 72 completed tasks, mostly code related, while 20 tasks went uncompleted or unclaimed. Nearly all of these unclaimed tasks are of the documentation variety, and many simply sat dormant the entire duration of the program. Prior efforts invested in organizing and maintaining the various project pages on the DragonFly BSD wiki proved invaluable in the specification of a number of the tasks successfully completed during the program. I believe that more effort spent defining worthwhile tasks and specifying them in such a way that they may be broken down into bite-size units of work would easily pay dividends if the project were to participate in a program of this type in the future. Brief notes on the completed projects: - EXAMPLES sections were written for the setitimer(2), getsockopt(2)/ setsockopt(2), socket(2)/accept(2)/bind(2)/connect(2), sendfile(2), writev(2), select(2), poll(2), fork(2), send(2)/recv(2), mmap(2), setjmp(3)/longmp(3), dladdr(3)/dlinfo(3)/dlopen(3), directory(3)/scandir(3), ucontext(3)/makecontext(3)/getcontext(3)/setcontext(3), msgctl(3)/msgget(3)/msgrcv(3)/msgsnd(3), glob(3), popen(3)/system(3), exec(3) and tree(3) manpages. * - A patch was created to make the hammer(8) iostats command display humanized output. * - A devattr tool was written. - A libfsid was written. - A usage() function / help output was added to vkernels. - sysctl documentation strings were created for lwkt.*, p1003_1b.*, debug.*, net.inet6.*, net.inet.*, vfs.*, vfs.nfs.*, vfs.hammer.*, vm.stats.* and kern.ipc.* sysctl's. - The default password hashing method was changed from md5 to sha2. - Installation and vkernel setup screencasts were created and put on YouTube, http://www.youtube.com/user/dragonflybsd - FTP server documentation was ported, http://www.dragonflybsd.org/docs/newhandbook/FTP/ - A document detailing hammer recovery was written, http://www.dragonflybsd.org/docs/docs/howtos/howtorecoverdataonhammerfs/ - 20+ pkgsrc packages were fixed and patches submitted to pkgsrc or upstream. - Patches were submitted to convert various subsystems from zalloc to objcache, including: nfsnode, nfsmount, kqueue, dirhash, aio and crypto. * - Most kernel usage of m_get() was converted to m_getb(). * Those items with a * appended are not yet committed or only partly committed, most/all of the results of these tasks are committable and will hit the tree, but if you want to adopt something and get it in sooner than later feel free to let myself, alexh or another mentor know and we can fish out the patch for you. A big thanks to Google for the opportunity and the mentors and students for their time and effort. Sam
Re: Avalon maintainance update
On Tue, Jan 11, 2011 at 4:12 PM, Justin C. Sherrill wrote: > On Tue, January 11, 2011 6:01 pm, Matthew Dillon wrote: >> Avalon will be down all of this week for maintainance. It is getting >> a new storage subsystem. We expect to be able to get it back into a >> rack mid-next-week or so. >> >> In the mean the time the mirrors have a snapshot of the recent bulk >> builds and the src and pkgsrc repos can be accessed from the master >> site, crater.dragonflybsd.org. >> >> Our other mirrors will likely be a bit out of date on src and pkgsrc >> as they typically mirrored from avalon. > > Is it worth changing the DNS for git.dragonflybsd.org, temporarily? That > way nothing confuses the mirrors, but 'make src-update' and friends work. > > Expiry of the CNAME is only 3600, I would say yes, it should be changed. Sam
Re: Comments on pkgsrc and DragonFly
> both are excluding DragonFly, since uname -s return "DragonFly" and > OSARCH is usually set to the same value. I can solve this by redefining > OSARCH variable and UNAME_s shell variable as "DragonFlyBSD", which > makes less work to do. But it doesn't seem very clean to me, so I'm not > using it. But it does mean that choosing FreeBSD as build type won't > necessarly mean no changes required on the autotool scripts. > > - Some programs are compiling successfully by defining FreeBSD as build > type. Is DragonFly kept close as possible to FreeBSD on purpose or > should we expect this to be a vanishing legacy? > > Official positions here will me help me knowing what to expect while > porting. > > Thanks, > > SR > Vanishing legacy, never depend on it. Sam
Re: Pango fails for Linux binaries
On Sat, Jan 1, 2011 at 7:02 PM, Pierre Abbat wrote: > I tried both bst (a program to develop software for the Parallax Propeller > microcontroller) and openoffice and got the same error: > > -bash-3.2$ /tmp/bst > > (bst:36461): Pango-WARNING **: No builtin or dynamically loaded modules > were found. Pango will not work correctly. This probably means > there was an error in the creation of: > '/etc/opt/gnome/pango/pango.modules' > You may be able to recreate this file by running pango-querymodules. > > (bst:36461): Pango-CRITICAL **: _pango_engine_shape_shape: assertion > `PANGO_IS_FONT (font)' failed > > Pango-ERROR **: file shape.c: line 75 (pango_shape): assertion failed: > (glyphs->num_glyphs > 0) > aborting... > Abort trap: 6 (core dumped) > -bash-3.2$ soffice > javaldx: Could not find a Java Runtime Environment! > > (soffice.bin:36477): Pango-WARNING **: No builtin or dynamically loaded > modules > were found. Pango will not work correctly. This probably means > there was an error in the creation of: > '/etc/opt/gnome/pango/pango.modules' > You may be able to recreate this file by running pango-querymodules. > > (soffice.bin:36477): Pango-CRITICAL **: _pango_engine_shape_shape: assertion > `PANGO_IS_FONT (font)' failed > > Pango-ERROR **: file shape.c: line 75 (pango_shape): assertion failed: > (glyphs->num_glyphs > 0) > aborting... > sh: : command not found > -bash-3.2$ > > Both are Linux binaries (soffice is a shell script, but it calls soffice.bin, > which is a Linux binary). How do I fix this? > > Pierre > -- > Jews use a lunisolar calendar; Muslims use a solely lunar calendar. > Did you try, "pango-querymodules" ? Sam
Google Code-In update
An update on our Google Code-In progress, the documentation tasks that are not code-related are still decidedly unpopular. The most popular tasks seem to be those that involve some coding, several fairly complicated projects have been done by students so far. The available tasks: doc: Improve the wlan(4) manpage doc: Update Chapter 13 of the old handbook doc: Update Chapter 14 of the old handbook doc: Update Chapter 17 of the old handbook doc: Update Chapter 18 of the old handbook doc: Update Chapter 19 of the old handbook doc: Update Chapter 20 of the old handbook doc: Update Chapter 21 of the old handbook doc: Update Chapter 22 of the old handbook doc: Update Chapter 25 of the old handbook code: make du(1) show space used by historical data on the HAMMER filesystem Release benchmarking Document upgrading Tear out C/H/S disk reporting doc: Write some handbook entries on the device mapper (dm), lvm, cryptsetup, crypttab and initrd code: Change the display of iostat(8) Research: find out what functionality is missing in our udev/libdevattr to get Linux' applications using libudev to work How-To SAMBA Server Create a basic setup screencast Create a vkernel screencast Create a HAMMER screencast Document Hammer recovery Fix a compilation or runtime bug of a popular piece of open source software and submit a patch upstream Fix a compilation or runtime bug of a popular piece of open source software and submit a patch upstream Fix a compilation or runtime bug of a popular piece of open source software and submit a patch upstream Completed tasks: kernel/code: Convert struct klist from an SLIST to a TAILQ (Part 1) kernel/code: Convert struct klist from an SLIST to a TAILQ (Part 2) doc: Write an EXAMPLES section for the setitimer(2) manpage doc: Write an EXAMPLES section for the getsockopt(2)/setsockopt(2) manpage(s) doc: Write an EXAMPLES section for the socket(2)/accept(2)/bind(2)/connect(2) manpage(s) doc: Write an EXAMPLES section for the sendfile(2) manpage doc: Write an EXAMPLES section for the writev(2) manpage doc: Write an EXAMPLES section for the select(2) manpage doc: Write an EXAMPLES section for the poll(2) manpage doc: Write an EXAMPLES section for the fork(2) manpage doc: Write an EXAMPLES section for the send(2)/recv(2) manpage(s) doc: Write an EXAMPLES section for the mmap(2) manpage doc: Write an EXAMPLES section for the setjmp(3)/longmp(3) manpage(s) doc: Write an EXAMPLES section for the dladdr(3)/dlinfo(3)/dlopen(3) manpage(s) doc: Write an EXAMPLES section for the directory(3)/scandir(3) manpage(s) doc: Write an EXAMPLES section for the ucontext(3)/makecontext(3)/getcontext(3)/setcontext(3) manpage(s) doc: Write an EXAMPLES section for the msgctl(3)/msgget(3)/msgrcv(3)/msgsnd(3) manpage(s) doc: Write an EXAMPLES section for the glob(3) manpage(s) doc: Write an EXAMPLES section for the popen(3)/system(3) manpage(s) doc: Write an EXAMPLES section for the exec(3) manpage(s) doc: Write an EXAMPLES section for the tree(3) manpage(s) code: make hammer iostats display humanized output bugs.dragonflybsd.org layout Get to the desktop Regression test code: write a devattr tool code: write a libfsid code: Add usage() to vkernels doc/research: Describe all lwkt.* sysctl's that lack a description doc/research: Describe all debug.* sysctl's that lack a description doc/research: Describe all net.inet6.* sysctl's that lack a description doc/research: Describe all net.inet.* and net.local.* sysctl's that lack a description doc/research: Describe many vfs.* sysctl's that lack a description doc/research: Describe all vfs.nfs.* sysctl's that lack a description doc/research: Describe all vfs.hammer.* sysctl's that lack a description doc/research: Describe all vm.stats.* sysctl's that lack a description doc/research: Describe all kern.ipc.* sysctl's that lack a description code: Change default password hashing from md5 to SHA2 Create an installation video Porting FTP server documentation About half of these completed tasks are already committed, and most of the rest will be committed within the next several weeks. As you can see, our numbers of available tasks is dwindling to the point that almost all of those that are left are those larger documentation wrangling projects that have proven wholly unpopular. If you can think of anything applicable that needs doing please speak up so it can be added to the list. Best, Sam
Re: Updating corecode's nvidia driver
On Thu, Nov 11, 2010 at 10:09 PM, wrote: >> Well, the poll stuff is easy We don't have poll support in the >> kernel anymore, you need to rewrite those as kq filters. See any other >> driver for details. >> > > I figured as much. > > Can you please point me to a specific place in the source code where I can > learn about kq filters, and maybe even show me "the old way and the new > way" next to each other for comparison? > > I've managed to unbreak couple of the problems but now Im stuck on > > nvidia_ctl.c:86: warning: 'struct dev_poll_args' declared inside parameter > list > > Thanks, > Petr > > If you are still working on this, put up a git branch of your progress and I'll see if I can beat the filters into shape for you. Sam
Re: kdebase-workspace4 error gmake[1]: *** [libs/ksysguard/processcore/CMakeFiles/ksysguardprocesslist_helper.dir/all] Error 2
On Mon, Dec 13, 2010 at 5:01 AM, Hasso Tepper wrote: > On 13.12.10 13:18, Siju George wrote: > > I get this error during bmake update > > > > EP' was not declared in this scope > > /usr/pkgobj/bootstrap/work/pkgsrc/x11/kdebase-workspace4/work/kdebase- > > workspace-4.4.5/libs/ksysguard/processcore > > /processes_freebsd_p.cpp:134: > > error: 'SWAIT' was not declared in this scope > > Please, someone write reasonable support for DragonFly - separate files, > no messing with FreeBSD specific files etc. I promise I'll blow the dust > away from my DragonFly machine and will commit it into the upstream. > > > -- > Hasso Tepper > Hasso, I will make sure this gets done. Sam
Google Code-In
We have just reached 30 tasks completed for Google Code-In, but we are now down to a single task in-progress. There are 34 more tasks in the pool, but adoption of these remaining tasks is going at a much slower rate than before. The possible reasons are numerous, but it would be great to add more useful tasks to the pool in an attempt to reach the broadest possible demographic of students participating. I will include summaries below of the completed and the unclaimed tasks, in the hopes that they may spark some ideas. Please send any ideas you might have, either on-list or off. There are some exceptionally bright students participating, so please do not leave out tasks that you might consider "too hard", only those that would be "too large", unless they can be broken down into pieces. Thanks! Completed Tasks: kernel/code: Convert struct klist from an SLIST to a TAILQ (Part 1) kernel/code: Convert struct klist from an SLIST to a TAILQ (Part 2) doc: Write an EXAMPLES section for the setitimer(2) manpage doc: Write an EXAMPLES section for the getsockopt(2)/setsockopt(2) manpage(s) doc: Write an EXAMPLES section for the socket(2)/accept(2)/bind(2)/connect(2) manpage(s) doc: Write an EXAMPLES section for the writev(2) manpage doc: Write an EXAMPLES section for the select(2) manpage doc: Write an EXAMPLES section for the poll(2) manpage doc: Write an EXAMPLES section for the fork(2) manpage doc: Write an EXAMPLES section for the send(2)/recv(2) manpage(s) doc: Write an EXAMPLES section for the mmap(2) manpage doc: Write an EXAMPLES section for the setjmp(3)/longmp(3) manpage(s) doc: Write an EXAMPLES section for the dladdr(3)/dlinfo(3)/dlopen(3) manpage(s) doc: Write an EXAMPLES section for the directory(3)/scandir(3) manpage(s) doc: Write an EXAMPLES section for the ucontext(3)/makecontext(3)/getcontext(3)/setcontext(3) manpage(s) doc: Write an EXAMPLES section for the glob(3) manpage(s) doc: Write an EXAMPLES section for the popen(3)/system(3) manpage(s) doc: Write an EXAMPLES section for the exec(3) manpage(s) bugs.dragonflybsd.org layout Get to the desktop Regression test code: write a devattr tool code: Add usage() to vkernels doc/research: Describe all lwkt.* sysctl's that lack a description doc/research: Describe all debug.* sysctl's that lack a description doc/research: Describe all net.inet6.* sysctl's that lack a description doc/research: Describe all net.inet.* and net.local.* sysctl's that lack a description doc/research: Describe all vm.stats.* sysctl's that lack a description code: Change default password hashing from md5 to SHA2 Create an installation video Open/unclaimed tasks: doc: Improve the wlan(4) manpage doc: Write an EXAMPLES section for the sendfile(2) manpage doc: Write an EXAMPLES section for the msgctl(3)/msgget(3)/msgrcv(3)/msgsnd(3) manpage(s) doc: Write an EXAMPLES section for the tree(3) manpage(s) doc: Update Chapter 13 of the old handbook doc: Update Chapter 14 of the old handbook doc: Update Chapter 17 of the old handbook doc: Update Chapter 18 of the old handbook doc: Update Chapter 19 of the old handbook doc: Update Chapter 20 of the old handbook doc: Update Chapter 21 of the old handbook doc: Update Chapter 22 of the old handbook doc: Update Chapter 25 of the old handbook code: make du(1) show space used by historical data on the HAMMER filesystem code: make df(1) show space used by historical data on the HAMMER filesystem code: make hammer iostats display humanized output Release benchmarking Document upgrading Tear out C/H/S disk reporting Implement sem_* functions doc: Write some handbook entries on the device mapper (dm), lvm, cryptsetup, crypttab and initrd code: Change the display of iostat(8) Research: find out what functionality is missing in our udev/libdevattr to get Linux' applications using libudev to work How-To SAMBA Server doc/research: Describe all p1003_1b.* sysctl's that lack a description doc/research: Describe many vfs.* sysctl's that lack a description doc/research: Describe all vfs.nfs.* sysctl's that lack a description doc/research: Describe all vfs.hammer.* sysctl's that lack a description doc/research: Describe all kern.ipc.* sysctl's that lack a description Create a basic setup screencast Create a vkernel screencast Create a HAMMER screencast Porting FTP server documentation Document Hammer recovery
Re: Updating corecode's nvidia driver
On Thu, Nov 11, 2010 at 9:45 PM, wrote: > Currently gives a compile error upon running "make" > > In file included from nvidia_ctl.c:14: > nv-freebsd.h:267: error: field 'rsel' has incomplete type > nv-freebsd.h: In function 'pmap_mapdev_attr': > nv-freebsd.h:351: error: too few arguments to function 'kmem_alloc_nofault' > nvidia_ctl.c: At top level: > nvidia_ctl.c:19: error: expected '=', ',', ';', 'asm' or '__attribute__' > before 'nvidia_ctl_poll' > nvidia_ctl.c:26: error: unknown field 'd_poll' specified in initializer > nvidia_ctl.c:26: error: 'nvidia_ctl_poll' undeclared here (not in a function) > nvidia_ctl.c:86: warning: 'struct dev_poll_args' declared inside parameter > list > nvidia_ctl.c:86: warning: its scope is only this definition or > declaration, which is probably not what you want > nvidia_ctl.c:87: warning: no previous prototype for 'nvidia_ctl_poll' > nvidia_ctl.c: In function 'nvidia_ctl_poll': > nvidia_ctl.c:88: error: dereferencing pointer to incomplete type > nvidia_ctl.c:105: warning: implicit declaration of function 'selrecord' > nvidia_ctl.c:105: warning: nested extern declaration of 'selrecord' > nvidia_ctl.c:106: error: dereferencing pointer to incomplete type > nvidia_ctl.c:109: error: dereferencing pointer to incomplete type > > Is this too difficult to unbreak? I just had a look at nv-freebsd.h:267 > and it's defining a variable rsel of type struct selinfo, but I have no > idea where that's coming from. Any clues? > > Thanks, > Petr > > > Well, the poll stuff is easy We don't have poll support in the kernel anymore, you need to rewrite those as kq filters. See any other driver for details. Sam
Re: Suggestion for hammer cleanup
On Mon, Oct 18, 2010 at 4:39 PM, Chris Turner wrote: > Samuel J. Greear wrote: >> >> That said, I think it would be fine to commit one or more optional >> stopgap measures/scripts to the RC system, for mobile users and etc., >> as long as it is well documented that they may go away if a better >> solution is developed or derived. > > not to flamebait or something - but: > > wouldn't the system crontab be a better place? > or perhaps create an /etc/periodic/hourly ? > > the 'newsyslog' is in /etc/crontab which is the only hourly > job I can think of off hand.. > > the script can still of course source rc.conf or something > to configure the job if the job is enabled by default > Sure, my only real point was that it should be a knob that users have to turn on (not on by default). I do not know what the precedent is for periodic/rc cross-pollination. Sam
Re: Suggestion for hammer cleanup
On Mon, Oct 18, 2010 at 4:06 PM, Chris Turner wrote: > elekktrett...@exemail.com.au wrote: >> >> Suggestions? > > quick-fix / hack wise - > > probably setup some job to run way more often > that checks the status & makes a determination - > or move the job to something like anacron, etc > > although, in a laptop situation - you might want > to manage this manually - because the heavy work > from reblocking, etc could easily suck the juice > out of your battery when you dont want it.. > Until / unless we have the disk scheduler tuned to a point that we can just run a "prunerandreblockerd" all the time, I think it would be sufficient (and in my opinion, preferred) to simply warn the administrator based on some metric, time since last reblock, egregious amount of storage used by history, low amount of free disk space, etc., or some combination, if it is to be on by default. ... That is, if we do anything at all. I think making it clear in the HAMMER documentation that the periodic maintenance must be performed, and why, should be sufficient. I do not feel that it is terribly obvious right now. That said, I think it would be fine to commit one or more optional stopgap measures/scripts to the RC system, for mobile users and etc., as long as it is well documented that they may go away if a better solution is developed or derived. If there were a consensus, it is possible we could see about getting a script or two written for RC and/or documentation updates made as a part of Google Code-In, if DragonFly is accepted. Assuming there are no volunteers participating in this thread. Sam
Re: Misleading directory names
2010/9/28 Przemysław Pawełczyk : > Hi, > > Listing from http://avalon.dragonflybsd.org/packages/ > > Name Last modified Size Description > Parent Directory - > README 18-May-2010 02:45 1.3K > amd64/ 24-Aug-2010 23:56 - > i386/ 27-Sep-2010 20:59 - > x86_64/ 24-Aug-2010 23:56 - > > Why there are two __identical__ directories under __two__ different > names which stand for the same contents? > > Excerpt from README: > > What's here > > > The i386 directory contains packages built on 32-bit DragonFly > systems. The amd64/x86_64 directores contains packages built on 64-bit > DragonFly systems. > > (amd64 and x86_64 are the same thing here) > ^^^ > > Why the mess? > > Regards > > -- > Przemysław Pawełczyk (P2O2) [pron. Pshemislav Paveltchick] > http://pp.blast.pl, pp...@o2.pl > Our x86_64 branch used to be called amd64, it's just legacy. Sam
Re: Weird entry in ISO
2010/9/24 Przemysław Pawełczyk : > On Fri, 24 Sep 2010 13:43:26 +0100 > Alex Hornung wrote: > >> On 24/09/10 13:37, Przemysław Pawełczyk wrote: >> > I know, and I would expect such answer. No offense please, but for >> > how long yet such attitude will prevail in Unix community? It >> > lingers from 80s of the last... Cenury of the last Millennium. ;-) There is a very specific and very good reason why the Unix community has this attitude and it has prevailed for so long. Did you ever consider what it might be? Importing software and even seemingly simple defaults, like making software required for things like our LiveDVD, increases our maintenance burden. Our maintenance burden is already too high. Sam
Re: Looking for some programming tasks to do
On Fri, Sep 24, 2010 at 5:55 AM, wrote: > I've been learning C++ for about a year now(own about 5 books on it), and > I also started doing a couple of projects in the language at work, but I > feel I need to use/understand plain C a bit more. Is there any projects on > DragonFly that are easy enough that I can pickup? Few hundred lines of > code? > > Petr > I have been doing my best to maintain the projects pages with tasks for all skill levels, you will definitely find something on one of them. http://www.dragonflybsd.org/docs/developer/ProjectsPage/ http://www.dragonflybsd.org/docs/developer/researchprojectspage/ http://www.dragonflybsd.org/docs/developer/Code_Bounties/ http://www.dragonflybsd.org/docs/developer/gsocprojectspage/ Sam
Re: Why did you choose DragonFly?
Samuel J. Greear wrote: > What has drawn you to use the DragonFly BSD operating system and/or > participate in its development by following this list? Technical > features, methodologies, something about the community? Thanks all for your responses, this has been very enlightening to me and I hope to others as well. I was somewhat surprised, but perhaps I shouldn't have been, that the community seems to play such a role for so many people. That is largely the reason I am here as well. I have been a FreeBSD user since 1998 and oversaw and maintained several rather large deployments over the years. I was also a developer, but usually a couple of layers above the OS (most often for the web). When I did contribute patches to FreeBSD it almost seemed like a fight to get anything to happen with them, oftentimes they were rejected on the basis of white-space or etc., rather than merit. Whether they were any good or not, well ... I have been following DragonFly BSD since the fork and I have greatly appreciated many of the design decisions that have been made in that time. I have poked around in all of the BSD's kernels and I would consider DragonFly by far the cleanest thanks in large part to the years of cleanup and source documentation work done by Matt. While finding someone to test patches can be a bear sometimes, the community is usually very willing to accept and provide input on odd concepts and alternative ways of doing things. For instance, sfbuf's, although novel have kind of rubbed me the wrong way since the early 2000's. When I finally decided to do something about them quite a few people were eager to offer their own ideas and approaches, explaining DragonFly's unique locking / kernel methodology along the way. lwbuf's have since been committed, I'm not sure I would have had the ambition to follow through and get them committed faced with some of the "obstacles" I have hit in other projects. So a big thanks to all of the recently active committers and contributors on that front, you guys are all low pressure and make things pretty easy. I also get the feeling that DragonFly really is what the developers and users make of it, more than anything. It's not a "toy" project but it's also not necessarily a 100% general-purpose project like FreeBSD aims to be. My personal aim is for it to be a seriously reliable and scalable piece of infrastructure supporting things like clustered web/cloud deployments and clustered/redundant NAS. I don't feel, as a develope/user, like there are any major hurdles to my making changes to DragonFly toward this end apart from my own ambition and the amount of time I am able to contribute. That might seem basic, but it is a very liberating feeling having been involved in various other projects. Thanks again, Sam
Re: SMP (Was: Why did you choose DragonFly?)
2010/9/20 Przemysław Pawełczyk : > On Mon, 20 Sep 2010 13:33:28 -0600 > "Samuel J. Greear" wrote: > >> This mail is intended for the infrequent responders and lurkers on the >> list just as much as the regular posters. >> >> What has drawn you to use the DragonFly BSD operating system and/or >> participate in its development by following this list? Technical >> features, methodologies, something about the community? I suspect the >> HAMMER filesystem to be the popular choice, but what other features >> affect or do you see affecting your day to day life as an >> administrator, developer, or [insert use case here], now or in the >> future? >> > > Hi Sam, > > A question for a question. > > Why _no one_ answered my question concerning DF BSD contained in my > post: > http://leaf.dragonflybsd.org/mailarchive/users/2010-07/msg00091.html > > What did I do wrong? > > I thought them over before I gathered enough temerity to ask here for > anything. > > Why do you ask me -"a lurker" - to answer your questions when you > (plural) are treating "the lurkers" that way? > > Regards > > -- > Przemysław Pawełczyk (P2O2) [pron. Pshemislav Paveltchick] > http://pp.blast.pl, pp...@o2.pl > I will try to answer here and now. The purpose of my question(s) is because I believe DragonFly BSD is not adequately represented in the easily accessible (main page and pages directly linked from it) literature on our website. I would like to fix this so that questions like yours need not arise in the future. As a first step I wanted to learn what people like about DragonFly and what keeps people using this OS and participating in the community so that I could expand on those points. DragonFly BSD is not necessarily targeted -to- SMP, rather it supports SMP and adopts a slightly different model than other mainstream operating systems. Most OS kernels use primarily "hard" locks in the form of mutexes and spinlocks. DragonFly prefers "soft" locks in the form of tokens and, even better, lockless algorithms. I do not believe anyone is ready to make any bold claims about our current SMP performance. However, I do believe many developers would claim that even though we may be a bit behind in performance today our model/methodology positions us well for the future. Modern hardware should be pretty well supported, if FreeBSD supports it then generally so should we and if we don't it is likely not too much work to port that support over. Matt Dillon just brought up DragonFly on a new AMD 880-series-based motherboard with a 6-core CPU and that is apparently working quite well. HAMMER is definitely a competitor to ZFS, although not in terms of volume management. We have LVM for that, but currently it does not support many of the targets one might expect (None of the real RAID levels). HAMMER is partly MPSAFE and many of the subsystems above it are also partially or fully MPSAFE, performance on multiple CPU's should be quite good from the point of view of the filesystem.
Why did you choose DragonFly?
This mail is intended for the infrequent responders and lurkers on the list just as much as the regular posters. What has drawn you to use the DragonFly BSD operating system and/or participate in its development by following this list? Technical features, methodologies, something about the community? I suspect the HAMMER filesystem to be the popular choice, but what other features affect or do you see affecting your day to day life as an administrator, developer, or [insert use case here], now or in the future? Thanks in advance for your response. Best, Sam
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
On Tue, Aug 31, 2010 at 9:52 AM, Matthew Dillon wrote: > > :On Sun, Aug 01, 2010 at 03:01:41AM -0600, Samuel J. Greear wrote: > :> This 10-second-wait should be fixed with commit 847ff8c. > : > :Apparently the recent commit (within a week or so) re-introduced this > :10-second-wait. On the other hand, the kernel built from the very recent > :master no longer panics when I reboot the PC while GNU screen is running. > > I am going to guess that this has to do with the changes I made to > TS_ZOMBIE in a recent patch. Those changes fixed traditional pty's, > they were blowing up on us testing with telnet (ssh uses unix-98 pty's). > > I will try to reproduce the issue. > > -Matt > Matthew Dillon > I originally fixed this with, http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/847ff8ce751358d6954bc9ea35d6513da665da3e http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/41cf5266ef48f9872e14b8d5707530a54161f3d5 Matt's recent commit http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/f454b4592466e584e6c5d54a579c8aa226a002da effectively un-did the prior fix. I just had the brilliant (sarcasm) thought to check the original poll function, it seems to use a magic combination of TS_CONNECTED and TS_CARR_ON to determine whether to set POLLHUP. I guess this is probably what we should go back to in the kq filters for pty's, but someone should make sure it does the right thing with consideration given to the POLLHUP/EV_EOF filtering recently introduced in the poll copyout function. I'll give this a looking over and make a commit in the next few days unless someone beats me to it. Sam
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
> This 10-second-wait should be fixed with commit 847ff8c. > > While debugging I noticed screen calls close(2) on all descriptors > except stdin/err/out every time it forks. Making it use DragonFly's > closefrom(2) would be a great optimization that would reduce new > window creation times, if anyone felt so inclined. > > Sam > Referenced commit broke xterm (maybe other things). I have just pushed a fix to master. Sam
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
On Mon, Jul 26, 2010 at 8:32 PM, YONETANI Tomokazu wrote: > On Mon, Jul 26, 2010 at 06:04:00PM -0600, Samuel J. Greear wrote: >> I've pushed some fixes into master, >> >> Commit 0f2e13efc9137bb21562ef4093049fd044651429 should fix the screen issue. > > I updated the kernel with the latest source (the world has been installed > from the source as of 4cc93e2d), but I'm afraid it doesn't fix the issue. > Here's how you compile GNU screen from git master, by the way: > > $ git clone git://git.sv.gnu.org/screen.git > $ cd screen.git/src > $ autoreconf && ./configure && gmake && ./screen > (and press ctrl+D or type `exit' followed by Enter key) > > An window still takes about 10-seconds before closing if it was running > a shell. The shell process itself is terminated right after pressing > ctrl+D, according to the output from ps command. Bisecting revealed that > the first commit in GNU screen which takes longer to close a shell window > on a recent DragonFly kernel is: > http://git.savannah.gnu.org/cgit/screen.git/commit/?id=33b7c9ca > > > I also noticed that issuing shutdown command from within screen triggers > a kernel panic, if it proceeds within the 10-seconds delay. I don't use a > special CFLAGS to build the kernel, and I use gcc4.1 (no CCVER specified). > > Fatal trap 12: page fault while in kernel mode > mp_lock = 0001; cpuid = 1; lapic.id = 0100 > fault virtual address = 0 > fault code = supervisor read, page not present > instruction pointer = 0x8:0x0 > stack pointer = 0x10:0xd3686a80 > frame pointer = 0x10:0xd3686aa8 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 4436 (screen) > current thread = pri 38 (CRIT) > <- SMP: XXX > trap number = 12 > panic: page fault > mp_lock = 0001; cpuid = 1 > Trace beginning at frame 0xd3686980 > panic() at panic+0x14f > panic(c0332c96,c0345fcc,0,0,f) at panic+0x14f > trap_fatal(0,0,cfaf7310,d274b650,c) at trap_fatal+0x31d > trap_pfault(26,0,0,d3a51f28,d25363d0) at trap_pfault+0xff > trap(d3686a38) at trap+0x7a0 > calltrap() at calltrap+0xd > --- trap 0, eip = 0, esp = 0xd3686a7c, ebp = 0xd274b650 --- > (null)(0,cfaac418,0,cc476400,0) at 0 > CPU_prvspace() at CPU_prvspace+0x8054 > boot() called on cpu#1 > Uptime: 20m42s > #0 _get_mycpu (di=0xc042b2a0) at ./machine/thread.h:83 > #1 md_dumpsys (di=0xc042b2a0) > at /usr/src/sys/platform/pc32/i386/dump_machdep.c:263 > #2 0xc01a24a1 in dumpsys () at /usr/src/sys/kern/kern_shutdown.c:839 > #3 0xc01a2a73 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:388 > #4 0xc01a2fd6 in panic (fmt=0xc0332c96 "%s") > at /usr/src/sys/kern/kern_shutdown.c:745 > #5 0xc030611d in trap_fatal (frame=0xd3686a38, eva=) > at /usr/src/sys/platform/pc32/i386/trap.c:1125 > #6 0xc030622e in trap_pfault (frame=0xd3686a38, usermode=0, eva=0) > at /usr/src/sys/platform/pc32/i386/trap.c:1026 > #7 0xc03076e8 in trap (frame=0xd3686a38) > at /usr/src/sys/platform/pc32/i386/trap.c:713 > #8 0xc02f2427 in calltrap () > at /usr/src/sys/platform/pc32/i386/exception.s:785 > #9 0x in ?? () > This 10-second-wait should be fixed with commit 847ff8c. While debugging I noticed screen calls close(2) on all descriptors except stdin/err/out every time it forks. Making it use DragonFly's closefrom(2) would be a great optimization that would reduce new window creation times, if anyone felt so inclined. Sam
Bluetooth
Is anyone using bluetooth on dragonfly in any capacity? What are you doing with it? Sam
Re: Abnormal termination of greeter
On Thu, Jul 29, 2010 at 5:43 PM, Pierre Abbat wrote: > I did a full upgrade today, then tried to log in and got "Abnormal termination > of greeter". I rebooted and got the same error. kdm is still running. I > logged in at the console and ran startx; it said "kde4: not found" and threw > me out of X. All the KDE packages I noticed in the upgrade are version > 3.something. What gives? > > Pierre > -- > lo ponse be lo mruli po'o cu ga'ezga roda lo ka dinko > Upgrade to master? full pkgsrc upgrade? What did you upgrade and from what version(s) to what version(s)? Sam
Re: Is it time to dump disklabel and use GPT instead?
On Tue, Jul 27, 2010 at 7:44 PM, wrote: >> What evidence do you have of newcomers being "more than often" turned >> away by having to use "archaic tools"? > > I visit a couple of Linux forums, and while the word "DragonFly" surely > seems to have picked up some usage in the recent months, I also hear that > they go somewhere else after a brief experience setting it up. Majority of > these people seem try DragonFly because of HAMMER and their aim is to > setup a "backup" box. > >> If they want DragonFly only on their whole disk, they can just let the >> installer install DragonFly to the whole disk without having to use >> either fdisk or disklabel. > > From what I hear, people prefer to use a separate hard disk(s) instead of > using the one on which they installed DragonFly initially to store their > backups. So they cannot avoid fdisk and disklabel. > > It made me think, what advantage do we get by over-complicating things > with disklabels, sectors, offsets etc? They are things that, I feel, > majority of *nix users don't wanna hear about these days. I've used *BSD > for a few years and while i never really had problems with > disklabel(except once), it does seem kind of cool to "partition a slice", > it is redundant at the same time especially now that GPT is here and it > does work with existing BIOSes. > > I blasted away a DF disklabel by accident once(installing FreeBSD on > another slice) and I didnt have backups and I managed to recover my data > only partially, sure my fault..i didnt have a backup, but on the other > hand I blame the disklabel to be too easy to stuff up. > > As I mentioned earlier, another issue they seem to find, is the > non-availability of choosing BASH during the install. > > - > > So, what is the real world advantage of using disklabel, that can't be > done with GPT on 99.99% of all OS install? that is worth breaking > compatibility with other *BSDs - each BSD implements disklabel > differently- and other OSs like Linux - doesn't use disklabel at all but > for Linux to support reading/writing to HAMMER or UFS, it would have to > implement some basic disklabel support. > > Petr > I am relatively certain nobody is going to argue, your points are mostly valid, and there are others you did not mention. I am also relatively certain nobody is going to stand up and do the work, unless you do. There is finite manpower and to my knowledge existing committers have any number of priorities before even considering GPT. Failing this it is possible someone would make it a priority if there were a reasonable code bounty placed on it. Sam
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
On Mon, Jul 26, 2010 at 8:32 PM, YONETANI Tomokazu wrote: > On Mon, Jul 26, 2010 at 06:04:00PM -0600, Samuel J. Greear wrote: >> I've pushed some fixes into master, >> >> Commit 0f2e13efc9137bb21562ef4093049fd044651429 should fix the screen issue. > > I updated the kernel with the latest source (the world has been installed > from the source as of 4cc93e2d), but I'm afraid it doesn't fix the issue. > Here's how you compile GNU screen from git master, by the way: > > $ git clone git://git.sv.gnu.org/screen.git > $ cd screen.git/src > $ autoreconf && ./configure && gmake && ./screen > (and press ctrl+D or type `exit' followed by Enter key) > > An window still takes about 10-seconds before closing if it was running > a shell. The shell process itself is terminated right after pressing > ctrl+D, according to the output from ps command. Bisecting revealed that > the first commit in GNU screen which takes longer to close a shell window > on a recent DragonFly kernel is: > http://git.savannah.gnu.org/cgit/screen.git/commit/?id=33b7c9ca > > > I also noticed that issuing shutdown command from within screen triggers > a kernel panic, if it proceeds within the 10-seconds delay. I don't use a > special CFLAGS to build the kernel, and I use gcc4.1 (no CCVER specified). > > Fatal trap 12: page fault while in kernel mode > mp_lock = 0001; cpuid = 1; lapic.id = 0100 > fault virtual address = 0 > fault code = supervisor read, page not present > instruction pointer = 0x8:0x0 > stack pointer = 0x10:0xd3686a80 > frame pointer = 0x10:0xd3686aa8 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 4436 (screen) > current thread = pri 38 (CRIT) > <- SMP: XXX > trap number = 12 > panic: page fault > mp_lock = 0001; cpuid = 1 > Trace beginning at frame 0xd3686980 > panic() at panic+0x14f > panic(c0332c96,c0345fcc,0,0,f) at panic+0x14f > trap_fatal(0,0,cfaf7310,d274b650,c) at trap_fatal+0x31d > trap_pfault(26,0,0,d3a51f28,d25363d0) at trap_pfault+0xff > trap(d3686a38) at trap+0x7a0 > calltrap() at calltrap+0xd > --- trap 0, eip = 0, esp = 0xd3686a7c, ebp = 0xd274b650 --- > (null)(0,cfaac418,0,cc476400,0) at 0 > CPU_prvspace() at CPU_prvspace+0x8054 > boot() called on cpu#1 > Uptime: 20m42s > #0 _get_mycpu (di=0xc042b2a0) at ./machine/thread.h:83 > #1 md_dumpsys (di=0xc042b2a0) > at /usr/src/sys/platform/pc32/i386/dump_machdep.c:263 > #2 0xc01a24a1 in dumpsys () at /usr/src/sys/kern/kern_shutdown.c:839 > #3 0xc01a2a73 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:388 > #4 0xc01a2fd6 in panic (fmt=0xc0332c96 "%s") > at /usr/src/sys/kern/kern_shutdown.c:745 > #5 0xc030611d in trap_fatal (frame=0xd3686a38, eva=) > at /usr/src/sys/platform/pc32/i386/trap.c:1125 > #6 0xc030622e in trap_pfault (frame=0xd3686a38, usermode=0, eva=0) > at /usr/src/sys/platform/pc32/i386/trap.c:1026 > #7 0xc03076e8 in trap (frame=0xd3686a38) > at /usr/src/sys/platform/pc32/i386/trap.c:713 > #8 0xc02f2427 in calltrap () > at /usr/src/sys/platform/pc32/i386/exception.s:785 > #9 0x in ?? () > The big difference it seems, between screen from pkgsrc and screen's master branch is that the latter uses domain sockets on the file system instead of named fifo's. As a temporary workaround it should be possible to force it to use named fifo's instead of sockets. (I didn't try). Still looking into the issue. Sam
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
On Sat, Jul 24, 2010 at 11:30 AM, Samuel J. Greear wrote: > I know where this bug is and am working on a fix. dhclient I am fairly > certain is the same issue only in the pipe code instead of the FIFO > code (where the screen problem is). I will follow up here when I have > a patch. > > Sam. > > On 7/24/10, YONETANI Tomokazu wrote: >> On Fri, Jul 23, 2010 at 09:16:56AM -0600, Samuel J. Greear wrote: >>> This only seems to happen on recent master with screen installed from >>> a package. I was unable to reproduce with screen compiled from pkgsrc. >> >> Sorry, I realized I've been using the development version of GNU >> screen for virtical split, not the one from pkgsrc. The pkgsrc >> version or official screen-4.0.3 don't have the problem. Besides >> that, sched.c in 4.0.3 and Git master are identical except for >> the comment at the beginning. I'll start bisecting the Git repository >> of GNU screen tomorrow. >> > I've pushed some fixes into master, Commit 0f2e13efc9137bb21562ef4093049fd044651429 should fix the screen issue. Commit 44aa8f0264c19830b9f6fd1de53c456054f85b53 should fix the issues everyone was having with dhclient being slow. Best, Sam
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
I know where this bug is and am working on a fix. dhclient I am fairly certain is the same issue only in the pipe code instead of the FIFO code (where the screen problem is). I will follow up here when I have a patch. Sam. On 7/24/10, YONETANI Tomokazu wrote: > On Fri, Jul 23, 2010 at 09:16:56AM -0600, Samuel J. Greear wrote: >> This only seems to happen on recent master with screen installed from >> a package. I was unable to reproduce with screen compiled from pkgsrc. > > Sorry, I realized I've been using the development version of GNU > screen for virtical split, not the one from pkgsrc. The pkgsrc > version or official screen-4.0.3 don't have the problem. Besides > that, sched.c in 4.0.3 and Git master are identical except for > the comment at the beginning. I'll start bisecting the Git repository > of GNU screen tomorrow. > -- Sent from my mobile device
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
On Fri, Jul 23, 2010 at 8:26 AM, YONETANI Tomokazu wrote: >> Anyway, I'm giving your latest commit a try to see if it's related. > > Unfortunately, 21ae0f4c doesn't seem to fix my problem. > This only seems to happen on recent master with screen installed from a package. I was unable to reproduce with screen compiled from pkgsrc. Looking into it. Sam
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
On Fri, Jul 23, 2010 at 5:56 AM, Sascha Wildner wrote: > On 7/20/2010 3:18, Matthew Dillon wrote: >> >> Sam's select/poll infrastructure removal project is now in HEAD. This >> project reimplements the kernel's select() and poll() system calls >> using >> per-thread kqueues and removes the original select/poll >> infrastructure. >> >> We expect there to be some bugs so anyone running HEAD please report >> issues where (primarily) programs wind up blocking on something and >> not waking up when they should, or if the system crashes or deadlocks >> when it did not before. > > I've already mentioned it on IRC, so just for the record. Since the > select/poll work, svn doesn't work properly. For example: > > svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm > > times out while on a system from the 19th it succeeds. > > Another thing I noticed is that dhclient takes longer now (more tries) to > get an IP (though it eventually succeeds). > > Regards, > Sascha > I have just committed a patch to master that fixes svn and may very well fix other issues. I am currently at a loss regarding dhclient as it is working fine in my test environments. All those that can confirm or deny that it is worse after the recent kq merge into master, it would be appreciated. Sam
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
On Fri, Jul 23, 2010 at 4:30 AM, YONETANI Tomokazu wrote: > On Mon, Jul 19, 2010 at 06:18:52PM -0700, Matthew Dillon wrote: >> Sam's select/poll infrastructure removal project is now in HEAD. This >> project reimplements the kernel's select() and poll() system calls using >> per-thread kqueues and removes the original select/poll infrastructure. >> >> We expect there to be some bugs so anyone running HEAD please report >> issues where (primarily) programs wind up blocking on something and >> not waking up when they should, or if the system crashes or deadlocks >> when it did not before. > > After the select/poll change, closing a window in GNU screen takes > about 10 second if the program running in that window was either > /bin/sh, /bin/csh, or /bin/tcsh. Top doesn't take 10 second to terminate, > so it appears like specific to shells, but bash from pkgsrc is also not > affected. > I attached gdb to the backend process of GNU screen and found that > the 10-second delay is caused by the call to select() in sched(). > > Cheers. > Yonetani, I apologize, I am not a screen user, can you tell me the appropriate magic incantation to reproduce this? Best, Sam
Re: HEADS UP: dm, lvm, cryptsetup and initrd on master
On Sun, Jul 11, 2010 at 7:38 PM, Adam Vande More wrote: > On Sun, Jul 11, 2010 at 5:11 PM, Alex wrote: >> >> Hi, >> >> as you know I've been working on getting dm and lvm into DragonFly. I've >> just committed my work so far which includes the following: >> - dm kernel part (including linear, stripe and crypt targets) >> - dm userland library >> - lvm userland tools >> - cryptsetup (with LUKS stuff) >> - some further modifications to the initrd stuff > > > Forgive my ignorance, but how does this stuff work with the kernel? Isn't > it GPL'd? If so, isn't that a problem? > > > -- > Adam Vande More > The kernel parts are BSD-licensed but compatible with the GNU-licensed LVM userland tools. Sam
Re: dragonfly installation into virtualbox
On Sat, Jun 12, 2010 at 2:19 PM, Justin C. Sherrill
wrote:
> On Sat, June 12, 2010 3:36 am, dark0s Optik wrote:
>> I tried to launch dragonfly x86 2.6.3 installation into virtualbox
>> 3.2, but it crash.
>> The output is:
>>
>> Debugger("panic"):
>> stopped at 0xc0537b3c movb $0, 0xc070fd34
>>
>> How can to install dragonfly into virtualbox?
>
> Try a different version of Virtualbox, or maybe a different emulator - it
> seems like every third release of Virtualbox doesn't work for running
> DragonFly, and then it does.
>
>
That's not the case, DragonFly has worked consistently on VirtualBox
for a year or so. On some machines it seems to panic on first boot,
but if you warm reset the virtual machine it may come up fine the
second time. Playing with the various machine settings such as APIC_IO
seems to fix this. I am beginning to get the impression that this only
happens on VirtualBox running under Windows.
Sam
Re: DragonFly 64-bit stability
On Thu, Jun 10, 2010 at 6:47 PM, Justin C. Sherrill wrote: > On Thu, June 10, 2010 4:32 pm, Francois Tigeot wrote: > >> Installing applications from pkgsrc went well. >> >> Unfortunately, running Postgres is a different matter: >> # /usr/pkg/etc/rc.d/pgsql start >> Starting pgsql. >> seg-fault accessing address 0x58 rip=0x80077037d pid=20186 >> p_comm=pg_ctl Segmentation fault > > Is this from a prebuilt binary or one that you compiled yourself? It may > be worth building locally if you did not before. > > Otherwise: http://www.postgresql.org/support/submitbug > If I had to guess I would say it is likely that this is our bug, probably in one of the kernel sysv subsystems. Sam
Re: HEADS UP: BIND Removal. Short instructions for migration to pkgsrc-BIND
On Thu, May 6, 2010 at 8:47 AM, Jan Lentfer wrote: > On Thu, 6 May 2010 06:04:19 -0500 (CDT), "Jeremy C. Reed" > wrote: > >> Were the kqueue issues in DragonFly itself looked at/fixed? > > Afaik it is a bug in BIND and Samuel send a report to ISC. > > Jan > I received a follow-up from ma...@isc, they think it's a kernel bug. So it's still up in the air. I'll dig in further soon. Sam
Re: HEADS UP: BIND Removal. Short instructions for migration to pkgsrc-BIND
On Thu, Apr 22, 2010 at 1:07 PM, Jeremy C. Reed wrote:
> On Wed, 14 Apr 2010, Jan Lentfer wrote:
>
>> After playing around with this back and forth for a while I think I found
>> the problem. Well, not actually the problem but a bypass to the BIND
>> crashes. When building any version of BIND from base autoconfigure will
>> enable kqueue support which seems to lead to this behaviour. I patched the
>> Makefiles in pkgsrc to disable kqueue and both bind95 and bind96 have now
>> my passed my queryperf tests that would originally let them crash within
>> minutes or even seconds. I will now upgrade my home server to this
>> kqueue-disabled version of BIND and report later. This are the patches:
>>
>>
>>
>> diff --git a/net/bind95/Makefile b/net/bind95/Makefile
>> index bb97183..ff2a37b 100644
>> --- a/net/bind95/Makefile
>> +++ b/net/bind95/Makefile
>> @@ -88,3 +88,7 @@ CONFIGURE_ARGS+= --disable-threads
>> .else
>> CONFIGURE_ARGS+= --enable-threads
>> .endif
>> +
>> +.if ${OPSYS} == "DragonFly"
>> +CONFIGURE_ARGS+= --disable-kqueue
>
> Can you please report your problems with kqueue on DragonFly to
> bind9-bugs
> AT
> isc.org?
>
> Or maybe better yet, we should look to see if the problem is kqueue on
> DragonFly and not BIND 9 related.
>
> If you have any core dumps, back traces or logs related to your
> problems, please share them. Thanks!
>
>
> (I work for ISC.)
>
>
Jeremy,
[13:02] <@corecode> what's wrong with bind?
[13:02] <@thesjg> corecode: it doesn't account for semantic
differences between kevent and select/poll
[13:02] <@corecode> ah?
[13:02] <@corecode> which are?
[13:03] <@thesjg> in kevent, if you register an fd, an event happens
on that fd, and you delete that fd from the watchlist, then pull out
your events, you will get that event on your already deleted fd
[13:03] <@thesjg> because it happened before you deleted it
[13:04] <@thesjg> select and poll you won't, obviously, because there
isn't an in-kernel watch list
[13:04] <@thesjg> BIND sets a flag after it deletes a fd from the
watch list and asserts when it gets an event for that fd
[13:04] <@corecode> oh
[13:05] <@corecode> i thought it would remove the events
[13:05] <@corecode> the kernel
[13:05] <@thesjg> corecode: i checked freebsd source and it seems to
share our semantics
[13:05] <@thesjg> corecode: which i think are correct (there was an
event that occured while the fd was in the watch list)
[13:06] <@thesjg> corecode: if one wanted it to exhibit poll-like
behavior i think the right approach would be to add a flag, which
would be ok i think
We were just talking about this on IRC. I was going to work up a test
case rather than a patch as I didn't know how willing the ISC was to
accept external patches. I can do either.
Sam
Re: upgrade packs
> The source(s) for the client and build tools for freebsd-update are available. > > http://www.freebsd.org/cgi/cvsweb.cgi/projects/freebsd-update-server/ > http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/freebsd-update/ > > Sam > Sascha was kind enough to point out that Matthias has already ported this and there has already been a thread regarding binary updates: http://leaf.dragonflybsd.org/mailarchive/users/2007-12/msg00036.html Sam
Re: upgrade packs
On Sat, Apr 10, 2010 at 8:27 AM, Jan Lentfer wrote: > Justin C. Sherrill schrieb: >> >> You could probably try this with two separate virtual machines - 1 2.4 and >> 1 2.6. Hint hint. > > Don't even need 2 VMs, 2 repositories one with 2.4 and one with 2.6 would be > sufficient because they will end up in 2 different objdirs. Actually that is > how I am keeping my lame VIA C7 box up to date. I just mount the repo and > the objdir via NFS on the C7. > > Jan The source(s) for the client and build tools for freebsd-update are available. http://www.freebsd.org/cgi/cvsweb.cgi/projects/freebsd-update-server/ http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/freebsd-update/ Sam
Re: amd64 - invitation to test
On Tue, Aug 18, 2009 at 8:57 AM, Simon 'corecode' Schubert wrote: > Jordan Gordeev wrote: >> >> Now, that GSoC is over, I have some spare time to say thanks. >> I'd like to thank all the people who have tested the amd64 port, namely >> Matthew Dillon and Antonio Huete Jimenez. Thanks for all the bugs you've >> found and fixed. > > Thanks to you for your great work! If every SoC works out as well as your > last two did, we'd be very happy. > > cheers > simon > Jordan, I would like to echo Simon's words. Congratulations on a successful SoC and thank you for all of your hard work. Sam
Re: 7-Zip / Bzip2
"Samuel J. Greear" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] "Matthew Dillon" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] :Hi, : :Posted this to kernel@ by accident, please reply here instead :) : :I just wanted to know if there's any interest for the devs to add :something like p7zip to the base install; even if it's a simple fork :that only supports 7z. While 7zip is about as obnoxiously slow as :bzip2, it usually gets much better compression. : :That's not why I'm suggesting it though - what really gets me is that :bzip2 has no "list" option. Does that 10 gb bzip2 backup archive :contain 100gb of data, or 200gb? Other than dumping the entire :archive to /dev/null through wc, there's really no way to do it. Gzip :will list files, but its compression ratio is awful. : :I imagine that other OSes are going to be watching Dragonfly very :carefully in the next while as new the features (especially HAMMER) :mature. Maybe adding 7z will get yet another bandwagon going and :there will be support across the board :) : :Best Regards, :Ben Cadieux Well, I think not in base, at least not unless a lot of people are using it. p7zip is readily available via the pkgsrc tree and that's the most reasonable method of accessibility for now. -Matt Matthew Dillon <[EMAIL PROTECTED]> I do not know if DragonFly is actively tracking libarchive, but it seems to be "the ticket" for implementing new archiving/compression methods through a common mechanism. If one wanted to see 7z functionality in base implementing a libarchive provider is probably the way to go. I did a quick test at one point on the dfly distribution ISO and as I recall 7z was ~60% the size of bzip2 using standard settings. food+thought, etc. Sam I got yelled at on IRC for not providing times, so here: Key: Selected Archiver - Compression Time - Threads - FileSize Source file: dfly-1.12.2_REL.iso - 295,512KB Bzip2 - 0:27 - 4 - 108,742KB Bzip2 - 1:24 - 1 - 108,742KB Decompress: 0:10 GZip - 0:55 - 1 - 118,024KB Decompress: 0:10 Zip - 0:55 - 4 - 118,024KB Zip - 0:55 - 1 - 118,024KB Decompress: 0:11 7Zip - 1:50 - 2 - 73,952KB 7Zip - 3:09 - 1 - 73,952KB Decompress: 0:12 All done via the most unscientific methods available (reporting user time as displayed by the 7Zip user interface), so treat it as such. Tested on an Intel Q6600 (4x2.4GHz) w/ single SATA disk. "Default" compression settings were used across the board. Everything was tested using the windows 7-Zip program, which integrates all of these algorithms. Sam
Re: 7-Zip / Bzip2
"Samuel J. Greear" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] "Matthew Dillon" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] :Hi, : :Posted this to kernel@ by accident, please reply here instead :) : :I just wanted to know if there's any interest for the devs to add :something like p7zip to the base install; even if it's a simple fork :that only supports 7z. While 7zip is about as obnoxiously slow as :bzip2, it usually gets much better compression. : :That's not why I'm suggesting it though - what really gets me is that :bzip2 has no "list" option. Does that 10 gb bzip2 backup archive :contain 100gb of data, or 200gb? Other than dumping the entire :archive to /dev/null through wc, there's really no way to do it. Gzip :will list files, but its compression ratio is awful. : :I imagine that other OSes are going to be watching Dragonfly very :carefully in the next while as new the features (especially HAMMER) :mature. Maybe adding 7z will get yet another bandwagon going and :there will be support across the board :) : :Best Regards, :Ben Cadieux Well, I think not in base, at least not unless a lot of people are using it. p7zip is readily available via the pkgsrc tree and that's the most reasonable method of accessibility for now. -Matt Matthew Dillon <[EMAIL PROTECTED]> I do not know if DragonFly is actively tracking libarchive, but it seems to be "the ticket" for implementing new archiving/compression methods through a common mechanism. If one wanted to see 7z functionality in base implementing a libarchive provider is probably the way to go. I did a quick test at one point on the dfly distribution ISO and as I recall 7z was ~60% the size of bzip2 using standard settings. food+thought, etc. Sam I just noticed I still have these sitting here so I figured I would post sizes. 1.12.1 ISO 294M, bz2 108M, 7z 74M, zip 118M, gz 120M. Sam
Re: 7-Zip / Bzip2
"Matthew Dillon" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] :Hi, : :Posted this to kernel@ by accident, please reply here instead :) : :I just wanted to know if there's any interest for the devs to add :something like p7zip to the base install; even if it's a simple fork :that only supports 7z. While 7zip is about as obnoxiously slow as :bzip2, it usually gets much better compression. : :That's not why I'm suggesting it though - what really gets me is that :bzip2 has no "list" option. Does that 10 gb bzip2 backup archive :contain 100gb of data, or 200gb? Other than dumping the entire :archive to /dev/null through wc, there's really no way to do it. Gzip :will list files, but its compression ratio is awful. : :I imagine that other OSes are going to be watching Dragonfly very :carefully in the next while as new the features (especially HAMMER) :mature. Maybe adding 7z will get yet another bandwagon going and :there will be support across the board :) : :Best Regards, :Ben Cadieux Well, I think not in base, at least not unless a lot of people are using it. p7zip is readily available via the pkgsrc tree and that's the most reasonable method of accessibility for now. -Matt Matthew Dillon <[EMAIL PROTECTED]> I do not know if DragonFly is actively tracking libarchive, but it seems to be "the ticket" for implementing new archiving/compression methods through a common mechanism. If one wanted to see 7z functionality in base implementing a libarchive provider is probably the way to go. I did a quick test at one point on the dfly distribution ISO and as I recall 7z was ~60% the size of bzip2 using standard settings. food+thought, etc. Sam
