Why Are You NOT Using FreeBSD ?

[Mehmet Erol Sanliturk]

Dear All ,

There is a thread

"Why Are You Using FreeBSD ?"


I think another thread with the specified subject '"Why Are You NOT Using
FreeBSD ?" may be useful :


If you are NOT using FreeBSD for any area or some areas , would you please
list those areas with most important first to least important last ?


These points may be used to remedy difficulty points over time with respect
to
importance levels suggested by the users .


Thank you very much .

Mehmet Erol Sanliturk
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"

[Kurt Jaeger]

Hi!

> I think another thread with the specified subject '"Why Are You NOT Using
> FreeBSD ?" may be useful :

- Exchange (MAPI) and its groupware functionality
I'm eager to test any replacement that will pop up in the ports 8-)
- Windows Terminalserver functionality
- Telephony (ISDN to SIP gateways, Asterisk etc) -- I know,
Hans Petter Selasky is doing wonderful work in that area, I had
no time to dive into this.

--
p...@opsec.eu +49 171 3101372 8 years to go !

[Daniel Kalchev]

On 01.06.12 15:15, Kurt Jaeger wrote:
> - Telephony (ISDN to SIP gateways, Asterisk etc) -- I know, Hans
> Petter Selasky is doing wonderful work in that area, I had no time to
> dive into this.

Asterisk (tested up to v 10) works wonderfully on FreeBSD. Mine even
runs in jail. The few gateways to PSTN are external and spread over
distance anyway. There are less and less PSTN physical interconnects
anyway. About any sane telco will provide SIP trunks over TCP/IP so
there is not much motivation for development in that area. Such
connectivity was big thing say 10 years ago..


There is hardly anything FreeBSD cannot do. I tend to avoid proprietary
technologies like the plague (this includes about anything from
Microsoft). For example if one wants an e-mail server, that is better
served in the long run by IMAP+MTA than any form of Exchange, because
you are not tied to one single platform and that vendor's lunacy.
Otherwise FreeBSD runs just fine as server for about any other OS
client, provided those clients use standard Internet protocols.

Things I don't particularly do is use FreeBSD for mobile. I find OS X
way better choice there. When you need to go mobile, you usually need
the highest performing hardware (that is, lower power consumption, less
heat etc) and those things usually are pretty much proprietary for quite
long time. With OS X you get nice UNIX client.. for your FreeBSD
servers, that is. I also find it increasingly tempting to use tablets
for such remote client tasks :)

Another thing I don't use FreeBSD for is CAD. Unfortunately, there is no
AutoCAD for anything but Windows or OS X.

It will sure be interesting to learn what people avoid to use FreeBSD for.

Best Regards,
Daniel Kalchev

[Steven Hartland]

----- Original Message -----
From: "Mehmet Erol Sanliturk" <m.e.sa...@gmail.com>
> If you are NOT using FreeBSD for any area or some areas , would you please
> list those areas with most important first to least important last ?

Although we would like to we cant use FreeBSD to run some Linux based
services due to the lack support for mremap syscall :(

Regards
Steve

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postm...@multiplay.co.uk.

[Florian Smeets]

On 06/01/2012 14:15, Kurt Jaeger wrote:
> Hi!
>
>> I think another thread with the specified subject '"Why Are You NOT Using
>> FreeBSD ?" may be useful :
>

> - Telephony (ISDN to SIP gateways, Asterisk etc) -- I know,
> Hans Petter Selasky is doing wonderful work in that area, I had
> no time to dive into this.

I can tell you it works fine :)

Florian

[Phil Regnauld]

Daniel Kalchev (daniel) writes:
>
> It will sure be interesting to learn what people avoid to use FreeBSD for.

* full virtualization

I am using VirtualBox in production with HAST + ZVOLs, but we need
something like DRBD's dual master mode to be able to do a teleport of the
instance like Ganeti does (http://code.google.com/p/ganeti/) with Linux

Getting Xen dom0 and/or KVM would be a major boost as a virtualization
platform, in particular with ZFS.

* Gluster

For very large FSes, nothing beats it, especially now that 3.3 has been
released.

Mind you, I've been using FreeBSD for about 19 years, so I'm not about
to change, but the two items above would go a long way to help FreeBSD
grow in the data center space again (what the kids call the cloud :)

Cheers,
Phil

[anime...@gmail.com]

On 06/01/2012 09:12 AM, Phil Regnauld wrote:
> Daniel Kalchev (daniel) writes:
>>
>> It will sure be interesting to learn what people avoid to use FreeBSD for.
>
> * full virtualization
>
> I am using VirtualBox in production with HAST + ZVOLs, but we need
> something like DRBD's dual master mode to be able to do a teleport of the
> instance like Ganeti does (http://code.google.com/p/ganeti/) with Linux
>
> Getting Xen dom0 and/or KVM would be a major boost as a virtualization
> platform, in particular with ZFS.
>
> * Gluster
>
> For very large FSes, nothing beats it, especially now that 3.3 has been
> released.
>
> Mind you, I've been using FreeBSD for about 19 years, so I'm not about
> to change, but the two items above would go a long way to help FreeBSD
> grow in the data center space again (what the kids call the cloud :)
>
> Cheers,
> Phil

Thanks for the info and the interesting thread.

Thinking about it now I'm not sure I would continue using FreeBSD
knowing it become a solution for advanced TCP/IP node routing and
clustering over the "clouds".

I guess this depends whatever is meant theses days with the so called
technical vocabulary to hidden concepts too abstract for the common
mortal, thus pretending its "state-of-the-art", or sometimes an
abstraction of a logical software unit using advanced technologies
harboring eugenic like dehumanization and even potentially harmful to
FreeBSD users as for example the intrisic inclusion of IEEE 80211 OFDM
modulation scheme within the wireless code base.

However I still love FreeBSD and use it along with Linux for playing
games and working, but definitely not for HAST based storage, a good
example of a technology driven by political hierarchies and more or less
by the FreeBSD community, naively adopting technologies without
understanding the science and implications beneath such things...

Its just common sense or intuition I guess.. :)

Kind regards,
Etienne

[Oliver Fromme]

Mehmet Erol Sanliturk <m.e.sa...@gmail.com> wrote:
> If you are NOT using FreeBSD for any area or some areas , would you please
> list those areas with most important first to least important last ?

ISDN. This is popular in Germany, but I don't know about
the rest of the world.

We have a machine that has an ISDN card (ISA). Currently
it's still running FreeBSD 6-stable because that's the last
version with full ISDN support. Since 6.x went EOL, it
costed me quite some time to keep it up to date with regard
to security fixes. And now, since a few days, the Makefiles
of the ports collection started to become incompatible with
FreeBSD 6 (make(1) throws syntax errors) so I can't update
BIND port anymore, for example. Of course I could build it
manually, but this is costing more and more time, so finally
I will have to think of a different solution, which probably
means something other than FreeBSD.

Other than that, well, there are the typical programs that
are only available for Windows. For example the software
for configuring my Logitech "Harmony" remote control. I'm
using my wife's laptop (Windows) for that. But of course
I'm not blaming FreeBSD for that, because it's not something
that FreeBSD can fix, it's rather a vendor problem (in the
aforementioned case: Logitech's problem).

Best regards
Oliver

--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd

One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.

[uki]

Hi,

The only reason I'm not using FreeBSD for everything (games) is
because it does not support (yet) intel/ati graphic drivers. ;)

Cheers,
Łukasz Gruner

[Nomen Nescio]

> Dear All ,
>
> There is a thread
>
> "Why Are You Using FreeBSD ?"
>
>
> I think another thread with the specified subject '"Why Are You NOT Using
> FreeBSD ?" may be useful :
>
>
> If you are NOT using FreeBSD for any area or some areas , would you please
> list those areas with most important first to least important last ?

1. The X-org changeover a few years ago screwed up a FreeBSD installation I
had been using so badly I never trusted FreeBSD's rolling update ports
system again. That should have been a major FreeBSD release, but instead it
was done just in the ports with no version bump and no choice and no notice
unless you read the fine print.

2. Broken ports galore. Much of the stuff I wanted broke on AMD64 after
downloading tarballs for hours. Not good. Contacted package maintainer and
received answer: yeah, I know it doesn't work on AMD64. I still feel i386 is
the only safe FreeBSD platform and I have only one or two 32 bit boxes left
so FreeBSD doesn't really give me a warm fuzzy anymore. But it is still
ahead of NetBSD which got more and more unstable with every new major
version to the point I can't trust it. FreeBSD never crashed or did anything
bad for me except during the X-org episode.

3. gcc. I realize FreeBSD is moving to clang and that it can even be built
with clang. When clang is the default build, I will probably try it
again. Due to nearsighted/blind Linux developers, every OS besides Linux is
going to lag because of autotools and gcc crapola. It often makes compiling
apps a pain in the ass on FreeBSD when a port doesn't exist. I realize this
is not FreeBSD's fault and it is still an inhibitor to all the BSD for me.

4. I transitioned to mostly headless operation. FreeBSD is probably the best
overall desktop there is but I found other server OS better, specifically
Solaris. For my needs, YMMV. I use a Linux box for a desktop and I have
servers with different archs running headless with Solaris or OpenBSD and I
am looking at Dragonfly again in the near future, because pkgsrc is much
better than ports. Maybe FreeBSD should consider migrating to pkgsrc?

5. ZFS support on Solaris is current, on anything else, despite much
appreciated efforts, it is just not there. FreeBSD has the best ZFS support
outside of Solaris, but it's not enough right now and I don't think it will
ever catch up until Oracle releases the source. Not holding my breath on
that.

[Chris Nehren]

On Fri, Jun 01, 2012 at 05:03:26 -0700 , Mehmet Erol Sanliturk wrote:
> Dear All ,
>
> There is a thread
>
> "Why Are You Using FreeBSD ?"
>
>
> I think another thread with the specified subject '"Why Are You NOT Using
> FreeBSD ?" may be useful :
>
>
> If you are NOT using FreeBSD for any area or some areas , would you please
> list those areas with most important first to least important last ?

I use Mac desktops. X11 and I don't get along. I still live in a
fullscreen green-on-black terminal, of course, and do all of my actual
work in either the Mac's BSD userland or a FreeBSD machine over ssh.

So, really, this is nothing to do with FreeBSD per se, and I will
consider reevaluating FreeBSD as a desktop when something not X11 comes
along (although I don't see that as incredibly likely).

--
Thanks and best regards,
Chris Nehren

[Etienne Robillard]

On 06/01/2012 11:59 AM, Chris Nehren wrote:
> On Fri, Jun 01, 2012 at 05:03:26 -0700 , Mehmet Erol Sanliturk wrote:
>> Dear All ,
>>
>> There is a thread
>>
>> "Why Are You Using FreeBSD ?"
>>
>>
>> I think another thread with the specified subject '"Why Are You NOT Using
>> FreeBSD ?" may be useful :
>>
>>
>> If you are NOT using FreeBSD for any area or some areas , would you please
>> list those areas with most important first to least important last ?
>
> I use Mac desktops. X11 and I don't get along. I still live in a
> fullscreen green-on-black terminal, of course, and do all of my actual
> work in either the Mac's BSD userland or a FreeBSD machine over ssh.
>
> So, really, this is nothing to do with FreeBSD per se, and I will
> consider reevaluating FreeBSD as a desktop when something not X11 comes
> along (although I don't see that as incredibly likely).

You mean like a TV screen? :)

Clearly for me I prefer FreeBSD for server operations and Linux for
desktop although I frequently choose FreeBSD for desktop computing
and in particular DVD playback with ffmpeg/mplayer.

Cheers,

Etienne

--
Etienne Robillard
Occupation: Software Developer
Company: Green Tea Hackers Club
Email: er...@gthcfoundation.org
Website: gthcfoundation.org
Skype ID: incidah

[Michael R. Wayne]

On Fri, Jun 01, 2012 at 05:03:26AM -0700, Mehmet Erol Sanliturk wrote:
>
> If you are NOT using FreeBSD for any area or some areas , would you please
> list those areas with most important first to least important last ?

As mentioned by several others, once you have a single applicaiton
that demands Windows, you are mostly stuck running windows.

My single biggest complaint about FreeBSD is that there appears to
be absolutely no interest by anyone associated with the core team
in supporting one version for an extended period. Extended, in this
case, meaning 10+ years. Support meaning patching security
vulnerabilities and permitting ports to build. It does not matter
that that version will not run on current hardware or have new
features as long as it can continue to run on the original hardware.

[Chris Nehren]

On Fri, Jun 01, 2012 at 13:56:45 -0400 , Michael R. Wayne wrote:
> On Fri, Jun 01, 2012 at 05:03:26AM -0700, Mehmet Erol Sanliturk wrote:
> >
> > If you are NOT using FreeBSD for any area or some areas , would you please
> > list those areas with most important first to least important last ?
>
> As mentioned by several others, once you have a single applicaiton
> that demands Windows, you are mostly stuck running windows.
>
> My single biggest complaint about FreeBSD is that there appears to
> be absolutely no interest by anyone associated with the core team
> in supporting one version for an extended period. Extended, in this
> case, meaning 10+ years. Support meaning patching security
> vulnerabilities and permitting ports to build. It does not matter
> that that version will not run on current hardware or have new
> features as long as it can continue to run on the original hardware.

Show me one volunteer Unix OS with a 10+ year support infrastructure.

--
Thanks and best regards,
Chris Nehren

[Thomas David Rivers]

We used to have FreeBSD exclusively on desktops...

Now, we have migrated to other desktops (mac) with FreeBSD running
the build and file server...

Why?

Because - the mac updates itself! No pain, no installation,
no keeping-up with mailing lists/announcements, just <click> and its done.

Mac OS has a nice X11 server, the Mac UI is good enough, you don't
have to install/update anything, the "app store" is perfect
for downloading/installing whatever a desktop user might need.

It was just too alluring...

So, FreeBSD runs our NFS file server, and we log into a larger
FreeBSD machine to do builds, etc... but, the desktop has moved.

One developer here uses Linux Debian for about the same reason,
it's trivial to update (via the network) to new versions, etc...

Our web site used to be FreeBSD-based, but it was just too
cost-effective to get a virtual Linux box on the backbone and
move everything to that. Our requirements aren't too big, so
that works beautifully. There _are_ people doing virtual
FreeBSD boxes in a similar fashion, but they were quote a lot
more for the annual fee.. so, Linux it was...

I suppose, in some sense, you could argue that MacOS is FreeBSD...

- Dave Rivers -

--
rivers Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

[Chris Rees]

On 1 June 2012 16:20, Nomen Nescio <nob...@dizum.com> wrote:
>> Dear All ,
>>
>> There is a thread
>>
>> "Why Are You Using FreeBSD ?"
>>
>>
>> I think another thread with the specified subject   '"Why Are You NOT Using
>> FreeBSD ?" may be useful :
>>
>>
>> If you are NOT using FreeBSD for any area or some areas , would you please
>> list those areas with most important first to least important last ?
>
> 1. The X-org changeover a few years ago screwed up a FreeBSD installation I
> had been using so badly I never trusted FreeBSD's rolling update ports
> system again. That should have been a major FreeBSD release, but instead it
> was done just in the ports with no version bump and no choice and no notice
> unless you read the fine print.
>
> 2. Broken ports galore. Much of the stuff I wanted broke on AMD64 after
> downloading tarballs for hours. Not good. Contacted package maintainer and
> received answer: yeah, I know it doesn't work on AMD64.

That is unacceptable. Submit a PR next time you find something like
that-- ports that are broken on an arch should be marked as such so
people don't waste their time as you have been made to.

Chris

[Lars Engels]

On Fri, Jun 01, 2012 at 08:32:08PM +0100, Chris Rees wrote:
> On 1 June 2012 16:20, Nomen Nescio <nob...@dizum.com> wrote:
> >> Dear All ,
> >>
> >> There is a thread
> >>
> >> "Why Are You Using FreeBSD ?"
> >>
> >>
> >> I think another thread with the specified subject   '"Why Are You NOT Using
> >> FreeBSD ?" may be useful :
> >>
> >>
> >> If you are NOT using FreeBSD for any area or some areas , would you please
> >> list those areas with most important first to least important last ?
> >
> > 1. The X-org changeover a few years ago screwed up a FreeBSD installation I
> > had been using so badly I never trusted FreeBSD's rolling update ports
> > system again. That should have been a major FreeBSD release, but instead it
> > was done just in the ports with no version bump and no choice and no notice
> > unless you read the fine print.
> >
> > 2. Broken ports galore. Much of the stuff I wanted broke on AMD64 after
> > downloading tarballs for hours. Not good. Contacted package maintainer and
> > received answer: yeah, I know it doesn't work on AMD64.
>
> That is unacceptable. Submit a PR next time you find something like
> that-- ports that are broken on an arch should be marked as such so
> people don't waste their time as you have been made to.

I guess he made his experiences with that some years ago when support
for amd64 in the ports was not very mature. But this has changed since
then, apart from a few ports almost all of them should work on amd64
without problems.

[Ron McDowell]

On 6/1/12 1:57 PM, Thomas David Rivers wrote:
> We used to have FreeBSD exclusively on desktops...
>
> Now, we have migrated to other desktops (mac) with FreeBSD running
> the build and file server...
>
> Why?
>
> Because - the mac updates itself! No pain, no installation,
> no keeping-up with mailing lists/announcements, just<click> and its done.
>
> Mac OS has a nice X11 server, the Mac UI is good enough, you don't
> have to install/update anything, the "app store" is perfect
> for downloading/installing whatever a desktop user might need.
>
> It was just too alluring...
>
> So, FreeBSD runs our NFS file server, and we log into a larger
> FreeBSD machine to do builds, etc... but, the desktop has moved.
>
> One developer here uses Linux Debian for about the same reason,
> it's trivial to update (via the network) to new versions, etc...
>
> Our web site used to be FreeBSD-based, but it was just too
> cost-effective to get a virtual Linux box on the backbone and
> move everything to that. Our requirements aren't too big, so
> that works beautifully. There _are_ people doing virtual
> FreeBSD boxes in a similar fashion, but they were quote a lot
> more for the annual fee.. so, Linux it was...
>
> I suppose, in some sense, you could argue that MacOS is FreeBSD...
>
> - Dave Rivers -
>

I feel the same way about OSX for desktops [and my desktop is also my
notebook with a monitor/keyboard/mouse].

I have been quite happy with rootbsd.com [right there in your area code]
for VM boxes, have some in Raleigh and in Dallas and they perform well,
running 8-stable and 9-stable. I've also used vr.org for FreeBSD boxes
in Europe and Asia, no problems there either.

--
Ron McDowell
San Antonio TX

[Bryan Drewery]

On 6/1/2012 1:57 PM, Thomas David Rivers wrote:
> One developer here uses Linux Debian for about the same reason,
> it's trivial to update (via the network) to new versions, etc...

FWIW, there is freebsd-update(8) now for binary updating of base, and
pkgng[1] will allow binary upgrading of packages/ports similar to apt-get.

[1] http://wiki.freebsd.org/pkgng

--
Regards,
Bryan Drewery
bdrewery@freenode, bryan@EFNet

[Chris Nehren]

On Fri, Jun 01, 2012 at 14:50:22 -0500 , Bryan Drewery wrote:
> FWIW, there is freebsd-update(8) now for binary updating of base, and
> pkgng[1] will allow binary upgrading of packages/ports similar to apt-get.
>
> [1] http://wiki.freebsd.org/pkgng

The thing that really has me attracted to pkgng is that it's based on a
C library with a public API that developers can use / abuse. It's not
(AFAIK) officially released yet, but some early work I've been doing
with it has shown it to be useful enough.

--
Thanks and best regards,
Chris Nehren

[Matthias Schuendehuette]

Hi all,

Am 01.06.2012 um 14:03 schrieb Mehmet Erol Sanliturk:

> [...]

> If you are NOT using FreeBSD for any area or some areas , would you please
> list those areas with most important first to least important last ?

We are using two FreeBSD-Servers as a SAMBA-Server and as a plot-server, partly using the Linux-ABI. Both servers are rock solid (HP ProLiant).

But I'm not brave enough to run an ORACLE Database-Server under FreeBSD. For a corporate database server I need official vendor support for that platform and therefor I have to use RedHat or SuSE.

It's really a pity. I'm using FreeBSD since version 2.05 and was never disappointed.


Best regards

Matthias
--
Ciao/BSD - Matthias

Matthias Schuendehuette <msch [at] snafu.de>, Berlin (Germany)

[David Magda]

On Jun 1, 2012, at 09:12, Phil Regnauld wrote:

> * Gluster
>
> For very large FSes, nothing beats it, especially now that 3.3 has been
> released.

Isilon built their OneFS on top of FreeBSD, does that count? :)

