Likes
- C macro preprocessor (I really love this one)
- C programming language
- Ruby programming language
- bash
- Autotools
- RPM packaging system
- Plain TeX
- XFCE
- midori
- mplayer2
- XHTML
- PulseAudio
- NetworkManager
- Fedora
- Matroska video container
- FLAC (Free Lossless Audio Codec)
- IBus input system
Dislikes
- C++ programming language
- C# programming language
- Java programming language
- CMake
- PHP
- Flash
- Firefox
- Gnome Shell
- WYSIWYG HTML editors
- LaTeX
- Symbolic Icons (the new hit in GTK3 based apps)
- Social networking sites such as Facebook or LinkedIn (I move invitations to these to my SPAM folder no matter who sends them)
- DEB packaging system
- Pointless limitations of choices exposed in UI (*cough* *cough* g-p-m, gnome-shell, …)
- Too complex UIs (*cough* *cough* KDE)
What about you?
Posts
11 comments:
I'm a web-dev so I have to use Firefox instead of Midori on my XFCE-Desktop sometimes (as well as PHP). Some Nerds are using Fluxbox (+ Conky) and vi(m) of course!! What about GIT? (Some) Windows "Nerds" always save their backups on their GUI shared samba server called backup_new, backup_old, backup_veryold :))
Richard: oh, yeah, git, I totally forgot about it. Yup, I like git and pretty much don't like the rest (I've tried CVS, SVN and mercurial).
Might start a flamewar here, but why do you like RPMs more than DEBs? Don't get me wrong, I use RPMs too (due to Fedora), but I can't tell any valid argument for either of them.
Like Pulseaudio seriously?
@Máté Gelei: Well, I kind of like how you create the RPMs, it seems very clean and easy to understand to me, on the contrary I always have troubles finding what I want in DEB source packages… It stems more from packager perspective than user perspective.
@Anonymous: Why not? Thanks to PA I no longer get 'device busy' messages, it finally correctly down-mixes 6ch audio to 2ch output, I can easily use not only more applications with sound output at once, but also more audio cards (I actually have an external audio card that I use only at the place I have it at) and still easily manage all these from one place. Now, if it didn't fall over from time to time, it would be perfect.
there is serious work in compiling such list of likes and dislikes, since, like any nerg, i have many of those, some more, some less important. is a good reflection topic.
@nicu: Yup, I totally agree. When I started writing it there were a few items in my mind that had to be there no matter what (C and Ruby vs. C++, C# and Java, plain TeX vs. LaTeX, good old [static] [X]HTML vs. PHP and Flash), then I tought really hard about few other items that I (dis)like and when nothing else had come to mind for a few minutes straight, I called it quits and pushed publish.
And then someone comes and reminds me that I forgot the git vs. the others war :-D
>Autotools
Now I dislike you.
Take care of that cough :P
@Máté Gelei: deb has no idea of "pristine sources" where rpm almost mandates this (by design). RPM also requires md5sums of every file and so something like rpm -V is guaranteed to work. Sure you can use debsums and it will normally work, but the reason something like rpm -V doesn't exist for debian packages is because the packaging policy doesn't mandate that support for such a feature is necessary.
To build an rpm, you need 1 file and the rpmbuild command. To build a deb, it is a whole directory of files and mess of silly commands (dget, dput, dch, etc, etc, etc). While building rpms, you can do most scripting or advanced things using regular bourne shell scripting. With debian, you often need to use behemoths such as cdbs, of which I don't full understand yet. From a packaging perspective, rpm packages are much much easier to fix.
Those are my personal 2 biggest gripes. Another one could be that dpkg uses plain text files to store package lists where rpm uses bdb which is a more transactional database format. In using linux for over a decade, I've seen dpkg completely crap itsself more than once due to corruption of these files under /var/lib/dpkg/info. Fixing it required manually editing this file and commenting out everything in $package.preinst or $package.postrm scripts. I've never seen it happen from a Fedora/CentOS/RHEL system nearly this bad. The one time I did, rpm --rebuilddb fixed the issue entirely.
Both are good however as competition breeds innovation. Typed from an Ubuntu desktop and likely to be re-read from a Fedora laptop later this evening.
Hush your mouth about KDE son.
Post a Comment