What I Learned from porting my projects to FreeBSD

It annoys me quite a bit when someone decides not to use autotools or meson, or other standard build tools. I have a build system set up to build static packages for several architectures, and most of my packages are described like this:

    name=some
    ver=123
    url=https://where-to-get/some-$ver.tar.gz
    build() {
      autotools_build --some-option
    }

If you roll out your own Makefile, I have to figure out how to build the targets, how to install them, whether you use DESTDIR, whether you respect cross-compile options, how to build static library, how to configure your package... and code all this by hand to build() function.

The same goes for my custom Arch Linux packages.

Make the packagers job easy and just don't roll your own if you want your package to be distributed widely.

It's probably a bad idea. But HIPPA is a specific and public block of text, which says less than most people seem to imagine it does. (I'm no lawyer. I've just read the thing).

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)?

okay, please provide a makefile which:

* detects if, say, libpng is available

* compile a library, an executable and a unit test if that's the case

* links the executable to the library and the library to libpng

* does so for mac, windows, linux, creates a .app for mac, an installer for windows, a .deb package for linux

* can be used from IDEs, with IDEs understanding where your code has to be fetched, what the includes are, etc

here's more-or-less the CMake version :

   project(myapp)

   find_package(PNG REQUIRED)

   add_library(mylib lib.c)
   add_executable(myapp MACOS_BUNDLE WIN32 app.c)
   target_link_libraries(mylib PRIVATE PNG::PNG)
   target_link_libraries(myapp PRIVATE mylib)

   install(
      TARGETS myapp mylib 
      RUNTIME DESTINATION bin 
      ARCHIVE DESTINATION lib)
   include(CPack)

[0] http://gittup.org/tup/make_vs_tup.html <edit substitutes the make comparison link instead of the main page>

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.

macOS has a marketshare in server market segment of around 0% (client of around 5%, iOS substantial though), and Linux is the defacto standard in that area. Which OS do people learn nowadays? Linux distributions. So it makes sense to see it from that PoV. Because chances are that you're going to use that defacto standard. And even if you prefer UNIX(tm) or BSD or Solaris you'd rather use Linux than Windows or OpenVMS. Cause the latter are aliens from outer space.

PCs were these toys for people who had no acces to real computers, until they were the standard. Microsoft provided toy OSes until they wiped out almost anybody else. Java, MySql and subversion are other examples.

I've read somewhere that every succesfull product has a phase where the world laughs at it. If that hadn't happened, it would have been smothered in the cradle by the behemots of its time. Being laughed at gave it time to grow.

Has created some incredible UI paradigms and elements, but...

- http://www.daemonology.net/blog/2011-12-17-POSIX-close-is-br... 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 (discussed at 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.)

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/ specifically: 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.