Panasas too IIRC.

[Dave Hayes]

Mehmet Erol Sanliturk <m.e.sa...@gmail.com> writes:
> If you are NOT using FreeBSD for any area or some areas , would you please
> list those areas with most important first to least important last ?

1) I don't use FreeBSD for virtualization as the host OS. I really want
to, becaus I want to be able to somewhat trust the kernel hosting my
virtual machines. FreeBSD technology, support, and documentation for
this idea appears unavailable.

2) I don't use FreeBSD for a 'modern' desktop. By 'modern' I mean areas
which most rank and file users would need: day-to-day non technical
browsing with flash, applications like skype, syncing to mobile
devices, etc.

I'd imagine this is important for rank and file users. However, I'm an
old schooler who likes text based applications and command lines, and I
personally feel that a lot of the desktop technologies out there (Gnome,
KDE, Aqua, Windows) are inherently unsafe (security wise) for a desktop
I do software development on. One glance at my X-mailer should tell many
people where I'm at. ;)

As an example (please don't think I'm singling KDE out here, I can
likely find examples for each desktop technology out there) I was given
to understand that the KDE file browser allowed the execution of
javascript. This single rumor has kept me from trying out KDE for years.
Again, nothing against KDE in particular, all of the 'user friendly'
desktop technologies likely have something just as egregious.

Thus, in many ways I feel it's a *feature* of FreeBSD that the desktop
software lags behind everyone else. I don't want flash in my Firefox. I
don't want hal, bonjour, or dbus as an extra attack surface. I don't
want gnome to auto discover all the fileshares on my network(s).

3) I don't use FreeBSD for games, sadly. This is the only place where I
will tolerate having a Windoze box, for my love of games exceeds my
hatred of windows (yes I -really- do love games) and it's hard to find a
better platform for games.
--
Dave Hayes - Consultant - Altadena CA, USA - da...@jetcafe.org
>>> The opinions expressed above are entirely my own <<<

Freedom is free of the need to be free. -George Clinton

[Dave Hayes]

Lars Engels <lars....@0x20.net> writes:
> I guess he made his experiences with that some years ago when support
> for amd64 in the ports was not very mature. But this has changed since
> then, apart from a few ports almost all of them should work on amd64
> without problems.

I can vouch for this. I have several production and two development
amd64 machines. I've yet to have a problem with a port because of the
architecture.

--
Dave Hayes - Consultant - Altadena CA, USA - da...@jetcafe.org
>>> The opinions expressed above are entirely my own <<<

Man does not have a capacity of instant comprehension. So
rare is the knowledge of how to train this, that most people
and institutions have compromised by playing upon man's
proneness to conditioning and indoctrination instead.

The end of *that* road is the ant-heap. Or, at best, the
beehive.

[David Magda]

On Jun 1, 2012, at 08:33, Daniel Kalchev wrote:

> For example if one wants an e-mail server, that is better served in the long run by IMAP+MTA than any form of Exchange, because you are not tied to one single platform and that vendor's lunacy. Otherwise FreeBSD runs just fine as server for about any other OS client, provided those clients use standard Internet protocols.

If all you want is e-mail, then there are certainly better options than Exchange IMHO. However, once you get into calendars (private and shared, with delegation to secretaries, etc.), meeting rooms, ActiveSync (to remotely wipe lost devices), then it's a whole different game.

E-mail was solved a long time ago, but Exchange does many things on top of it that many organizations find very handy, and where there doesn't seem to be a decent open alternative.

[Phil Regnauld]

David Magda (dmagda) writes:
> On Jun 1, 2012, at 09:12, Phil Regnauld wrote:
>
> > * Gluster
> >
> > For very large FSes, nothing beats it, especially now that 3.3 has been
> > released.
>
> Isilon built their OneFS on top of FreeBSD, does that count? :)
>
> Panasas too IIRC.

Good pointers, thanks. It's still "appliance", but good to know that
FreeBSD is out there :)

Phil

[Gary Palmer]

On Fri, Jun 01, 2012 at 05:12:14PM -0700, Dave Hayes wrote:
> Mehmet Erol Sanliturk <m.e.sa...@gmail.com> writes:
> > If you are NOT using FreeBSD for any area or some areas , would you please
> > list those areas with most important first to least important last ?
>
> 1) I don't use FreeBSD for virtualization as the host OS. I really want
> to, becaus I want to be able to somewhat trust the kernel hosting my
> virtual machines. FreeBSD technology, support, and documentation for
> this idea appears unavailable.

Have you looked at VirtualBox? /usr/ports/emulators/virtualbox-ose

Its not a fully featured replacement for vSphere (e.g. no equivalent
of vMotion) but it is a perfectly workable virtualisation solution
for a number of situations.

Gary

[Freddie Cash]

On Jun 1, 2012 5:34 PM, "David Magda" <dma...@ee.ryerson.ca> wrote:
>
> On Jun 1, 2012, at 08:33, Daniel Kalchev wrote:
>
> > For example if one wants an e-mail server, that is better served in the
long run by IMAP+MTA than any form of Exchange, because you are not tied to
one single platform and that vendor's lunacy. Otherwise FreeBSD runs just
fine as server for about any other OS client, provided those clients use
standard Internet protocols.
>
> If all you want is e-mail, then there are certainly better options than
Exchange IMHO. However, once you get into calendars (private and shared,
with delegation to secretaries, etc.), meeting rooms, ActiveSync (to
remotely wipe lost devices), then it's a whole different game.
>
> E-mail was solved a long time ago, but Exchange does many things on top
of it that many organizations find very handy, and where there doesn't seem
to be a decent open alternative.

Zimbra, Kolab, OpenGroupware, Citadel, Zarafa, and many others have filled
the gap in recent years.

Zimbra in particular is very nice to work with. Especially the for-pay
Network Edition. It's basically a drop-in replacement for Exchange, right
down to the Outlook Connector and ActiveSync support.

And the open-source version (which has the exact same web interface) is
also very nice to work with. It's just a nice GUI/DB wrapper to Postfix,
Cyrus IMAPd, MySQL, and various other OSS bits.

[Alex Goncharov]

,--- Dave Hayes (Fri, 01 Jun 2012 17:12:14 -0700) ----*

| 2) I don't use FreeBSD for a 'modern' desktop. By 'modern' I mean
| areas which most rank and file users would need: day-to-day non
| technical browsing with flash, applications like skype, syncing to
| mobile devices, etc.

First, two statements and one statement/question:

