looks like I am no longer welcome around here
baho-utot at columbus.rr.com
Fri Dec 15 00:52:35 UTC 2017
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
>> 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
>>>> 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
Who is "he" anyway?
>>> 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.
It really shows me that the devels are way behind the 8 ball.
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
>>>> 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).
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.
>>> 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.
>>>> 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.
If I am running version 9 why should compiling the "latest ports" not
work. You seem to think I build ports on version 11.0 and intend to run
them on 10.3. Just not the case.
> 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.
>>>> 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).
I can build a complete scratch built linux base OS as a user and never
have to run root at all.
Root is only used when installed the scratch built system.
> 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.
>>>> 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).
Swing and a miss. you are out in left field.
>> 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
> 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.
I am not going to waste any more time on freebsd.
>>>> 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.
>> 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.
As long as you grant me that and I am allowed........
>>>> 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
>> 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.
>>>> 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.
>>>> 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
>> 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.
>>>> 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.
I have notified port maintainers many a time, they can not be bothered.
Three years later and no fix no response.
>>>> 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.
>>>> 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
>> 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.).
No I taylor make the "port list" for each function, I create a
meta-port with what is needed.
>> 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.
>> 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?
>> 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
>> 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.
More information about the freebsd-questions