?

Log in

Elia Pinto (devzero2000) Blog
Recent Entries 
It is too much time that I don't write something. But I found the opportunity when I saw the deterioration that has reached the world of IT labor in Italy. Look at these Troll.

https://www.infojobs.it/roma/sistemista-certificato-rhca/of-i58def3517e4c74bca586e07e2fde42

As you know the RHCA is one of the top, and more difficult, IT certification on Red Hat Linux. If you have this it means to have made ​​a minimum investment of at least 15,000 in training.
And of course this is not enough to pass the exam, it is necessary a considerable personal effort.
By the way certainly if one were to do all this for 900 eur per month he would be a fool al least.

Luckily in Europe and the USA IT professionals are paid like should.

USA :

Staff and Entry-level Positions
http://www.computerworld.com/spring/salary-survey/2011/job_level/3

Middle Management
http://www.computerworld.com/spring/salary-survey/2011/job_level/4

Senior Management
http://www.computerworld.com/spring/salary-survey/2011/job_level/5

Again from USA. In the first post i was wrong, but i forgot that many USA city are named as the their  European Countrepart.

Londra http://www.simplyhired.com/a/salary/search/q-RHCA/l-London%2C+AR
Zurigo http://www.simplyhired.com/a/salary/search/q-RHCA/l-zurich%2C+KS
Berlino http://www.simplyhired.com/a/salary/search/q-RHCA/l-berlin%2C+AR

In Europa i have not found an equivalent of the "It Salary Report". Perhaps for the Italy should be
better to change
in the above "ey"  with "ival" if one want to obtain, this time, a true Italian Record (Thanks to Dario Fazio for this very nice indication posted on Linkedin). Aside, if someone find more info for the Europe i am glad to report here.

I have found only this for the UK
http://www.michaelpage.co.uk/content/15698/salary-survey.html

This is a survey in Germany
http://www.interec.net/salary/servlet/SkyServlet?country=Germany&handler=SalSurvey&horizontal-axis=Company+Size&specialization=Unspecified

I think it look better that in Italy. Or almost of what  those "troll" want offer in their job research. In effect some time ago Assintel published a report on the IT profession , by geographical area and by job http://www.assintel.it/jsp/download.jsp?go=../INDAGINI/Osservatorio2010_volume.zip (requires registration) (for the 2009 period anyway). These data seem more reasonable than they would like to offer the "troll", at least for overcoming the threshold of survival for some IT profession, at least. Recent jobs recruting offered on LinkedIn for RHCA / RHCT seem to confirm my hypothesis. For example this link (http://tinyurl.com/65q85tv) contains the following offer

"U.S. GLOBAL INDUSTRY LEADER REQUIRES SYSTEM & APPLICATIONS ENGINEER IN AMSTERDAM, EU Candidates ONLY, PERMANENT ROLE" That Applicants must have The following are interested;

A Minimum of 5 years experience as a system administrator
Minimum of 5 years experience in installing, configuring, troubleshooting and tuning Java applications
Experience in Shell, Perl, Python or similar scripting languages ​​to automate common tasks.
Experience with LDAP and SSL setup and configuration.
Experience with NFS setup, configuration, and tuning.

What's on Offer
Between base salary of 50.000 to 65.000 Euros
Bonus scheme of up to 7%
20 days Holiday
Collective Healthcare Insurance

Pension Scheme
Training


Not bad at all, isn't it ?

Concluding,  i think that this sorry state It 's a further effect of the well know "bunga bunga", the severe economic crisis of Italy, but perhaps more important the Italian serious moral crisis. And no,  it's not what I will want for my children, ever.

-----------------------------------

