Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 9 Dec 2017 20:23:21 +0100
From:      Polytropon <>
To:        Baho Utot <>
Subject:   Re: looks like I am no longer welcome around here
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
Please allow me a few comments regarding your rant (which has
some valid point, but in my opinion illustrates a little lack
of understanding of how some things on FreeBSD work):

> They don't like to be called out or have some one be critcal of the 
> "new" flavor system or any "new" thing that comes down the pike. It has 
> caused a butt load of issues with my systems here.

In that case, "they" would have kicked me more than once for
expressing that I don't like the sc -> vt transition (which,
as I might mention again, is one of the biggest show stoppers,
because vt isn't a fully working replacement of sc, and it
can do only a fraction of what sc could, and even that only
at bad quality, and it's hardly documented). Now let's see
what happens. :-)

> Any way I have started to update my scratch built linux systems, because 
> this 5 year trial of FreeBSD has just been fraught with an unbelievable 
> work load just to make it function.

THis is in fact a big deal - but usually this list is very
helpful if you're willing to "do your homework".

> Some of the issues:
> Lack of direction.
> No transactions in pkg.  One "bad" package and your system doesn't boot, 
> so dig out the USB drive

That exactly is the situation on Linux, where even the kernel
is just a package. FreeBSD has a strong barrier between the
operating system and 3rd party applications (that come from
the ports collection). Even with damaged ports (or with _no_
ports), the system will still boot. Sure, certain additional
services might not be started, but that's not a problem for
the OS. In worst case, /usr/local is removed altogether, its
structure rebuilt from the /etc/mtree/ file, pkg gets boot-
strapped - and you're ready to install new ports cleanly.
The OS does not care.

However, I am not sure how the new packaging approach will
handle this. As you might have read, pkg will be used for
installing and upgrading OS files in the future, so there
will not be the big difference "freebsd-update" and "pkg
update" / "pkg upgrade".

> source head in-stability, or you could say base instability.

Only tested and verified changes will be in RELEASE. Then
there is STABLE, which only contains additional components
that will be in the next RELEASE. From here, security patches
will be "extracted", so they can be applied to RELEASE. And
finally, there's CURRENT or HEAD. This is where development
takes place. A feature might be added, and the build from
source breaks. A few hours later, ir builds again, but the
result makes the system crash upon reboot. Next day, the
added feature is entirely gone. This is fully acceptable
for the HEAD branch.

Common consensus is to use RELEASE and the security patches.
This can be done with freebsd-update easily. For those who
wish to experiment with bleeding-edge software, STABLE is
the right choice, but it requires building from source.
And those who are applying experimental (!) changes, for
example kernel and OS developers, or testers, use HEAD,
fully aware of what I mentioned before.

> ports in-stability... I was using Head then I was told to use quarterly 
> and then told that it does not receive security updates, well not all 
> and not on a regular basis. Then I was told to use head WTF?

You are mixing ports and OS. The ports tree (and the
corresponding repository) can be reset at RELEASE, you
can choose a quarterly updated branch (often used in
combination with a RELEASE-pX system), or you can keep
your ports tree as current as possible. You can use tools
like portsnap (snapshots) or svn (tracking), or just use
the ports tree that came with your RELEASE install - it
depends on what kind of software (versions) you intend to
run. Always (!) choose your tools depending on the task.
There is no "one size fits all egg-laying wool-milk-sow". ;-)

> Hell most people here don't even know why you should be building in a 
> clean room and you should build packages as a user not as root.

Nothing wrong with building packages as root (if you use
the /usr/ports tree manually). For _installing_ packages,
you'll need root permissions anyway, or do you wish Hinz & Kunz
to be able to install arbitrary software on your system, with
an ugly surprise for you later? ;-)

> You 
> should not even use root even when you do the make install.  Tried to 
> tell them why, all I got was "shut up you know nothing".

Keep in mind that FreeBSD is (among others) a multi-user system,
and that's why even on a PC you have a regular user and a root
user. The non-root user can damaga his own $HOME as he likes,
but should he be allowed to damage the whole system? Maybe for
other users to suffer? No, that's the wrong approach.

