Linked by Eugenia Loli on Mon 25th Apr 2005 23:21 UTC
PC-BSD Have you ever wondered why there is no easy-to-install desktop BSD operating system with automatic hardware detection and setup? If so, you'll be pleased to learn that things are about to change in this respect - courtesy of PC-BSD. Designed as an "easy-to-install-and-use operating system", this FreeBSD-based system comes with a graphical installer and automatic hardware detection - features that have never been seen in the BSD world!
Order by: Score:
Always thought of that
by Anonymous on Mon 25th Apr 2005 23:31 UTC

I use FreeBSD all the time. I have always wanted to suggest an option that would allow the user at boot time to choose between advanced setup (the one they already have). And a simple to use GUI setup similar to the one PC-BSD has.

This would make it easier for adoption and might as well push FreeBSD to Desktop scene. You never know when Linux is going to die ;)

bsd
by James on Mon 25th Apr 2005 23:36 UTC

Go bsd! I've always enjoyed it (freebsd), but haven't been able to get my recent wireless mouse to work. Maybe this will help.

Automatic hardware detection?
by David Gwynne on Mon 25th Apr 2005 23:43 UTC

How can you claim that automatic hardware detection is a feature that has never been seen in the BSD world before? Have you ever tried booting an OpenBSD or NetBSD box? Last time I tried using these two BSDs all the supported hardware was detected at boot and ready to use. I believe FreeBSD did a great job of automatic hardware detection too when it was still a monolithic kernel. Perhaps FreeBSD's kernel modules could be considered a regression in this situation since it seems to complicate and obfuscate things for the user?

uhhh, no...
by SAM on Mon 25th Apr 2005 23:49 UTC

um...isn't Mac OS X a FreeBSD distrib with a graphical installer and automatic hardware detection?

RE; uhhh, no...
by Mad Echidna on Tue 26th Apr 2005 00:15 UTC

If you're going to be that technical, than Windows XP is a VMS distro with a graphical installer and automatic hardware detection. See how dumb that is?

Loadable moduals and regression
by Anonymous on Tue 26th Apr 2005 00:16 UTC

"Perhaps FreeBSD's kernel modules could be considered a regression in this situation since it seems to complicate and obfuscate things for the user?"

I believe loadable moduals exist in various BSD's (and Linux) and it is not considered a regression.

1) While have hundred moduals compiled into the kernel when you only going to use one or two moduals.
2) No need to recompile a kernel when adding and or changing hardware. Just have it load as a new modual.

And yes, loadable moduals for the paranoid can be a secuirty risk (IE: rootkit getting loaded).

As for hardware detection, all BSD's just work when it comes to hardware support. I really cannot blame the group starting up this project. Its a tad bit on the side of sensationalsim but not in a bad way.

I very much encourage the development of a slightly more user friendly version of *BSD. However, I am somwehat curious on how they are going to handle (in a GUI fashion):
1) packages
2) ports

Using the command line to update Packages and Ports isn't difficult (as well as cvs). However, I am curious about which particular solution they will be using to have the system:
1) Install software
2) Upgrade software

There are several Ncurses and GUI based tools to handle them. But its the implementation that makes me a tad bit curious.

One last thing on loadable moduals. The enhancement or implemetation of SCSI/CAM as a loadable modual truley is and excellent idea. Several users like using "cdrecord" while burning CD's. And not having to compile the kernel to get this functionality is just fantastic.

And yes, there is "burncd", however some prefer to use the SCSI/CAM emulation with "cdrecord".

All I can say is, this is going to be an interesting release of PC-BSD, FreeBSD, OpenBSD and NetBSD.

FYI: FreeBSD and OpenBSD release dates are just around the corner. Not sure about NetBSD, though; also DragonFly just did a new release most recently.

PS: I would love to hear more on the new pending releases of:
1) OpenBSD
2) DragonFlyBSD
3) FreeBSD
4) NetBSD

PSS: And yes, we cannot forget the obligitory "BSD Rocks".

Re: uhhh, no...
by Olli on Tue 26th Apr 2005 00:16 UTC

Does Mac OS X (natively) run on a PC (x86)... uuuuh no.

re: Loadable moduals and regression
by Anonymous on Tue 26th Apr 2005 00:26 UTC

