Date: Sun, 21 Aug 2011 21:05:21 +1000 From: Peter Jeremy <peterjeremy@acm.org> To: Vadim Goncharov <vadim_nuclight@mail.ru> Cc: freebsd-arch@freebsd.org Subject: Re: FreeBSD problems and preliminary ways to solve Message-ID: <20110821110521.GA48820@server.vk2pj.dyndns.org> In-Reply-To: <slrnj4oiiq.21rg.vadim_nuclight@kernblitz.nuclight.avtf.net> References: <slrnj4oiiq.21rg.vadim_nuclight@kernblitz.nuclight.avtf.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--huq684BweRXVnRxX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2011-Aug-17 23:10:19 +0000, Vadim Goncharov <vadim_nuclight@mail.ru> wro=
te:
>A month ago techlead of Rambler's Mail department declared in his blog=20
>that they begin migration from FreeBSD to Debian/Ubuntu. Comments to the=
=20
>blog entry (there was much flame) revealed that search department of=20
>Russian search engine #1 Yandex.com also plans to migrate their=20
>search cluster - about 30,000 servers in several DCs (~60% of total=20
>their servers - to Linux.
This is unfortunate.
>The official reasons (really semi-official, as these are individual
>blogs), in short, were:
> * inadequate package manager and huge monolithic base system
> * lack of OpenVZ-like virtualization (need CPU limiting)
> * a FreeBSD marketshare forecast for 5 years
I'll accept that the package management could be better and the base
system is monolithic but it's hardly huge. It's not clear how
marketshare forecast is relevant (though if they are as large as you
imply, the marketshare forecast is circular). To take a devil's
advocate approach, they need to accept some of the responsibility
for what they perceive as FreeBSD shortcomings - they have chosen
to not fund the development of functionality that they require and
are now complaining that no-one else has either.
>specialists on the market to hire (e.g. Yandex has about 20 FreeBSD
>admins and about 84 Linux admins, for all other their services and
>40% of servers).
Based on this, a Linux system needs about 6.3 times as many admins as
a FreeBSD system. It's not clear how migrating to Linux is going to
save money here. And, again, they could always train people to meet
their needs instead of expecting someone else to do it.
> 1. Social (psychologic) problems of community (marketing, docs, ...).
>
>This is the most important one, because all technical problems are just
>won't get solved because are even not viewed as problems. The FreeBSD
>Project does not listen to users' needs. The typical response when poor
>user want something is: "we don't need this, we won't change for you",
>with "where are your patches?" at best. Then many users go out when see
>such attitude toward them.
I agree with this. The underlying problem is that most FreeBSD
committers and developers are volunteers who work on FreeBSD in their
spare time in areas that interest them. Even if they agree with the
issue that the user raised, they probably don't have all of the time,
expertise and motivation to work on it. Note that you can't tell a
volunteer what to work on. If he doesn't want to work on something,
he won't. If you push him, he'll just leave.
If someone (person or corporation) wants some functionality that
doesn't exist then they are going to need to either pay for it
themselves or convince someone else (eg FreeBSD Foundation) to pay
for it. Obviously, the FreeBSD Foundation is going to want to fund
areas where it perceives it will get the greatest benefit.
> 3. Ports and packages.
>
>What was the main problems with large-scale installations of FreeBSD in
>that businesses? In short, that binary packages are not equal in rights
>to ports, and that complicates things (i.e. requires too much work) when
>one have many (> 10) servers. This was listed to me as:
>
>1) No pkg and pkg-devel versions. The -devel version is headers, static
> libs, programmer examples, etc. not needed in production (we could
> say this part is what is actually depended on in B-deps).
Xorg is partially broken up in this way. In general, it is up to the
ports' maintainers to do this - the FreeBSD project just hosts the
ports infrastructure, it's up to maintainers to supply and maintain
the actual ports. Note that requiring both pkg and pkg-devel versions
of ports significantly increases maintainer effort for little (to
them) perceived value. Also, I find having separate pkg and pkg-devel
versions a real PITA - I regularly find that information i need is
missing from the pkg file and I have to dig out the missing files.
Out of interest, what is the rationale behind this requirement.
=20
>2) Package name is dependent on options, so packages with another opts
> don't work well when dependencies are rebuilt.
This isn't always true and there are pros and cons to both approaches
- making the package name independent of the options makes it very
difficult to determine what options were used to build the package.
This _is_ an area where the higher-level management tools (eg
portmaster) can help.
>3) Conflicts: no way to have apache13 and apache22 the same time.
Because both install files with the same name. Again, this is an
issue for the maintainer to address.
>4) No dependence on base system. You may cut out something, recompile
> world, deploy it on cluster and just then see that some packages are
> now don't work.
Ports _must_ depend on the base system or there's no point in having a
base system. This is no different to changing any other port
dependency and expecting it not to have any impact. I agree that
there's no explicit tracking of base system dependencies and that is
a deficiency.
>5) Dependencies are badly designed. No version ranges in dependencies,
> no alternative packages, no priorities in package search.
I would dispute that dependencies are badly designed. There may be
scope for allowing more flexibility in some cases but you then run
the risk of running into subtle incompatibilities - especially since
the maintainer can't be expected to verify all possible combinations.
>6) Update problems. The version is just coded into name of package, and
> dependencies are on the entire name, so there are situations when
> install/upgrade of just one package may require rebuild 3/4 of all
> pkgs. You cannot easiy modify installed package without editing pkgdb
> manually. It is impossible to upgrade/replace package by out of the
> box tools.
Agreed. Tools like portmaster can assist here but it's not possible
to always avoid rebuilding packages: If portx-3.1 depends on liby.so.2
in porty-2.4. When porty-2.4 gets upgraded so it installs liby.so.3,
there is no alternative to rebuilding portx. It is unfortunate that
a number of widely-used "core" ports have very unstable ABIs which are
regularly changed but FreeBSD has no control over that. This is a no-
win situation - if the ports are not updated, people complain that the
ports are out of date. If the ports are updated, people complain about
having to recompile all the affected ports.
>7) Base system has no "out of the box" tools for package upgrade. Our
> business opponents say this the least problem as one can always
> install portupgrade, but conclude that overall base system concept
> does not play well with full-featured packages (see also next part
> about base system).
And later on, you complain that the base system is too large. You
can't have it both ways. Note that having the package upgrade system
as a port means it can be be updated independently of the base system
- which is a major benefit.
>8) There is no -STABLE supported branches in ports.
This issue comes up regularly. It's not clear how to achieve this
without a major increase in infrastructure and committer resources.
>It is obvious that current packages are not first-class citizens, in
>comparison with ports.
Source code is inherently more flexible than pre-compiled executables.
There is no way to avoid this.
>So packages need to be "equal in rights" in ports. The ports can have
>things like this:
>
> .if ${OSVERSION} < 700104 || ${OSVERSION} >=3D 900000=20
Different versions of FreeBSD have different functionality. Sometimes
this affects ports.
> * Options must be included and installed to /var/db/ports/*/options
> (this will allow to rebuild installed binary pkg as port)
This is already done.
> * Info about options must be included to /var/db/pkg/*/+CONTENTS like:
>
> @option WITH_SSL
> @option WITHOUT_DEBUG
>
> * Dependencies must be able to specify needed OPTIONS, both required to
> set and required to be unset, somewaht like:
>
> RUN_DEPENDS+=3D foobar:${PORTSDIR}/devel/foobar:+SSL:-SQLITE
>
> This will allow to detect conflicts with installed packages with
> incompatible options.
>
> * For the package file names, introduce presets, e.g.:
>
> OPTIONS_PRESETS=3D default "+SSL:-DEBUG" \
> lite "-SSL:-DEBUG"
These all seem like good ideas.
> * (internal) move away from CVS, rebalance to category-subcategory.
I don't believe the former point is relevant. There is probably
scope for improving port categorisation.
> 4. Base system, closely related with packages.
=2E..
>2. Consequently, there is no way to check integrity (MD5 etc.) of any
> non-RELEASE variant (freebsd-update IDS is very limited).
If you have built a non-standard world, you need to generate/verify
your own checksums. mtree(8) can do this and there are a number of
other suitable tools in ports.
>3. No ties between base system and packages: who knows what previous
> admin has installed, you may have compiler or may not have, etc.
> Packages may silently broke if some part of base system SUDDENLY
> disappears, as no dependency information is recorded.
This _is_ a deficiency. It's not clear how to cleanly resolve this.
>4. Base system is monolithic, so there is no easy way to replace one
> component with another - ports replacing base parts are hemorrhoids.
OTOH, the base system is integrated together and works as a whole.
This is a major advantage over Sinux.
>Looking at /usr/src/sontrib and http://wiki.freebsd.org/ContribSoftware
>we can identify many of what could became a package. There can be
>different approaches to criteria "what is in base system":
>
>1. Only what is done on freebsd.org: all contrib must go to pkgs.
I don't believe this is currently practical due to dependencies from
core FreeBSD code on contrib code.
>2. Whose effective vendor is now *@*bsd.org: contrib from other BSDs may
> still live, and those with ceased upstream or renamed
> (non-conflicting with ports) soft like libbsdxml, too.
I'm not sure I follow this.
>3. Axe out only the most odious contrib parts: BIND (as Peter said in
> archives, host/dig could be resurrected from Attic), sendmail (could
> be replaced by dma) and several others, presumably GCC/binutils & CVS
> (I've also heard about painful Kereberos interferencing with Samba).
This would seem to be a lose-lose situation. The workload on FreeBSD
committers goes up as they take over all maintenance of local host/dig
etc and users need to do more work to build a functional system. And
you've already indicated you are opposed to having ports replace base
components.
>Axing out GCC to packages has another benefit: the newer GCC could be
>used, and base could be polished to be more compiler-agnostic (hello,
>clang).
Work is currently under way to replace gcc with clang for building
FreeBSD. I don't believe it's possible to build a truely compiler-
agnostic system - FreeBSD is large and complex enough that it's
highly likely to trigger compiler bugs. In order to deliver a
reliable base OS, the compiler needs to be defined.
>to split docs to packages, that's a right direction. For POLA reasons
>all axed out packages (and sendmail too, respect traditions) should be
>just packaged on CD1.
Agreed.
> 5. Too short major releases' cycle.
=2E..
>It is known why the current scheme was adopted: the 4.11/5.3 case,
>a horror.
"Horror" is over-doing things. 3.x and 5.x both included major
changes which made migration relatively difficult, as well as making
it difficult to merge code back to the previous release.
>Proposed solution: prolonging major releases fork time a little. Just to
>time so only one stable branch will exist. I hope increasing branch
>lifetime to one minor release will help:
The difficulty of backporting fixes relates more to the magnitude of
change in the code base than the time. It's not clear that increasing
the longevity of major releases will really solve the problem -
however long the Project supports branches, there will always be
people complaining it's too short.
> 6. Bug tracker, unicode and other less important trivia.
>
>GNATS is too old and unfriendly e.g. to user attachments.
Agreed. But it's not clear what the solution is.
>That's all for today. Thanks to everyone who has patience to carefully
>read this all entirely.
Thanks for your mail. It has made thought-provoking reading.
--=20
Peter Jeremy
--huq684BweRXVnRxX
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iEYEARECAAYFAk5Q5nEACgkQ/opHv/APuIe0vgCcDoBI2d47ZkZBiU8dSrmrw+51
q60An0KY9ekLXzK36lB2nUUFbQ3Q9t/7
=ZVuU
-----END PGP SIGNATURE-----
--huq684BweRXVnRxX--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110821110521.GA48820>