We don't overwrite glibc or gtk or any of your precious system components. Autopackages are desktop apps, remember?
Perhaps that's your goal, but desktop apps are some of the applications with the most insane set of dependencies out there; it's definetly not unforseeable that your package will require a version of gtk that is slightly different from the version that is installed upon the system. [Worse, if it has the same soname but different API or ABI.]
You are talking about the C++ ABI problem. We have done extensive research on that area, and we have a solution [plan99.net] planned for autopackage 1.2 (due very soon now).
This "solution" is to double or trebble the size of the packages distributed by compiling them for every possible ABI incompatible version.
If you install an autopackage as root, it'll be installed to/usr. This can be customized by editing a configuration option. If you install an autopackage as user, it'll be installed to ~/.local.
So autopackage will stomp all over the files installed by the distribution by default. Great to know. (What happens if it installs a version of a library that is ABI incompatible with a version that the distribution ships?)
I don't really understand what you mean. But we detect dependencies in the same way like autoconf does: by directly scanning for their presence. But nobody seems to complain about that.
Surprisingly, people in autopackage's target demographic probably would complain about autoconf... but regardless, the question was how will autopackage deal with an ABI conflict (lets say the gcc-3.3->gcc-3.4 one) between itself and a library it wants to dynamically link with at runtime. Seems to me that you're going to end up with the same sorts of package incompatibilities between distributions that autopackage was supposed to solve.
Is there something wrong with focusing on desktop applications?
What you focus on isn't the point; the issue was that dealing with the above will (most likely) require you to deal with a whole host of things which are decidedly not "desktop applications."
In any case, best of luck. Just don't expect distributions to be willing to support people who have installed packages using autopackage. [And don't be surprised either if distributions speak actively against the use of autopackage.]
By default, programs installed with root privileges are placed in/usr/share.
I sure hope that's a typo for/usr/sbin... If not, well, that's so horribly broken that I don't even want to get strarted with it. FHS anyone?
When a package is removed, its dependencies remain. Hearn and Lai point out that dependencies are not always removed by some other package management systems, either.
Some package management systems may not do that, but at least they keep track of exactly which packages have been installed so you at least have a chance of removing the dependencies at some point in time. With this solution you end up with files on your system that have no clear correspondence to any package, which kind of defeats the purpose of having a package in the first place. (To just expose my bias... aptitude, synaptic or deborphan anyone?)
"A binary from one distribution doesn't always work on another, because of things like glibc symbols and C++ ABI." [...] "Native package managers' dependency detection depends on a database. Autopackage, on the other hand-detects dependencies by actually scanning for them."
Right, and what exactly is autopackage going to do about these dependencies once it has found that they don't match up? Use LD_PRELOAD and have multiple copies of system libraries in place instead? Oh wait, autopackage is for "desktop packages only".
Of course, all of that isn't to say that autopackage may not do something useful in the future, but it sure looks like some of the fundamental problems of developing and distributing packages which other packaging systems have already dealt with still remain to be solved.
In any case, if you don't believe me, see what Scott Remnant has had to say on the matter (he's currently the dpkg maintainer, so he at least is passingly familiar with the issues surrounding a packaging format.)
If you still think that obfuscating the source code is going to gain your company anything, then I doubt anyone really wants to see your code at all. (You don't happen to work for Blackboard, do you?)
And when will Debian start a Debian GNU/MINIX project?
When you or someone like you decides that it's actually worth doing, and sits down and does it. The fact that it hasn't been done yet indicates that no one has decided that it's worth doing and done it.
But for Debian users, you aren't supposed to even be able to have 64-bit and 32-bit binaries co-existing on one system.
The 64 bit Sparc port must be an example of my overactive imagination then... it's been running 32 bit userland with specific 64 bit programs for quite some time.
Those results were based on well-conceived and performed experiments, all of which confirmed their hypothesis (b/c they couldn't get close to light-speed so they couldn't tell).
It's more correct to say that their experiments all failed to disprove their hypothesis. In the end, that's what science is: Making hypothesis which you then attempt to disprove through the most rigorous experiments you can contemplate.
I was specifically referring to the plans to throw out most architectures.
This is primarily related to the ability of these architectures to actually be supported when there are few people willing to put in the work to keep them working... assuming Developers and other volunteers continue to care about those architectures, expect to see them continuing to be released.
No, the version number was planned for quite a long time to be 3.1. The only time using 4 was even brought up was a few months before release by people who aren't on the release team, and therefore don't make the decision on what arbitrary dotted set of integers that is strictly greater than the previous arbitrary set is used.
Who cares what the release is numbered anyway? Call it pi if it makes you happy.
Is there an "Open Source license-picking wizard" anywhere?
Not really, but there are really only two (maybe three) sane choices (unless the project you are developing for uses a different license already, or you already know better):
MIT
GPL (maybe LGPL)
Anything else risks your license being incompatible with large swaths of software (in the linking sense) and possible failing the DFSG. Moreover, using uncommon licenses means that you're more and more on your own for figuring out what they mean.
This proves that not only was humanity designed by coders, but that your butt is a hack that was stuck in after a rather unpleasant code review.
See a planaria or cnidarian if you need an example of an organism that managed to escape the unpleasant code review... having no anus, it gets to spend its time eating through its pharynx or oral opening, processing its food, and then pucking it and the wastes back out.
Consider this: for blood clotting to occur, one needs a dozen proteins to be present, none of which serve ANY OTHER PURPOSE in the absence of all of them. How could this evolve?
Clearly you have not yet studied introductory molecular biology.
You can get rudimentary clotting with two proteins. Fibrinogen, and ICAM. Obviously to any molecular biologist, these two proteins have very important functions in any relatively large organism. The latter is one of the intracellular adhesion molecules that is reponsible for the adherance of cells to basal lamina amongst other functions. Why is that important you ask? Consider what would happen if your epidermis came unglued easily from your basal lamina: blisters on all of your joints. (Yes, people who have mutations in these various receptors do have blisters on most joints.)
So clearly, one of the proteins that functions quite elegantly in clotting is quite important in other functions of the organism, and a similar protein would have to be present early on in order for single celled organisms to clump together to form a multicellular organism.
As for the second protein, fibrinogen, it's actually quite simple. You stick a whole bunch of RGD interspersed with spacing regions, and you can get a reasonable approximation of fibrinogen. [Obviously, the early multicellular organisms would also have had to have expressed something for ICAM to bind to as well, so they would have been making a similar membrane bound protein quite early on.]
Finally, before trotting out examples of how specific proteins don't serve "ANY OTHER PURPOSE" it would be quite helpful to list exactly which proteins you are refering to, and to have done some preliminary thinking on your own to propose a method in which those proteins could have arrisen.
[If someone wants to check the possibility that the program I've outlined here actually occured, you can quite easily track fibrinogen and ICAM homologues through various organisms that have been sequenced (the C. elegans->drosophila->human comparison should be illuminating) to see just how ICAM and fibrinogen could have been derived from those present in early organisms.]
The thread that discussed the APSL version 2.0 is here
Unfortunatly, there isn't a particularly good sumary of the problems with that license in the thread, if for no other reason than the thread goes on for a few hundred messages. The reason why I posted only the message from the bug is because Steve had actually sumarized the issues relatively well. As far as whether or not the license fails the DFSG, the debian-legal list never officially closes a question even when a summary is made. If new information is brought forward, anyone can revist an old question.
If you're still having a hard time understanding what actually occurred in this case, feel free to e-mail me, as holding a discussion in a weeks old slashdot thread is kind of annoying.
Specifically, there is not an infinite number of people
There is a fundamental difference between the term "infinite" as used in mathematics and the term "infinite" as is often used in common speech. The former is the number greater than any natural number, the latter merely means uncountably large. Without devolving into rediculous pedantism, the usage in this sentence falls under the following definition:
From WordNet (r) 2.0 [wn]: infinite 3: too numerous to be counted;
Now, if you want to argue that WN and Web1913 have got it wrong and that infinite should only apply in the mathmatical sense, well, I suppose you've got a bit of work on your hands to convince a large number of people who are quite capable of dicerning between the same word used in two different ways. (Note as well that we're talking about countable in the "I can physically count these things" sense, not in the "Aleph Null" sense.)
Olson should know. He is one of a select few looking to review the current GPL and recommend updates for the public review process, which he says should happen before the end of the year.
Right, so Mike Olson is one of an infinite number of people who can read the current GPL and recommend updates by mailing licensing@gnu.org for public review. Obviously this makes him an insider. (Congratulations! If you're reading this, and can click or right arrow on two links, you're an insider too!)
Oh, right. Must not have actually checked all that out. Gee, does Mike Olson even use the GPL at all? Why would he be reviewing it anyway? Well, lets see: hrm... this sure looks like the 3 clause BSD license to me. Yerp. No GPL in sight at all. Ok, so someone who doesn't even use the GPL, (to my knowledge) isn't a lawyer, and isn't a prominent member of the copyleft side of the Free Software movement is reviewing a license that no one else has seen?
I mean, I can understand slashdot editors missing this bit of trivia in their rush to approve/reject a story... but surely Michael Singer at internetnews would have bothered to actually check if Mike Olson was the "insider" he was claiming himself to be?
Any objections Debian people have against it should now be strongly justified rather than vaguely hinted at, so we can stop getting these silly bug reports which escalate a vague licence issue to full-scale removal without a proper discussion.
Did you even actually read the bug report? APSL 2.0 has been extensively discussed by the debian-legal mailing list which is the body that typically deals with these things. The executive summary is the following:
The copyright license is terminated if you attempt to defend your patent
rights against Apple.
The license requires you to publish any local modifications if you deploy
public services based on the Covered Code, which discriminates against a
field of endeavour.
The license includes a choice of venue clause forcing all licensees to
accept the jurisdiction of the Northern District of California, which is
discriminatory against persons located outside this district by exposing
them to unequal legal expense.
While it's possible that you disagree with the conclusion that was reached by Debian, to claim that the license wasn't properly discussed or that the problems were just vaguely hinted at is rather irresponsible, considering that the second message in the bug report delinated the problems, and the threads on this rather crappy license on -legal have reached hundreds of messages in length.
Bug 280859. The packager forgot to package the runtime library FFS. 138 days old. Unfixed.
There's a reason why this bug hasn't been fixed, and that reason is bug 289856.
Quoting from the bug:
Hi, my apologies for the late response.
After the original report came in, I had a moment of doubt, and went back to check through the APSL 2.0. I came to pretty much the same conclusion (but I do think there needs to be some kind of review of the DFSG and commonly used new licenses, cf. Matthew's reply, yada yada).
Here's what I'm going to do about it:
* Propose that we remove howl from the archive in its entirety. It is not the most beautiful implementation, and it does not have enormous buy-in throughout the FOSS community so far (only 31 rdepends in sid atm).
* Talk to the Debian GNOME team about how much pain this will inflict on them, offer to buy beer for them, etc.
* Make a public statement about howl's removal, in the hopes of inspiring new, Free implementations to be finished (or written).
"When there's public debate and mass hysteria, that's when the patches roll in." - Michael Meeks
As you can see, the ASPL 2.0 isn't even DFSG free, and moreover no one really is using this package. Expect it to be jetissoned from the archive RSN.
Okay. So, again, why did it take three releases to realize something was wrong?
It didn't.
After potato was released, Anthony Towns implemented testing in an attempt to keep testing in a releaseable state always, so releases could occur more rapidly. That helped, but still didn't really fix the problem.
After woody was released, security support and the installer were serious problems that had stalled the release of woody for quite some time, so more effort was placed into those areas to create a working installer along with a decent security infrastructure. That has helped as well. However, it took quite a while for those to be implemented.
Now that sarge is on the verge of being released, people are analyzing the situation again to try to figure out what else should be done to fix the problem. The Vancouver Prospectus is an attempt to solve what have been identified as the problems for etch.
you and other Debian people have thrown up your hands and said, "augh, look at this mess, it's huge, complex! We can't possibly fix this mess!
No, as you can see above, specific things have been attempted to solve the problem. They haven't succeeded, clearly, but it's not for lack of trying them.
If it's so hard to make a useful distribution, why did we see a veritable explosion of distributions (some of them based off Debian) in the time Debian hasn't released a single stable version?
Distributions based on Debian are rather easy to make, frankly, especially if you're going to standardize on a specific set of packages and only support them. It helps as well if you can throw money at the problem and hire people to work on specific problems. Point in fact, none of the not-for-profit Debian based distributions have every actually released a stable distribution and suported the entire stable distribution for a whole product life cycle. They have different goals for the releases that they make than Debian does, which is quite acceptable for them. [Nothing is stoping anyone from taking a specific version of testing, calling it "stable" and supporting it. The fact that no one has should tell you something.]
Face it, trying to stablize the exact same set of 2000 packages across 11 architectures is valiant but foolhardy. The solution is obvious -- reduce the number of packages and number of archs.
Surprisingly, this actually hasn't been a major blocker for quite some time. If any of the superfluous packages can't get their act together to be in a releaseable state, they are summarily removed from testing.
The actual blocker for the past 6 months or so has been the testing-security support. Before that, it was the fact that we didn't have a working installer.
Question- why did it take, oh, 3 years for them to finally come to terms with the fact that their iguana was turning into a dinosaur? It's like they've all been collectively in denial.
We've not been happy with the time that it takes to release for AGES now. Potato took too long, woody took longer, and sarge is taking it's own time. The symptoms are known, and much lamented. However, the fix for the underlying problems is far less trivial, and so far no one who is actually capable of doing the work has come forward and done whatever needs doing to fix the actual problem (whatever the hell the actual problem actually is.)
I understand the need for stability, but that means you put more effort into QA, not that you sit on your ass because what you've got works.
Perhaps you've been sleeping through the 300,000 bugs that have been filed on packages in Debian, many of which have been fixed? Or maybe it's just that you don't really understand the amount of work that it takes to actually release a stable distribution without RC bugs on all of the architectures that Debian supports?
By forgeting the href, your mistake has doubled your mod points! Good job.
Eh, I'm maxed out already... plus, the href was there, it was just missing a " which caused it to be eaten by the "destroy all evil html" filter.
Re:Vital Data for Your Spamming Company
on
Spammers Sue Spamee
·
· Score: 4, Informative
Ergh, "SpamHaus tidbits" should read: SpamHaus has a few interesting tidbits about this guy.
Vital Data for Your Spamming Company
on
Spammers Sue Spamee
·
· Score: 5, Informative
Just a quick look through the atriks (yes, they're "at risk") website shows a number of interesting "products".
My personal favorite, the "Atriks Personal Domain Owners with Credit Cards" Database.
7,000,000+ consumers have registered a domain for their own personal use and have created Web sites that share everything from jokes to family pictures. A key part of their registration is supplying credit card information, resulting in a file with all major credit card selects available.
Unless you've been sleeping for the past 10 years, this means harvesting whois records (against the ToS) and using them to spam people.
SpamHaus tidbits.
Slashdot Mirror
Surprisingly, people in autopackage's target demographic probably would complain about autoconf... but regardless, the question was how will autopackage deal with an ABI conflict (lets say the gcc-3.3->gcc-3.4 one) between itself and a library it wants to dynamically link with at runtime. Seems to me that you're going to end up with the same sorts of package incompatibilities between distributions that autopackage was supposed to solve. What you focus on isn't the point; the issue was that dealing with the above will (most likely) require you to deal with a whole host of things which are decidedly not "desktop applications."
In any case, best of luck. Just don't expect distributions to be willing to support people who have installed packages using autopackage. [And don't be surprised either if distributions speak actively against the use of autopackage.]
Right, and what exactly is autopackage going to do about these dependencies once it has found that they don't match up? Use LD_PRELOAD and have multiple copies of system libraries in place instead? Oh wait, autopackage is for "desktop packages only".
Of course, all of that isn't to say that autopackage may not do something useful in the future, but it sure looks like some of the fundamental problems of developing and distributing packages which other packaging systems have already dealt with still remain to be solved.
In any case, if you don't believe me, see what Scott Remnant has had to say on the matter (he's currently the dpkg maintainer, so he at least is passingly familiar with the issues surrounding a packaging format.)
This is such a frequently asked question that there's even a faq in the documentation that is distributed in almost every single perl distribution.
perldoc -q 'hide the source'
If that's not simple enough, then see the thread on perlmonks.org about it.
If you still think that obfuscating the source code is going to gain your company anything, then I doubt anyone really wants to see your code at all. (You don't happen to work for Blackboard, do you?)
The tools are all there; jump in and start.
Who cares what the release is numbered anyway? Call it pi if it makes you happy.
- MIT
- GPL (maybe LGPL)
Anything else risks your license being incompatible with large swaths of software (in the linking sense) and possible failing the DFSG. Moreover, using uncommon licenses means that you're more and more on your own for figuring out what they mean.You can get rudimentary clotting with two proteins. Fibrinogen, and ICAM. Obviously to any molecular biologist, these two proteins have very important functions in any relatively large organism. The latter is one of the intracellular adhesion molecules that is reponsible for the adherance of cells to basal lamina amongst other functions. Why is that important you ask? Consider what would happen if your epidermis came unglued easily from your basal lamina: blisters on all of your joints. (Yes, people who have mutations in these various receptors do have blisters on most joints.)
So clearly, one of the proteins that functions quite elegantly in clotting is quite important in other functions of the organism, and a similar protein would have to be present early on in order for single celled organisms to clump together to form a multicellular organism.
As for the second protein, fibrinogen, it's actually quite simple. You stick a whole bunch of RGD interspersed with spacing regions, and you can get a reasonable approximation of fibrinogen. [Obviously, the early multicellular organisms would also have had to have expressed something for ICAM to bind to as well, so they would have been making a similar membrane bound protein quite early on.]
Finally, before trotting out examples of how specific proteins don't serve "ANY OTHER PURPOSE" it would be quite helpful to list exactly which proteins you are refering to, and to have done some preliminary thinking on your own to propose a method in which those proteins could have arrisen.
[If someone wants to check the possibility that the program I've outlined here actually occured, you can quite easily track fibrinogen and ICAM homologues through various organisms that have been sequenced (the C. elegans->drosophila->human comparison should be illuminating) to see just how ICAM and fibrinogen could have been derived from those present in early organisms.]
The thread that discussed the APSL version 2.0 is here
Unfortunatly, there isn't a particularly good sumary of the problems with that license in the thread, if for no other reason than the thread goes on for a few hundred messages. The reason why I posted only the message from the bug is because Steve had actually sumarized the issues relatively well. As far as whether or not the license fails the DFSG, the debian-legal list never officially closes a question even when a summary is made. If new information is brought forward, anyone can revist an old question.
If you're still having a hard time understanding what actually occurred in this case, feel free to e-mail me, as holding a discussion in a weeks old slashdot thread is kind of annoying.
Now, if you want to argue that WN and Web1913 have got it wrong and that infinite should only apply in the mathmatical sense, well, I suppose you've got a bit of work on your hands to convince a large number of people who are quite capable of dicerning between the same word used in two different ways. (Note as well that we're talking about countable in the "I can physically count these things" sense, not in the "Aleph Null" sense.)
Perhaps he's just managed to read the Affero General Public License v1 and has decided that that's the way that the GPL v3 is going to look? But apparently he hasn't already read the coverage of this rather crappy license that debian-legal gave in 2003 and then informed the FSF (and RMS), explaining that it couldn't possibly be DFSG Free, let alone satisfy the 4 freedoms?
Oh, right. Must not have actually checked all that out. Gee, does Mike Olson even use the GPL at all? Why would he be reviewing it anyway? Well, lets see: hrm... this sure looks like the 3 clause BSD license to me. Yerp. No GPL in sight at all. Ok, so someone who doesn't even use the GPL, (to my knowledge) isn't a lawyer, and isn't a prominent member of the copyleft side of the Free Software movement is reviewing a license that no one else has seen?
I mean, I can understand slashdot editors missing this bit of trivia in their rush to approve/reject a story... but surely Michael Singer at internetnews would have bothered to actually check if Mike Olson was the "insider" he was claiming himself to be?
- The copyright license is terminated if you attempt to defend your patent
rights against Apple.
- The license requires you to publish any local modifications if you deploy
public services based on the Covered Code, which discriminates against a
field of endeavour.
- The license includes a choice of venue clause forcing all licensees to
accept the jurisdiction of the Northern District of California, which is
discriminatory against persons located outside this district by exposing
them to unequal legal expense.
(quoted directly from 20050120093050.GF9785@mauritius.dodds.net)While it's possible that you disagree with the conclusion that was reached by Debian, to claim that the license wasn't properly discussed or that the problems were just vaguely hinted at is rather irresponsible, considering that the second message in the bug report delinated the problems, and the threads on this rather crappy license on -legal have reached hundreds of messages in length.
Quoting from the bug: As you can see, the ASPL 2.0 isn't even DFSG free, and moreover no one really is using this package. Expect it to be jetissoned from the archive RSN.
After potato was released, Anthony Towns implemented testing in an attempt to keep testing in a releaseable state always, so releases could occur more rapidly. That helped, but still didn't really fix the problem.
After woody was released, security support and the installer were serious problems that had stalled the release of woody for quite some time, so more effort was placed into those areas to create a working installer along with a decent security infrastructure. That has helped as well. However, it took quite a while for those to be implemented.
Now that sarge is on the verge of being released, people are analyzing the situation again to try to figure out what else should be done to fix the problem. The Vancouver Prospectus is an attempt to solve what have been identified as the problems for etch.
No, as you can see above, specific things have been attempted to solve the problem. They haven't succeeded, clearly, but it's not for lack of trying them. Distributions based on Debian are rather easy to make, frankly, especially if you're going to standardize on a specific set of packages and only support them. It helps as well if you can throw money at the problem and hire people to work on specific problems. Point in fact, none of the not-for-profit Debian based distributions have every actually released a stable distribution and suported the entire stable distribution for a whole product life cycle. They have different goals for the releases that they make than Debian does, which is quite acceptable for them. [Nothing is stoping anyone from taking a specific version of testing, calling it "stable" and supporting it. The fact that no one has should tell you something.]
The actual blocker for the past 6 months or so has been the testing-security support. Before that, it was the fact that we didn't have a working installer.
You're probably refering to d-i which does have snapshots which get updated every now and then, but it itself is updated all the time.
Ergh, "SpamHaus tidbits" should read: SpamHaus has a few interesting tidbits about this guy.
My personal favorite, the "Atriks Personal Domain Owners with Credit Cards" Database. Unless you've been sleeping for the past 10 years, this means harvesting whois records (against the ToS) and using them to spam people. SpamHaus tidbits.