Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg?

On 2014-10-20 19:15, Mason Loring Bliss wrote:
> On Mon, Oct 20, 2014 at 06:21:58PM -0400, Allan Jude wrote:
> 
>> This thread is supposed to be about how to make it easier for people to
>> migrate to FreeBSD from Linux. Not a discussion about forums vs mailing
>> lists vs newsgroups.
> 
> I'm going to transition from being an avid Debian user who hates web fora to
> an avid FreeBSD who hates web fora.
> 
> Anyway, my experience here is useful as I've got to be representative of a
> number of people making the transition lately. It's been a relatively smooth
> transition so far, with only a couple bugs and quirks in the way of my doing
> everything I did with Debian.
> 
> Two things would be principally useful for people coming from Linux.

Thank you very much for sharing this

> 
> First, the handbook should be updated and corrected, as it's a good enough
> resource that I've come to depend upon it, but I've hit snags that seem to
> not reflect the current state of FreeBSD.
> 
> For instance, the page that talks about running buildworld and buildkernel
> have some instructions that are evidently vestigal for root-on-ZFS people.
> 

Which parts? Nothing about buildworld is really any different when using
ZFS except maybe the way you mount /usr/obj with noatime etc.

> Another example, the documentation of Poudriere is hard to follow, presenting
> a complex and idealized set-up rather than explaining to a new user what the
> moving parts are and how it all works. I strongly suspect in that case that
> people who need the Handbook won't easily follow that, and people who can
> follow it don't need the Handbook per se, or that level of instruction.
> 

Can you be more specific? The documentation team likes to add 'quick
start' sections to the often more complex sections, so that users
looking to just get started can do so, and dig into the more advanced
options once they have it working.

> Joe Armstrong talks about this process of picking an audience in his forward
> to the second edition of his Erlang book:
> 
>     https://joearms.github.io/2014/06/26/Background-to-programming-erlang.html
> 
> The second thing that would be useful would be a series of cheat sheets for
> various things. This can either be equivalent commands or equivalent systems.
> Let new folks know that LUKS is GELI and that md-raid1 is gmirror and so
> forth. Show common package handling commands for various Linux flavours and
> map them to pkgng and ports. For instance, what's the equivalent of "yum
> provides"? Or what do I do in place of "apt-cache search" or "zypper up" or
> similar.
> 

This is what this thread was originally about, creating such cheat sheets.

> Other things in the grab bag... It's generally said that ports and pkgs
> shouldn't mix, but there are at least a couple instances where it's
> unavoidable:
> 

This was true with the old package system, since those packages were
built work a ports tree snapshot from the date of the release. With the
new binary packages being rebuild weekly, it is much less of an issues.
One goal is to actually have the version of the ports tree that the most
recent binary packages were built with available, so that users who use
that would have 0 complications from mixing.

Also, there have been some proposed features for pkg to make it aware of
which packages were installed from ports, and when 'pkg upgrade' runs,
to rebuild those packages from ports with the same options, instead of
installing the 'wrong' version from the binary packages, requiring the
user to 'pkg lock' or 'pkg annotate' to avoid that.

> I bet roughly no one who installs Subversion wants the FreeBSD bug report
> headers baked in by default, but there they are unless you rebuild from ports
> with a non-default configuration.
> 
> If you want to watch DVDs on your FreeBSD workstation, it's necessary to
> install libdvdcss, but you can't get it from pkgng because it's not there.
> Again, you must build from ports.
> 

Binary packages of libdvdcss are not built for legal reasons

> I have nothing against ports, but people are warned off of mixing packages
> and ports when clearly it's necessary sometimes.
> 

It may be time to revisit this warning, as it may no longer be required.

> Oh, here's one. I *was* horrified by ports at first, until someone told me
> about "make config-recursive". It really makes me wonder why this isn't the
> default. I remember giving up on FreeBSD when 9.x was new because I had to
> build X from ports after the FreeBSD breach, and it seemed like the process
> was going to take a couple days of stuttering stops and starts as random
> packages I didn't want in some cases popped up between compiles. I learned
> some mechanism for saying "just take the defaults" but what I know now is
> that what I really wanted was "make config-recursive". Why, out of curiosity,
> is it not the default? That would seem better than documenting it harder.
> 

Making config-recursive the default is infact a good idea, unless
someone knows a reason it should not be.

> Ah, and one more for the grab bag. I strongly suspect that many folks coming
> from Linux are going to bristle at the notion of using Sendmail. I used to
> run it so I wasn't terribly bothered by it, but maybe pre-populating rc.conf
> with obvious bits that people can see and turn off would be nice. OpenBSD has
> a nice model of populating rc.conf and sysctl.conf fully, and it ends up
> being a pleasant tool. Those awash in wonder, coming from Linux, can say,
> "Look, it's all right here!"
> 

The pre-populated with every option version of rc.conf is
/etc/defaults/rc.conf

There was a project to better document the sysctl tunabled, but it seems
to have stalled.

-- 
Allan Jude