Why on earth to 32-bit programs have their installers written as DOS programs? I can't think of any.
Reminds me, are all the DLLs with '32' in their names renamed to '64' on Amd64? Or will our children and our children's children wonder, in times far in the future, what piece of bad designed caused ADVAPI32.DLL to be named so, even on a 64 bit platform?
What translation of the Bibile are you reading? I'd be interested to read one that was done in modern times, from as close to the source material as possible.
First of all, you are correct; Grub can't compare to OpenBoot/Firmware, etc.
However, you can list devices present with tab completion. Type root (hd and you will get a list of all your disks. At least the ones that Grub can see through the PC BIOS calls. *shudder*. God knows how you're supposed to boot off a PCI IDE controller, I sure as hell can't.
Ah, so it's informative, not normative--fair enough. I never looked into it that deeply.
It's worth noting that the current version of the lsb package in testing/unstable is 2.0.
I wonder if all this is irrelevant anyway... vendors like Oracle say that their products will run on Red Hat version X and Suse version Y, rather than any LSB-Z compliant distribution.
> So the packager have to do something special to generate MD5 sums? What if he > forgets to do it? What if his script is not correct? RPM does this for you > automatically.
If the packager is using CDBS then it is done automatically. If the packager is doing stuff manually then they are generally intelligent enough to place dh_md5sums in debian/rules. This is even the default for a skeleton rules file generated by dh_make.
> No. RPM's debuginfo packages are created for every package automatically.
Cute, that sounds useful. I guess Debian doesn't do it either because no one has asked about it, or because it is hairy to generate such symbols across Debian's 11 architectures or something.
> With RPM, you can download the tar.gz file from the upstream site, and run "rpmbuild -ta.tar.gz"...
Well this is just a case of whether you include the.spec file, or debian directory, in teh upstream archives, isn't it?
An upstream package developer is free to include a debian directory inside their own releases; ndiswrapper is one package I use where upstream does this. Of course, in almost every case this directory is removed and replaced by the Debian maintainer of the package, since usually upstream's attempts at a debian directory are sorely lacking.
If you are both the developer and packager then you have two choices:
Create a 'debian native' package. Native source packages dontain only an orig.tar.gz. This is for packages native to Debian, where it doesn't make sense to have a separately maintained debian directory, such as apt or dpkg.
If your package is not specific to Debian, then you should separate your roles as developer and maintainer, and keep the contents of your debian directory out of your 'upstream' releases. In this case, your 'upstream' releases become the.orig.tar.gz archive, and your debian directory it stored in the per-Debian-revision.diff.gz file.
Ok, dpkg can't do this. However at the risk of sounding like a pompous twat, it sounds liek the kind of thing that shouldn't be necessary if you factor the operations that your packages perform correctly in the first place.:)
A Debian package that could be extended with other packages would tend to use a method more along the lines of this:/etc/init.d/foopackage sources all scripts in/etc/foopackage.d/ barpackage contains a file:/etc/foopackage.d/barpackage.sh
FYI, barpackage would then probably declare Enhances: foopackage in its control file, but that's not directly relevant to the above.
There are two ways that this is done in Debian, IIRC. The first way is to sign the actual.deb file itself. This is used to confirm the authenticity of a particular package, and the checking is done by the debsigs package.
The second way is to sign the Release file that each Apt repository provides (the Release file contains a cryptographic hash of the Package files, which contain hashes of the individual packages). You can start digging down the chain of trust from http://ftp.uk.debian.org/debian/dists/sarge/, for example.
This second method is used to ensure that a given package is part of a given release of Debian, so you can be sure that the package you are installing has not been obsoleted by, say, a security update. Now, for some reason, the version of Apt that comes with Debian doesn't do these checks, you have to pull Apt 0.6 from experimental. I guess it will be uploaded to Unstable once Sarge is out.
> MD5 sums
Most packages generate MD5 sums at build time. You can configure dpkg to generate missing md5sums at install time if you want.
> There were no debuginfo packages.
Packages with debugging symbols? There are plenty; look for, eg, libc6-dbg. Obviously, it's up to the package maintainer to create such packages along with the more usual libfoo and libfoo-dev packages.
> No rebuilding from a taball with.spec (or what) file included
Not sure what you mean by this. The say to rebuild a set of binary packages is to download the source package (consists of a.dsc file, a tarball of the sources and a patch). You then install the source package's build-depends (specified in the source package control file). Finally, you run the build script to build the package.
This process can be automated to a greater or lesser extent according to your preferences. I prefer to run apt-get source, apt-get build-dep, fakeroot debian/rules binary manually, I think DDs tend to use dpkg-buildpackage because it does extra stuff that they need to do in order to upload the result, like signing the packages with Gnupg. There is even a tool, apt-build, that automates the entire process, including compiling build-depends as well, all with customisable compiler flags, etc etc. Useful for people who like Gentoo, maybe.
> "Nosource" directive
If I have a correct understanding of what this is for, the way it's done in Debian is to remove the files from the upstream tarball, before uploading the source package. I can see why specifying the files you don't want included somewhere else, and having them removed after the fact, is useful; however Debian packages must be freely distributable, and so uploading a source package containing undistributable files is not allowed.
I don't know what RPM triggers are, but a cursory Googling indicates that they are similar to the {pre,post}{inst,rm} scripts found in debs. Perhaps the typical contents of an RPM trigger are too dissimilar to a postinst script for the same script to work on two different distributions?
The Debian package format provides all the stuff you list as being specific to RPM. Except for a warning about forgetting to package a file that was built.
It seems the two formats are more similar than many people suspect.
Whoa, we don't want that! The Orange County Book Burners responsible for the sticker would just pull their kids out of school all together--better they are home schooled, than their minds are poisoned by the evil of books!
When he spoke of "one-sided" copyright laws, the OP referred to how in the Good Old Days, copyright was a covenant between an artist and the public; the artist was granted a _temporary_ monopoly on the distribution of his work, and after the copyright expired, the work returned to the public domain.
These days, whenever Mickey Mouse is about to fall in to the public domain, Disney just buys a new law extending the copyright period.:(
Ah, "Love it or leave it"--the words of the small-minded coward who is too afraid to admit that there might, just might, be something wrong with his country.
So basically, you dislike Java because it is not Lisp?:)
Remember, Java is an excellent language to use on your project, because it allows a PHB to hire hundreds of cheap, poor programmers, as a commodity. Java's structure reduces the difference between how different people/teams write code, so that new developers can be integrated into a development team faster, spending less time learning the ropes of a particular project.
Java is a good tool to allow poor programmers to write reasonable code.:)
Slashdot Mirror
Why on earth to 32-bit programs have their installers written as DOS programs? I can't think of any.
Reminds me, are all the DLLs with '32' in their names renamed to '64' on Amd64? Or will our children and our children's children wonder, in times far in the future, what piece of bad designed caused ADVAPI32.DLL to be named so, even on a 64 bit platform?
What translation of the Bibile are you reading? I'd be interested to read one that was done in modern times, from as close to the source material as possible.
Strange, it works fine here. Try http://www-biol.paisley.ac.uk/courses/Tatner/biome dia/units/bird3.htm since the OP was unable to insert a link himself.
l #pred4) gives a better overview anyway.
I believe this document (http://talkorigins.org/faqs/comdesc/section1.htm
The thing is, the other two companies are the ones that run .biz and .info.
Hardly a reputation that imbues honesty and integrity.
The German company might do ok, but I doubt manyAmericans would feel comfortable with that.
First of all, you are correct; Grub can't compare to OpenBoot/Firmware, etc.
However, you can list devices present with tab completion. Type root (hd and you will get a list of all your disks. At least the ones that Grub can see through the PC BIOS calls. *shudder*. God knows how you're supposed to boot off a PCI IDE controller, I sure as hell can't.
Ah, so it's informative, not normative--fair enough. I never looked into it that deeply.
It's worth noting that the current version of the lsb package in testing/unstable is 2.0.
I wonder if all this is irrelevant anyway... vendors like Oracle say that their products will run on Red Hat version X and Suse version Y, rather than any LSB-Z compliant distribution.
Not to mention that Debian is about to break lsb compatibility in a fairly major way with Multiarch (http://raw.no/debian/amd64-multiarch-2).
> So the packager have to do something special to generate MD5 sums? What if he
.tar.gz"...
.spec file, or debian directory, in teh upstream archives, isn't it?
.orig.tar.gz archive, and your debian directory it stored in the per-Debian-revision .diff.gz file.
> forgets to do it? What if his script is not correct? RPM does this for you
> automatically.
If the packager is using CDBS then it is done automatically. If the packager is doing stuff manually then they are generally intelligent enough to place dh_md5sums in debian/rules. This is even the default for a skeleton rules file generated by dh_make.
> No. RPM's debuginfo packages are created for every package automatically.
Cute, that sounds useful. I guess Debian doesn't do it either because no one has asked about it, or because it is hairy to generate such symbols across Debian's 11 architectures or something.
> With RPM, you can download the tar.gz file from the upstream site, and run "rpmbuild -ta
Well this is just a case of whether you include the
An upstream package developer is free to include a debian directory inside their own releases; ndiswrapper is one package I use where upstream does this. Of course, in almost every case this directory is removed and replaced by the Debian maintainer of the package, since usually upstream's attempts at a debian directory are sorely lacking.
If you are both the developer and packager then you have two choices:
Create a 'debian native' package. Native source packages dontain only an orig.tar.gz. This is for packages native to Debian, where it doesn't make sense to have a separately maintained debian directory, such as apt or dpkg.
If your package is not specific to Debian, then you should separate your roles as developer and maintainer, and keep the contents of your debian directory out of your 'upstream' releases. In this case, your 'upstream' releases become the
Ok, dpkg can't do this. However at the risk of sounding like a pompous twat, it sounds liek the kind of thing that shouldn't be necessary if you factor the operations that your packages perform correctly in the first place. :)
/etc/init.d/foopackage sources all scripts in /etc/foopackage.d/ /etc/foopackage.d/barpackage.sh
A Debian package that could be extended with other packages would tend to use a method more along the lines of this:
barpackage contains a file:
FYI, barpackage would then probably declare Enhances: foopackage in its control file, but that's not directly relevant to the above.
> weren't GPG signed
.deb file itself. This is used to confirm the authenticity of a particular package, and the checking is done by the debsigs package.
.spec (or what) file included
.dsc file, a tarball of the sources and a patch). You then install the source package's build-depends (specified in the source package control file). Finally, you run the build script to build the package.
There are two ways that this is done in Debian, IIRC. The first way is to sign the actual
The second way is to sign the Release file that each Apt repository provides (the Release file contains a cryptographic hash of the Package files, which contain hashes of the individual packages). You can start digging down the chain of trust from http://ftp.uk.debian.org/debian/dists/sarge/, for example.
This second method is used to ensure that a given package is part of a given release of Debian, so you can be sure that the package you are installing has not been obsoleted by, say, a security update. Now, for some reason, the version of Apt that comes with Debian doesn't do these checks, you have to pull Apt 0.6 from experimental. I guess it will be uploaded to Unstable once Sarge is out.
> MD5 sums
Most packages generate MD5 sums at build time. You can configure dpkg to generate missing md5sums at install time if you want.
> There were no debuginfo packages.
Packages with debugging symbols? There are plenty; look for, eg, libc6-dbg. Obviously, it's up to the package maintainer to create such packages along with the more usual libfoo and libfoo-dev packages.
> No rebuilding from a taball with
Not sure what you mean by this. The say to rebuild a set of binary packages is to download the source package (consists of a
This process can be automated to a greater or lesser extent according to your preferences. I prefer to run apt-get source, apt-get build-dep, fakeroot debian/rules binary manually, I think DDs tend to use dpkg-buildpackage because it does extra stuff that they need to do in order to upload the result, like signing the packages with Gnupg. There is even a tool, apt-build, that automates the entire process, including compiling build-depends as well, all with customisable compiler flags, etc etc. Useful for people who like Gentoo, maybe.
> "Nosource" directive
If I have a correct understanding of what this is for, the way it's done in Debian is to remove the files from the upstream tarball, before uploading the source package. I can see why specifying the files you don't want included somewhere else, and having them removed after the fact, is useful; however Debian packages must be freely distributable, and so uploading a source package containing undistributable files is not allowed.
I don't know what RPM triggers are, but a cursory Googling indicates that they are similar to the {pre,post}{inst,rm} scripts found in debs. Perhaps the typical contents of an RPM trigger are too dissimilar to a postinst script for the same script to work on two different distributions?
On Debian, installing 'lsb' from apt gives you a fully LSB compliant system.
The Debian package format provides all the stuff you list as being specific to RPM. Except for a warning about forgetting to package a file that was built.
It seems the two formats are more similar than many people suspect.
Look, you're never going to be able to convince the static-linking-luddites. Just give up. :)
Cite please?
l and I can't seem to find any mention of Internet Explorer.
Do you really mean what you are saying? I've looked through all the Native APIs listed at http://www.sysinternals.com/ntw2k/info/ntdll.shtm
If there are less of these kind of users on the Net, then there is a decrease in the target audience of all the spam and spyware we put up with.
If we're lucky then eventually, we will even see an end to the Septermber that never ended...
Don't say you weren't thinking it!
Whoa, we don't want that! The Orange County Book Burners responsible for the sticker would just pull their kids out of school all together--better they are home schooled, than their minds are poisoned by the evil of books!
> Wow, well money talks too.
:)
:(
Well, you're not wrong!
When he spoke of "one-sided" copyright laws, the OP referred to how in the Good Old Days, copyright was a covenant between an artist and the public; the artist was granted a _temporary_ monopoly on the distribution of his work, and after the copyright expired, the work returned to the public domain.
These days, whenever Mickey Mouse is about to fall in to the public domain, Disney just buys a new law extending the copyright period.
Tell it to these people. :)
Ah, "Love it or leave it"--the words of the small-minded coward who is too afraid to admit that there might, just might, be something wrong with his country.
If softwareupdate doesn't return immediatly, and instead quits once the update is done, you can "softwareupdate -ia && shutdown -r now".
http://www.google.com/search?q=legal+torrents
Untill you want to go to Windows Update in order to download, say, the vendor patch for this issue.
Oh wait! No need to worry--there's no patch available from the vendor for this issue in the first place!
You're arguing with an AC, what do you expect :)
find -type f -exec sed -i 's/Biotch/Lawyer/g' {} \;
:)
But anyway, I'd be scared if a company website consisting of 96,000 pages really stored them all as separate, flat files.
So basically, you dislike Java because it is not Lisp? :)
:)
Remember, Java is an excellent language to use on your project, because it allows a PHB to hire hundreds of cheap, poor programmers, as a commodity. Java's structure reduces the difference between how different people/teams write code, so that new developers can be integrated into a development team faster, spending less time learning the ropes of a particular project.
Java is a good tool to allow poor programmers to write reasonable code.