"1) While have hundred moduals compiled into the kernel when you only going to use one or two moduals?"

I meant to say, Why not While.

I also didn't mean to steer to far off topic on this new BSD release. Upon doing some further reasearch, on the list of packages, it looks like its going to be an interesting relase:

Packages
http://www.pcbsd.org/releasenotes.htm

I must say, there looks like there is going to be a nice font selection (GhostScript, cmpsfont, bitstream-vera, MS fonts) as well as some nice extras like a WebDAV client, ImageMagick, cdparanoia, TeTeX and so on.

WOW!
by Ricardo on Tue 26th Apr 2005 00:30 UTC

..."automatic hardware detection"?
Welcome to the 21st Century!

v OS X x86
by mike on Tue 26th Apr 2005 00:38 UTC
RE: Loadable moduals and regression
by David Gwynne on Tue 26th Apr 2005 00:43 UTC

"I believe loadable moduals exist in various BSD's (and Linux) and it is not considered a regression."

This is true, but having support for LKMs and relying on LKMs are two different things.

"1) While have hundred moduals compiled into the kernel when you only going to use one or two moduals."

But what do you gain by not having these modules in the kernel? The answer is a couple of megabytes of RAM.

Personally I value the ability to move a hard disk between computers and not have to reconfigure or recompile because everything that is supported by my kernel is already there. I value being able to mount root off a filesystem on a strange storage controller without having to load a module which is on my root filesystem. I value being able to use the features that are there, rather than wasting time trying to find the module that provides the feature before I start using it.

Taking into consideration how cheap ram is and how much I value my time, the decision isn't hard for me.

"2) No need to recompile a kernel when adding and or changing hardware. Just have it load as a new modual."

Or if you have a monolithic kernel with support for everything including the kitchen sink, you simply plug in the hardware and it works.

If your argument that a new driver has been written for a bit of hardware, then in my experience you have to upgrade the kernel anyway, or waste time backporting it to the same tree your kernel was built from and go from there.

It all just seems so complicated.

RE: uhhh, no, no, no!!!
by GAlain on Tue 26th Apr 2005 00:56 UTC

