7 ms·

As a web developer who knows enough Linux to do minimum dev-ops, could anyone recommend some things worth playing around with in FreeBSD? Like "do this and see

by xhrpost 12y ago

As a web developer who knows enough Linux to do minimum dev-ops, could anyone recommend some things worth playing around with in FreeBSD? Like "do this and see how easy it is vs Ubuntu!". Or are the gains more long term like better stability?

joshbaptiste 12y ago
Dtrace alone will turn you from a developer to a Developer + Systems admin + practical OS engineer, you will understand how your stack is performing within various lower levels of the operating system and be able to tune the hell out of your stack from bottom up.
- Thaxll 12y ago
  Come on, 0.1% of the people need Dtrace...
  - 4ad 12y ago
    If you do any kind of programming or system administration, you need DTrace (or some lame Linux equivalent). It really pains me to see that people reject it because it's "too advanced" for them, or such nonsense. Dynamic tracing is the one technique that will enrich your life as an IT professional more than absolutely anything else ever did. And DTrace in particular is really, really easy to use (the Linux alternatives, not so much).
    - atmosx 12y ago
      Yeah that said, Dtrace on FreeBSD sucks. The DSL is hard and many ready-to-run scripts don't run at all. Other than Dtrace... Tools like dtruss & co are not as clean as strace, that's the feeling I've got when I had to trace some calls.
  - juliangoldsmith 12y ago
    But that doesn't mean it's only useful to 0.1% of people.
  - duggan 12y ago
    If it's more widely available, more developers will reach for it. The more comfortable people are with tools like DTrace, the better they will be able to write and use software.
  - sneak 12y ago
    Everyone needs to know all of the things. Just because it's a pain to get now doesn't mean people wouldn't use it if it were there. Remember when monitor mode meant patching drivers and running a weirdo kernel? It's like that.
    - Thaxll 12y ago
      Two things here: - If you use Dtrace to troubleshoot a problem it's way beyond your scope of knowledge as a web developer. Dtrace is too deep and very specific to certain problems that you will never see because your regular nginx + php works fine in all cases. - Not everyone wants and should be good at everything. Just be good at what your doing well, I'm not saying that one shouldn't be curious but Dtrace isn't "an excuse" to install *BSD as a web dev.
      - 4ad 12y ago
        If you don't use DTrace to debug php, you're missing a lot: http://php.net/manual/en/features.dtrace.dtrace.php http://php.net/manual/en/features.dtrace.dtrace.php. Same for python and ruby and node.js. All these have DTrace support. DTrace is not hard, it's essential; and it's significantly easier, than say, awk, which is another crucial tool.
        bitroliest 12y ago
        Under OSX it seems that DTrace support is incomplete thanks to OSX' dtrace implementation [1]. [1] https://github.com/joyent/node/issues/3617 https://github.com/joyent/node/issues/3617 I think only Solaris has full support?
  - bsg75 12y ago
    Its interesting to some of us: http://www.postgresql.org/docs/9.4/static/dynamic-trace.html http://www.postgresql.org/docs/9.4/static/dynamic-trace.html
  - woodman 12y ago
    0.1% of people in the world? That seems a little high. 0.1% of people who describe themselves as *-dev? That seems really low. Also, how do you define "need"? Dtrace isn't just for tracing functions down to the kernel level, and I can imagine all sorts of things that a web dev would find useful in dtrace. Just google "ruby dtrace".