S1. Flash works pretty well -- sometimes almost perfectly -- in
FreeBSD: in Firefox, Opera or Chrome. Some software upgrades (the
plugin in ports or base, I haven't figured out) lead to periodic hangs
on (I think) plugin disconnects, so the plugin processes better to be
cleaned up by 'kill' periodically. A nuisance but can be lived with,
if FreeBSD seems a better option in other respects (which it does for
me.) I visit scores of very "flashy" Web sites every day and am, on
the balance, happy with what I get with either of the mentioned
browsers in FreeBSD there.

S2. I tried Skype in FreeBSD 9 a few months back and, IIRC, all there
worked: at least I was able to use Skype for instant messaging.

S3? Syncing to Ip*d and BB PlayBook is something I would really like
to do in FreeBSD and I haven't figured out if that is possible. I
played with "fuse", "gtkpod" and other things that work in Linux. No
luck for me. So does anybody know if this is possible somehow? (After
all, one can see these devices as SCSI "something". Is "fuse" of any
good for this?)

| I'd imagine this is important for rank and file users. However, I'm an
| old schooler who likes text based applications and command lines, and I
| personally feel that a lot of the desktop technologies out there (Gnome,
| KDE, Aqua, Windows) are inherently unsafe (security wise) for a desktop
| I do software development on. One glance at my X-mailer should tell many
| people where I'm at. ;)

You don't have to use anything of Gnome or KDE in order to use the
technologies mentioned in my S1 and S2 -- I use TWM, for example.

| Thus, in many ways I feel it's a *feature* of FreeBSD that the desktop
| software lags behind everyone else. I don't want flash in my Firefox. I
| don't want hal, bonjour, or dbus as an extra attack surface. I don't
| want gnome to auto discover all the fileshares on my network(s).

I don't run 'hal'; 'dbus' may be harder to avoid.

It would be really nice to be able to talk to Apple and BB mobile
devices from FreeBSD -- and that is my only current grievance about
FreeBSD as a desktop environment. Everything else is shining
brilliant for me. Thanks all who made it so!

-- Alex -- alex-go...@comcast.net --

[Chris Nehren]

On Fri, Jun 01, 2012 at 15:12:36 +0200 , Phil Regnauld wrote:
>
> * full virtualization
>
> I am using VirtualBox in production with HAST + ZVOLs, but we need
> something like DRBD's dual master mode to be able to do a teleport of the
> instance like Ganeti does (http://code.google.com/p/ganeti/) with Linux
>
> Getting Xen dom0 and/or KVM would be a major boost as a virtualization
> platform, in particular with ZFS.
>
> * Gluster
>
> For very large FSes, nothing beats it, especially now that 3.3 has been
> released.
>

You say your'e using ZVOLs but then recommend gluster for large
filesystems. I would like to take a moment to point out that one of the
design goals of ZFS was to scale beyond the capabilities of current
hardware.

What does gluster do that ZFS does not? I'm not trying to troll here,
but am genuinely curious about ZFS's shortfalls in one of the problem
domains it seeks to address.

--
Thanks and best regards,
Chris Nehren

[Brian]

On 6/1/2012 5:14 PM, Dave Hayes wrote:
> Lars Engels<lars....@0x20.net> writes:
>> I guess he made his experiences with that some years ago when support
>> for amd64 in the ports was not very mature. But this has changed since
>> then, apart from a few ports almost all of them should work on amd64
>> without problems.
> I can vouch for this. I have several production and two development
> amd64 machines. I've yet to have a problem with a port because of the
> architecture.

Early in the 7.x timeframe I had this experience; not recently. Back
then I installed i386 on a 64 bit AM2 proc equipped machine after seeing
funny port compile errors in amd64 that went away with i386.

Brian

[David Magda]

On Jun 1, 2012, at 21:03, Chris Nehren wrote:

> You say your'e using ZVOLs but then recommend gluster for large
> filesystems. I would like to take a moment to point out that one of the
> design goals of ZFS was to scale beyond the capabilities of current
> hardware.
>
> What does gluster do that ZFS does not? I'm not trying to troll here,
> but am genuinely curious about ZFS's shortfalls in one of the problem
> domains it seeks to address.

ZFS is for storing file systems on locally connected block devices. Gluster is a network file system where data can be distributed over many nodes.

So ZFS can ensure that bits-on-disk stay safe through checksums and mirroring / RAIDZ, while Gluster allows entire file servers to go offline and the files are still accessible because you have a kind of network-level RAID going on. This also helps in performance since instead of clients pounding on one file server (as usually happens with NFS), every write is sent to many data nodes so you're striping across many network elements. Think of it as NFS on steroids.

A competitive open source equivalent would be Lustre, while Isilon and Panasas would probably be commercial alternatives (though they do NFS / CIFS on the 'front-end' and the distributed "magic" occurs on a 'back-end' network between the appliances).

http://en.wikipedia.org/wiki/GlusterFS
http://en.wikipedia.org/wiki/Lustre_(file_system)

[Glen Barber]

On Fri, Jun 01, 2012 at 11:14:10PM -0400, David Magda wrote:
> ZFS is for storing file systems on locally connected block devices.
> Gluster is a network file system where data can be distributed over
> many nodes.
>

Pardon my ignorance to not knowing what gluster is, but is this
conceptually similar to HAST?

Glen

[Erich]

Hi,

On 01 June 2012 AM 5:03:26 Mehmet Erol Sanliturk wrote:
>
> "Why Are You Using FreeBSD ?"

there is only one reason for me not using FreeBSD: hardware which is not supported but found in the machine.

I have had to move two machines within the last three years to Fedora because of this. The first machine has had an old network adapter which was not supported by FreeBSD.

The second machine is my new X220 on which I could not get X running before I have had to use it for work. I will stick now with it while I am travelling. This will take some time. I will have a try with FreeBSD again after my return.

I also noticed one small problem when people use FreeBSD mainly and have one machine with Linux. It is similar. Yes, but it is not the same. When options differ, it becomes real problematic. I was really considering moving back to Windows on that one machine.

Fedora supports the built-in camera and finger print reader. I could not read memory cards with the built-in reader but have had to use my old external one.

What really puts me off on Fedora is the maintenance. I do not understand why people do this to themselfs. FreeBSD is so much easier to maintain. How often did Fedora introduce basic changes which runs you crazy when you have to maintain several machines?

Erich

[Zach Leslie]

> So ZFS can ensure that bits-on-disk stay safe through checksums and mirroring / RAIDZ, while Gluster allows entire file servers to go offline and the files are still accessible because you have a kind of network-level RAID going on. This also helps in performance since instead of clients pounding on one file server (as usually happens with NFS), every write is sent to many data nodes so you're striping across many network elements. Think of it as NFS on steroids.

I love distributed filessystems. While Gluster is a pain, this is
something that the Linux community is at least paying attention to as a
real issue and working to solve it.

I don't know that new work in distributed filesystems, like Ceph
(http://ceph.com/), is inherently tied to Linux, but more that devs are
choosing Linux as a platform on which to build awesome projects.

I would love to see ZFS backed distributed network filesystems, but even
ZFS came from outside FreeBSD, so the commercial vendors you mentioned
may be the only way forward in this regard for FreeBSD.

--
Zach

[Eitan Adler]

On 1 June 2012 23:33, Zach Leslie <xaqu...@gmail.com> wrote:
>> So ZFS can ensure that bits-on-disk stay safe through checksums and mirroring / RAIDZ, while Gluster allows entire file servers to go offline and the files are still accessible because you have a kind of network-level RAID going on. This also helps in performance since instead of clients pounding on one file server (as usually happens with NFS), every write is sent to many data nodes so you're striping across many network elements. Think of it as NFS on steroids.
>

> I don't know that new work in distributed filesystems, like Ceph
> (http://ceph.com/), is inherently tied to Linux, but more that devs are
> choosing Linux as a platform on which to build awesome projects.

The question to ask here is what utilities, APIs, and features does
Linux have which cause developers to use it instead and what could we
do about it?



--
Eitan Adler

[Freddie Cash]

On Jun 1, 2012 8:27 PM, "Glen Barber" <g...@freebsd.org> wrote:
>
> On Fri, Jun 01, 2012 at 11:14:10PM -0400, David Magda wrote:
> > ZFS is for storing file systems on locally connected block devices.
> > Gluster is a network file system where data can be distributed over
> > many nodes.
> >
>
> Pardon my ignorance to not knowing what gluster is, but is this
> conceptually similar to HAST?

Similar in concept, but different layers in the storage stack.

HAST sits between the physical disks and the filesystem, replicating data
between two systems. So, disks -- HAST -- ZFS.

Glustre sits above the storage system, replicating data between systems.
So, disks -- ZFS (via Zvols) -- Glustre.

The primary difference is that HAST provides only a single master node that
all I/O goes through. The filesystem(s) above HAST cannot be mounted on
more than one host. I/O is limited to what the master can handle.

Glustre is distributed across hosts, so I/O is multiplied (to some extent),
and data is accessible across multiple hosts.

[Daniel Kalchev]

On 02.06.2012, at 03:06, David Magda <dma...@ee.ryerson.ca> wrote:

> On Jun 1, 2012, at 08:33, Daniel Kalchev wrote:
>
>> For example if one wants an e-mail server, that is better served in the long run by IMAP+MTA than any form of Exchange, because you are not tied to one single platform and that vendor's lunacy. Otherwise FreeBSD runs just fine as server for about any other OS client, provided those clients use standard Internet protocols.
>
> If all you want is e-mail, then there are certainly better options than Exchange IMHO. However, once you get into calendars (private and shared, with delegation to secretaries, etc.), meeting rooms, ActiveSync (to remotely wipe lost devices), then it's a whole different game.

There are a lot of open source calendaring applications, of all kinds. Most run fine on FreeBSD.

I really see no reason why your 'mail or calendaring server' should be able to wipe your devices.. This is the sort of bloat that keeps me away. From Microsoft products.

>
> E-mail was solved a long time ago, but Exchange does many things on top of it that many organizations find very handy, and where there doesn't seem to be a decent open alternative.
>

Hope you are not of the opinion that first there was Exchange, then all other e-mail servers appeared, "copying" it. History was exactly the other way around. We were using it long before Microsoft discovered this Internet thing exists and first tried to kill it.
Again it is not about open source. It is about non-proprietary protocols. All proprietary platforms turn to be more expensive in every respect in a while.

In this regard I rather prefer the way Apple handles things. Shiny wrapper interface to pretty much generic technology. No reinvention of the wheel and experiments to see if it can be made square.

Daniel_______________________________________________

[Daniel Kalchev]

On 02.06.2012, at 07:19, Freddie Cash <fjw...@gmail.com> wrote:

>
> Glustre sits above the storage system, replicating data between systems.
> So, disks -- ZFS (via Zvols) -- Glustre.
>

How is this different than ZFS using remote zvols via iSCSI? Can it tolerate down nodes better than ZFS?

Daniel_______________________________________________

[Mark Linimon]

On Fri, Jun 01, 2012 at 05:20:39PM +0200, Nomen Nescio wrote:
> Maybe FreeBSD should consider migrating to pkgsrc?

I'm not arguing that your other points are invalid (in particular,
I agree that the xorg change was really painful, and for a long time
amd64 lagged i386 badly), but there is one very major blocker for this
particular idea. If you browse the following URL:

http://wiki.freebsd.org/PackageSystemsComparison

You'll see that pkgsrc is around 12k packages. Although our graph
is stale, per the portsmon/FreshPorts URLs, we're approaching 24k
ports.

So: while it's been suggested before, it's not really workable.

mcl

[David Magda]

On Jun 2, 2012, at 00:51, Daniel Kalchev wrote:

> On 02.06.2012, at 07:19, Freddie Cash <fjw...@gmail.com> wrote:
>
>>
>> Glustre sits above the storage system, replicating data between systems.
>> So, disks -- ZFS (via Zvols) -- Glustre.
>>
>
> How is this different than ZFS using remote zvols via iSCSI? Can it tolerate down nodes better than ZFS?

Gluster ~ NFS++.

[Marc Santhoff]

Am Freitag, den 01.06.2012, 13:56 -0400 schrieb Michael R. Wayne:

> On Fri, Jun 01, 2012 at 05:03:26AM -0700, Mehmet Erol Sanliturk wrote:
> >
> > If you are NOT using FreeBSD for any area or some areas , would you please
> > list those areas with most important first to least important last ?
>

> As mentioned by several others, once you have a single applicaiton
> that demands Windows, you are mostly stuck running windows.

I was used to thinking the same way, but today there is VirtualBox and
it does very well. More simple applications work fine using wine, that
keeps you from having to install a complete Windows-OS.

I do not use FreeBSD when it comes to running hardware dependent WIndows
programs in a virtual box. But to be fair I have to mention that things
are getting better, the most gadgets do work even without windows - like
DMMs (digital multimeters), suport for video and tv hardware has gotten
much better.

Where I have to leave FreeBSD it's mostly because of fast USB2 tranfers,
a DSO (digital storage oscilloscope) is one of those cases that refuse
to work inside a vbox, although the device itself is found and attached.

Those are the last few issues stopping me from deleting the Windows
partition^wslice on my desktop machine.

Well done!

--
Marc Santhoff <M.San...@web.de>

[Hugo Lombard]

On Fri, Jun 01, 2012 at 05:12:14PM -0700, Dave Hayes wrote:
>

> 1) I don't use FreeBSD for virtualization as the host OS. I really want
> to, becaus I want to be able to somewhat trust the kernel hosting my
> virtual machines. FreeBSD technology, support, and documentation for
> this idea appears unavailable.
>

Perhaps the BSD Hypervisor (BHyVe) might be of interest?

http://wiki.freebsd.org/BHyVe

A caveat:

"BHyVe requires Intel CPUs with VT-x and NPT support. These features
are on all Nehalem models and beyond (e.g. SandyBridge), but not on
the lower-end Atom CPUs."

--
Hugo Lombard

[O. Hartmann]

On 06/01/12 21:46, Lars Engels wrote:
> On Fri, Jun 01, 2012 at 08:32:08PM +0100, Chris Rees wrote:
>> On 1 June 2012 16:20, Nomen Nescio <nob...@dizum.com> wrote:
>>>> Dear All ,
>>>>
>>>> There is a thread

>>>>
>>>> "Why Are You Using FreeBSD ?"
>>>>
>>>>

>>>> I think another thread with the specified subject '"Why Are You NOT Using
>>>> FreeBSD ?" may be useful :

>>>>
>>>>
>>>> If you are NOT using FreeBSD for any area or some areas , would you please
>>>> list those areas with most important first to least important last ?

1a) On "scietific production systems", FreeBSD has been banned due to
the lack of HPC compilers and appropriate mathematical libraries. The
lack of professional/academic support, like that from NAG in the late
1990s, has been droped for FreeBSD as well as the presence of C/C++/F95
compilers.

1b) The lack of GPGPU. This has become so important to HPC these days.
We use nVidia GPU based TESLA boards with OpenCL software (CUDA is
luckily not necessary). The lack of professional drivers for 64Bit on
FreeBSD was long time an issue, nVidia now provides drivers, but they
don't provide their CUDA/OpenCL libraries along with their nvcc compiler
natively for 64Bit FreeBSD/amd64. The Linuxulator isn't any option.

2) Disk and network I/O issues under load. We realized that FreeBSD has
some issues in multithreaded environments. Even on 6/12 or 12/24
core/thread systems, under heavy load (especially network and CPU load),
disk I/O was (is?) poor. This is a no-go in a HPC environment.

3) Outdated ports OR not available ports: some important software
maintained by the US government (USGS, NASA/JPL) is only provided for
Mac OS X and some Linux derivatives. We created our own ports for some
of those, but maintaining these, especially those provided by the USGS
(ISIS3) is hard work. Other software, like the AMES StereoPipeline,
seems to be crippled by intention when it comes to the sources
(essential portions are "vanished" in the repositories).
Developers are unwilling - by intention, lack of time or lack of
capabilities.

4) The lack of clustering capabilities. The lack of a clustered
filesystem grows more and more important in the area of HPC, where
storage systems get spread over a department. I lost track in the
development on FreeBSD since around 2003. At the moment, for me
personally this issue isn't so important, but in combination with items
1) through 3) and the migration towards Linux (we use prefereably Ubuntu
server, some Suse and on some servers CentOS/RedHat, which suffers from
the Linux-narrowminded deseas as well, in my opinion, but you'll get
support by Dell and others - in times of strangling contracts, a more
and more restricted freedom of science in favor of "business" ...
another story ...)


Well, item 3 isn't a real FreeBSD issue. I have the impression that
since the good old UNIX times, mid 1990s, a deadly Virus spread around
called Linux, attracting development schemata known from
Microsoft/Windows: narrow minded Linux-only sources, nearsighted
development, shortcuts due to political reasons, even if the sources are
available for all.
I regret this development of "open software" very deeply and it is not
the *BSD UNIX developers fault (excluding item 1 and 2, that are
political issues and a burden of the BSD folks having made political
decissions in the past!).

I do not speak for my department and I do not speak for my colleagues. I
speka for myself and my opinion.
Personally, I use FreeBSD private and under my desk - and I really
suffer from the lack of GPGPU, since even some opensource, high
performance software like "Blender" benefetis tremendously from using
CUDA/OpenCL if GPU is available.

Regards,

Oliver Hartmann

[Daniel Kalchev]

On 02.06.12 09:23, David Magda wrote:
> On Jun 2, 2012, at 00:51, Daniel Kalchev wrote:
>
>> On 02.06.2012, at 07:19, Freddie Cash<fjw...@gmail.com> wrote:
>>
>>> Glustre sits above the storage system, replicating data between systems.
>>> So, disks -- ZFS (via Zvols) -- Glustre.
>>>
>> How is this different than ZFS using remote zvols via iSCSI? Can it tolerate down nodes better than ZFS?
> Gluster ~ NFS++.

So Gluster is basically ZFS with NFS frontend? Something readily
available in FreeBSD. The clients don't even have to learn new file
sharing protocol.

Daniel

[Daniel Kalchev]

On 02.06.12 12:27, O. Hartmann wrote:
>
> 1a) On "scietific production systems", FreeBSD has been banned due to
> the lack of HPC compilers and appropriate mathematical libraries. The
> lack of professional/academic support, like that from NAG in the late
> 1990s, has been droped for FreeBSD as well as the presence of C/C++/F95
> compilers.

Could you please elaborate on this a bit. "Scientific" software, as such
rarely depends on any hardware and should be practically OS agnostic.
What are these libraries, that "scientific production systems" use that
cannot be used on FreeBSD? Same about support. If someone supports an
"scientific" library on an OS, chances are they can support it on
FreeBSD just as well, except if they are religious fanatics, that is.

FreeBSD has always had more or less recent compilers available. Perhaps,
not in the base system. As you say, this issue is strictly political (to
not have "cuitting edge" [double the quote, for more pun] compilers).
The policy with FreeBSD is stability over all else and that the base
must be able to compile itself -- this is what any UNIX system is
supposed to handle, but that's another long story. The recent
developments with clang/llvm are very promising as well.

I can hardly imagine it being that difficult to maintain an "advanced"
compiler around just to compile your highly specific code. Further,
recent gcc is in ports anyway.

> 1b) The lack of GPGPU. This has become so important to HPC these days.
> We use nVidia GPU based TESLA boards with OpenCL software (CUDA is
> luckily not necessary). The lack of professional drivers for 64Bit on
> FreeBSD was long time an issue, nVidia now provides drivers, but they
> don't provide their CUDA/OpenCL libraries along with their nvcc compiler
> natively for 64Bit FreeBSD/amd64. The Linuxulator isn't any option.

This one is regrettable. Outside of the "scientific" usage, it could let
desktop users offload a lot of processing to their (in most cases more
powerful than the CPU, video controller). But how is this FreeBSD fault?
I would attribute it more to inability of nVidia programmers, or their
lack of resources (I doubt that many people do driver development there
anyway) as the reason why we don't see it. If they have scarce resources
available, it's understandable why they do not see the immediate need to
port their code to FreeBSD. I am confident, given this hardware is not
that cheap, that any bigger user asking for FreeBSD support could
motivate them to just do it.
I also believe there is nothing hidden in FreeBSD and that in general
FreeBSD has been more stable API-wise than other UNIX platforms around.
And, I also believe should there be interest from nVidia, tey will see
support and help from FreeBSD developers. Or they could just release
their hardware spec, if they can't do it themselves for one reason or
another. After all, much more complex tasks have been resolved with FreeBSD.

> 2) Disk and network I/O issues under load. We realized that FreeBSD has
> some issues in multithreaded environments. Even on 6/12 or 12/24
> core/thread systems, under heavy load (especially network and CPU load),
> disk I/O was (is?) poor. This is a no-go in a HPC environment.

Could you please elaborate on this a bit?
On one hand, I am surprised that the HPC environment will have such
requirements and on the other hand this is how typical higher-end
storage systems are built with FreeBSD. I haven't seen anything like
this and am willing to test on 24-32 core systems.

You said this is political for FreeBSD .. why? I don't get it? FreeBSD
has no policy of failing under heavy load -- quite the contrary.

> 3) Outdated ports OR not available ports: some important software
> maintained by the US government (USGS, NASA/JPL) is only provided for
> Mac OS X and some Linux derivatives.

This may be for many, many reasons, including (most often and most
unfortunately) licensing. But there is not much anyone working with
FreeBSD can do, except create an port, if the license permits.
If the license does not permit this software run on FreeBSD -- then
probably the only choice is to try and persuade it's author.
If it runs on OS X, chances are it will run on FreeBSD with very little
effort. (except if it relies heavily on Cocoa)

> 4) The lack of clustering capabilities. The lack of a clustered
> filesystem grows more and more important in the area of HPC, where
> storage systems get spread over a department. I lost track in the
> development on FreeBSD since around 2003. At the moment, for me
> personally this issue isn't so important, but in combination with items
> 1) through 3) and the migration towards Linux (we use prefereably Ubuntu
> server, some Suse and on some servers CentOS/RedHat, which suffers from
> the Linux-narrowminded deseas as well, in my opinion, but you'll get
> support by Dell and others - in times of strangling contracts, a more
> and more restricted freedom of science in favor of "business" ...
> another story ...)

