The Perfect Desktop: FreebSD 8.2 in Virtualbox 4?

Polytropon freebsd at edvax.de
Mon May 23 15:17:58 UTC 2011


On Sun, 22 May 2011 17:56:37 -0400, Xn Nooby <xnooby at gmail.com> wrote:
> On Sun, May 22, 2011 at 3:48 PM, Polytropon <freebsd at edvax.de> wrote:
> > On Sun, 22 May 2011 15:17:50 -0400, Xn Nooby <xnooby at gmail.com> wrote:
> >> HowtoForge has a lot of good examples of how to install and configure
> >> a desktop system using various Linux distributions, but there are none
> >> on how to create a FreeBSD desktop.  Would someone will be willing to
> >> put one together?
> >
> > U think the majority of FreeBSD users who use the system
> > on their desktop won't agree on "the one desktop", as
> > everyone I've encountered so far has different preferences
> > and requirements. So a generalized statement is quite hard.
> > There are systems with preconfigured desktops, such as
> > PC-BSD, DesktopBSD and FreeSBIE.
> 
> 
> I'm thinking about new users, rather than typical users. A typical
> FreeBSD user probably already knows how to configure a desktop that is
> ideal for them.  A new user will take whatever they can get working,
> and keep working.

Hmmm... Then we have different observations about what
a "new FreeBSD user" means. In my opinion, those who
come to FreeBSD don't come here "from nothing" - i. e.
they traditionally have a UNIX or at least Linux background
and begin understanding that FreeBSD doesn't come as
a preinstalled and preconfigured desktop - it CAN'T,
as it is a multi-purpose operating system that you
can use on desktops of course, but also on servers
and on "mixed forms". Those who do not want to
understand the OS, but want a preconfigured system,
will quickly orientate to use PC-BSD or some other
system which already has the goal to exactly provide
that: a preconfigured system for a specific target
audience. This brings up another question: Why would
somebody want to build a system on his own when he can
download "the result" already?



> >> I envision this more of a how-to than just providing an "appliance".
> >
> > But that would be a good starting point for learning on
> > how the inventors of VirtualBSD (to name an appliance)
> > have done it, and build an own system from there on,
> > keeping The FreeBSD Handbook at hand.
> >
> > See http://www.virtualbsd.info/ for details.
> 
> 
> I had previously visited their site, but they did not have
> instructions on how they created the appliance, or a forum to discuss
> it.

I think they did create it in a similar way as how
anyone (with sufficient knowledge) can create such
a system using FreeBSD and the appropriate tools.
As we discuss free and open software here, it should
be possible to deduct the chain of creation from
"mentally de-compiling" the results. In most cases,
things can be observed back to files modified and
programs installed.



> When I configured the sound driver on my machines, I had to go through
> a "discovery" process to find out what driver was required on each
> machine.  Inside a VM, you would know what driver to load, and you
> could just tell the user to "install the sound driver with this
> command".  You wouldn't have to tell them how to figure out which
> driver to install.

I just have limited experience with virtualized hardware
on a PC basis, but shouldn't it be possible to define the
kind of DSP when creating the VM - so a VM could also have
different "virtual sound cards" installed?



> I would expect that a typical new desktop user would be using an old
> computer purchased before they knew anything about FreeBSD. Or even
> more likely, a virtual machine hosted on a Windows box.

Unlike "mainstream" operating systems, FreeBSD is able to
deliver good results on "older hardware", but only if the
person who installs the system has sufficient knowledge
about which ports to install (NB: older software may be
the better solution here!). But I agree that providing
a lightweight-oriented system could be a good approach.
It doesn't mean that you need to run older versions of
the OS - in fact you can run 8.2 even on a 300 MHz machine. :-)



> >> Some parameters for the guide could be:
> >>  - uses 8.2 installer
> >>  - tracks errata branch with FreeBSD update
> >>  - tracks 8-stable branch for ports
> >
> > Depends on preferred usage paradigm.
> 
> 
> Yes and that paradigm would have to be properly defined.  My
> definition would be that of a hobbyist desktop user who wants a
> functioning and maintainable desktop enviroment. In the Debian example
> I gave, their "included software" implies their target audience.  I'm
> not interested in hosting 5000 jails, running a database cluster, or
> acting as the neighborhood ISP.

