Date: Sun, 21 Aug 2011 17:52:10 +0400 From: Slawa Olhovchenkov <slw@zxy.spb.ru> To: Peter Jeremy <peterjeremy@acm.org> Cc: Vadim Goncharov <vadim_nuclight@mail.ru>, freebsd-arch@freebsd.org Subject: Re: FreeBSD problems and preliminary ways to solve Message-ID: <20110821135210.GA62845@zxy.spb.ru> In-Reply-To: <20110821110521.GA48820@server.vk2pj.dyndns.org> References: <slrnj4oiiq.21rg.vadim_nuclight@kernblitz.nuclight.avtf.net> <20110821110521.GA48820@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 21, 2011 at 09:05:21PM +1000, Peter Jeremy wrote: > >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. Yandex try to reduce count of servers. Now [in Yandex] co-exist large set of productions servers and also large set of servers for tests and labs purpose. Migrating to Linux with virtualisation allow to drop tests and labs server and run on production cluster in off-peak time. > >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. In real word this is [no backward compatibility] rare case. > >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. Also, this is rare case. More frequent liby.so.2 updated to liby.so.2.1, liby.so.2.2, liby.so.2.2.1 etc. > >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. This is complain about missing pkg_update (since FreeBSD 3.x). Only pkg_add and pkg_delete, this is not preserve +REQUIRED_BY, for example. > > * 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. Realy?! I can install binary package by pkg_add and found build options in /var/db/ports/*/options? > >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. Why is not done by installworld? > >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. Define base as virtual packae with options (BASE_SSL, BASE_SENDMAIL etc) > >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. Define 'negative' package as package remove files from base systems or other package. Allow package to replace files from base systems or other package. All this (removed or replaced files) must be preserved,
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110821135210.GA62845>