On 7/23/20 7:19 AM, Ted Mittelstaedt wrote:
Well for starters there is no way for ME to validate that the compiled
software you built for me isn't busy running your Doom network server
behind my back. (do people still even run Doom servers?)
People would find out when an unnecessary service is started up though,
no? Especially with services, you can see those with netstat/ss right
away. Additionally, the distribution maintainers are (or at least should
be) the ones compiling it. It could be argued that by installing their
distribution, there is already a certain level of trust being given to
said maintainers.
For example I don't trust Manjaro's maintainers, since they screwed up
their TLS certificate renewal no less than 3 times. That's complete and
utter incompetence on their part. How they didn't already put certbot in
a cron job after the first time is beyond me. On the other hand, I have
started to get fond of Debian.. though also not entirely. But enough to
consider that their packages are probably just fine. I could also verify
this by compiling it myself and comparing the result. They publish their
downstream source code along with any modifications they made.
You are making an argument that is a desktop argument. That is, the
argument goes Those That Know Better Will Do It For You.
Not quite, rather my goals for the system sufficiently align with those
of the distribution I end up going with on this or that system. And on a
server I don't like compiling from source for the same reason that I
wouldn't install and run a desktop environment on it. I consider it
unnecessary cruft. And keeping those packages up-to-date... I forgot to
manually update software I built from a git repository more often than
I'd like to admit. I also lost count.
With my internal BIND servers now running on Alpine (because super
lightweight), that blurs the lines a bit. With 9.14.12, they ship an EOL
version of BIND. And their stock configuration for it was pretty much
unusable anyway. Everything on that was replaced. Compiling from source
or sticking with what they provide, perhaps notifying Alpine's
maintainers that they should look into it? I don't know. But compiling
9.16 ESV there probably wouldn't be a bad idea. Certainly doable, but
not as convenient.
Also, I have had at least 5 Open Source programs over the years that
I found Really Useful to have that the authors decided they wanted to
"take commercial" or they had other religious conversions that made them
decide to go on a rampage and issue take down notices everywhere they
could find their source. One of those for example was when
Nasty-Company-Who-Shall-Not-Be-Graced-With-A-Mention decided to start
charging
for software that created .gif files and the graphics community went
on a ballistic rampage jihad and destroyed every scrap of .gif code it
could find so as to force users to migrate to .png. I did not wish to
migrate to .png so I was very glad that I had saved all the old code,
safe from the fires of the religious zealots.
That's an issue of licensing, it is super annoying, and having older
source code still available in those cases is indeed really useful. I
don't know how relevant this is to this discussion though (granted, can
we still pretend to be on-topic anyway?) given that this is more about
open source projects merely providing binary packages (with the source
available), rather than said project completely denying source code access.
Regarding the ballistic rampage... I can't help but think that this is
what's happening in BIND right now. Fortunately it was only a few days
worth of commits that dealt with.. that totally 100% necessary change of
nomenclature.
Lastly, the way I look at it is when I field a new server, if it cannot
recompile it's OS, kernel, make world, and all of it's applications from
source, then it's a piece of excrement that I do not want in service.
It is also a fact that I have had pre-production servers blow up on
"make worlds" In a few cases this was bad ram, in one case the server
was returned to the manufacturer under warranty. These are machines
that did not display any issues before the OS load. Do not ask me why
it was possible to install all the binaries for the OS and have it boot
with no problems yet blow chunks/blue screen/abend/take a dive into the
toilet/whatever your preferred term for crashing and burning is.
I don't generally run FreeBSD or Linux as a desktop OS, BTW so that
does affect my view of things.
So yes, there is definitely an argument in favor of compiling the
stuff at least on a server.
Fair points. And I agree, having the option is absolutely something I
wouldn't want to give away for proprietary software either. But in all
the software I use (be it on workstations or servers, I run Linux on
both) I do have that option. It's just not as convenient and I certainly
wouldn't want every distro to turn into a Gentoo for increased merit or
reasons like that. If the distro makes compiling from source (be it
upstream or their downstream version) easy, either to compare or to
actually put it to use, all the better.
(My preferred term for for crashing and burning servers would probably
not be suitable for this list)
--
Met vriendelijke groet / Best regards,
Michael De Roover
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