For most ports from the desktop area, running -STABLE
is eing suggested. But this involves system updates per
src/ updating and compiling. On the other hand, if you
keep using RELEASE-pX, using freebsd-update, you _could_
run into trouble from time to time (depending on ports
installed).



> >>  - demonstrates how to install many desktop apps
> >
> > That would be covered by "how to install additional
> > software", which means pkg_add, make install, or a
> > port management tool. Maybe you refer to how to involve
> > graphical port management abstractors?
> 
> 
> I would prefer to stick with command-line tools, but in a controlled
> environment that won't fail.  Maybe that is not possible when tracking
> "stable" (ironically).  For example, I've spent most of the last 72
> hours trying to install firefox, flash (via linux_base-10), and
> virtualbox-ose-additons in to a "stable" environment, and only firefox
> is working.  About once a year for the last 6 years I try to setup a
> FreeBSD desktop, and eventually get frustrated and go back to linux.

I may say that I'm using FreeBSD exclusively on the desktop
since 4.0 without any problems, but I also don't have requirements
like VirtualBox or "Flash". I got "Flash" running some years
ago, found it made the web fully unusable, and removed it. :-)

But as we're discussing average desktop users, the requirement
of having "Flash" will be there, at least some time, until
HTML 5 has its full impact, and in that case, a good browser
and proper media plugins will take its role.

Especially this kind of software often needs "bleeding-edge"
versions, so updating src/ (because of -STABLE) and ports/
(because of the recent versions) will be required, and
continuous updating will also be required.

Just let me state that there is a totally different usage
paradigm: "Install ONCE, then keep using", which also has
its benefits and disadvantages.



> >>  - optionally includes tips for upgrading to 8.3+
> >
> > Also the standard means apply here.
> 
> 
> Yes, but it would potentially be less error-prone with known hardware
> devices being emulated.

Yes, I agree.



> >> Here is the page for Debian Lenny as an example:
> >>
> >> http://www.howtoforge.com/the-perfect-desktop-debian-lenny
> >
> > Yes, a very pictural step-by-step guide. For FreeBSD users
> > who traditionally are educated in how UNIX in general and
> > FreeBSD in special case do need to be operated, this may
> > not be the primary kind of information supply, but I may
> > be wrong here.
> 
> 
> I'm thinking of something for new users who probably have linux
> experience, but not a Computer Science degree.

A CS degree has ***_NOTHING_*** (can't add much more emphasize)
to do with actual skills operating a computer (no matter which
OS it runs).

A Linux background is good, as long as it involves how to
use the command line - this means simple UNIX basics should
be there to help in the installation and configuration
process. If the instruction (compare The FreeBSD Handbook)
are given in a good form, it doesn't matter if they are
pictures or text (but text is preferred, as you can easily
copy + paste them into the virtual client's command line
window, and also blind users can benefit from that fact.)



> There is a lot of value in having instructions that work.  I would
> rather have instructions that work in a simulated environment, than
> instructions that don't work in a real environment.

Fully agree. :-)



> >> Admittedly I am asking for what I need, but there might be others who
> >> could benefit.
> >
> > That's understandable, but could you describe the target
> > audience a bit better?
> 
> 
> I would say someone who already has some experience with Linux, and
> who wants to try building a usable FreeBSD desktop system for home
> use. It would need to do things like surf-the-web, watch youtube
> videos, stream audio, burnd CD's, use Libre Office, and maybe play
> some games with MAME or WINE.

Okay, that's all things I'm doing here for many years now,
years before they became common on average PCs. :-)

The advanced and user-friendly FreeBSD OS should provide
a good basis on building such a system and the according
HOWTO. Another requirement is users who use VirtualBox on
a daily basis to provide some testing.



> >> I have been trying to make a script to do these
> >> automatically, but I am still having problems understanding certain
> >> things.
> >
> > And I may predict that exactly those things are needed to
> > be understood to get the whole show running. "Learning by
> > doing" is nothing wrong here, although it requires some
> > reading.
> 
> Yes, and I do a lot of reading.  Sometimes reading can be confusing
> when there are many ways to do something, and no clear preferred
> method. 