Windows is NOT based on VMS. Microsoft only hired some developers of VMS (including the VMS's chief architect) to design the NT kernel, thus the similarities. Nothing more. No common codebase.

What about Freebsie?
by Tim on Tue 26th Apr 2005 00:56 UTC

Tested the Freebsie FreeBSD based livecd last week, detected hardware flawlessly on my desktop (Duron 900, 256), worked fine on my Laptop to IBM R31, although it didn't autoconfigure the wifi. Pretty good for a LiveCD.

RE: OS X x86
by GAlain on Tue 26th Apr 2005 00:57 UTC

So, where is the easy graphical installer of darwin?

Tip
by Anonymous on Tue 26th Apr 2005 01:01 UTC

FreeBSD Workstation recipe:

1. Install FreeBSD from your favourite media
2. Login on the machine
3. cd /usr/ports/misc/instant-workstation && make install clean

It doesn't provide a graphical installer, but it is really FreeBSD and not some FreeBSD-based system.
Still, it's nice to have yet-other-BSD to play around ;)

Re: OS X x86
by wired on Tue 26th Apr 2005 01:08 UTC

"'Does Mac OS X (natively) run on a PC (x86)... uuuuh no.'

http://www.gnu-darwin.org/

idiot."

Mac OS X is not Darwin. It's kind of like saying "Redhat is the same thing as Linux." Redhat contains linux, but Linux by itself is not Redhat.

So I wouldn't be so quick to call this person an idiot.

. . .
by Anonymous on Tue 26th Apr 2005 01:13 UTC

As for automatic hardware detection, FreeBSD does a lot of it, but not all of it. For example, one has to manually set up a sound card in FreeBSD.

I think this is a nice project. I would like to see it with more packages (does anyone know if it is compatible with the FreeBSD repositories?). Maybe PCBSD will grow to be the Ubuntu of FreeBSD. I've installed FreeBSD before. It wasn't too hard, but I did have to write my own config files for when X starts and such. Not too difficult, but still. I really hope this project takes off. Maybe someone will work on getting a Gnome-centric version.

Oh, and installing from a live CD is so much nicer than installing from a boot-time installer (ala Fedora or Ubuntu) if for no other reason than I can chat online while installing.

Thanks to the person who posted the instant-workstation port. Do you know exactly what it installs (Gnome/KDE? Does it set up a graphical login prompt like GDM? Does it take forever to compile? Can I install it using pkg_add?)

License
by Anonymous on Tue 26th Apr 2005 01:17 UTC


PC-BSD License Info

All software custom developed for PC-BSD is released under the GNU General Public License, and may be downloaded from sourceforge.net.


Bummer

Nice project, love the idea, wish they would leave out the FUD, such as in here:

"One of the reasons FreeBSD was chosen over Linux is an issue at the very core of the two systems. Linux is not an OS in the true sense of the word, but rather a kernel with a collection of various packages and software, combined to form distributions. Because of this, Linux has the tendency to become very fragmented, and break compatibility with just about every release of a new distribution. This makes the creating and supporting of software a nightmare for developers, who usually don't wish to rewrite portions of code every couple of months.

FreeBSD on the other hand is a proven platform that is created to be a complete UNIX based operating system at its core. With the standard FreeBSD OS installed, a desktop can be built and maintained very easily, and code ported to it has a much longer life."

Re:
by chris on Tue 26th Apr 2005 01:43 UTC

A few people have mentioned this now so it needs correcting. FreeBSD is a monolithic kernel. Just because it has kernel loadable modules does not make it a micro-kernel.

A monolithic kernel is one where everything is compiled into the same program. Just because you can load a module in does not make a kernel a microkernel.

In contrast, a microkernel only implements the very basics expected of a kernel. Modules added to a microkernel are a separate entity and tend to be run as user services and communicate with the kernel usually through IPC. If a module dies in a microkernel it can be restarted without effecting the rest of the system.

So FreeBSD is a monolithic kernel.

Re: License
by Anonymous on Tue 26th Apr 2005 01:51 UTC

GNU's GPL again!
why would the developers even bother.
When it comes to *BSD OS's I would like to keep it a freebsd license not GNU's GPL.

Apple OSX
by Anonymous on Tue 26th Apr 2005 01:55 UTC

Is NOT based on FreeBSD. It's based on NeXTSTEP which is based on Mach and 4.3BSD which was forked in 1989 and eventually became FreeBSD in 1993.

:-)

I would like to keep it a freebsd license not GNU's GPL
by Anonymous on Tue 26th Apr 2005 01:56 UTC

Well then fork it (pre GPL), and build your own OS! Isn't that what both licenses are all about?

@ By Anonymous (IP: ---.cpe.townisp.com)
by Anonymous Penguin on Tue 26th Apr 2005 02:18 UTC

"Maybe PCBSD will grow to be the Ubuntu of FreeBSD."

I hope not. Long before Ubuntu existed, Mandrake and SUSE had made linux easy to use and had a lot to offer.
And Libranet had made Debian easy.

It most certainly does contain freebsd code
by brad on Tue 26th Apr 2005 02:21 UTC

"Is NOT based on FreeBSD. It's based on NeXTSTEP which is based on Mach and 4.3BSD which was forked in 1989 and eventually became FreeBSD in 1993.

:-)"

Uhm, it most certainly does contain code from FreeBSD 5.x

The BSD3.3 layer was replaced with a FreeBSD one

It most certainly does contain freebsd code
by brad on Tue 26th Apr 2005 02:22 UTC

Proof right here, on apples own website :

http://www.apple.com/macosx/features/unix/

Way to go, but much to do
by subliminalwinter on Tue 26th Apr 2005 02:33 UTC

It's about time! But there's still much to do. To be accepted as a desktop, or to be competitive with "You Know What", it needs to beat all the bells and whistles of YKW. That's a pretty tall order, and it takes time and innovation.

Limited Usefulness
by itanic on Tue 26th Apr 2005 02:34 UTC

This will be largely irrelevant to existing BSD users, and as a BSD project will offer little contribution to the other existing projects. Not only will the work itself not offer much worth the other projects merging into their code, but the GPL tainted code rules it out entirely.

