|
> I'm curious if you could talk about any of the consequences at all. One major consequence is that your software and setup scripts are likely to continue to work over many major releases. Basic system tools don't often get replaced, so you don't need to worry about migrating to a new tool to configure interfaces, or a new firewall (although you do have three firewalls to choose from, they all have been there for a long time) or a drastically new init system etc. Otoh, there are many projects that are made for Linux only. Sometimes intentionally, sometimes unintentionally. Lots of assumptions creep in, people write Makefiles that need GNU make, and call make recursively with 'make' instead of $(MAKE), but FreeBSD has BSD make as make, and GNU make, if you install it, as gmake. FreeBSD sets up cc to be llvm's clang, and I don't think that's common in Linux. Many projects compile with either, but some don't. Specialized linking is tricky. Compiler and linker changes are probably an exception to my rule earlier about not replacing tools, but there's a case to be made that clang is at least as good as gcc, and the license is a better fit; there's no requirement that the base be all BSD licensed, but it's nice to move in that direction where possible. System monitoring is different, but capabilities are roughly similar. FreeBSD has some nice things, and Linux has some nice things, I've got my preferences, but whatever. I don't think it's hard to take a reasonable systems aware person and sit them down with a FreeBSD book and a FreeBSD system and get acceptable results. Yes, mastery takes time, but consultancies are available if you need mastery right now, and don't have time to develop it in house. |