FreeBSD Multimedia Resources List
Links on this page refer to multimedia resources (podcast, vodcast, audio recordings, video recordings, photos) related to FreeBSD or of interest for FreeBSD users.
If you know any resources not listed here, or notice any dead links, please send details to Edwin Groothuis so that it can be included or updated.
DragonFlyBSD 2.8 with Matthew Dillon
Added: 06 November 2010
Tags: bsdtalk, interview, meetbsd, meetbsd2010, dragonflybsd, matthew dillon
Ogg version (15 minutes), MP3 version (7 Mb, 15 minutes)
Interview from MeetBSD California 2010 with Matthew Dillon about the recent 2.8 release of DragonFlyBSD. More information at http://www.dragonflybsd.org/
DragonFlyBSD with Matthew Dillon
Added: 07 January 2010
Tags: bsdtalk, interview, dragonflybsd, matthew dillon
Ogg version (34 minutes), MP3 version (16 Mb, 34 minutes)
An interview with Matthew Dillon. We talk about recent developments in DragonFlyBSD.
Justin Sherrill of the DragonFlyBSD Digest
Added: 19 January 2009
Tags: bsdtalk, interview, dragonflybsd, justin sherril
Ogg version (22 minutes), MP3 version (10 Mb, 22 minutes)
Interview with Justin Sherrill of the DragonFlyBSD Digest, which can be found at http://www.shiningsilence.com/dbsdlog/
Added: 16 August 2007
Tags: bsdtalk, interview, dragonflybsd, mattew dillon
Ogg version (20 minutes), MP3 version (10 Mb, 20 minutes)
Interview with DragonflyBSD's Matthew Dillon. We talk about the 1.10 release and the design of a new filesystem.
DragonFlyBSD Developer Matthew Dillon
Added: 08 February 2007
Tags: bsdtalk, interview, dragonflybsd, mathew dillon
Ogg version (24 minutes), MP3 version (12 Mb, 24 minutes)
Interview with DragonFlyBSD developer Matthew Dillon. We talk about the 1.8 release.
Robert Luciani - M:N threading in DragonflyBSD
Added: 24 May 2009
Tags: dcbsdcon, dcbsdcon2009, slides, dragonflybsd, concurrency, robert luciani
PDF (1.5 Mb, 23 pages)
Ineffective concurrency mechanisms in an operating system can lead to low performance in both single and multiprocessor environments. Practical setbacks involved with attempting overly invasive kernel changes have made it difficult in the past to implement new and innovative concurrency systems. This paper describes the rationale behind interfaces in the DragonFly BSD operating system intended to provide high performance and scalability on multiprocessor architectures. Using a lock-free processor centric approach, DragonFly BSD has developed a unique thread system with the potential for excellent scalability.
EuroBSDCon 2008 - Aggelos Economopoulos - An MP-capable network stack for DragonFlyBSD with minimal use of locks
Added: 22 October 2008
Tags: eurobsdcon, eurobsdcon2008, dragonflybsd, mp, network stack, aggelos economopoulos
MP3 (1 byte, 42 minutes), OGG (1 byte, 42 minutes), PDF (1 byte, n pages)
Given the modern trend towards multi-core shared memory multiprocessors, it is inconceivable for production OS kernels not to be reentrant. The typical approach for allowing multiple execution contexts to simultaneously execute in kernel mode has been to use fine-grained locking for synchronising access to shared resources. While this technique has been proven efficient, empirical evidence suggests that the resulting locking rules tend to be cumbersome even for the experienced kernel programmer, leading to bugs that are hard to diagnose. Moreover, scaling to more processors requires extensive use of locks, which may impose unnecessary locking overhead for small scale multiprocessor systems. This talk will describe the typical approach and then discuss the alternative approach taken in the DragonFlyBSD network stack. We will give an overview of the various protocol threads employed for network I/O processing and the common-case code paths for packet reception and transmission. Additionally, we'll need to make a passing reference to DragonFlyBSD's message passing model. This should establish a baseline, allowing us to focus on the recent work by the author to eliminate use of the Big Giant Lock in the performance-critical paths for the TCP and UDP protocols. The decision to constrain this work on the two by far most widely-used transport protocols was made in order to (a) limit the amount of work necessary and (b) explore the effectiveness of the approach on the cases that matter at this point in time.