BSD is not difficult to install right now. In fact, the install options are pretty darn easy as it is. Package selection is already broken down into a few simple options. The only way it's not user-friendly about it is that there's no eye candy where you can click the same button in the same spot non-stop until the installation is done. Really though, a user that requires such user-friendliness is only going to be able to skim the surface of the true power of the BSD's anyway.

In many ways, the BSDs are already very user-friendly, in the sense that they have excellent documentation and are extremely cleanly, logically designed. People who don't find them to be such are probably better off with other operating systems.

Sure, by basing a desktop OS on BSD you may be able to tie in some of the BSD advantages,but even once this project has achieved that point these advantages will only be slight from the perspective of a desktop user. The real opportunity for such a project would have been in the BSD licensing, which would give it a major advantage as a business workstation for enterprise use, where having a political manifesto as a code license may be a deterrent. However, by GPL'ing all the forked code, this project leaves it little room to stand out, either as a BSD or as a GPL desktop operating system.

re: David Gwynne (IP: ---.vislab.uq.edu.au)
by Anonymous on Tue 26th Apr 2005 02:59 UTC

David,
Let me be the first to say I agree that you have points and to a good extent, I respect those points and opinions. Hopefully I will be able to outline my point of view (hopefully).

"But what do you gain by not having these modules in the kernel? The answer is a couple of megabytes of RAM.

Personally I value the ability to move a hard disk between computers and not have to reconfigure or recompile because everything that is supported by my kernel is already there. I value being able to mount root off a filesystem on a strange storage controller without having to load a module which is on my root filesystem. I value being able to use the features that are there, rather than wasting time trying to find the module that provides the feature before I start using it."

Yes, you do get a couple megs of ram. But you also get some other benefits.

1) Testing a new moduals without having to recompile the kernel/userland. Say a new sound driver gets released that may fix a problem that a user is experiencing. Now, without having download the source for the OS and compile the kernel and potentially the userland tools would be of some benefit. Depending on how much the source code has changed, rebuilding userland tools might be in order. On my dated pIII 800, it takes about an hour to redo the tools and 5 minutes for the kernel. It is a time saver. Doing the tools takes time.

"Taking into consideration how cheap ram is and how much I value my time, the decision isn't hard for me. "

Memory isn't cheap all around the world, nor are PC's. Please don't take offense but you may be in a country where PC's cost approx a year's (plus) in wages to purchase.

"Or if you have a monolithic kernel with support for everything including the kitchen sink, you simply plug in the hardware and it works. "

True, it is very convient. No arguments here.

"If your argument that a new driver has been written for a bit of hardware, then in my experience you have to upgrade the kernel anyway, or waste time backporting it to the same tree your kernel was built from and go from there."

Just because a driver gets updated doesn't necessarily mean that a kernel has to get upgraded.

As I mentioned before, testing a new driver or whatever else "x" happens to exist. Compiling a modual and just loading it are just a tad bit quicker than: compiling a kernel and userland utilities. Hey, someone might be testing a patch.

"It all just seems so complicated."

Sorry if it seems a tad bit complicated.

FYI: This is just an excerpt of some flexibility that some people can enjoy. It may not be your cup of tea (as the saying goes 'us saying').

freenode irc
by tuxi on Tue 26th Apr 2005 03:00 UTC

irc.freenode.net
#pcbsd

is open .

time saver
by tobaccofarm on Tue 26th Apr 2005 04:54 UTC

Great time saver.Instead of cvsup + portsdb + portupgrade everything to current and a lot of dull "hard" labour work in order to get an initial desktop running this is a great starting point.

Didn't read
by Andrea on Tue 26th Apr 2005 05:54 UTC

I admit that I didn't read too much from their website but imho FreeBSD is *not* that hard to install ( I mean it's a waste of time to me to develop a GUI installer, what's the difference from a text box style ? ) but it can be hard to keep it up-to-date (yes, I know some tutorials have been posted here) because I'd like something like debian's apt-get.

So I'd say: are you going to develop a user-friendly freebsd-desktop ?
Please first develop two simple commands, yes only two..., to upgrade the kernel and the packages.

Desktop
by dennis on Tue 26th Apr 2005 06:22 UTC

I love FreeBSD as desktop OS.. All my desktops are FreeBSD, and I would give PC-BSD a chance if they would have the choice to take GNOME. I don't like blinky blinky KDE @all.. :-)