Maybe this is because there is _no_ preferred method? For
example, partitioning mechanisms and file systems supported
by FreeBSD give you some freedom, but YOU have to decide
which one to use.



> For example, on Windows/Mac/Ubuntu I can just do a "system
> update" and everything managed by the system is updated. 

In such environment, it's confusing _what_ is actually
managed by the system.



> If you google
> "how to update freebsd ports" you will find everyone has their own way
> of doing it. A long time ago I used csup to update the ports tree, but
> apparently that is incompatible with portsnap.

While portsnap provides a current snapshot, csup (the "old"
method behind "make update") provides a "more current" one.
Both methods are supported, and depending on your setting and
requirements, one of them will be _your_ "preferred method".

There are also different methods for dealing with ports:
Some users prefer "make install", others like portmaster,
and others use portupgrade, or portmanager. Together with
the system tools, many programs can be used side-by-side,
but there are additional things to consider when doing so.



> From what I have read,
> you should at least track the errata branch for the core system, so
> you don't get hacked, [...]

For offline systems, you can also easily run 4.x or 5.x,
for example when running as a backup server for internal
use. As I said: Depends.



> [...] and track the stable branch so you can get more
> recent desktop apps (like Firefox4).

Not "and" - it's "or". The -STABLE branch gets more often
updated on the road to the next -RELEASE, so many software
that is considered "bleeding edge" works better with -STABLE.
Unlike -CURRENT, -STABLE _is_ a stable OS development
snapshot.



> When tracking stable, you may
> have problems with the precompiled binaries, so it is better to use
> portmaster instead of pkg_add.

I've not encountered yet such a problem, but if you state
it, I don't assume you're wrong. And in the role of portmaster,
ANY of the port management tools can appear, even "none"
(which means that you use the "make" framework). For your
goal, I would also suggest employing portmaster, as it has
proven to be an excellent port management tool.

There is a set of -RELEASE related precompiled packages
that can be used with systems that run -RELEASE and also
the -RELEASE-pX branch.


> Did you set your PACKAGESITE variable
> on the last thing you installed? 

YOu can use this variable to explicitely request newer
packages that are compiled more often and usually require
-STABLE, as they correspond to a newer than -RELEASE
ports tree.



> Or maybe I should run portupgrade?

Also depends on preference. I've been using portupgrade
together with "make install" and "pkg_add -r" (and don't 
forget to run "pkgdb -aF" before and after each run!),
but there are many users who stopped using it in favour
of portmaster.



> Is one deprecated?

I don't think so, both are still supported.



> What is the difference?

The main difference is that portmaster is lighter on
dependencies.



> Why isn't the file I had to
> manually download and put in distifles not being recognized? 

An error message should tell this, e. g. wrong file, checksum
mismatch...



> There a
> million little questions that come up in what on other systems that
> take one command. 

This is because FreeBSD gives _YOU_ the chance to decide,
instead of defining the way for you to go, and aggressively
keeping you on that way.



> If FreeBSD just has a lot of tools for doing
> updates, that is fine, but it would be nice to see a minimized process
> even if it has to happen in a controlled environment.

The tools provided by system and ports can be nicely automated,
e. g. fetching updates once a week, recompiling on Monday
evening (system and ports), and making a backup before
starting.



> An opensource VM
> is also something that is available to everyone.

And it's also a good means for "trial & error" as you can
easily make copies of whole virtual machines, so if you
accidentally mess up system n, you can delete it and try
again with n-1.



> I would prefer a "plain vanilla" example, where someone installs
> FreeBSD taking mostly the default options, and then converts it into
> their desktop system. For example, when I test my notes, I just tell
> FreeBSD to take the entire disk, and format it using the default
> options (the "a" option).

On a VM, this is no problem (as the user doesn't have to
care for partitioning). It may even be possible to leave
out sysinstall and write an own installer shell script
(which should be very easy) that installs a base system
that can then be booted, and from there on, everything
else is installed and configured.




-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...


More information about the freebsd-questions mailing list