[Ukfreebsd] opentech - 11th Sept - London

[Robert N. M. Watson]

On 1 Aug 2010, at 09:39, Mark Blackman wrote:

> I'd say that's a case of lots of evolutionary changes starting to add up to
> radical change.

Yeah -- I think I'd say that the UNIX model (really just a subset of the MULTICS model) has evolved pretty well to new hardware and new requirements over the years. That said, in a world of GUIs, some elements have proven less practical for end users than others: POSIX is a huge success, the process model has done very well, the file system pretty well, but end users mostly don't use command pipelines...

> In any case, I'm sure one could easily take Robert's great
> list of points and turn that into a talk with very little effort. Maybe he's
> volunteering! :)

Probably not, unfortunately, life is pretty busy currently. However, I'm happy to review slides and chat with people about what might be said!

> Mostly I was saying, FreeBSD is keeping up with everyone and "Modern" FreeBSD
> is recognisably different to FreeBSD 2000 once you get past basic sysadmin jobs
> and start running applications, but radical isn't the word that comes
> to mind for me if you're comparing to the FreeBSD 4 series, but is probably 
> appropriate compared to FreeBSD 3 which was a little more like the deployed
> versions in 2000, even if 4 was available.
> 
> I'm happily running FreeBSD 4 jails, merely because they're not doing a bad enough
> job to justify the effort of migrating to FreeBSD 8.

My experience is that FreeBSD is consistently consistent. The main motivations to shift forward from FreeBSD 4 tend to be:

- Get a version that's in security support
- Improved support for multicore
- Improved support for virtualization
- Improved file system feature set
- More recent network features (SACK, etc)
- Improved security feature set
- More recent compiler suite, system APIs (and hence support for more recent applications)

With the exception of security support (i.e, advisories), there's not a lot of motivation to update well-performing devices whose applications don't require upgrades or new features -- the main limit on uptime is power loss!

In terms of some of our larger users and their upgrade paths, 4.x -> 6.1 -> 7.2 is not an uncommon path. Some might argue that the 5.x jump was because of quality issues during SMPng development -- that's certainly possible, but looking at some of those companies having trouble getting forward from 6.1, I think it's actually just the difficulty of large system upgrades if you haven't been tracking the whole time. Most of the pressure to get to 7.x/8.x from 6.x has been improved multicore/network performance or improved threading performance, and while 6.1 and 8.1 look pretty similar in many ways, there are literally orders of magnitude performance improvements on high core density systems.

Robert