Tugux, a mais recente distribuição nacional de linux entrou esta semana para o distrowatch. Ainda está um pouco crua para desktop usage, mas se calhar já vale a pena experimentar.
É por causa disto que eu prefiro apt (ou tgz).
quoting temporary title
- 1 - Berkeley database backend. Dpkg does a much faster and at least equally reliable job with plaintext files, which don’t get corrupt as often, don’t need periodic reconstruction and are human-readable. The SQL database backend is a huge step in the wrong direction.
- 2 - Installation of new package before removal of the previous version. This adds unnecessary complexity and leads to a non-intuitive sequence in execution of pre- and post- install/uninstall scriptlets, and can create problems only solvable using triggers. Triggers shouldn’t exist, they only solve problems caused by design problems and policy flaws.
- 3 - Network awareness features. It increases size and complexity of the binary, and tries to perform a task that should belong to an external utility such as Apt-get or Smart. Recent versions try to contact PGP keyservers and block execution when it fails.
- 4 - Obtuse macro expansion and comment handling in specfiles. Macros expand inside comments, and line breaks cause unexpected behavior.
- 5 - Absence of logical OR in requirements forces the developer to always regenerate all alternative packages to provide virtual packages.
- 6 - Incomplete timestamp format in specfile changelogs. Standard
date(1) format or other providing time of change is needed.
- 7 - File dependencies are treated in a special way and are not regular virtual packages (a better design would make packages relate only to other packages, real or virtual). They increase complexity of dependency resolution and promote sloppy pratices in software packaging.
- 8 - Problematic handling of simple situations such as replacing directories with symlinks. Bad habit of stating all mounted filesystems prior to installation (at least in earlier versions).
- 9 - Non-intuitive (or plain broken) algorithm to compare package versions (example: 1a > 1B) . Epoch zero is considered newer than no epoch at all.
- 10 - No provisions for interactive configuration scripts or human inspection/approval of new configuration files, and no concept of post-transaction configuration.
E que nem me falem de portage e emerge… Ainda estou à espera que me expliquem porque é que eu preciso de instalar o mysql quando apenas preciso de um cliente de mysql…
Estão já prontas as novas features do Kmail e do Kopete para o KDE3.5, que podem espreitar aqui.
Estão também já prontos:
KLettres
o Rewrite the code to allow 4 letters syllables or more. Usability improvements as well: a Look menu with Themes and Modes, a new Level menu, use of QPainter for writing the letters/syllables.
Kalzium
o Provinding a view which shows the families of elements like transition-metals or alkaline elements
o Display more information in the table
As futuras features do KDE3.5 e current status podem ser vistas aqui.
Saiu esta semana na anandtech uma review intitulada de No more mysteries: Apple’s G5 versus x86, Mac OS X versus Linux. Surpreendeu-me com bastantes elogios à arquitectura do processador quando depois concluiu indicando que embora o G5 seja um processador super escalável e desenhado de um modo agressivo, a sua performance como servidor é catastrófica. E acreditem que o adjectivo não é exagerado! Os dual G5 a 2.5 e 2.7 GHz tiveram uma performance similar a 1/10 dos Dual Xeon(3,6) ou Dual Opteron(2,4) tanto com o MySQL4.x como com o Apache 1.3.x. E continuam afirmando que Mac OS X is incredibly slow, between 2 and 5(!) times slower, in creating new threads, as it doesn’t use kernel threads, and has to go through extra layers (wrappers). No need to continue our search: the G5 might not be the fastest integer CPU on earth - its database performance is completely crippled by an asthmatic operating system that needs up to 5 times more time to handle and create threads.
E terminam assim:
Workstation apps will hardly mind, but the performance of server applications depends greatly on the threading, signalling and locking engine. I am no operating system expert, but with the data that we have today, I think that a PowerPC optimised Linux such as Yellow Dog is a better idea for the Xserve than Mac OS X server.
Podem ver a review aqui.