“PC-BSD version 0.8 is now available! A lot of effort went into improving this version, and many thanks is due to all the people who have tested and provided valuable feedback on our support forum. This version now adds the Online Update Manager, along with many other fixes and enhancements. For a complete list of changes, please refer to the changelog.” Release notes are here, download locations here. The various documents disagree with one another on whether or not this is the final or beta release.
Well, it says 0.8 beta, so I would imagine in keeping in line with the other releases, 1.0 would be a “final”, and anything under that is beta.
The more and more PCBSD develops, the more it seems to be suited to my needs. I juts wish this was the “firefox” of open-source OSs. I am going to give it a try!
I have tried PC-BSD and like it a lot, the only isue I have is with the PBI package format. I’m wondering how many develpers will take time to create PBIs. I think it will be upt to PC-BSD community to create and update PBI which means it will be slow and coming for most apps to be in PBI format and to be kept updated.
I wish all these *nix distros would realize that Apple has the best solution for installing apps. They need to start using an AppDir that a single folder that has all necessary files & dependencies for the app and so that installation is as easy as drag and drop.
Given the momentum PC-BSD is gaining, I guess the number of available PBIs is bound to grow pretty fast…
But in any case, PBIs aren’t meant for advanced users: there are FreeBSD ports for those ones, and they’re already available on every PC-BSD system, right under the hood.
http://www.freebsd.org/ports/index.html
If you wish you can mix them, and install some apps from PBIs, some other apps from ports.
Yeah, I realize I can install apps from ports, but then I have apps that get installed in one place with PBI and apps that get installed in another place with ports. This make me feel less in control of my system.
It would be nice if just the OS updates were handled with ports and all other apps were installed in /programs directory with PBI or similar.
*I* wish all those mac-heads out there would realize that mac isn’t the crown of creation, the mac way isn’t necessarily the best way, and that the mac way have *serious* problems as well.
For instance, “all necessary files & dependencies for the app” means a *lot* of redundant code on your disk. This means if you have a security issue in a common lib you’ll have to patch each and every fucking application that brings along its own copy of this lib. *This is _BAD_*.
It also means you lose control over what’s exactly on your disks. *This is _BAD_*. If you want to dispute it, you’ll first have to tell me how many got hit by slammer because they had no idea whatsoever that they had a version of ms-sql running on their system. Then you are allowed to say that this is no problem. If you can do it with a straight face, that is..
I prefer to be able to decide where my applications are installed and be able to remove an application easily without breaking other applications, which is why I think PC-BSD is headed in a good direction.
I also think that systems like Ports and Apt are great for updating the OS, but I don’t think thay are good for the general installation of applications. Sure they work, but you don’t get much control over the installation process. I think a separate system is needed. I do think that Apple has the most flexible and simple solution, and it just works.
The redundancy in dependencies that you mentioned is not that big of an issue. Disk space is very cheap and disk space can also be saved with compression and on the fly decompression if that is such an issue.
As a matter of fact ther is already a project called Klik for debian that uses serverside Apt to generate a compressed AppDir image that when clicked on is mounted and the application is run. This makes installing applications as easy as possible, just download, put it where you want it and click. These type of projects will be what attract more users to *nix.
How about replying to what I wrote? I didn’t even mention diskspace.
And BTW, you aren’t allowed to say it’s not a problem, you didnt give the number..
Actually the FreeBSD Ports system gives you lots of control over installation. Check the man file for ports.
Yeah, I’m sure it does but there are plenty of casual computer users who don’t have time or don’t want to read through mind-numbing manuals just to be able to change the location of where an application is installed. This is why we need projects like PC-BSD, not everyone has the knowlege and endless amounts of time to tweak their systems to high heaven.
I’m hoping as PC-BSD matures they will address these type of issues, since the larger Linux/BSD community seems to be OK with the status quo and all the difficulties that come with it.
I also think that systems like Ports and Apt are great for updating the OS
*What* about the FreeBSD OS is handled by ports? Answer: none. Ports is strictly for external applications, not for the FreeBSD kernel or userland. For OS upgrades, use CVSup or a binary update service such as http://www.daemonology.net/freebsd-update/
In fact the whole distinction between ports and OS/userland is exactly why FreeBSD is such a great, stable platform. Kernel and userland tools are kept sychronized throughout the lifetime of a release, without needing to fiddle with individual packages. It is an atomic operation (well, at least atomic if you don’t shutdown in the middle of a userland or kernel update).
As for the relative merits of PBI/Ports, it really depends on how intimate with your system you want to be. This is why PBI is great for novice or desktop users (PC-BSD’s intended audience), while ports is great for those with more serious needs, or who want to maintain a synchronized farm of workstations or servers. The fact that you can do both with PC-BSD is a nice bonus.
The mac way is the mac way… Every system has it’s problems. I never had or heared of a dependecy problem in a mac that’s for sure.
Placing all the files of a program in a self contained folder does add a *lot* of redundant code on your disk. This means if you have a security issue in a common lib you’ll have to patch each and every application that brings along its own copy of this lib to be sure you are imune to it. On the other hand, the PBI system also aims to pass the responsability of app maintaining to the app creators and maintainers, which translates to this: Whoever makes an app must be responsible for it. The app creators are the ones who must maintain their work, not the OS developers. Most apps have auto update features these days for this reason. Of course, it’s easyer to update 1 file. There are other ways to answer this problem being thought out. (if you have any ideas other linux os’s dont approve come to PC-BSD forum and tell us about it. we like mad non working schemes)
The mac way is the mac way… Every system has it’s problems
Exactly the point I was trying to make. Which means the mac way isn’t as ideal as some would make it sound. “I wish all these *nix distros would realize that Apple has the best solution[]..” blah, blah.
On the other hand, the PBI system also aims to pass the responsability of app maintaining to the app creators and maintainers, which translates to this: Whoever makes an app must be responsible for it. The app creators are the ones who must maintain their work, not the OS developers.
I’m sorry but I disagree with that. What you effectively do IMO is passing the buck to the end-user, who has to keep watching the app creators and maintainers to make sure they are sufficiently patched up. We all know how well that works in real life, don’t we? The only way around this is if there is a central repo for these pbi’s, and if that’s how things are supposed to work, I fail to see the point with it compared to a conventional repo.
if you have any ideas other linux os’s dont approve come to PC-BSD forum and tell us about it. we like mad non working schemes
nah, you’ll have to sort out your own mess.
I hope it doesn’t come off like I’m bagging the etire idea, that wasn’t the intention. I’m sure it’s a good idea, for some users, in some circumstances. But claiming “the apple way” is the ultimate solution and everyone else should drop what they are doing, like the inital poster did, is going way too far.
Hmmm… As PBIs are self-contained apps, like Mac AppDir, it would be cool to have a kind of right click option “Launch this app” without having to install the program. Great for testing purpose 😀
Ok, one would have Ports + pkg_add + PBI installing the “Windows-like” way + PBI able to run the Mac way = more choice or more headaches ?
I prefer the Apple way, who cares about all the empty code lying around.
Its up to the apple creator to maintain his or her app not the end user cos’ most ‘normal’ people do not want to spend hours on the internet finding a stupid lib file and working out how to install it.
A central database system is also good that why i like the Debian way also (as well as freebsd etc and other similar ways).
But i never had any problems with the apple way whatsoever. Nope its not perfect but we all remember the depenacies problem baby linux had dont we?
but the old “let the end user worry about it” idea is gone.
Yes, but the Apple way sucks really hard when it comes to updating the other 50 apps you installed yourself. Remember, only the OS and apps pre-packaged from Apple can be updated via Software Update…
Yeah but most apps today have a software update feature built in.
However OS X does have like a database to know what progs it got installed so it would only take some clever coding and an open central server to make this happen so everydone done via software update.
>Yeah but most apps today have a software update feature built in
Yes, a totally pointless and often annoying feature which then means that I would have to start up each of those 50 apps to see if there’s an update available, and that usually means that the product webpage opens in Safari with a download link to the new version that I then have to download and install, gets quite tedious after a while…
Then there’s apps like acrobat reader and the like, where the built-in auto-update lets you download security fixes but not update to new (as in major) software versions.
>However OS X does have like a database to know what progs it got installed so it would
>only take some clever coding and an open central server to make this happen so
>everydone done via software update.
You do realize that this “database” (I guess you mean the “/Library/Reciepts/PackageName.pkg/” directories) only gets added to when you install software that uses Apples own installer…
No, updating the software in /Applications on my Mac is a royal pain in the a**.
I wish that all Mac software could be installed from Darwinports instead, “sudo port -a upgrade” is a 1000 times better and a LOT less manual labor involved
On the spot!!!
it is very usefull for those who finds the installation FreeBSD difficult and who wants to try FreeBSD/BSD as well for those wo wants to migrate from Linux to FreeBSD.the installation is easy cake and it is fully supported FreeBSD just update your ports tree and enjoy the beautiy,security,stability of FreeBSD.just try it!by the way,once you try FreeBSD,OpenBSD,NetBSD i mean any of them,you will never go back again,mark my words!it is same in Linux world Slackware users know this,once you try Slackware,you won’t use any other Linux distro again ;=) have a nice day!
alot of you are whining that the pbi’s should be more like how mac is. If thats true then there goes linux, since we all know the fueds that go between each distro on which is better and which isnt. It matter if it suits your needs and frankly i find that pbi’s and ports is a good thing to have at the same time. Something like using emerde on slackwere so that way you could use gentoo based way or slackwere based. Lets see how many other distro out there allow you to have 3 three differnt ways to install, since pcbsd uses ports, package add and pbi’s. easier to find something in a hurry
I have been testing this OS since v 0.7 (0.7.5,0.7.8,0.8) and I have found that It has some serious hardware detection problems, It was unable to recognize my Drive 100 GB but was able to recognize a 6GB HDD; when I have entered into manual partitioning the program nagged from the CHS value of the drive and told me to enter geometry of my BIOS which I did( the valuse of the BIOS was: 47885/16/255: the value the partitioner keeps insisting on was: 12161/255/63).
I tried to use different HDD access methods like CHS, LBA, LARGE DRIVE all failed and I was not able to install the OS to the HDD. Keep in mind that the HDD is not defective because I ran almost 10 different OS on with no hiccups; I even retured back to Xandros. Anyway I believe that till now we do not have a real decent true UNIX OS available as an alternative to Windows or Linux on X86. I have tried Sun Solaris 5.10 for x86 and It was like 1990 nagging about the monitor resolution and its dimention. I have tried FreeBSD 5.x also which with its installtion is like the pain you will have when installing debian.
Even YellowTabs Zeta 1.0 was light years ahead of these Unixes when installing them on x86 hardware.
You might ask why do I need to install a UNIX OS while we have a lot of linuxes; I would say the stability is the reason. I could get any linux OS to freeze unless you reboot by just inserting a defectively burned CD/DVD, and I could not tolerate this on my workstation while I am running important tasks on the backgroud video editing, graphics design and internet downloading which all you will loose if you reboot. Zeta 1 and OSX on x86 do not make such a mistake.
Maybe we will need to wait for the final version to rule out these bugs.
You might ask why do I need to install a UNIX OS while we have a lot of linuxes; I would say the stability is the reason. I could get any linux OS to freeze unless you reboot by just inserting a defectively burned CD/DVD, and I could not tolerate this on my workstation while I am running important tasks on the backgroud video editing, graphics design and internet downloading which all you will loose if you reboot.
This is pretty much misleading information. A defective CD crashing a Linux system is a unheard of thing.
Are you talking about this out of your mind or out of your experience. I really crashed all kind of linuxes (Xandros 3.0.2 BE, Novell SUSE 10 beta 3, Redhat Enterprise linux 4 WS) on at least 2 desktop computers and I was very sad about this because I thought that nothing on earth could crash linux and that linux is better than any other OS out there in device crash handling. Some extra info about the badly burned DVD-ROM : Dirve- Sony DVD+RW 700 series using Nero Burning ROM 6.6.0.2 using windows XP SP2 using UDF as file system.
That way I got 10 corrupted DVD where you can see physically by your eye a circular band inside the burned area ( the burned area on a DVD is of different color than the unburned areas, so I think the burner didn’t burn few sectors while doing the job)
Still I say it I was shocked with this fact and now I am more sad after all that time I spend trying to shift my platform to linux. I want to tell also that I was able to burn the same DVD with the same drive but on Xandros 3.0.2 using “nerolinux-2.0.0.2-x86.deb” and the DVD didn’t have any corruption.
What PCBSD lacks most is hibernate/suspend to RAM feature.
Given the excellent OS FreeBSD is, this feature can add to its adoption as most new home computers are Laptops.
This is my real reason of sticking to gentoo.
It has FreeBSD ports like package manager and the goodies of Linux.
Abhay
To the people discussing the burden of creating PBIs: wouldn’t it be great if there were a simple script to build PBI packages using the existing Ports system? I bet it’s feasible.
To the poster discussing the use of Ports and PBIs simultaneously, who also disusses Gentoo’s and Slackware’s package management framework: What happens if you uninstall a PBI that contains the same library (for instance) required by an application compiled from Ports? Do PBIs necessarily install in a directory hierarchy separate from the /, /usr, /usr/local, or /opt hierarchies?
If you like Gentoo and Slackware’s package management and wish you could have the best of both worlds, you should try Arch Linux. Between Pacman and ABS (Arch Build System), it’s basically the Linux analogue of PC-BSD, except you can build packages from ABS really easily.
To the guy who implied that Ports is difficult because it makes it harder for the casual user to change where an application is installed: First, the casual user should be allowed to change this easily, it’s in the best interest of a stable, upgradable installation to have applications installed in a uniform manner. Second, it is usually a lot easier to modify the installation directory with a build system like Ports than with a package tool. I don’t know how PBIs extract onto the filesystem so I can’t comment on that specifically, but ‘make –prefix=/opt install’ is an example of how to do this with Ports.
Overall this looks like a good project with some potential.
How do PBIs affect dynamic linking?
What I have in mind is that one of the merits of dynamic linking is, that each library is loaded in RAM only once, even if used by multiple executables. This saves both starting time (no need to load the library) and RAM (RAM not used by running processes can be used for file cache -> worth saving it).
Now with PBIs, you will have multiple copies of the same library on disk. e.g. /opt/app1/lib/libfoo.so and /opt/app2/lib/libfoo.so. How will the dynamic linker react to this – will it know that /opt/app1/lib/libfoo.so and /opt/app2/lib/libfoo.so are actually the same code and could be loaded into RAM only once?
If not, then PBIs not only waste disk space (cheap), network (arguably cheap in some places), but also RAM (never cheap, as it could be used for better purpose, e.g. file cache). If yes, how does it work?
Also, how is the linker’s search path set up? does /etc/ld.so.conf* include all /opt/*/lib directories?. If so, then running app2 could result in loading a library from app1’s directory. That should be OK, but sort of defeats the “self-contained application” model. If /etc/ld.so.conf only includes system directories, do you set LD_LIBRARY_PATH for each application separately (trough a wrapper)?
Having a library multiple times on the disk (and in RAM) sounds a bit backwards to me. People did not invent dynamic linking and packaging systems (such as apt) for no reasons….
* I am not sure /etc/ld.so.conf is call that way on *BSD, but on Linux, it tell the dynamic linker in which directories to look for libraries.
p.s. site coders – any chance of allowing the [tt],[/tt] tag in comments? Would have been useful now, I had to resort to using italics instead of monospace for file names.