Hacker News Reader

One big thing for me is that I trust the FreeBSD devs to not completely reinvent things unless they're sure it's an improvement.

I got sick of the churn in Linux, having to relearn things all the time and then find out when I'm done that it's not any better, just different.

Things I learned how to do in FreeBSD a decade ago still work. For example, to get a NIC configured I can either put one or two lines of text in rc.conf, (which I have pretty much memorized at this point), or stop and learn what RedHat thinks is the coolest way to do network config this year.

Watching iptables get replaced was a really depressing example of that, after the developers swore that "this time we got it right" when replacing ipchains......

Thanks - clearly I wasn't paying attention as I had not noticed NFtables. Another exciting task to look forward too, then.

In fairness IPTables has been around and considered stable for, what, more than a decade and a half now?

I'm sure there are great many things that I consider "right" now that will be wrong in 15 years time either due to changes in the environment in which they work or me otherwise learning new information or developing new techniques over time.

... and ipchains (in 2.2) replaced ipfwadm.

I haven't had reason to use nftables yet (beyond the default config in a distro), but if it's in any way closer to PF, then it's vastly superior to iptables in my eyes. I spent a while configuring OpenBSD firewall/VPN gateway boxes about a decade ago, and the all around superiority of PF was astounding.

I'm inclined to agree that there probably aren't any great reasons why you would benefit from FreeBSD rather than Debian, but just to correct one misconception:

I don't have GBs of free memory for ZFS

In the early days of ZFS it required many GB of memory -- it was developed for Solaris, and designed for servers with lots of memory. But it has improved dramatically since it first came to FreeBSD, and people run it with far less memory these days.

How much RAM is required these days?

There are definitely people running ZFS on systems with less than 1GB of RAM. I'm not sure if anyone is running ZFS on a system with less than 512 MB of RAM.

