> 2. The problems we have had at Franz Inc with Linux has to do > specifically with signal handling, and even more specifically > with reading and changing the context in order to vector off to > lisp interrupt handlers, and, for example, to return a value from > the unbound-variable handler to the specific register in inline > code in which received the unbound value (see example, below). > If another lisp implementation or any other program doesn't do > this kind of thing with trap handlers, then it will never see the > kind of difference that we've seen between kernels.
Hi, I am curious to know if doing "this kind of thing" and the consequent dependence on a distribution's (or kernel's) signal handling peculiarities is unique to Franz' implementation. Do Xanalys, CMUCL, and other Lisps also have this problem, or do they avoid it somehow (and if so, how).
If this problem is unique to Franz, what is the benefit and bottomline from the programmer's (as opposed to language implementor's) point of view, compared with other implementations which "sidestep" it (assuming "sidestep" is the right word).
For example, is there a correctness benefit, in that as a result of doing "this kind of thing", the Franz behavior is able to conform strictly to the language standard in such and such situation, whereas Xanalys or CMUCL or others do not, or may not necessarily, or may not always?
Anyway, I guess this thread has scared me [us] away from RedHat. It sounds as if, for those of us without the expertise or willingness or time to deal with RedHat problems, or the willingness to use obsoleted distribution versions, the best common denominator to run all of the 3 Lisps are FreeBSD 4.x and, on the Linux side, the latest Debian, and perhaps the latest SuSE (for installation ease).
Hopefully, Allegro won't have any problems with those, even though Debian and SuSE aren't officially "supported". I would dread getting those SIGSEGV violations that I see being reported here every now and then... (Lisp was supposed to free us from that sort of low-level error, where you don't have a clue as to what hit you, no?)
ibprati...@yahoo.com (Pratibha) writes: > Duane Rettig wrote > > If another lisp implementation or any other program doesn't do > > this kind of thing with trap handlers, then it will never see the > > kind of difference that we've seen between kernels.
> Hi, I am curious to know if doing "this kind of thing" and the > consequent dependence on a distribution's (or kernel's) > signal handling peculiarities is unique to Franz' implementation. > Do Xanalys, CMUCL, and other Lisps also have this problem, > or do they avoid it somehow (and if so, how).
CMUCL and SBCL both use signals in (what appears from Duane's description to be) a similar way to ACL. For example, in the Linux/Alpha SBCL port, internal errors ("function does not exist", that kind of thing) will run something like (from memory, this may be wrong)
call_pal bug_chk byte 10 byte foo,bar,baz,quux
where 10 is the error code and the following bytes are arguments to the trap handler. This will cause the kernel to signal the process with SIGTRAP; becaause we set up our sigtrap handler with the SA_SIGINFO flag, it's called with a third argument containing a ucontext structure, which has copies of the registers and the program counter and similar things at the time of the trap.
(Why not use the normal bpt instruction? Because we're already using that for breakpoints and it looked painful to change all the relevant bits to have it serve both purposes. It's possible that we revisit that decision in future, though, because I don't know how much of a guarantee there is that newer kernels and newer PALcodes (BIOSes, more or less) will continue to give us a user-level trap for bugchk)
After we're done handling the trap we need to resume execution at the code following those data bytes, and we expect to be able to do this by modifying the program counter in the ucontext that we were given. We don't have coping strategies if the third argument is something else, but consider
- SBCL is comparatively new and probably has never even been tried on pre-2.2 kernels.
- It still doesn't work with the kernel/libc combination on the Sparc we have access to, which doesn't appear to support SA_SIGINFO at all. An upgrade may fix that.
(Actually, if anyone knows for certain what Linux/Sparc kernel versions do support SA_SIGINFO, Christophe Rhodes would probably be quite happy to hear from you)
- It was a problem with PPC as well, but that went away when I moved from kernel 2.2.aged to 2.4.recent, and at the present rate of progress a PPC SBCL is unlikely to be usable before practically everyone is running 2.4 anyway. So, it could also have been fixed in later 2.2 kernels, but I haven't investigated further
So, yeah. If we tried to support the range of systems that ACL does, we'd have similar problems. As it is, it's free software. If it breaks, you get to keep both pieces ;-)
Actually, I've just thought of another example of needing to modify the register contents - calling the garbage collector from interrupt context. When the GC moves objects around, it needs to update the pointers to them - if some of those pointers are in registers, we'd better update those too ...
cbbro...@acm.org writes: > Arguably the BSD folks have an even better scheme, with their "make > world" approach, combined with "Ports"; you can pull arbitrary > proportions of your system out of public CVS archives, and recompile > it all locally, which means that you can be _sure_ that your > libraries all match.
Of course, I'm sure you know that you can 'apt-get source foo' and build your own packages that way. I'm not sure how ports is better. From what I've heard is pretty much the same as apt.
> But everybody's too proud of their own existant systems integration > efforts to toss it out and adopt someone else's...
I'm not sure what this statement means. I personally wrote the install script for our product. It was easier to do that than use existing package formats. The problem is that I didn't want to have to do rpm and deb and pkg (on solaris). It was much easier to just write install.pl and put it in the tarball. It's not that I'm particularly "proud" of my install.pl. It's just less effort. -- (__) Doug Alcorn (mailto:d...@lathi.net http://www.lathi.net) oo / PGP 02B3 1E26 BCF2 9AAF 93F1 61D7 450C B264 3E63 D543 |_/ If you're a capitalist and you have the best goods and they're free, you don't have to proselytize, you just have to wait.
Doug Alcorn <la...@seapine.com> writes: > cbbro...@acm.org writes: > > Arguably the BSD folks have an even better scheme, with their > > "make world" approach, combined with "Ports"; you can pull > > arbitrary proportions of your system out of public CVS archives, > > and recompile it all locally, which means that you can be _sure_ > > that your libraries all match. > Of course, I'm sure you know that you can 'apt-get source foo' and > build your own packages that way. I'm not sure how ports is better. > From what I've heard is pretty much the same as apt.
The difference is that the default is to grab sources, and compile them, rather than to _usually_ download precompiled binaries.
The merits are likely to be about threefold:
1. You might use CVS/rsync to update the source trees, which is liable to be a bit more efficient than what Debian does now...
2. You might be able to do some bits of customization on (oh, say) compiler options so that everything would be generated with your favorite bits of tuning.
3. You can be _certain_ that library headers will match _perfectly_, because your system compiled them, rather than being "virtually certain," as is typically the case with binary packages.
The place where #3 is likely to be the most important is with C++ code, where variations in versions of G++ can have really significant effects on whether programs and libraries can correctly interact.
> > But everybody's too proud of their own existant systems > > integration efforts to toss it out and adopt someone else's... > I'm not sure what this statement means. I personally wrote the > install script for our product. It was easier to do that than use > existing package formats. The problem is that I didn't want to have > to do rpm and deb and pkg (on solaris). It was much easier to just > write install.pl and put it in the tarball. It's not that I'm > particularly "proud" of my install.pl. It's just less effort.
The point is _not_ about the packaging of one product; it's of the packaging of whole "distributions."
The point is that the Linux distribution makers have too much invested in their existing code bases to be willing to change things to conform with someone else's approach.
Think of the amount of effort that would be required if (say) Red Hat decided that they were (for the sake of argument):
a) Going to follow LSB in all respects, and so had to move all sorts of bits of the system around, and
b) Replacing RPM with DPKG.
That would be quite a lot of work.
Throw in that doing this would be an admission that their "old ways" were inferior - that loss of face would _not_ sell well at the shareholders' annual meeting. -- (reverse (concatenate 'string "moc.enworbbc@" "enworbbc")) http://www.cbbrowne.com/info/nonrdbms.html :FATAL ERROR -- ERROR IN USER
cbbro...@acm.org writes: > The merits are likely to be about threefold: > 1. You might use CVS/rsync to update the source trees, which is > liable to be a bit more efficient than what Debian does now...
Debian works fine with CVS/rsync'ing the source tree. The only problems may occur when the debianization patch has conflicting chunks with the new source.
> 2. You might be able to do some bits of customization on (oh, say) > compiler options so that everything would be generated with your > favorite bits of tuning.
This is easy with debian. I export CFLAGS in my shell init script, and when I apt-get -b source foo, it compiles with those CFLAGS
> 3. You can be _certain_ that library headers will match _perfectly_, > because your system compiled them, rather than being "virtually > certain," as is typically the case with binary packages.
Yes, this is what happens when you compile a .deb from source. Also, debian is a single distro, so all the stuff in it works with everything else unless there has been a binary ABI change. In that case, just recompile the package and you're set.
-- -> -/- - Rahul Jain - -\- <- -> -\- http://linux.rice.edu/~rahul -=- mailto:rahul-j...@usa.net -/- <- -> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <- |--|--------|--------------|----|-------------|------|---------|-----|-| Version 11.423.999.220020101.23.50110101.042 (c)1996-2000, All rights reserved. Disclaimer available upon request.
* Rajappa Iyer | Not trying to start a Linux vs. FreeBSD flamewar [...]
I shall attempt to keep that in mind.
| Contrast this to the number of combinations that an ISV may have to deal | with a Linux distribution. The base system is a (IMHO hodge podge) | collection of independently maintained packages. It doesn't matter how | good your packaging system is: you cannot precisely define the | environment unless you specify the version numbers of several packages.
Nice try with yet more FUD, though. Debian delivers exactly as well-defined releases as FreeBSD does. 2.2r3 is the current release.
FreeBSD folks need to figure out that while they have a definitve edge compared to the worst Linux distributions, that does not mean they have that an edge compared to the best Linux distributions. Why anyone would want to compare themselves to anybhing _but_ the best is beyond me. I guess it is the only way some people _think_ they can win, at least until someone points it out to them, but from what I have seen of FreeBSD, it is a worthy competitor even for the best of the Linuxes and should not have had to resort to such game-playing.
/// -- Norway is now run by a priest from the fundamentalist Christian People's Party, the fifth largest party representing one eighth of the electorate. -- The purpose of computing is insight, not numbers. -- Richard Hamming
Rajappa Iyer <r...@panix.com> writes: > Fact: each individual system component in Debian is individually > upgradeable.
Isn't it in FreeBSD, as well? What if there was a security hole in some arbitrary part of the distribution? Wouldn't you upgrade it? Individual system components in Debian are updated for the same reason that components in FreeBSD are updated. Neither of them would update the major version of a component within a stable release.
> Fact: individual system components in Debian are periodically updated > even within the same release.
As they are in FreeBSD. (The "RELENG_4_4_0_RELEASE"-branch, for example, and I think you also get binary package-updates now.)
> point where (the dynamically linked) /bin/sh stops working etc.
(You're right here, though, /bin- and /sbin-binaries should be statically linked. I think it's strange that a distribution which do so many other things right, that they've gotten this basic thing wrong.)
* Rajappa Iyer | Fact: each individual system component in Debian is individually | upgradeable. | | Fact: individual system components in Debian are periodically updated | even within the same release. | | Fact: installing some package may result in an upgrade of another package. | | So tell me, how exactly can you tell with any degree of certainty what | 2.2r3 consists of without an inventory of all the relevant installed | packages?
All these findings of facts hold for FreeBSD, too, do they not? Since you claim that you can say what you say for FreeBSD, the onus of proof remains on you to show it to be true for FreeBSD. When you have shown that, you have also shown that it is true for Debian, because the same conditions hold for Debian. In other words, I fail to see what your argument really is, here. It looks like so much useless FUD.
| Perhaps you've been lucky enough to never have your Linux system hosed to | the point of having to edit the package database manually (due to poorly | specified package dependencies and conflicts), or getting burnt with libc | changes to the point where (the dynamically linked) /bin/sh stops working | etc. but I haven't been as lucky.
Oh, geez, another burn victim with another sob story. Just get over it! Painful experiences that damage your ability to deal with a fast-changing reality are just holding you back. Memory is a wondeful thing with us humans, but not when you remember things that change under your feet. If you choose to give priority to your painful memories over tracking the developments that invalidate them, that should be a personal choice the consequences of which should not be levied on anyone else.
Only if you have reason to believe that people are evil and do harmful things on purpose, such as is obviously the case with Microsoft, can you rely on prior experience to predict the future. Just because you had a painful experiernce does not mean that somebody else meant to hurt you _and_ will continue to hurt you if presented with the opportunity again. These are disjoint judgments. Far too often, people who have been hurt cannot see beyond their pain, but one of the most important, if not _the_ most important time to exercise your observational skills to the fullest and require the utmost of your intelligence is when you experience pain, because it is an indication that _something_ is wrong. Fortunately for us humans as a species, that is just how the cognitive system works in the psychical reality, but we seem to nee to be taught to do it in the psychological reality we create for ourselves. The biggest intellectual mistake you can make is to make up a conclusion from what looks like convenient enemies at the time it hurts and then never re-examine it -- such is the very recipe for intellectual dishonesty and any disaster that follows is easily trackable to that one decision not to think while you experienced something painful. Unfortunately, people are effectively taught to disconnect their thinking process while suffering pain, and it is somehow legitimate in most Western societies to react irrationally to something painful long after the pain itself is gone. This is just a bad cognitive process and needs to be fixed, because it causes such things as unfair characterizations of the work of other people, of other people as such, of groups of people, of cultures, of countries, etc, and before you know it, some monosyllabic president goes to war because he is pissed off.
/// -- Norway is now run by a priest from the fundamentalist Christian People's Party, the fifth largest party representing one eighth of the electorate. -- The purpose of computing is insight, not numbers. -- Richard Hamming
* Rajappa Iyer | The problem that I have run into in the past with Debian is that some | application upgrades trigger an update in the base package as well. On | occasion this has resulted in changed version for the component even on | stable releases.
Some of us are able to discern the subtle difference between normal and abnormal situations before we base a blanket judgment of a system on our painful experiences. Computers do not generally say they are sorry, but that does not mean the person behind the computer's action is not. In fact, most computers are far sorrier than their humans, but they do not have the power to express their feelings, they just commit suicide when they are too depressed. This explains the frequent "crashes" on Windows, but I digress, sort of.
/// -- Norway is now run by a priest from the fundamentalist Christian People's Party, the fifth largest party representing one eighth of the electorate. -- The purpose of computing is insight, not numbers. -- Richard Hamming
* Rajappa Iyer <r...@panix.com> | In other words, no matter what you do under /usr/local, /usr does not get | affected. For Debian, this is not true.
I am so relieved to see that you have no idea what you are talking about. Debian does not place any packages in /usr/local. If you now blame the package system for its ability to require packages or versions you have not instaleled, you need to ask yourself whether you actually asked for the right package for your system or went for that bleeding edge version. If you did the latter, the problems you will run into are not caused by any package system whose goal is to maintain sanity on your system: You have brought the insanity. If the system actually _survives_, but needs packages _outside_ of the distribution, which _you_ have to tell it how to get from somewhere else, that is a credit to its design. Surviving abuse by idiots is a good thing. Having said idiots not grasp this is unfortunately the downside of not causing idiots to harm themselves when they do really stupid things. That way, they never learn, but if they get hurt, they tend to blame the wrong guy, anyway, so maybe the only solution is to reject idiocy outright, but this generally gets in the way of the work of intelligent, careful people.
| You could install an application package A (that would normally go into | /usr/local in FreeBSD) which requires an upgrade to libc or libtermcap or | ld.so (all of which have happened to me.)
And from where would you get this package and the upgraded versions? _NOT_ from the Debian archives for the release you have installed. You _must_ have tweaked /etc/apt/sources.list to get the behavior you fault the distribution for. This is typical of people who lack relevant clues.
| In other words for, say, FreeBSD 4.3, you can definitively state the | version numbers of various libraries whereas for, say, Debian 2.2 it | depends on the exact mix of packages that have been installed.
You are factually wrong on this count. Please demonstrate the situation you have observed and falsely accuse Debian of having caused, so maybe somebody who pays attention to the details you have ignored can explain back to you why you have made up your mind about blaming the wrong guy.
| FUD implies a vested interest. I have none.
Then stop presenting false accusations. Failure to do so _constitutes_ an agenda. And anyone who _had_ vested interests would say he had none.
| <standard Erik rant snipped>
Geez. How mature. But it appears that the standard Rajappa Iyer rant is one of lying and false accusations. We shall remember this and not give you a chance to change or improve because you do not grant that to others.
The number of FreeBSD "advocates" who need to falsely accuse various Linux systems of problems they do not in fact have, is alarming. I am not sure what cause this need to lie and misrepresent the competition is, but it colors my impression of FreeBSD that so many of its adherents need to engage in such tactics to make FreeBSD appear an alternative for people who do stupid things and do not realize their culpability.
/// -- Norway is now run by a priest from the fundamentalist Christian People's Party, the fifth largest party representing one eighth of the electorate. -- The purpose of computing is insight, not numbers. -- Richard Hamming
Rajappa Iyer <r...@panix.com> writes: > Erik Naggum <e...@naggum.net> writes:
> > * Rajappa Iyer > > | Fact: each individual system component in Debian is individually > > | upgradeable. > > | > > | Fact: individual system components in Debian are periodically updated > > | even within the same release. > > | > > | Fact: installing some package may result in an upgrade of another package. > > | > > | So tell me, how exactly can you tell with any degree of certainty what > > | 2.2r3 consists of without an inventory of all the relevant installed > > | packages?
> > All these findings of facts hold for FreeBSD, too, do they not?
> No and here's why: the base system in FreeBSD is part of the OS src > tree. The base system does not get updated as a result of adding a > package; it gets updated only as a result of updating the base system.
The same is true of Debian. Since the only source of base packages is the distribution, unless there are upgrades to the distribution (which only happens through new releases), there is no way a base package can get updated, period.
> In other words, no matter what you do under /usr/local, /usr does not > get affected. For Debian, this is not true. You could install an
/usr/local is completely outside the realm of package managing systems on Debian (and any other LSB-compliant distribution), so whatever you do under /usr/local is up to you. And all the non-base packages (the stuff that is comparable to the packages system of FreeBSD) of the stable distribution only depend on other packages in the stable distribution, hence they will not even request an update of base-packages within a release. And even if they did, that request would fail, and no updating would happen, because there is no source for the new base packages to come from!
> application package A (that would normally go into /usr/local in > FreeBSD) which requires an upgrade to libc or libtermcap or ld.so (all > of which have happened to me.)
As said above, installing packages from a certain distribution onto a system of that distribution will never require such updates. If it did, this would be a bug, not something done by design. And 3rd party applications/packages can of course require a newer libtermcap than is installed on your system. But even in that case no automatic upgrade to the base packages can happen, since there is no source from which newer packages can be installed. So unless you upgrade to a new distribution (which you can do incrementally, if you want that), again no changes in base-package versions happens.
And the situation is identical in FreeBSD, if a 3rd party application needs newer versions of some base packages, the only recourse you have is upgrading to a newer release.
> In other words for, say, FreeBSD 4.3, you can definitively state the > version numbers of various libraries whereas for, say, Debian 2.2 it > depends on the exact mix of packages that have been installed.
That is untrue. Take a look at the base section of Debian 2.2r3, and you will see exactly what packages can be installed, with what version numbers. And you will find those exact versions on all of my Debian 2.2r3 machines.
Of course, if you add unstable or testing to your apt-sources, then upgrades as you described can and do happen, since by so doing you are indicating that you want to (incrementally) update to the new distribution, and hence installing an application package from that new distribution will of course often require matching base-package versions, and hence automatic updates will happen.
But this is by your own choice of incrementally updating to the new distribution. If you could do this in FreeBSD, then the same "problems" would apply. Since FreeBSD, to the best of my knowledge, doesn't allow incremental upgrading at this granularity-level, associated problems of course don't apply to FreeBSD. But that's hardly an advantage of FreeBSD, since Debian distributions can just as easily be upgraded non-incrementally, (that's what apt-get dist-upgrade is for).
Furthermore complaining about stability problems of unstable or testing distributions seems hardly intelligent behaviour. Stay with stable distributions, upgrade when they are released/when you are ready, and I don't see (or have experienced) the problems you are talking about (and I maintain lots of Debian based machines for many, many years).
Now if you had complained about the larger frequency of incompatible changes in Linux base-components (such as glibc, etc.) than on FreeBSD, I would have been sympathetic. But blaiming the problems on the packaging/distribution system seems strange.
Regs, Pierre.
-- Pierre R. Mai <p...@acm.org> http://www.pmsf.de/pmai/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein
* Rajappa Iyer wrote: > FreeBSD maintains a distinction between the base system that is part > of the FreeBSD distribution and third party applications. This is > crucial to the stability of the system since third party applications > cannot affect the main distribution. This is not the case (by design) > of Debian or Red Hat.
However, Debian (by design) has a mechanism which ensures a similar level of stability.
--tim (a FreeBSD user when I have time, and a BSD user since 4.1)
Rajappa Iyer <r...@panix.com> writes: > Tim Bradshaw <t...@cley.com> writes:
> > * Rajappa Iyer wrote:
> > > FreeBSD maintains a distinction between the base system that is part > > > of the FreeBSD distribution and third party applications. This is > > > crucial to the stability of the system since third party applications > > > cannot affect the main distribution. This is not the case (by design) > > > of Debian or Red Hat.
> > However, Debian (by design) has a mechanism which ensures a similar > > level of stability.
> I'm unfamiliar with this mechanism. Could you or someone else > elaborate? Email is fine.
Run "stable" and you get security fixes as needed. Run "unstable" and hope things work out.
//Ingvar (I think "testing" is somewhere in-between, stability-wise) -- When it doesn't work, it's because you did something wrong. Try to do it the right way, instead.
Rajappa Iyer <r...@panix.com> writes: > "Pierre R. Mai" <p...@acm.org> writes: > > > application package A (that would normally go into /usr/local in > > > FreeBSD) which requires an upgrade to libc or libtermcap or > > > ld.so (all of which have happened to me.) > > As said above, installing packages from a certain distribution > > onto a system of that distribution will never require such > > updates. If it did, this would be a bug, not something done by > > design. > But that's precisely the point of my objection: a bug in the package > specification can result in changes to your base system. I consider > this to be a systemic flaw that is endemic to the approach of > package-izing the base system.
Fine; call it a "systemic flaw."
How many times have you been affected by this "systemic flaw?" How many times have you observed this "systemic flaw" in action?
It's _not_ something that is commonly seen outside of the "unstable" and "testing" environments, and those are environments that involve some specific and conscious risks.
> > And 3rd party applications/packages can of course require a newer > > libtermcap than is installed on your system. But even in that > > case no automatic upgrade to the base packages can happen, since > > there is no source from which newer packages can be installed. So > > unless you upgrade to a new distribution (which you can do > > incrementally, if you want that), again no changes in base-package > > versions happens. > This has not been true in my experience. If this has changed in the > past couple of years, then I stand corrected.
_What_ has "not been true in my experience"?
- That automatic upgrade could not happen?
I see this precise scenario happen quite regularly, thank you very much; I have the "Galeon" web browser installed, each version of which depends on a particular version of "Mozilla."
Someone may update Mozilla; I don't pull that update until Galeon has been brought up to date, at which point _both_ packages come in to be upgraded at the same time.
It might be irritating not to have the latest version of Mozilla at some points in time; the dependancy system has been nicely maintaining the constraint that Galeon and Mozilla be upgraded in sync with one another.
- That upgrades of base packages won't take place spontaneously?
If there's no new version of the libncurses5 package out there, then _obviously_ there can't be any upgrade done to it.
At one point [obLisp reference], I tried adding some of the CCLAN packages to a Debian/stable system. Somewhat unfortunately, but not particularly surprisingly, I couldn't even so much as add in CLISP from CCLAN without forcing it in as a source package, and then pushing it _hard_, because parts of CCLAN depend on LIBC versions that aren't available in "Debian/stable."
Note that the attempt to install CLISP from CCLAN _attempted_ to request that a newer version of LIBC be installed. THAT COULDN'T HAPPEN, because no newer version of LIBC was available in Debian/Stable.
If you're going to claim that this isn't true, I suggest you point out some specific instances. The above certainly reflects how the dependency system is _designed_ to work; it also reflects how the dependancy system is _observed_ to work.
> > Furthermore complaining about stability problems of unstable or > > testing distributions seems hardly intelligent behaviour. > So many assumptions.
The stable versions don't change very much, so it would seem quite surprising for someone to observe significant stability problems with the stable release.
Feel free to elaborate with _specifics_, if you can, although that would fit better into the context of some other newsgroup. -- (reverse (concatenate 'string "moc.enworbbc@" "enworbbc")) http://www.cbbrowne.com/info/languages.html Editing is a rewording activity. -- Alan Perlis [And EMACS a rewording editor. Ed.]
cbbro...@acm.org writes: > At one point [obLisp reference], I tried adding some of the CCLAN > packages to a Debian/stable system. Somewhat unfortunately, but not > particularly surprisingly, I couldn't even so much as add in CLISP > from CCLAN without forcing it in as a source package, and then > pushing it _hard_, because parts of CCLAN depend on LIBC versions > that aren't available in "Debian/stable."
I think the cCLan-people would appreciate that you report this either as a bug in the BTS or on the mailing-lists.
> Note that the attempt to install CLISP from CCLAN _attempted_ to > request that a newer version of LIBC be installed. THAT COULDN'T > HAPPEN, because no newer version of LIBC was available in > Debian/Stable.
I think cCLan has currently tracked sid/unstable, but it would probably be much appreciated if people with potato/stable reported their issues and possibly contributed some time to test packages for potato/stable. Until people with potato/stable can test these things and report back the cCLan-team cannot do much. However, I'll add a notice on the web-page that only sid/unstable is recommended.
However, I'd exploit the chance to say that cCLan now consist of 41 packages of lisp-code for x86, and 36 for powerpc and alpha. All of them should be trivial to install and get working out-of-the-box. Progress is limited to what people contribute. Even if you don't know how to make such packages but have lisp-code suitable for a package (or two) please contact the cclan mailing-list and you might get help. Lisp to the people! :-)
(Yes, the goal is to make this work for other systems than Debian, but the people doing the work now use Debian, so they need help from other people who want a cool distribution-system for Common Lisp code)
-- ------------------------------------------------------------------ Stig E Sandoe s...@ii.uib.no http://www.ii.uib.no/~stig/
> However, I'll add a notice on the web-page that only sid/unstable is > recommended.
FWIW, a combination of "testing" and cmucl from "unstable" works fine for me. (or, if clisp & sbcl are enough, just "testing"). that would be safer than "unstable", theoretically at least.
-- I think we might have been better off with a slide rule. -- Zaphod Beeblebrox
Rajappa Iyer <r...@panix.com> writes: > Another time, I think this was an update for XEmacs, a change in > libtermcap ensued which triggered off some conflicting upgrades. This > one didn't hose my system to the point that I was unable to boot to it > without a rescue disk, but I did have to fix the package database by > hand.
Sounds like you changed to unstable without upgrading to it and then blamed debian on the fact that major upgrades in glibc require upgrades in all packages on the system. Note that there is a difference between compiled binaries and source code, so you're comparing apples and oranges.
-- -> -/- - Rahul Jain - -\- <- -> -\- http://linux.rice.edu/~rahul -=- mailto:rahul-j...@usa.net -/- <- -> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <- |--|--------|--------------|----|-------------|------|---------|-----|-| Version 11.423.999.220020101.23.50110101.042 (c)1996-2000, All rights reserved. Disclaimer available upon request.
* Rajappa Iyer | On the contrary, Erik, you are the one that doesn't have a clue.
You admit to being vague because all this is two years old (what have I been saying about your "experiences" and the dishonesty of using stale painful experiences to _continue_ to post negative comments about something?) and that you have no specific examples to back up your claim. I already knew that, but it is good to see that you admit to this.
This leaves us with a very simple, straightforward conclusion: There is absolutely no reason to believe anything you say. You are simply too much of a dishonest person to have any credibility at all. Until and unless you can show us exactly what you did and exactly what happened, your whole set of experiences falls in the category of "idiot operator error". Blame whoever you want, every honest person has to conclude that it was your own goddamn fault. _No_ system can be so fool-proof that a self-destructive, lying, angry fool cannot find something to blame it for.
Only good thing is it was a Linux and not a Common Lisp system that you mistreated so badly that your hatred was misdirected towards Common Lisp. There have been enough dishonest lunatics just like you who have been so angry about their failure to understand what they are doing in Common Lisp that they publish books about it. It is fortunate for Debian that you are unlikely to be capable of such demanding intellectual endeavors.
/// -- Norway is now run by a priest from the fundamentalist Christian People's Party, the fifth largest party representing one eighth of the electorate. -- The purpose of computing is insight, not numbers. -- Richard Hamming
Erik Naggum <e...@naggum.net> writes: > * Rajappa Iyer > | On the contrary, Erik, you are the one that doesn't have a clue.
> You admit to being vague because all this is two years old (what have I > been saying about your "experiences" and the dishonesty of using stale > painful experiences to _continue_ to post negative comments about > something?) and that you have no specific examples to back up your claim. > I already knew that, but it is good to see that you admit to this.
> This leaves us with a very simple, straightforward conclusion: There is > absolutely no reason to believe anything you say. You are simply too > much of a dishonest person to have any credibility at all. Until and > unless you can show us exactly what you did and exactly what happened, > your whole set of experiences falls in the category of "idiot operator > error". Blame whoever you want, every honest person has to conclude that > it was your own goddamn fault. _No_ system can be so fool-proof that a > self-destructive, lying, angry fool cannot find something to blame it for.
> Only good thing is it was a Linux and not a Common Lisp system that you > mistreated so badly that your hatred was misdirected towards Common Lisp. > There have been enough dishonest lunatics just like you who have been so > angry about their failure to understand what they are doing in Common > Lisp that they publish books about it. It is fortunate for Debian that > you are unlikely to be capable of such demanding intellectual endeavors.
Do you do this to embarass your parents?
rsi -- <r...@panix.com> a.k.a. Rajappa Iyer. They also surf who stand in the waves.
Erik Naggum <e...@naggum.net> writes: > The number of FreeBSD "advocates" who need to falsely accuse various > Linux systems of problems they do not in fact have, is alarming. I am > not sure what cause this need to lie and misrepresent the competition is, > but it colors my impression of FreeBSD that so many of its adherents need > to engage in such tactics to make FreeBSD appear an alternative for > people who do stupid things and do not realize their culpability.
I think this is generally true of "advocates". I will sometimes advocate Debian, but I'm not generally a Debian advocate -- I only suggest it to people when I think that they will see a benefit from changing; I don't go around suggesting Debian to FreeBSD'ers, or those running Solaris, without a really good reason. Don't let the loudmouthed FreeBSD advocates scare you away -- it's a really nice system, and I'd guess that most Debian users, if forced to pick a new OS, would go with FreeBSD over another linux distro. I know I would.
One of its biggest advantages over Debian is the fact that they control the kernel. So they're not victim to the whims of the Linux kernel maintainers. "Sure, let's release 2.4.x -- it must be time to, since it's been so long -- any user hopes of a decent VM system, be damned!" So, while my experience with FreeBSD was that it was harder to run a *really* old system, it also wasn't as necessary.
Gonna be using kernel 2.2.x and Emacs 20.7 for a long time more... (Yes, yes, I know I'm posting this from emacs 21 -- I meant for things more important than news :)
-- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
Rajappa Iyer <r...@panix.com> writes: > I updated some applications from the stable platform which required a > new locales package which in turn required changes to libc. There was > a broken conflict in the locales package which caused an incorrect > attempted upgrade to libc and totally hosed my system.
Where did this updated application come from? The packages within one release of Debian _are not_ updated, so I fail to see where this updated application package could have come from.
Remember that your complaint was with base packages changing within one release. They don't, just as application packages don't change within one release.
The system breaking on upgrading to another release is not at issue here.
Regs, Pierre.
-- Pierre R. Mai <p...@acm.org> http://www.pmsf.de/pmai/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein
Rajappa Iyer <r...@panix.com> writes: > > As said above, installing packages from a certain distribution onto a > > system of that distribution will never require such updates. If it > > did, this would be a bug, not something done by design.
> But that's precisely the point of my objection: a bug in the package > specification can result in changes to your base system. I consider > this to be a systemic flaw that is endemic to the approach of > package-izing the base system.
Maybe I don't make myself clear: Even _if_ any such bug existed, and hence upgrades would be required, then they wouldn't happen automatically, because there is no source for those updated packages to come from. Hence installation of the application package will just fail, with a clear error message. You file a bug report, the package gets fixed, and that's it.
Not that I have encountered such a bug in my 6 years of Debian usage in stable distributions (such things happen all the time in unstable, but that's precisely what unstable is for).
> This has not been true in my experience. If this has changed in the > past couple of years, then I stand corrected.
It hasn't changed in the past couple of years, it has always been this way, to the best of my knowledge.
Regs, Pierre.
-- Pierre R. Mai <p...@acm.org> http://www.pmsf.de/pmai/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein
* Rajappa Iyer | Sheesh and you talk about dishonesty!
Smart people understand that personal communication can be employed to change the outcome of an exchange without the possible embarrassment of losing face in public. Idiots think personal communication is the best venue to prove what utter misfits they are. You had an opportunity to regret your behavior that you failed to use, and you got a chance to make up for it, but you continued in your fantastically stupid and hostile ways, simply because you are unwilling to admit to posting negative crap about something based on vague memories of several years ago, which is such an incredibly stupid thing to do that anyone with any brains would have been better off admitting it was not productive, but you choose a very different path, straight to self-destruction. I think you have done enough damage to yourself by now. I hope you enjoy what you fought for.
/// -- Norway is now run by a priest from the fundamentalist Christian People's Party, the fifth largest party representing one eighth of the electorate. -- The purpose of computing is insight, not numbers. -- Richard Hamming
* Rajappa Iyer | Meanwhile, how about explaining your dishonesty in posting email?
What is _dishonest_ about that? And why is that relevant to the fact that you post two-year old vague memories of a painful experience that you want to use to smear Debian unfairly for what looks like a stupid operator error and do not accept that people who have a _very_ different opinion than you do post corrections to your false claims and a different take on it all? Why is it so important to have your false accusations against Debian stand unchallenged? You have failed to come up with the only thing that could redeem yourself: _evidence_. All you now claim is that this is so long ago, you are vague, you no longer remember, etc. Why then is the _conclusion_ still valid? Why do you _still_ believe that Debian suffers the kind of problems you have _attributed_ to it with what looks very much like idiotic prejudice and an enraged ignorance that lashes out in random directions until it find something to attack and then it keeps attacking no matter what the result is. Now you have gone from attacking Debian to attacking me, with equally outlandishly stupid and unfair nonsense. What is _wrong_ with you?
And do you think I am bound by the choices made by a deranged lunatic who chooses to use e-mail to mount such a fantastically moronic personal attack on me? It was _obviously_ meant for public consumption by the very nature of the message. Insults and the like are _not_ private. The person who receives an insult has the _right_ to post it _because_ it is hurtful and damaging if it is _not_ made publicly visible. The only defense anyone can possibly have against using personal communication to harrass and insult people is precisely to post it and make the community aware of the behavior of those who do such things. If you do not want to have the mail you send exposed by people who do not want to respect your desire to keep it private when you clearly do not respect the recipient at all, adjust your behavior accordingly: Do not mail people any insults over which you want to maintain control of distribution. It is that easy.
I really thought you had done yourself in, but just how stupid _are_ you, Rajappa Iyer? Do you think _you_ have right to privacy when you choose to invade people's private mail with unwelcome and insulting messages? You _violate_ people's privacy by doing that, and then _you_ whine when you get exposed? Why? Get a grip on yourself and snap out of your stupid hostility. You are the transgressor here. You lie about Debian, you choose to call people clueless, you refer to other people's concerns over your ways "rants". What do you _expect_? And then you mail people insults? How the hell did you think you could even _believe_ you could get away with that?
I think you actually made a third-party application upgrade to your brain and that the base system got seriously screwed up. Reinstall and reboot!
/// -- Norway is now run by a priest from the fundamentalist Christian People's Party, the fifth largest party representing one eighth of the electorate. -- The purpose of computing is insight, not numbers. -- Richard Hamming
* Rajappa Iyer | The fact that you mis-represented it as mis-sent. A transparent excuse | if there were ever one.
Yeah, that gives you _such_ a great excuse to be outraged, does it not? Never mind that you proved to the whole Common Lisp community what kind of person you are and that you dug your own grave so deep you get to stay there for quite a while, did absolutely nothing to regret your action when you had the chance, and continue to act like a little terrorist in training. Just coughing up some real information about your gripes with Debian is certainly out of the question for someone so stupid as you.
| > [more rabid insanity deleted]
Who do you think wins the most points when you resort to this behavior? Do you think anything I have said about you is considered _less_ accurate?
| You must have me confused with someone who gets intimidated by your | lunatic ravings. So give it a rest and take your medication. And a | refresher course in netiquette.
Amusing. You really have _nothing_ left to argue with, anymore, do you? It is actually quite amusing to watch people self-destruct so thoroughly as you have. And just because you cannot deal with corrections to your stupid negative propaganda against Debian and demonstrations that you base your very strong negative opinions on vague memories and painful experiences so long ago you cannot even remember what they were! You want credibility for so useless negativism? You could have remembered better and provided evidence, but what do you do? You attack me because I ask you for the evidence that you cannot provide and because you know that when you cannot present any evidence at all, you look like an idiot, which I think you actually _are_, since a smart person who looked like an idiot would back down and get back on top of things by admitting his mistakes and learning from people who know better. I do in fact enjoy exposing people like you for what you are, just like I get a personal satisfaction from exposing racism and other forms of prejudice when it runs amuck and causes people to act on stale information and too strong emotions for their intellectual capacity.
But thanks for the good laugh. It always brings laughter to an enjoyable day to find someone incoherently hurling random insults in all directions in what looks very much like the imagery he himself brings up: medicated insanity, suggest that somebody else, but never himself, take courses in netiquette. Whoever taught you, Rajappa Iyer? This is just _too_ funny!
/// -- Norway is now run by a priest from the fundamentalist Christian People's Party, the fifth largest party representing one eighth of the electorate. -- The purpose of computing is insight, not numbers. -- Richard Hamming