This is an update on the 29/07/2013. It is based on the direct translation of the following article published on lineaedp.it, clearly if there are translation errors the fault is only mine (http://www.lineaedp.it/news/4229/ma-quanto-guadagnano-i-professionisti-dellict-2/)


"Summer time and vacation time. For all of us it is time to make a budget to see how far they allow us to get our finances. The same problem also affects the ICT professionals.And if you are wondering how much they earn these professionals, as one might that be, now that we can find a more exhaustive thanks to the 15th Report on Wages in Italy , signed by OD & M Consulting (note from the author: t
he full report can be purchased here http://www.odmconsulting.com/it/store/rapporto-sulle-retribuzioni.html)

The report provides the detailed information on the market and provides a representation of the professions that can help identify trends useful for operators in their business are confronted with the complex mechanisms of supply and demand of labor in domestic markets and external organizations.

It is important to emphasize that the surveys carried out by OD&M in Italian companies held monitored over time the "market value" of a profession and as the market for the same profession is willing to spend. It is not the object of analysis increases applied to a specific person.

The report elaborates 458,584 earnings profiles of private employees (Executives, Managers, Employees and workers) collected in the years 2008-2012, where to wages is a system of earnings-related information: industry and sector of origin, size and turnover of ' company, territorial area, professional work, framing category, age, professional seniority and gender.
Looking at the overall trends, compared with calendar year 2011, it is noted in 2012 an upward trend in wages , with trend higher than those of past years. The situation of slower wage growth began in 2007 seems to get unstuck in 2012 in a diffuse manner for all professional groups.

At regional level, the North West has the highest average compensation value in all professional groups, while the lowest values ​​belong in all cases in the South and the Islands.
If we now focus more closely on ICT professionals, the Report shows that the fund Informatics, electronics and automation brings, relatively to 2012, average annual gross un'RTA of € 109,709 for executives , with a growing trend of 5.3%.

For the middle management the RTA average gross annual 2012 came to € 53,327 , registering a decrease in the negative trend over the previous year, with a - 0.2%.

Employees had registred instead un'RTA record annual average of 28,843 , with an increasing trend of 2.2%.

Finally, the workers (low level employees) in the ICT sector report un'RTA annual average € 23,267 , with a growing trend of 5.9%."

20th-Sep-2010 11:16 pm - RPM5 and RPM live also on launchpad
For those interested I am pleased to announce that rpm5 and rpm in general, now also live on launchpad. Launchpad is a fantastic platform for project management, and allows rpm5 to automatically collect all the problems of rpm, and rpm5, among the different rpm based distributions. It 'also underway a project to draw up a FAQ for rpm5 and rpm in general : this is what it is really  needed for speaking, and forgetting,  about always asked problem that in turn resolved into  something never well understood, or well documented. Many RPM-based distributions, not rpm5 based also, maybe they could find some added value in this initiative of the rpm5 maintainer. But, as always, who can know. 

https://launchpad.net/rpm

https://launchpad.net/~rpm5

I hope this is some interest because here live many of the RPM monks, expert in the package management areas and questions relate to them.
These  are two toy script for finding deps as RPM does on binary package, probably installed manually
by a tarball. The RPM rpmdeps works as the "internal dependency generator" that  RPM introduced from 4.2.X version, mostly because  the multiarch functionality, introduced by Jeff Johnson, required this implementation. Perhaps could be useful if your commercial package go without a RPM and you want to know what dependency - shared libs in first place - this program requires.

Hint : the best things is to create a binary rpm of these tarball.


rpm-find-deps.sh
  
################## CUT HERE ######################
#!/bin/bash
#
##########################################################
#  Enumerates package  dependencies  for  the  set  of  file
#  on the directory argument
#
#  rpm-find-deps.sh <RPM_BUILD_ROOT directory>
#
#  Copyright (C) 2006 Elia Pinto
#
#  This program is free software; you can redistribute it and/or modify
#  it under the terms of the GNU General Public License as published by
#  The Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.
#
#  This program is distributed in the hope that it will be useful,
#  but WITHOUT ANY WARRANTY; without even the implied warranty of
#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#  GNU General Public License for more details.
#
##########################################################
Usage() {
   echo "${_PROGNAME}: Error: usage : ${_PROGNAME} [-R|-P] <RPM_BUILD_ROOT dir>" >&2
   exit 1
}
readonly _PROGNAME=${0##*/}
[ $# -ne 2 ] &&  Usage
while getopts "RP" opt; do
        case "$opt" in
        R)    _type_dep="-R" ; break;;
        P)    _type_dep="-P" ; break;;
        *)      Usage;;
        \?)     Usage;;
        esac
