The Perfect Desktop: FreebSD 8.2 in Virtualbox 4?

Xn Nooby xnooby at gmail.com
Sun May 22 21:56:39 UTC 2011


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.


>> 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.


>> The goal would be to show how to configure the system on a
>> hardware-neutral platform (Virtualbox VM), so that people could use it
>> as an example for setting up their own systems.
>
> I'm sure the handbook's sections about the required
> parts can be very easily applied to virtual hardware,
> as they are generic enough to cover them.


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 suspect a lot of
>> people would use this guide for setting up a laptop, so an
>> underpowered VM would be a good proxy.
>
> Due to hardware limitations (incompatible parts) mostly
> found in "modern" laptops, I would assume that FreeBSD
> users prefer running the system on hardware that is
> known to work...


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.


>> 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.


>>  - builds from source minimally (laptops are slow!)
>
> There are laptops with resources equal to a fullblown
> desktop machine. :-)
>
>
>
>>  - 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.


>>  - uses a lightweight VM, icewm or openbox ?
>
> Or WindowMaker? :-)
>
>
>
>>  - optionally uses a heavyweight WM, Gnome3 ?
>
> Until it stops working. :-)
>
>
>
>>  - ideally demonstrates "best practices"
>
> Also depends on requirements, by users or by setting in
> which the system should be used (e. g. security policies,
> prohibition of standard means of communication and so on).
>
>
>
>>  - looks good, with nice fonts
>
> "Looks good" also depends VERY.
>
>
>
>>  - optionally supports openGL (desktop users would need that)
>
> Would they? :-)
>
> I know that average desktop users seem to get addicted
> to certain "bling", but some lines above, you mentioned
> that "laptops are slow", and the resources required for
> eye candy... are they included here?


If Virtualbox supports hardware-accelerated graphics on 64-bit FreeBSD
guests, then yes.


>>  - 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.


>> 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.


>> I know the Handbook has everything it it, but I am looking for
>> something that can leverage the fact that in a VM the hardware is
>> known in advance.  The instructions could then be very direct, and
>> would not have to cover all possible situations.  They would simply be
>> "do exactly these commands".
>
> But then this would depend on the VM's settings that
> needed to be in the preface, and this would be the same
> as keeping instructions generic and giving the additional
> advice of "change this if needed".


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. If I can make
something work in a controlled enviroment, my chances of getting it to
work in an uncontrolled environment are much higher.  For example, if
I can get Flash in 8-stable to work inside a Virtualbox VM, I can
probably make it work on my real desktop.


>> 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.


>> 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.  For example, on Windows/Mac/Ubuntu I can just do a "system
update" and everything managed by the system is updated. 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. From what I have read,
you should at least track the errata branch for the core system, so
you don't get hacked, and track the stable branch so you can get more
recent desktop apps (like Firefox4). When tracking stable, you may
have problems with the precompiled binaries, so it is better to use
portmaster instead of pkg_add. Did you set your PACKAGESITE variable
on the last thing you installed?  Or maybe I should run portupgrade?
Is one deprecated? What is the difference? Why isn't the file I had to
manually download and put in distifles not being recognized?  There a
million little questions that come up in what on other systems that
take one command.  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. An opensource VM
is also something that is available to everyone.


>> I could help some, by testing, and I can write an install
>> script to automate anything that I can understand.
>
> I know that the default installer "sysinstall" has a
> feature for scripting, but you could easily write your
> own installer that uses e. g. ZFS or GPT initialisation
> for the (virtual) disk instead of the traditional run
> of fdisk + disklabel + newfs. Providing packages for
> the required software (and ALL their dependencies) would
> also be a good step, so installation could even be done
> in an offline environment without ending with broken
> software.


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).

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

Thanks for the feeback!


More information about the freebsd-questions mailing list