Slashdot Mirror

Why wouldn't he simply codify his preferences? I hear, he still holds some sway among Linux developers — once a particular style is accepted by consensus, it becomes easier to convince folks to follow it...

Interestingly, the style Mr. Torvalds prefers has been part of BSD's style(9) manual for decades.

Maybe, he should leave children's to children and join a real OS-project...

I was hopiing Apple would license ZFS

ZFS is under CDDL and would not even need to be "licensed" in the usual sense — it is free for anybody to take. "Too free" for certain zealots, in fact, which is why it was not part of Linux kernel for a while — until the supposed "license incompatibility" myths got debunked.

Even Linux now offers ZFS — Apple would've had a much easier time porting it, because MacOS is already FreeBSD-based and the FreeBSD-project had ZFS available "out of the box" for several major releases spanning many years.

What did Apple find lacking about ZFS, that would justify creating their own, is, indeed, a mystery. Probably, a case of the Not Invented Here Syndrome. Sad...

It has caused huge problems for many Linux users, as evidenced by the many mailing list posts and bug reports describing serious problems with it. A recent example is how a systemd change broke tools like screen and tmux [slashdot.org].

What in the fuck us wrong with Linux devs?

systemd is nothing more than a bad cooy of OS X's launchd. Launchd has been an integral part of OS X since 10.4 (Tiger). That means that OS X had been happily using essentially the same concept as systemd for TWELVE YEARS. But even when that figure was 1 or 2 years, launchd didn't cause anywhere NEAR the problems with OS X or its Developer Community that systemd has caused in the Linux world.

So WTF is the problem? Are Linux System Devs REALLY THAT INCOMPETENT?

Maybe it's time to kick Pottering's code to the curb, take a clue from FreeBSD, and rally behind launchd. Afterall, Apple DID give it to you guys!!!

Yes, but why do you recommend a crap choice?

Some better ones:

https://linuxmint.com
https://kororaproject.org
https://getfedora.org
http://alpinelinux.org
http://www.ghostbsd.org
http://www.openbsd.org
https://www.freebsd.org

He's... not even wrong. It's rather impressive, the number of misconceptions and sheer volume of ignorance he manages to cram into just six short paragraphs.

It was actually quite strange of UNIX that it by default let arbitrary user code stay around unrestricted after logout.

Except that it wasn't by default. You logout, your shell gets the HUP signal. That signal gets propagated down to all of the shell's children, and all of their children, and their children - all the way down to the end of the chain. By default, HUP terminates a given process. If it doesn't terminate a process as described, it's because one of three things has happened. First possibility: the process has deliberately severed its child-parent relationship with the shell, as any program designed to run as a daemon will do. Second possibility: the process has explicitly set a signal handler to trap (or ignore) the HUP signal. Third possibility: the process has been launched with the nohup command (which effectively is the same as the second possibility).

If a program hangs around after logout that isn't supposed to, that's a bug in the program, not in the operating system. The defaults are all set up properly; if a program deliberately sets out to ignore them, presumably that's for a good reason.

It has never been the default that a program will just hang around forever for no good reason.

we should consider it our duty as Fedora developers to improve the Linux platform

Right. That's it. I'm done. I'm out. I've been involved with Linux in some form or another since the days of the a.out to ELF transition - over ten years. I've been grumbling about systemd breaking a whole bunch of conventions for no good reason since I first laid eyes on it. This? This is the straw that broke the camel's back. Any operating system that quietly introduces a breaking change like this - something that is a fundamental part of the design of the Unix operating system, that is a basic assumption that every long-term Unix user is aware of - is not an operating system I want to have to deal with. Sure, it's easy to change the configuration setting for this thing. What about the next change that breaks something fundamental? Or the one after that? Or the one after that?

This isn't good enough. Sure, sometimes change is necessary - the a.out to ELF transition was done for good reasons; swapping out telnet to ssh was done for good reasons - but this kind of subtle breakage is a huge time sink to any halfway serious systems administrator.

Well, at least there are alternatives out there.

If you waited a few months, the needed drivers came out, and all was well.

In 1994 I was struggling with a modem, that worked fine under Windows, but would not work under FreeBSD.

This wasn't a "winmodem" in the sense it required a driver to function. But it had to be initialized and would not work without that.

To my delight, certain phk added the code necessary to allow a userspace program (which he also wrote) to load the modem's firmware into the chip — you had to load different code (supplied on manufacturer's floppies) depending on whether you wanted to use it for data (SLIP, PPP, kermit, etc.) or faxing. I, for one, was most grateful.

