Live data from Hacker News

Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

crocidb.com

231–240 of 241 posts

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#231
post #227

Earlier quoted context omitted.

How would you implement no-downtime hot swap with only one item?

By implementing hot-swap into the one item? Am I missing something in this question?

Executing hardware hot-swap typically means telling the system that a component is going down. Then the system moves those resources to the other component to gracefully allow you to remove it without a restart.

Like it's not a case where you just yank out a CPU as you like as though it were a spindle in a RAID-6 array. Especially if there's only one CPU. The state machine can't maintain state if the only component that tracks and maintains state goes missing.

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#232

Earlier quoted context omitted.

You patch it in memory and on disk. What you put on disk is the patch though, so when you restart, the original unpatched version is booted, and then the same live patch is applied. This is how Ksplice worked. It has the advantage that there isn't a config file in /etc to get changed out from under it, so the second problem did not apply.

Ksplice can do that because the kernel is only in memory in one place an it never sleeps. It has to orchestrate a process that's always running, which is complex, but it's never more than one. Now try patching glibc like that. Not only does almost every thread have it in memory, several of them will have it in process, and some of them will have it swapped to disk while the thread sleeps. You're going to quickly deci…

The corporate named "Ksplice for userspace" did exactly that, patch glibc.

https://blogs.oracle.com/linux/new-userspace-patching-with-o...

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#233
post #227

Earlier quoted context omitted.

By implementing hot-swap into the one item? Am I missing something in this question?

Executing hardware hot-swap typically means telling the system that a component is going down. Then the system moves those resources to the other component to gracefully allow you to remove it without a restart. Like it's not a case where you just yank out a CPU as you like as though it were a spindle in a RAID-6 array. Especially if there's only one CPU. The state machine can't maintain state if the only component t…

[dead]

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#234

I enjoyed my foray into trying FreeBSD for my personal server. There's something cool, clean, simple and "punk rock" about it. But I gave up as my main pain points were: - PM2 was buggy on FreeBSD, which I used to manage my processes - An alternative, using `rc.d` to run daemons was just so hard to get logs working. - The firewall required too much self configuration to get it right with all the best security practic…

> An alternative, using `rc.d` to run daemons was just so hard to get logs working.

I actually just did this for a web application on FreeBSD 15. It wasn't too bad, but I used `daemon` to send stdout & stderr into syslog and then I just added a syslog config to send that to it's own file. Roughly, I did this:

    # /usr/local/etc/rc.d/app:

    # PROVIDE: app
    # KEYWORD: shutdown
    
    . /etc/rc.subr
    
    name="app"
    rcvar="app_enable"
    
    load_rc_config $name
    
    : ${app_enable:="NO"}
    : ${app_user:="www"}
    : ${app_database_url:=""}
    
    app_command="/usr/local/bin/app"
    
    cpidfile="/var/run/${name}/${name}.pid"
    pidfile="/var/run/${name}/${name}d.pid"
    logfile="/var/log/${name}.log"
    command=/usr/sbin/daemon
    command_args="-P ${pidfile} -p ${cpidfile} -S -t ${name}-super -T ${name} ${app_command} start"
    
    start_precmd="${name}_prestart"

    app_prestart()
    {
        # ... Set environment variables here with EXPORT, using values from rc.conf
        export DATABASE_URL=${app_database_url}

        # This is also a good place to use install(1) to create 
        #   config files and log directories if they don't exist
    }

    run_rc_command "$1"

Note that -S to `daemon` instructs it to use syslog, and the -T sets the syslog tag which controls how messages are routed. See for more information on daemon: https://man.freebsd.org/cgi/man.cgi?query=daemon&apropos=0&s...

After sending the log messages to syslog, it's a simple matter of routing them to the desired destination. That's easy enough to do by creating a file as follows:

    # /usr/local/etc/syslog.d/app.conf:
    !app
    *.*    /var/log/app.log

in this, the !app indicates this rule is for all items tagged "app", then the *.* matches "all facilities" and "all levels". The last bit indicates the file to route those messages to. After that, it pretty much runs itself. You can start and stop the service with `service app start` and `service app stop` and all log messages get forwarded to `/var/log/app.log`. You do need to make sure the log file exists and has appropriate permissions (usually 600 or 644, owned by root & the wheel group).

You can additionally set up log rotation with:

    # /usr/local/etc/newsyslog.conf.d/app.conf:
    /var/log/blog.log  640  7  *  @T00  Z

Oh and I believe you do need to reload syslog with `service syslogd reload` after this.

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#235

Earlier quoted context omitted.

Why would a VPS choke hosting static HTML? For 5 EUR you get 20 TB traffic on Hetzner.

You tell me. Here's a list of maybe 15 sites it's happened to on HN in just the last month: https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=tr...

I also know it happens. I still don't understand why.

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#236

Earlier quoted context omitted.

This is your personal opinion, a rolling release like NicOS is exactly the opposite of an LTS distro. I actually wonder what would happen to a NixOS installation frozen in time for 5 years that then you want to update to latest all of a sudden.

I'd say not much: you update the channel, run nixos-rebuild switch, fix all the warnings/errors due to renamed/changed options until it succeeds and you're done. If you have a database like postgres you may have to do a schema upgrade manually, since the default version is updated every 4/5 releases or so. It's very rare to find something that prevents you from directly updating. Nixpkgs tries very hard to no require…

And when it happens, that there are new Nix features used in Nixpkgs, then you can download the closure for the new Nix executable, directly from the build farm, and update your OS from this new Nix version.

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#237
post #140

Earlier quoted context omitted.

Show me those benchmarks

From every benchmark I've seen so far, Linux has always been faster than the BSDs. For example, look at these benchmarks from 2003[1]. The newest benchmarks I could find[2], [3] point in the same direction. [1] http://bulk.fefe.de/scalability/ [2] https://matteocroce.it/blog/freebsd_linux_networking/ [3] https://www.phoronix.com/review/freebsd-15-amd-epyc-linux

The comment I replied to pointed out that the benchmarks were old, which I agree with.

Both 1 and 2 are old and irrelevant, the 3rd has no clear winner?

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#238
post #4

Slightly off topic: What's currently the free Linux distribution with the longest support cycle? For a while I used CentOS 7 on all of those small VMs, because it got security updates for a really long time. With minimal risk of breaking things on updates. PS: after a bit of research Alma/Rocky Linux are probably the best choices for now. 10 years of support. But are they maintained well?

I don't have data, but my guess would be Debian or Slackware

gentoo

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#239

Earlier quoted context omitted.

> One reason mainframes and micros are still around us, is that you can change almost everything between hardware and software without downtime. We have some Sun V880s at work and I'm fairly sure the only part you cannot change with the power on and system running is the motherboard itself. And I would not be surprised if some ex-Sun Gandalf Beard "well akshully"s this comment.

Hot swapping the failed half of a bonded NIC pair on a v880 was a treat…

I come from an era when unplugging the RAM pack could blow every chip on the ZX80's board, so hot-swappable PCIe cards are just absolute fucking black magic to me.

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#240

Earlier quoted context omitted.

Hot swapping the failed half of a bonded NIC pair on a v880 was a treat…

I come from an era when unplugging the RAM pack could blow every chip on the ZX80's board, so hot-swappable PCIe cards are just absolute fucking black magic to me.

Yeah, I almost had a heart attack the first time I saw someone do a 'cfgadm unconfigure' && 'cfgadm disconnect'; then pop open the side of a prod box, press a button and pull a card out.

"See, oracle's still running!"

Things like that used to be how one distinguished enterprise hw & sw vs. PCs w/ delusions of grandeur.

Post reply on HN