One Linux'rs guide to FreeBSD Updating

why a Linux'rs guide?

I came from linux. Specifically the Gentoo mindset. Building from source. CFLAGS and the like aud-nauseum.

Why I chose FreeBSD over linux would be considered as flame bait, so I'll keep my mouth closed on this subject.

I am older. I found the FreeBSd documentation so thorough as to be daunting. In my case, likely because I'm older, the updating section was downright confusing.

There were so many ways to do things, yet there wasn't really a clear, concise roadmap or guide, or example of one way to do a complete source update.

I found FreeBSD's maintenance model different enough I couldn't get my arms around it alone, and posted because I may not be the only old fart who wants to change OS's.

I can't count the times in a VM, I completely borked a FreeBSD setup. You see, I had no one to "lead me by the hand" through one method (of many) of updating a box and rebuilding it from scratch. And that's all I needed to get me up and going and to turn on the light bulb of understanding in my head.

I just needed one iteration of hand-holding.......and now things are working well. I can now do in FreeBSD what I used to do in Gentoo.

Maybe I didn't look in the correct places, but in Gentoo, there was a step by step guide on how to bring a system out of the ground. I couldn't locate a concise guide for FreeBSD to do the same (from source). So I floundered. And if you look at when I joined the FreeBSD forums.....you will see I've been working at this for many months. Struggling.

My son (who's mid thirties now) gave me a little EEPC to use as my "guinea pig". And I've been using VMware also as test beds.

The binary portion of installation and updating on the FreeBSD documentation were clear and simple enough. It worked. But to rebuild from source, I was unsuccessful, and repeatedly so. Some of the packages I want to use get updated frequently and I want to use them. This means building that application from source rather than waiting for it to appear as a binary package. And of course there will be dependency updates as well.

I do NOT blame the documentation, I accept full responsibility myself for my inability to understand it.

And now as an advocate of FreeBSD, knowing what I know now.....having gone through enough tutorage to be able to install and maintain FreeBSD.....I have others in my old communities that would also like to use FreeBSD......But are also intimidated by the documentation's depth. And yes like me, they're not spring chickens either! So if they change OS's, I will be their first line of support.

Man pages have their place for sure, but I have found that real memory retention can be had in real world examples put to use, coupled with the man pages. At least that what works for me.


So I posted here to help others with a concise guide to updating from source. It's only meant to help.


It's not the only way for sure...But it is one way that has proven to work on my systems.


Sincerely and respectfully,


Dave
 
FYI, you can combine portsnap commands, like so:

Code: 
portsnap fetch update

I'm a lazy typist, so I have this aliased as 'pfu'.
 
I am old. I am not able to understand this formatting thing. What I posted I thought was very readible and clear.

My son (mid-thirties) is a network engineer and has extensive experience in some very large and mission critical data centers. He's more "in the know" than I am. I have asked him to review my posts and tell me what it is that is expected of me.

I have also PM'd the moderator and asked for examples for me to follow. I am HTML illiterate.

For those of you who are upset by the formatting, I apologize.

I ask for your understanding as my son reviews and tutors me on what it is I'm being asked to do.


Dave....
 
Sorry Dave. I didn't mean to get you going. Nothing beats the stability of FreeBSD.

I agree the handbook is mostly theory vs step by step instructions. It's interesting though, over the years I've come to appreciate it more as it comes in handy as a centralized document which for the most part is up to date. In some cases it can be considered a survival guide to the OS. It has become better over the years with the colored "best practices" boxes sprinkled throughout here and there now.

I tried gentoo a couple of years back( I'm the reverse of you I did FreeBSD first) and couldn't get past how often I had to deal with system breakage. Recently I have been toying with Funtoo which has the goal to 'Bring The Fun Back To Gentoo'. I have had little issues with it but it has only been just over a month. Hopefully that project goal will become established and we can have a linux distro which emulate a freebsd like ports system without fear of running software upgrades.

Now if they could just put user installed configurations in /usr/local/etc I would feel closer to home =)
 
Thanks UNIXgod,

No one's really got me going. I'm just older and cranky, and it's late here and haven't taken my evening medications........Take it with a grain of salt...:)