done
shift $(($OPTIND - 1))
[ $# -ne 1 ] && Usage
[ ! -d "$1" ] && { echo "${_PROGNAME}: Error: $1 not found or not a directory" >&2 ; exit 1 ; }
[ ! -x /usr/lib/rpm/rpmdeps ] && { echo "${_PROGNAME}: Error: /usr/lib/rpm/rpmdeps not found" >&2 ; exit 1 ; }
for _f in $(/usr/bin/find "$1" ! -name "*.debug" -type f )
do
_risdep=$(/usr/lib/rpm/rpmdeps ${_type_dep} <<EOF
${_f}
EOF)
#[ -n "${_risdep}" ] && { echo -e "${_f}\n${_type_dep}\t:"  ; echo -e "${_risdep}" ; }
[ -n "${_risdep}" ] && { echo -e "${_risdep}" ; }
done


This one instead find, via yum, the package name that "Provides", in RPM term, the "capability" - again an RPM term for indicate a virtual Requires/Provides e.g. a dependency, the "dependency" that
the previous script have found.





pkgdeps.sh

##########################CUT HERE ######################################
#!/bin/bash
PROGRAM=${0##*/}
[ ! -f "$1" ] && { echo "$PROGRAM: Usage: $PROGRAM filedeps" >&2 ; exit 1 ; }
while read _F
do
repoquery --whatprovides "${_F}"
done < "$1"

#########################CUT HERE##########################################


This is a repost of a blog entry by Jeff Johnson, actual leading Mantainer of rpm5.org, about RPM, the RPM Package Manager. Most of the issue discussed are relevant, in my opinion, also in this days.
But, unfortunately, the site on which it was issued is no longer accessible. Every inaccuracy or omission is of course my fault.

A reply to Claudio Matsuoka’s clueless advocacy at

top-ten-problems-in-rpm


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.

Blaming Berkeley DB for rpm performance problems is like blaming Iraq for Bush.

Berkeley DB is one of the highest performing, widely deployed, “best-of-breed” database implementations in the world. Period. Not only RPM uses Berkeley DB: perl, python, sendmail, subversion, and many many other projects have chosen Berkeley DB. All of those applications are not mis-guided, or they all would have chosen flat file databases, like apt and dpkg have chosen to do.

Claiming dpkg is faster without any attempt at measurement is akin to asking one to believe Rumsfield’s lies.

Flat files have their uses, but the goal in RPM of using Berkeley DB (or any DB) is performance, not otherwise. No flat file implementation will beat hashing and b-tree indices for the same content retrieval in any but trivial cases. Human readable is only necessary when humans need to edit files to “fix” something, which is perhaps at odds with the claim of uncorrupted reliability of dpkg and apt flat files.

Next time try adding –stats to any rpm command and study the numbers a bit. Try to come up with a comparable operation with dpkg/apt before baldly spreading FUD about Berkeley DB thickly and clumsily.

The sqlite3 database backend was added because Berkeley DB licensing prevents certain vendor(s)from distributing RPM, and because other cross-platform vendor(s) wished not to spend time implementing locking schemes on odd-ball embedded architectures. So the sqlite3 implementation is there to satisfy RPM customer requests. Perhaps satisfying customer requests is not as important a goal for dpkg and apt as it is for RPM.

I will happily use the highest performing implementation in rpm, whether that is flat files, Berkeley DB, sqlite3, whatever. At the moment, Berkeley DB is the highest performing database implementation I am aware of.

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.

Installation before removal is absolutely necessary to insure that the window where shared libraries are not available is minimized. Removal of library symlinks before reinstalling will affect all programs that are started while the upgrade is in process. That is a requirement for upgrading software on live production machines.

Perhaps dpkg and apt do not run as often as RPM does in “production” environments, where the size of the window where a soname is unavailable determines whether upgrades can be attempted on live systems. Large upgrades with remove-before-install can/will cause programs executed during the upgrade to fail randomly, and lare installs will ibncrease the probability of random failures.

Confusing the use with the concept of triggers in order to argue that triggers should not exist is silly at best. In the real world of already released packages — some with flaws — triggers are necessary to retrofit fixes for packages that cannot otherwise be changed.
Sure Debian packaging policy is better at preventing packaging flaws that must be corrected by use of triggers. OTOH, RPM based distros are released far more often than Debian is released, and packaging mistakes are a fact of life for all distros.
Naive intuitions are often wrong. Catering to intuition rather than reality is, well, wrong.

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.

There is nothing whatsoever forcing anyone to use rpm networking capabilities to download and/or install packages. Size and complexity are bogus metrics, socket programming has been around since the early 1980’s, and certainly isn’t hard or complex.

RPM has had a FTP client (one of the first in a linux tool, nice and small) since 1997. RPM was also one of the first HTTP 1.1 clients in linux in RHL 5.2. Users expect features in RPM to be maintained.

All distro vendors were warned that rpm-4.4.1 was going to have a default key retrieval enabled. A posting describing how to disable was sent to <rpm-devel@lists.dulug.duke.edu>. The goal is/was to increase security by always checking signed package contents, that can only be done (imho) by automating pubkey retrieval (or otherwise installing keys beforehand). Stronger package integrity checks increase the reliability of package management.

So the pubkey retrieval from key server facility is C-O-N-F-I-G-U-R-A-B-L-E, and not attempted if/when pubkeys are properly imported locally.

4 - Obtuse macro expansion and comment handling in specfiles. Macros expand inside comments, and line breaks cause unexpected behavior.

All macro languages exhibit context peculier behavior to some degree. For one example, m4 macros expand where found, and require dnl as a m4 specific comment lead in. The expansion of $Foo$ rcs/cvs strings is another example that can/will cause damage to the file that contains the $Foo$ token, depending on what multiline construction is needed for the file. Is the difference between use of “#” and “dnl” comments in m4 any different than the need to add a 2nd ‘%’ character to prevent rpm macro expansion in comments?

Furthermore, the simple rule

Macros expand everywhere they are found.

is a brutally efficient solution to the lack of a well defined enumeration of all possible contexts in which macros can expand. Without identifying all expansion contexts, other rules are doomed to fail someone’s expectations.

5 - Absence of logical OR in requirements forces the developer to always regenerate all alternative packages to provide virtual packages.

I see no basis for the claim that developers are forced to regenerate all alternative packages. A matching Provides: to satisfy a Requires: can be added to any virtual package, and additional Requires: (or other dependencies) can be added to the virtual package to insure that the semantic intent is preserved.

RPM has alternation of Provides: rather than Requires:. This is very well known, and has been thoroughly discussed on (at least) the LSB packaging mailing list several years ago.

Without a concrete and specific example of a flaw, I cannot respond further.

6 - Incomplete timestamp format in specfile changelogs. Standard date(1) format or other providing time of change is needed.

Yes, quite annoying. However, a fix introduces instant legacy incompatibility in any spec file that attempts to use the fix, and that problem is insoluble without forcing users to upgrade their version of rpm.

The timestamp syntax has been consistently broken since 1997. Is it *really* that hard to edit date(1) output in a spec file %changelog?
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.

RPM computes a “contains” relationship to map all — package, soname, file, foo(bar), … — dependency tokens to the package that resolves the dependency. The cost of the mapping is quite modest using any standard technique (rpm uses bsearch because of portability) to associate a key with a value. Add –stats to any rpm command to measure the overhead for your specific benchmark.

The only “special way” that file dependencies are different than, say, package name dependencies, is that dependency tokens that start with ‘/’ are resolved using file paths rather than provided dependency arrays. The file paths also have a different index than other provided tokens that needs to be addressed by depsolvers using rpmlib.
The additional complexity introduced by the mapping from dependency token to package has immediate benefits in permitting simpler automation for extracting dependencies, and more precise specification of the dependency context, e.g. a dependency is needed to, say, run a script interpreter during install.
If anything, package managers need more, not fewer, contextual hints like ‘/’ (and the quite similar foo(bar) namespace markers) in order to more precisely identify the resolution context, and (incidentally) to assist packagers and applications with hints why the dependency is necessary. Increasingly, probe dependencies attached to syntactical sugar like “rpmlib(foo)” are going to be needed to detect intrinsically run-time conditions like “This system has booted with selinux enabled and nptl disabled.”
OTOH, the mapping of dependency tokens — including file paths — could be done when the package was built in order to only include package name dependencies in the package being built, and the world of rpm packaging would not change a bit. There has been no reason to attempt build time mapping, perhaps I shall add to rpm so that I do not have to listen to the droning mechanical noises of the Debian Borg regarding the use of file dependencies in RPM ever again.
I see no basis for your claim that file dependencies lead to “sloppy … packaging”. In fact, automating dependency extraction with rule based scripting using non-package-name dependency tokens leads to better, not sloppier, packaging, as human packagers often make mistakes that are harder to detect and correct than a faulty rule based script.
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).

Last I checked tar/cpio have exactly the same problem as rpm unpacking a symlink path onto a directory. Perhaps current versions of tar/cpio have “fixed” the behavior.

FWIW, rpm-4.0 in RHL 7.0 had a means to replace directories with a symlink. The implemention was scrapped because of a clunky, hardwired syntax for the functionality that did not permit testing exceptional conditions, like ENOSPC or EIO on a system call. Recent rpm has embedded lua, and a pre-everything scriptlet, which permits symlinks to replace directories in *.rpm packaging, but perhaps the implementation is not sufficiently transparent for your tastes.


9 - Non-intuitive (or plain broken) algorithm to compare package versions (example: 1a > 1B) . Epoch zero is considered newer than no epoch at all.


The rpmvercmp algorithm is not broken because the comparison is well defined, has the
properties needed for package management, and is widely and usefully deployed.

Whether the algorithm is intuitive is entirely in the eye of the beholder.
The “1a > 1B” comparison is due to strcmp(3) from glibc. Blaming rpm for glibc behavior is like blaming the atomic bomb for the cold war. Certainly internationalization has led to some surprising and unexpected behavior from all unix utilities.
Comparisons between 0 and undefined (because missing) epoch need to be defined somehow. The number of packages that choose to add Epoch: 0 explicitly used to be vanishingly small until Fedora pedants decided to change the world by demanding (wrongly!) that Epoch: 0 be added to all packages.
There are other well known non-intuitive flaws in rpmvercmp like

a) 1.0000000000000000002 > 1.1 (because 2 > 1 in the segmented digit string compare)
b) 1_1 = 1.1 (because all non-alphabetic, non-numeric, characters are treated equivalently)

