Slashdot Mirror
Binary Package Formats Compared
jjaimon writes "There is a document on different package formats used in Linux/Unix systems. Worth reading." Another reader sends in this guide to creating Debian packages which seems apropos here.
← Back to Stories (view on slashdot.org)
Why don't you just ask what everyone's favourite distro is?
Apt-get, no emerge, no make world, ARRRGH!
...considered a gross misfeature? Count me in.
No matter how many "packages" I see. Still love slack-packs the best.
Come with everything you need, esp created to make you learn what the hell your doing before you do it.
argan0n
It seems to me, if you want to cover everything, you would put a debian package inside a RPM.
Why? I have no clue, but you could if you wanted all the features. Kind of like putting a roll bar into a SUV, so that you can start amature racing.
=================
Unix is very user friendly, it's just picky about who its friends are.
It is silly for us to ignore such a large divide in our community though. It exists, therefore we should look at it in depth so we can improve it and better the community as a whole. We shouldn't set off a battle cry for the entire community to come together if that's not really what's going to happen, at least not in the reality that i see. but then again my personal reality distortion field is out of whack this week.
The distroes are quite divided. How 'bout we look at what is specific to each distro so people can chose which is best for them. That is a better way to garner support from the outside community, doncha think? Don't leave them in the dark, that's what scares people away from Linux.
First time I've ever seen guys compare packages and size doesn't seem to matter.
Not compared: my favorite package
* Please do not read my signature.
While at first glance it seems heavily slanted towards Debian's .deb packages (Its first and contains more "YES"'s than the competition), as a developer I'd be far more concerned with basics like "market penetration" than whether it allows me to assign my package a "priority" over other packages.
I suppose it might be of use to folks building their own distribution, but I expect thats a pretty short list.
But personally, I tend to grab the source when I'm adding something that RedHat didn't include (or seems woefully out of date)
You are in a maze of twisted little posts, all alike.
I'm sure this will erupt into a huge flamewar like the last time it was posted when all it boils down to is that it doesn't really matter much to end users about the package format as long as the installation and upgrades are made easy. For me, aptitude/apt with .deb packages has proven easiest, but a lot of people like apt with RPM or RedCarpet or rpmfind or whatever else is out there. Lindows users use the 'one-click' install thing not even caring that there are .deb's behind the scene.
Part of the reason, I think that the deb format has always seemed to hold together really well is that most all of teh deb using distributions are so tightly integrated with the main debian distribution that packages are always totoally interchangeable (and are very good to notify you when they will not work.)
RPM on the other hand is adopted by many different and sligtly incompatible distributions that often finding the libraries and applications you want to install is difficult not because RPM's are hard to find but because RPM's that work in your current setup are hard to find.
This is simply why the management tool(s) on both ends (creating packages and maintaining installed packages) matter way more than the package formats themselves. Deb's are very compicated but sometimes easier to deal with because of all the good debhelper tools. RPM's are most often more 'hand-crafted', but they are a lot easier to create from scratch for many people.
The thing I really hate about deb's is the lack of signature verification. It's absolutely central to the development/upload/build process but until very recent efforts has been a total pain to use on the installation front. There is no good reason for this either.
~GoRK
There are different levels of package management which often confuses the newcomer into believing (dogmatically) that one is better than the other.
The installable packages themselves have to have flexible dependency markings and coherent version markings. The low-level package tool has to be able to install and uninstall packages cleanly and repeatably. Seems like the dpkg/deb suite and the rpm suite are quite comparable here.
The package manager has to be able to build a requirements tree for a desired package, and then fetch all of the required packages to fulfill those dependencies on the local system. It should offer trust or signature verification to ensure only trusted repositories and trusted packages are used. The apt tool seems to be cross-platform, while non-Debian distros often spin their own service model here: up2date, Red Carpet, and whatever Mandrake and Lindows offer are each commercialized with some amount of sample access.
Lastly, the most important criteria, is the repository itself: it should contain packages which are clean and trustworthy. There have been cracking incidents, and there will be more. The quality of code between distro-produced packages and externally-produced packages can be as different as night and day. The package's meta-data and manifesting information can be crap, or it can be carefully constructed. The embedded installation scripts can be trivially exploitable or they can be carefully scrutinized against unexpected results.
Even if your package format is cool, and your package manager is cool, consider the repository. If the repository is not secure and offers poorly tested packages, many folks are going to unfairly blame it on the tools.
[
Are you smoking crack?
Having a compiler available on all of your systems to compile C code is far greater risk than the "threat" of getting trojaned builds from Red Hat.
Take your tinfoil hat off and breathe.
Conformity is the jailer of freedom and enemy of growth. -JFK
It will be so good all the other packages will run and hide!
You are in a maze of twisted little posts, all alike.
I love Gentoo, but I can entirely understand someone not wanting to spend 18 hours compiling OO.org or KDE. Or even half an hour getting Moz-Frirebird. All I know about the Gentoo reference binaries is that they exist. But they weren't covered and since they seem to be the (distant) second choice for the Gentoo devs, I doubt it is as easy to use as portage.
Because all those optimizations don't mean squat when most computers are not maxing the CPU on a regular basis anyway. Also, portage is not a silver bullet. While it's got a very good system for handling a whole lot of things (especially cool stuff like being able to peg versions or inject versions if you want to roll something by hand), it's not nearly complete. Look at the lame way it handles config issues by just post-poning that to etc-update, which isn't remotely user friendly, imho.
I do not have a signature
Gentoo is bad for the environment, since a computer uses more power when the processor is at work.
:-)
This means that using Gentoo is aggravating our problems with long-term storage of nuclear waste as well as introducing fossile carbon dioxide into the atmosphere.
Additionally, source code is generally larger than the equivalent binaries, so it is a waste of bandwidth to download Gentoo, which also is a waste of energy in the long run.
So, for the sake of our children, from whom we borrow the earth, use Debian GNU/Linux.
Click here
8 J: www.kitenet.net/~joey/pkg-comp/+&hl=en&start=1&ie= UTF-8
>> or for those with text browsers or aol
http://216.239.37.104/search?q=cache:x0Hrwxt537
Have a nice day
The site appears to have been slashdotted. Can anybody provide mirrors or summaries?
;)
Just like every other Slashdot reader, I'd like to read the article before I post a comment
This space left intentionally blank.
Joey Hess created that document (at least the first revision) around 1998 IIRC, so it's not so much new news (guessing it's been posted here before, but probably around then as well)
What Linux really needs is a dir-independent application running /usr/bin to /usr/local/bin). Most packages, including g++, configure
system. Imagine a package of...oh, say, g++, where g++ runs properly
even if you move the whole g++ package to a different dir (say from
themselves to run in one location, and they'll get confused if you
move 'em.
Some packages (eg Tomcat) let you move them and they'll still
work...but only if you set an environment variable (eg TOMCAT_HOME)
so that Tomcat now knows where it lives. In a proper environment, an
application could easily & consistently know where it currently
resides on the filesystem *cough* OSX *cough*.
What Linux needs is some standard 'run-app' script that would inform
a package of its location. For instance:
% run-app tomcat
Run-app would be simple, say, the following:
#!/bin/sh -f
$app = shift
$location = `which $app`
env {$app}_home = $location $location/bin/app
That would enable Linux to devise a package format (or better yet,
improve rpm, deb, etc) for more flexible package management.
A package would no longer need to place its binary, libraries,
manpages, etc. all in hardwired locations in the OS...it could just
leave them in its original dir. (or maybe create a 'obj' dir that you
can remove if you wish to clean up the package.)
Practice Kind Randomness and Beautiful Acts of Nonsense.
Believe it or not, like (essentially) all things, binary packages have a purpose, just as source packages have a purpose--platform agnostism.
Before giving me an explanation as to why you (read, the parent poster) in particular would not have a use for binary packages, allow me to explain why binary packages are useful. In the majority of instances, binary packages are useful when one is installing the userland on a system, or when installing a compiler, when you have no other systems to build the compiler on. Binary packages are also handy for systems where compiling from source would be inconvenient, resource-intensive, and time consuming.
Also, there are some proprietary applications that are not available as source, so a logical manner of packaging is with a standard binary packaging system such as RPM or dpkg.
Even NetBSD has its own binary package format (no, not the sets, those are for the base install and are just tarballs without package information).
All in all, binary packages are very convenient, despite the inconveniences caused by vendors who do a poor job of managing their package collection and dependencies. Binary packages are single files, smaller than source archives in most instances, and are installable in a uniform manner.
Let's not get into rogue "package vendors" who package trojans. They are the minority, and most reputable software developers release their own binary packages along with sources anyways.
I think I need a glass of water.
-
And the Angel said unto me, "These are the cries of the carrots! The cries of the carrots!"
Because there are folks that I do trust. I don't trust the latest nightly build of Mozilla, but I do trust the most recent stable release after it's been out a week or so.
You see, I know there are folks out there like you... so I don't have to be like you too. Enough hobiests and security folks will bang on popular newly released code to pacify my concerns. For specialty apps coming from unknown sources, care is taken and sourcecode reviewed. But, for code from the likeness of a major OS distributor (RedHat, Debian, etc) or a major code project (Moz, Apache, etc), I don't have to bother.
I want it fast and pain - free. Binaries please.
Support a few technologists in Washington.
Instead of drawing attention to our differences we should be emphasizing what we have in common.
Yeah!
Cause since when has using direct comparisons for determining
the best method for a process worked for anyone?
"You worthless post!"
-Shakespeare, 2 Gentlemen of Verona, 1. 1. 147
If your paranoid enough not to trust the RPM Builders, the checksums, the download process, etc, then download the src.rpm; unpack the contents, and do your vodoo tricks. Then run rpmbuild to build your own damned binary package. I've done it (Ok, I'm a RHCE) and its cake.
Basically, this isn't a reason to dis binary packages unless your paranoia is well into the tinfoil hat level.
You are in a maze of twisted little posts, all alike.
The list does not analyze autopackage. Despite it's really recent, it has some interesting features, and as far as i tried it works really well.
-- "If A equals success, then the formula is A=X+Y+Z. X is work. Y is play. Z is keep your mouth shut." - Einstein
Are you smoking crack?
Apparently not as much crack as the moderators. Score 4, Informative for strtok as a security risk? Give me a break.
Your credit card information wants to be free.
One of the main reasons I enjoy DEB binary packages which also do not have any of the bad issues you mention is this:
.deb from that, not just to install on that machine (Personally I like the fact i can remove it with a package manager) but i can also install that binary package I made myself on my slower systems that dont have a compiler installed.
I'll download the source and compile it on my nice fast zippy P4 2.6ghz machine, then build a
My three router computers are all p133 or p166 machines. No way am I compiling anything there. Routers also dont need gcc installed.
I run my own private apt repository for this (Its just apache and some config files in text format, and one more line in my apt sources file.)
This way I can tell whichever machines to apt-get it, and later I can apt-get remove it as well.
I also dont have a huge server farm, I just have 8 machines at home for different purposes. Below the P4 mentioned above, my next fastest system is a p2 450. The others get way slower below that (p2 200 and the like, or worse.)
I also dont want a compiler on any system but my development system. The machines in my DMZ dont need compilers, as if they do happen to get rooted, that's one less tool for them to use aginst me.
Open source is also about choice. Please let us have ours, even if you have made your own.
Security is always a tradeoff between the effort required and the risk entailed. SSH is more secure than telnet. Even more secure is making all of your employees carry around OTP calculators, but most places don't do this because for them, it's not worth the effort. At a certain point, the "price/performance" tradeoff curve of security starts to get very steep in the direction of "price", and the only way to get 100% security is to have 0% usability (as often noted by the example of unplugging the computer and encasing it in concrete).
So, how much do you need to trust your packages? Do you have enough work and not enough top-secret data that you can trust the package maintainer, the upstream maintainer, and your copy of MD5? For most people, the answer is "yes". This does not apply to X Random Freshmeat App; if you're downloading a new program and installing it yourself, you should check it out first (if you have the means), since sometimes even good authors do things that are unintentionally destructive. But most people can afford to trust that a package which has been around for a while and comes from a reputable distributor is reasonably safe, especially if they're doing the work of 3 people, maintaining 5 platforms, and just trying to keep up.
Unless you're in a situation where many people want your very important data, you can usually afford at least a little well-placed trust. Otherwise, just keeping up with updates is going to consume an inordinate amount of your time, and the rest of your duties will suffer.
WMBC freeform/independent online radio.
Best thing about RPMs? GPG signatures built in. Try rpm -K whatever-x.x.x.rpm next time. Second best thing? rpm -Va.
Get your own free personal location tracker
For starts, having access to the source doesn't guarantee anything, since your compiler itself may be hacked. (There are a couple papers on this iirc, Google is your friend.)
Second, there is the simple case of ease. It is a serious pain in the ass to check each and every program installed on a modern desktop OS. It is so much easier to just click on an app in Red Carpet, wait for it (and dependencies) to download and install, and then get on with doing real work. I don't have the time nor the inclination to spend hours and hours scouring source.
If was running a server used to control nuclear reactors, sure, I'd want a little more security. Sitting at my desk doing web development or playing Quake, who the hell cares?
Because some people have older machines that take several days to compile large subsystems such as Gnome and KDE?
Because some people run dozens or hundreds of machine with identical configurations, so compiling the same package on every single machine is pointless?
Because companies prefer working against a known build of a piece of software for support reasons?
Source distributions are far from a panacea.
I use binaries because it is simple and straight forward. It is fine for 90% of all my package installs to be of this variety at this point.
I use source packages when I need to make something fit in the system, even if it means hacing code.
Generally, only if a program is of critical importance, or I am curious do I ever bother source browsing. I am not lazy, just practical. I have real work to do, and wasting my time being -anally- paranoid about legitimate distribution channels doesn't help me do my job.
Bye!
Definitely one of the features which makes Linux a powerful OS. A good and well-configured packaging system can be a blessing, automagically resolving dependancies or at least telling you where and how things will fuck up. The problem with package managers is that there are quite a few of them around. Normally, diversity would be a good thing but those package managers don't seem too willing to process eachother's packages...
For example, RPM packages are almost common these days; most open source software has a few packages ready to be implemented. Pretty much the same thing with Debian packages, because of the large userbase. Chances are that a few hours after the release of a major product someone has made a .deb somewhere, ready for you to install. However, if you'd look beyond these two packaging systems, you'd get a few nasty surprises...
The TGZ packaging scheme (also mentioned in the article, along with RPM and DEB) just... Well... Sucks. Or at least in Slackware, I don't know if any other distributions use it differently but lets use Slackware's TGZ system as an example for now. What's wrong with it, you ask? First of all (and possible the foremost reason) it's almost unused. Apart from the Slackware packages itself, I've never seen anyone distribute something in the TGZ format which worked. That excludes the few things which I found and simply refused to install. It doesn't do dependancy checking, conflict-checking, heck, it doesn't do anything or so it seems. I'd continue but ranting about the bad parts of Slackware isn't the issue at hand.
The issue at hand are the two remaining package systems, which might be technically sound and quite useable, but they still won't have allot of use. Who here has ever heard of SLP and PKG packages? And even then, who here knows of any major applications which distribute their software using those package systems? Sure, SLP and PKG might be a dream to use, but without any actual packages to install, they're (possibly sadly?) not really of any value.
Which brings us back to RPM and DEB, apparently two of the most common systems, courtesy of Red Hat and Debian. Looking at the list of summed up data, it's really not a miracle those two are more common: Both support mostly options listed, both are backed by a large amount of users/developers and both are relatively easy to use, yet still distinct. Perhaps a system which allows multiple systems to cooperate (regarding dependancies and conflicts and the like) would be a nice compliment to both RPM and DEB?
Hate me!
The binary distributions usually come with a way to compile your own binary packages if you wish to inspect the source code. Just download the source RPMs or use "apt-get source". The "binary distributions" are generally binary and source distributions where you can choose whether you use prepackaged binaries or compile your own.
Um.
./configure script connects to a remote server giving it a shell. Running ./configure as root makes this potentially even more destructive. The ./configure script is the last you audit for security holes, no?
Yes, and it is completely impossible for users to (gasp) compile their trojans elsewhere and FTP them over?
Also, are you saying that you're compiling your stuff as root? Bad idea, since compiling software does not require root priviledges. A better idea is to compile your software as a user, and then "make install" as root through sudo.
There have been cases in the past in which open source software source code has been backdoored, so that running the
Sure, you could argue that "make install" is backdoored, but it's always a good idea to check exactly what scripts you're running through "make install" anyway, since that's done as root.
Run as little as possible as root, and don't fool yourself that chmodding user-space programs not requiring root privileges is somehow improving your security.
All of these formats could be done better. The OpenPackages project had a design project underway to consider the features of an ideal, multi- platform package format early last year but it seems to have died from lack of input. It'd be great to see it get a breath of new life. If nothing else, this article could serve as a starting point for what we do and don't like about current formats.
On the other hand, many of the backdoors I've seen recently have been incorporated into the Makefile. If you get a binary distro, you're completely safe. Yes, reading every line of code would be nice, but let's try to be realistic here. A malicious programmer could just put an off-by-one error in somewhere to leave themselves a backdoor. To get things back on topic, where are comparisons to .tardist or to encaps?
No matter how many "packages" I see. Still love slack-packs the best
Exactly how many of these "packages" do you see in a day?
And of all of them, you like the slacked ones?
are better than packages because you get more control over what is installed onto your file system. If you really want to the slight advantage that package formats provide over ports, use SRPMS. You will have some of the customizability of using ports and all the features that RPMs provide.
I'm primarily a Mac user here, but can someone please explain to me why the Linux equivilent of InstallShield(or VISE, or anything else like that) hasn't been created yet? While it isn't the best solution when you want to deal with versioning, dependancies, and top-notch security, it still seems silly that such a program isn't around, when it's obvious that most everbody that isn't tech-head wants such a program. Is there really such an evil reason that people can't have simple, easy to use installers on Linux?
It isn't necessary for 100% of users to look at the code in order to test its safety. If only 10% or 1% of the community do, then it's still better than closed-source. The rest of us just have to listen to the gurus. After all, you don't expect 100% of users to write their own code do you?
cat * >> sig
Every time I've bought a car I bring a socket wrench set with me and tear apart the engine right there on the dealership floor. If I didn't how could I know that Al Queda hasn't set me up to be a pawn!?! Not checking your equipment like this is tantamount to supporting terrorists.
Read here to find out why:
Delay is preferable to error. (Thomas Jefferson)
You have got to be kidding. Do you think everyone who uses Linux has the time to do that for every package they install? When I installed Debian, I wanted X. I typed 'apt-get install x-window-system'. The following download and install of all the required packages took about a half hour (over dsl). Your way would have taken me about 2 hours to get all the right packages, and another couple days to compile them from source (after of course checking for security vulnerabilities and fixing them myself).
Not everyone who uses a computer is a programmer. Not everyone who is a programmer is paranoid enough to think that a binary package from RedHat contains a secret connect() to send out their passwd files. Not everyone who IS a programmer, and who IS that paranoid, has the time to audit the code of every package they install.
For these people, binary packages are quite convenient and useful.
While I understand your logic, there's a HUGE hole in your reasoning (besides the ones already commented upon.)
:o) and binary packages save me a TON of time and effort - the result of which makes my boxes more secure than compiling from source.
Binary packages are a great boon to any sysadmin that manages more than one box..
I admin a few dozen Linux boxes (all slackware
For example, not too long ago I updated Squid (due to a security hole), which was running on 20 or so of my servers.. can you imagine HOW MUCH TIME it would take to compile from source for EACH one (considering they are Pentium 1's)? And that I'd have to have a working dev environment on each one!
Instead, I compile the software on an offline server, and check to make sure it works (another imporant step - Squid changed it's config file between versions, so I had to modify the config file).. then turn it into a package, which gets scp'ed to each of the servers, and installed.
Package management allows me to keep track of each file, so upgrades are painless.. and if one of the servers goes down, I can have a new one up and running in 20 minutes, using the same packages I used to upgrade the other systems.
By using binary packages in this way, my systems are MORE secure, because I'm able to minimize the window of vulnerability, and because I don't have to maintain extra software on the boxes (from a security standpoint, anything you don't need should be removed - on a production server, this would include a compiler.)
Remember - not every binary package is untrusted. The ones you make yourself are as trustworthy as the source you used to create them.
Similarly, I could install a Debian binary package if that were all that existed for my particular environment, with a simple
(I digress, simple may be relative)
On the other hand, since RPMs have a special binary header, the lazy would be forced to install RPM and Berkeley DB on non-Red Hat-machines in order to build an RPM package. Though it is possible to extract the gzip'ed+cpio'ed data in an RPM without using rpm.
So, in my view, Debian has a bit of an upper hand in simplicity, from a technical standpoint, but not by much.
-
And the Angel said unto me, "These are the cries of the carrots! The cries of the carrots!"
However, it is reasonable to expect several hundred packages to be in place on a moderately loaded machine. I get paid to admin linux, but even i have better things to do than sit and go over all the packages with even grep. On 9 different distributions. across 30+ machines. And it's not like i have a large installation to deal with.
If you're downloading source, you should be downloading gpg signatures and checking them. I'm downloading binaries, and checking the signatures against those. It comes back to trust, then, in the way pki and pgp meant trust to be: do you trust the source of this tarball? do you trust the person who signed it to not be naughty? If so, go nuts.
If you have the time and patience to go through every piece of software, every perl module, evey little whatever that goes into your machine, more power to you.
But I think your attitude undermines the idea that open source programmers participate in the community for the peer prestige and bragging rights. Where do your bragging rights go if your stuff's been trojaned? if you can't be bothered to gpg your stuff? Someone's going to clamp onto the security idea and say "well, you really can't trust those Open Source guys; they're all just out to trojan your machines and hijack your network, so you should buy windows".
You have to have some kind of package management in a production environment. Being able to tell with one query what version of a package is installed on a machine is very useful (rpm -qi)...knowing what all the files are that the package installed is more than useful (rpm -qf). Having shit all over your machine that you installed by hand, in some random directory scheme that makes sense to you is great. FOR YOUR HOME MACHINE. But if i get your job and find that box, i'm reformatting and badmouthing you to your mom.
--mandi
that's fucking nonsense. I hope your trolling, not seriously implying that discussing differences in packaging formats is somehow wrong or divisive.
shit. I have been trolled.
of course, we are assuming that you follow a good security practice and have a BUILD machine to compile, before deploying to your 'secure' servers with no compiler
*shower*
Is that the rpmlib API is almost completely undocumented. As GoRK pointed out, management tools such as apt, rpmfind, up2date, etc. are far more important than the underlying package format.
But it's very difficult to create those management tools for RPM when the API is a "black art" known only to a few. Questions on the RPM mailing list/newsgroup will generally be met with the advice to "use the source, Luke"--all several hundred thousand lines of it!
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
Stupidly designed functions don't lose data centers. Sloppy programmers lose data centers!
It doesn't insert null pointers between the fields, it inserts null terminators, '\0'. If you're treating a char as a pointer, that's a big problem in itself.
Understand the function before using it. If you do not understand how to use the function, you shouldn't.
If you want to bash functions, bash people using strcpy() etc instead of strncpy().
What's next, you complaining that the C language allows you to do stuff without error checking? Get over it. If you want some kind of security net against buffer overflows and strack-smashing, use Java or something.
Loki Setup is now maintained by icculus.org. However, I think that any good package scheme (read: RPM, DEB, Portage, or whatever) is better than this if the administrative tools are good.
http://freshmeat.net/search/?q=installshieldp ://freshmeat.net/search/?q=installer
htt
Everyone and their brother is probably writing an installer (although more people are apparently writing MP3 jukeboxes, Web image galleries, and CMSs. Trust me.) Can't say I'm seeing a "clear winner" though, which is also the case with apt front-ends.
WMBC freeform/independent online radio.
Obviously, for large software packages, you probably don't have time to read every last line of code.
That is the understatement of the year. I would dare say that in order to read and understand a program that is on the order of five million lines, it could take you a year or two. For a non-expert programmer (or even an expert with no operating systems experience) it could take forever to just begin to understand something like the Linux kernel source.
But what I generally do is untar the source and then grep through it for suspicious things.
That's great if you know what you are an expert programmer (and if you think that a simple grep will help you that much.) But what of the small business that doesn't employ you? Do they need to perform that same review? Of course, they could skip it and just compile the thing, but that is the same as just using the binary packages!
You may as well just hang your Linux box out on the net with 500 open ports and no firewalls.
Baloney.
Because a well-hacked program will allow the hacker to get at your data, firewall or not.
A well-hacked program will be completely invisible to you, as well. Your grep methodology is too simplistic to catch any sort of sophisticated trojan. Even if you were to laboriously go through the code, line by line, you still wouldn't catch anything but the most obvious of hacks/problems.
The only way you can be completely sure is to read the source.
No, the only way is to not run it. Software is not a mathematical formula that you can "prove". Large programs are horribly complex, as you most likely already know. Binary packages serve a very useful purpose for many people. If you choose not to use them and to perform some limited form of code review, then that is great for you, but don't try to demean anyone who doesn't do the same.
Gentoo provides binary downloads of the larger packages. The stage 3 tarballs (available in multiple flavors to accomodate different processors) provide the basic system, while v1.4rc2 includes the Gentoo Reference Platform (GRP). GRP provides prebuilt X11, GNOME, KDE, Mozilla, and OpenOffice on x86 and PowerPC systems. (It doesn't seem to have been updated for newer Gentoo versions, so it's no doubt a few versions behind now.)
Binary packages are somewhat ignoring the point of Gentoo...yes, they speed along deployment if you have a bunch of machines to roll out, but you could achieve the same effect on a bunch of identical machines by doing one install in the normal manner and then just clone that install into the other machines. The desire of some people for a quick install hasn't been completely ignored.
(For my purposes, I'll usually start with a stage 1 tarball. I built 1.4rc4 inside VMware on a WinXP box at home; even with VMware only letting Linux see one of the two processors in that system, the build ran quickly enough. Once I migrate my stuff off of the existing server config, alfter.us will switch from Linux From Scratch to Gentoo. I've had it running on several servers at work for a while now...it combines the performance and security of Linux From Scratch with most of the ease of setup of a conventional Linux distro.)
20 January 2017: the End of an Error.
Or even half an hour getting Moz-Frirebird
Half an hour? You spoiled, dual 3GHz-running... guy! Seriously, it's more like 4-5 for me.
Have you ever heard of signed binary packages ?
Mandrake RPMs are security-signed, and if they don't have a valid Mandrake GPG signature, you get prompted as to whether you really want to install them. I'm sure most other distributions which use binary packages do the same.
Why should we choose a binary format when we have Gentoo with which you can download the sources and build your own optimized binaries..
Why should we choose Gentoo when we have the actual sources, with which you can download and build your own optimized binaries?
C'mon, people. This is obviously a joke. It might not be deserving of a 5 (I think it is, but that's not important), but it certainly isn't flamebait.
Putting a compiler on a production machine is a sure sign of an amateur. Any linux noobs out there want to debate this?
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
Here is the link to googles cache of the site:
CLICK HERE
"If ignorance is bliss, why aren't there more happy people in the world?"
Installing from source can take less time and be much easier than installing binary packages. Binary packages depend on one specific set of library versions. For many packages these dependancies are difficult to maintain, without a cascade resulting in the need to upgrade many other packages in your system. If you're building from source, though, you can build the package against whatever versions of the libraries you already have installed...
Let's be honest. If you don't follow the correct procedures in the beginning, anything you attempt afterwards will be a band-aid(tm).
Security is a process, not a line item.
Security requires more time be spent and more effort be expended than unsecure practices.
Right up to the point where someone or something happens to your systems.
For example, if it's not a networking application, then I'll usually grep for system calls like connect() or bind() .. a dead giveaway that somebody has tried to slip some kind of a backdoor into the code. If I find something like that, I rm -rf it and forget it. You can also search for calls like gets(), strtok(), fopen(), and other well-known security risks and fix them if you feel like it.
I have two questions. What percentage of the packages you use did you download the source for and grep through? And how many of them did you find trojans in?
If you have not checked your trusted base (kernel, compiler, linker, libraries and whatever tools you use to look at the code), then you can never be completely sure. See Ken Thompson's article, Reflections on Trusting Trust for an excellent explanation of why.
The net will not be what we demand, but what we make it. Build it well.
I'd put Windows just a little ahead of Linux (because of the multiple formats of Linux packages), but OS X (and all Macs) are way out in front in this arena, IMHO.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
I've been running Gentoo for a few months. I *love* the package manager, except for occasional compile errors (latest problem is with Bash 2.05b-r5).
Anybody know if binary package management would be more stable, but still allow for the somewhat bleeding-edge version releases of Gentoo? I haven't used a binary system in years, so I don't recall what it was like.
Seriously, RPM or .tgz are the only format you need.
Any reasonable arguments for that claim?
Wow. It's just like an M.Doughty poem when you format it like that.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
You cannot get your binary into the main site without going through a social screening process.
.rpm based installations.
This allows more standardization than amongst the various
Standardization means fewer problems for the rest of the users.
But it means more work for the people developing the packages.
I cant read the article since it seems to be slashdotted, but in my opinion the RPM's and DEB's etc. seem all equally good, the difference comes from how easily you can get them and whatever the package depends on. I wouldn't care if my Debian box would use RPM's, as long as I could still use apt-get to grab them and the dependencies.
See A whole lot of unecessary effort
Mad Software: Rantings on Developing So
The return key is a good thing. See?
Everything Zen;
Everything Zen;
I don't think so!!!
All of this goes away if you download and install binary packages. You may as well just hang your Linux box out on the net with 500 open ports and no firewalls....The only way you can be completely sure is to read the source.
You haven't read the entire source of the GNU/Linux system you're running, so you have no business telling us that we ought to do it!
Why am I so confident you haven't read the source? Because it's not possible. Even a relatively basic Linux install will correspond to over 2GB of source code. That would be about 800,000 pages of a typical book (2500 to 2800 characters per page). Source code is typically much less dense in terms of characters per page, so it would be millions of pages. It would take you several years to read it, by which time the bits you'd read first would be long obsolete.
Ever try to gather all the parts needed to compile PHP? I have - we needed the calendar functions which, for some reason, aren't included in most Linux binaries. It didn't complile properly, though; we ended up implementing the needed functionality as part of the scripts themselves, rather than relying upon the "buildable-in" versions.
Binary distributions aren't evil, just because they're binary. If you feel this way, I hope you don't accept those binary installation disks for Linux, since the only safe way to install it is to compile it completely from source, and hand-copy it to a virgin hard drive...
Cause: The word "apropos" is used in The Matrix: Reloaded
Effect: The word apropos is used on Slashdot.
suggestions yes no no no no conflicts yes yes no yes yes
Ahh, I understand...
One of many things that drove me to FreeBSD from Linux was binary packages, specifically RPMs. I built enough stuff from tarballs by hand to know that outside of a few smaller sysutils, many things have a ton of compile-time configurables that aren't modifiable at run-time, such as config file locations, logging options and other sundries, not the least of which might be compiler optimizations, linking options and other things.
Mostly you have no idea what options the binary package builder chose. Some could be stupid, some could be 100% opposite of what you actually want. I always wished there had been a rpm --build-option that would have printed out a summary of the options chosen by the person building the package.
I eventually just took to unpacking SRPMs and building stuff myself, but even that became tedious.
AFIAC it's another bit in FreeBSD ports' favor. I can make extract, check out the build options tweak them and then install the application; a good combination between building it by hand from tarballs (and hoping autoconf or something works right) and accepting a binary that may have been built by someone like me...
This is why debs are signed. Run MD5 on the deb you download and compare it to the one that Debian shows. If they're not the same, delete the package. Don't trust the Debian packagers? Then why the hell are you using their software?
One of the biggest selling points of open source software is that it is precisely that -- open
/var, /home, so I just assign it to /. Different on a server (having /var/log or /home spill into root or /usr is bad).
Or you can choose not to and use a binary. It's about choice and flexibility, not my-way-is-best or "just trust me." I've had some cases where my compiled versions simply aren't quite up to snuff... either because my compiler version is off or other reasons - and the binary worked much better.
The whole my-distro, my-way is just going badly for all open-source. Really, if you have the skills and time to edit source, compile it, etc - go ahead. If you need something to run or can't compile, go binary. And as far as insecurity, don't trust something without a verified signature - even with source there could be something easily overlooked in thousands of code lines in a non-popular module
And hell, what your doing directly influences what you use.
My laptop? I don't really need the segregation of
Servers, a lot of care going into what I put there, optimization, not binaries or precompiled kernels, mostly stuff from deb packages. I also use debian 3.0
Desktops... hundreds of 'em at work, all a mishmash of hardware. I'm looking at the beauty of knoppix or morphix and eying it as the successor to all those nasty win98 machines there.
Oh yeah, and even windows has a place... but that's getting smaller and is generally restricted to me games.
The deal on linux is choice and flexibility. It's not about not-using-windows, or a geeking competition, it's about using what you want and getting what you need. A lot of people tend to forget this.
The RPM/DEb ideas are really good. The main problem i have however , and don't really know how can be solved is combining binary packages with source code packages (eg. when you compile you own X). When the time comes and you want to update , let say Libc, then you will be unable to do so because the dependecies include almost every package.
Or when you compile a program that is listed as a dependency to another program , you can not install that other program because compiling from source code does not update the RPM database.
It seems that binary packages are only good when you stick to what your vendor offers you.
Using --nodeps is not the solutions because it defeats the whole idea of depencdency tracking.
Slashdot Sig. version 0.1alpha. Use at your own risk.
I don't see this as a problem. I personally am glad that there are many packaging systems. This gives me the freedom to use what I like best (deb).
If things were unified to one system your freedom would be taken away. It is surpassing on how many people are willing to give up this freedom.
One of the biggest advantages of the OpenSource movement is that the end user has many choices for just about every aspect of the system.
Live Free Or Die!
I have only recently come across the freshrpms.net site, and I have been amazed at the work that has been there. The site helps the user to find, from a list of supported packages, the most recently rpm packages available for their systems. This site along with rpmfind.net, and tuxfind.net is what makes the RPM packaging system so successful.
I have on the past thought about changing distros, from Red Hat to lets say SUSE, Mandrake, Conectiva, etc, but I haven't mainly because of their support (at the time) for rpm packages was not very good.
Is RPM the best solution for the person who is looking to install software on their Linux box? I have my complaints, but since when does the best solution for a problem is the one most suited for the job?
The constant changes, in path structure in RedHat even between close number releases is not a good thing. It is more akin to a Microsoft like tactic than sensible advancement of an OS.
Perhaps a killer app for linux would be a Pathmaker that reads dependancy requirements goes out and checks the install paths before you ./config. Similar to gdb but easier to step through. Then it could help identify and rewrite any path errors in the source for the user. If the software determines that you do not have a required library then it could help the user to install or see if installing it might cause havock.
The current state of free software for Linux is becoming more and more difficult for the ordinary user to deal with. A logical tool designed to help the ordinary user to use source would sure be great. There are great dev tools in Kde and Gnome but there is a severe lack of a sensible integated install tool for non-coding users.
OH THE SHAME I fell off the wagon and use sigs again!
Why? A compiler is only a translator. How is the ability to translate an arbitrary C program into assembly going to aid an attacker? The attacker could just as easily precompile the program themselves.
Compilers go on development boxes. Production boxes don't have compilers...why on earth would you need one? Don't tell me you're compiling code on a box that's in production!
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
While technically a "binary package format", Gentoo's Portage has a way to create binary tarballs of merged programs. However, this is not meant to be a way to distribute software to random users; instead it's for setups where you have a bunch of similar machines and want to compile once, install many.
When you merge a package, do "emerge -b package". It builds and installs the program like normal, then creates a signed tarball file that you can use to install on other machines. emerge can then take that tbz2 file and treat it as an alternative to the actual compile process.
is to distance ourselfs from the system V filesytem, and have each package installed in it's own dir, this would make things so much easier.
And instead of the old PATH environment variable idea, think of something new, how about a central file (with user modifyable sub-files) that contains a list of all binaries to be called by default.
Or about a package tree in the bash memory, that holds the information which binaries are callable... etc.
There are so much ways to get rid of PATH, and with PATH away, nothing speeks anymore against installing every package in it's very own directory, making administration and package management so much easier...
--
Karma 50, and all I got was this lousy T-Shirt.
Zero Install
"The Zero Install system makes software installation not merely easy, but unnecessary. Users run their applications directly from the Internet from the software author's pages. Caching makes this as fast as running a normal application after the first time, and allows off-line use."
Experimental, but give it a try. See especially the comparison with apt-get and the security model documents.
Huh? No they don't. Most packages don't give a rat's ass where the binary is located. Historically, GCC was one of the few that did, and recent versions have changed that so that you can move the install tree around.
The remaining few packages that care are mostly just suffering from bad design. Fortunately, as you say, they usually pay attention to environment variables telling them where to look.
Here's a better writeup than what I can fit here, at sunfreeware.com. They've been repackaging open source stuff as Solaris-style pkg files for a long time, so they've good experience with these sorts of questions.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
So smart you posted under the wrong story?
I think you mean something different by apropos than I do.
Appropriate, perhaps?
</pedant>
On the commercial side, the most common multiplatform installation tool is InstallAnywhere by Zero G Software. Great tool and certainly has its place along with native binary packages - I've seen tons of enterprise applications that install with InstallAnywhere.
I (author) am currently enroute to Norway, only found out I was slashdotted in the airport. I don't really understand why they posted it today, and not some time in the past 5+ years.. Anyway, I will respond to anything worth responding to sometime later.
see shy jo
I'm surprised nobody mentionned uPM (u as 'micro') so far. I don't know this packaging system very well, but it was discussed on /. a few times IIRC. Seems to be part of uOS, but maybe it can be used on any distro (at least, I see an uPM ebuild on my Gentoo, so I assume this is true) ?
Does anyone have more informations to add about uPM ?
theefer
> Why? A compiler is only a translator. How is the ability to translate an arbitrary C program into assembly going to aid an attacker? The attacker could just as easily precompile the program themselves.
...unless the attacker's computer doesn't have the same architecture as the target machine. Linux and the *BSDs all run on a wide variety of platforms; if you were making a max-damage virus, being able to transport the source kit to the targets and make the executable locally, regardless of architecture, would be a good feature.
Considering that Joey Hess is a prominent Debian developer, it is not surprising that Debian looks like the winner.
More seriously, if I recall correctly (I think I saw this a few years ago being mentioned on debian-devel), this comparison was not meant to prove which packaging format is better, it is more like an ongoing self check within Debian on "what we're doing right/what others are doing that we should evaluate". Plain ol' healthy evaluation of your friendly competitors.
And yes, my favorite distro is Debian, after surviving the cultural shock of going through dselect the first time, now I won't accept anyhing less (maybe I should make a t-shirt design "I [debwhirl] dselect" ':)
plenty other people have already linked to "Reflections on Trusting Trust", so i won't duplicate their efforts. i'll just point out that:
(1) you're _trusting_ that the C compiler really is "only" a translator. unless, of course, you've verified the damn thing yourself, this may or may not be a safe assumption to make. more than likely it *is* safe, of course, but it would be better security to take no more on trust than you absolutely have to - which means, no more code on your important machines than necessary. does the machine need a compiler to do its primary task? if no, it shouldn't have one; useless code can have useless security vulnerabilities.
(2) how is it going to help an attacker? idunno. i don't want to find out, either. any attacker that got through *my* firewall will damn well *have* to precompile their own code (making sure to get all their dependencies right for the target system) then upload the binary, wasting that much more time and effort and bandwidth. this is *good* - it means attacking my system will be that much more work for them. i *want* it to be hard for the bad guys.
(3) sure, the blackhat can precompile and download his own binaries. what if i'm paranoid enough to mount all my "binary" filesystems RO, and all my writable ones noexec? probably a smart enough attacker could work around that too, but doing so without a compiler (or perl interpreter, or whatever else i'm masochistic enough to do without) will be steadily more of a PITA.
security in depth relies on several, independent security measures. each by itself may provide no more than an inconvenience, yet all together may be more trouble than it's worth for any attacker. removing gcc can be one such inconvenience. don't knock it until you've been exploited through it...
The header said:"... Another reader sends in this guide to creating Debian packages which seems apropos here. " Apropos is not appropriate in this context. Surely what was meant was: Another reader sends in this guide to creating Debian packages which seems apt here.
Am I the only one who hates it when people use that word all over the place?
This is why RPM has file dependencies, though its usage is up to the packager. For example, most RPMs require the file libc.so.6 but it doesn't have to be from the glibc RPM.
Escher was the first MC and Giger invented the HR department.
Todo.
* relocatable packages
* support for arch name in metadata, arch indep packages
* multiple version of the same package can be installed simultaneously (is this really a package format issue?)
Sigh. The guy has an entire section on how well "standard" tools can manipulate these file formats, as if the typical user has any desire to do home surgery on their software.
(Well, why shouldn't he? The typical linux user does want this level of control...)
But there, at the end, in the neglected "ToDo" section, are the real issues. Features that put the user in control of their software instead of the other way around. Is anyone ever going to write a package management system that addresses the needs of the user, instead of the sysadmin?
-pmb
apt is not tied to the deb package format. There is apt for rpm, but the lack of apt-gettable rpm sites is a problem. On the other hand, Mandrake has urpmi which is similar in functionality.
Escher was the first MC and Giger invented the HR department.
It is important to note, that for the PKG format (Solaris, etc) that System V does not define certain functionality, but the system vendor may include it. I know that Solaris does support ghost files, editable config files, virtual packages and boolean dependancies, but the chart doesn't reflect this.
;)
.02
Not that this helps out the Linux community in the slightest...
I still think Apple's (NeXT's) App format is still the best. A complete archive including all features and bits of an app that can be moved around at will.
My
Contrary to popular belief, life is not a bitch. It is far far worse.
My EPM software (http://www.easysw.com/epm/) supports the creation of software packages in multiple formats along with a common "portable" format that works on all systems.
I print, therefore I am.
Ah, this old chestnut. ISTR this comparison of formats was first mentioned on Slashdot a few years back.
.zip format because this is extractable on MS-DOS too; or storing all your images in xpm format because you can view it as a C header file in your text editor (urgh).
I have to take issue with the 'usability by standard Linux tools' columns. RPM _is_ a standard Linux tool and it's easy to install it (or even just rpm2cpio) on systems that don't use it. Systems that don't use RPM would not be interested in RPM binary packages (maybe in source packages, but that's a consideration for only a few users). You might as well advocate making packages in
-- Ed Avis ed@membled.com
-malander
don't moderate, flame!
One of the main reasons I enjoy DEB binary packages which also do not have any of the bad issues you mention is this:
Dude, you can do that with _any_ distro with binary packages. I personally do it with Slackware.
I don't know what format it's considered (.run file), but did anyone else install Wolfenstein Enemy Territory on linux? It seriously couldn't have been easier. I executed the file on Mandrake 9.1, a nice little graphic popped up with a logo telling me that I was installing the program, it gave me options of where to install the files to, whether or not to add an entry to the Kicker, etc.
This was the closest thing to a simple Windows installer that I've ever seen on Linux. Absolutely painless, n00bie friendly... exactly what Linux needs to assist in penetrating the desktop.
Now this whole episode took me a matter of hours. Whereas Windows would take me a whole 30 minutes to choose what I did/didn't want to install and then download my fixes.
.figure out the best way to install your packages.
Why didn't you just drop them all in a directory and execute rpm -Uvh * instead of manually installing one at a time? That let the package manager do what it does best . .
As far as the 30 minutes on windows deal, on my Debian box I type apt-get update; apt-get upgrade and walk away. On my Gentoo box I type emerge sync; emerge -u world and walk away. Mandrake has urpmi that does the same thing, Connectiva has apt for rpm. If you would have looked, Redhat8 has an automatic updater that will do it for you. Shit, even Slackware has an automatic updater in the works.
Get your information straight before you bitch. Just because you can't figure it out doesn't mean it doesn't have that capability.
This file is usually statically-linked, and can be used instead of RPM to install packages in case of emergency.
I was disappointed to see that there was not an included compaison of the .sh (or other script) wrapped packages (usually .tar.gz (.tgz) or .tar.bz2).
> Dude, you can do that with _any_ distro with binary packages.
:)
> I personally do it with Slackware.
I didn't mean to imply that only deb can do this. Just that its what I happen to use.
The parents post was claiming that building from source each time is the 'only way', which was what I was arguing
Half an hour was a guess. It was less than 3 for sure though. I have XP1700+ with 512mb of ram, so don't get too jealous.
(p2 200 and the like)
:)
That's quite a trick, since the slowest Pentium 2 made was a 233. Underclocking for longer hardware life?
You like your new Mac more than you like me, don't you, Dave? Dave? I asked...She said Yes.
The developer of swaret (update utility for Slackware) and I have been working on resolving library dependencies when a user installs or upgrades tgz packages in Slackware. To make a long story sort, it works great. New release due out 13 July. Info at http://swaret.xbone.be.
I've used many systems, and many package systems.. from old machines where there really was no concept of a package, to debian, with it's superb package management, and everything in between.
The only conclusion I've come to is this: The package format itself isnt' so important.. what matters is the whole system approach to packaging and distribution.
Take Debian. Everyone agrees, I think, that the debian package format, and apt, together make for a great system.. but that's because of the method of package distribution and tracking, not the packaging system itself.. that and the fact that it's fairly universal in the debian world. Several apt repositories make up basically all software available for debian... and it's a lot. SO the overall experience is "Great package management". It's not just about the format, but the people.. people know what's in the standard packages, and can refer back and forth to them, checking for compatability and whatnot. The overall appraoch to package management is what rocks.. not the binary format.
Look at OSX.. they have fink. Fink, if you don't know, is basically apt-get for OSX. Works fine, no problem... except, it puts stuff in it's own folder (/sw) and it doesn't necessairly know about apple stuff already installed.. it only tracks stuff that is in the fink repositories.
In other words.. it's useful, but it doesn't have the feel of a really great package system.. because the system itself isn't based on it.
People say "ports rocks" in bsd land... but why? Becasue it's superior? No.. just because it's a big collection of useful stuff that handles dependencies well. The actual package management system is extremely basic. But the system is more or less based on it, so it works very, very well.
Redhat.. is kind of a mess. Is it because rpm sucks? Heck no.. it's just because, well, the overall approach wasn't right.
OSX.. (yeah okay I'm a mac fiend now.. I admit it.). What package management? Apps tend to be one single file, which is a package containing all the bits and pieces. No real package management system to see what's installed or not.. and who needs it.. you can just go to the Apps folder and toss stuff in the trash to get rid of it. The system was designed to work that way. so it works really well. You don't say "Gee I wish the system tracked apps" because it's so very simple to get rid of them, and to ferret out any pieces they may have left behind, which is rare..
So overall... the complexity of the package management isn't as important as everyone sticking together on how things are going to be installed and removed. If everything works the same way, it doesn't really matter how sophisticated it is.
He states that rpm is not unpackable by standard tools.
Can an experienced user, when presented with a package in this format, extract its payload using only tools that will be on any linux system? They can remember a few facts to help them deal with the format, but remembering file offsets and stuff like that is too hard.
First problem I have is with the "any linux system" Ummmm I've a Linksys router running Linux that can't do jack with any of these. Next an RPM is actually a cpio archive rpm2cpio is actually just a tool to shortcut what is doable with cpio. This applies as well to all of the "standard tools" statements. I also would like to point out that standard depends on which standard you use. Posix, LSB etc. In that rpm is a standard of LSB but not of Posix.
His statement that binary programs are not allowed.
Must these programs be scripts, or can compiled binaries be used as well?
This is very, unclear. Can I execute a binary from within rpm. The answer is yes. I do it all the time. Can RPM be made directly from binaries (skiping all of the build etc.) Yes it can. Can I embed the binary in the RPM and not have it ever get installed... no. But I can run it then remove it before RPM finishes.
Suggestions ... he states that RPM doesn't have them.
... but it's up to the packager to use the tool. Second the author needed to get a little deeper into rpm's queryformat (info here) He would have found much of what he needed.
A suggestion says a package may sometimes work better if another package is installed. The user can just be informed of this as a FYI
This is really the fault of the packager not of the product. There are two areas for comments which can give you this kind of data
Statement that RPM can't do Boolean Relationships.
This means that a package can depend, conflict, etc on a package AND (another package OR a third package). Any boolean expression must be representable, no matter how complex.
RPM does have the conflicts and the depends paramaters that can be set. Once set you can't install a without b and c, plus removing y and x.
HOWEVER he is very right about the boolean "or" being missing... I've been championing this one for a while (I've talked with some of the developers.) but it seems it hasn't up till now been high enough on the horizon to have someone take a shot at it. (Sorry but it's beyond my ken to work on this personally) So I will keep politely advocating this until it does break the plane of need.
New Section
.. On a system that uses this product how do you do X" will yeild a completely different answer.
Sorry but this stament is just too nebulous. It's been coping with the unforseen for years. Just as debian has. That's why it get's upgraded. That's in fact a lot of the reason for the new version coming out now. To make the format more modular. and easier to mutate as times change.
All and all the article seems well done. However I'd say the chances are pretty strong that the author is a Debian fan. My personal recommendations would be. One lose the subjective nature of a number of statements. Next, when doing research be careful how you ask a question. Often times asking "Can this product do X" will yeild a no. But if you ask
I'd give this article all in all a 6 on a 1 to 10 scale for research. a 3 for new info. and a 7 for layout and style.
I'm sorry, I'm to tired to be witty at the moment so this message will have to do.
$ cat /proc/cpuinfo
vendor_id : GenuineIntel
[snip]
model name : Pentium II (Klamath)
cpu MHz : 233.869
[snip]
Doh, i guess you are right!
Dunno where the 200 number stuck in my memory from.
Here it would be fitting to point the original poster to Ken Thompson's Turing award speech, Reflections on trusting trust.
To quote:
Stefan Axelsson
Alien allows you to convert LSB, Red Hat, Stampede and Slackware Packages into Debian packages, which can be installed with dpkg
Not sure how well it handles dependencies and such, though.
It's interesting to see how similar the .deb system is to the FreeBSD Ports collection, if you look beyond the details.
They didn't review FreeBSD's, one of the best there is. What a fucking waste of time.
... is that this article was writtin 5 years ago. I don't believe Gentoo really existed back then :).
In case kiddie doesn't find gcc on the system, kiddie easily compiles binary on different system (although i agree that in case it's some less popular platform, it would be a bit harder).Then kiddie uploads the code to your server via something like netcat or even copy&pastes(!) base64 encoded binary.
And no, deleting uudecode won't help either - it's trivial to write some decoder in your favourite shell...
I'm somewhat amazed that there used to be a standard package format for SysVr4, which I think many Linux distros model after. Why is it historically so that every distro seems to need its own package format, instead of adapting towards the standard?
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
I'm one of the developers of the Autopackage project, and we have bumbed into the relocateability problem since Autopackage allows user (non-root installs).
/proc/self/exe. However, this only works for applications, not for libraries. We still haven't found a solution for libraries, so for now we are using a "semi-hack" solution called libprefixdb.
/etc/ld.so.conf! I don't think that's a good thing.
In Linux (dunno about other Unices), there is one way to tell where the application's binary is: by dereferencing the symlink
Using a shell script is another solution (since shell scripts can find out their own location), but too only works for applications.
Personally I don't understand what's the big deal about AppFolders. How do you want to handle dependancies? I don't think that shipping all dependancies in the app folder is a good and efficient solution. That'll make us no better than Windows apps which also ship all their dependancies.
And second, why should the user even care about where an app is installed? They launch the app using icons and menus, and that's the only thing they should have to know! Letting them know where the app is installed to is exposing implementation details. Users shouldn't have to know about that (unless they're programmers or something).
And installing each app in it's own folder would require 200+ entires in your PATH variable and
Might want to check out the ESP Package Manager. It seems to be able to generate output for multiple 'single package systems'. I just stumbled onto it while looking for more info on packing options. Haven't used it but it does make for a good/polished presentation...If the software is half as good...:-)
-l
It could be the P1 and Pentium Pro. Pentium Pros came in up to 200MHz, and original pentium topped out at 233.
You like your new Mac more than you like me, don't you, Dave? Dave? I asked...She said Yes.
Don't forget to write your own assembler first using "echo 'crazy_acsii_codes' > hand_made_binary".
First off, the entire "metadata" section is FUBAR. tgz isn't a package management system; it is a packaging system. Something like portage is needed on top of it; comparing tgz to rpm is like comparing yaml to jabber. Therefore, entire sections in this "comparison" should be marked N/A, not "no".
What this with "documentation file specially marked?" tar tzf | grep. Duh.
Oh, and tgz files are indeed recognized by file.