Can you explain on this too? What kind of clustering filesystem you
need? FreeBSD doesn't do bad in the storage area and in fact many
(most?) commercial storage solutions are built on top of FreeBSD.

[Glen Barber]

On Fri, Jun 01, 2012 at 09:19:15PM -0700, Freddie Cash wrote:
> > Pardon my ignorance to not knowing what gluster is, but is this
> > conceptually similar to HAST?
>
> Similar in concept, but different layers in the storage stack.
>
> HAST sits between the physical disks and the filesystem, replicating data
> between two systems. So, disks -- HAST -- ZFS.
>

Got it, thanks.

However, HAST is not specifically ZFS. (Just pointing it out.)

Glen

[Daniel Kalchev]

On 02.06.12 10:21, Marc Santhoff wrote:
> Am Freitag, den 01.06.2012, 13:56 -0400 schrieb Michael R. Wayne:
>> On Fri, Jun 01, 2012 at 05:03:26AM -0700, Mehmet Erol Sanliturk wrote:
>>> If you are NOT using FreeBSD for any area or some areas , would you please
>>> list those areas with most important first to least important last ?
>> As mentioned by several others, once you have a single applicaiton
>> that demands Windows, you are mostly stuck running windows.
> I was used to thinking the same way, but today there is VirtualBox and
> it does very well. More simple applications work fine using wine, that
> keeps you from having to install a complete Windows-OS.

I want to second this. For me, until recently the only Windows computer
was an laptop. I was thinking along the same lines (being primary BSD
UNIX for everything for over 20 years) - if you need Windows software,
run it on Windows. But, I was more and more pissed of this stuff and
eventually brought myself an Macbook. Never touched the Windows laptop
ever since. Any "windows only" software that comes across, of any kind,
runs in VirtualBox on either FreeBSD or OS X. No issues of any kind.

[Alexander Yerenkow]

I'll try to be short.
I'm using FreeBSD both at servers and as a desktop, but I see
struggling of my friends with it in some things.

1. Ports mess. You can very easily render system unusable, or broken
if you trying to use latest ports. And then you had to became "a port
master" to fix all. Of course you need a lot of free time, right? :)
2. No decent packet manager (I hope pkgng will make life easier). You
can't just upgrade this and that packet and see what's new, and
rollback if you don't like somthing .
3. "FreeBSD is not a linux" - so FreeBSD avoid linuxisms, like KMS
etc. And when it became crystal clear that progress is inevitable, we
need wait few more years to get new graphics working. Some time ago, I
read somewhere on wiki proud phrase "We are more linux than linux
itself", it was about LSB test or something similar. FreeBSD can deny
linux ways, but it's here, and it's widespread standard (at least in
comparing with FreeBSD). FreeBSD do really need those fancy new techs,
at least which related to X/hardware. XEN is one more thing, which
could be attractive, but there's not much progress. I don't say let's
rewrite all as in linux. I'm saying about having copatibility layer a
bit fresher.
4. NDIS is working, right? Why there's no L(inux)DIS :) For new
hardware, like wifi's, networks,webcams,raids etc there some linux
drivers. and no FreeBSD drivers. At all. And if you need one - "write
one" or "wait please few years until someone look into it".
5. Name public person behind Microsoft? yes, there are one. And from
Google? And from Oracle? And from GNU? And from Linux? Human nature is
such that any company/big product is replaced in his mind with person,
at least partially. And there's no person behind FreeBSD. There are
many collaborators, who rarely well known in world as FreeBSD
developer. And this is how it's affect reality:
- Please, big boss, give me 10mil for new cluster system run on Linux.
- What's Linux?
- It's product developed for 20 years by Linus, and in recent years
got support by many major world companies (long list goes here).
- Ah, ok, here you go.
- And also, big boss I need 50 thousands for FreeBSD cluster.
- FreeBSD? What's this?
- Ehm... it's a operating system, developed by many peoples, there are
many good progammers (long list goes here)
- You better buy a few more linuxes then.

That could be PR issue anyway, but dirty politics rules the world, face it.
6. No "try-it" system for FreeBSD. No official virtual images (PC-BSD
will fix the issue). No testing images for major changes, where's
nightly builds with latest KDE/QT/KMS/new drivers? There's none, at
least none automatic build. Yea, I know that's because there's no
decent auto build system of such things.
- I'm volunteer to test FreeBSD!
- Ok, grab sources here, compile kernel, world, download ports, patch
it with area51, try to build something, and rebuild all again (you too
early build all, we just updated libXX*)...
- Oh... ok. I'm volunteer to test Linux
- Grab live image/virtual image, boot and poke programs.
- Great, thanks!

You can easily be involved in many programs development. Kdenlive -
just another example how one program have own infrastructure to
provide live images and virtual machine images, so any can try and
test it.

You could think I'm wrong, but FreeBSD have many problems as project,
but it's all fixable.

P.S. Of course FreeBSD is great, and I'm using it, and I glad that it
here, and all developers are awesome, no offence here ;)

--
Regards,
Alexander Yerenkow

[Mel Flynn]

On 1-6-2012 20:57, Thomas David Rivers wrote:
> We used to have FreeBSD exclusively on desktops...
>
> Now, we have migrated to other desktops (mac) with FreeBSD running
> the build and file server...
>
> Why?
>
> Because - the mac updates itself! No pain, no installation,
> no keeping-up with mailing lists/announcements, just <click> and its done.

Aren't PC-BSD's PBI's working the same way? I know it is their goal.
Have you evaluated that? If so, what were your experiences?
--
Mel

[Kurt Jaeger]

Hi!

> For example if one wants an e-mail server, that is better
> served in the long run by IMAP+MTA than any form of Exchange, because
> you are not tied to one single platform and that vendor's lunacy.

In the field, many customers are drawn into the world of
Exchange and related technologies because of groupware features
that are not easy to replicate without it.

Once they are in that world, it's very tough to climb back out.

--
p...@opsec.eu +49 171 3101372 8 years to go !

[Fritz Wuehler]

You wrote:

> On Fri, Jun 01, 2012 at 05:20:39PM +0200, Nomen Nescio wrote:
> > Maybe FreeBSD should consider migrating to pkgsrc?
>
> I'm not arguing that your other points are invalid (in particular,
> I agree that the xorg change was really painful, and for a long time
> amd64 lagged i386 badly), but there is one very major blocker for this
> particular idea. If you browse the following URL:
>
> http://wiki.freebsd.org/PackageSystemsComparison
>
> You'll see that pkgsrc is around 12k packages. Although our graph
> is stale, per the portsmon/FreshPorts URLs, we're approaching 24k
> ports.
>
> So: while it's been suggested before, it's not really workable.

I am not in a position to know, but it seems to me the number of ports at
some point isn't that big of a deal vs. how well the ports build, and on how
many architectures they're available. First, is it possible to automate the
conversion of ports to pkgsrc? If not, how much of it could be automated?
How many of those 24,000 ports are actively maintained and build correctly?
If they're all active and work then yeah I think everyone would agree it
would take a lot of convincing to get those maintainers to switch to another
system, but does anyone know how many of those guys aren't *already*
maintaining pkgsrc packages for the same app? Often one maintainer does
packaging for multiple BSD and/or Linux distros. So there could be lots of
overlap and just looking at the two numbers you posted doesn't really tell
the whole story.

[Mark Linimon]

On Sun, Jun 03, 2012 at 01:43:43AM +0200, Fritz Wuehler wrote:
> So there could be lots of overlap and just looking at the two numbers
> you posted doesn't really tell the whole story.

No, I agree that it doesn't. I was just trying to add an aside, and
point out that the task would not be trivial.

Since I'm heavily invested in FreeBSD ports I think I need to step back
and let other folks comment in this thread.

mcl

[Erich]

Hi,

On 02 June 2012 PM 4:07:23 Alexander Yerenkow wrote:
> I'll try to be short.
> I'm using FreeBSD both at servers and as a desktop, but I see
> struggling of my friends with it in some things.
>
> 1. Ports mess. You can very easily render system unusable, or broken
> if you trying to use latest ports. And then you had to became "a port
> master" to fix all. Of course you need a lot of free time, right? :)

this seems to be ignored. I have just a small discussion in the thread Why are you using FreeBSD about this. It would be already a step forward to help people out of this fix when the ports tree of release would be easily available.

> 2. No decent packet manager (I hope pkgng will make life easier). You
> can't just upgrade this and that packet and see what's new, and
> rollback if you don't like somthing .

I really hope this will never come. Why? It will kill make install. Make install is the key to FreeBSD.

I believe a better solution would be versioning of the ports tree. When the ports tree compiles fully, it can be saved and its version number incremented.

I do not believe that much more would be needed. Of course, we have then a huge number of versions. Would it matter? Give the ports tree the major version number of the latest release. So, at the moment it would be 10. Increment then the minor every hour if you want. Just make sure that the ports tree can be downloaded for some time under this version number.

> 3. "FreeBSD is not a linux" - so FreeBSD avoid linuxisms, like KMS
> etc. And when it became crystal clear that progress is inevitable, we
> need wait few more years to get new graphics working. Some time ago, I
> read somewhere on wiki proud phrase "We are more linux than linux
> itself", it was about LSB test or something similar. FreeBSD can deny
> linux ways, but it's here, and it's widespread standard (at least in
> comparing with FreeBSD). FreeBSD do really need those fancy new techs,
> at least which related to X/hardware. XEN is one more thing, which
> could be attractive, but there's not much progress. I don't say let's
> rewrite all as in linux. I'm saying about having copatibility layer a
> bit fresher.

Have you ever worked with Linux? They have so many new features which are pushed like crazy until they are forgotten again. But I agree. Something can be done about X.

> 5. Name public person behind Microsoft? yes, there are one. And from
> Google? And from Oracle? And from GNU? And from Linux? Human nature is
> such that any company/big product is replaced in his mind with person,
> at least partially. And there's no person behind FreeBSD. There are
> many collaborators, who rarely well known in world as FreeBSD
> developer. And this is how it's affect reality:

I think that there is a big misunderstanding in this when it comes to Linux. Yes, there is one guy but he does not have the money. Others have the money.

> - Please, big boss, give me 10mil for new cluster system run on Linux.
> - What's Linux?
> - It's product developed for 20 years by Linus, and in recent years
> got support by many major world companies (long list goes here).

It was the luck of Linus that he used GPL and somebody announced an OS but did not have a kernel.

> P.S. Of course FreeBSD is great, and I'm using it, and I glad that it
> here, and all developers are awesome, no offence here ;)
>

It is also the question if this would make sense in the spirit of FreeBSD.

I have to run Fedora on one machine. The fast development there comes with a price. I installed Fedora and the applications I needed before I started to travel. I have had the chance to upgrade after 2 weeks. Hey, this was like Windows. Fedora downloaded more than 600 MB after just two weeks.

I know, it can be even worse on FreeBSD when things like jpeg or png change.

Erich

[Matthew Seaman]

On 03/06/2012 02:21, Erich wrote:
>> 2. No decent packet manager (I hope pkgng will make life easier). You
>> > can't just upgrade this and that packet and see what's new, and
>> > rollback if you don't like somthing .

> I really hope this will never come. Why? It will kill make install.
> Make install is the key to FreeBSD.

I doubt very much indeed that pkgng will "kill make install." What it
will do is fill in a widely recognised gap in FreeBSD's offering: that
FreeBSD is essentially unmanageable at the moment only using binary
packages.

While compiling from ports really is the gold standard for tunability,
configurability and lots of other good things, it lacks quite a lot in
terms of speed and convenience for most users. This is something that
turns off lots of new users coming from Linux or MacOSX before they have
really had a chance to get to grips with the OS and start to appreciate
its finer qualities. Somewhere that FreeBSD does itself absolutely no
favours.

The ideal which I think is attainable with pkgng is to be able to use
the ports to compile your own customized versions of the applications
which are critical to you, but otherwise rely on pre-compiled packages
for anything else.

Also, consider people developing embedded devices (and this is going to
be a *major* area for FreeBSD in the future) -- you want to compile
software offline (probably cross-compiling on a completely different
architecture), strip out inessential documentation and so forth and
manage precisely what is installed on your device using an efficient
binary package manager. pkgng promises to make this feasible.

PC-BSD's .pbi package format is another way of addressing this same sort
of problem, and although originally aimed at desktop users it makes a
lot of sense for server side usage too. As .pbi and pkgng are actually
complimentary, rather than in competition, expect some interesting
developments in the relatively near future.

> I believe a better solution would be versioning of the ports tree.
> When the ports tree compiles fully, it can be saved and its version
> number incremented.

This is simply a non-starter. Remember what the ports tree is: *third
party software* ported to run on FreeBSD. That 3rd party software is
going to continue to be developed at its own pace without any reference
to the FreeBSD project. You can't just choose a point in time for the
ports tree and expect it to keep working effectively. Particularly not
if you admit the possibility of updating some packages for security
reasons or other egregious bugs. Nor will most users be content with
running year-or-more old versions of most software packages.

In fact, one of the big plusses of the ports is how up to date it
generally is. Most big packages are updated in the ports within days of
updates being published upstream.

> I do not believe that much more would be needed. Of course, we have
> then a huge number of versions. Would it matter? Give the ports tree
> the major version number of the latest release. So, at the moment it
> would be 10. Increment then the minor every hour if you want. Just
> make sure that the ports tree can be downloaded for some time under
> this version number.

What exactly is this supposed to solve? Simply attaching a number to
the ports tree won't do anything. There is already a promise that the
ports should work on all supported FreeBSD release branches. Besides,
with the imminent switch of the ports from CVS to SVN, there will soon
be a global revision number for the whole ports tree.

Cheers,

Matthew

--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey

[Chris Rees]

On Jun 3, 2012 4:39 AM, "Erich" <erichfre...@ovitrap.com> wrote:
>
> Hi,
>
> On 02 June 2012 PM 4:07:23 Alexander Yerenkow wrote:
> > I'll try to be short.
> > I'm using FreeBSD both at servers and as a desktop, but I see
> > struggling of my friends with it in some things.
> >
> > 1. Ports mess. You can very easily render system unusable, or broken
> > if you trying to use latest ports. And then you had to became "a port
> > master" to fix all. Of course you need a lot of free time, right? :)
>
> this seems to be ignored. I have just a small discussion in the thread
Why are you using FreeBSD about this. It would be already a step forward to
help people out of this fix when the ports tree of release would be easily
available.
>
> > 2. No decent packet manager (I hope pkgng will make life easier). You
> > can't just upgrade this and that packet and see what's new, and
> > rollback if you don't like somthing .
>
> I really hope this will never come. Why? It will kill make install. Make
install is the key to FreeBSD.
>
> I believe a better solution would be versioning of the ports tree. When
the ports tree compiles fully, it can be saved and its version number
incremented.

The Ports Tree is very rarely in a broken state-- the vast majority of
commits are thoroughly tested and nearly all ports will always compile on a
clean system.

> I do not believe that much more would be needed. Of course, we have then
a huge number of versions. Would it matter? Give the ports tree the major
version number of the latest release. So, at the moment it would be 10.
Increment then the minor every hour if you want. Just make sure that the
ports tree can be downloaded for some time under this version number.

This is already possible....

Chris

[Adam Strohl]

On 6/3/2012 10:09, Mark Linimon wrote:
> On Sun, Jun 03, 2012 at 01:43:43AM +0200, Fritz Wuehler wrote:
>> So there could be lots of overlap and just looking at the two numbers
>> you posted doesn't really tell the whole story.
> No, I agree that it doesn't. I was just trying to add an aside, and
> point out that the task would not be trivial.
>
> Since I'm heavily invested in FreeBSD ports I think I need to step back
> and let other folks comment in this thread.

I manage and support a little over 50 FreeBSD servers (VMWare, Xen and
native) and feel that the port system, on the whole, is excellent. Its
easily one of the best features about FreeBSD. Portaudit reports
issues and I can plan and upgrade them as needed. Portupgrade works
great 99% of the time and when it doesn't it has the good sense to roll
back what its done. If there is any question as to what it should do it
errors and tells me, which is exactly what I want it to do.

I've been a FreeBSD user for about 18 years and supported it
professionally for about 10. In this thread I've read a few posts that
contain blanket statements like "ports are broken" and "never work", I'm
at a loss as to how to respond to this as it is completely counter to my
experience. I wish I could see what they were talking about and figure
out what happened so I could understand what caused them to make such a
statement. It's like they're talking about a different OS than the one
I know.