I left Gentoo because of the constant broken ports, but I also chose to leave linux as a technology after trying no less than 20 different distro's. And this has been a years process, not an overnight decision.

From my perspective, be that junior for sure, is that FreeBSD is designed to work together. Even the ports. Where as linux in my humble experience has many developers pulling the linux technology in different directions. Overall it's going forward, but without a cohesive entity with it's hand on the rudder, and sometimes things get a little hairy because there is no "captain" at the helm.

I wanted an OS than is designed to work together, where it is put together deliberately. Where all the developers for the most part are all aiming at the same target.

My choices are Windows 7, OS-X, or FreeBSD from which Apple's OS-X is derived (in part).

I need to get my arms and mind around whatever it is I'm doing wrong in the formatting thing (my son's going to have a look and assist me), then I think all will be well.

I remain appreciative of the support and assistance in the community.


Dave
 
dcbdbis said:
I have also PM'd the moderator and asked for examples for me to follow. I am HTML illiterate.
Click to expand...
If you mean PM, that you send me: I'm not a moderator :)
btw, I wanted to reply you, but, you either blocked all users from PM you or blocked me :)

dcbdbis said:
For those of you who are upset by the formatting, I apologize.
Click to expand...
Noone is offended by formating.... just warning you before DutchDaemon (Who never sleeps. lol), wakes up
 
Wierd. I just checked my settings and I do not have anyone blocked as far as sending me messages......

Anyway, I replace the text with a link, and my son gave me some pointers that I'm going to try to make the original post comply with formatting rules.


Dave.............
 
Thanks for nice summary.

I think the problem of FreeBSD Handbook is that it was written by multiple persons in multiple times, thus it explains the same subject in multiple places. Of course, there are more than one method to do a job (e.g. updating ports) but that just makes beginners more confused. What FreeBSD Handbook needs is this kind of "canonical" guide. Just explain ONE canonical method and leave others in Appendix.

The other day, I was reading FreeBSD Handbook looking for information on RAID, and it's same again --- there are multiple approaches to RAID and I don't know if a beginner can decide what to choose by reading FreeBSD Handbook.
 
ahavatar said:
Thanks for nice summary.

I think the problem of FreeBSD Handbook is that it was written by multiple persons in multiple times, thus it explains the same subject in multiple places. Of course, there are more than one method to do a job (e.g. updating ports) but that just makes beginners more confused. What FreeBSD Handbook needs is this kind of "canonical" guide. Just explain ONE canonical method and leave others in Appendix.
Click to expand...
Another problem with the handbook is that best practice methods change over time, as new tools and systems are developed. Not that anyone would call them "best practices", as they don't want to by implication rubbish the considerable effort that has gone into the previous generation of tools/systems. But if you judge the best practices by what the people who appear to know what they are doing do, it is obvious that this changes over time and the handbook doesn't keep up. For that reason I often search the forum first to see what people do, then try and figure out how to do that.

Not really sure as how one would go about fixing it though, other than my ad hoc method of forum search, generic google search, and handbook consultation.
 
carlton_draught said:
Another problem with the handbook is that best practice methods change over time, as new tools and systems are developed.
Click to expand...
That's not a real problem, the handbook gets regular updates. So if best practices change it'll be changed in the handbook too.
 
SirDice said:
That's not a real problem, the handbook gets regular updates. So if best practices change it'll be changed in the handbook too.
Click to expand...
True. I just checked the handbook and noticed that instructions for portmaster is now included. I think it had previously been absent, and it seems to be rapidly becoming a dominant way of doing stuff with ports. That (and ZFS backup and restore for root mirror setups) were the main things I was thinking about. I'm in the midst of doing something about the latter, hopefully will be able to release it soon.
 
You must log in or register to reply here.
Back
Top