Sponsored Content
Full Discussion: Are the BSDs dying?
The Lounge What is on Your Mind? Are the BSDs dying? Post 303012227 by Neo on Wednesday 31st of January 2018 11:15:49 PM
Old 02-01-2018
There is nothing "dead" about BSD. BSD lives in the heart and soul of MacOS, and MacOS is a very popular computer operating system. All software changes over time, and BSD is no exception and BSD changed the heart of the MacOS forever:

Reference:

BSD Overview

Quote:
BSD Overview

The BSD portion of the OS X kernel is derived primarily from FreeBSD, a version of 4.4BSD that offers advanced networking, performance, security, and compatibility features. BSD variants in general are derived (sometimes indirectly) from 4.4BSD-Lite Release 2 from the Computer Systems Research Group (CSRG) at the University of California at Berkeley. BSD provides many advanced features, including the following:

Preemptive multitasking with dynamic priority adjustment. Smooth and fair sharing of the computer between applications and users is ensured, even under the heaviest of loads.

Multiuser access. Many people can use an OS X system simultaneously for a variety of things. This means, for example, that system peripherals such as printers and disk drives are properly shared between all users on the system or the network and that individual resource limits can be placed on users or groups of users, protecting critical system resources from overuse.

Strong TCP/IP networking with support for industry standards such as SLIP, PPP, and NFS. OS X can interoperate easily with other systems as well as act as an enterprise server, providing vital functions such as NFS (remote file access) and email services, or Internet services such as HTTP, FTP, routing, and firewall (security) services.
Memory protection. Applications cannot interfere with each other. One application crashing does not affect others in any way.

Virtual memory and dynamic memory allocation. Applications with large appetites for memory are satisfied while still maintaining interactive response to users. With the virtual memory system in OS X, each application has access to its own 4 GB memory address space; this should satisfy even the most memory-hungry applications.
Support for kernel threads based on Mach threads. User-level threading packages are implemented on top of kernel threads. Each kernel thread is an independently scheduled entity. When a thread from a user process blocks in a system call, other threads from the same process can continue to execute on that or other processors. By default, a process in the conventional sense has one thread, the main thread. A user process can use the POSIX thread API to create other user threads.

SMP support. Support is included for computers with multiple CPUs.

Source code. Developers gain the greatest degree of control over the BSD programming environment because source is included.

Many of the POSIX APIs.
 

7 More Discussions You Might Find Interesting

1. Ubuntu

Internet dying in Debian?

