Misplaced Pages

#153846

43-405: The ports collection uses Makefiles arranged in a directory hierarchy so that software can be built , installed and uninstalled with the make command. When installing an application, very little (if any) user intervention is required after issuing a beginning command such as make install or make install clean in the ports directory of the desired application . In most cases the software

86-565: A database and weekly builds logs are also available through mailing list archives. These pre-compiled packages are separated into categories by the architectures for which they are available. Packages are further separated into several "release" directories, one for each current production release built from the ports collection and shipped with the release. These production release directories are never updated. There are also stable and current directories for several major release branches. These are updated more or less weekly. In most cases

129-461: A binary distribution model is that the installation can be tuned and optimized according to available resources. For example, the system administrator can easily install a 32 bit version of a package if the 64 bit version is not available or is not optimized for that machine. Conversely, the main disadvantage is compilation time, which can be significant. For example, a full installation of a FreeBSD system, using ports, can take several days, depending on

172-477: A built-in kernel debugger to help the developers find kernel bugs. Furthermore, as of October 2004 , a debug kernel, which makes bug reports more useful for tracking down kernel-related problems, is installed by default, at the expense of a relatively small quantity of disk space. When a new kernel is installed, the backup copy of the previous kernel and its modules are stripped of their debugging symbols to further minimize disk space usage. The operating system

215-516: A collection of patches and files that overlay and modify the FreeBSD Ports, in order to generate DPorts. Ports collection Ports collections (or ports trees , or just ports ) are the sets of makefiles and patches provided by the BSD -based operating systems , FreeBSD , NetBSD , and OpenBSD , as a simple method of installing software or creating binary packages. They are usually

258-519: A package by passing the package name to the pkg install command. This downloads the appropriate package for the installed FreeBSD release version , then installs the application, including any software dependencies it may have. By default, packages are downloaded from the main FreeBSD Package Repository (pkg.freebsd.org), but if there are any troubles after updating packages, previous version of packages cannot be installed because

301-581: A package created for an older version of FreeBSD can be installed and used on a newer system without difficulty since binary backward compatibility across major releases is enabled by default. A packaging system for binary packages called pkg has replaced the package management system in FreeBSD 10. Jordan Hubbard committed his port make macros to the FreeBSD CVS repository on August 21, 1994. His package install suite Makefile had been committed

344-566: A resource to be shared among multiple threads. The serializing token code is evolving into something quite similar to the " Read-copy-update " feature now available in Linux. Unlike Linux's current RCU implementation, DragonFly's is being implemented such that only processors competing for the same token are affected rather than all processors in the computer. DragonFly switched to multiprocessor safe slab allocator , which requires neither mutexes nor blocking operations for memory assignment tasks. It

387-474: A year earlier (August 26, 1993). The core ports framework was at first maintained by Hubbard along with Satoshi Asami for several years. The Ports Management Team was later formed to handle this task. NetBSD's pkgsrc and OpenBSD's ports collection trace their roots to FreeBSD. Since its release, 3.6 DragonFly BSD project uses FreeBSD Ports as a base for its own DPorts ports collection. John Marino of DragonFly BSD project created DeltaPorts repository –

430-560: Is automatically downloaded from the Internet , patched and configured if necessary, then compiled , installed and registered in the package database. If the new port has needed dependencies on other applications or libraries, these are installed beforehand automatically. Most ports are already configured with default options which have been deemed generally appropriate for most users. However, these configuration options (called knobs ) can sometimes be changed before installation using

473-659: Is distinctive in that it aims to be portable and is usable on a number of operating systems aside from NetBSD itself, including the other BSDs, SmartOS / illumos , macOS , MINIX 3 , Linux and other Unix-likes . pkgsrc was created in August 1997 based on the existing FreeBSD ports system. It follows a quarterly release schedule and as of October 2018 contains over 22'000 packages. With their 1.4 release, DragonFly BSD announced that they would be adopting pkgsrc as their official package management system. DragonFly BSD however built their own ports implementation called dports with