Unfortunately, the same guy deleted the functionality some years later — claiming, it was too hard to maintain and "nobody wants it, or whoever does, should ask the manufacturer to supply drivers — the usual...

This rendered my old computer — which I kept around for faxing — unupgradable. I was, actually, able to maintain the local diff for the feature for some time longer, but not long enough — the little ISA-card outlasted FreeBSD support for it.

I still run Linux on my workstations because it's easier to get all the workstation/laptop things working there. However, I'll give FreeBSD a try on the desktop as well next time I reinstall.

On the server, there are really no benefits to Linux currently.

From https://www.freebsd.org/doc/ha...

"Creating a ZFS storage pool (zpool) involves making a number of decisions that are relatively permanent because the structure of the pool cannot be changed after the pool has been created. The most important decision is what types of vdevs into which to group the physical disks. See the list of vdev types for details about the possible options. After the pool has been created, most vdev types do not allow additional disks to be added to the vdev. The exceptions are mirrors, which allow additional disks to be added to the vdev, and stripes, which can be upgraded to mirrors by attaching an additional disk to the vdev. Although additional vdevs can be added to expand a pool, the layout of the pool cannot be changed after pool creation. Instead, the data must be backed up and the pool destroyed and recreated."

It was too restrictive for me.

Upgrade To Cost $119 After July 29

The upgrade is free - before, during and after July 29.

IIRC the kernel dropped boot floppies around version 2.6

Last time I installed OpenBSD and NetBSD they installed from one and two floppies each if I remember correctly.

Back before then I think Debian maybe had like five or something..

See, this is how it's done:
http://ftp.eu.openbsd.org/pub/... - The _ONE_ floppy required to net-install OpenBSD 5.9 i386.
http://ftp.eu.openbsd.org/pub/... The _ONE_ floppy required to net-install OpenBSD 5.9 AMD64.

Wow, NetBSD uses _FIVE_ floppies now?!
http://ftp.fi.netbsd.org/pub/N...

FreeBSD doesn't even offer floppy-installation any more?
ftp://ftp.se.freebsd.org/pub/F...

If we're using the full desktop DVD .iso file for Ubuntu 16.04 (amd64), and not the Ubuntu Core, Server, or netinstall images, then it's 1.4 GB.

