Linked by Thom Holwerda on Fri 5th Oct 2007 20:49 UTC, submitted by Flatland_Spider
PC-BSD Jan Stedehouder has used PC-BSD for thirty days to see what living with it is like. On day thirty, he concludes: "Does PC-BSD have the potential to be a serious contender for the open source desktop? I answered that question with a yes, because the potential is there. The solid FreeBSD roots, the very strong and very accessible information, the friendly and mature community and the PBI system provide the foundations for that potential. I don't think it is ready now and I couldn't recommend it yet to someone in the early stages of moving away from Windows to an open source desktop. But I do think that the PC-BSD team has the right target audience in mind and is building an system and a support system that addresses it's needs."
Thread beginning with comment 276506
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Package Management
by zombie process on Sat 6th Oct 2007 17:36 UTC in reply to "RE[4]: Package Management"
zombie process
Member since:

How does that solution resolve, say, library version issues? Personally, I think that all inclusive bin files probably *is* the solution - yes, there are certain security caveats, but for 99% of the people out there, fscking around with dependencies is a nightmare.

Most people want to be able to install software that is meant for "their OS" w/o having to compile or fight with their package manager - even very intelligent people with decent tech savvy have issues with this kind of thing. Right now, it's extremely difficult for me to explain to people who run linux part-time that, no, you cannot get that rpm and expect it to "just work" on your ubuntu box, or whatever. It's kind of a mess whether we want to admit it to ourselves as uber-1337 g33x or not.

Reply Parent Score: 2

RE[6]: Package Management
by dylansmrjones on Sat 6th Oct 2007 18:54 in reply to "RE[5]: Package Management"
dylansmrjones Member since:

How does that solution resolve, say, library version issues?

Hmm... we could store dependency information in one or more text-files included in the installer, put them somewhere sane (if possible with that crappy FHS) and simply let the installer download installers for missing dependencies. In regard to reverse dependency resolution we could have a dependency counter (think semaphore or memory management in non-managed languages) and when the counter reaches 0 there is no packages depending on it. Removal would be safe (except for packages compiled by the user outside the package management).

In order for packages from one distribution to work on another we need at least two things:

1* A common package format (or at least ONE common installer format, or at least ONE open standard for this task)
2* A common binary installation (LSB is a step in that direction, I guess - at least for Linux)

#2 is what pretty much kills this idea for GNU/Linux.

Reply Parent Score: 2