woodman 12y ago
I switched from CentOS to FreeBSD as my daily driver a little over a year ago, for the ports tree. I needed a bleeding edge version of valgrind, but my ~/bin and ~/lib were already pretty unwieldy - so that is what caused the switch. That and ZFS. But I've found a couple of other things that I really like: the documentation is awesome, and config files are where you'd expect them to be. Being able to tune system internals online with sysctl is really awesome as well. Wanna change the lowest possible C-state one cpu3? sysctl hw.acpi.cpu.3.cx_lowest=C3. I dunno how useful that is for web devs, but as a C programmer and perpetual tinkerer - FreeBSD suits my needs very nicely.
- icebraining 12y ago
  Linux has sysctl as well, and other parameters can be set by writing to the right files in /sys. For example, the maximum c-state can be set by writing to /sys/module/processor/parameters/max_cstate (if you have support enabled in the kernel).
  - woodman 12y ago
    The linux sysctl is a wrapper for kernel state represented in the file system, freebsd sysctl is direct to kernel. So that is nice, everything in one place. Before my switch to freebsd, I had been a linux user since 2000 - and while I was aware of the existence of sysctl, I don't remember seeing it used very often. It was much more common to see direct interaction with stuff in /proc (rockectraid, never again). Why is that? Is it an issue with standardizing driver interaction or what? My prior post wasn't written as a statement of exclusivity, simply that I prefer the way freebsd does it.
    - caf 12y ago
      The /proc/sys/ and sysctl(2) methods are really just down to which syscall is used to talk to the kernel - either way it's just reading or writing a kernel-side data structure, there's no fundamental difference there. The /proc/sys/ pseudo-filesystem interface has the advantage that it's discoverable. The sysctl(2) interface requires userspace to have knowledge of a swag of hardcoded ID numbers identifying each node in the sysctl tree.
gtrubetskoy 12y ago
When bored, you can run `make world` (it recompiles the kernel and every binary on the system).
namidark 12y ago
Jails are awesome
romaniv 12y ago
IMO, just having something of the quality of FreeBSD's handbook (https://www.freebsd.org/doc/handbook/ https://www.freebsd.org/doc/handbook/) is a significant point to consider. It is the best piece of documentation for a system I have ever read.
josegonzalez 12y ago
You probably mean "knows enough Linux to do minimum ops".
xenophonf 12y ago
My reasons for using FreeBSD are a little more philosophical: - I want to have a stable base O/S to which I can always easily return. - I want to be able to customize installed packages in an easily scalable way. - I want a server O/S to be simple to maintain, relative to Windows or Solaris. - I want the goddamned documentation installed. During development it's difficult to get RHEL or Ubuntu back to a known-good set of base packages without fiddling a lot with the package manager. It's better nowadays with package groups and autoremoval supported in both yum and APT, but with FreeBSD, you can always punt, do "pkg delete -a && rm -rf /usr/local" (or "pkg_delete" in the before time), and start over. The base configuration is also pretty simple and centralized, with most of what you need in /etc/rc.conf or /etc/periodic.conf. pkgng + poudriere + a suitable web server makes custom package management really, really easy. I haven't tackled Spacewalk or similar tools for Linux, but even building locally customized versions of packages on RHEL or Ubuntu is a moderately complicated process compared to the FreeBSD Ports Tree. On RHEL or Ubuntu, you typically have to install the developer tools, hunt down the source RPMs/DEBs, edit the package definition, run rpmbuild/debuild, and install the resulting RPM. Compare that to the FreeBSD Ports Tree, where you run one command to download/update your copy of the package definitions, add whatever package-specific knobs you need to /etc/make.conf, and run "cd /usr/ports/category/packagename && make install" (the compilers and everything come built into the base system). I'm not going to start an argument about the relative merits of init systems, as systemd (Linux), SMF (Solaris), and SCM (Windows) all have their merits, but I personally like the simplicity of configuring everything through /etc/rc.conf on FreeBSD. It's definitely old school, but then I cut my teeth on NeXTSTEP, SunOS 4, and Slackware Linux, so rc-style init scripts feel pretty natural to me. As for documentation, I cannot tell you how many times I've wanted to run "man something" only to find out I need to install the -doc package. (Also, I cannot tell you how many times I've wanted to compile something, only to find out I need to install the -dev package.) Compared to Linux, FreeBSD has superior documentation. Even kernel bits get manual pages, and not just syscalls in section 2, but kernel interfaces and modules in section 4. Of course I use both FreeBSD and Linux to great effect at home and at work, as well as Windows and Solaris. I just _like_ FreeBSD better.
- Florin_Andrei 12y ago
  > I cut my teeth on NeXTSTEP, SunOS 4, and Slackware Linux That's the real reason. Everything else is rationalization added later. (Don't get me wrong, I've also started on Slackware. But sometimes you need to break old habits to learn something new.)
bsg75 12y ago
I asked a related question from the database developer perspective just yesterday: https://news.ycombinator.com/item?id=8884125 https://news.ycombinator.com/item?id=8884125
atmosx 12y ago
Yes. From my experience: * PF (default on OpenBSD, a fork exists on FreeBSD) configuration is way more human-readable than iptables. Makes a lot easier to create custom complex rulesets. * Documentation is much cleaner on FreeBSD (or OpenBSD) compared to GNU/Linux. Again helps you deploy complex solutions easily. * The upgrade process (using ports or pkg) is well documented, easy to execute[1]. * ZFS makes FreeBSD a very solid file server So, other than specific software, a clean approach on how start/stop services, where goes what, etc. I don't see any other reason for someone to switch from Linux to BSD. However, given my experience ruby (I'm a ruby programmer) under-performs on FreeBSD VPSs compared to Linux VPSs while on bare metal doesn't. There are reports citing NetBSD as fastest ruby bare-metal OS. But again, differences shouldn't be all that much between BSD and Linux deployments in bare metal to justify a switch on VPSs though, if deploy ruby apps, I'd say stick with Linux. [1] Hm. It's easy to execute if you are not afraid to read some extra documentation. But once you get the hand of it, it's really a breeze, never had serious issues with FreeBSD in ~3 years.
- oscargrouch 12y ago
  + Dtrace + Jails + Capsicum [1] + Netmap [2] + Most performing network stack + Resource Management (pretty low memory usage) + The userspace tools come with the source (no GNU/Linux duality) + Clang/LLVM as default compiler stack [1] - https://www.freebsd.org/cgi/man.cgi?query=capsicum&sektion=4 https://www.freebsd.org/cgi/man.cgi?query=capsicum&sektion=4 [2] - https://www.freebsd.org/cgi/man.cgi?query=netmap&sektion=4 https://www.freebsd.org/cgi/man.cgi?query=netmap&sektion=4
  - thiagowfx 12y ago
    I never understood the main differences between jails and chroots. Would you be willing to explain?
    - rhizome 12y ago
      Chroots only lock you to a particular part of the filesystem. Jails add process and network resource restrictions.