SECTION 10

#1732793367154

516-411: Is distributed as a Live CD and Live USB that boots into a complete DragonFly system. It includes the base system and a complete set of manual pages, and may include source code and useful packages in future versions. The advantage of this is that with a single CD users can install the software onto a computer, use a full set of tools to repair a damaged installation, or demonstrate the capabilities of

559-438: Is running at any given time. Blocked or sleeping threads therefore do not prevent other threads from accessing the shared resource unlike a thread that is holding a mutex. Among other things, the use of serializing tokens prevents many of the situations that could result in deadlocks and priority inversions when using mutexes, as well as greatly simplifying the design and implementation of a many-step procedure that would require

602-488: The FreeBSD Ports collection as its official package management system , but starting with the 1.4 release switched to NetBSD 's pkgsrc system, which was perceived as a way of lessening the amount of work needed for third-party software availability. Eventually, maintaining compatibility with pkgsrc proved to require more effort than was initially anticipated, so the project created DPorts, an overlay on top of

645-613: The FreeBSD Ports collection. The initial implementation of Common Address Redundancy Protocol (commonly referred to as CARP ) was finished in March 2007. As of 2011, CARP support is integrated into DragonFly BSD. Alongside the Unix File System , which is typically the default file system on BSDs, DragonFly BSD supports the HAMMER and HAMMER2 file systems. HAMMER2 is the default file system as of version 5.2.0. HAMMER

688-555: The GNU Compiler Collection has an enhancement called the Stack-Smashing Protector (ProPolice) enabled by default, providing some additional protection against buffer overflow based attacks. As of 23 July 2005 , the kernel is no longer built with this protection by default. Being a derivative of FreeBSD, DragonFly has inherited an easy-to-use integrated build system that can rebuild

731-509: The make config command, which brings up a text-based interface that allows the user to select the desired options. Historically, each port (or software package) has been maintained by an individual port maintainer who is responsible for ensuring the currency of the port and providing general support. Today, many ports are maintained by special task forces or sub-projects, each with a dedicated mailing list (e.g. kde@FreeBSD.org, java@FreeBSD.org, etc.), while unmaintained ports are assigned to

774-568: The prelinking capability that was being worked on earlier in the project's history, as the resident support is much more efficient. Large programs like those found in KDE Software Compilation with many shared libraries will benefit the most from this support. As with FreeBSD and OpenBSD , the developers of DragonFly BSD are slowly replacing pre- function prototype -style C code with more modern, ANSI equivalents. Similar to other operating systems, DragonFly's version of

817-580: The x86-64 platform. DragonFly originally ran on the x86 architecture, however as of version 4.0 it is no longer supported. Since version 1.10, DragonFly supports 1:1 userland threading (one kernel thread per userland thread), which is regarded as a relatively simple solution that is also easy to maintain. Inherited from FreeBSD, DragonFly also supports multi-threading. In DragonFly, each CPU has its own thread scheduler. Upon creation, threads are assigned to processors and are never preemptively switched from one processor to another; they are only migrated by

860-552: The FreeBSD project. Due to conflicts with other FreeBSD developers over the implementation of his ideas, his ability to directly change the codebase was eventually revoked. Despite this, the DragonFly BSD and FreeBSD projects still work together, sharing bug fixes, driver updates, and other improvements. Dillon named the project after photographing a dragonfly in his yard, while he was still working on FreeBSD. Intended as

903-445: The ability to act in either a synchronous or asynchronous fashion, and attempts to use this capability to achieve the best performance possible in any given situation. According to developer Matthew Dillon , progress is being made to provide both device input/output (I/O) and virtual file system (VFS) messaging capabilities that will enable the remainder of the project goals to be met. The new infrastructure will allow many parts of

SECTION 20

#1732793367154

946-473: The base of a package management system , with ports handling package creation and additional tools managing package removal, upgrade, and other tasks. In addition to the BSDs, a few Linux distributions have implemented similar infrastructure , including Gentoo 's Portage , Arch 's Arch Build System (ABS) , CRUX 's Ports and Void Linux 's Templates. The main advantage of the ports system when compared with

