Hi,
yesterday I read the Flight Aware and FreeBSD article of the FreeBSD Journal.
They seem to like it a lot, but they seem to have pain points that come up a lot. I think some of them might be solved in CURRENT or so already, but I wonder about the state of this issues, cause I want to understand how much of work it would be to fix those issues and what the reason for some of those really is.
The article is great and it's worthwhile to get the edition (it's only 6.99$), but to make it short and to not infringe any copyrights I'll sum up the issues that are described in multiple paragraphs in short points. Also forgive me if they sound harsher for that reason. In the article they actually tend to mention weak (my opinion) reasons for some of those.
Please don't judge FlightAware based on my writings here, because I really shortly summed things up in my own words, as I understood it. Also I left out all the great things about FreeBSD. If you wanna make your own picture just get the FreeBSD Journal (issue or subscription).
I think a lot of those are actually being worked on. However, what I personally I am most curious about is the parts about defaults, including DTRACE support, network tuning (I know there is developments here) and stuff that is kind of configured for really small systems, that might not even really be supported by the rest of the OS.
Hope that all doesn't sound like "not wanting to use FreeBSD", since pretty all of those in my personal opinion are changes of defaults and I just don't know what the reason is to have them like they are. I know some of those are about being a bit conservative, which is good, but it seems that some values could be changed and it would still be conservative. What I mean is that if one increases the log files to a couple of megabytes it wouldn't result in setups the majority of installations on smaller systems to run into any issues. This is probably even more true for some of the sysctl tuning (even though I think work has been done here).
About the installer I wonder whether that's developer time lacking for those. I think I should look into the installer, but I am sure there are parts of the FreeBSD community that already have some automatic deployment solution that could be made more generic and then find it's way into the project, meaning they have less to deal with and support by the community. It's not like that's the "big advantage" kind of software.
Side note: I think it would be really great if this could become an "open article", cause it's well written and pretty much a case study. Seeing what other users of FreeBSD do and what they have troubles with is really good for the community, because people might work together on making the system even better.
yesterday I read the Flight Aware and FreeBSD article of the FreeBSD Journal.
They seem to like it a lot, but they seem to have pain points that come up a lot. I think some of them might be solved in CURRENT or so already, but I wonder about the state of this issues, cause I want to understand how much of work it would be to fix those issues and what the reason for some of those really is.
The article is great and it's worthwhile to get the edition (it's only 6.99$), but to make it short and to not infringe any copyrights I'll sum up the issues that are described in multiple paragraphs in short points. Also forgive me if they sound harsher for that reason. In the article they actually tend to mention weak (my opinion) reasons for some of those.
- No headless installer
They actually created their own installer to get around some of that, but of course it's very specific to the project. And I agree something official(!) way to deploy large scale FreeBSD setups would b nice. I know that people make their own systems and that allows more customization, but making it scriptable and having that config shared over the network would be really nice. They mention RedHat's Kickstart and the Debian preconfiguration file. - Unifying Containers [aka Jails]
There are currently many ways to deal with containers (cbsd, ezjail, jail.conf, iocage). Since FreeBSD is more like a complete system it would be great to have something along those lines in base, that also allows larger scale management out of the box. Personally I think jailctl or an extended jail utility (but honestly I think that is already big).
- VIMAGE in GENERIC
I think that that's mostly them being excited for it to finally be considered stable enough to be in there, since they are excited about RCTL.
- Official 64bit Oracle Java
They said that they had issues with OpenJDK. That's actually the only point that I feel I couldn't relate to, because OpenJDK has been fine with me. But they say it's good to have the "authoritative environment" in production and that they saw corruption on their Kafka instance. This actually made them use Linux for this application.
- Default Configuration
I think everyone runs into that. FreeBSD, while sometimes used on smaller devices (esp. routers) seems to have its biggest user basis on big servers and desktops. Specifically they mention -DFD_SETSIZE=4096 (currently 1024) for Tcl, in newsyslog config, to use more than 100KB per file, because even on rather small systems, like SD cards 100KB isn't much. And lastly generic network stack tuning. I guess most people with production machines run into these. - Overall Debugging Experience
Next to the 100KB for log files a problem is that many things (base system and packages) come without debug symbols per default and when you enable them this often disables many optimizations, which makes it rather hard to have a debugable production environment. Binaries should not be stripped. Also everything should come with DTRACE per default.
Please don't judge FlightAware based on my writings here, because I really shortly summed things up in my own words, as I understood it. Also I left out all the great things about FreeBSD. If you wanna make your own picture just get the FreeBSD Journal (issue or subscription).
I think a lot of those are actually being worked on. However, what I personally I am most curious about is the parts about defaults, including DTRACE support, network tuning (I know there is developments here) and stuff that is kind of configured for really small systems, that might not even really be supported by the rest of the OS.
Hope that all doesn't sound like "not wanting to use FreeBSD", since pretty all of those in my personal opinion are changes of defaults and I just don't know what the reason is to have them like they are. I know some of those are about being a bit conservative, which is good, but it seems that some values could be changed and it would still be conservative. What I mean is that if one increases the log files to a couple of megabytes it wouldn't result in setups the majority of installations on smaller systems to run into any issues. This is probably even more true for some of the sysctl tuning (even though I think work has been done here).
About the installer I wonder whether that's developer time lacking for those. I think I should look into the installer, but I am sure there are parts of the FreeBSD community that already have some automatic deployment solution that could be made more generic and then find it's way into the project, meaning they have less to deal with and support by the community. It's not like that's the "big advantage" kind of software.
Side note: I think it would be really great if this could become an "open article", cause it's well written and pretty much a case study. Seeing what other users of FreeBSD do and what they have troubles with is really good for the community, because people might work together on making the system even better.