Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 08 Mar 2012 12:38:21 +0000
From:      "Peter Harrison" <four.harrisons@googlemail.com>
To:        "David Jackson" <djackson452@gmail.com>, <freebsd-questions@freebsd.org>
Subject:   RE: Still having trouble with package upgrades
Message-ID:  <4f58a840.a368b40a.7e63.0aad@mx.google.com>
In-Reply-To: <CAGy-%2Bi-faTgPPFya8TD8rjkHG0=4E8S6Pvy2XiawXMru6z=pRQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

   Da= vid,
   Sorry for top posting - my 'phone makes it difficult.
   Do= we really have to have this debate again?
   You made the same points = a short while ago, and there was a long
   on-list debate about the strengths = and shortfalls of the existing
   ports and packages system.
   I don't se= e what value is added by having that debate again?
   I have certainly = been able to do binary package updates between
   releases in the past, so I c= an't agree that it doesn't work at all.
   Be that as it may, if you ca= n't or won't contribute programming
   time, money, or server resources to cre= ate the kind of package
   system you're talking about I don't see how it help= s to continually
   harangue the user community about your wish to make FreeBS= D work
   like Debian.
   Regards,

   --
   Peter Harrison

   From:= David Jackson
   Sent: Wednesday, 7 March 2012 16:29
   To:<= /b> freebsd-questions@freebsd.org
   Subject: Still having trouble w= ith package upgrades
   I still have yet to find a resolution to= the problems I have had
   with=0D
   binary packages and upgrades on FreeBSD= =2E Binary upgrading is
   broken with=0D
   every tool I have tried.=0D
   = =0D
   There is no real reason why FreeBSD should not provide a facility fo=
   r users=0D
   to be able to binary upgrade to the most recent version of al= l
   packages=0D
   with a simple upgrade command.=0D
   =0D
   One faulty arg= ument I heard was that it is often not a good idea to
   upgrade=0D
   to new = software release. The whole purpose of having a release cycle
   for=0D
   pro= grams is to provide stable, tested releases for the public to
   install=0D
   that will will work properly, and improve upon and fix problems with
   older= =0D
   releases. This is why mainline release are differentiated from betas=
   and=0D
   the CVS downloads which are experimental. So you really do want = the
   most=0D
   recent release, especially for corrections to any security p= roblem.
   Making=0D
   upgrades more difficult actually makes the system more= insecure by
   exposing=0D
   people for a long time to security problems tha= t were fixed in
   software but=0D
   making it difficult for people to upgrad= e.=0D
   =0D
   =0D
   As for the security issues of downloading binary pac= kages. The fact
   is=0D
   source packages are not safer than binary packages= , more on that in
   a bit.=0D
   I am astonished that people here would not r= ealise the obvious,
   having safe=0D
   binary installs is do-able from mirro= r sites, just have the
   package=0D
   management software download MD5s from= many mirror sites, compare
   them and=0D
   test the downloaded package, is = they are off, then the package will
   not be=0D
   installed the user will be= prompted to allow a notification of the
   problem=0D
   to be sent to the Fr= eeBSD administrators. The fact is, binary
   releases are=0D
   no more danger= ous than source releases, someone could just as easily
   insert=0D
   bad cod= e in a source code package on a mirror, you need automated
   MD5=0D
   checki= ng anyway, for both binary or source upgrades. So the idea
   that=0D
   sourc= e upgrades are safer is false, just dead wrong.=0D
   =0D
   As for compile= options, the solution is simple, compile in all
   feature=0D
   options and = the most commonly used settings into the binary
   packages, for=0D
   the sta= ndard i386 CPU. If people want customisations then they can
   build=0D
   the= software for themselves.=0D
   =0D
   A good software philosophy is to all= ow software to work out of the
   box with=0D
   as little configuration as po= ssible, but allow everything to be
   configured=0D
   by the user if they wan= t, by shipping software with reasonable
   defaults=0D
   which can be overrid= den by the user. Make simple things easy and=0D
   complicated things doabl= e. In GUI, by default, complexity can be
   hidden=0D
   from users, but if pe= ople want fine grain control, they should be
   free to=0D
   use advanced scr= eens of the GUI to get complex, fine grained
   control. In=0D
   GUI design, = more commonly used settings can be provided more upfront
   while=0D
   advanc= ed features for use by experts can be placed deeper in
   advanced or=0D
   ex= pert screens oft the GUI. Everything should be able to be
   configured or=0D<= br>accomplished by both GUI and CLI and API.=0D
   =0D
   A good user frien= dly model for a useable OS is to allow for binary
   packages=0D
   of the ent= ire system to be upgraded with a single upgrade command.
   It=0D
   should wo= rk out of the box without hassle. Keeping software up to
   date to=0D
   rece= nt releases is good practice, remember what I said about the
   purpose of=0D<= br>software releases. make it easy.=0D
   =0D
   why dont the freebsd admin= istrators just have a build machine
   that=0D
   automatically compiles the s= oftware and makes them available as the
   ports=0D
   are updated.=0D
   =0D<= br>The user should be able to keep their system up to date
   without doing a= ny=0D
   system wide all at once OS-release upgrades at all. There is no re=
   ason why=0D
   kernel and userland programs have to be upgraded at the same= time.=0D
   Especially considering its a good design practice for kernel t= o
   provide=0D
   backward compatability. Instead the system would be pieceme= al
   updated over=0D
   time, including the kernel, in a piecemeal fashion. T= he need for
   system=0D
   wide OS distribution version numbers like FreeBSD = 9.0 is becoming
   obsolete.=0D
   Versions are still very valuable for the ke= rnel, but for collections
   of the=0D
   entire system software, it has becom= e much less relevant. This was
   from an=0D
   age when people would receive= a Tape or CD in the mail and update=0D
   everything all at once, now soft= ware can be upgraded in a piecemeal
   way=0D
   over time with automatic upda= tes. The CD-based upgrade and all at
   once=0D
   system wide upgrades actual= ly for reasons are inferior, in that it
   meant=0D
   often months would go b= y before a software program was updated,
   delying the=0D
   application of v= ital security fixes. Before the age of the internet
   and the=0D
   hacker, t= hat may have been acceptable. Its not anymore. With Firefox
   and=0D
   Flash= for instance, security fixes are made sometimes weekly, with
   an=0D
   syst= em wide at once upgrade model, it could be a very long time
   between=0D
   u= pgrades of such software between releases of the OS software
   distribution= =0D
   CD. The idea of waiting on a FreeBSD kernel release to upgrade firef=
   ox is=0D
   absurd, and the idea that firefox must be upgraded during a ker= nel
   upgrade=0D
   is also absurd. The piecemeal model is much more convenie= nt for
   users,=0D
   providing more up to date packages and no OS release up= grade
   hassle.=0D
   =0D
   There really should be little reason for release= upgrades anymore
   these=0D
   days, when the different parts of the system = can be upgraded
   independantly=0D
   through a binary package management too= l, including kernel and
   user=0D
   programs.=0D
   =0D
   When a new kernel= is released, there is no reason to reinstall all of
   the=0D
   packages on = the system at the same time. Since the kernel and
   userland=0D
   packages h= ave different development cycles, there is no reason why
   there=0D
   has to= be synchronization of the upgrading.=0D
   =0D
   Some here suggested PC-B= SD, it was no better at all than FreeBSD, In
   fact=0D
   in its documentatio= n it demanded a complete system reinstall just
   to=0D
   upgrade to a new ke= rnel version. An OS that requires a user to
   reinstall=0D
   everything just= to upgrade the kernel is not user friendly. It
   creates more=0D
   trouble = and difficulty for users and ironically makes the system
   more user=0D
   un= friendly, and makes these users suffer due to the design faults of
   the=0Dsystem, a user having to upgrade userland packages for a kernel
   upgrade i= s=0D
   a symptom of serious design faults and deficiencies. These two part= s
   should=0D
   be able to be upgraded independently and a good system assur= es
   backwards=0D
   compatability support so older packages can run on a new= er
   kernel.=0D
   =0D
   For now I have totally given up on FreeBSD, all I h= ad with FreeBSD
   were=0D
   problems, big problems. The lack of smooth binar= y upgrades, and the
   poor=0D
   virtual box support made it very difficult t= o use.=0D
   _______________________________________________=0D
   freebsd-= questions@freebsd.org mailing list=0D
   http://lists.freebsd.org/mailman/l= istinfo/freebsd-questions=0D
   To unsubscribe, send any mail to "freebsd-q=
   uestions-unsubscribe@freebsd.org"=0D
   



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4f58a840.a368b40a.7e63.0aad>