989-504: The entire base system from source with only a few commands. The DragonFly developers use the Git version control system to manage changes to the DragonFly source code . Unlike its parent FreeBSD, DragonFly has both stable and unstable releases in a single source tree, due to a smaller developer base. Like the other BSD kernels (and those of most modern operating systems), DragonFly employs

1032-469: The generic group ports@FreeBSD.org. In general, anyone may become a port maintainer by contributing their favorite software to the collection. One may also choose to maintain an existing port with no active maintainer. Precompiled (binary) ports are called packages . A package can be created from the corresponding port with the make package command; pre-built packages are also available for download from FreeBSD-hosted package repositories. A user can install

1075-412: The hardware. Jordan Hubbard committed his port make macros to the FreeBSD CVS repository on August 21, 1994. His package install suite Makefile had been committed a year earlier (August 26, 1993). The core ports framework was at first maintained by Hubbard along with Satoshi Asami for several years. The Ports Management Team was later formed to handle this task. NetBSD's pkgsrc ports collection

1118-497: The kernel to be migrated out into userspace; here they will be more easily debugged as they will be smaller, isolated programs, instead of being small parts entwined in a larger chunk of code. Additionally, the migration of select kernel code into userspace has the benefit of making the system more robust; if a userspace driver crashes, it will not crash the kernel. System calls are being split into userland and kernel versions and being encapsulated into messages. This will help reduce

1161-508: The lack of resources. This effectively forced users to run -current ports/base tree in order to keep up with security updates. In 2009, it was decided to revive the -stable ports tree under supervision of Robert Nagy and Jasper Lievisse Adriaanse. There are three unofficial web sites with a listing of OpenBSD ports and packages: DragonFly BSD DragonFly BSD is a free and open-source Unix-like operating system forked from FreeBSD 4.8. Matthew Dillon , an Amiga developer in

1204-477: The late 1980s and early 1990s and FreeBSD developer between 1994 and 2003, began working on DragonFly BSD in June 2003 and announced it on the FreeBSD mailing lists on 16 July 2003. Dillon started DragonFly in the belief that the techniques adopted for threading and symmetric multiprocessing in FreeBSD 5 would lead to poor performance and maintenance problems. He sought to correct these anticipated problems within

1247-458: The logical continuation of the FreeBSD 4.x series, DragonFly has diverged significantly from FreeBSD, implementing lightweight kernel threads (LWKT), an in-kernel message passing system, and the HAMMER file system . Many design concepts were influenced by AmigaOS . The kernel messaging subsystem being developed is similar to those found in microkernels such as Mach , though it is less complex by design. DragonFly's messaging subsystem has

1290-404: The need for pre-populated /dev file system hierarchy. It was implemented as a Google Summer of Code 2009 project. DragonFly BSD supports Amiga -style resident applications feature: it takes a snapshot of a large, dynamically linked program's virtual memory space after loading, allowing future instances of the program to start much more quickly than it otherwise would have. This replaces

1333-451: The next DragonFly BSD version (5.0.0) would include a usable, though still experimental, version of HAMMER2, and described features of the design. With the release after 5.0.0, version 5.2.0, HAMMER2 became the new default file system. In 2007 DragonFly BSD received a new device file system (devfs), which dynamically adds and removes device nodes, allows accessing devices by connection paths, recognises drives by serial numbers and removes

FreeBSD Ports - Misplaced Pages Continue

1376-478: The passing of an inter-processor interrupt (IPI) message between the CPUs involved. Inter-processor thread scheduling is also accomplished by sending asynchronous IPI messages. One advantage to this clean compartmentalization of the threading subsystem is that the processors' on-board caches in symmetric multiprocessor systems do not contain duplicated data, allowing for higher performance by giving each processor in