I've written a simple script to run portaudit and pop up a dialog with
check boxes that then kicks off portupgrade for the selected ports which
have issues. 99% of the time its that simple. This is what I want in
a server environment. I do not want things auto-updating (a.k.a. auto
breaking) or making decisions about supporting libraries behind my back.
PHP is a good and common example why: an upgrade can and does break
web sites that ran fine before. Updates need to be managed in a
process which is outside the scope of the OS (because its a server not a
desktop). FreeBSD has all these great tools for managing the mechanical
action of updating and imposes minimal process which is perfect because
I have my own process. And if things get mucked up (which mostly isn't
the ports system fault when it does happen), its easy to back out and
re-do if needed.

After reading this thread I am wondering if I should clean the update
dialog script up and submit to the ports tree. It seems like people
think the port update process is harder than it is because it lacks a
Windows Update like dialog which is essentially what this is akin to
(and there might be a port which does this already, too .. anyone?).
All the hard stuff has been done by the FreeBSD team, all I did was put
a bash/dialog script on it.

I very rarely run into ports that don't build on supported versions of
FreeBSD (ie; ones that haven't reached EoL). I have a number of
customers with a few 6.2 boxes [which I can't wait to upgrade] and still
almost everything builds without tinkering.

All of this is in the scope of servers though (web, DB, application,
etc) and not on the desktop. I haven't used a FreeBSD desktop since
probably 4.x, and while I don't begrudge the work people are doing for
the desktop experience it just doesn't apply to me nor is it why I love
FreeBSD. I won't say something like "you're running a server OS on
your desktop and expecting it to be like a Mac". What will say is: I'm
getting from this thread that a lot of the complaints people have seem
to be based around the desktop. My guess is that this is a super
minority of actual use (by server count).

BUT: I feel like people are judging how fit an FreeBSD is for server
work by how easy/Mac/Windows/whatever like (as many Linux distros try to
emulate) it is to update. Not good ... but it makes sense from a
social/human perspective, and is probably another thing we should
consider in terms of advocacy.

I'm interested in what people think about this, and yeah this should
probably be in the advocacy list but its not so thhblt :P

[Mehmet Erol Sanliturk]

On Sun, Jun 3, 2012 at 3:08 AM, Adam Strohl
<adams-...@ateamsystems.com>wrote:

Always I am stressing that to manage FreeBSD, a fair amount of expertise
is required which I think this level may be reduced by improving the
FreeBSD management by transferring knowledge to its managing parts ( for
example : package management , repair of broken parts , installation steps
to reach a state like in very easily usable Linux distributions such as
Fedora , Mageia , Mandriva , and many others , etc. )

You know what to do by your expertise gained over use , which such an
expertise is completely missing in a new comer , and even sometimes in very
highly experienced computer professionals because a different operating
system reduces them to a little experienced new starter .

As an example :

I have installed FreeBSD 9.0 amd64 Release . In root use , it is
successfully mounting USB sticks and USB NTFS hard disks in KDE4 and GNOME
.

In user mode , it could NOT be possible either to automount USB sticks or
NTFS USB hard disks .


Obviously , everything is set how they are written in Handbook , but NOT
working for ME .


Dolphin is given a message pointing to HAL Policy Kit . When PolicyKit is
searched , it is generating a very long file list which many of them are
with the same name in different directories . One of them is responsible
from the error message generation . Which one ? Look at the sources : To
where ?
Look at their web site : Nothing is there .


They are working in GhostBSD . Which files are modified by GhostBSD which
they are different ones
in FreeBSD ? When number of related number of files are considered , it is
very difficult to find the differences .

After struggling with many fruitless steps , there remains ONLY another
step :

SWITCH to ANOTHER operating system .

It should be remembered that struggling is a TIME EXPENSE and IT IS COSTED .

Compare the cost of a Linux or Windows and personal time , and make a
decision which one to choose .

Another point frequently mentioned is that FreeBSD is leaned toward servers
.
Only I want to say that , "Please , install a CentOS , Debian , or Windows
Server trial , and see how a server may be ..."




Thank you very much .


Mehmet Erol Sanliturk

[Adam Strohl]

On 6/3/2012 17:51, Mehmet Erol Sanliturk wrote:
> Always I am stressing that to manage FreeBSD, a fair amount of expertise
> is required which I think this level may be reduced by improving the
> FreeBSD management by transferring knowledge to its managing parts ( for
> example : package management , repair of broken parts , installation steps
> to reach a state like in very easily usable Linux distributions such as
> Fedora , Mageia , Mandriva , and many others , etc. )

Yeah or a GUI to reduce the need for knowledge transfer.

> You know what to do by your expertise gained over use , which such an
> expertise is completely missing in a new comer , and even sometimes in very
> highly experienced computer professionals because a different operating
> system reduces them to a little experienced new starter .
>

I agree and your issue with USB sticks proves my point. I've never
tried to mount an NTFS USB stick and I'm OK with that. But for you it
is a big hassle (understandably so) and it has definitely negatively
impacted your view of FreeBSD.

> Compare the cost of a Linux or Windows and personal time , and make a
> decision which one to choose .
>
> Another point frequently mentioned is that FreeBSD is leaned toward servers
> .
> Only I want to say that , "Please , install a CentOS , Debian , or Windows
> Server trial , and see how a server may be ..."

I manage Windows, CentOS and Debian (and RedHat and a few others)
servers too. I've found FreeBSD is more reliable on the whole and
takes less time to maintain (which means less expensive for my clients).
This is one area where FreeBSD shines. And when things do break it is
possible to recover fairly easily. That is another.

And yes, in terms of that initial learning curve my experience helps but
its the OS that is doing the work here. If I was more experienced with
Windows or Linux it wouldn't make them any easier to update, either
though. So there is a point at which "knowing what to do" stops being
the limiting issue and its just "ok well this is broken now and it can't
be cost-effectively fixed". That crossover point is something that is
almost never reached with FreeBSD in my experience.

All of this is completely parallel and unrelated to your (or another
person's) experience as a desktop user though. What you see is "USB
thumbdrives don't work" :) So you decide to use another OS, and
probably wouldn't advocate for FreeBSD if presented the chance in a
server context because of that experience. That is a shame in my book.
(I know I'm putting words in your mouth but its simply to illustrate my
thinking on how public perception is formed).

[Erich Dollansky]

Hi,

On 03 June 2012 PM 5:08:44 Adam Strohl wrote:
> On 6/3/2012 10:09, Mark Linimon wrote:
> > On Sun, Jun 03, 2012 at 01:43:43AM +0200, Fritz Wuehler wrote:
> >> So there could be lots of overlap and just looking at the two numbers
> >> you posted doesn't really tell the whole story.
> > No, I agree that it doesn't. I was just trying to add an aside, and
> > point out that the task would not be trivial.
> >
> > Since I'm heavily invested in FreeBSD ports I think I need to step back
> > and let other folks comment in this thread.
>
> I manage and support a little over 50 FreeBSD servers (VMWare, Xen and

servers are a bit different as the tricky ports are not installed there.

> native) and feel that the port system, on the whole, is excellent. Its

Yes, it is. But is this a reason to stop improving it a little bit. Just a little bit for the cases something went wrong.

> easily one of the best features about FreeBSD. Portaudit reports
> issues and I can plan and upgrade them as needed. Portupgrade works
> great 99% of the time and when it doesn't it has the good sense to roll
> back what its done. If there is any question as to what it should do it
> errors and tells me, which is exactly what I want it to do.
>

I do not share the 99% for a server which runs some thin clients. But still, it makes life easy.

> I've been a FreeBSD user for about 18 years and supported it
> professionally for about 10. In this thread I've read a few posts that
> contain blanket statements like "ports are broken" and "never work", I'm
> at a loss as to how to respond to this as it is completely counter to my
> experience. I wish I could see what they were talking about and figure

I mentioned already one example. I install a plain FreeBSD on new hardware. I download the current ports tree and start compiling X then.

I do this intentionally meanwhile as this did not work in a single case since around summer 2007 for me.

I first reported this. I then tried to fix the make files myself. I could not find a working solution.

Anyway, I always get a working system with some manual work. One time it is the left corner, one time it is the right corner where the problems hide. Do not ask me why it is so.

After compiling X once on a machine, it is never a problem compiling it again.

> out what happened so I could understand what caused them to make such a
> statement. It's like they're talking about a different OS than the one
> I know.
>

I know BSD since the end of the seventies from DEC hardware. This is the main reason why I am using it now. I think that I made the same mistake in thinking as you before. Hey, the OS is perfect. We are talking here about a real small problem when installing applications. Other operating systems would be happy if their problems would be that small.

> I've written a simple script to run portaudit and pop up a dialog with
> check boxes that then kicks off portupgrade for the selected ports which
> have issues. 99% of the time its that simple. This is what I want in
> a server environment. I do not want things auto-updating (a.k.a. auto
> breaking) or making decisions about supporting libraries behind my back.

Again, I did not experience these problems on a typical server. Just on servers which run thin clients or real desktop machines.

> After reading this thread I am wondering if I should clean the update
> dialog script up and submit to the ports tree. It seems like people
> think the port update process is harder than it is because it lacks a
> Windows Update like dialog which is essentially what this is akin to
> (and there might be a port which does this already, too .. anyone?).
> All the hard stuff has been done by the FreeBSD team, all I did was put
> a bash/dialog script on it.

I do not know if I suggested this here once. A small site which collects these things would be good. But who will maintain it.

>
> I very rarely run into ports that don't build on supported versions of
> FreeBSD (ie; ones that haven't reached EoL). I have a number of
> customers with a few 6.2 boxes [which I can't wait to upgrade] and still
> almost everything builds without tinkering.
>

As I said before, it is not the updating as such, it is the time it will take when you do not have the time.

> All of this is in the scope of servers though (web, DB, application,
> etc) and not on the desktop. I haven't used a FreeBSD desktop since
> probably 4.x, and while I don't begrudge the work people are doing for
> the desktop experience it just doesn't apply to me nor is it why I love
> FreeBSD. I won't say something like "you're running a server OS on
> your desktop and expecting it to be like a Mac". What will say is: I'm
> getting from this thread that a lot of the complaints people have seem
> to be based around the desktop. My guess is that this is a super
> minority of actual use (by server count).
>

Isn't this the problem FreeBSd has? I would like to see more people using it there.

> BUT: I feel like people are judging how fit an FreeBSD is for server
> work by how easy/Mac/Windows/whatever like (as many Linux distros try to
> emulate) it is to update. Not good ... but it makes sense from a
> social/human perspective, and is probably another thing we should
> consider in terms of advocacy.
>

YYYYYYYYYYYYYYYEEEEEEEEEEEEEEEEEESSSSSSSSSSSSSSSSS

You got the point. This is all we are talking about. You found the proper words for it.

All other users of FreeBSD do not have a problem with these little things. You have written your script, I have written my script. You know what knob to turn, I know what knob to turn.

But the newcomer who wants to do some for the first time gets easily stuck here.

Erich

[Mehmet Erol Sanliturk]

On Sun, Jun 3, 2012 at 4:58 AM, Adam Strohl
<adams-...@ateamsystems.com>wrote:

All of us are here for like and love for FreeBSD and to make it much more
better than the present state .

Our goal is to identify gaps and missing parts to fill the gaps and to
generate missing parts .

Without doing this it is unlikely that FreeBSD will advance by itself . We
should be helpful to developers by bringing issues to agenda .

Actually and really FreeBSD is a very high quality operating system as a
design and an implementation . With its that structure it is an important
contribution to humanity welfare . For this , we really thank very much to
its developers and supporters in any way .

All over the years , my most stressed issue is its "easiness of usability"
, not for my own benefit but for the "normal" users . I can solve my
problems in any way , but the other people are not so much experienced and
they are living without benefiting from FreeBSD .

Since 1970 , I am in this area ( computing ) .

If there were NOT FreeBSD or Linux , we will , MOST LIKELY perhaps still
use a console mode operating system with painted by a useless windowing
program . If you remember the history , Intel 386 with its 32-bit structure
appeared around 1985 , and a famous operating system , perhaps understood
that there is no other way than doing this , produced its 32-bit , again
painted console mode operating system at 1995 , after 10 years , perhaps
because , their vision was that a 640 Kilo Bytes program would be much more
than requirements of the people .

The contributions made by FreeBSD should NOT be forgotten .


A few days ago I was suggesting to a professor to use a Unix which was very
fond of computer usage too much at the beginning . He asked "Which Unix ?"
. He is just a "user" in a different field than in "Computer Sciences and
Engineering" . Which Unix you can advise to use by him ?

Please think alternatives : ( I am NOT trying to insult any one , please
understand in that way . )

FreeBSD : Installation is now easy . Use : Impossible because of installed
structure .
PC-BSD : Installation and then use is not possible ( I am trying each one
by one , perhaps one day
I can reach to a working release ) .
GhostBSD : Installation is easy . Use is Easy . It is based on only GNOME .
Personally I do NOT like GNOME very much and I am NOT
using it .

Linux : ( Fedora , Mandriva , Mageia , and many others ) Wonderful . I can
not think any other choice other than LInux to suggest to ONLY a user which
he/she will install and use the system .

Please , do NOT forget that server installers and maintainers are computer
professionals having sufficient training to work on such a job .

The point is this .

Thank you very much .

Mehmet Erol Sanliturk

[Erich Dollansky]

Hi,

are you talking about the Fedora I have installed here?

> not think any other choice other than LInux to suggest to ONLY a user which
> he/she will install and use the system .

I am not so sure if this will work. At least not on my machine. I did a standard install as I expect to replace this installation with FreeBSD when I have a bit more time at hand.

I noticed meanwhile two problems which are show stoppers for normal users. After the notebook was put to sleep, it was literally put to sleep, at least partially. I could not fire out what was wrong as the user interface still worked. I got many error messages that writes to sockets failed. So, I assume writing to sockets died.

The next thing are updates. After downloading some 600MB of updates via the GUI tool, I could not install a single package with it anymore. I have had to go to the console and use yum install to get things installed.

If a user manages this, the same user will manage FreeBSD too.

If a user does not manage this, Windows will be back on the machine.

>
> Please , do NOT forget that server installers and maintainers are computer
> professionals having sufficient training to work on such a job .
>

Yeah, FreeBSD is also very easy for me to handle. For my wife? No, she complains then that this was working under Windows even when she never saw it working under Windows.

Erich

[Zane C. B-H.]

On Fri, 1 Jun 2012 14:15:55 +0200
Kurt Jaeger <li...@opsec.eu> wrote:

> <snip>
> - Windows Terminalserver functionality
> <snip>

If you mean the lack of something similar in regards to reconnecting
sessions, you may find xpra to be of interest to you.

[Zane C. B-H.]

On Sat, 2 Jun 2012 16:07:23 +0300
Alexander Yerenkow <yere...@gmail.com> wrote:

> I'll try to be short.
> I'm using FreeBSD both at servers and as a desktop, but I see
> struggling of my friends with it in some things.
>
> 1. Ports mess. You can very easily render system unusable, or broken
> if you trying to use latest ports. And then you had to became "a
> port master" to fix all. Of course you need a lot of free time,
> right? :)

This is not a FreeBSD specific issue. Regardless of the OS in
question, one needs to make sure to run it all in a test environment
first before pushing it out.

> 2. No decent packet manager (I hope pkgng will make life
> easier). You can't just upgrade this and that packet and see what's
> new, and rollback if you don't like somthing .

Actually rolling back is completely possible as the ports tree is in
a vcs. Just roll back to the last working version of a port you are
having issues with and make sure it is set to not be updated next
time up update the tree.

> 3. "FreeBSD is not a linux" - so FreeBSD avoid linuxisms, like KMS
> etc. And when it became crystal clear that progress is inevitable,
> we need wait few more years to get new graphics working. Some time
> ago, I read somewhere on wiki proud phrase "We are more linux than
> linux itself", it was about LSB test or something similar. FreeBSD
> can deny linux ways, but it's here, and it's widespread standard
> (at least in comparing with FreeBSD). FreeBSD do really need those
> fancy new techs, at least which related to X/hardware. XEN is one
> more thing, which could be attractive, but there's not much
> progress. I don't say let's rewrite all as in linux. I'm saying
> about having copatibility layer a bit fresher.

This is question of time of the people involved. I can't say I've
seen any one saying new features like KMS should not be added because
it is to Linux like.

> <snip>

[Franci Nabalanci]

I am not a computer educated person but maybe I am like your professor (I
am in genetics).
I start with DOS, OS/2, Linux and last three years I am on FreeBSD. I don't
have a server but I use console a lot, Fluxbox and KDE.
I never tried PC BSD but it is FreeBSD and because that I will recommended
him FreeBSD which is IMO more stable than Linux which I am 'friendly" too
:).

On Sun, Jun 3, 2012 at 8:12 AM, Mehmet Erol Sanliturk <
m.e.sa...@gmail.com> wrote:

> On Sun, Jun 3, 2012 at 4:58 AM, Adam Strohl
> <adams-...@ateamsystems.com>wrote:
>
> > On 6/3/2012 17:51, Mehmet Erol Sanliturk wrote:
> >
> >> Always I am stressing that to manage FreeBSD, a fair amount of
> expertise
>
>
>
>

[Mel Flynn]

There's one problem that can never practically be solved and one that
isn't being tested by maintainers because of Tinderbox.

The first is that very fast the possible number of combinations
introduced with options goes out of range of a human life time. This is
especially true for GUI components.
Other operating systems referenced here are no comparison, since they
simply do not provide those kinds of choices for 3rd party software.

The second issue is that Tinderbox processes each port stage separately,
starting with a clean system. This hides bugs that only come out when
the various stages are chained or when a ports management tool removes
and tries to reinstall a port in the dependency chain.
In a few cases there are hidden circular dependencies caused by runtime
loading.

Once the base system supports binary upgrades of packages through pkgng
it should solve a lot of issues that people have with production systems
now, though there are already people that are deploying custom built
binary packages to their production systems using a "wipe and reload"
approach.
--
Mel

[O. Hartmann]

... I highly doubt this view!

> program . If you remember the history , Intel 386 with its 32-bit structure
> appeared around 1985 , and a famous operating system , perhaps understood
> that there is no other way than doing this , produced its 32-bit , again
> painted console mode operating system at 1995 , after 10 years , perhaps
> because , their vision was that a 640 Kilo Bytes program would be much more
> than requirements of the people .

Well, I regeret that in most cases the most aggressiv nonsense makes the
run. This very famous operating system was no competition to so many
other window based operating systems that time. Most of the windowing
systems I remember of in that time where derived from X11 or Apples vision.

And, by the way, compared the Intel x86 legacy crap in my recent box
compared to the DEC Alpha AXP or the MIPS based platforms with either
OSF/1 or BSD/4.3 or 4.4 is much more hurting!

>
> The contributions made by FreeBSD should NOT be forgotten .
>
>
> A few days ago I was suggesting to a professor to use a Unix which was very
> fond of computer usage too much at the beginning . He asked "Which Unix ?"
> . He is just a "user" in a different field than in "Computer Sciences and
> Engineering" . Which Unix you can advise to use by him ?

... it is ALL about PR! That is, why my department is driven by managers
and the IT by people which pretend having knowledge (they never where in
computer science and all their knowledge comes from fancy weekly magazines).

>
> Please think alternatives : ( I am NOT trying to insult any one , please
> understand in that way . )
>
> FreeBSD : Installation is now easy . Use : Impossible because of installed
> structure .
> PC-BSD : Installation and then use is not possible ( I am trying each one
> by one , perhaps one day
> I can reach to a working release ) .
> GhostBSD : Installation is easy . Use is Easy . It is based on only GNOME .
> Personally I do NOT like GNOME very much and I am NOT
> using it .
>
> Linux : ( Fedora , Mandriva , Mageia , and many others ) Wonderful . I can
> not think any other choice other than LInux to suggest to ONLY a user which
> he/she will install and use the system .
>
> Please , do NOT forget that server installers and maintainers are computer
> professionals having sufficient training to work on such a job .

You really believe this is in general that way? I can proff you wrong!

[Dave Hayes]

Gary Palmer <gpa...@freebsd.org> writes:
> Have you looked at VirtualBox? /usr/ports/emulators/virtualbox-ose
> Its not a fully featured replacement for vSphere (e.g. no equivalent
> of vMotion) but it is a perfectly workable virtualisation solution
> for a number of situations.

I don't necessarily need vMotion. Thanks greatly for the tip, which is
very valuable and the reason I like discussions like these.

As I am trying to try this, of course I ran into a snag. This snag is
very relevant to the current discussion(s) about ports and "ease of use".

# cd /usr/ports/emulators/virtualbox-ose
# make config

I'm now presented with a number of options, but no real documentation
for what these options actually mean (to say nothing of the -fine
points- which can be drastically important). I can pretty much guess Qt4
is for a GUI frontend, but pulseaudio? Eh? Why do I need sound,
especially pulseaudio, in a virtualbox hypervisor? What is VDE? Do I
really need that to do intra-virtual-box networking at all or are there
other solutions?

I know. Google is a resource. Still, would it kill us to have some sort
of extra file of textual documentation lying around for each port that
explained each option in a bit more depth, what ports it will try to
include, and why you'd want it or not want it?

Ok so continuing...

# make install
...way later...
In file included from socket/qabstractsocket.cpp:2927:
.moc/release-shared/moc_qabstractsocket.cpp:14:2: error: #error "This file was generated using the moc from 4.7.4. It"
.moc/release-shared/moc_qabstractsocket.cpp:15:2: error: #error "cannot be used with the include files from this version of Qt."
.moc/release-shared/moc_qabstractsocket.cpp:16:2: error: #error "(The moc has changed too much.)"

Here you "just have to know" that this kind of an error likely means
that the qt4-moc port is out of date. At this point, a "normal" user
gives up. (A smarter "normal" user gave up when they couldn't figure out
what the port options really meant.)

When I talk about documentation and support being unavailable, this is a
decent example of what I mean. I see features and pkgng and things being
offered up as solutions...these are all well and good, but in my opinion
more comprehensive documentation and support in these areas would do
more good than pkgng. Even for us seasoned experts, installing
something new out of ports is sometimes met with at least an hour of
googling, re-compiling, re-installing, and struggling. It goes smoothly
often enough, but IMO not often enough for prime time.

All these ideas presume that the FreeBSD community wants more users. I
have a vague impression that a percentage of the community really
doesn't. I'm not commenting on this other than to say I understand both
sides and that my comments really only make sense if FreeBSD as a
community really does want more users. :)

Anyway, given my workload, it will probably take me a man week to get
two virtualized test servers. Someone I know with a vmware gui and
windows is doing this in 15 minutes (and that's being careful).

Just my $0.02.
--
Dave Hayes - Consultant - Altadena CA, USA - da...@jetcafe.org
>>> The opinions expressed above are entirely my own <<<

There's only one corner of the universe you can be certain
of improving and that's your own self.

[Mark Linimon]

On Sun, Jun 03, 2012 at 09:31:19PM +0200, Mel Flynn wrote:
> Once the base system supports binary upgrades of packages through pkgng
> it should solve a lot of issues that people have with production systems
> now

IMHO, s/solve/expose/ :-) It will then be up to use to solve them.

mcl

[Dave Hayes]

Mark Linimon <lin...@lonesome.com> writes:

> On Sun, Jun 03, 2012 at 07:24:11PM -0700, Dave Hayes wrote:
>> I see features and pkgng and things being offered up as solutions...
>> these are all well and good, but in my opinion more comprehensive
>> documentation and support in these areas would do more good than pkgng.

> IMHO pkgng and optionsng are necessary, but not sufficient, to solve
> our current problems.

Optionsng is nice, but lacking in documentation. Is it too much to ask
port maintainers to write a bit more documentation on the options they
are providing?

--
Dave Hayes - Consultant - Altadena CA, USA - da...@jetcafe.org
>>> The opinions expressed above are entirely my own <<<

Sunshine proves it's own existence.

[Chris Rees]

On Jun 4, 2012 9:50 AM, "Dave Hayes" <da...@jetcafe.org> wrote:
>
> Mark Linimon <lin...@lonesome.com> writes:
> > On Sun, Jun 03, 2012 at 07:24:11PM -0700, Dave Hayes wrote:
> >> I see features and pkgng and things being offered up as solutions...
> >> these are all well and good, but in my opinion more comprehensive
> >> documentation and support in these areas would do more good than pkgng.
> > IMHO pkgng and optionsng are necessary, but not sufficient, to solve
> > our current problems.
>
> Optionsng is nice, but lacking in documentation. Is it too much to ask
> port maintainers to write a bit more documentation on the options they
> are providing?

Where are you looking? I updated the Porter's Handbook- is there something
missing?

Chris

[Daniel Kalchev]

On 04.06.12 05:24, Dave Hayes wrote:
> Anyway, given my workload, it will probably take me a man week to get
> two virtualized test servers. Someone I know with a vmware gui and
> windows is doing this in 15 minutes (and that's being careful). Just
> my $0.02.

You are unfortunately comparing apples with oranges here.

If you want true comparison, compare how fast you will have VirtualBox
OSE up and running on both FreeBSD and Windows. Both of you start with a
system where it has to be compiled and installed. I guess your Windows
friend will stop at "compiler? what?".
You can't get the source code of vmware and compile it yourself, of
course.. that's just another little detail.

Not the same? They get the thing pre-compiled? So could you.

Thing is, once you go trough the trouble to install VirtualBox on
FreeBSD you get a lot more usable vrtualization platform, with things
like ZFS that aren't going to be available on Windows.

It was mentioned a number of times already, that if you want to run
"binary only" you would be better with PC-BSD -- and system based on
FreeBSD (so it has most, but not all of the goodies), and someone else
pre-compiles and pre-packages software for you. Just one click install.

So, if you used PC-BSD, you could have had VirtualBox running perhaps
for the same time an Windows user would.

There is place for binary-only systems and systems where you are able to
rebuild everything from source. FreeBSD tends to focus on the later
while various folk (like PC-BSD) use the great FreeBSD platform to offer
easier to use binary only systems. Of course, you could use the FreeBSD
ports tree and build from source on PC-BSD too.

Daniel

[Victor Balada Diaz]

On Fri, Jun 01, 2012 at 05:03:26AM -0700, Mehmet Erol Sanliturk wrote:

> Dear All ,
>
> There is a thread
>
> "Why Are You Using FreeBSD ?"
>
>

Hello,

I'm using FreeBSD for most of my tasks and servers and i think it's great, but
this things could be improved:

- Good FUSE support. On the desktop side, you can't use NTFS for write access.
On the server side, you miss things like Gluster. You can't run things like
truecrypt because they need it and things like geli/gbde doesn't work on
anything but FreeBSD. Ie: FUSE is needed for interoperability.

- Easier way to replicate FreeBSD infrastructure. I've found that maintain 1 server
on FreeBSD is great. Requires lower maintenance that any other operating system.

Once you start managing 20 or 30 things change. Suddenly you find yourself needing
automated package building because ports are not versioned, so you must copy
the repo, maintain local patches and build a tinderbox.

If you find problems on a FreeBSD version and need patches you need to
build a freebsd-update server to still use it, or start maintaining servers
on two different ways: source and binary, which just adds testing time. Would be
better if you could switch from source to binary and back in a easier way.

- Hardware support. If you want to build a server on new atom boards, you
will have problems, eg:

http://www.freebsd.org/cgi/query-pr.cgi?pr=amd64/166639

Same with laptop and other kind of hardware. Not just on computers, but also
on peripherals. AFAIK no single all-in-one printer works fully with FreeBSD, so
it's hard to configure as print/scan server.

- I/O performance: If you do heavy I/O, the system becomes unresponsive. I've read a few
days ago on the lists that it was a problem related to priorizing writes over reads
and the recommendation was to use gsched, but haven't had time to check.

Regards.
Victor.

--
La prueba m�s fehaciente de que existe vida inteligente en otros
planetas, es que no han intentado contactar con nosotros.

[xenophon\+freebsd]

> -----Original Message-----
> From: owner-free...@freebsd.org [mailto:owner-freebsd-
> sta...@freebsd.org] On Behalf Of Daniel Kalchev
> Sent: Saturday, June 02, 2012 12:42 AM
>
> I really see no reason why your 'mail or calendaring server'
> should be able to wipe your devices.. This is the sort of bloat
> that keeps me away. From Microsoft products.

I don't think that's fair to say. Email/calendaring seems to be the
only connection point between a smartphone and an organization for at
least the current crop of devices (although I'm sure that at some point
soon, you'll be able to include organizational file servers as well).
Even if you're just a SOHO or SMB, you should want to be able to locate
or remotely wipe a device that's stolen, if only to ensure that someone
doesn't have access to potentially sensitive personal information. Oh
and by the way, not only do the Windows phones feature this, but so do
the iPhones and the Android handsets - so this isn't just Microsoft.

> In this regard I rather prefer the way Apple handles things.
> Shiny wrapper interface to pretty much generic technology. No
> reinvention of the wheel and experiments to see if it can be made
> square.

You can't damn Microsoft for being too proprietary in one paragraph and
then praise Apple for its openness in the next. Does not compute.

Best wishes,
Matthew

--
I FIGHT FOR THE USERS

[Daniel Kalchev]

On 04.06.12 18:04, xenophon\+freebsd wrote:
>> -----Original Message-----
>> From: owner-free...@freebsd.org [mailto:owner-freebsd-
>> sta...@freebsd.org] On Behalf Of Daniel Kalchev
>> Sent: Saturday, June 02, 2012 12:42 AM
>>
>> I really see no reason why your 'mail or calendaring server'
>> should be able to wipe your devices.. This is the sort of bloat
>> that keeps me away. From Microsoft products.
> I don't think that's fair to say. Email/calendaring seems to be the
> only connection point between a smartphone and an organization for at
> least the current crop of devices (although I'm sure that at some point
> soon, you'll be able to include organizational file servers as well).

Again, what does your e-mail or calendaring service have to do with
wiping your device clean?? Wiping the device is task for your device
management platform, which does not belong to the e-mail or calendaring
platform. If you connect your desktop to Exchange, is it supposed to be
wiped too? What if the Exchange account is just one of the many e-mail
accounts you use, as typically is the case?

> Even if you're just a SOHO or SMB, you should want to be able to locate
> or remotely wipe a device that's stolen, if only to ensure that someone
> doesn't have access to potentially sensitive personal information. Oh
> and by the way, not only do the Windows phones feature this, but so do
> the iPhones and the Android handsets - so this isn't just Microsoft.

I understand you don't like it, but apparently Apple got this right.
They have device management tool that is in no way ties to your e-mail
or calendaring server. Not only Apple, but any sane vendor too.

It is not excuse that because some (censored) at Microsoft has designed
things this way, there are no other proper ways.

>> In this regard I rather prefer the way Apple handles things.
>> Shiny wrapper interface to pretty much generic technology. No
>> reinvention of the wheel and experiments to see if it can be made
>> square.
> You can't damn Microsoft for being too proprietary in one paragraph and
> then praise Apple for its openness in the next. Does not compute.

I don't care how proprietary an proprietary thing is. If it is correctly
implemented, it is ok, if it is not correctly implemented, it is not ok.
Microsoft's "wipe trough Exchange" is weird, to put it mildly.
Apple too had a track record of doing many proprietary things, but in
recent years their offerings are, as I mentioned earlier, pretty much
generic standard and widespread protocols with a lot of sugar coating.

Daniel

[Dave Hayes]

Chris Rees <uti...@gmail.com> writes:
> On Jun 4, 2012 9:50 AM, "Dave Hayes" <da...@jetcafe.org> wrote:
>> Mark Linimon <lin...@lonesome.com> writes:
>> > On Sun, Jun 03, 2012 at 07:24:11PM -0700, Dave Hayes wrote:
>> >> I see features and pkgng and things being offered up as solutions...
>> >> these are all well and good, but in my opinion more comprehensive
>> >> documentation and support in these areas would do more good than pkgng.
>> > IMHO pkgng and optionsng are necessary, but not sufficient, to solve
>> > our current problems.
>> Optionsng is nice, but lacking in documentation. Is it too much to ask
>> port maintainers to write a bit more documentation on the options they
>> are providing?
> Where are you looking? I updated the Porter's Handbook- is there something
> missing?

Yes there is...my point. :) Perhaps I was unclear. Optionsng is likely a
fine project. However, it does not include the idea of extra
documentation on the user selectable options provided to a port.

Often when building a port I am presented with a list of build options.
For example, virtualbox has this:

OPTIONS= QT4 "Build with QT4 Frontend" on \
DEBUG "Build with debugging symbols" off \
GUESTADDITIONS "Build with Guest Additions" off \
DBUS "Build with D-Bus and HAL support" on \
PULSEAUDIO "Build with PulseAudio" off \
X11 "Build with X11 support" on \
UDPTUNNEL "Build with UDP tunnel support" on \
VDE "Build with VDE support" off \
VNC "Build with VNC support" off \
WEBSERVICE "Build Webservice" off \
NLS "Native language support" on

What I feel is missing from ports is the information that would allow me
to make intelligent decisions about each option. To see what's missing,
consider the following questions:

- Why would I want pulseaudio in a hypervisor?
- What, exactly, are guestadditions and why would I want them?
- Why does this need dbus and hal?
- What is VDE?
- What webservice?
etc.

The porter's handbook is fine if you are writing ports. It's using them
that can get opaque. There's meta topics also, these would be great to
know about without having to read 200 mail messages:

- Some people do not like pulseaudio for good technical reasons.
What are those? What are the non-technical opinion based reasons?

- What are the common objections to HAL and DBUS?

It's this kind of attention to communication that I think FreeBSD, in
any attempt to reach more users, needs to strongly consider.

--
Dave Hayes - Consultant - Altadena CA, USA - da...@jetcafe.org
>>> The opinions expressed above are entirely my own <<<

Treat people as if they are what they ought to be, and you
help them to become what they are capable of being.

[Chris Nehren]

The descriptions of the options assume the admin is familiar with the
software they're installing. I do not think it is the FreeBSD Project's
purview to document every option for every port. At the very least it'd
take quite a lot of time and effort to document all of that. Beyond
this, such explanations would duplicate each port's own documentation.
If you're not familiar with something, you very probably shouldn't be
installing it.

Show me one other similar packaging system that does this level of
handholding. The only comparable ones I can think of are portage and
macports, and they certainly don't, either.

--
Thanks and best regards,
Chris Nehren

[Dave Hayes]

Chris Nehren <apeiron+fre...@isuckatdomains.net> writes:
> The descriptions of the options assume the admin is familiar with the
> software they're installing. I do not think it is the FreeBSD Project's
> purview to document every option for every port. At the very least it'd
> take quite a lot of time and effort to document all of that.

That's a fair position. Perhaps it would not be too much trouble to add
this one idea to optionsng: a "more info" field on each option knob
which may be filled in by a port maintainer.

> Beyond this, such explanations would duplicate each port's own
> documentation.

Not necessarily. I don't have an example offhand, but I suspect there
are a number of FreeBSD specific option knobs applied to ports.

> If you're not familiar with something, you very probably shouldn't be
> installing it.

Basing my argument here on assumptions that FreeBSD wants more users, I
would argue that the better policy is to be liberal in who you help and
conservative in who you call unfamiliar.

In this spirit, I can guarantee you that there are plenty of people who
will install despite your requirement above, set some option that they
shouldn't (or fail to set one that they should), and then come away with
a bad experience.

Instead, if the person familiar with the software (who is ostensibly
writing the port) could spend just 5 more minutes writing a simple "this
option is documented at url://..." or "dont set this if you have port
foo installed" that would help a lot of people.

> Show me one other similar packaging system that does this level of
> handholding. The only comparable ones I can think of are portage and
> macports, and they certainly don't, either.

The absence of such a system isn't really relevant to the idea of
improving the current one is it? :)

--
Dave Hayes - Consultant - Altadena CA, USA - da...@jetcafe.org
>>> The opinions expressed above are entirely my own <<<

"Computer games don't affect kids; I mean if Pac-Man
affected us as kids, we'd all be running around in darkened
rooms, munching magic pills and listening to repetitive
electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

[Zane C. B-H.]

On Mon, 04 Jun 2012 18:49:45 +0300
Daniel Kalchev <dan...@digsys.bg> wrote:

>
>
> On 04.06.12 18:04, xenophon\+freebsd wrote:
> >> -----Original Message-----
> >> From: owner-free...@freebsd.org [mailto:owner-freebsd-
> >> sta...@freebsd.org] On Behalf Of Daniel Kalchev
> >> Sent: Saturday, June 02, 2012 12:42 AM
> >>
> >> I really see no reason why your 'mail or calendaring server'
> >> should be able to wipe your devices.. This is the sort of bloat
> >> that keeps me away. From Microsoft products.
> > I don't think that's fair to say. Email/calendaring seems to be
> > the only connection point between a smartphone and an
> > organization for at least the current crop of devices (although
> > I'm sure that at some point soon, you'll be able to include
> > organizational file servers as well).
>
> Again, what does your e-mail or calendaring service have to do with
> wiping your device clean?? Wiping the device is task for your
> device management platform, which does not belong to the e-mail or
> calendaring platform. If you connect your desktop to Exchange, is
> it supposed to be wiped too? What if the Exchange account is just
> one of the many e-mail accounts you use, as typically is the case?

It is part of the protocol, Exchanged ActiveSync, used by Exchange
based mobile devices.

> >> In this regard I rather prefer the way Apple handles things.
> >> Shiny wrapper interface to pretty much generic technology. No
> >> reinvention of the wheel and experiments to see if it can be made
> >> square.
> > You can't damn Microsoft for being too proprietary in one
> > paragraph and then praise Apple for its openness in the next.
> > Does not compute.
>
> I don't care how proprietary an proprietary thing is. If it is
> correctly implemented, it is ok, if it is not correctly
> implemented, it is not ok. Microsoft's "wipe trough Exchange" is
> weird, to put it mildly. Apple too had a track record of doing many
> proprietary things, but in recent years their offerings are, as I
> mentioned earlier, pretty much generic standard and widespread
> protocols with a lot of sugar coating.

From a enterprise perspective, it makes sense. Lets say a device goes
missing, it allows one to wipe it the next time it calls home.

The usefulness of such a feature is better disconnected from the
debate of proprietary v. non-proprietary though, given the different
nature of both issues.

[Daniel Kalchev]

On 04.06.12 22:32, Dave Hayes wrote:
> Chris Nehren<apeiron+fre...@isuckatdomains.net> writes:
>> The descriptions of the options assume the admin is familiar with the
>> software they're installing. I do not think it is the FreeBSD Project's
>> purview to document every option for every port. At the very least it'd
>> take quite a lot of time and effort to document all of that.
> That's a fair position. Perhaps it would not be too much trouble to add
> this one idea to optionsng: a "more info" field on each option knob
> which may be filled in by a port maintainer.

The pkg-descr file in the port already contains link to the software's
origin. The various options the software has are or should be described
there. We definitely don't want the ports cluttered with extraneous and
sometimes out of date (and thus misleading) information.

>> Beyond this, such explanations would duplicate each port's own
>> documentation.
> Not necessarily. I don't have an example offhand, but I suspect there
> are a number of FreeBSD specific option knobs applied to ports.

There are in a way, and all of them are pretty much generic. Like
WITHOUT_X11, WITH_CUPS etc. The purpose of these options is to more or
less define the environment in which the port is intended to be used.
For example, on a head-less server you most definitely want to build
(say) php5 with WITHOUT_X11 in order to not pull unnecessary X11 related
pieces. The intent of such options is to go to make.conf.

These options are for convenience however. You can set each port's
options individually. In all case, compiling from source is not for
those having no clue what they do. The ports infrastructure in FreeBSD
is already doing the hard work to port the software to your OS, you need
to make informed decisions on options yourself.
If this is beyond you (and not you personally), then by all means use
pre-packaged software in binary form.

Since it is very likely that you interpret this as yet another elitist
comment, let's make it clear: anyone is welcome to ask for help with
FreeBSD and ports (in the proper mailing list as to not create much
noise and get negative response). Nobody is obliged to provide any help
on anything. Nevertheless, the FreeBSD users are great community and you
are often getting help even for the most stupid questions. Except when
you start with name calling, or insist "if you don't help me, I will go
elsewhere" or "apparently, you don't want the number of FreeBSD users to
grow". Then you waste everyone's time -- that could be spent on
answering other people's "stupid" questions.


Daniel
Daniel

[Daniel Kalchev]

On 05.06.12 07:33, Zane C. B-H. wrote:

[on Exchange wiping devices]

> From a enterprise perspective, it makes sense. Lets say a device goes
> missing, it allows one to wipe it the next time it calls home.

This is supposed to be handled by the device management software. Not by
your e-mail server. Because it does not belong to the mail server, this
is why you will not find this functionality implemented in any "open"
mail server or calendaring or groupware software.

As you involved "enterprise" and your previous statement on Apple, they
"surprisingly" do have such device deployment and management solution.
You can either use their own Apple Configurator, or any third party MDM
as described in http://www.apple.com/ipad/business/integration/mdm/. I
would not call this technique "proprietary". Ok, it only works on iOS ;)

> The usefulness of such a feature is better disconnected from the
> debate of proprietary v. non-proprietary though, given the different
> nature of both issues.

With this I fully agree. I hope you too agree, than when you disconnect
the e-mail handling features of Exchange, from the lock-in technology
Microsoft integrated there (ActiveSync), Exchange is no different than
any other non-proprietary mail server.

The point here is that in order to have more freedom, one has to set
expectations and setups right, from the begining. Separate the MDM and
e-mail functionality and you are no longer locked with Microsoft or
anyone. You can easily replace each component of your system and use the
best software for the task. Not make compromises.

Daniel

PS: Yes, I don't like Microsoft's offerings. I understand why they do
this, but this doesn't mean I agree and since I have plenty of other
choices... I prefer the best. My enterprise(s) have been running on BSD
UNIX for good over 20 years now. No Microsoft stuff. Not needed, not missed.

[Oliver Fromme]

O. Hartmann <ohar...@zedat.fu-berlin.de> wrote:
> 2) Disk and network I/O issues under load. We realized that FreeBSD has
> some issues in multithreaded environments. Even on 6/12 or 12/24
> core/thread systems, under heavy load (especially network and CPU load),
> disk I/O was (is?) poor. This is a no-go in a HPC environment.

This got a lot better when I switched to native AHCI mode
for SATA disks. You have to have a fairly recent mainboard;
my workstation at the office (about 3 years old) doesn't
support AHCI mode yet.

> 4) The lack of clustering capabilities. The lack of a clustered
> filesystem grows more and more important in the area of HPC, where
> storage systems get spread over a department.

