Sponsored Content
Full Discussion: Are the BSDs dying?
The Lounge What is on Your Mind? Are the BSDs dying? Post 303012182 by drysdalk on Wednesday 31st of January 2018 10:59:36 AM
Old 01-31-2018
Hi,

Whilst there's no question that Linux is the dominant OS in the UNIX(ish) family, I don't personally think that the BSDs are going to go away any time soon.

For example, looking at OpenBSD, there has been some ongoing native innovation happening there. They've implemented their own Web and mail servers for instance, and also have recently added a replacement for sudo. Some of that work has also been cross-ported to FreeBSD. And all of this has happened within just the last few years. Now, the question of whether doing such things is worthwhile is a separate issue and an exercise left for the reader, but nevertheles there are things happening in the BSD world that don't have anything to do with Linux, and which are happening entirely under their own momentum.

Likewise, don't count out the commercial UNIXes just yet. Oracle just yesterday released the first beta of Solaris 11.4, and have committed to provding extended support for Solaris 11.x until 2034. I've not really got any involvement with the AIX or HP-UX worlds at all myself, but I'd again be surprised if these OS's up and die any year soon. There's just too much to be gained from some very lucrative (and very locked-in) customers for them to pull the plug on their in-house UNIXes any decade soon.

And to play the real Devil's Advocate here, don't forget the most popular UNIX distros in the world in terms of number of installations and sites: iOS and macOS. OK, my tongue is definitely a bit in my cheek as I type this, and the user interface and use-case design targets for these are wildly different from anything in the "proper" UNIX/server world, but there's no denying that they are genuine proper all-in-caps-trademark UNIX systems, and again show no signs of disappearing in anything like the near future.

So whilst there's no doubt that Linux is the de facto winner of the UNIX-a-like OS wars, and ultimately almost all new deployments taking place will be on Linux and not the BSDs or any proprietary UNIX, the other survivors will continue to do quite nicely in their own little niches for a long time to come, I think.

And who knows what the future has in store ? In the early 1990s there weren't many people predicting that the established big boys (Sun in particular) would meet the fates that the ultimately did. All things must pass, and in the end Linux too will be replaced by something else that we can't currently see or imagine.
These 2 Users Gave Thanks to drysdalk For This Post:
 

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
CLRI(8) 						    BSD System Manager's Manual 						   CLRI(8)

NAME
clri -- clear an inode SYNOPSIS
clri special_device inode_number ... DESCRIPTION
Clri is obsoleted for normal file system repair work by fsck(8). Clri zeros out the inodes with the specified inode number(s) on the filesystem residing on the given special_device. The fsck(8) utility is usually run after clri to reclaim the zero'ed inode(s) and the blocks previously claimed by those inode(s). Both read and write permission are required on the specified special_device. The primary purpose of this routine is to remove a file which for some reason is not being properly handled by fsck(8). Once removed, it is anticipated that fsck(8) will be able to clean up the resulting mess. SEE ALSO
fsck(8), fsdb(8), icheck(8), ncheck(8) BUGS
If the file is open, the work of clri will be lost when the inode is written back to disk from the inode cache. 4th Berkeley Distribution April 19, 1994 4th Berkeley Distribution
All times are GMT -4. The time now is 12:30 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy