
What I Learned from porting my projects to FreeBSD - zdw
https://github.com/shlomif/what-i-learned-from-porting-to-freebsd
======
raimue
The author mentions to be unsatisfied with the solution to use symlinks for
finding DocBook XSL files. The correct way to reference DocBook XSL
stylesheets is to use the HTTP URL to the stylesheet, which will be looked up
in the XML catalog of your system. This catalog file maps URLs to files on
disk and is managed by your package manager.

You should also forbid your tools to access these URLs directly (--nonet), as
it would be incredicly slow and you rather want your build to fail in this
case instead of downloading on-demand.

    
    
      xsltproc --nonet http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl foobar.xml
    

If you prefer to work with files instead of passing long URLs on command line,
use a small wrapper file to import the real stylesheet and pass that on
command line instead of using the URL. The advantage is that you can also put
additional <xsl:param> tags to customize the output right into this file.

    
    
      <?xml version='1.0' ?>
      <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
      <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl"/>
      <!-- put additional xsl:param here -->
      </xsl:stylesheet>

~~~
blattimwind
Isn't referencing something like
"[http://docbook.sourceforge.net/release/xsl/current/manpages/...](http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl")
wrong, because that refers to some unspecified version (note the "/current/"
bit)?

------
mcbain
If your makefiles use gnu-isms (which is a valid choice) then I would lean
towards using GNUmakefile and have Makefile call gmake - and don’t forget to
use $(MAKE) for any recursion.

This is less fragile and requires less dependence on replacing make in the
$PATH.

~~~
rwmj
Could do all that, but FreeBSD _could_ also have GNU make as the standard
"make". I know there's some "license purity" reason why they don't want to do
that, but don't expect everyone else to work around your self-imposed problem.

~~~
minusf
isn't make older than gmake? it is normally gnu that adds extensions not
compatible with the rest of the Unix world. making people believe sh == bash,
make == gmake, m4 == gm4, and the list goes on for everything they touch.

~~~
lmz
But BSD make has extensions too. They're just different extensions.

------
Sir_Cmpwn
For anyone interested, I'm providing FreeBSD CI services on sr.ht. We use it
to test wlroots[0].