Yes, a clustered file system would be very useful to have,
even outside the HPC area.

Best regards
Oliver

--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd

[Ronald Klop]

On Fri, 01 Jun 2012 20:57:52 +0200, Thomas David Rivers
<riv...@dignus.com> wrote:

> We used to have FreeBSD exclusively on desktops...
>
> Now, we have migrated to other desktops (mac) with FreeBSD running
> the build and file server...
>
> Why?
>
> Because - the mac updates itself! No pain, no installation,
> no keeping-up with mailing lists/announcements, just <click> and its
> done.
>
> Mac OS has a nice X11 server, the Mac UI is good enough, you don't
> have to install/update anything, the "app store" is perfect
> for downloading/installing whatever a desktop user might need.
>
> It was just too alluring...
>
> So, FreeBSD runs our NFS file server, and we log into a larger
> FreeBSD machine to do builds, etc... but, the desktop has moved.
>
> One developer here uses Linux Debian for about the same reason,
> it's trivial to update (via the network) to new versions, etc...
>
> Our web site used to be FreeBSD-based, but it was just too
> cost-effective to get a virtual Linux box on the backbone and
> move everything to that. Our requirements aren't too big, so
> that works beautifully. There _are_ people doing virtual
> FreeBSD boxes in a similar fashion, but they were quote a lot
> more for the annual fee.. so, Linux it was...
>
> I suppose, in some sense, you could argue that MacOS is FreeBSD...
>
> - Dave Rivers -

