3 ms·

You might want to ask them again if 2 is true. In reality, I highly doubt they really use what you described in point 2. (or it's a miscommunication). Unless t

You might want to ask them again if 2 is true. In reality, I highly doubt they really use what you described in point 2. (or it's a miscommunication). Unless they recompile world all the time (a nontrivial amount of work and a waste of time if you are not actively developing the OS itself) - CURRENT is actually much much slower because of debugging flags that are enabled by default. Some of these flags make the kernel panic upon certain types of errors and drop into kernel debugging mode allowing the examination of kernel dumps. I can't fathom why anyone would generate real security certificates in this kind of environment. You can recompile with the WITNESS (kernel lock counting & validation - incurs performance loss but useful for counting kernel data structures) and INVARIANTS (run-time assertion checks and tests for kernel data structures) options off, but then you would have to spend time recompiling the kernel instead of working on your software. https://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-options.html https://www.freebsd.org/doc/en/books/developers-handbook/ker... Note that CURRENT is packaged as snapshot binaries without binary upgrade capability - which means that once you install "one day's" -CURRENT the only 2 ways to upgrade are a) download the new iso and reinstall the entire OS or b) check out the freebsd source code via svn and recompile the system (often world changes as well so you need to do both kernel + userland). If 2. is actually true, then the person you know who is doing that, unless they are being paid to work on freebsd features or perhaps validating and porting freebsd to a different hardware platform like ARM or PS4 or an embedded device like a medical imaging device or a router (ie Junos), they are wasting a lot of their employer's time and foot-gunning themselves massively in security. If you show them this post, ask them what they are doing with -CURRENT? I am open to learning new things so I'd really like to know!

barkingcat 12y ago
I spent way too much typing this reply. I should just join the freebsd development team and learn the answer to my own question. Thinking about this again - yah - the poster might be referring to some kind of workflow like this: production machines are platforms that run -STABLE there is some kind of device, embedded or otherwise, that they keep locked up somewhere in a lab. It could be the new xxyz multicore switching fabric [imaginary name] that is running a new version of BSD-OS variant that's undergoing verification testing - they run hardware development and need -CURRENT's capabilities for debugging the system itself. It generates some keys that will be distributed into the pool of machines running -STABLE so that in the future, when this new variant comes into the market, there will be "pre-seeded" keys for compatability (ie. older versions of systems will be able to interact via signed certs with the new system) Since FreeBSD is BSD licensed, there can be any number of things people are doing with it without anyone else knowing - so maybe to give the benefit of the doubt, I can envision a workflow that needs -CURRENT as a workstation / dev platform. I think one weakness to my thinking is that VARIANTS/WITNESS/kdb/ddb can be enabled on -RELEASE and -STABLE distributions as well! Why not just do everything on -STABLE even if you need kernel debugging? If they need -CURRENT for new hardware support, it shouldn't be too hard to figure out from the svn log and the rolling release notes. It's kinda fun trying to reverse engineer the job of the thread parent's acquaintance!

barkingcat 12y ago

I spent way too much typing this reply. I should just join the freebsd development team and learn the answer to my own question. Thinking about this again - yah - the poster might be referring to some kind of workflow like this: production machines are platforms that run -STABLE there is some kind of device, embedded or otherwise, that they keep locked up somewhere in a lab. It could be the new xxyz multicore switching fabric [imaginary name] that is running a new version of BSD-OS variant that's undergoing verification testing - they run hardware development and need -CURRENT's capabilities for debugging the system itself. It generates some keys that will be distributed into the pool of machines running -STABLE so that in the future, when this new variant comes into the market, there will be "pre-seeded" keys for compatability (ie. older versions of systems will be able to interact via signed certs with the new system) Since FreeBSD is BSD licensed, there can be any number of things people are doing with it without anyone else knowing - so maybe to give the benefit of the doubt, I can envision a workflow that needs -CURRENT as a workstation / dev platform. I think one weakness to my thinking is that VARIANTS/WITNESS/kdb/ddb can be enabled on -RELEASE and -STABLE distributions as well! Why not just do everything on -STABLE even if you need kernel debugging? If they need -CURRENT for new hardware support, it shouldn't be too hard to figure out from the svn log and the rolling release notes. It's kinda fun trying to reverse engineer the job of the thread parent's acquaintance!