vbit 12y ago
As a developer you might find jails useful. I use them to create multiple isolated 'virtual machines' on the same machine. In each one I can install a different set of packages and I like the my base system in clean. With zfs, I also snapshot each jail before major changes so rollback is easy. Try this and see how easy, well-integrated it is as opposed to something similar on linux. I use ezjail, btw.

by xhrpost 12y ago

joshbaptiste 12y ago

Dtrace alone will turn you from a developer to a Developer + Systems admin + practical OS engineer, you will understand how your stack is performing within various lower levels of the operating system and be able to tune the hell out of your stack from bottom up.

Thaxll 12y ago
Come on, 0.1% of the people need Dtrace...
- 4ad 12y ago
  If you do any kind of programming or system administration, you need DTrace (or some lame Linux equivalent). It really pains me to see that people reject it because it's "too advanced" for them, or such nonsense. Dynamic tracing is the one technique that will enrich your life as an IT professional more than absolutely anything else ever did. And DTrace in particular is really, really easy to use (the Linux alternatives, not so much).
  - atmosx 12y ago
    Yeah that said, Dtrace on FreeBSD sucks. The DSL is hard and many ready-to-run scripts don't run at all. Other than Dtrace... Tools like dtruss & co are not as clean as strace, that's the feeling I've got when I had to trace some calls.
- juliangoldsmith 12y ago
  But that doesn't mean it's only useful to 0.1% of people.
- duggan 12y ago
  If it's more widely available, more developers will reach for it. The more comfortable people are with tools like DTrace, the better they will be able to write and use software.
- sneak 12y ago
  Everyone needs to know all of the things. Just because it's a pain to get now doesn't mean people wouldn't use it if it were there. Remember when monitor mode meant patching drivers and running a weirdo kernel? It's like that.
  - Thaxll 12y ago
    Two things here: - If you use Dtrace to troubleshoot a problem it's way beyond your scope of knowledge as a web developer. Dtrace is too deep and very specific to certain problems that you will never see because your regular nginx + php works fine in all cases. - Not everyone wants and should be good at everything. Just be good at what your doing well, I'm not saying that one shouldn't be curious but Dtrace isn't "an excuse" to install *BSD as a web dev.
    - 4ad 12y ago
      If you don't use DTrace to debug php, you're missing a lot: http://php.net/manual/en/features.dtrace.dtrace.php http://php.net/manual/en/features.dtrace.dtrace.php. Same for python and ruby and node.js. All these have DTrace support. DTrace is not hard, it's essential; and it's significantly easier, than say, awk, which is another crucial tool.
      - bitroliest 12y ago
        Under OSX it seems that DTrace support is incomplete thanks to OSX' dtrace implementation [1]. [1] https://github.com/joyent/node/issues/3617 https://github.com/joyent/node/issues/3617 I think only Solaris has full support?
