Linked by Thom Holwerda on Tue 24th Oct 2006 10:20 UTC, submitted by Joel Dahl
PC-BSD "iXsystems is a leading provider of high-performance computing clusters, blade servers, rackmount servers, and storage solutions based on FreeBSD, NetBSD, OpenBSD, and Linux. iXsystems also recently announced its acquisition of the PC-BSD operating system. I had the opportunity to interview Kris Moore, founder and lead developer of the PC-BSD project, and Matt Olander, CTO of iXsystems, about the acquisition."
Order by: Score:
Oh, wow...
by Wowbagger on Tue 24th Oct 2006 14:04 UTC
Wowbagger
Member since:
2005-07-06

Completely self contained apps with no dependencies? This guy is seeing the light, I'd say... albeit a Mac/NeXTSTEP light this is...

Reply Score: 4

RE: Oh, wow...
by Blackhouse on Tue 24th Oct 2006 14:10 UTC in reply to "Oh, wow..."
Blackhouse Member since:
2005-07-06

yeah, actually I don't understand why this isn't done in more OS's. Shared libraries are nice, but now we have 100 of gigs of harddisk space, why bother? It only leads to library dependency problems and makes your OS less flexible.

Reply Score: 3

RE[2]: Oh, wow...
by Isolationist on Tue 24th Oct 2006 09:23 UTC in reply to "RE: Oh, wow..."
Isolationist Member since:
2006-05-28

"yeah, actually I don't understand why this isn't done in more OS's. Shared libraries are nice, but now we have 100 of gigs of harddisk space, why bother? It only leads to library dependency problems and makes your OS less flexible."

What about precious RAM for a start? ;)

Reply Score: 2

RE[2]: Oh, wow...
by elvstone on Tue 24th Oct 2006 14:56 UTC in reply to "RE: Oh, wow..."
elvstone Member since:
2005-09-08

Apart from RAM usage as suggested by the other poster, there's always the issue with security. What if there's a vulnerability in a library used by X packages, then you have to upgrade X packages instead of just one.

PC-BSD looks nice though, eventhough I think I'll continue using plain FreeBSD it's interesting to see.

Aron

Reply Score: 3

RE[3]: Oh, wow...
by jmansion on Tue 24th Oct 2006 15:21 UTC in reply to "RE[2]: Oh, wow..."
jmansion Member since:
2006-02-20

The flip side is that you have to regression test X packages before you can upgrade the shared library to fix any of them. Or have several versions and be selective as you complete testing. Its pretty painful however you cut it, you just have to do an impact and risk analysis.

Reply Score: 2

RE[4]: Oh, wow...
by danieldk on Tue 24th Oct 2006 16:23 UTC in reply to "RE[3]: Oh, wow..."
danieldk Member since:
2005-11-18

No, usually this is not necessary. Suppose that you are fixing a buffer overflow or off-by-one in a library, this (normally) has no impact on the API. So, most programs will continue to run correctly.

Yeah, if you introduce a new version of a library to fix a security bug, things will fail.

Reply Score: 2

RE[3]: Oh, wow...
by Doc Pain on Tue 24th Oct 2006 16:15 UTC in reply to "RE[2]: Oh, wow..."
Doc Pain Member since:
2006-10-08

PC-BSD looks nice though, eventhough I think I'll continue using plain FreeBSD it's interesting to see.

I'll do the same.

Aahm... what's happening... I'd line iXsystems to check several (unnecessary) open TCP and UDP ports (139, 445, ipp, syslog etc.)... that would be great. :-)

Reply Score: 2

RE[4]: Oh, wow...
by antik on Tue 24th Oct 2006 17:29 UTC in reply to "RE[3]: Oh, wow..."
antik Member since:
2006-05-19

Aahm... what's happening... I'd line iXsystems to check several (unnecessary) open TCP and UDP ports (139, 445, ipp, syslog etc.)... that would be great. :-)

What open ports? This is my PC-BSD 1.3B1 firewall and I selected only port 22 (SSH) for connectivity in installer- by default all ports are closed. Of course you can open/close your favorite ports if you wish.

# pfctl -sa
FILTER RULES:
scrub in all fragment reassemble
block drop all
pass out inet proto icmp all icmp-type echoreq keep state
pass on nve0 proto icmp all
pass out on nve0 proto tcp from (nve0) to any keep state
pass out on nve0 proto udp from (nve0) to any keep state
pass in on nve0 proto tcp from any to (nve0) port = ssh keep state
block drop on nve0 from <blacklist> to any
No queue in use

Edited 2006-10-24 17:36

Reply Score: 1