For some reason after a while my internet connection dies. I just moved on to Debian from Ubuntu and I can't find the dhclient-program to reconfigure dhcp. Pretty new to *nix's. ONe thing I noticed while rebooting (do get my connection back) is that it configures dhcp and says: reconfigure (or... (1 Reply)
Discussion started by: riwa
1 Replies

2. IP Networking

network connection dying after an uptime of a day or two days

hie guys I am running fedora 6 on remote machines which are connecting to my server. The remote machines connect through one machine (more like my router) to the server. The problem i am having is that the remote machines are suppose to be reporting in real time mode to the server. Most of these... (2 Replies)
Discussion started by: no3more
2 Replies

3. Boot Loaders

EFI on BSDs problem

Hi, at time I have some problems installing a BSD system on my GPT disk... Thing is, I don't understand why support for the EFI seems to be so hard. Neither FreeBSD nor NetBSD nor OpenBSD seem to be able to install on GPT disks. They all misconceive the hard disk would use an MBR and the DOS... (6 Replies)
Discussion started by: Blackbird
6 Replies

4. Programming

Java application dying randomly

Hi, (First post, please be gental!) I have a java app that I am running on unix (centos) But it keeps dying randomly. The times seem random from anything between 3 hours and 3 days. I have a cronjob running to restart it when ever it dies but I would rather this happened less often. ... (2 Replies)
Discussion started by: sm9ai
2 Replies

5. Shell Programming and Scripting

Expect script cronjob running but dying prematurely

I have an Ubuntu machine that I'd like to update automatically. I've written an expect script to run the aptitude package manager and update my packages. Essentially it does: aptitude update && aptitude upgrade while answering "yes" at the appropriate time. It works quite nicely when run... (4 Replies)
Discussion started by: CluelessPerson
4 Replies

6. Shell Programming and Scripting

Utilities not dying after script run

Hi folks, Friendly router geek wanting to be a programmer here... So I worked with another guy here and came up with this to capture Unix admin data: #!/bin/ksh # # # Set Default Paths # PATH=/usr/apps/client/bin:$PATH; export PATH... (4 Replies)
Discussion started by: Marc G
4 Replies

7. Red Hat

Snmpd dying on centos7.1

Hello All, SNMPD dying after 2 mins once it started. Here is the configuration Oct 12 04:43:00 localhost systemd: Starting Simple Network Management Protocol (SNMP) Daemon.... Oct 12 04:43:00 localhost snmpd: dlopen failed: /usr/lib64/libcmaX64.so: cannot open shared object file: No such... (1 Reply)
Discussion started by: shekar777
1 Replies
aio_proc_threads(5)						File Formats Manual					       aio_proc_threads(5)

NAME
aio_proc_threads - maximum number of process threads allowed in AIO pool VALUES
Failsafe Default Allowed values Recommended values DESCRIPTION
The implementation of POSIX AIO on HP-UX uses kernel threads to perform I/Os to filesystems that do not directly support true asynchronous I/O. (This distinction is transparent to the user.) The kernel threads are organized into worker-thread pools (called AIO thread pools) created on a per-process basis. Since a thread pool mechanism for I/Os introduces a variety of trade-offs concerning utilization of CPU time vs. I/O resources, four dynamic tunables are available to customize the behavior of this thread pool: aio_proc_threads(5), aio_proc_thread_pct(5), aio_req_per_thread(5), and aio_monitor_run_sec(5). Please see individual manpages for details on each of these tunables. The tunable specifies, on a per-process basis, the maximum number of process threads that can be used by the POSIX AIO system as kernel threads for issuing I/Os. This tunable interacts with in the following way: the maximum number of threads used for AIO will be the smaller of the two values defined by the two tunables, i.e.: This allows the number of AIO threads to vary dynamically with but to always be bound by an absolute limit of Who Is Expected to Change This Tunable? System administrators that run applications requiring heavy usage of POSIX AIO to filesystems. Restrictions on Changing This tunable is dynamic. Changes to to this tunable take effect immediately for new processes started after the change. They also impact existing processes, but the speed with which the changes propagate to running processes is determined by the tunable When Should the Value of This Tunable Be Raised? should be raised for applications that do not use very many threads for their own work, but desire high performance from the POSIX AIO sub- system. What Are the Side Effects of Raising the Value of This Tunable? Some applications that use POSIX AIO but also require a large number of threads may find that they are unable to create new threads. (This could happen if the POSIX AIO thread pool ends up using too many of a process' allowable threads.) In addition, using a larger number of kernel threads might lead to increased CPU utilization. When Should the Value of This Tunable Be Lowered? should be lowered when POSIX AIO performance is acceptable but applications using POSIX AIO are seeing errors when trying to create new threads for other work. What Are the Side Effects of Lowering the Value of This Tunable? By ultimately reducing the number of threads available to handle POSIX AIO requests, overall I/O throughput of the POSIX AIO subsystem could be reduced. What Other Tunables Should Be Changed at the Same Time as This One? interacts with this tunable by setting a limit on the number of AIO threads based on a percentage of the maximum number of allowable process threads. This allows the AIO thread pools to respond dynamically to changes in defines the desired relationship between the number of POSIX AIO kernel threads and the number of I/Os to be serviced. defines how often (in seconds) the AIO thread mechanism will monitor itself for adherence to the constraints defined by the tunables above. WARNINGS
All HP-UX kernel tunable parameters are release specific. This parameter may be removed or have its meaning changed in future releases of HP-UX. Installation of optional kernel software, from HP or other vendors, may cause changes to tunable parameter values. After installation, some tunable parameters may no longer be at the default or recommended values. For information about the effects of installation on tun- able values, consult the documentation for the kernel software being installed. For information about optional kernel software that was factory installed on your system, see at AUTHOR
was developed by HP. SEE ALSO
kctune(1M), sam(1M), gettune(2), settune(2), aio_proc_thread_pct(5), aio_req_per_thread(5), aio_monitor_run_sec(5). Tunable Kernel Parameters aio_proc_threads(5)
All times are GMT -4. The time now is 09:16 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy