The FreeBSD operating system is the unknown giant among free operating systems. Starting out from the 386BSD project, it is an extremely fast UNIX-like operating system mostly for the Intel chip and its clones. In many ways, FreeBSD has always been the operating system that GNU/Linux-based operating systems should have been. It runs on out-of-date Intel machines and 64-bit AMD chips, and it serves terabytes of files a day on some of the largest file servers on earth. Elsewhere, here is a guide to PC-BSD.
Thats not a guide to PC-BSD, PC-BSD is meant to be simple by design, he’s doing everything via Bash scripts and Ports, instead of downloading all the scripts why not use the PBI’s that are available?
Configuring networking, if you have a DHCP Server on your network, theres no need to configure your network connection, sure in other cases this may be required, but I’m sure Kris and others will be working on GUI based Network configuration.
This ” Guide ” looks more like a guide for standard FreeBSD opposed to PC-BSD, you could argue its for power-users but then you wouldn’t need a guide as the system is extremely simple to use.
Thats not a guide to PC-BSD, PC-BSD is meant to be simple by design, he’s doing everything via Bash scripts and Ports,
Perhaps not a guide suitable for everyone,but it’s still a guide,which shows clearly you don’t have to suffer any configurabillity while using PC-BSD.
Well done!
True, if im honest I am biased towards PC-BSD, as I am an avid user of the OS, and I enjoy its simplicity, and I find my self slightly disgrunted with the guide as it ignores PBI’s completely, this is mainly due to the fact I myself have spent many, many hours producing PBI’s for PC-BSD
Is there a website that compares between PBI, Ports, and Pkgs?
Wow, IBM is talking about BSD.
I’m quite as shocked as you are. Maybe even more so.
Actually its not IBM, but someone who contributed to devworks. You can tell by the by-line.
“FreeBSD is just as slick and fast when run on laptops”
Can anyone comments about ndiswrapper on FreeBSD? I believe FreeBSD has had support for it since 5.3??? How robust is it?
Thanks.
Cheers
Well, with my RealTek 8180 WLAN NIC, ndisulator works better then both ndiswrapper and the open source driver from a project for this chip on sourceforge.
I myself have spent many, many hours producing PBI’s for PC-BSD
Those PBI’s makes PC-BSD usefull and atractive for a broader audience,without sacrificing any of FreeBSD’s strength:-)
> Those PBI’s makes PC-BSD usefull and atractive for a
> broader audience,without sacrificing any of FreeBSD’s
> strength:-)
Maybe they do, BUT:
– they have nothing to do with BSD; it’s actually very easy to link Linux or Solaris apps statically against zlib, put them into an archive (deb, rpm, tar, whatever) together with a copy of libpng and jpeglib and call this an “innovation” that “resolves dependencies” (actually, every software for Microsoft Windows has been packaged like this for years)
– they are very convenient at install time just like the famous user-friendly Microsoft Windows SETUP.EXE, but they are very inconvenient and hard to maintain later because they need to be checked, patched, installed over and over again in the case of a library security leak or any other sort of bug
Therefore: Yes, these PBIs are exactly what makes PC-BSD so useful and attractive, and they are exactly what people who don’t understand UNIX deserve.
that’s the idea i guess. But as mentioned on that guide?review? md5 checksums aren’t used yet. This should be aken care asap before smeone gets into trouble…
I have tried PC-BSD (being a Linux user myself) and i have to say i am impressed. The install is a breeze and the OS feels solid and fast. Is there a Gnome version planned? Personally I prefer Gnome (Disclaimer: please read “personally” – i do not intend to start a KDE/Gnome flamewar and am purely talking about a personal preference). I also like the fact that packages get installed with all the necessary libaries, so that it is easy to install and remove software without breaking sth. else … i guess this will make it also easy for third parties to package software. I will certainly keep my eye on this one and might use it more regularily in the future … as i said very impressed, keep up the great work.
You can always use ‘pkg_add -r gnome2’ beacuse PC-BSD is based on FreeBSD. Then configure X to start Gnome instead of KDE.
Please, consider it as a work in progress. There is currently no internationalization at all. No way to set keyboard layout from the installer, which is very painful. Also, if you’re using a laptop, please disable KDE automatic activation of num lock.
(I’m asking because PC-BSD’s installer consistently hangs on all three of my boxes)
Is the PC-BSD packaging system aware of the standard FreeBSD ports/packages system… as in, if I install something using the PC-BSD packaging system, and then do “pkg_add -r somepackage” does the already installed software count towards any dependancies that somepackage requires, or are you forced to essentially install the same packages twice?
> Is the PC-BSD packaging system aware of the standard FreeBSD ports/packages system…
No, at least not at the moment. I think you should use pkg_* tools anyway as you seem to be user who knows more than avarage person who comes from windows environment.
I’ve been using Linux (Debian) and FreeBSD–both are pretty nice for servers.
I’ve stayed with FreeBSD 4.x because it just works. I think a lot of the conservative admins (like me) stayed away from 5.x because we considered it more of a development branch.
With FreeBSD 6.0 coming out shortly, I’ll probably begin trying it out on test servers and upgrade when FreeBSD 6.1 is released.
True if a security problem with a library in theory all applications using that library need updating. Thats why I and some others in the PC-BSD community proposed a Library DB to be linked to the PBI system, which would log what applications that are installed use what libraries making updating them easier and make sure Applications cant be broken through accidental file removal.
I mentioned it in a different thread (under different article) and it did not get answered. Now that I see someone involved in that matter is here, I’ll ask again.
If I understand PBI correctly, if two applications use e.g. libfreetype.so, you would end up with two copies of libfreetype.so on your system.
1) What is the content of /etc/ld.so.conf (or the equivalent in PC-BSD, in case it is called differently than on Linux) or LD_LIBRARY_PATH? Does it include each library directory of each PBI installed?
2) If so, how does the dynamic linker react to this? If I had “foo” and “bar” installed through PBI, I expect I would have:
/usr/local/MyPrograms/foo/
and
/usr/local/MyPrograms/bar/
I also assume there would be “lib” (or equivalent) subdirectory in each of them. Both “foo” and “bar” include libfreetype.so, so it would be present in both directories. If /etc/ld.so.conf or LD_LIBRARY_PATH includes both /usr/local/MyPrograms/foo/ and /usr/local/MyPrograms/bar/ (with foo coming first), then running “bar” would result with libfreetype.so being loaded from /usr/local/MyPrograms/foo/. I just checked on my system, “gaim” is linked against libfreetype and references libfreetype.so.6. Hence, if the versions for “foo” and “bar” differed in the minor number only, then bar could be running with the wrong version of libfreetype.so. Am I right, or have I missed a detail?
3) Assume I was wrong in 2) and through some magic, each application has LD_LIBRARY_PATH set in a way that it references only the correct directory and the correct libfreetype.so would be used. If there were the exact same copies of libfreetype.so /usr/local/MyPrograms/foo/lib and /usr/local/MyPrograms/bar/lib and both “foo” and “bar” are running (with different LD_LIBRARY_PATH) – is there just one copy of libfreetype.so loaded in memory, shared by “foo” and “bar”, or are there two separate, one for each of the processes?
4) If libfreetype.so is considered a system-wide library installed in /usr/lib – where do you draw the line between “system-wide” and “application-specific” libraries? PCBSD comes with KDE. Imagine I will download Evolution, which would bring the whole pack of GNOME libraries. Then I will download Epiphany – will I get the whole pack of GNOME libraries again?
note by: I don’t want to flame about the merits of PBI, I’m genuinely curious. I only have experience with Linux and have a rough understanding of dynamic linking. I might be missing some details. And the linker might be different on *BSD.
I’ve considered installing and trying out FreeBSD or NetBSD numerous times, but there are a few things that always turned me away. One, that is present in both FreeBSD and NetBSD is the naming of network interfaces.
The FreeBSD handbook says:
FreeBSD uses the driver name followed by the order in which one the card is detected at the kernel boot to name the network card.
Why is it like that?
Imagine I have a card, which is called dc0. I can live with the fact it’s not eth0
. However, it dies and I get a new one from my spare supplies. It has a different chipset, so it is handled by a different driver and is called sis0. Now I have to go somewhere /etc and replace all occurences of “dc0” by “sis0”. Not nice. What if the said computer was headless?.
On Linux, having one supported ethernet card installed, it would be always called “eth0”. Swap hardware, no configuration to change. (Yeah, they blew this by having wlanX, ethX, athX, etc for WiFi cards. Not nice either – it ticked me off, when I was trying to get WPA 2 running at home and was switching cards to localize a problem).
The other thing that turned me away from NetBSD was the naming of disk partitions. However, judging from a quick view in FreeBSD install notes, FreeBSD seems to have it defined in a sane way.
You dont like it?..
change it..
root@book ~> ifconfig bge0 name eth0
root@book ~> ifconfig eth0
eth0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
options=1a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING>
ether 00:11:d8:6f:30:31
media: Ethernet autoselect (none)
status: no carrier
Thank you for the example.
FreeBSD uses the driver name followed by the order in which one the card is detected at the kernel boot to name the network card.
“Why’s it like that”, you ask. Well, that’s the way it’s done in Unix operating systems (keep in mind that BSD originated from AT&T Unix itself – it maintains alot of the traditions). I guess perhaps it’s also done that way out of tradition. Solaris does the same thing. I think under Solaris (x86) the BSD fxp driver is known as iprb (or something similar to that, I have forgotten exactly what it was). The point being, that’s just the way Unix does it.
It might seem wierd at first, but probably just as weird as it is for me in Linux trying to figure out why my fxp card hasn’t be initialized, then trying to figure out how I know if eth0 is fxp (eepro or whatever under Linux, fxp is just what I’m used to knowing it by). Evenutally, you’ll get used to the BSD network device naming convention. It ends up making alot of sense.
Now, as far is your issues with scripts under /etc. Well, let’s say you’re setting up a firewall. Typically, you would use a macro (for instance when using pf as the firewall) so that the outside interface is fxp0 and the inside interface is fxp1. The rest of the firewall script uses those macro names instead of the real device name. If your devices change, you only need to change one spot on on the firewall script. It’s not that big of a deal.
I can’t think of many other places in /etc where you would need to reconfigure things other than maybe if you have a DHCP server or your /etc/rc.conf file for network configuration. I’m sure there are other places too, but you’re making a big deal out of nothing.
Oh, I think under FreeBSD 6.0 you can actually change the name of the network device (like giving it an alias name) but don’t quote me on that. Lately, I’ve been too busy playing with DragonFlyBSD and not paying as much attention to FreeBSD as I should.
Thank you for the answer. SO, it is Unix heritage.
Of course one can get used to it. I was just curious.
as it is for me in Linux trying to figure out why my fxp card hasn’t be initialized, then trying to figure out how I know if eth0 is fxp
Look into dmesg – the drivers, when loading, would report which device name they took. And it happens in a deterministic way, so you can be sure it will be the same after the next reboot.
If you load drivers “manually” through /etc/modules – the order in this file decides it. If more cards are handled by the same driver, their PCI id would decide (probably the same in *BSD). I’m not sure about hotplug, but I guess it would walk the PCI bus one by one, hence would decide by PCI ids which module to load. HTH.
If I understand PBI correctly, if two applications use e.g. libfreetype.so, you would end up with two copies of libfreetype.so on your system.
Yes in the present PBI system you will end up with 2 copies, and this is not a desirable situation to have.
And yes Gnome applications with both each have a copy of all the required lib’s.
This is one reason for wanting a Library Database, which records library locations so other app’s can use them, and make sure that when a program is uninstalled it doesnt remove those libs if they are still required by an application
Can you please comment on the dynamic linking issues?
Or is you answer hidden in “and this is not a desirable situation to have” ?
a Library Database, which records library locations so other app’s can use them, and make sure that when a program is uninstalled it doesnt remove those libs if they are still required by an application
Sounds very much like dpkg’s (or rpm’s) installed packages database to me. The difference being, your Library Database only handles libraries.
Is there a 64-bit version of PC-BSD (for the AMD Opteron)?
Dynamic linking, when creating PBI’s there are 2 options…
1) specify a Library Folder (Statically linked lib’s in side the application folder… self-contained)
2) using standard libraries (dynamically linked from /lib, /usr/lib, /usr/share/lib, etc… semi-self contained)
so dynamic linking is possible, but then you end up with the questions… which libraries do i leave? what libraries is it safe to remove?
So libraries in PBIs are statically linked with their respective binaries? Maybe it makes more sense the opposite way: So binaries in PBIs are statically linked with their respective binaires, but the result is the same.
If my memory serves me well, statically linked libs would not be shared in memory. So if I ran e.g. gnome-terminal and Evolution, I would end up with all GNOME libraries twice in my RAM? Ouch
Yeah, why would someone run a GNOME program on a KDE system. I just picked GNOME as a prime example of something, which would not be in the base install, hence distributed through PBIs and has a lot of libraries involved.
If you read my first post, the long one, I went thinking on how the link would behave, if you had dynamically linked libraries in PBIs. I hoped for an answer on that.