[https://builds.sr.ht/~sircmpwn/job/9348](https://builds.sr.ht/~sircmpwn/job/9348)

I'm also working on OpenBSD and NetBSD, other kernels, and non-x86
architectures. If anyone is interested in using this to make their software
more portable, please let me know! Email in my profile.

[0] [https://github.com/swaywm/wlroots](https://github.com/swaywm/wlroots)

~~~
profquail
TravisCI has been asked repeatedly to provide FreeBSD as a build OS, and it
doesn’t appear they’re interested in expanding beyond Linux/macOS on x86:

* [https://github.com/travis-ci/travis-ci/issues/1818](https://github.com/travis-ci/travis-ci/issues/1818) * [https://github.com/travis-ci/travis-ci/issues/6671](https://github.com/travis-ci/travis-ci/issues/6671) * [https://github.com/travis-ci/travis-ci/issues/5473](https://github.com/travis-ci/travis-ci/issues/5473)

Do you plan on providing Github integration? Providing other OSes and
platforms (e.g. ARM64, ppc64el) would be really useful for testing low-level
projects like .NET Core runtime, node.js / libuv, etc., and integrating with
Github would make it really easy for people to start adding this to their
existing projects.

If you do end up providing Github integration, consider listing a paid option
for your service in the Github marketplace:
[https://github.com/marketplace/category/continuous-
integrati...](https://github.com/marketplace/category/continuous-integration)

~~~
Sir_Cmpwn
I already provide Github integration, but it's not very polished. That's how
wlroots gets built, for example:

[https://github.com/swaywm/wlroots/pull/1341](https://github.com/swaywm/wlroots/pull/1341)

(click "show all checks")

I may add it to the marketplace once it's open for public registration and
more polished.

------
nikisweeting
Just wait till you discover FreeNAS, pfSense, and OpenBSD! A world of awesome,
battle-tested software awaits once you join the BSD dark side.

~~~
metildaa
pfSense is great for a prosumer router. What gets me about it is cleaning up
the mess it creates in business use cases, as pfSense is designed with a
mindset that the pro will always be there, ready to attach a screen at a
moments notice when interfaces change or packages get updated. Running PHP as
root also isn't great, I'm not sure how that passes in the context of HIPPA.

~~~
closeparen
The HIPAA Technical Safeguards are compact, readable, and basic:
[https://www.law.cornell.edu/cfr/text/45/164.312](https://www.law.cornell.edu/cfr/text/45/164.312)

~~~
metildaa
Okay, but how does running one of the most commonly exploited languages as
root pass any HIPAA audit? That was the question asked in my prior comment.

We ended up ripping out PFSense at a few medical practices due in part to this
issue.

~~~
jimktrains2
You seem to be under the impression that the management UI is on a public
network. Ideally locked down to certain vlans.

The UI controls setting up the network and other services. Please explain how
to do this without root access. (Write another process which runs as root and
controls the settings and is talked to over a Unix socket actually isn't a bad
idea, however, it is not void of its problems either.)

Also "most commonly exploited languages" is a bit of hyperbole, no? First, C
probably takes that slot. Second, being one of the most common languages for
web development makes it a target. Third, most php exploits are bad code,
which, while easy to write in php (and c!), can be and is done in all
languages.

Isn't the administrator interface on _any_ router essentially root access on
said router? Do you complain that juniper or Cisco equipment is insecure
because you can login?

BMCs (Baseboard management controllers) are something with very ...
questionable ... security, yet network segregation is used to ensure its use
securely. Given that many HIPAA complaint organizations such as AWS and GCP
(Google Cloud Platform) I find it hard to believe that a management interface
would disqualify something from HIPAA compliance.

Which part of the HIPAA audit did pfsense fail? Was it simply an abundance of
caution" on your part? If so, what did you replace it with that didn't have a
management or has a management interface with no bugs (hint: even Cisco and
juniper have CVEs for the management interface)?

~~~
richardwhiuk
PHP makes it trivial to write bad code, and hard to write good code.

~~~
jimktrains2
So does C?

Also, php in no way makes it hard to write good code, it's just easy not to.

------
xvilka
Or just switch to Meson+Ninja [1][2] and enjoy all features of modern build
systems.

[1] [https://mesonbuild.com/](https://mesonbuild.com/)

[2] [https://ninja-build.org/](https://ninja-build.org/)

~~~
enriquto
In what sense isn't gnu make a modern build system?

~~~
Orphis
Make is a much of a build system as C++ as you can call stat() and system()
from it.

A modern build system by default should be able to provide utilities to make
sure your build is correct and reproducible. Those features need to be coded
into your Makefile and aren't available easily or by default.

If you need to code those rules, then you don't have a build system, just a
way to run commands and possibly add some (usually poor) logic around them.

A typical example that most handcrafted Makefiles will fail is that changing a
build flag should only rebuild the files affected. Most will either require a
full clean (aka ignoring the flag change) or rebuild everything.

~~~
enriquto
> A typical example that most handcrafted Makefiles will fail is that changing
> a build flag should only rebuild the files affected.

If you change a build flag, how aren't all the files affected?

~~~
hpcjoe
I've noticed a plethora of build options over the past decades. I keep hearing
how they are all "better" than make.

Then to build one particular bit of software, there is a dependency upon a
particular version of cmake, which you don't have.

Or you have to upgrade Maven. Or install some software you do not have by
default on your environment.

I've never had to do that with make.

I've been told that other tools are better because the are simpler ... that is
... until you run into one of those aforementioned compatibility issues with
the build tool.

This isn't an infrequent occurrence for me, I see lots of hardwiring for
various packages that I don't have installed by default in some projects.

Then you get the gophers/rust folk, and their need to run on the most recently
released kit. With all its undiscovered bugs. The gophers want to replace make
with mage ... well, to be more correct, they want to replace every non-go
based tool with one built in go, because ... go. A modern version of the
insufferable pythonistas of years past.

Throughout this, I've been using and building with Make just fine. My make
files do the heavy lifting in my projects. And I get a good laugh each time I
hear "oh I have to fix my magefile/CMakeFile.txt/yadda yadda yadda".

As the great philosopher Inigo Montoya once opined ... you keep using that
word [better]. I do not think it means what you think it means.

------
howard941
Another great thing about FreeBSD is it's not too hard going the other way:
Embedding FreeBSD is a robust choice, one that can take you quickly to market
as it did for me and a GPS on golf cart project I did in the late 90s with it,
busybox, and some valuable help from PHK on getting support for the weirdo LCD
panel the suits picked (we had to turn the panel upside down in the cart, the
viewing angle was atrocious).

------
dis-sys
"It is easier to port a shell than a shell script."

This is gold!

------
rob
I wish more VPS providers offered OpenBSD and FreeBSD. I remember using
FreeBSD a lot when I was 12-17 just messing around and setting up servers, etc
but eventually moved to Debian because VPS' at the time didn't really offer
these that much (reliably.)

~~~
tamentis
I've been running OpenBSD machines on Vultr for a little while, it's been
good.

------
otherflavors
now you should try openbsd or netbsd, as they are even less tolerant of linux-
isms

~~~
na85
Given that Linux is the de facto standard, wouldn't it be more correct to
describe the BSDisms as idiosyncrasies?

~~~
wahern
Which distro? Which libc? Which minimum kernel version? Which minimum version
of GNU Make? Which _specific_ version of GCC or clang?

Linux isn't a static environment. The closest thing to static is POSIX, and by
and large every Unix environment, including various Linux environments as well
as BSD environments, asymptotically approach POSIX compliance.

If you want to maintain a project long-term (5+ years), attempting to minimize
deviations from POSIX is a solid strategy in terms of avoiding bit rot and
long-term maintenance burdens. Sometimes it's unavoidable, but the point is to
weigh your options carefully and don't undervalue the benefit of POSIX
compliance. If you want to maximize the chance that your software will compile
and execute correctly on a Linux distro 5+ years from now, a good first step
is making sure it builds and runs natively on some of the BSDs.

There's a trend to discount the value of POSIX and to even actively break
POSIX compliance in a way that makes it very difficult to support both POSIX
semantics and some feature du jure. Developers should be wary of those who do
this because if such projects and their maintainers don't see any value in
POSIX they're not likely to see value in the long-term maintenance and
stability of whatever feature they're selling you on today.

Else thread somebody says that they see Linux as the new SunOS. I agree.[1]
But where is SunOS today?

[1] Except that Sun put much more emphasis on backwards compatibility. The
Linux _kernel_ _developers_ emphasize backward compatibility, but the distros
don't, and if the distros rip something out then inevitably it gets removed
from upstream. OTOH, while the kernel developers rightfully have said they
won't compromise sane design for POSIX, it turns out that such situations have
been _exceedingly_ rare and in general they take POSIX compliance seriously.

~~~
danieldk
_maintainers don 't see any value in POSIX _

The problem is that POSIX only provides a tiny subset of the API surface that
an application might need today. Just to give two random examples: how can an
application inhibit system sleep or use a webcam? The best one often can do is
rely on some widely-used library and hope that they (will continue to) support
multiple platforms.

 _But where is SunOS today?_

Comparing apples and oranges. For a large part of its lifetime, SunOS was a
proprietary UNIX that only worked with Sun hardware. If we include SunOS
5/Solaris, they open sourced Solaris way after Linux already had a stronghold
in the market.

Linux is now so dominant in mobile phones, servers, network devices, and IoT,
that even it will take much longer to disappear than SunOS.

~~~
a1369209993
The other problem is that POSIX is _horrible_. See eg:

\- [http://www.daemonology.net/blog/2011-12-17-POSIX-close-is-
br...](http://www.daemonology.net/blog/2011-12-17-POSIX-close-is-broken.html)
It's impossible to reliably _close a file_ if you have active signal handlers
that might be triggered.

\-
[https://www.sqlite.org/src/artifact/c230a7a24?ln=994-1081](https://www.sqlite.org/src/artifact/c230a7a24?ln=994-1081)
(discussed at
[https://news.ycombinator.com/item?id=17601581](https://news.ycombinator.com/item?id=17601581)
"POSIX advisory locks are broken by design.")

\- Seemingly anything to do with terminal devices or job control. (Allocating
ptys, sending control sequences like ^D or ^Z, adding processes to a group
that will all recieve terminal signals together, etc.)

\- 'Basic' regular expressions (as in `echo baaar | grep 'a+' || echo WTF`).

\- The existence of hard links as anything beyond a destination cache for
symlinks.

Most operating systems _have_ problems like these, but POSIX proceeds to
enshrine them as unfixable 'features' rather than "DEPRECATED: DO NOT USE".
(On the plus side, F_SETLK(W) and close seem likely to be fixed at some point
and close doesn't tend to get maliciously exploited the way eg integer
overflow does by C compilers.)

~~~
wahern
Every implementation of close, _except_ on HP/UX, will close the file
descriptor before returning upon a signal. But POSIX has actually approved
posix_close, which will guarantee the proper, desired semantics. See
[http://austingroupbugs.net/view.php?id=529](http://austingroupbugs.net/view.php?id=529)

The semantics of POSIX advisory locks were inherited; they codified the most
widely used existing implementation. The ergonomics suck, but they offer one
distinct advantage: you can query the PID of the lock holder, something not
possible when a lock can be inherited. This can be useful for PID file locks
where you can query the PID directly rather than trying to write and read it
from the PID file; there's no loaded gun lying around, although there's still
the TOCTTOU race between querying and kill'ing. In any event, "file-private"
advisory locks are likely to be standardized and are already implemented by
both Linux and FreeBSD. See
[http://austingroupbugs.net/view.php?id=768](http://austingroupbugs.net/view.php?id=768)
The semantics are not coincidentally very similar to BSD flock, and the types
similar to POSIX. Which is noteworthy because it's an example of how paying
attention to POSIX and portability issues can help you triangulate the
evolution of Linux interfaces down the road.

It's not like Linux is without its warts. The kernel's implementation of
setuid & friends is per thread. That's not only horribly inconvenient
semantics for 99% of use cases, it's a security nightmare. And glibc and musl
must implement an obscenely complex dance to get process-wide, atomic
behavior. There are also many legacy Linux interfaces that the project is
committed to supporting because of its commitment to backwards compatibility.
I don't understand the logic of pointing out all the anachronisms of POSIX
(e.g. advisory locks) while ignoring the anachronisms of Linux.

I never said POSIX was perfect, and I'm not arguing to _only_ stick to POSIX.
There's no substitute for using your own good judgment. I'm simply saying that
too many people don't appreciate the benefits of POSIX and portability more
generally, which are substantial. The benefits aren't just the standard itself
or the ability to use an alternative OS like FreeBSD--if you didn't care
before you're almost certainly never going to--but the fact that every Unix
vendor _tracks_ the standard and, to a lesser extent, avoids gratuitous
incompatibilities with other POSIX environments. Standardization signals
important information about the stability of an interface, and the process of
standardization channels the evolution of interfaces long before they become
standardized (if ever). POSIX and the BSDs matter to Linux development; and
they _should_ matter to Linux developers even if they'll never run code
outside of a Linux environment.

It's also worth mentioning that Red Hat basically steers POSIX, now, judging
by the Austin Group Bugs issue tracker. So while some teams are rather
antagonistic toward POSIX (e.g. Poettering and systemd team), others put
considerable effort into it.

------
jancsika
Is there a jquery equivalent for shell scripting?

~~~
lloeki
Quoting a quote from the article:

> Perl is portable shell

Which ironically I do use in this way but never formulated it in such a
compact and witty way.

I found Perl to be available basically by default on every platform I could
encounter, from AIX 3 to Windows (it comes along with Git for Windows, which
gives you bash too).

------
nopacience
FreeBSD is great! Even as a desktop. NVIDIA builds official drivers for
FreeBSD. I dont know whats the status for newer AMD graphics card. Nvidia +
Intel graphics also works very well.

There is a port system where users can build the packages from sourcecode on
their own machines. Its +- like gentoo.

There is also a binary pkg system. It is faster to install since the packages
are already built (binary).

To upgrade from minor versions ie. 11.1 to 11.2 it is very simple and well
documented. Just see in the manual freebsd-update

There is native support for ZFS also which is great.

Virtualbox works very well, so its possible to install other OSes in
virtualbox. VMware i dont think is supported.

------
agambrahma
> FreeBSD’s grep does not have a "-P" flag by default

(I continue to wonder what's stopping everyone from just ditching `grep`
altogether and switching to `ag`/`rg`)

~~~
xorcist
Why? They're not compatible and not a drop-in replacement.

They're also likely a little bit slower, especially on large datasets. It's
really hard to beat GNU grep. (Which is famously 3 cycles/byte in the trivial
case. Great exercise though.) But for the most part performance is secondary
to feature partity.

~~~
SSLy
FWIW rg is faster than gnu grep [https://github.com/BurntSushi/ripgrep#quick-
examples-compari...](https://github.com/BurntSushi/ripgrep#quick-examples-
comparing-tools)

~~~
xorcist
Right, by "very hard to beat" I didn't mean to imply it was somehow
impossible.

Looking at the whole benchmark that that page links to, the difference is
within a few percent for the actual searching, but it is also the only
software in the author's own benchmark that is even close. The other software
that was mentioned in the comment above is some 5x worse.

Nobody is going to change the standard grep for performance reasons.

~~~
burntsushi
ripgrep author here.

It really depends on what you're searching. In some types of searches, GNU
grep can get very very slow. The page you were linked to includes some
benchmarks for that. In particular, cases where you're searching large amounts
of non-ASCII (but UTF-8) text. There are some benchmarks for that case here:
[https://blog.burntsushi.net/ripgrep/](https://blog.burntsushi.net/ripgrep/)
specifically: [https://blog.burntsushi.net/ripgrep/#subtitles-no-
literal](https://blog.burntsushi.net/ripgrep/#subtitles-no-literal)

Also, it's probably not about "feature parity" per se, but standardization. In
terms of feature parity, there is very little that grep can do that, say,
ripgrep cannot. But there is quite a bit that ripgrep can do that grep cannot
do, mostly by design.

"replacing" grep with ripgrep has at least a dual meaning, and it is the
source of unending miscommunication. In the one sense, I know plenty of people
that have replaced grep with ripgrep (or whatever) in daily usage. This is a
perfectly valid thing to do. In another sense, nobody is going to replace grep
with ripgrep in a distribution because they almost certainly do not want to
stop being POSIX compatible. That is, asking to "just replace" grep with
ripgrep is equivalent to asking distributors to stop being POSIX compatible in
exchange for some other feature that ripgrep provides. That question is a non-
starter, but a lot of people either don't realize that or are confusing what
it means to "replace" something.

~~~
flurrything
Could ripgrep offer a POSIX compatible mode?

~~~
burntsushi
It "could" in the sense that it's of course technically possible. But it's a
_ton_ of work, and it's not clear to me that it would actually be beneficial.
GNU grep is doing just fine as far as I can tell at being a POSIX compatible
grep.

ripgrep is split into libraries, so if someone wanted this, they could just go
do it themselves. :-) It would actually be pretty easy to get something that
_smells_ like POSIX. But the details make up a very long tail, and some of
those tasks are fairly significant (supporting BRE syntax, supporting POSIX-
style alternations, supporting POSIX locales).

------
DonHopkins
>Perl is portable shell — Guy Keren

Which still has many of the terrible problems of the shell, because its
original design was an imitation of several different shell scripting
languages.

If all you know is Perl and you're incapable of learning any other languages,
or for some perverse reason you like the way Perl scripts look just as
incomprehensible as shell scripts, and you're absolutely sure nobody else will
ever need to look at or maintain your code, then by all means use Perl. But if
you don't hate the people who will have to clean up after you or decipher and
maintain what you're done, then please use Python or JavaScript instead of
Perl or shell scripts.

~~~
ivanhoe
> and you're absolutely sure nobody else will ever need to look at or maintain
> your code

By "nobody else" you really mean "other people with the same mindset who
aren't willing to invest some time in getting used to perl syntax". Thing is
that modern javascript is just as incomprehensible to sysops/devops people
who're not familiar with the new JS syntax. You come from one world and think
that's the "normal", they come from the other and expect that everyone already
knows perl as it is half bash, half C. And in the end it's really much more
about how much time did you spend working in it, than in one language being so
much clearer than the other.

~~~
DonHopkins
Too many people have for too long treated Perl as way to blackmail their
employers into not firing them, by developing an unmaintainable code base that
nobody else can understand. Do you really want to be "that guy", or clean up
after them yourself? (I say "that guy" because the Perl community is
historically hostile to women, with the "hooters girls" at trade show booths,
etc.)

[http://geekfeminism.wikia.com/wiki/Randal_Schwartz](http://geekfeminism.wikia.com/wiki/Randal_Schwartz)

"He's the Hooter's guy, right?"

[https://web.archive.org/web/20080328132126/https://www.oblom...](https://web.archive.org/web/20080328132126/https://www.oblomovka.com/entries/2004/07/28)

[http://blogs.perl.org/users/joe_mcmahon1/2012/08/why-im-
cons...](http://blogs.perl.org/users/joe_mcmahon1/2012/08/why-im-considering-
dropping-perlmonks.html)

And have you ever tried to hire a competent experienced Perl programmer?
They're extremely hard to find, and very expensive, and usually would rather
be working with some other language. Sure, incompetent ones are a dime a
dozen, but hiring those and setting them loose just starts the vicious cycle
again.

All of the competent Perl programmers have long since been hired up by
companies desperately trying to find people qualified to work on their old
toxic legacy code bases that they're stuck with. Like Booking.com for example.

And writing new code in Perl is insane. There's absolutely nothing special
about Perl 5 or Perl 6 that solves any problems you can't easily solve in most
other languages.

Perl's much larger problems totally overwhelm the minor conveniences from its
"syntactic syrup of ipecac" that perversely appeals those few people who think
saving a few keystrokes at the expense of readability, instead of spelling
words out with letters instead of line-noise punctuation and acronyms, is the
sole goal of software development.

Perl 6 is a joke, a slow moving parody of itself that missed the boat decades
ago, and it's absolutely never going to catch up with JavaScript or Python.

If you really want to optimize your career for programming toxic legacy code
that's too ugly for anyone else to touch, you should have learned COBOL before
the Y2K "crisis". But in the long term, you might have regretted it:

[https://medium.com/@donhopkins/cobol-
forever-1a49f7d28a39](https://medium.com/@donhopkins/cobol-
forever-1a49f7d28a39)

~~~
hpcjoe
Wow. Just wow. FUD. Pure and simple.

Perl is doing well, thank you. Perl6 is interesting, but I don't have a
project for it yet. There are jobs in perl, there are needs, and we (perl
devs) aren't appreciably more expensive than non-perl devs, though some of us
may be better at negotiation than the dime-a-dozen developers in more "common"
languages.

There is just so much that is wrong with the post above. Its actually sad.