Freesbie?
by Anonymous on Tue 26th Apr 2005 06:26 UTC

Seems that's BSD with automatic hardware detection and is now installable.

RE: time saver
by dennis on Tue 26th Apr 2005 06:32 UTC

I don't think so..

- Install FreeBSD [5.4] x-user or x-developer
- Reboot and insert the 2nd CDROM
- mount /cdrom and cd into it
- pkg_add -v gnome2-2.10.0.tbz [or KDE]
- Xorg -configure; cp /root/xorg.conf.new /etc/X11/xorg.conf

I've made an extra CDROM with packages like Firefox, you can make a repository with "cd /usr/ports/category/program; make package-recursive".

So within one hour I have a full funtional desktop with the programs I have chosen, which is in my eyes the power of free software.

After my desktop is up I just have to do "pkg_add -rv cvsup-without-gui; cp /usr/share/examples/cvsup/ports-supfile ~/; /usr/local/bin/cvsup ~/ports-supfile; cd /usr/ports/sysutils/portupgrade; make install clean; /usr/local/sbin/portupgrade -arR" and I go to town to have a beer.. :-)

Text Installer
by Daniel on Tue 26th Apr 2005 06:42 UTC

FreeBSD has a easy-to-use text installer and it detects your hardware like any other good Linux distro, but it seems some people don't understood that (graphical installer) != (easy to install).

I think the popularity of Ubuntu is a great example. Ubuntu does not have a graphical installer and it's one of the easiest Linux distro to install and run.

Maybe I'm not the only one, but when I was a Red Hat user (now I'm a NetBSD user), at the first versions with graphical installers, I always chose to install with a text installer.

What's needed...
by Smartjak on Tue 26th Apr 2005 06:56 UTC

This version of BSD just might be the thing I've been waiting for. It makes installing the system a breeze unlike my previous attemps which went by the wayside. Just too techie/geeky for me.

I've just installed PC-BSD. It zippier on my old test box then the Linux distros I've install on it but BSD does have a steep learning cruve. At least I know what I'm doing with Linux. And like the poster before, I too would prefer Gnome over KDE. God knows I've given KDE a good try but it's just not my cup of tea.

By the way, can someone point me to a HowTo for this OS? Something that will take me by the hand? How to install packages, add to the repository list, upgrade, etc? The sites for BSD tend to be a bit, er, to deep for this fair weather Linux user. Meaning I'm not a 'True Geek'.

This will give folks that have stayed away from BSD a chance to get their feet wet. Something like this is what is needed to make BSD more accessable to the public. Good show!

re"RE: time saver"
by Peter on Tue 26th Apr 2005 07:50 UTC

Thanks for the tip,a different aproach of installing.:-)I might adopt it (i think i will).

Good idea
by Dunceor on Tue 26th Apr 2005 08:08 UTC

This project is still a good idea because it helps attract users that would never look at *BSD.
It's sad it goes under GPL though and not BSD licence.

OT - FreeSBIE
by Anonymous on Tue 26th Apr 2005 08:27 UTC

does 1.1 install on SATA drives (AMD Shuttle)?

excellent
by Anonymous on Tue 26th Apr 2005 08:47 UTC

Good to show BSD is keeping up their end of the OS world and not letting all the nice looking *nix's goto Linux.

Unnecessary if that's all
by Johan Krüger-Haglert on Tue 26th Apr 2005 09:28 UTC

If this post is correct and that is all that differs it's unnecessary. The BSDs aren't hard to install, something doesn't have to be because it lacks a GUI, is it so hard to use arrow keys and return? Regarding the hardware issue the big three comes with a kernel with all drivers enabled to not necessary there either.

PC-FreeBSD
by mike on Tue 26th Apr 2005 10:21 UTC

The section explaining why they didn't base their product on Linux seems somewhat irrelevant, since they call it PC-FreeBSD, plus there are dozens of Linux distros aimed at desktop which means that nobody would really pay attention to them if they came out of another one.

My question is how are they going to handle binary packages? FreeBSD is great when it comes to ports, however resolving dependecies between binary packages isn't done by FreeBSD as far as I know. Correct me if I am wrong