RE[5]: Oh, wow...
by Doc Pain on Tue 24th Oct 2006 17:44 UTC in reply to "RE[4]: Oh, wow..."
Doc Pain Member since:
2006-10-08

What open ports?

This is a TCP / UDP report about the PC-BSD machine on our local net, portscanned using nmap(1) from the server (sorry for not in HTML -tt- mode):

% nmap -sT -sU -O 192.168.1.40
Interesting ports on 192.168.1.40:
(The 3107 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
137/udp open netbios-ns
138/udp open netbios-dgm
139/tcp open netbios-ssn
445/tcp open microsoft-ds
514/udp open syslog
631/tcp open ipp
631/udp open unknown

It really looks strange to me. Of course, an open ssh port is really NO problem.

This is my PC-BSD 1.3B1 firewall and I selected only port 22 (SSH) for connectivity in installer- by default all ports are closed.

Really? Is PF (or IPFW) enabled by default? Seems that someone has to review his configuration... :-)

Of course you can open/close your favorite ports if you wish.

Of course you can, it's a BSD. :-)

Reply Score: 1

RE[6]: Oh, wow...
by antik on Tue 24th Oct 2006 17:53 UTC in reply to "RE[5]: Oh, wow..."
antik Member since:
2006-05-19

% nmap -sT -sU -O 192.168.1.40
Interesting ports on 192.168.1.40:
(The 3107 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
137/udp open netbios-ns
138/udp open netbios-dgm
139/tcp open netbios-ssn
445/tcp open microsoft-ds
514/udp open syslog
631/tcp open ipp
631/udp open unknown


Now I understand the "problem", it shows ports, but you can't actually connect to- your connection would be dropped...

Reply Score: 1

RE[7]: Oh, wow...
by antik on Tue 24th Oct 2006 19:36 UTC in reply to "RE[6]: Oh, wow..."
antik Member since:
2006-05-19

Now I understand why you see open ports- scanned from other computer:
---------------------------------------------------------------------- -------------
Interesting ports on 192.168.2.100:
Not shown: 1679 filtered ports
PORT   STATE  SERVICE
80/tcp closed http
MAC Address: 00:50:8D:xx:xx:xx (Abit Computer)

Nmap finished: 1 IP address (1 host up) scanned in 24.686 seconds
---------------------------------------------------------------------- -------------

Scanned from localhost:
---------------------------------------------------------------------- -------------
Interesting ports on 192.168.2.100:
Not shown: 1676 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
139/tcp open  netbios-ssn
445/tcp open  microsoft-ds
631/tcp open  ipp

Nmap finished: 1 IP address (1 host up) scanned in 14.438 seconds
---------------------------------------------------------------------- -------------

Reply Score: 1

RE[2]: Oh, wow...
by Brandybuck on Tue 24th Oct 2006 19:33 UTC in reply to "RE: Oh, wow..."
Brandybuck Member since:
2006-08-27

"why bother?"

Do the math. Qt 3.3.6 is 8.5Mb, but every KDE application uses it. If all KDE apps were statically linked, that would be around 2.5 Gigabytes JUST for Qt. Add in the Xlib and KDE libaries, along with libc, libxml, etc, and you start eating up impressive amounts disk space.

Even though the Mac uses app bundles, it STILL has shared libraries/frameworks. There is a reason for this.

Reply Score: 2

wow?
by nullpt on Tue 24th Oct 2006 14:31 UTC
nullpt
Member since:
2006-10-20

The only dependency some users know is that they need a PC to run a program. If they are aiming at the common user why not simplify even further the installation of his favorite programs? Ports are easy to use but for someone who never even touched the cmd from windows it doesn't seem right and even if the pc-bsd solution was a gui to the ports system it would still have to deal with dependencies that sometimes have to be tweaked and hammered.

Reply Score: 0

RE: wow?
by Don T. Bothers on Tue 24th Oct 2006 17:03 UTC in reply to "wow?"
Don T. Bothers Member since:
2006-03-15

I marked you down because you never used PCBSD and decided to post something that is blatantly wrong. You do not need to use ports or packages for PCBSD. Instead, PCBSD uses PBI and you install PBIs through a standard "Windows" type installation.

Reply Score: 2

They need frameworks ....
by dindin on Tue 24th Oct 2006 15:32 UTC
dindin
Member since:
2006-03-29

Something like in OS X. So that libraries can be installed like aplications but into a framework that other applications can then utilize. In the PC-BSD system, the standard install keeps the Qt/KDE libraries as shared libraries (since it is a KDE distro) but other libraries will have to reside along with Applications.

Reply Score: 2