Have you already tried pc-bsd?

http://www.pcbsd.org/

FreeBSD with easy install and auto-update.

Ronald.

[Dave Hayes]

Daniel Kalchev <dan...@digsys.bg> writes:
> On 04.06.12 22:32, Dave Hayes wrote:
>> That's a fair position. Perhaps it would not be too much trouble to add
>> this one idea to optionsng: a "more info" field on each option knob
>> which may be filled in by a port maintainer.
> The pkg-descr file in the port already contains link to the software's
> origin. The various options the software has are or should be described
> there. We definitely don't want the ports cluttered with extraneous and
> sometimes out of date (and thus misleading) information.

I'm describing more of a use case here, not attempting to specify an
implementation. If a user invokes 'make', a window is presented to them
with various options. It's probably very common that this is met with an
initial reaction of "what the hell do these do?", even from the most
seasoned of admins (presuming they are unfamiliar with the software they
have been asked to install). I claim it would be an improvement to have
that information at the fingertips of the make invoker.

I believe this is the first time I've seen more documentation labeled as
"extraneous". :) I had thought to suggest an implementation by having a
simple pkg-option-desr file which describes the options and implications
in each port. Are you suggesting that such a file would be unwelcome?

I have built many ports for many years. IIRC I've seen the option
descriptions you mention in pkg-descr maybe 0.1% of the time. (That's my
sense, not a measured objective number.) Usually I have to go digging
through the Makefile, then the source to find these answers.

> In all case, compiling from source is not for those having no clue

> what they do. ... you need to make informed decisions on options

> yourself. If this is beyond you (and not you personally),

...

> Since it is very likely that you interpret this as yet another elitist
> comment,

Actually, I hadn't thought of this conceptual linkage until you suggested
it here. :)

Still, you are quite correct. The likelihood of anyone interpreting your
position as 'elitist' from these comments is high. I will, of course,
not interpret them that way.

> If this is beyond you (and not you personally), then by all means use
> pre-packaged software in binary form.

Heh. Even this idea is beyond most normal users, who should likely use
PC-BSD or Ubuntu. In responding in this thread, I was thinking of the
reasonably clued system admin level users when I said "users". As an SA,
in many situations, you aren't able to have fun digging for information.
It's much easier to have the answers right here in front of you.

I know if I ever committed a port, I would quite likely spend the extra
five minutes to put option documentation in a number of places, even if
this angered some of the more anal of the community.

> elsewhere" or "apparently, you don't want the number of FreeBSD users to
> grow". Then you waste everyone's time -- that could be spent on
> answering other people's "stupid" questions.

I see. Personally, I believe this way:

It is the responsibility of the responder to determine whether their
response is a waste of time or not.

Blaming anyone else other than you (the generic 'you', not you
personally) for the inappropriate use of your time should only really
happen in an employment or indentured servitude relationship; certainly
not on a mailing list. :)

Given that the "FreeBSD wants more users" idea is repeatedly brought up
on lists (at least this is my impression), I would presume that the
subject of 'more users' is somewhat relevant to some people; one look at
the subject of this thread should be enough to demonstrate relevance.

--
Dave Hayes - Consultant - Altadena CA, USA - da...@jetcafe.org
>>> The opinions expressed above are entirely my own <<<

Implementation: (n.) The fruitless struggle by the talented
and underpaid to fulfill promises made by the rich and
ignorant

[Doug Barton]

On 06/06/2012 11:59, Dave Hayes wrote:
> I'm describing more of a use case here, not attempting to specify an
> implementation. If a user invokes 'make', a window is presented to them
> with various options. It's probably very common that this is met with an
> initial reaction of "what the hell do these do?", even from the most
> seasoned of admins (presuming they are unfamiliar with the software they
> have been asked to install). I claim it would be an improvement to have
> that information at the fingertips of the make invoker.

What manner of providing this information would meet your needs?

--

This .signature sanitized for your protection

[Glen Barber]

On Wed, Jun 06, 2012 at 02:14:46PM -0700, Doug Barton wrote:
> On 06/06/2012 11:59, Dave Hayes wrote:
> > I'm describing more of a use case here, not attempting to specify an
> > implementation. If a user invokes 'make', a window is presented to them
> > with various options. It's probably very common that this is met with an
> > initial reaction of "what the hell do these do?", even from the most
> > seasoned of admins (presuming they are unfamiliar with the software they
> > have been asked to install). I claim it would be an improvement to have
> > that information at the fingertips of the make invoker.
>
> What manner of providing this information would meet your needs?
>

IMHO, something informing what "THAT" is in devel/subversion option
MOD_DONTDOTHAT would be nice. :)

Glen

[Vincent Hoffman]

On 06/06/2012 22:23, Glen Barber wrote:
> On Wed, Jun 06, 2012 at 02:14:46PM -0700, Doug Barton wrote:
>> On 06/06/2012 11:59, Dave Hayes wrote:
>>> I'm describing more of a use case here, not attempting to specify an
>>> implementation. If a user invokes 'make', a window is presented to them
>>> with various options. It's probably very common that this is met with an
>>> initial reaction of "what the hell do these do?", even from the most
>>> seasoned of admins (presuming they are unfamiliar with the software they
>>> have been asked to install). I claim it would be an improvement to have
>>> that information at the fingertips of the make invoker.
>> What manner of providing this information would meet your needs?
>>
> IMHO, something informing what "THAT" is in devel/subversion option
> MOD_DONTDOTHAT would be nice. :)
>
> Glen