RE: uhhh, no...
by Johan Krüger-Haglert on Tue 26th Apr 2005 11:13 UTC

"um...isn't Mac OS X a FreeBSD distrib with a graphical installer and automatic hardware detection?"

uhhh, no...

Lovely
by Anonymous on Tue 26th Apr 2005 11:21 UTC

Downloading it now and I've been waiting for this for quite some time. I do lack on the info page a clear version number ow what FreeBSD they're using. Is it 5.3?

Also the license is a big problem, why would they wanna choose the GPL for this when it is based on BSD. One of the big reasons to use BSD is to get rid of the stupidity of the GPL.

RE: Lovely
by Andrea on Tue 26th Apr 2005 11:34 UTC

> why would they wanna choose the GPL for this when it is
> based on BSD

Quoted from: http://www.pcbsd.org/license.html
<<<
All software custom developed for PC-BSD is released under the GNU General Public License, and may be downloaded from sourceforge.net.

The OS portion of the software developed by the FreeBSD team is released under the BSD License, and may be obtained from www.freebsd.org.
>>>

They are using GPL for their work because maybe they don't want others to use their work and ditribuite it with a closed distro.

just a thought

none
by joe on Tue 26th Apr 2005 11:42 UTC

just in case no one has posted it yet...

BSD ROCKS!

package dependency resolution
by itanic on Tue 26th Apr 2005 12:15 UTC

"My question is how are they going to handle binary packages? FreeBSD is great when it comes to ports, however resolving dependecies between binary packages isn't done by FreeBSD as far as I know. Correct me if I am wrong"

You are indeed wrong. FreeBSD handles dependencies for binary packages the same way they handle ports. A package is just a precompiled port.

@GAlain (IP: ---.244.81.adsl.skynet.be) -
by hammer on Tue 26th Apr 2005 12:23 UTC

IF they are not *similar* then DEC has no grounds to sue** Microsoft. **A deal was signed enabling Microsoft to access to DEC’s VMS related patents.

Refer to http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=4494

v Ugh
by Anonymous on Tue 26th Apr 2005 12:44 UTC
logo
by zupcis on Tue 26th Apr 2005 13:08 UTC

Nothing against them, but their logo is ugly

License Issues
by Kris Moore on Tue 26th Apr 2005 13:33 UTC

Hey all, just wanted to drop a line about what I see reguarding the GPL issue.

In all honesty, I prefer the BSD license, but in this case, the software i'm developing is written with QT, which I do not believe would let me release a BSD licensed version of the software, since I do not have a commercial license. Hence, my code will be GPL for now, but all the FreeBSD stuff is still and always will be BSD licensed ;)

RE: PC-FreeBSD
by dennis on Tue 26th Apr 2005 14:13 UTC

My question is how are they going to handle binary packages? FreeBSD is great when it comes to ports, however resolving dependecies between binary packages isn't done by FreeBSD as far as I know. Correct me if I am wrong

You're wrong. Once you do a "pkg_add -rv $some_pkg" you see it handles dependencies. ;-)

Good stuff kris
by AQ on Tue 26th Apr 2005 14:42 UTC

I say you run with it Kris. You will likely get more help with this project under gpl than you would under BSD. I really look forward to seeing this project progress. Good luck.

Re:
by chinhngt on Tue 26th Apr 2005 15:42 UTC

OK. The text-mode installer of FBSD is not too hard to use anyway. But a project like PCBSD is a good choice for newbees, after installing PCBSD, they can play with man pages, handbook , etc. for advance ;)

RE: Automatic hardware detection?
by Pedro on Tue 26th Apr 2005 16:01 UTC

FreeBSD is still a monolithic kernel..no plans to change that. Autodetection seems to work but I've always prefered to load the modules I know should be loaded.

RE: License Issues
by Gabe Yoder on Tue 26th Apr 2005 16:20 UTC

You are free to dual license your code. If you are releasing a binary linked against the GPL version of Qt, then you will need to have a GPL version of your source code, but you can additionally release a BSD licensed copy of the source code. Somebody who posesses a commercial Qt license would then be free to use the source and choose which license they wish to use.

RE: Lovely
by DonQ on Tue 26th Apr 2005 18:22 UTC

They are using GPL for their work because maybe they don't want others to use their work and ditribuite it with a closed distro.

Exactly why I don't like GPL. BSD people want others use their work:)

Despite license it's good news. More people will know about *BSD - and some desktop testing for FreeBSD won't hurt either;)

c'mon kde
by nivenh on Tue 26th Apr 2005 20:10 UTC

http://www.pcbsd.org/screenshots/PCBSDSS8.jpg

What the hell are the kde people thinking in that screenshot? 3d girl in a dress, fashion???

So I'm a bastard
by Anonymous on Tue 26th Apr 2005 22:04 UTC

So, I started writing a paper trying to be short about all the issues brought up here and why they weren't really issues at all, but after about 12 pages of pointing out that most people are stupid, I guess I shouldn't post that.

How about this then:

Don't design a new system, it's not needed, it branches the already slim support.

You want hardware detection, how's this sound. Make a script that reads the device IDs then looks them up in the ID chart then dumps the corrosponding driver name into a new kernel config file, recompiles your kernel, then asks you to reboot. Pretty straight forward, would probably take someone about 5 minutes to make.

Graphical installer? I second the statement "Using the arrow keys and pressing return is not that hard". If you can't figure it out, go someplace else, BSD is not for you. That a pretty good way to tell, I think. If you can't figure out how to install something, you aren't going to be able to use it either.

Packages installing/updating: KDE is already on FreeBSD install CD 1 you goobers, did you take the 30 seconds to look? Check the "packages" directory. Wow, complex, eh?
Ok, so I know people are baffled by how this guy plans to work with packages, and while I have no idea how he plans on it yet, I can tell you how you can do it in about 5 minutes, including the time it takes to write two perl scripts.


1)how will they handle ports and packages graphically?
Well, packages could be handled by loading the index file of the ftp site with the pre-compiled packages, run it through a script to get package names, set a simple GUI with radio buttons to be clicked for a specific package, then re-feed the package name to “pkg_add -r” so that it automatically handles all dependencies. Ports could be done in a similar way. Imagine the way they let you select options in the Kernel config thing in KDE used for linux and you’re probably about there.
2)........ upgrade software?
I would imagine much the same thing. As long as they keep a current build of every package in ports they can do recursive dependencies resolving on a binary upgrade... but that would cause problems in GUI form as soon as KDE needed to be upgraded. You’d either end up with the “reboot to upgrade” thing everyone hates about windows, or you’d end up dumping the user to the command prompt, during which time a script will run the upgrade program then relaunch KDE. Pretty simple really.

OK, so, I've just stated ways that you can do the "goals" of this system and make it so you aren't actually a pompous windbag: make a package to install with normal FreeBSD that gives these options, like the "portupgrade" package. Then, use your own machine to rebuild the ports collection once a week, and put the packages online, using your own space.

Doing that will take you about a week to get a full, functional, pretty little thing done. You won't be wasting your time, and you won't be pissing me off.

Good day sir.

I agree with the points, but not the final assessment
by AQ on Tue 26th Apr 2005 22:28 UTC

"Don't design a new system, it's not needed, it branches the already slim support."

But he is using the gpl... so it won't branch BSD devs at all.

If anything it would draw some gpl programmers from linux, of which there seem to be many, especially if you look at the amount of projects on sourceforge.

All BSD kernels, all Linux kernels, and the DOS, Windows 9x, and MacOS <9 kernels are monolithic kernels.

The Mach, HURD, Plan9, MacOS X (to a degree) kernels are microkernels.

What's the main difference?

In a monolithic kernel, all device drivers run inside the kernel, in the same memory space as the kernel, they are a part of the kernel. If a device driver causes a crash, the whole kernel (usually) crashes with it.

In a microkernel, almost all device drivers run outside the kernel, in their own memory space, and pass data back and forth. If a device driver crashes, only that driver dies. The kernel and other devices are not affected.

What you guys are talking about is modular kernels. Where one can load or unload kernel modules as needed. However, once loaded, they are a part of the kernel. There is absolutely no difference between a kernel with the ATA driver compiled into it, and a kernel with the ATA module loaded from disk.

The early Linux kernels were not modular, everything had to be compiled directly into the kernel. Around 2.0 or thereabouts, it became modular.

Not sure when the BSDs became modular kernel, or if they were like that from the start.

Re: So I'm a bastard
by phoenix on Wed 27th Apr 2005 00:06 UTC

I agree.

You want hardware detection, how's this sound. Make a script that reads the device IDs then looks them up in the ID chart then dumps the corrosponding driver name into a new kernel config file, recompiles your kernel, then asks you to reboot. Pretty straight forward, would probably take someone about 5 minutes to make.

I may be mistaken, but I'm pretty sure NetBSD has something like this.

An even better solution would be to have a basic GENERIC kernel on the install CD (just like now), and a very slimmed-down kernel for installing on the harddrive. In the installer, run through the dmesg output and figure out what kind of storage (ATA, SATA, SCSI), what kind of video, what soundcard, etc are in the system, and add the appropriate <module>_load="YES" lines to loader.conf to auto-load those drivers at boot time.

During the normal system boot, you run the same script and compare it to the existing loader.conf to see if any new devices need to be added, or any old ones removed.

Voila! Auto-hardware detection support. ;) Yeah, a lot of testing and whatnot would need to be done to be sure you couldn't hose your system, but you get the general idea.

1)how will they handle ports and packages graphically?
Well, packages could be handled by loading the index file of the ftp site with the pre-compiled packages, run it through a script to get package names, set a simple GUI with radio buttons to be clicked for a specific package, then re-feed the package name to "pkg_add -r" so that it automatically handles all dependencies. Ports could be done in a similar way. Imagine the way they let you select options in the Kernel config thing in KDE used for linux and you're probably about there.

There are several front-ends that already do most of this, like Barry (KDE frontend to the ports tree). None are completely finished, none support everything the ports tree can do, but it wouldn't take too long for someone to take these and finish them (or chuck them if the coding is too horrible to work with). They'd make good starting point and studying, though.

2)........ upgrade software?
I would imagine much the same thing. As long as they keep a current build of every package in ports they can do recursive dependencies resolving on a binary upgrade... but that would cause problems in GUI form as soon as KDE needed to be upgraded. You'd either end up with the "reboot to upgrade" thing everyone hates about windows, or you'd end up dumping the user to the command prompt, during which time a script will run the upgrade program then relaunch KDE. Pretty simple really.

Keep a separate package building cluster (FreeBSD packages are only built for releases or major security issues) and then use portupgrade -PP in the background to do the upgrades. ;)

This project would have been better as an add-on to FreeBSD, and not a complete re-packaging of FreeBSD under a different name. Create a better installer, then submit it to the FreeBSD Project. If it actually is better, it would be used. Create a meta-port or meta-package for giving you a GUI desktop from the get-go. Update the hardware detection and submit patches.

Would be so much simpler, and less work, than trying to create and maintain a complete OS.

Promissing
by Joe User on Wed 27th Apr 2005 00:47 UTC

That looks good. I think if they keep up the good work, they can attract a fair amount of people.
Good luck!

i686
by Andrea on Wed 27th Apr 2005 06:05 UTC

forgot to say:
beucase we are talkinga bout desktop why not distribuite an i686 optimized version ?

afaik, default is i486

@ phoenix
by Geert Hendrickx on Wed 27th Apr 2005 07:06 UTC

You want hardware detection, how's this sound. Make a script that reads the device IDs then looks them up in the ID chart then dumps the corrosponding driver name into a new kernel config file, recompiles your kernel, then asks you to reboot. Pretty straight forward, would probably take someone about 5 minutes to make.

I may be mistaken, but I'm pretty sure NetBSD has something like this.


Yes, see pkgsrc/sysutils/adjustkernel/DESCR:
Build a NetBSD kernel config file from dmesg output.

Suggestion to PC BSD
by Anonymous on Wed 27th Apr 2005 11:07 UTC

One thing I noticed during installation which they should fix is when you choose what Slice to install PCBSD to. It didn't offer me to change the size of the slice which was available. Like I had a 20gig slice, I really wanted to only use 10gb but PCBSD only offered me to use all.

This is something that ought to be fixed in the installer.

Also FreeBSD bootmanager didn't allow me to offer XP as an option when rebooting. It offers that partition but XP doesn't boot. What is wrong with the BSD Boot manager? Can someone help me to fix this?