(FWIW, at one point the amount of address space was far more important than the amount of RAM -- amd64 systems with 1 GB of RAM would run better than i386 systems with 2 GB. I'm not sure if this is still the case.)

Back in the days of OpenSolaris, I was absolutely running it on 512MB, including a Gnome 2 desktop. I won't claim it won any records for speed, but it absolutely worked, and the data survived a rather nasty intermittent disk controller failure.

No first-hand experience with ZFS on BSD, but I believe in the early days of the ZFS port there were issues where if the system came under sudden memory pressure, ZFS might not hand its RAM back to the kernel fast enough, leading to (I guess) a panic. So this is a fit-and-finish issue with a specific port, not an inherent ZFS issue, but it seems to have fed into the whole notion of "ZFS needs bucketloads of RAM".

A big user of RAM in ZFS is dedup and compression - which can both be disabled.

Compression does not use a significant amount of memory - it's the deduplication which uses a lot of memory. In fact compression can make it run faster as there is less I/O data.

Compression in ZFS doesn't use RAM, dedup tables, the arc and l2arc mapping tables are all that matters with regards to memory usage with ZFS. l2arc is where a lot of newbies end up shooting themselves in the foot, they go toss in a mirrored pair of 512GB SSD's for their l2arc on a system with 32GB of RAM and wonder why performance got worse or it crashed, or they enabled dedup on 24TB of data with 64GB of ram and wonder why it crashed and their zpool is beyond recovery.

If you are using ZFS without an l2arc or dedup enabled even a measly 1GB of RAM is "sufficient", you just won't get the best performance since it's going to have to constantly fetch from disk depending on your active data set (which is literally no different a problem than OS-level file caching in any other operating system).

Ah crap. The advice I got was just about the opposite - I wanted an L2ARC device in my system for performance.

Atom C2758, 32GB ECC RAM, 4x4TB in RAIDZ2 (losing that much storage was painful, and the $1200AUD upgrade path to 4x8TB even more so) with a 128GB SSD as L2ARC.

I found out some time later that I probably wanted an SLOG device instead but I'm really too afraid to touch my config. FWIW it's pretty stable on FreeBSD 10.3 with around 5GB RAM in use.

Your L2ARC shouldn't be bigger than 5x your system memory, ZFS has to keep mapping tables in-memory to determine where data on the L2ARC is stored, the bigger it gets the more memory you take away from your in-memory ARC, which can lead to worse performance than before since more data is having to come from your much higher-latency and lower bandwidth L2ARC or straight from spinning disks.

RAIDZ is a performance killer right off the bat, I would switch to using mirrored vdev's instead if throughput is an issue for you. Parity calculation kills write speeds, especially on slower CPU's like a C2758, and RAIDZ doesn't give you any extra throughput on reads since there's only one usable copy of a stripe to read from. I have 2x4TB disks in my pool as a mirrored vdev (with an additional 2x3TB coming after I get my 128GB flash drive for XenServer to free up my second 3TB disk again) and I get reads over 500MB/sec using 10Gig-E to my XenServer host, and equally fast writes. Disks are fairly cheap, RAIDZ is not a good solution if you need performance, and if you are using four disks in RAIDZ-2 you would lose the same amount of storage using two mirrored vdev's anyway (and save the increased potential of a rebuild failing due to multiple disk failures that is increasingly common on higher capacity drives).

If writes are a bigger problem for you, then, yes, a SLOG device will help - but any random SSD is not going to do. If you are using a SLOG ZFS expects it will not corrupt in-flight data following a power loss, even a "high-end" SSD like a Samsung 850 Pro or a Crucial MX200 will lose data in the event of a power failure. You also don't want a SLOG that isn't mirrored, if your SLOG is corrupted you just lost your entire pool. In addition you need a SSD with proper power-failure protection like the Intel DC series. Also, large writes skip the SLOG (>64KB) entirely, so if you are bandwidth bound (either from network or to disk) it is not going to help, if you are IOPS bound it can help tremendously.

Also, you mention 4x4TB and 4x8TB, I assume your issue is the available disk bays in your system? I personally ignore high-capacity drives as they are far too expensive, and my HP ML10 that I run FreeNAS off only has 1 internal drive bay (with a $50 add-on I can buy to install an extra 3), instead of dealing with internal drives as well as limited capacity I bought a cheap DAS array (Lenovo SA120, here's a picture of mine and my cheap TP-Link layer 3 switch http://i.imgur.com/eEvtP6Z.jpg) that cost me $200USD and connected it with an equally cheap LSI 9200-8e SAS HBA ($40), I now have 12 hot-swap drive bays and can replace my FreeNAS box without worrying about how many bays it has, if I need more I just need to buy an additional enclosure and daisy chain it off the first. This isn't a dirt cheap solution by any means (my homelab gear is easily worth over $1500 at this point, including my Lenovo TD340 acting as my XenServer host), but it will save you money in the long run by allowing you to easily buy many cheaper drives than fewer more expensive (but high capacity) ones.

And at this point I give up and go back to an off the shelf solution.

I do have mirrored vdevs but now you've made me doubt what configuration I put them in.

This stuff is so advanced it's not funny.

Also, where should I read up about DAS arrays? I didn't even know that was an option when I started building.

Edit: thanks for your help here - you don't have an email address listed in your profile but I'd like to discuss this further if you have the time.

DAS arrays are extremely easy to understand, they're just "expanders" - SAS has special support built in for this, in servers you typically have the front drive bays connected to a single SAS port on the board instead of individual cables running to each drive, a DAS is the same thing just as an external enclosure with separate power. You connect it to a basic SAS HBA with an external SAS port (SFF-8088), like the LSI 9200-8e I mentioned and it just shows up as a bunch of drives to your operating system. There's some special control services you have to the enclosure depending on the model through a protocol called SAS Enclosure Services (SES), my Lenovo SA120 uses this to manage things like fan speeds (very important, because every time it loses power it resets to HIGH which is VERY LOUD, I have a boot script on my FreeNAS box to set this back down to LOW which is much more manageable).

This seems like a lot, but you can ignore most of the technical details I just posted. Buy a SAS HBA with external ports, buy a SAS DAS array, plug it in and you see a bunch of drives - no fuss. Since SAS controllers can also support SATA drives you can save yourself $10-20 a drive and buy normal SATA disks, or you can get some added reliability (multi-pathing and error handling) and buy near-line SAS drives for a small premium (I don't bother personally, but I only have one controller installed in my SA120 so I have no second path for data to travel in the event of a failure anyway).

Feel free to hit me up anytime, I'm /u/snuxoll on reddit (pretty active on /r/homelab) and you can email me at stefan [a] nuxoll.me.

Doesn't look like I can use an expander with my chassis. http://www.supermicro.com/products/motherboard/atom/x10/a1sr.... Don't know why I was so set on this in the end. Had to import it, and then it wasn't really supported by FreeNAS.

You've got a PCIe 8X slot on there, plenty for a SAS HBA card if it isn't taken already. That's all you need to drive the DAS.

> if your SLOG is corrupted you just lost your entire pool

As far as I'm aware, SLOG loss does not jeopardise the pool, only the transactions that are in the SLOG. The pool may violate synchronous write guarantees in that supposedly committed writes that were in the SLOG effectively get rolled back (or rather, never get applied to the underlying pool), but that's about it.

Are you quite sure that is the best solution long term? All of those extra drives are using additional power.

1. zfs runs well on a lot of systems. You might have to change a setting or two but it's not as you say.

2. pkg install and the related pkg utilities have existed for awhile.

5. systemd isn't and shouldn't be a requirement for applications going forward. Any application that requires it is limiting its portability for unknown reasons.

The joy of trying a new system is the little things you learn that you weren't even aware of before.

Regarding your point 5: Application developers embrace systemd (and thereby reject portability to some extent) because it makes it easier for them to not do infrastructure work. A description of that phenomenon in KDE can be read here: http://blog.davidedmundson.co.uk/blog/systemd-and-plasma

So it's a feature. I cut myself from shitty software by using FreeBSD.

> pkg install and the related pkg utilities have existed for awhile.

So have apt and apt-get. So that takes away one of the advantages of FreeBSD

> systemd isn't and shouldn't be a requirement for applications going forward. Any application that requires it is limiting its portability for unknown reasons.

True, tell RedHat that :(

So have apt and apt-get. So that takes away one of the advantages of FreeBSD

Not completely. In Debian and others it's mostly a choice between a stable base and stale software or a moving base and up to date software (though backports improve things quite a bit for Debian Stable).

Since in FreeBSD packages are separated from the base system, it's possible to run a stable base system, while using quarterly updates or rolling release (latest) of packages.

(Note: I didn't have many problems running Debian Unstable, but it may depend on your requirements.)

Of course, there's nothing stopping people from using things like pkgsrc or Nix on Linux.

What would you consider the advantage of FreeBSD ports/packages? Why would that be taken away by pkg?

pkg provides a way to manage (binary) packages. There are other tools (like poudriere, last time I dabbled in the FreeBSD world) to manage/create binary packages.

You could run FreeBSD on your tiny VPS, but build packages with all the custom ports options you could want in a jail on your local machine.

The advantage of ports is that they are compiled for your machine. The minute you get precompiled packages, you might as well be on Debian

Well, the nice thing is that you can mix and match. Don't care about the configuration of a package, use pkg. Want to use a set op custom compilation options? Use ports with 'make config'.

> systemd isn't and shouldn't be a requirement for applications going forward. Any application that requires it is limiting its portability for unknown reasons.

How should one do it instead? Treat each alternative system specifically? Or is there a way to cover them all at once, including unknown and future ones?

How about this: don't write applications that depend on the init system.

Seriously, who ever thought such a dependency was a good idea? Who even thought it would be a good idea to make an init system that was possible for an application to be dependent on? This is exceedingly poor engineering, and I'm dumbfounded at its acceptance and spread.

Hint: Programming is not engineering.

I've heard this before, but I've seen pretty convincing arguments both pro and contra. I'd actually love to discuss this (not argue -- I honestly don't have a strong opinion on the topic at this time). If you're willing, my e-mail address is on my profile :)

Linux is fine for ordinary computing and many specialized tasks but some areas are better served by BSDs.

If you require the integrity guarantees offered by ZFS and still want the efficient resource allocation of containers you will not get around FreeBSD or a Solaris based distribution.

If you need a system that is secure by default you will not get around OpenBSD.

If you need the portability of Linux coupled with a license that lets you freely redistribute in order to sell an appliance you will be hard pressed to get around NetBSD.

By the way, ZFS will run fine on small VPS since the RAM cache can be turned off. You still get instant snapshots and rollbacks, efficient replication and integrity guarantees.

If you need the portability of Linux coupled with a license that lets you freely redistribute in order to sell an appliance you will be hard pressed to get around NetBSD.

It's perfectly legal to sell an appliance with Linux, people do it all the time.

You can't "freely redistribute" it though. You have to comply with the viral decidedly non-freeing provisions.

You can redistribute it as much as you want, providing you permit recipients to do the same thing. Entire industries have found this to be completely reasonable.

The only freedom you give up by using the GPL is the freedom to screw your users over by denying them access to the source code. All you are demanded is to let others enjoy the freedom you enjoy. That, surely, isn't too much to ask.

Meh, hardware vendors routinely ignore GPL, and for the money it takes to sue them in court you could in most cases reverse engineer their drivers and write them for scratch.

Yeah, NVIDIA is an "example" of that.

While I can appreciate that point of view (i.e. as a vendor), the definition does depend on whose POV you are looking at it from. From an end-user (individual or business) POV, the GPL is absolutely 'freely redistributable' what you're talking about is your inability to limit that ability. That's the GPL doing its job.

> That's the GPL doing its job.

It also makes it really hard to earn a living with actual software (not services) that depends on GPL.

Buy commercial licenses from authors of GPL code, so they will earn something too.

It is astonishing how many people don't know that they could do it.

I can see how that works for code that has zero compile-time dependencies on other copyleft software. I.e. a very limited usecase. Or am I getting something wrong?

Yes, you're absolutely correct. The GPL, and resulting GPL'd software, does not exist for the benefit of commercial software vendors. While some business models are viable under it, that's a side-effect rather than an objective of it.

i.e. it's condemned to be a hobby for almost everyone involved, besides some key players who can live off of donations or those who sell services based on mostly other people's software.

Selling services 'based on mostly other people's software' is not some crime or bad thing. Servicing cars or houses made by other people is an honorable profession. So are software services. If the thing needs servicing, then I salute those who stand ready to do the dirty work.

And I didn't say it is. Only that it's usually the only way of building a business around GPL software. This is fine for serving some people, but it has a huge blind spot for those who mainly want to write Software and try to live off of it. IMO this is the main reason why Desktop linux never took off - you just don't have enough userland software that's ready for production use in a professional environment - see desktop publishing, audio, video etc. This sort of software is not going to be written as a hobby, it needs full time professional developers and investors who can see the ROI starting at around 1M$.

And to many it's fine if it is. The GPL wasn't created to benefit the software industry, it was a reaction to it. That's also part of the reason that some commercial interests (most famously Apple) have been moving in the direction of MIT/BSD-style licenses. It's OK to align your efforts with licenses that match your requirements. The GPL is most aligned with the interests of users, not commercial developers. MIT/BSD is the reverse.

All of the software I have written for money is free software. In some fields it is hard to not do that: Wordpress plugins, for example, are GPL licensed by default. Can you elaborate what problems you have run into?

How would you solve the following use-case: You want users to be able to try your software for non commercial use, but you want them to pay for commercial. I don't see how GPL licenses can do that for you. In fact, I don't know any common OSS license that has non-commercial limitations with the option of purchasing a commercial license.

Creative Commons works that way. So its possible.

People keep saying CC, but that license has never been intended for software. Did it ever stand up to a trial in court for this usecase? See also [1]. Why isn't there something like CC NC geared for software?

[1] https://wiki.creativecommons.org/index.php/Frequently_Asked_...

> We recommend against using Creative Commons licenses for software. Instead, we strongly encourage you to use one of the very good software licenses which are already available.

Is it important if court has tested the license? A software license is like a will, in that it describes the authors intention in a legal binding document. A infringer would need to prove in court that their activity does not conflict with the requirements of the license, and the words "non-commercial" would be quite hard to sneak around. The main reason that FSF and similar activly advice against such license is primarily because "non-commercial" is ambiguous and there is a clear risk for the recipients/re-distributors if the original author starts to act abusive. A common example I have heard is public schools vs private school, where the later is a commercial activity and the former is common viewed as not. How that would translate to a student using it in a student project would be up in the air.

If I where you, I would instead copy the license of the unreal engine. That is, you don't look at the commercial status but rather on profits from products that include your work. If someone is earning profits, regardless of the nature of the organization who do so, then a cut is required to be given to you. Its simple, it fixes the school problem above, and there is a "industry" example to use if it ever became a court case. The big drawback is that its not an open source compatible license.

You can always dual-license the software. The GPL version of your software can always be a basic version, customers could pay for features they want to have.

Yes, but we're at the start again: Only when you don't depend on other GPL software at compile time (and even runtime bindings can be tricky AFAIK). So it only works if all people do is write a bunch of siloes and don't work as a community at all.

So, looking at Linux system software as an example, it only works as long as you stay far away from the kernel.

If you depend on software, the authors of the dependencies have done a part of your job for you. GPL basically says the authors only agree to help you on the condition that you also help others. You can always choose not to be a part of such a community, then you will not get help. What is the problem?

For me the problem is that GPL mixes up the requirement of "Open Source" (which I'm fine with) with a requirement that anything depending on it has to be GPL as well (which I have a problem with). Basically, if GPL would allow someone to sell licenses to his software as long as he keeps publishing the sources, it would go a long way to enable a userland application market on top of GNU based kernels.

Gnu.org could even demand a percentage of revenues going towards the GNU foundation. IMO that would make Linux even free-er since it would democratise the way kernel development is funded (i.e. redistribute some of the influence away from the big software corporations who currently chip in). Right now kernel development works fine because you have the right gatekeepers at the top (especially LT), but I wonder what happens when he retires - will some committee take over?

You're right, you can't "sell" GPL software. What you mean by "sell" is "grant a license for usage" and that's exactly what the GPL or a similar FOSS license does. So the two things conflict. Really you're describing a situation that the GPL is not designed for.

Your desires are more inline with Microsoft 'shared source' type of situations.

The GPL and the FSF's world-view isn't particularly aligned with what you want (I believe). Either use the GPL and live with the constraints, or use something else. Something else's that come-up in a GPL but commercial context are:

a. Service or Support. You've said you want to be paid for creating the software and not for providing services, so this one is out. Note that SaaS is now the easiest way to achieve what you want.

b. Dual licensing. You said "you can't depend on GPL software then". Well yeah, because GPL is about a commons of equals 'sharing' and you want to charge for sharing - so you don't get to use other people's stuff for free. Seems fair to me.

But, your actual concern isn't really valid - there are lots of things you can write without depending on GPL software. This is probably more realistic than you think.

c. Open core. Someone described this to you earlier, I think.

d. Validation and/or IPR. Probably outside the boundaries of most individual developers. But think of the way that Java is licensed on the basis of it being a 'valid' implementation and then IPR and trademarks.

NetBSD runs on a subset of the hardware that Linux runs on, other than supporting a very small number of systems built in the 90s that have never been supported by Linux. NetBSD's portability was a strong point in the past, but the massive industry acceptance of Linux means that there are giant numbers of shipped systems that came pre-installed with Linux and which have no support in the NetBSD kernel. There's a bunch of great reasons to choose NetBSD, but comparing its hardware support to Linux isn't one of them.

> I don't have GBs of free memory for ZFS

Only ZFS dedup uses goobles of RAM, and use of that is discouraged anyway.

> I don't have GB of RAM, CPU and HD space to build everything from ports, and most importantly, no need.

Last I checked, Debian now supports ZFS in form of a source DKMS package. No need to maintain your own setup.

If you go with Ubuntu instead, which provides binary ZFS packages, you can also use it as a rootfs to get full advantage of its capabilities[1].

That said, I've decided to just stick with btrfs, because it's in the mainline Linux kernel, and works well enough for my needs with absolutely zero hassle.

FreeBSD is nice though. No harm in trying it out to widen your horizon :)

[1] https://github.com/zfsonlinux/zfs/wiki/Ubuntu-16.04-Root-on-...

> I just can't find any serious use-cases where FreeBSD would be of any advantage.

Ditto. I definitely like the idea of FreeBSD (and, even more, OpenBSD), but neither really seems worth the pain. The fact that I can't just rely on third-party software working means that I can't use either for my personal desktop (I like to play proprietary games) or even for servers (without extensive testing ahead of time, anyway).

As for the license, I prefer the GPL over the BSDL. I don't see why third parties should be permitted to forbid their users from enjoying the same rights they themselves received. Nuts to that.

And, honestly, as much as BSDs are a nicely-integrated software suite, they are an old nicely-integrated software suite. As much as the GNU userland is … weird & inconsistent, it's also really powerful. I like having an ls which has added options since 1986.

I'd love to love the BSDs, but … I don't.

ZFS only needs GBs if you need deduplication. 99% don't, almost everyone is better off with compression. 1GB is the min for ZFS though it can run in a little less.

Too much. I've got a 700-800 MB system.

It's unfortunate, as I'd love to have a versioned FS

Well, if you're willing to tune settings there's an example on the FreeBSD wiki of someone with a laptop "running nicely" with 768M and their settings.

https://wiki.freebsd.org/ZFSTuningGuide

I've no idea what compromises that'll bring you, or how it would react to you pointing it at a multi TB space.

VMS could run a versioned FS in <128MB of RAM, so there's really nothing conceptually in the way. I bet with dedup off and some tweaking you can get ZFS to run in very little memory.

That's not really an apples to apples comparison. VMS versioning is a completely different thing than ZFS snapshots and copy on write.

> It's unfortunate, as I'd love to have a versioned FS

btrfs at your service then. Comes with the mainline Linux-kernel. Give it a spin!

HAMMER1 on DragonflyBSD runs well with little memory, including running dedup. It also has the binary pkg system just like FreeBSD. Also, the DRM drivers are up to date and support current Intel GPUs.

Huh. I had not really looked closely at DragonFly in a while. I had briefly looked at it when setting up my new server, but the fact that HAMMER does not deal with redundancy itself made me stick with FreeBSD/ZFS.

On a laptop, however (with an Intel GPU) that is not an issue, as there is only one disk, anyway. I might have to take a look over the summer.

Redundancy as advanced as ZFS can do would be sweet, but if you're ok with something simple, like a two disk setup, you can put a PFS on each and stream one disk to the other.

> It also has the binary pkg system just like FreeBSD.

Not just like, but the very same one. DPorts is FreeBSD ports with a few patches, and pkg in DragonflyBSD is pkg from FreeBSD.

> Also, the DRM drivers are up to date and support current Intel GPUs.

I believe FreeBSD is integrating that work itself. Intel GPU support on Dragonfly is pretty great.

> 1. I don't have GBs of free memory for ZFS

Others have already addressed the memory hog myth, so I'll just say that you aren't required to run ZFS - UFS still works just fine. I just sshed into my freebsd AWS instance (UFS) to see 116d uptime with 130MB ram in use and the remaining 110MB being free. I've made no effort to optimize resource usage on the instance, but if I wanted to I could pretty easily cut that by a third without a noticeable impact on performance.

> 2. I don't have GB of RAM, CPU and HD space to build everything from ports, and most importantly, no need.

You might be surprised to learn how many build options there are for the software you use daily. I jumped in with both feet and setup a jailed build server after wanting some uncommon build options for vim, ncurses and sqlite3.

> 5. systemd? ... didn't have the manpower ... I don't know how FreeBSD is doing in that regard.

It has made no attempt, which I'm pretty happy about. The only annoying thing from linux that keeps popping up on my freebsd desktop is dbus.

Which FreeBSD desktop do you use? I'm collecting recommendations before I try using one.

Try Lumina It's simple and light on resources.

https://lumina-desktop.org/

I was about to ask about it's robustness and security. Then, the website gave me 404 errors on features, news, and other sections on the website. Hmm. I'll still put it on the list, though, for non-critical use.

I don't use a DE, but I've used the tiling WM i3 for years:

https://i3wm.org

I am just a layuser, but I have had no issue running MATE and Gnome3 on my Lenovo Ideapad Y410p.

> 1. I don't have GBs of free memory for ZFS

ZFS does not require large amounts of RAM any more, unless you want to benefit from its impressive caching features and have large amounts of disk space.

> 2. I don't have GB of RAM, CPU and HD space to build everything from ports, and most importantly, no need.

Since FreeBSD 10, pkg-ng has been the standard. It unifies binary packages installable similar to apt and other linux package managers with your custom ports built packages as needed. Now you can mix and match seamlessly and there is no need to have an entire ports tree unless you have special needs.

> 3. License - I don't care. GPL is free enough for me.

Each to their own, but MIT and BSD are, to me, free-er and more friendly to business applications.

> 4. Base vs. Ports - Why should I care? Debian (testing!) is stable enough for me. Except for dist-upgrades, I never ran into issues, and then it may be faster to nuke the server from orbit. Now had BSD "appified" the /usr/local directory (rather than keeping the nginx binary in /usr/local/bin and conf in /usr/local/conf it would have kept everything related to nginx in a /usr/local/nginx) it would have been interesting, but now?

The layout you're discussing is basically what happens by default when things are `make install`ed most times without any customizations. The layout that you're lamenting makes sense enough and has merits, with no need to be "appified" -- that is what packages are for. Again, I implore you to check out pkg-ng, it is a core feature of the OS now.

> 5. systemd? The reason Debian went with systemd was (IIRC) because they didn't have the manpower to undo all of RedHat's work in forcing all applications to integrate into systemd (such as GNOME). I don't know how FreeBSD is doing in that regard

People are experimenting with alternative init systems in the BSD world, though we will likely never directly have SystemD, there are some efforts to support systemd unit files as well as some new directions taking into account Apple's work as well as lessons learned from systemd to build a BSD licensed alternative to all of the above.

> But FreeBSD?

FreeBSD brings to the table a free, cohesive, highly engineered and integrated operating system that is coming into its prime. There are a multitude of advanced features in terms of filesystems, networking, and more. FreeBSD has first class support in AWS and some other major cloud environments. However, FreeBSD has been and continues to be a server focused operating system. Even so, FreeBSD on the desktop is coming along, but it's certainly nowhere near linux in that regard.

In the end, each to their own, if you find a reason to like and use it, then great, but at the least you should look into it and learn what you can from it, like any system.

> Each to their own, but MIT and BSD are, to me, free-er and more friendly to business applications.

True, but I'm not going to sell OSs, and plenty of corporations are working on Linux