Date: Sat, 09 Dec 2017 18:20:51 -0700 From: JD <jd1008@gmail.com> To: freebsd-questions@freebsd.org Subject: Re: looks like I am no longer welcome around here Message-ID: <5A2C8BF3.4040607@gmail.com> In-Reply-To: <e844e34e-3a66-7860-f03b-dab4c0237df3@columbus.rr.com> References: <CALM2mEkgjZ2XdiRvuT1364zWOZ4XY_6KSAg9dTqREK3cQKjWAw@mail.gmail.com> <20171209135853.a6c104f5.freebsd@edvax.de> <d9656b09-14b5-390b-6c7f-3ae3a4c123da@columbus.rr.com> <20171209142711.d5bd91b7.freebsd@edvax.de> <4b109558-8422-a62a-9c45-748e03efbfba@columbus.rr.com> <20171209202321.b9919fc3.freebsd@edvax.de> <e844e34e-3a66-7860-f03b-dab4c0237df3@columbus.rr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Baho, I have used FreeBSD for many years. It is true that it needs a lot of know-how, not all of which is in the documentation, especially your problem with booting a FreeBSD on a ZFS Raid Array. If BIOS is ignorant of the presence of a ZFS Raid array as a "BIOS DISK", then you will have to boot it indirectly - an example of which is to tell bios to boot from a disk which has grub which in turn has knowledge of zfs raid array, and has a menu of bootable OS'es, one of which would be the ZFS Raid Array. This is, for example, how we work work multi-boot systems. Am sorry for the trouble you are having. FreeBSD Releases are STABLE insofar as the amount of testing done with most common configurations. Perhaps testing needs to be more rigorous to include fringe areas as what you were trying to accomplish. But that would really delay release dates considerably. Regards, JD On 12/09/2017 06:01 PM, Baho Utot wrote: > On 12/9/2017 2:23 PM, Polytropon wrote: >> 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". >> > 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. > > 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. > >> >>> 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. > > >> >> 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 > >> >> >>> 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. > > >> >> 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. > > >> >> >>> 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. > >> >>> 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. > > >> >> >>> 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 > >> 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. > > You have proved my point that FreeBSD users/admins etc do not > understand at all what I am trying to say. > Hell they won't even attempt to have a conversion about it let alone a > thought. > >> >>> 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. Isn't 11.0 on EOL? 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? > >>> 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. 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. > > >> >>> 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.) >> > > It works, trust me I have done that. You need to hunt and peck a > little but it is not difficult. > >> >>> 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 > > >> >>> 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. > > >> >>> 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. >> > > Not by me, I am leaving remember, you folks loss...... > > >> >>> when I started using freebsd ver 10.1 I was told just wait for rev 11 >>> and package base will be there.....Really? >> No. :-) >> > > Yes it was look it up, that was all the rage for going to 11.0 > > >>> 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. >> > > Bug report Hell the developers are the ones removing all support for > base in 13.0. And building it 12.0 without but leaving the "Hooks" > >>> 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 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. >> > > Been there done that. I was not the one saying that base was going to > have no GNU software there. Your developers said that. > >> >>> 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! ;-) >> > > 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? > >> >>> 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 > > tickle a few config files and your done. One could even install > multiple "function meta packages on a single machine. > > 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. > > 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. > > 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 > > > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "freebsd-questions-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5A2C8BF3.4040607>