- bsg75 12y ago
  Its interesting to some of us: http://www.postgresql.org/docs/9.4/static/dynamic-trace.html http://www.postgresql.org/docs/9.4/static/dynamic-trace.html
- woodman 12y ago
  0.1% of people in the world? That seems a little high. 0.1% of people who describe themselves as *-dev? That seems really low. Also, how do you define "need"? Dtrace isn't just for tracing functions down to the kernel level, and I can imagine all sorts of things that a web dev would find useful in dtrace. Just google "ruby dtrace".

woodman 12y ago

I switched from CentOS to FreeBSD as my daily driver a little over a year ago, for the ports tree. I needed a bleeding edge version of valgrind, but my ~/bin and ~/lib were already pretty unwieldy - so that is what caused the switch. That and ZFS. But I've found a couple of other things that I really like: the documentation is awesome, and config files are where you'd expect them to be. Being able to tune system internals online with sysctl is really awesome as well. Wanna change the lowest possible C-state one cpu3? sysctl hw.acpi.cpu.3.cx_lowest=C3. I dunno how useful that is for web devs, but as a C programmer and perpetual tinkerer - FreeBSD suits my needs very nicely.

icebraining 12y ago
Linux has sysctl as well, and other parameters can be set by writing to the right files in /sys. For example, the maximum c-state can be set by writing to /sys/module/processor/parameters/max_cstate (if you have support enabled in the kernel).
- woodman 12y ago
  The linux sysctl is a wrapper for kernel state represented in the file system, freebsd sysctl is direct to kernel. So that is nice, everything in one place. Before my switch to freebsd, I had been a linux user since 2000 - and while I was aware of the existence of sysctl, I don't remember seeing it used very often. It was much more common to see direct interaction with stuff in /proc (rockectraid, never again). Why is that? Is it an issue with standardizing driver interaction or what? My prior post wasn't written as a statement of exclusivity, simply that I prefer the way freebsd does it.
  - caf 12y ago
    The /proc/sys/ and sysctl(2) methods are really just down to which syscall is used to talk to the kernel - either way it's just reading or writing a kernel-side data structure, there's no fundamental difference there. The /proc/sys/ pseudo-filesystem interface has the advantage that it's discoverable. The sysctl(2) interface requires userspace to have knowledge of a swag of hardcoded ID numbers identifying each node in the sysctl tree.

gtrubetskoy 12y ago

When bored, you can run `make world` (it recompiles the kernel and every binary on the system).

namidark 12y ago

Jails are awesome

romaniv 12y ago

IMO, just having something of the quality of FreeBSD's handbook (https://www.freebsd.org/doc/handbook/ https://www.freebsd.org/doc/handbook/) is a significant point to consider. It is the best piece of documentation for a system I have ever read.

josegonzalez 12y ago

You probably mean "knows enough Linux to do minimum ops".

xenophonf 12y ago

