Date: Sat, 9 Dec 2017 20:23:21 +0100 From: Polytropon <freebsd@edvax.de> To: Baho Utot <baho-utot@columbus.rr.com> Cc: freebsd-questions@freebsd.org Subject: Re: looks like I am no longer welcome around here Message-ID: <20171209202321.b9919fc3.freebsd@edvax.de> In-Reply-To: <4b109558-8422-a62a-9c45-748e03efbfba@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>
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 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. > 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. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171209202321.b9919fc3.freebsd>