Slackware 14.1 is 2.4 GB (source: http://www.slackware.com/getsl... )
FreeBSD is 2.7 GB (source: ftp://ftp.freebsd.org/pub/Free... )
Solaris 11.3 is 1.4 GB for the USB (source: http://www.oracle.com/technetw... )
Devuan beta is 4.36 GB (source: https://files.devuan.org/devua... )
Fedora 23 Workstation is 1.4 GB (source: https://getfedora.org/en/works... )

https://wiki.freebsd.org/GPLin...

Some time ago the Xorg ATI driver team decided that they would exclusively support KMS (Kernel Mode Switch) which obviously is NOT implemented in FreeBSD and anywhere except Linux. Basically it costed me US$1000 in unusable hardware since I falsely believed that my beloved Radeons would still be supported. The news of about 1 year ago are that the old console driver cannot support KMS but the new console driver does not support KOI-8r codepage which is required here in Russia. In other words, the hardware is still unusable. https://wiki.freebsd.org/Newco...

Almost the same problems plagued the Intel drivers (X cannot exit to text mode) at least when I tested it with FreeBSD 10.1. So I am forced either to use VESA drivers or install Geforces.

And I don't care about BSOD since it's a Windows thing and the Windows is almost nonexistent for me during 18 years.

You haven't given any technical explanation of why RealTek hardware isn't worth the effort, and on this page it shows support in BSD for half a dozen model numbers from RealTek. You must be talking about a different model? There could be many reasons the developers haven't spent time on it other than the quality of the design. For example, a simple lack of people.

You could explain, for example, how the DMA engine in the card is broken or that it drops interrupts (if either of those is the case). Just saying it's crap isn't very credible without technical background.

My impression was that nVidia provided a proprietary driver, thus not long-term supportable once they lose interest.

I have a number of Supermicro boards. Actually their driver and firmware support is not great, and I have complained about their boards to them, only to get the answer that they work correctly on Windows. I buy them because they have remote management, but have given up on their remote management implementations and will go with an external solution next time. My latest Supermicro board is a C7X99-OCE-F and as you can see here, they don't claim BSD support at all. On Linux they have some IOMMU issues at the moment.

Yeah, it's funny that you're full of shit.

I just tested it. Sleep works fine as well. The documentation on it is straight forward and easy to read: https://www.freebsd.org/doc/ha...

Tested it and it works fine.

I've used FreeBSD (custom ISO -- meaning a 9.3-STABLE snapshot ISO, rather than 9.3-RELEASE) on Vultr.com for a while now -- quite reliable. I also used FreeBSD on cari.net (dedicated, expensive) as well as ARP Networks (highly recommended provider with excellent peering and networking, but disk I/O on their VPSes is abysmally slow).

Be aware that Vultr's VPSes have HPET enabled (or "VM translated" somehow) in the BIOS, which is causing load average problems (i.e. box will show LA of 0.20 or higher when the system is doing literally nothing). This appears to be specific to FreeBSD 10.x. This can happen on both bare metal as well as a VM. Full details are in bug 173541, including a response from a kernel dev who insists nothing is wrong.

Same AC here.

I'm all for disk encryption, assuming it's being done 1) with the user/owner's knowledge (i.e. at their request and that they've been educated as to the caveats of its use) and 2) there are multiple public software applications or suites that can decrypt the data in situations where data recovery is needed. The end-user needs to be in control of both. My feeling is that when someone purchases a drive, the data on that drive is theirs -- it shouldn't be essentially "locked" by some chip the buyer has no knowledge of.

Things like Microsoft's BitLocker and some other software-based (as in "OS-based") encryption fall into the "OK that's fine" category -- meaning the user has some possibilities/options where recovery may be possible (from a drive that went bad, say, able to dd 99.8% of it to a donor/spare). Linux and FreeBSD both have their own software-based encryption stacks as well -- I forget what the one on Linux is (sedutil rings a bell -- thank you!), but on FreeBSD there are gbde(8) and geli(8). I consider those worthwhile solutions for the time being. They're not flawless, but they're good in the sense they allow the end-user full control. I'm absolutely certain Windows has many choices as well (not sure about recovery scenarios, though -- most data recovery companies I've encountered will immediately reject the support case if any kind of encryption is knowingly used).

What I described in my post above is completely transparent, hardware-based encryption -- the USB bridge chip on the drive PCB is what's doing the encryption without the owner's knowledge. This isn't gdbe, geli, or sedutil -- this is proprietary stuff, hence the reverse-engineering PDF white paper. Equally as bad, there's no way to disable/turn off the encryption in advance of use of the drive (hence why I used the word "transparent"). The PDF referenced actually reads fairly easily; I don't have a college degree yet I understood about 85% of it. We're talking about vendor lock-in encryption, with no backwards compatibility either. It reminds me of hardware RAID controllers in essence, actually. You can't find open public documentation of the chips or encryption in question, nor can you find any public (free or reasonably-priced commercial (for end-users)) software that deals with it either.

This hardware-level encryption doesn't help with any scenario I can think of other than one: making data recovery painful. It doesn't help with stolen drives or misplaced/lost drives (Fortune 500s care mainly about those two scenarios) -- the thief or person who acquired the drive can plug it in and access everything, as there's no password or "key" or anything else. The Register published an article last year pretty much stating exactly this -- and my own experiences mirror their opinion. That said, there is one piece of software that is proprietary and hasn't fully been examined/explained: WD's SmartWare suite. To my knowledge, nobody is sure if this is what controls the underlying encryption bits of the USB bridge chips or if it's something else completely (I keep finding conflicting statements on data recovery forums).

WHY THE HELL ARE YOU NOT MIGRATING TO SOMETHING ELSE??!!!?

BECAUSE THE GRAPHICS STACK IS STILL INCOMPLETE!1!!111!LOL!1!!11!

And no, OperatingSystemd aka TOSFKAGL (The OS Formerly Known As GNU/Linux) is not an option.

Don't use Winblows, use Linux or something.

You cretinous hobo, or somesuch.

All file systems are approximately the same for most day to day users.

ZFS is not merely yet another way to arrange pieces of your files on the disks (and "disks") — it is a filesystem and a volume-manager in one.

I would be interested in knowing which is fastest at read/writes.

ZFS adds features, which are a rarity among other filesystems: checksumming, options for redundancy and deduplication, snapshots, etc.

We spent decades keeping the underlying storage separate from the filesystem on top of it — neither ufs, nor xfs, nor ext know, what actual hardware is underneath the /dev/foo — and SCSI or (S)ATA protocols is all they can use to talk to this device. In these days of RAIDs and SSDs, the newfs(8) still has notions of sector-sizes and cylinder-groups, for crying out loud.

With ZFS we have a filesystem, that is aware of the underlying hardware and can make a good use of that knowledge. It is, what Unix filesystem would've been, had we had RAIDs in the seventies... But the above-mentioned checksumming and snapshots as well as redundancy and deduplication options are useful even on with a single drive.

For home users, basically meaningless.

Come, come, even FreeNAS users use ZFS on their systems to protect their content from "bit rot" and hardware failures. Smarter folks have been turning to FreeBSD, which has been offering ZFS for years — and Linux developers started working on porting it to Linux long ago — first as a FUSE-module, and now, finally, as part of the kernel.

BitZtream was wrong. A fix has been committed which adds the missing parenthesis.

How the fuck are you so sure that the code in question is "working as intended"?

For MOD_LOAD, random_source_register(&random_nehemiah) is only called under very specific circumstances.

Yet for MOD_UNLOAD, random_source_deregister(&random_nehemiah) is called even if random_source_register(&random_nehemiah) wasn't called during MOD_LOAD.

Deregistering something that was not registered properly in the first place is often a very dangerous, and incorrect, thing to be doing!

Oh, and guess what? A FIX WAS JUST FUCKING COMMITTED FOR THE BUG THAT YOU INCORRECTLY CLAIMED DIDN'T EXIST!

You should apologize to all of us for your snide, and incorrect, bullshit.

who is paying you for your evil words ?

or is it just the common devil worshipping of your culture?

No, that's the other BSD :-)

And when it comes to our operating systems of choice, it's not a religion. Far more faith than one.

Well, nothing is bug free, but you won't have to deal with that steaming pile of dung that is glibc

Drepper was Pottering before Pottering was uncool.

It's just been automated.

groups=...,0(wheel),5(operator)

https://lists.freebsd.org/pipe...

I replaced a job with a gid.

If you want to get technical, had Windows not added the proprietary field, we're just talking a KDC implementation, as in Heimdal Kerberos, or before that, MIT

_just_ ? Try setting setting up IPA sometime. That's just LDAP and Kerberos too. Have fun...

LDAP is really easy. Well, it is for me:

From the OpenLDAP commit logs:
===
1.1.4.1 Sat Aug 8 23:05:28 1998 UTC; 17 years, 6 months ago by kurt
CVS Tags: FreeBSD_3_3; Branch: FreeBSD
Changed since 1.1: +0 -0 lines
Diffs to 1.1 (colored diff)
Import of FreeBSD LDAP 3.3 Port
---
1.1 Sat Aug 8 22:43:17 1998 UTC; 17 years, 6 months ago by kurt
Initial revision
---
1.1.3.1 Sat Aug 8 22:43:17 1998 UTC; 17 years, 6 months ago by kurt
CVS Tags: LDAP_3_3+prerelease, UMICH_LDAP_3_3, BOOLEAN_LDAP, LDAP_POSTE, LDAPworld; Branch: UMICH ; Branch point for: RAGE
Changed since 1.1: +0 -0 lines
Diffs to 1.1 (colored diff)
Import of Umich LDAP 3.3
===

See that 1.1.4.1? Those are my patches to get OpenLDAP working from UMich LDAP sources. It added about 40 platforms. OpenLDAP started with the UMich LDAP, added my patches, and then went on from there. Originals of the (120K of) patches are HERE:

http://www.freebsd.org/~terry/...

Just because something is hard for you, doesn't make it hard for the rest of us. Some of us have been doing this for nearly two decades.

You can run Docker on FreeBSD thanks to the 64-bit Linux compatibility layer that was added last year.

With closed kernels

What "closed kernels"? BSDs and Linux all come with complete sources — and detailed instructions for using them to fine-tune your kernel.

and binary blobs

Some device-drivers require the manufacturer-provided binary-blobs, yes. But, if you don't trust those, you should not trust the very devices either... And, of course, Hurd does not support those devices — blobs or not — anyway.

From FreeBSD's site:

ARM is officially a Tier 2 architecture, as the FreeBSD project does not provide official releases or pre-built packages for this platform due to it primarily targeting the embedded arena.

And once you get it installed, you get the joy of cross-compiling ports or waiting days/weeks/months for them to compile on the system itself (if you have the space or set up an NFS host to use). And you still get the treat of using uboot.

FreeBSD's support lifetime for its versions isnt nearly as long.

"based on a Unix-like software called FreeBSD"

Wow, the lack of comprehension here is amazing.

So they managed to install Linux on a machine already running an OS based on an open source Unix which already comes with a full Linux kernel/software compatibility layer? That's such an amazing accomplishment...

What will they do next, get some ports running on it and make it do useful work? Figure out how to get a unix shell on an OS X machine?

The difference is BSD Jails are entirely separate environments with their own unshared kernel datastructures, and the jail communicates with the host via an API. Linux namespaces is just metadata added to shared environments.

I'm sorry, but this notion is completely wrong. A BSD Jail is a forked process (the "jail process"), which calls the "jail" kernel system call and then executes a chroot. The jail syscall serves to attach the "prison" data structure to the "proc" data structure of the jail process, allowing the kernel to identify the process as "jailed" and treat it accordingly. The isolation of the environments is dependent entirely on the kernel recognizing that the process is jailed and putting the appropriate restrictions on it.
https://www.freebsd.org/doc/en...

An LXC container is a forked process with a chroot that is assigned a set of namespaces, which are then restricted by kernel cgroups and kernel capabilities. The end result is that the forked process is only able to communicate with other processes within its namespace and is only allowed to access resources that cgroups allow that namespace to access. The only way for a containerized process to communicate with the host is through a vnet bridge device, which is similar to way it works with Jails.
https://libvirt.org/drvlxc.htm...

So in other words, the specific implementations details are different, but the result is nearly identical. A forked process executes a chroot and then is assigned a special status by the kernel which determines which resources it can access and which processes it can communicate with.

I'd also like to see what, if anything, is FreeBSD doing as a succession for system init.

Launchd is one of many potential routes.

An installation of FreeBSD using bsdinstall does not automatically install a graphical user interface. This chapter describes how to install and configure Xorg, which provides the open source X Window System used to provide a graphical environment. It then describes how to find and install a desktop environment or window manager.
Note: Users who prefer an installation method that automatically configures the Xorg and offers a choice of window managers during installation should refer to the pcbsd.org website.

Why would you assume you can only run pfsense on x86? Besides, if you have a successful FreeBSD hack you could make yourself famous by sharing it now. What processor you run has very little impact on security.

https://www.freebsd.org/platfo...

Nothing as far as a distro (or desktop environment) with 3D VR or AI comes to mind but there is innovation in OS going on. Not many have attempted to answer the OP, so here's my list. Others mentioned Qubes, Urbit, and Mirage.io, which reminded me of Nix OS and HaLVM.

Both innovative and seems daily-driver ready:
1. Qubes OS - https://www.qubes-os.org/ - Linux distro that runs a Xen hypervisor to contain every app (including Windows ones) away from the desktop environment
2. Haiku OS - https://www.haiku-os.org/ - Tiny (under 200MB installed), Non-Linux that is binary-compatible with BeOS, nice understated GUI that is bland but usable
3. ReactOS - http://reactos.org/ - Win32 compatible open source OS, very active development scene working toward full NT kernel ABI compatibility. Seems stable enough to be a daily driver but hardware support is lacking
4. PC-BSD & freeBSD 10 - http://www.pcbsd.org/ http://www.freebsd.org/ - PC-BSD is a desktop distro of freeBSD 10 built for user-friendliness with automatic ZFS snapshoting and a nice graphical package manager, freeBSD 10 has a completely new package manager (pkg-ng replaces the 'pkg' binary)
5. Nix OS - https://nixos.org/ - Linux distro with innovative package manager promising atomic upgrades & rollback.

Innovative server-exclusive (ie no GUI):
5. SmartOS - https://smartos.org/ - Solaris + KVM + Docker w/ full Dtrace support. Claims ZFS as an innovation? Joyent is running a cloud of it
6. CoreOS - https://coreos.com/ - Linux distro exclusively for large Docker deployments. developing a suite of Go tools for datacenter management.

Innovative, but not ready for desktop use:
7. Redox OS - http://www.redox-os.org/ - OS written in Rust (rust-lang), which guarantees a lot of memory-safety, screenshots of desktop in 'News' section
8. Contiki OS - http://www.contiki-os.org/ - Linux distro for IoT embedded devices that claims an innovative network stack
9. Urbit - http://urbit.org/docs/user/int... - *nix distro with exclusively web-based userland, invite-only at the moment, doesn't seem like it will have a UI but that each user is the dev of their own interface
10. Mirage.io - http://mirage.io/ - Develop each app and compile into a single-purpose kernel to be run on some hypervisor
11. HaLVM - https://github.com/GaloisInc/H... - The Haskell Ligthweight Virtual Machine - which runs just the GHC on Xen, another 'build uni-purpose VMs' system

Your link is someone spamming the FreeBSD mailing list.

https://lists.freebsd.org/pipe...

From the comments on the bug report:

As a female committer, I have to say that you're asking to be treated
differently by proposing unnecessary changes in such a fashion. While
the wording could have been better in regards to being more
professional (such as the patch that pjd committed), saying that a
female isn't going to use FreeBSD because of a humorous statement in a
man page is ridiculous.

If you don't want to see prejudice in IT communities, stop making
everything a gender issue. Instead, if you would like to see more
changes in the future, propose a phrasing that is more professional
and leave your gender out of it.

-- randi

It is amazing how people change.

The same disclaimer also appears in the man page for groff_mdoc. Seems like it's getting popular!

Throughout the UNIX manual pages, a manual entry is simply referred to as a man page, regardless of actual length and without sexist intention.

(captcha: miseries)

try this instead

That does sound better than this description. We'll see how it goes.

Does BSD have Dtrace?

Yes why?

It's actually newfs(8)

Not so fast - after all, guess what Cisco chained into their Nexus line of switches? (NX-OS is not using a FBSD kernel, after all.)

It's not that FBSD is failed or failing, but because Linux has a much bigger mindshare nowadays, which means you can more easily get the real esoteric and custom bits for your needs, especially without having to write it all yourself.

Yes, I know FBSD has linux compatibility and stuff, but that's not the point.

We're getting to the point where the Linux kernel itself is superb, but everything built on top of it is becoming utter shit. This is unfortunate, because the kernel alone is not very useful. The kernel's actual usefulness comes from it laying a solid foundation for the great things that could potentially be built upon it.

There was a billion Android devices shipped last year. It has 98% market share on the TOP500 supercomputer list. About 92% of Amazon's EC2 cloud servers run some form of Linux. Maybe we'll still be waiting for YotLD ten years from now, but I don't think anything could reverse that momentum. The entire FreeBSD ports tree had in Q1 2015 a bit less than 7000 commits from 163 developers, there's a ton of work missing to reach feature parity with the Linux kernel and nobody complained about it in the first place, I think there already was a "BSD-like" init system called OpenRC and it'd probably be less work to finish that than to write all the bits that are missing from Linux. Either way the problem is how many packages you must maintain that don't support your init system upstream.

Personally I wish Google would take a play from the Microsoft playbook and introduce the Android desktop, then again at this point it might be seen as admitting Microsoft has a point about one device from smartphones to tablets to laptops to desktops. Then again their Chromebooks are very successful, unfortunately really since they got you very hooked up to the mothership.

Um, no.

https://lists.freebsd.org/pipe...

That post is dated, but significant parts of OS X's kernel constructs are *BSD derived. Please note while the link is focused on FreeBSD code in OS X, that isn't the only BSD code Apple drew from.

All common Linux FS (EXT2/3/4, XFS, JFS, BRTFS, etc) and probably all common BSD/OS X (though I'm not sure) support more fine-grained access control in the form of POSIX Access Control Lists (ACL). I'm not 100% sure if it supports all of your use cases, but it certainly supports the 'grant access to every member of this group except A, B and C', since the permission model is essentially 'most specific match wins'.

Here's the relevant end-user ACL documentation for FreeBSD

SJW, Randi Harper in particular. My opinions on my social media accounts are my own and have nothing to do with my code or how I code. I don't need doxxed and fake rape reports being called in (as happened to a FreeBSD Developer) for making an off handed comment on Twitter or have something buried in my comment history.

Nobody forgot this shit. If it was better now, I would say it is. It's not.

Linux is the natural flight to quality and BSD is awesome as well. Windows is death knell.

I won't argue ONE BIT (haha) about EVERYTHING you say about the Windows Registry (and trying to troubleshoot Windows problems). Been there, done that. Printed my OWN T-Shirt. Multiple times. I hate, hate HATE the Windows Registry. Even though I haven't personally been hosed by it for a long time. It still scares me every time I type "Regedit", even if it's just to look at something.

And I really don't have an opinion on systemd, because I don't run Linux. However, I would really like to know if you have an opinion on OS X's Open-Sourced launchd; which is somewhat similar in purpose and scope to systemd (but I think came before systemd). Apple has literally millions of copies of launchd in the field, and has been using it since OS X 10.4 (Tiger), which was launched (no pun) a decade ago. And I haven't heard any real horror stories about it. And I see that FreeBSD has adopted it as well. And launchd has normal, ordinary Logs...