My reasons for using FreeBSD are a little more philosophical: - I want to have a stable base O/S to which I can always easily return. - I want to be able to customize installed packages in an easily scalable way. - I want a server O/S to be simple to maintain, relative to Windows or Solaris. - I want the goddamned documentation installed. During development it's difficult to get RHEL or Ubuntu back to a known-good set of base packages without fiddling a lot with the package manager. It's better nowadays with package groups and autoremoval supported in both yum and APT, but with FreeBSD, you can always punt, do "pkg delete -a && rm -rf /usr/local" (or "pkg_delete" in the before time), and start over. The base configuration is also pretty simple and centralized, with most of what you need in /etc/rc.conf or /etc/periodic.conf. pkgng + poudriere + a suitable web server makes custom package management really, really easy. I haven't tackled Spacewalk or similar tools for Linux, but even building locally customized versions of packages on RHEL or Ubuntu is a moderately complicated process compared to the FreeBSD Ports Tree. On RHEL or Ubuntu, you typically have to install the developer tools, hunt down the source RPMs/DEBs, edit the package definition, run rpmbuild/debuild, and install the resulting RPM. Compare that to the FreeBSD Ports Tree, where you run one command to download/update your copy of the package definitions, add whatever package-specific knobs you need to /etc/make.conf, and run "cd /usr/ports/category/packagename && make install" (the compilers and everything come built into the base system). I'm not going to start an argument about the relative merits of init systems, as systemd (Linux), SMF (Solaris), and SCM (Windows) all have their merits, but I personally like the simplicity of configuring everything through /etc/rc.conf on FreeBSD. It's definitely old school, but then I cut my teeth on NeXTSTEP, SunOS 4, and Slackware Linux, so rc-style init scripts feel pretty natural to me. As for documentation, I cannot tell you how many times I've wanted to run "man something" only to find out I need to install the -doc package. (Also, I cannot tell you how many times I've wanted to compile something, only to find out I need to install the -dev package.) Compared to Linux, FreeBSD has superior documentation. Even kernel bits get manual pages, and not just syscalls in section 2, but kernel interfaces and modules in section 4. Of course I use both FreeBSD and Linux to great effect at home and at work, as well as Windows and Solaris. I just _like_ FreeBSD better.

Florin_Andrei 12y ago
> I cut my teeth on NeXTSTEP, SunOS 4, and Slackware Linux That's the real reason. Everything else is rationalization added later. (Don't get me wrong, I've also started on Slackware. But sometimes you need to break old habits to learn something new.)

bsg75 12y ago

I asked a related question from the database developer perspective just yesterday: https://news.ycombinator.com/item?id=8884125 https://news.ycombinator.com/item?id=8884125

atmosx 12y ago

Yes. From my experience: * PF (default on OpenBSD, a fork exists on FreeBSD) configuration is way more human-readable than iptables. Makes a lot easier to create custom complex rulesets. * Documentation is much cleaner on FreeBSD (or OpenBSD) compared to GNU/Linux. Again helps you deploy complex solutions easily. * The upgrade process (using ports or pkg) is well documented, easy to execute[1]. * ZFS makes FreeBSD a very solid file server So, other than specific software, a clean approach on how start/stop services, where goes what, etc. I don't see any other reason for someone to switch from Linux to BSD. However, given my experience ruby (I'm a ruby programmer) under-performs on FreeBSD VPSs compared to Linux VPSs while on bare metal doesn't. There are reports citing NetBSD as fastest ruby bare-metal OS. But again, differences shouldn't be all that much between BSD and Linux deployments in bare metal to justify a switch on VPSs though, if deploy ruby apps, I'd say stick with Linux. [1] Hm. It's easy to execute if you are not afraid to read some extra documentation. But once you get the hand of it, it's really a breeze, never had serious issues with FreeBSD in ~3 years.

oscargrouch 12y ago
+ Dtrace + Jails + Capsicum [1] + Netmap [2] + Most performing network stack + Resource Management (pretty low memory usage) + The userspace tools come with the source (no GNU/Linux duality) + Clang/LLVM as default compiler stack [1] - https://www.freebsd.org/cgi/man.cgi?query=capsicum&sektion=4 https://www.freebsd.org/cgi/man.cgi?query=capsicum&sektion=4 [2] - https://www.freebsd.org/cgi/man.cgi?query=netmap&sektion=4 https://www.freebsd.org/cgi/man.cgi?query=netmap&sektion=4
- thiagowfx 12y ago
  I never understood the main differences between jails and chroots. Would you be willing to explain?
  - rhizome 12y ago
    Chroots only lock you to a particular part of the filesystem. Jails add process and network resource restrictions.

vbit 12y ago

As a developer you might find jails useful. I use them to create multiple isolated 'virtual machines' on the same machine. In each one I can install a different set of packages and I like the my base system in clean. With zfs, I also snapshot each jail before major changes so rollback is easy. Try this and see how easy, well-integrated it is as opposed to something similar on linux. I use ezjail, btw.