and there are further problems with mixed mode comparisons between alpha and digit strings,
that are perhaps more likely to be encountered than the examples that you give.

The rpmvercmp algorithm is not ever going to change, the release engineering necessary to deploy a change to version comparison in RPM is cost prohibitive because of the gazillions of *.rpm packages that have been built successfully over the years.
But yes, the rpmvercmp comparison is quite unpleasant from an intellectual POV, and just happens to “work” sufficiently well for package management purposes.

10 - No provisions for interactive configuration scripts or human inspection/approval of new configuration files, and no concept of post-transaction configuration.

Configuration management is unrelated to package management. Batch mode unattended installs
were a primary design goal of rpm that has proven successful and popular. You might as well
fault emacs for not behaving like vi.

This entry was posted on Sunday, July 3rd, 2005 at 10:56 pm and is filed under rpm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

2 Responses to “Reply: “Top 10 Problems with RPM””

  1. temporary title » Blog Archive » Jeff’s reply to RPM problems Says:
    July 4th, 2005 at 12:18 pm

    […] If you read my previous “Top Ten Problems in RPM” post you should also check the maintainer’s take on it. Some interesting explanations that are worth your attention. […]
  2. Vault » Blog Archive » Desktop Linux Debate Says:
    January 10th, 2006 at 4:11 pm

    […] sign decisions. A technically solid (if less then totally coherent) rebuttal can be found here. The whole DKPG/RPM debate is one of the quickest ways to spot a Linux zealot. Technically speaking RPM i […]

 



This page was loaded Feb 20th 2017, 10:47 am GMT.