looks like I am no longer welcome around here

[Polytropon]

On Sat, 9 Dec 2017 20:01:41 -0500, Baho Utot wrote:
> On 12/9/2017 2:23 PM, Polytropon wrote:
> > [...]
> >> 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".
> >
> Helpful as in what I asked how do you boot yo a zfs raid array?  The 
> answer but using the BIOS menu to boot it.  Thjat is just not acceptable.

Things as complex as ZFS RAID have more than one solution,
usually depending on the specific hardware and software
combination you are using.



> Asked how well does grub2 work and how does one install it. answer 
> crikets.  searchging the web produces info from 2009 and earlier, that 
> dog don't hunt.

In the context of dual-booting FreeBSD / Linux, Grub2 has
come up a few times at least on _this_ list, if I remember
correctly. Check if the mailing list archive can help. How
to install Grub2 is a question that the documentation of
Grub2 should provide. ;-)



> >> 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.
> Not really I have built scratch built linux versions for 10 years and 
> have less than 10% of the problems I have had with FreeBSD.

Never _personally_ suffered from it, but I had to help several
fellow sysadmins dealing with "the upgrade ate my system" kind
of trouble. So this definitely happens. And we're talking about
a massive _system_ problem, not just some random application
coredumping or just printing error messages after an upgrade.

However, the wise choice of the Linux distribution has big
effects on what kind of errors you get, and how many, and how
often. Recovery plans, backups, failover systems and so on
can also be very useful, just in case. So if your boss tells
you to install a crappy desktop Linux on a server, doesn't
allow backups ("Disks are expensive!"), and urges you to
do updates at 10 a.m. so he can "observe" you... well...
you know what you'll get. :-)



> > 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".
> 
> I suspect it will kill systems with a ge=reat deal of regulaity

At the current development stage, this could be possible.
But I think when the packaged base will be the default,
it should work _at least_ as good as the current method
(freebsd-update). From the wiki page, you can see that there
is still work to do, so it's clearly optional at this point.



> >> 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.
> 
> I have used all of the different base repos,  none of them are what I 
> would call stable.  I can not count on a release or version to work out 
> of the box,  some did most did not or only with a struggle.

I have no idea what you're doing, but it seems that you are
either doing something wrong (I don't assume you do), or you're
doing something too different, non-standard, discouraged. I'm
using FreeBSD since 4.0 and never got the kind of problems you
are describing - but that just says I'm doing things obviously
different than you. No insult. Actually, I have both systems
that were "never" updated (still running) and those that
receive regular updates (still running as well).



> > 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.
> 
> I've heard that bedtime story all too many times.

It seems to be reality for the majority of FreeBSD users, and
it is consistent with the descriptions of the development
cycle of FreeBSD.



> >> 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". ;-)
> >
> I mixed no ports,  you see I created meta-ports to install a standard 
> set of packages and when changing port repos removed all the packages 
> and rm -rf /usr/local, then built and installed the meta-port package.

Maybe you misunderstood:

"Mixing ports and OS" refers to confusing OS updates with ports
updates (and OS installation with ports installation for that
matter) - compare it to Linux where you don't have something like
"the OS" per se, instead it's a selection of individual packages
made by the distribution maintainers about what they consider the
core functionality of their distribution.

Meta-ports are just an abstraction of ports ("ports that contain,
or better, require other ports"), nothing wrong here. They have
nothing to do with the OS and its version (RELEASE, STABLE, HEAD),
except you have a specific requirement that for example RELEASE
doesn't fulfill (yet), but STABLE already does.



> >> 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? ;-)
> 
> There is every thing wrong with building packages as root.  On my 
> scratch built systems you build all the packages as a user.  You only 
> need to run the package manager as root to install them as any sane 
> admin should know.

I think you don't see the whole picture here.

A port usually defines dependencies. Those are runtime dependencies
and build dependencies. If a build dependency is encountered, for
example a specific compiler, this needs to be installed first,
which of course requires root level access (as the installation
will go to the /usr/local subtree in order to be usable).

Of course just compiling stuff is possible from a regular user
account (given that working directories and maybe a staging area
can be written to). It would _maybe_ (!) be possible to temporarily
install build dependencies (as mentioned above) into such a location
as long as root level access isn't needed for execution.



> >> 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.
> 
> Linux is not multi user?  I beg to differ

I didn't say it wasn't. Don't read things I didn't write. :-)



> > On Linux, "wget http://app.example.com | 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.
> >
> 
> This has nothing to do with installing software to your home directory.

The key is that being a regular user usually restricts you to
your $HOME and a few other locations, so in worst case, if you
install some arbitrary crap given the command illustrated above,
all your data is encrypted, deleted, or whatever. But the system
cannot be harmed. The "| sudo bash" is the real danger, especially
when it's conveniently set up to not ask for a password (and be
accessible this way from _all_ user accounts).



> You have proved my point that FreeBSD users/admins etc do not understand 
> at all what I am trying to say.

That might be possible. I can only speak for myself. Keep in mind
English is not my native language.



> Hell they won't even attempt to have a conversion about it let alone a 
> thought.

This is generally a bad attitude. Still polite language and good
knowledge of terminology and design (of OS, of filesystem, of
ports infrastructure, etc.) are an important aspect to show.



> >> 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.
> >
> 
> Well it WAS promised for release 11.0.

Yes, I read that. But would you like to have something becoming
mandatory which doesn't really work as expected? Just think about
the sc -> vt trouble! :-)



> Isn't 11.0 on EOL?

>From the release information https://www.freebsd.org/releases/ it
seems... yes. A few days ago (2017-11-30, today is 2017-12-13).



> The whole 
> process that is currently being used to package base in not sound.  
> Again no one wanted to listen to different ways to go about packaging 
> base.  I was going to do that but the amount of work for me to do that 
> on my own was greater than if I just go back to my scratch built 
> systems..  Which would YOU do?

As long as you don't _need_ a packaged base, stay with what
works for you. And if FreeBSD _in general_ doesn't work for
you, use Linux instead. There is nothing wrong doing so.



> >> 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.
> >
> I did source upgrades.

Did so myself for a long time, with custom kernel, configuration
tweaked to meet the exact hardware. But nowadays - maybe I'm just
getting older! - I prefer to use binary updates for OS and ports.
FOr me, this works as intended, and there is hardly a need to
build stuff from source.



> Here then is a good example of what hacks me 
> off.  People think they know what some one else was doing and then go 
> about telling them how they are doing everything wrong when it has not 
> even been established what the process or environment is.

This is very problematic, I can understand.



> >> 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.
> >
> Well it was implied that that was to be the future starting with 11.0

Maybe in 12.0 then. :-)



> >> 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. :-)
> >
> 
> Not nonsense look here https://wiki.freebsd.org/Graphics.
> 
> It only works with Radeon HD 7660 or earlier.  Radeon HD 7700 and later 
> nope.
> Nvidia only to GTX 960.

Now you can imagine the horror I feel when I need to buy
new hardware. That's why I'm using old hardware, simply
because it just works(TM)(R)(C). :-)

Note the opening paragraph: "The tables below are not an
exhaustive list of supported hardware."

But... maybe I have a misunderstanding of what the wiki
page you mentioned is about. At a point, it reads:
"Radeon video cards: AGP cards not supported before
FreeBSD 10-CURRENT". I've been using an ATi Radeon 9200
(or was it a 9600?) for many years with FreeBSD 5 and 7,
with full 3D support! What was my problem? ;-)



> >> 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.
> 
> Except there are ports the will not build with GCC that use to.

The port maintainer should be notified that the Makefile
needs some alteration.



> >> 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! ;-)
> >
> 
> Exactly my point.  When you work for a mega corp (billions of dollars) 
> you learn how to roll things out where they work 95% of the time.  Yes 
> you have things happen,  FreeBSD seems to make a mess every time 
> something is rolled out.  See the difference?

As I said, I follow FreeBSD since 4.0, and to be honest, the
problem sc -> vt is the _first_ thing (at OS responsibility)
that I find really annoying. Except for this specific case,
FreeBSD never failed for me in this area.



> >> 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. :-)
> 
> Well rolling out systems can be as easy as this.
> 
> Boot USB drive with os.
> partition drive(s)
> install file systems
> install base package - with boot loader
> install function package
>      like:
>      server-dhcp
>      server-mail
>      server-name
>      server-ftp
>      server-file
>      desktop-kde
>      desktop-gnome
>      desk-lumina
> 
> just a few of my "meta" installation packages

The question is: In how far should packages be considered
base or function? Is a mail server optional? I'm primarily
thinking about inter-OS communication (e. g., cron), but
you are probably thining about something more complex
(like including MTA, MDA, etc.).



> tickle a few config files and your done.  One could even install 
> multiple "function meta packages on a single machine.

Why "even"? One of FreeBSD's strength is that you can
easily have a server on your desktop. :-)



> This is how I install FreeBSD but with the base package missing.
> But I am told I am a rank amature and know nothing of value.

You're definitely not a "know nothing" from what you explain.



> FreeBSD is harder to do this way because of non-packed base and boot 
> loader issues.  Also with a broken getent makes it harder to 
> programmically install user into the system.

Yes, ripping apart what initially has been one functional unit
will cause problems. And imagine the fun when the system cannot
start because the scripts require a new shell that hasn't been
packaged yet for the base. :-)



> It is also how I install my scratch built systems.
> This works on my scratch built systems no matter the disk 
> configuration,  RAID, LVM, MBR or GPT.  it don't matter

Those aspects don't matter when it comes to software installation,
as everything already happens "invisibly" at VFS level.



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