On Sun, 22 May 2011 17:56:37 -0400, Xn Nooby <xno...@gmail.com> wrote: > On Sun, May 22, 2011 at 3:48 PM, Polytropon <free...@edvax.de> wrote: > > On Sun, 22 May 2011 15:17:50 -0400, Xn Nooby <xno...@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, ... _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