On Linux, "wget | sudo bash" has become
quite common. Do you think this is a good idea? Please read the
command line, more than once, and look at each individual part.
You'll find at least 5 things that are wrong... ;-)

You _can_ install software locally (i. e., local to your user
account), this is possible, but it often creates more problems
than it solves. However, if you know what you're doing, there
is nothing wrong with it.

> no packaged base, the packaged base just isn't usable, and no one wants 
> to listen to alternatives.

This is something still in development (and with potential of
improvement). If implemented in a reliable and secure manner,
it will probably be a positive thing. But only time will tell.

> After trying packaged base no one could tell 
> me how to go back to the "old" method of updating base.

You also cannot go back from pkg-based ports to the old way,
because it's not supported anymore, the build environments
do not exist anymore, and the old ways don't work anymore.

But in your specific problem, downloading the source (with
a RELEASE version preferred), from the distribution tarball
or via svn, then building from source (as explained in the
comment header of /usr/src/Makefile), should work.

> Hell no one 
> knew how to remove the base package entries in the pkg database.

The database is just a database, so a properly formed query
should fix this. (I have never tried that, but basically, it
should work.)

> I 
> found a way and it was trival.  I have not updated base since 11.0 p10 
> as I am not up for fixing any breakage if it would occur.

If I remember correctly, 11.0 doesn't use pkg-base as a default.

> Lack of ability to use modern graphics cards on the "desktop",  it seems 
> to have taken a back seat to pkg development.

Nonsense. Even though you have to think before you buy, there are
lots of modern graphics cards that work well on FreeBSD. And if
you don't have a problem using nVidia's binary drivers, they
usually work quite nicely and enable you a plethora of 3D stuff.
And pkg has nothing to do with it, as those binary drivers are
distributed binarily, so nothing can be ported. :-)

> Regular breakage when I use synth,  that is just not acceptable.

I'm not using it, so no idea...

> Can not boot ZFS raid system from a boot loader, I have to hit the "F8" 
> key and select a drive to boot.  No one seem to know if grub2 would work.

That would be worth testing.

> when I started using freebsd ver 10.1  I was told just wait for rev 11 
> and package base will be there.....Really?

No. :-)

> Now out of the blue sendmail 
> is going to bite the dust in version 13, if that is really true.  Given 
> the lack of finishing things I have my doubts.

Basic system functionality breaking is definitely worth creating
a bug report. In case you cannot isolate the problem, the developers
will be helpful and ask for specific outputs.

> The move from gcc to clang does not appear to me to have been completed.
> BTW what is wrong with GCC, works for me.

It is primarily a licensing _and_ modularity issue. Of course
you can use gcc _and_ clang on the same system. Building certain
ports requires gcc, and sometimes requires a _specific_ gcc
version. Nothing wrong here.

> The move off of GNU software in base was to have been completed and has 
> not been.

It probably isn't still completed, and there is also softeware
from other licensing realms. Just check /usr/src/contrib to find
out what's there.

> I was looking for a "system" to use in my entire organization and though 
> freebsd would work accross the different archs.  I was completely wrong.

That might depend on your organization. Other places are happy
FreeBSD-only installations.

> If one is going to be doing major changes how about doing them one at a 
> time and actually finishing them.

I wish they had been doing this with sc -> vt, but no... you want
X _and_ text mode? NO SOUP FOR YOU! ;-)

> So you see I see freebsd as a nightmare on elm street, so I need to 
> return to something stable and something that makes sense. 
> Incapatibilies plays a part too.
> Which for me will be my own "scratch built distro".

Nothing wrong with that. I've been using "UNIX-like" distros
like Slackware and Gentoo as well as "preconfigured" distros
of and on, as well as "Linux from scratch". Experience and
knowledge can be obtained that way. But every time I tried
something that should be stable, fast, reliable, predictable,
secure and easy to use in production, I always cam back to
using FreeBSD. - Needless to say, this is my very individual
opinion and experience, and I don't claim it will (or can)
be the same for everyone everywhere at every time. :-)

Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

Want to link to this message? Use this URL: <>