looks like I am no longer welcome around here

[Polytropon]

On Thu, 14 Dec 2017 19:52:23 -0500, Baho Utot wrote:
> 
> 
> On 12/13/17 11:54, Polytropon wrote:
> > 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.
> > 
> > 
> 
> The Raidz i install was from the manual, so how come there is nothing in 
> the manual showing one how to boot it?
> 
> It is not complex by any means

This is really a problem. A procedure that has been verified (!)
to enter the handbook, i. e.,  how to install something, should
also include how to use it, unless it's not trivial.



> >> 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. ;-)
> > 
> > 
> 
> well the docs do show one how to make it work,  freebsd could integrate 
> it into to things....would not hurt any one much to do that.  Then 
> freebsd would have a newer boot loader instead of the achient one they 
> have now.

I don't really see a problem with the classic MBR and GPT
bootloaders. They do what they are intended for. Specific
combinations, like UEFI + GPT + multiboot _can_ be a
problem, but I'd rather deal with a simple and understandable
concept that FreeBSD uses than be forced (!) to use something
complicated.



> >>>> 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. :-)
> > 
> 
> I don't do linux distributions, I roll my own

I understood that from your explanation.


> Who is "he" anyway?

In the example above "he" = "the boss".



> >>> 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.
> 
> 
> The manner at which packaged base has taken is just horrific
> I'll be dead before it is of any value.

We will see. Or maybe not... ;-)



> Most on here don't even know why one should build packages in a "clean 
> room"  let alone know why you should only build packages with a user 
> account.

The jail approach that Poudriere uses implements such a
"clean room" concept.



> What I am doing is simple,  you folks like to wrap it up into some 
> complete ball from outer space.
> 
> Install an OS to use as a toolchain
> 
> fetch source and build system
> 
> Install the built system
> 
> Add packages to create Desktop/servers boxes.
> 
> See Really simple.
> 
> I have been doing that with Linux since 1998.

This description raises one question - please correct me if
I'm wrong:

You're saying that you first build something from source
(the build system), then you add binary packages... wouldn't
it be easier to

	(a)	use a source-based system only, or

	(b)	use precompiled packages only?

Combining both forms is surely possible, and may even be
a good solution under specific circumstances, for example
if a custom-compiled kernel or userland is needed, or a
port requires options which are not the default options.
This is where precompiled packages just cannot deliver
that kind of flexibility. However, FreeBSD has done good
work in providing a system that allows binary upgrades
both for the OS (freebsd-update) and ports (pkg), which
is a real improvement compared to what was present 10
years ago (with the "classic" infrastructures, before
the revision of the build system and the introduction
of pkg).




> >>> 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.
> > 
> 
> What is the average uptime?  I have a raspberry pi running Arch linux 
> with an up time of over 3 years.  It will be retired when I finish my 
> scratch built linux system for a Raspberry Pi 3.
> 
> The Arch system on the pi was built by me,  I don't use binaryies from 
> any source.  Binary blobs for hardware excepted.
> 
> If I can not compile it I don't use it.

I feel the same about software installations myself, but the
ability to use precompiled packages that just work (TM) is
very convenient. PCs today are more than powerful enough
to build things fron source, except you consider software
as complex as a whole operating system, such as the common
web browsers and office suites. Again, precompiled packages
make installation and upgrading (!) eaiser / faster.



> >>>> 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.
> 
> If one builds a base OS and adds "ports" there is no mixing.  I have 
> heard too many people say that.  I see no evidence.

OS and ports live in independent worlds. The problem arises
from _confusing_ OS and ports, forgetting about the "barrier"
that keeps your OS fully functional even when you make a total
mess with the ports. Other problems occur when you combine
software installed with "pkg install" and "make install", i. e.,
binary packages and stuff built from source with nonstandard (!)
options. In such cases, "pkg lock" or using Poudriere is the
way to go.



> If I am running version 9 why should compiling the "latest ports" not 
> work.

This depends on the toolchain that you have on that system.
During FreeBSD 9, the "big revivion" of the port system
happened, if I remember correctly. Newer ports trees won't
build on the old system, and older ports trees aren't even
supported anymore. It's like trying to use "pkg_add" today. :-)



> You seem to think I build ports on version 11.0 and intend to run 
> them on 10.3.  Just not the case.

That was not my assumption.



> > 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.
> > 
> 
> meta-packages are everything...if you know what you are doing.
> I use just 4 meta-ports with synth to install a freebsd desktop.

I see mata-packages at the upcoming "packaged base" to be
able to create a tailored system, for example one where you
can "remove" lpr (read: not install lpr at all) because you
are going to use CUPS anyway. This is the equivalent of
using src.conf to avoid building and installing lpr. Such
"OS meta-packages" could be used to allow fine-grained control
of what to install (at install time, not later on).



> > 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.
> > 
> 
> That is why you have a "build system".  I build a gcc toolchain just to 
> build the "new system".  You can not boot strap an OS with out building 
> a tool chain to separate you from the host OS.

With tools like Poudriere, those toolchains are kept within
the jail that serves as a build system. They do not affect
the (host) OS.



> >>>> 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! :-)
> > 
> > 
> 
> No I would like when a project is going to be undertaken that the folks 
> bringing the project would have had an project scope and then used some 
> GANTT charing to see if what they are proposing is doable in the time 
> slot allotted.  Hell it looks like the devls here just start hacking on 
> things without any direction.

A decision was to retire sc... ;-)



> >> 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.
> > 
> 
> As long as you grant me that and I am allowed........

I am not the responsible authority for this specific kind of
permission. I cannot tell you which institution to attend to
because I'm using Linux myself without someone else's proper
permission... :-)



> >>>> 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.
> > 
> 
> I see build from source as security issue....A good habit as I know what 
> was installed.  Yes some one could place a back door in the source but 
> it would not be likely

On few occassions, it happens. But in how far is building
from (manually unverified) sources on your own system fundamentally
different from using what the FreeBSD build clusters created?
Generally, I understand (and share) the attitude of building
from source as an aspect of security.



> >>>> 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. :-)
> > 
> > 
> 
> I'll never see 12.0,  Hell from 11.0 to 11.1 didn't go well for some folks.

And people complain that FreeBSD 5 was bad! :-)



> >>>> 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? ;-)
> > 
> > 
> 
> Well on linux I can walk into the local computer store and buy the 
> current AMD graphics card and run it... freebsd never, unless I run it 
> in vesa mode.... Oh yea I will run out and buy a $500.00 graphics card 
> just to run vesa.. I can see that now.

Don't be stupid. First think, then buy. And "to think" here
includes verification of hardware compatibility. You never
do something wrong this way. And if VESA modes are okay for
simple desktop use, why spend $500 for a GPU? The cheapest
one will do.



> >>>> 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.
> > 
> 
> You time will come.

I hope not!



> >> 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. :-)
> > 
> 
> You go right ahead and do that,  I am not even going there.

I had to do this on few occassions, ranging from office print
servers to internal web servers and shared directories, but
nothing more complex of course. Separation of functionality
is usually preferred, but sometimes, the rule is "Do what I
tell you to do, I know better!" which pays the bills. But I
usually make sure I have written and signed documentation,
stating the risks and predicted problems, so it's not _my_
fault when something breaks. :-)



> >> 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.
> > 
> 
> So that is why no one wants to listen?  I know about what I am doing so 
> I can not be listened to, so the devs path will not diviate?

I have no idea, I cannot read people's minds...



> >> 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. :-)
> > 
> 
> Don't have a clue about what you are saying

Have you ever encountered a system where some "certified
consultant" has removed the system's scripting shell? And
you are not allowed to touch anything, but make it work
again? :-)





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