1419-501: The program to work on OpenBSD and a packing list listing the files to be included in the packages. The ports tree uses a set of standard makefiles, some of which are shared with the source tree, to provide the bulk of its functionality; this shared infrastructure includes many utility functions for port developers and means that ports can often be made very simply. In late October 2007, OpenBSD developer Nikolay Sturm announced that -stable ports tree should be considered unmaintained due to

1462-402: The real kernel. These include the kqueue -based timer, the console (mapped to the virtual terminal where vkernel is executed), the disk image and virtual kernel Ethernet device ( VKE ), tunneling all packets to the host's tap interface. Third-party software is available on DragonFly as binary packages via pkgng or from a native ports collection – DPorts . DragonFly originally used

1505-468: The real kernel: it lacks many routines for dealing with the low-level hardware management and it uses C standard library (libc) functions in place of in-kernel implementations wherever possible. As both real and virtual kernel are compiled from the same code base, this effectively means that platform-dependent routines and re-implementations of libc functions are clearly separated in a source tree. The vkernel runs on top of hardware abstractions provided by

1548-503: The release 3.4 and switched over to it completely with 3.6. The development is done via their git. In contrast to FreeBSD Ports , on which it was originally based, the OpenBSD ports system is intended as a source used to create the end product, packages : installing a port first creates a package and then installs it. Ports are made up of a makefile, text files with descriptions and installation messages, any patches required to adjust

1591-459: The repository denies subfolders indexes. In this case, a user must upgrade the OS version to the latest release and install latest packages. FreeBSD maintains a build farm called the pointyhat cluster in which all packages for all supported architectures and major releases are built. The build logs and known errors for all ports built into packages through the pointyhat cluster are available in

1634-478: The same resource at the same time. In order to prevent multiple threads from accessing or modifying a shared resource simultaneously, DragonFly employs critical sections , and serializing tokens to prevent concurrent access. While both Linux and FreeBSD 5 employ fine-grained mutex models to achieve higher performance on multiprocessor systems, DragonFly does not. Until recently, DragonFly also employed spls , but these were replaced with critical sections. Much of

1677-443: The size and complexity of the kernel by moving variants of standard system calls into a userland compatibility layer , and help maintain forwards and backwards compatibility between DragonFly versions. Linux and other Unix-like OS compatibility code is being migrated out similarly. As support for multiple instruction set architectures complicates symmetric multiprocessing (SMP) support, DragonFly BSD now limits its support to

1720-541: The system the ability to use its own cache to store different things to work on. The LWKT subsystem is being employed to partition work among multiple kernel threads (for example in the networking code there is one thread per protocol per processor), reducing competition by removing the need to share certain resources among various kernel tasks. In order to run safely on multiprocessor machines, access to shared resources (like files, data structures) must be serialized so that threads or processes do not attempt to modify

1763-657: The system's core, including the LWKT subsystem, the IPI messaging subsystem and the new kernel memory allocator, are lockless, meaning that they work without using mutexes, with each process operating on a single CPU. Critical sections are used to protect against local interrupts, individually for each CPU, guaranteeing that a thread currently being executed will not be preempted. Serializing tokens are used to prevent concurrent accesses from other CPUs and may be held simultaneously by multiple threads, ensuring that only one of those threads

FreeBSD Ports - Misplaced Pages Continue

1806-571: Was developed specifically for DragonFly BSD to provide a feature-rich yet better designed analogue of the increasingly popular ZFS . HAMMER supports configurable file system history, snapshots , checksumming , data deduplication and other features typical for file systems of its kind. HAMMER2, the successor of the HAMMER file system, is now considered stable, used by default, and the focus of further development. Plans for its development were initially shared in 2012. In 2017, Dillon announced that

1849-499: Was eventually ported into standard C library in the userland, where it replaced FreeBSD's malloc implementation. Since release 1.8 DragonFly has a virtualization mechanism similar to User-mode Linux , allowing a user to run another kernel in the userland. The virtual kernel ( vkernel ) is run in completely isolated environment with emulated network and storage interfaces, thus simplifying testing kernel subsystems and clustering features. The vkernel has two important differences from

#153846