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