Not something I had bothered looking up till now as I hadnt wanted to
use it but the 2nd hit on google,
http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2009-April/161673.html
describes it quite well.
I tend to go with, If i dont know what it is, and its not default, I
probably dont need it.
Unless it looks interesting, then I google it ;)

Maybe an (optional) new file with a longer descriptions of the make
options so as not to crowd the make config dialog?
I dont mind looking up compile time options for software I am installing
but I can see how having a precis available locally might be handy.

Vince

[Warren Block]

On Wed, 6 Jun 2012, Vincent Hoffman wrote:

> On 06/06/2012 22:23, Glen Barber wrote:
>> On Wed, Jun 06, 2012 at 02:14:46PM -0700, Doug Barton wrote:
>>> On 06/06/2012 11:59, Dave Hayes wrote:
>>>> I'm describing more of a use case here, not attempting to specify an
>>>> implementation. If a user invokes 'make', a window is presented to them
>>>> with various options. It's probably very common that this is met with an
>>>> initial reaction of "what the hell do these do?", even from the most
>>>> seasoned of admins (presuming they are unfamiliar with the software they
>>>> have been asked to install). I claim it would be an improvement to have
>>>> that information at the fingertips of the make invoker.
>>> What manner of providing this information would meet your needs?
>>>
>> IMHO, something informing what "THAT" is in devel/subversion option
>> MOD_DONTDOTHAT would be nice. :)
>>

> Not something I had bothered looking up till now as I hadnt wanted to
> use it but the 2nd hit on google,
> http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2009-April/161673.html
> describes it quite well.
> I tend to go with, If i dont know what it is, and its not default, I
> probably dont need it.
> Unless it looks interesting, then I google it ;)
>
> Maybe an (optional) new file with a longer descriptions of the make
> options so as not to crowd the make config dialog?
> I dont mind looking up compile time options for software I am installing
> but I can see how having a precis available locally might be handy.

Here's an idea: if the description is too long to show in the very
limited space, cut it off, show a "...", and show the entire description
in a two- or three-line text box below the main one. The >< indicate
a highlight here:

-----------------------------------------------
>[ ] GOOFY Build with support for the... <
[ ] EXAMPLES Install the examples

-----------------------------------------------
< OK > <Cancel>

---------------------------------------------
Build with support for the GOOFY framework
that provides concurrent whoopsies integrated
with a Perubython interpreter, and stuff.
-----------------------------------------------

The description at the bottom is from whatever option is currently
highlighted, and changes as the user scrolls through the options. It
would be blank if the entire description could be displayed in the space
available above.

The advantage of this is that it would work with existing ports, and
give the ability to use longer descriptions. The disadvantage is that
dialog(1) would probably need modifications.

[Charles Sprickman]

If we're talking about changing dialog(1), let's make sure there's also an "uncheck all"/"check all" option.

I'm looking at you, ghostscript:

wc -l /var/db/ports/ghostscript9/options
315 /var/db/ports/ghostscript9/options

Charles

> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"

--
Charles Sprickman
NetEng/SysAdmin
Bway.net - New York's Best Internet www.bway.net
sp...@bway.net - 212.655.9344

[Dan Daley]

I usually use portmaster to install ports. The options dialogs that pop
up are often for dependencies. The options dialog gives the name of the
port for which the options are being selected, but no description or
indication as to why this is being installed (this could be a dependency
of a dependency of some dependency of the port I am installing). It's
probably too much for this dialog to show why this port is being
installed (what other port required this port that is being installed),
but a description of what this current port is would be helpful.

But, if possible, some breadcrumb across the top showing the
dependencies which prompted this install would be great:

Port A --> Port B --> Port C --> Current Port for which options are
being chosen

[Dave Hayes]

Doug Barton <do...@FreeBSD.org> writes:
> On 06/06/2012 11:59, Dave Hayes wrote:
>> I'm describing more of a use case here, not attempting to specify an
>> implementation. If a user invokes 'make', a window is presented to them
>> with various options. It's probably very common that this is met with an
>> initial reaction of "what the hell do these do?", even from the most
>> seasoned of admins (presuming they are unfamiliar with the software they
>> have been asked to install). I claim it would be an improvement to have
>> that information at the fingertips of the make invoker.
> What manner of providing this information would meet your needs?

Personally, a 'pkg-options-descr' text file would suit me just fine.

I don't claim this is a good or bad idea from the general perspective of
FreeBSD users as a group. ;) From that perspective, the menu example
suggested by Warren Block is decent; perhaps with an added button to
"reset to defaults". From a quick persual of dialog(1), I'm sure
something similar in functionality could be used without having to
modify dialog itself.

My loose attempt at requirements is that "enough" information about each
option be in one place in the port skeleton to make an informed decision
about whether to turn that option on or off. There should be a clear
paragraph explaining what the option does, what consequences it might
have if you enable/disable it, and why the default was chosen.

BTW, thank you for changing the subject line.

--
Dave Hayes - Consultant - Altadena CA, USA - da...@jetcafe.org
>>> The opinions expressed above are entirely my own <<<

Never promise, even by implication, without fulfilling your
promise. The only acceptable alternative to completing an
undertaking is to over-fulfil it.

To betray any promise, explicit or otherwise, will harm you
more than it can harm anyone else.

[Daniel Kalchev]

On 07.06.12 08:27, Dave Hayes wrote:
> Personally, a 'pkg-options-descr' text file would suit me just fine.

I have considered this lack of information about port options myself.
Sometimes, when installing "new" (to your understanding) software
finding out what those options actually do and what are the real
implications is very hard. The same situation, even worse happens when
you update an port and the new version has introduced yet new options.
Sometimes, hints on what those do end up in /usr/ports/UPDATING.

It is clear, that something has to be done. Unfortunately, you can't
just force port maintainers to document it, because of many reasons. One
not very obvious reason is that many ports use pretty much 'generic'
options, like WITHOUT_CUPS. For most such ports, this means "I don't
want cups on my system", but in few it might mean something different.
Finding adequate way to document all this is a bit tricky. Good ideas
are welcome.

The idea Warren Block has is very useful and I fully agree that there
should be some option to "reset to default". It would be also extremely
helpful if the dialog UI indicates somehow which options are set to
something different from the default. Lacking this information is a big
waste of time, especially when upgrading older ports. Or having the
saved options lying around from an previous install of that port.

At least, some way of mandatory describing of what setting particular
option for a port does, outside of what is found in the Makefile and in
plain English will be very, very useful.

[off topic]
By the way, on the "waste of time". I view it a bit differently, when it
comes to internet mailing lists. Suppose I waste 30 minutes of my time
researching and preparing an response to a "stupid" question. It is
apparently my decision to do so and nobody is blaming anyone. But
imagine, this mailing list is read by tens, hundreds, thousands or even
tens of thousands people (Google searches not accounted for). All those
people are going to read the stupid question and the trivial answer.
This is huge waste of time. Doesn't help that all those people are
willingly wasting their time.
Of course, we need discussions like this as a lot of people learn new
things. Just the proper balance sometimes is difficult to achieve. But
those who ask, will do better for everyone to try to comprehend what
they have been told, before continuing their jihad.

Daniel

[Rainer Duffner]

Am 06.06.2012 um 20:59 schrieb Dave Hayes:
>
>
> I believe this is the first time I've seen more documentation labeled as
> "extraneous". :) I had thought to suggest an implementation by having a
> simple pkg-option-desr file which describes the options and implications
> in each port. Are you suggesting that such a file would be unwelcome?
>

No, but take a look at the nginx port, which (I'm too lazy to count) has gained a couple of dozens of options over the years.
It's a bit of an extreme example, I know - but nevertheless.
I've enabled some that I know what they do and some where I think I know what they do. Some are default on, so I left them on.
The rest I disabled if I knew I wouldn't ever need them.
Documenting all of them would probably be a huge endeavor - and I'm glad that Sergey keeps the ports updated super-fast and chases down all the updates of 3rd-party patches (which often have little more than the source itself as documentation) etc.
Asking him to do even more work - I wouldn't dare to do that ;-)

It's really the person who is running make config who has to read up on all the options and decide if (s)he needs them.
Sometimes, options only make sense in context of the selection of options of other ports and it thus may no be easily explainable in one line.
I don't maintain any ports, I just build about 600 of them in our private tinderbox.
IMO, you can't really maintain more than a couple of FreeBSD-servers professionally without some sort of central package-building.
The earlier people realize this, the less pain they will have to suffer. In practice, you realize it 50 or 100 servers too late...

The work that goes into the ports-tree is tremendous and once you start running your own tinderbox, maintain some 3rd-party patches yourself and just generally dig deeper into this stuff you begin to realize just how difficult this is.

What I do (or try to do) on my tinderbox is to take a "frozen" ports-tree towards a release and build packages from it (trying to minimize the number of unique builds per portstree)
After the tree is open again, I try to get the stuff that interests me, the security-patches (e.g. the recent php bug) or other stuff that is useful for us as an update directly from CVS for the 600 or so ports that we actually use.
Of course, this only works until something in the ports-framework changes significantly (like that options-ng thing recently) and I either have to update the whole ports-tree or just wait till the next pre-release freeze.
I found that currently the fastest way to update my packages on a server is to pkg_delete -fa and then pkg_add the stuff back that I need (more or less the same packages everywhere, anyway).
Portupgrade is far too slow to be of any practical use (and more than a handful of package-management-tools in the ports-mgnt category isn't really helpful, either - who has the time to test them all?)
I hope that pkgng will solve most of these problems and enable me to update my ports-tree more often.
Unfortunately, by then some of the FreeBSD-servers will have moved into our private cloud (using Joyent's private cloud, which, incidentally uses NetBSD's pkgsrc - we will have to see how that works out longtime)

Personally, I don't need more frequent FreeBSD-releases but two or maybe three ports-tree freezes per year would be good.

So, FreeBSD 9.0-RELEASE, FreeBSD 9.0-U1, FreeBSD 9.0U2 would be cool ;-)


Would that be a lot of additional work?

[Oliver Fromme]

Dan Daley <ddd...@yahoo.com> wrote:
> I usually use portmaster to install ports. The options dialogs that pop
> up are often for dependencies. The options dialog gives the name of the
> port for which the options are being selected, but no description or
> indication as to why this is being installed (this could be a dependency
> of a dependency of some dependency of the port I am installing). It's
> probably too much for this dialog to show why this port is being
> installed (what other port required this port that is being installed),
> but a description of what this current port is would be helpful.
>
> But, if possible, some breadcrumb across the top showing the
> dependencies which prompted this install would be great:
>
> Port A --> Port B --> Port C --> Current Port for which options are
> being chosen

You might want to have a look at my "portup" script. It can
be used to install ports, and the -w option causes it to use
a split-screen display: The bottom 80% contain the usual
output from "make", and the top 20% show the progress of the
build, including information about dependencies. This might
be exactly the "breadcrumb across the top" that you requested.

You can download the current version from here:

http://www.secnetix.de/olli/scripts/portup

For FreeBSD >= 8.x, the -w option requires the "window" port
to be installed (from /usr/ports/misc/window) which was removed
from the base system in FreeBSD 8.x.

Usage for installing ports is simple:

# cd /usr/ports/category/foo
# portup -wy .

Best regards
Oliver

--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd

I suggested holding a "Python Object Oriented Programming Seminar",
but the acronym was unpopular.
-- Joseph Strout

[Steve Franks]

On Fri, Jun 1, 2012 at 8:43 AM, Pierre-Luc Drouin <pldr...@pldrouin.net> wrote:
> For me it is the lack of support for suspend/resume on laptops. I don't
> want to turn off my laptop when I am in the middle of doing something but
> need to put the laptop aside. I love using FreeBSD on servers, workstations
> and even a computer I have hooked to the TV at home for multimedia purpose,
> but not having suspend/resume working on my laptops is a major source of
> annoyance for me. So I have been trying various Linux distributions instead
> and I am currently using Gentoo, which is not that bad, although I find
> that system configuration and maintenance is always more painful with Linux
> than FreeBSD no matter the distribution I use...

+1000. (I understand this may not be feasible given the number of
developers, by the way)

Steve

[Dan Daley]

Thanks. I'll check this script out.

________________________________
From: Oliver Fromme <ol...@lurza.secnetix.de>
To: freebsd...@FreeBSD.ORG; Dan Daley <ddd...@yahoo.com>; Charles Sprickman
<sp...@bway.net>; Warren Block <wbl...@wonkity.com>; Vincent Hoffman
<vi...@unsane.co.uk>
Sent: Fri, June 8, 2012 2:47:37 AM
Subject: Re: Documenting 'make config' options

[Steve Franks]

I think XOrg 7.2 or 7.3 or whatever was the straw that broke the
camel's back for me, but it's just an example. Every time libjpeg or
perl or python bumps the rev, I have to explain to my boss that I
won't be using my computer for 48 hours. You can say "don't follow the
bleeding edge", but it seems like a weekly excersise that I need some
port that wasn't built with a key option enabled, so pkg_add is really
not an answer. If you have all the freetime in the world, reading
/usr/ports/UPDATING back far enough will usually keep you out of
trouble, but for a production system, it's a touch frustrating as soon
as you touch the ports tree.

That said, having been a linux user for a couple years now, I'm
starting to think they are even worse: at least on F.B. you can
rebuild the entire system in straightforward fashion if you do need an
option that wasn't turned on, and go get a really big cup of coffee.
The linux guys (or *buntu and derivatives at least) expect you never
to upgrade a package/port unless you upgrade the whole OS (I think it
was a ploy to get everyone locked-in to the abject failure that is
gnome 3.0). I've got systems with 3-y.o. versions of everything on
them, because there is no good way to upgrade an ap w/o upgrading the
whole system, (at least past the couple of wannabe backports that they
usually do the first year after a release. After that, you'd better
really like the versions of everything that existed when you installed
origonally.) That aside, you can clone a linux system with dpkg really
really fast from a text list of previously installed packages (which
is, however, unnecessary on freebsd because dump/restore works so well
- never got it to clone a linux system into a functional state - so
F.B wins again).

So, conceptually and freedom-to-choose-wise, I prefer FreeBSD, it's
just that mechanically, day-to-day, it has brought my capacity to use
the computer effectively to a halt for such extended periods that I
can't often justify it on the desktop. My server on the other hand
has been running 7.x for years, and shows no sign of giving out. Just
keep sticking new HDD's in periodically. For a server that you rarely
add new apps to, it's stellar. Mind you, it's probably chock full of
security holes due to it's age...

I guess the bottom line is when it comes to package management, you
can't have it all, and you can rarely even have very much, and OS guys
really don't get much excitement from coding on pkg managers, so we're
gonna all be out of luck indefinitely no matter the platform.

Steve

[Adam Strohl]

On 6/9/2012 3:34, Steve Franks wrote:
> Every time libjpeg or
> perl or python bumps the rev, I have to explain to my boss that I
> won't be using my computer for 48 hours.

Why is this? And why are you updating every time there is a rev bump?

It almost sounds like you're recompiling everything just for the heck of
it, though I don't get how even that takes 48 hours. Even make
buildworld is done in multi-user mode and so you could use your
workstation during the build. And we're talking about ports here so ...

Just curious!

--
Adam Strohl
http://www.ateamsystems.com/

[O. Hartmann]

On 06/09/12 06:45, Adam Strohl wrote:
> On 6/9/2012 3:34, Steve Franks wrote:
>> Every time libjpeg or
>> perl or python bumps the rev, I have to explain to my boss that I
>> won't be using my computer for 48 hours.

Lucky man! We are "off" from some desktop services (like LibreOffice and
Firefox) for more than a week now!

[O. Hartmann]

On 06/09/12 15:43, Adam Strohl wrote:

> On 6/9/2012 14:50, O. Hartmann wrote:
>> Lucky man! We are "off" from some desktop services (like LibreOffice and
>> Firefox) for more than a week now!
>

> Why did you update to begin with? Bug/security fix?

>
> --
> Adam Strohl
> http://www.ateamsystems.com/

Well, this is a good question. Unfortunately, I did an update of the
ports tree and PNG update rushed in. The information in UPDATING came a
in bit later, but since then several ports have been updated already -
and rendered some applications unuseable.

The question "why" isn't applicable here. Sometimes ports need updates
or a port that is installed reels in another or even an update and this
triggers the avalnche of messes.