There was a time (late 90s) when GCC would optimize conditionals in an asymmetric way. Somebody will hopefully correct me, but I think the advice was to make conditionals usually be true, for best performance. Since most coders would never hear about this asymmetry (though that's just my impression) it was a bizarre case of favoring one branch of a conditional over another for purely historical (machine code) reasons.
I think now branch prediction on processors can go either way, just as long as it's biased one way or another. If it's not biased one way or another, try to reduce out branches into vectorizable instructions (or pray that GCC takes care of it for you).
Branch prediction isn't a GCC thing, it's a processor thing.
Not to hijack this post, but I'm saddened every time I see anything monte carlo related referred to as the metropolis algorithm. When you're the boss, what you say goes.
For those of you that don't know about Slackware. Slackware is the oldest distro and it is still plenty alive today. When to setup linux on my computer in the early days with other distros (red hat/suse/etc), this would eventually crap up (rpm hell) and give me something unusable. Using Slackware forces you understand how everything works in a linux distro. This lets you fix your own problems.
I know you didn't mean to bring this up as a point against rpm but my ALL TIME MOST HATED PHASE is rpm hell. I still hear people say that they won't use RPM based systems because of RPM Hell which makes me inside want to jump through the screen and shake them and say "Have you ever built a single package?! Because if you ever have you would know this is 100% crap for over 10 YEARS!"
Sure there was a time frame when there was an issue with dependency and it was fixed but everyone treated it like it still was an issue 5+ years later.
Sorry rant over but I just want people to know that RPM issue was just an issue in the early 2000s and Redhat made --redhatprovides and --redhatrequires command line options that if people used them would fix the issues at the time till things got changed with libraries.
Sorry, but I am still stuck in my own version of RPM hell, and yes I have packaged RPM's.
The problem: production servers for a client use RHEL 6.3 and are very slow to upgrade. Moreover, they don't have the subscription to RH's commercial repos, and instead host their own, which means that some packages are straight up missing.
For development I use CentOS of a matching version. All works well until I go to deploy something to production and find out that a package I need is not available. The solution has been to (a) install packages from the CentOS repos (yup, old school download them off their site and then `rpm -i` them locally) or ask the client's IT to temporarily enable certain repos of later RHEL versions they have, so that I can install packages with lots of missing dependencies. The most recent fiasco with this involved ImageMagick and ImageMagick-dev not being there and depending on a crapton of libraries that were also missing.
Now, I am not RPM-distro professional, I stick to Debian derivatives for the most part, but I have worked with them enough to know that unless you do things by RH's book, you are going to be in trouble, and even people whose full time jobs it is to maintain these production servers seem to have a really hard time figuring out how to get this right.
P.S.: One solution I attempted was to create my own RPM repo that I could these missing packages from. This worked for some, until it landed me in a world of hurt where yum really wanted to install i386 versions of the packages instead of x64, even though (a) the server was x64 and (b) both versions of the package were available. This resulted in yum refusing to do anything because it saw conflicts. I have never had these types of problems with Debian based distros and a day of Googling for answers did not solve it.
I too am mostly a Debian guy but it sounds like your situation has less to do with RPM than it does with a client putting themselves in a crazy situation.
The whole point of getting your OS from RH is that RH has a book that you can do things by and be pretty well assured of the results. When they decided to no longer subscribe to that they really should have switched to a community managed Linux version.
I can't imagine the one time cost of moving their production servers to CentOS would be more than the continual update pains they're experiencing.
I assume so, though the part where yum could not figure out the server's architecture was really odd.
I would love for them to move to CentOS, or Fedora or whatever. The problem is that they are a huge healthcare company, and I am a part time subcontractor.
So you post a German blog post about something you have never done. I now have gone full on salt.
Once again their is nothing wrong with RPM and this anti-RPM stuff needs to just die. Linus uses Fedora and if anyone would flip out if something was bad technology Linus would, but instead people who just heard a cool RPM Dependency Hell still continue this 10+ year old issue over and over again without knowing anything technical about why it was an issue (For a short period of time) and how it was fixed.
A) I know 3 ancient languages and have degrees in them undergrad and grad. Google Translate German is minimally okay at best. The most important aspects of languages are not words but sentence structure. That is lost on Google Translation BUT... what I can see is this guy is just raging about a missing dependency in the repos of a library last built in 2010 (5 years old). NOT AN RPM ISSUE.
2) Oh and who the RPM file format has since devised please ?! What's that supposed to be? If the alien invaders drive you crazy, so they can not exterminate mankind? Holy shit. By contrast, even the Debian stuff is obvious and self-explanatory! And self-documenting all. As a .deb works, one can find out with file and home remedies, you do not even need a hex editor."
C) This guy is clueless he says Gnome handles this better then RPM? What does a Desktop Environment have to do with RPM? Does he equate Gnome with Debian/Ubuntu and thinks Gnome is Deb?
"Does "deltarpm". Say, is that a joke here? Even Rotz Gnome checked before building if its dependencies are fulfilled!"
"First there are RPM directly two strands, RPM and RPM 4 5, and both claim to be the "official" RPM. Lolwut?"
E) Why would anyone need a hex editor for when looking at RPM its plain text?
If you can't find anything on the issue in several languages it isn't an issue. RPM is a stable good technology that people randomly out of what need to put down without knowingly what they are talking about.
Enough said about this stupid blog post:
"My goodness. And I know otherwise perfectly sane people who swear on CentOS!
Update: Maybe I should say, as I so imagine a package management tool. My request would be that always works. Python zerschossen? Perl is not installed? glibc update failed in the middle? The package manager needs to go and can still be saved. And it must be small enough to fit with metadata in 5 MB. Must also without OpenSSL and curl and wget can work, at least in an emergency. Of the systems that I've seen so far, I like best pacman (Arch Linux). But there is something else."
In all fairness, RPM really is a shitty package format [0]. It's a binary format with a lot of different versions, and any tool dealing with RPMs needs to be able to handle all those different versions. Compare that with nearly every other package format: a standard archive file with the package data and metadata stored within. This means that you need specialized tools to deal with RPM packages, whereas packages in other formats can be dealt with using standard archival and compression tools.
The situation could be a lot worse, for sure, but dealing with RPM packages is a pain in the ass compared to practically every other package format (programmatically speaking).
(I say this as the maintainer of a tool that converts RPMs to CRUX packages [1]).
2. Most of the complaints are about RPM's build chain and the bloat included in it. NSS/NSPR: RPM doesn't care about any standard ways of configuring them – nspr-config, pkg-config, LSB default folders, … ) BDB: Needs to be copied into RPM's source tree. RPM doesn't build its python modules (needed by yum etc.) by default. Yum has a hard dependency on sqlitecachec but doesn't declare it. (sqlitecachec is the piece of software from 2010, BTW.)
(No idea whether those are accurate.)
3. The gnome comparison is, again, related to the build system: RPM does not check all build- and runtime dependencies before building, you have to determine them by trial and error.
(No idea whether this is accurate either.)
4. RPM packages are binary, and to inspect them you either need specialized tools or, well, hex editors. (Also seems to be correct.) This is a marked difference from all competing formats, which are plain text. DEB packages are ar(1) archives with some special files, all ASCII text. Same for Pacman packages (which are tars).
5. I don't think his "package manager wishlist" is unreasonable. A statically compiled package manager that works without any external dependencies is desirable, as it e.g. allows cross-installation from other platforms, and makes the system harder to break with botched updates.
6. Another complaint is the dependency bloat: Why use a mixture of XML text databases (repodata) backed by an SQLite cache (yum) and BDB databases (rpm)? (No idea what's an accurate representation.)
Generally, Fefe has been lobbying for less complex, easier to maintain, easier to verify, more resource efficient software for over a decade. His projects – gatling, dietlibc, minit, fgetty … – show it.
Sure down vote BUT defend your opposition to the point of this blog post that I pointed out. It is 100% not RPM issues that this person is talking about.
Okay so by the down votes I guess people prefer to think RPM is bad and won't take anything from anyone pointing out how it works and that the article used was full of holes by someone that doesn't understand package management.
I SAID STUPID: Ye sit is stupid to request a package manager that uses unsecured packages with disabled SSL and curl and wget to download packages and manage them so that any hacker could install any package it wants with a simple script.
"this guy" and "this person" with the "stupid blog post" is Felix von Leitner, for reference. Understand that, and understand things like diet libc, libowfat, and minit, and you will understand some of the bases of M. von Leitner's opinions here.
> Ye sit is stupid to request a package manager that uses unsecured packages with disabled SSL and curl and wget to download packages and manage them so that any hacker could install any package it wants with a simple script.
That was not the demand. The demand was a package manager that works without requiring openssl as a dynamically linked dependency, so the package manager still works if those dependencies are broken or missing (due to e.g. a botched update) and can repair dynamic libraries for the rest of the system.
It's not the oldest. SLS predates slackware (as do a few others iirc)
https://en.wikipedia.org/wiki/Softlanding_Linux_System
Slack was awesome back in the day, but the the philosophy as being "as unix like as possible" prevented it evolving and adding nice things like package managers. Using slackware is a good exercise, but I'd never use it for an application I care about.
If you only need a couple of applications, it's great. We use it for 200+ POS terminals for our ERP/CRM software. It's obscure enough that the end users have no clue how to mess anything up (aside for occasional icon deletion in KDE, but even that needs the "unlock" step).
> the philosophy as being "as unix like as possible" prevented it evolving and adding nice things like package managers
Others have pointed out that the existence of Slackware package management gives the lie to that assertion. It remains to point out that Unices had package managers, so being "Unix like" does not involve eschewing package management at all. XENIX had a package management system, for example. It originated in AT&T System V Release 4, was also present in Solaris, and has been picked up by the Heirloom Project.
This is simply false. Slackware has a package manager. It just does not resolve dependencies. It has also evolved. The Slackware developers have worked on packages such as wicd, which makes networking easy without dependency bloat; other distros reap the benefits of it too.
Wicd is proving difficult for 14.2. I must admit that I prefer network-manager because of the convenience of the modem-manager when using a usb mobile Internet dongle.
I take the general point you are making. I'm an end user of Slackware. I think that anyone who has ever successfully installed Windows on a laptop would cope with a Slackware install fine if they read the docs on the DVD. Slackpkg makes updates reasonably easy.
wicd is pretty much obsoleted outside Slackware because of its atrociously slow development pace. connman beats it by far in terms of "easy networking without bloat", and NetworkManager doesn't have noticeable bloat if you have a desktop environment anyway.
It was my very first one, Slackware 2 with kernel 1.0.9.
I still remember the main feature being announced was the early support for elf format.
Nowadays after a decade of jumping between OSes, I just settled on Windows, for better or worse, it does better what I need for my work (please don't start a flame war on this).
However I do owe a lot to Slackware, as before it my only access to UNIX were expensive Xenix, Aix and DG/UX workstations at the university.
I don't see Windows User as being anything negative, given the pleasure I had in these 30 years developing for it, more than any UNIX platform I used in the same years.
But as I said, I don't want to start a flamewar about OSes and development tools available.
