Presumably compatibility. Many Amiga apps would make assumptions about being able to pass structures between tasks (Amiga speak for processes, or rather threads since there is no protection) with pointers into eachothers address spaces and stuff like that.
As for personal politics, Commodore was all about personal politics and bizarre power games... Wish I knew why it was as fucked up as it was - it was one of the most frustrating things about owning an Amiga back in it's glory days: You saw what their techs were capable off, but inevitably Commodore would find a way of messing it up. The mess that was the A4000 and A1200 (the first two models to include AGA) was just one of the last of a long string of ridiculous management screw ups - much better designs than the ones that were launched frequently were almost completed before management pulled the plug and went with something even Frankenstein would have been ashamed of (A4000 for instance).
Re:Is IRC all bad?
on
Is IRC All Bad?
·
· Score: 3, Insightful
Has it not occurred to you that you do encounter people of all the categories you mention above in your daily life? It is just that for the most part, most people have enough social skills to appear as "normal" when dealing with people face to face, and most people who fall in the categories you list would have a very strong interest in keeping this hidden from you in their daily life.
Further, this tells more about you than about the overall "population" of Undernet. You've self-selected who you got in contact with by your choice of channels, by your choice of nick, and by choosing who you talk to. It's perfectly possible to find civilised and "normal" conversations on Undernet, as on most IRC networks. But contrary to the physical world where people with unconvential or perverse fantasies are to a certain extent forced to hide their fantasies, anonymous networks gives them a chance to explore in the open - as a result, if you look you most likely will find.
Another point you need to realise, is that allthough there are many truly disturbed people out there, there's also a great many that just enjoy playing out roles that they in many cases would never dream of living out for real. A significant part of the "nutcases" you've run into on IRC have probably been laughing their ass off from having gotten you to believe what they're writing.
I hope you realise that the reason IPC on Amiga was so fast (and no, it was not "faster than any other kernel to date") was that it was nothing more than an interrupt protected insert in a doubly linked list. You can achieve the same on Unix compatible OS's today by having apps mmap() a memory area and maintaining a linked list of messages for each app. But of course this comes at the cost of less separation of the address spaces unless each pair of apps that wants to communicate set up a separate shared memory map.
As for window refresh, lots of X11 window managers do the same, as can most other OS's, but it was rarely used on the Amiga - most app's did redraw, because letting the OS redraw meant having the OS keep a backing store, which meant wasting memory, which most Amiga programmers detested.
The low latency interactivity of the Amiga had more to do with the task prioritisation, as you mentioned, and the way interrupts were propagated, as well as the extremely low overhead of context switches due to lack of memory management.
All in all, though, I still dislike virtual memory. Even on the Amiga's with MMU, the virtual memory extensions that were written never got popular for the simple reason that they are disastrous to performance.
I'm still amased that something as simple as a mail application today often takes tens of MB, while I'd never have considered using offline readers (for BBS's) in my Amiga days if they used more than a few hundred KB.
Yes, they apps are more capable, but often I wonder how much of the functionality is worth it, and how much of it could have just been provided as plugins/extensions instead, and that I'd never use.
Having swap in RAM defeats the entire purpose of having swap space in the first place.
Several virtual memory management apps were written for the larger of the classic Amiga's and worked fine, but most of the time we made do with a few MB of memory and the lack of a vmm was rarely an issue.
And the separation of church and state is exactly the argument that have been used in France for banning the head scarves. I don't agree with it, but the argument typically goes that conspicuous religious symbols does not belong in state schools because allowing them is an implicit acceptance of religious expression in a setting that is otherwise explicitly protected from it.
To play the devils advocate: If you allow students the freedom to wear religious symbols, then what about other religious practices, such as organized prayer - as long as it is done by the students and not the teachers? What about teaching religious beliefs, as long as it is done by students?
If one want a secular school, then as long as there are people that want religion in schools you will need to draw a line and set rules for what is and isn't an acceptable level of religious influence. This is in many ways not any different than other limitations on freedoms endured by school pupils everywhere - including in the US.
The headscarf ban is too restrictive for my taste, though, and it does seem like it is more intended to make muslims "less visible" than it is to prevent any real religious influence in schools.
Then talk to them and explain that some people might get the wrong idea if they bare their bodies in places where most other people are dressed, unless they have a good reason. Treating them with respect is far more likely to work than trying to sheltering them from something they WILL face sooner or later anyway.
And that is also usually how it is structured in Fedora.
Triggers are useful in more complex cases. Say I have application A and application B. They don't depend on eachother to work, but application A provides additional functionality that application B can make use of if available. Application A is useful without application B and the two may be completely unrelated, so it shouldn't require B. Application B requires configuration data that tells it where to find application A if present, and application A might be retargetable, so it might not be present in a fixed location.
Either you let the user handle the configuration, or you make application A know about application B and provide the configuration data, or you let application B look for application A whenever it could make use of it, possibly using the package manager to look for the location of the files it needs, and ignore it if it isn't present, or you use triggers to let application B's configuration be upgraded when application A is installed.
In a situation like this I'd argue that triggers might be the cleanest solution.
But it's not as if they do anything you can't do in alternative ways.
Rpm also allows you to list packages that conflicts. So that leaves suggests and recommends. I'm not so sure that is functionality that adds a net benefit (since it could easily have been provided in the documentation), though at last someone have actually managed to suggest something Debian packages has that RPM's doesn't (to my knowledge anyway).
The PROBLEM is when an app is packaged via RPM and it REQUIRES a specific app that should have been sufficiently abstracted so that any server of that type could fulfill it.
As I've pointed out before, and as others have pointed out, this has nothing to do with the package format. RPM supports it. If you have a problem with a particular RPM based distro, then fine, but it's annoying when you keep on bashing RPM for something that has nothing to do with RPM.
I've already mentioned some fairly large applications that use this (Sendmail, Exim, Postfix all providing "smtpdaemon") for Fedora, but I stand by what I said about it being of relatively limited used simply because there are relatively few cases where applications are suitably interchangable that it makes sense.
You've not said anything to refute that other than make a loose claim that Debian use it a lot. Why don't you provide some examples?
The version checker could check which individual files need to be downloaded and download and install only those.
So in other words what you want is dependency resolution, as provided by Apt, Yum, Urpmi and several others. What features of Apt for instance is it you think you need? So far what you have mentioned is stuff that is already there, and in use, by most modern distros. And if you want application local libs, you can trivially do that by using pre-install scripts to pull down additional packages.
As for Loki games, I've reinstalled several Loki games several times through many major distro updates, without any problems. Whenever you find apps where you do run into problems, they can usually be solved by having multiple versions of the RPM installed at once. RPM supports it. Some tools supports it better than others. So far, I've heard very few users actually bring this up as anything but a hypothetical situation - it's a concern that mostly affects closed source apps, and few Linux users rely on old closed source Linux apps as they tend to be left in the dust fairly quickly.
However, I challenge you to point out a single feature of the current package management systems that prevent you from shipping whatever set of dynamic libraries you want with it, if you do want to go to the trouble of copying how it's done on Windows. If what you want to do is treat the package manager as an archiver with a method to run a script, you can.
So what are you complaining about? As I've pointed out, the package management systems supports what you have suggested, so should I assume what you're complaining about is the package maintainers who apparently doesn't agree with you?
For an example, think virtual webhosting. Most hosting companies will sell you either a colocated box where you get root, or a shared hosting account where you don't. Some of them will offer UML or vservers alternatives where you get root on a virtual box. Xen allows the same thing, but faster than UML or VMWare, and with more total separation than vservers.
Actually, I have twice now upgraded Fedora Core boxes by changing my APT repository and doing a dist-upgrade.
I did the same from Redhat 6.2 straight to 7.3 once (again with apt-get). THAT was painful, but it worked (after I reran apt 3-4 times).
It's been getting steadily better, but there's still a lot of work left before I'd recommend anyone to try it without a backup, or a bootdisk and a lot of patience:)
Regardless of your hypothetical "smart version checking", I'd rather not have every application that needs all the Gnome libs, for instance, ship with the 11MB of stuff I already have that makes up/usr/lib/libgnome* alone on my system, thank you very much. Not to mention the X11 libs, and glibc, and all the other dependencies most of them have.
All Linux packagers have the option of doing what you want NOW by simply including the libraries they prefer in each package, and have a wrapper script to set the preferred library loading path and include scripts in their packages to install only the libraries needed. They aren't doing it because most people consider it a tremendous pain in the ass and more trouble than it's worth.
My wild guess of 50 copies of a library aside, if the number is low, then the NEED for what you suggest isn't likely to be there either, because if so it would demonstrate that the number of incompatible library versions that users are likely to have to deal with is low as well.
A couple were already given you elsewhere. Here's a larger list: sendmail, exim, postfix all provide "smtpdaemon". httpd (Apache) provides "webserver". Firefox, Mozilla, Lynx all provide "webclient". coreutils provides the virtual packages fileutils, sh-utils, textutils, and "/bin/ls" for instance is part of "fileutils". Most applications that wants/bin/ls will either depend on/bin/ls directly or on the virtual package "fileutils" (again Sendmail is an example - it depends on fileutils, regardless of which package provides fileutils).
I "claim that some functionality exists" because it is well documented, and it's existence easily verifiable.
As for examples, try Sendmail. Do an "rpm -q --provides sendmail" on a Fedora Core box, for instance, and you'll get "smtpdaemon" listed. Exim and Postfix for Fedora Core also provides "smtpdaemon".
It is not much used because there are very few cases where it is reasonable to use it - most applications that require something require a specific library or a specific application to be present, very few requires a capability that is met by many applications.
Why then is triggers not allowed in LSB compliant packages specifically in order to maintain compatibility with Debian based systems? Or is that a restriction due to limitations of Alien and not the.deb format?
What do you want an example of? It works exactly like in Debian, allowing you to specify a "virtual" package name/capability that the package in question can be used to satisfy.
First, nobody is forcing you to download binary RPM's from who knows where. However, the very purpose of a "standard" packaging format is that that is exactly what most users want. To make that less painful and risky, RPM's can be signed, but you still won't get around the fact that users WANT to be able to install and run binary packages from "anyone". Deb's allow the same thing, and source is no safer unless you inspect it, which the typical binary package installing user is never going to consider. What do you suggest as a safer solution?
As for the specfile format, that is quite close to the equivalent file for.deb's as far as I can see. What specifically do you have a problem with? I agree the macro format is horrible, but how many people EVER get in a situation where they need/want it? I've written a large number of specfiles over the years, but I've never ever felt the need to use macro's. Can you point me to an example where using the macro's would be useful where the macro format makes it more complicated than need be?
Provides is supported by RPM as well. In fact, I believe the syntax for the package maintainer is exactly the same, but my experience with.deb's is limited so I might be wrong (for RPM you write "Provides: whatever-capability" in the spec file, and that package can satisy the dependency of any package that contains "whatever-capability" in the "Requires:" line).
I don't agree. I don't want 50 versions of some library on my system just because it makes package maintenance better. But if that is what you want, NOTHING is stopping packages from including everything it depends on. The reason it is rarely done is because there's rarely any need to do it.
I absolutely don't agree. Any good text book on evolution should cover how the theory has evolved (no pun intended) since Darwin and until present day. Certainly my science text books at school did so. It was not presented any more as undisputable fact than any of the physics or chemistry or theories in any other subjects were. In fact, many theories in other subjects were never explained or presented in a way that would allow us to raise questions over their validity.
The ongoing debate over evolution in the US is certainly more than enough to make it clear to everyone that there are dissenting viewpoints, so this is nothing but an attempt to make people question evolution more than they're expected to question anything else.
Take a look at the discovery channel. Is it really logical that random mutations will make a spider look EXACTLY like a species of ants, use EXACTLY the same pheromones to hunt them? Or how about this little worm which produces some kind of food that ants like? Or how about the orchid Mantis?
Have you ever thought you saw something, and then looked closer to discover what you thought you saw was something different?
That is a perfectly plausible explanation to your problem. If a spider sometimes, maybe once in a trillion times or less, got an advantage over other types of spider because it happened to have a trait that made it look more like a species of ant, then that trait would (if genetic) gradually become more common. If once in a trillion times or less, in a population of spiders with those features another feature that made them look even more similar to ants arose and gave the spider an advantage, their looks would start converging even more.
Same for food. If once in a trillion times an ant with a specific gene got an advantage out of being able to live on what the worm produces, then that gene would be likely to spread, and other mutations might eventually arise to give advantages to ants that got more benefits out of what the worm produced.
What you are questioning is the very foundation of evolution: Natural selection through environmental pressure.
Symbiosis means SYNCHRONIZED evolution, and I don't think that random mutations can do that. Furthermore, HOW are these mutations produced?
Symbiosis requires no such thing. It requires that one species evolve to take advantage of something from another species because it is available, making itself an integral part of the other species environment and thus making it possible for mutations in the other species to spread that are only beneficial because of the first species, creating a bond that may gradually grow into symbiosis.
It is again trivially explained using only natural selection.
As for how mutations are produced, consider that cells in your body mutate all the time as a result of radiation, chemical reactions, errors in replication of DNA etc.. Sometimes this affects reproduction, and sometimes the mutations do something without causing the reproduction to fail.
Again, it would be more remarkable if mutations didn't happen as it would indicate a completely flawless, 100% fault tolerant system.
Slashdot Mirror
As for personal politics, Commodore was all about personal politics and bizarre power games... Wish I knew why it was as fucked up as it was - it was one of the most frustrating things about owning an Amiga back in it's glory days: You saw what their techs were capable off, but inevitably Commodore would find a way of messing it up. The mess that was the A4000 and A1200 (the first two models to include AGA) was just one of the last of a long string of ridiculous management screw ups - much better designs than the ones that were launched frequently were almost completed before management pulled the plug and went with something even Frankenstein would have been ashamed of (A4000 for instance).
Further, this tells more about you than about the overall "population" of Undernet. You've self-selected who you got in contact with by your choice of channels, by your choice of nick, and by choosing who you talk to. It's perfectly possible to find civilised and "normal" conversations on Undernet, as on most IRC networks. But contrary to the physical world where people with unconvential or perverse fantasies are to a certain extent forced to hide their fantasies, anonymous networks gives them a chance to explore in the open - as a result, if you look you most likely will find.
Another point you need to realise, is that allthough there are many truly disturbed people out there, there's also a great many that just enjoy playing out roles that they in many cases would never dream of living out for real. A significant part of the "nutcases" you've run into on IRC have probably been laughing their ass off from having gotten you to believe what they're writing.
As for window refresh, lots of X11 window managers do the same, as can most other OS's, but it was rarely used on the Amiga - most app's did redraw, because letting the OS redraw meant having the OS keep a backing store, which meant wasting memory, which most Amiga programmers detested.
The low latency interactivity of the Amiga had more to do with the task prioritisation, as you mentioned, and the way interrupts were propagated, as well as the extremely low overhead of context switches due to lack of memory management.
All in all, though, I still dislike virtual memory. Even on the Amiga's with MMU, the virtual memory extensions that were written never got popular for the simple reason that they are disastrous to performance.
I'm still amased that something as simple as a mail application today often takes tens of MB, while I'd never have considered using offline readers (for BBS's) in my Amiga days if they used more than a few hundred KB.
Yes, they apps are more capable, but often I wonder how much of the functionality is worth it, and how much of it could have just been provided as plugins/extensions instead, and that I'd never use.
Having swap in RAM defeats the entire purpose of having swap space in the first place.
Several virtual memory management apps were written for the larger of the classic Amiga's and worked fine, but most of the time we made do with a few MB of memory and the lack of a vmm was rarely an issue.
To play the devils advocate: If you allow students the freedom to wear religious symbols, then what about other religious practices, such as organized prayer - as long as it is done by the students and not the teachers? What about teaching religious beliefs, as long as it is done by students?
If one want a secular school, then as long as there are people that want religion in schools you will need to draw a line and set rules for what is and isn't an acceptable level of religious influence. This is in many ways not any different than other limitations on freedoms endured by school pupils everywhere - including in the US.
The headscarf ban is too restrictive for my taste, though, and it does seem like it is more intended to make muslims "less visible" than it is to prevent any real religious influence in schools.
Then talk to them and explain that some people might get the wrong idea if they bare their bodies in places where most other people are dressed, unless they have a good reason. Treating them with respect is far more likely to work than trying to sheltering them from something they WILL face sooner or later anyway.
Triggers are useful in more complex cases. Say I have application A and application B. They don't depend on eachother to work, but application A provides additional functionality that application B can make use of if available. Application A is useful without application B and the two may be completely unrelated, so it shouldn't require B. Application B requires configuration data that tells it where to find application A if present, and application A might be retargetable, so it might not be present in a fixed location.
Either you let the user handle the configuration, or you make application A know about application B and provide the configuration data, or you let application B look for application A whenever it could make use of it, possibly using the package manager to look for the location of the files it needs, and ignore it if it isn't present, or you use triggers to let application B's configuration be upgraded when application A is installed.
In a situation like this I'd argue that triggers might be the cleanest solution. But it's not as if they do anything you can't do in alternative ways.
Talk about taking out of context. The discussion is about the packaging of Linux applications vs. formats such as RPM and DEB.
Rpm also allows you to list packages that conflicts. So that leaves suggests and recommends. I'm not so sure that is functionality that adds a net benefit (since it could easily have been provided in the documentation), though at last someone have actually managed to suggest something Debian packages has that RPM's doesn't (to my knowledge anyway).
As I've pointed out before, and as others have pointed out, this has nothing to do with the package format. RPM supports it. If you have a problem with a particular RPM based distro, then fine, but it's annoying when you keep on bashing RPM for something that has nothing to do with RPM.
I've already mentioned some fairly large applications that use this (Sendmail, Exim, Postfix all providing "smtpdaemon") for Fedora, but I stand by what I said about it being of relatively limited used simply because there are relatively few cases where applications are suitably interchangable that it makes sense.
You've not said anything to refute that other than make a loose claim that Debian use it a lot. Why don't you provide some examples?
So in other words what you want is dependency resolution, as provided by Apt, Yum, Urpmi and several others. What features of Apt for instance is it you think you need? So far what you have mentioned is stuff that is already there, and in use, by most modern distros. And if you want application local libs, you can trivially do that by using pre-install scripts to pull down additional packages.
As for Loki games, I've reinstalled several Loki games several times through many major distro updates, without any problems. Whenever you find apps where you do run into problems, they can usually be solved by having multiple versions of the RPM installed at once. RPM supports it. Some tools supports it better than others. So far, I've heard very few users actually bring this up as anything but a hypothetical situation - it's a concern that mostly affects closed source apps, and few Linux users rely on old closed source Linux apps as they tend to be left in the dust fairly quickly.
However, I challenge you to point out a single feature of the current package management systems that prevent you from shipping whatever set of dynamic libraries you want with it, if you do want to go to the trouble of copying how it's done on Windows. If what you want to do is treat the package manager as an archiver with a method to run a script, you can.
So what are you complaining about? As I've pointed out, the package management systems supports what you have suggested, so should I assume what you're complaining about is the package maintainers who apparently doesn't agree with you?
For an example, think virtual webhosting. Most hosting companies will sell you either a colocated box where you get root, or a shared hosting account where you don't. Some of them will offer UML or vservers alternatives where you get root on a virtual box. Xen allows the same thing, but faster than UML or VMWare, and with more total separation than vservers.
I did the same from Redhat 6.2 straight to 7.3 once (again with apt-get). THAT was painful, but it worked (after I reran apt 3-4 times).
It's been getting steadily better, but there's still a lot of work left before I'd recommend anyone to try it without a backup, or a bootdisk and a lot of patience :)
All Linux packagers have the option of doing what you want NOW by simply including the libraries they prefer in each package, and have a wrapper script to set the preferred library loading path and include scripts in their packages to install only the libraries needed. They aren't doing it because most people consider it a tremendous pain in the ass and more trouble than it's worth.
My wild guess of 50 copies of a library aside, if the number is low, then the NEED for what you suggest isn't likely to be there either, because if so it would demonstrate that the number of incompatible library versions that users are likely to have to deal with is low as well.
A couple were already given you elsewhere. Here's a larger list: sendmail, exim, postfix all provide "smtpdaemon". httpd (Apache) provides "webserver". Firefox, Mozilla, Lynx all provide "webclient". coreutils provides the virtual packages fileutils, sh-utils, textutils, and "/bin/ls" for instance is part of "fileutils". Most applications that wants /bin/ls will either depend on /bin/ls directly or on the virtual package "fileutils" (again Sendmail is an example - it depends on fileutils, regardless of which package provides fileutils).
As for examples, try Sendmail. Do an "rpm -q --provides sendmail" on a Fedora Core box, for instance, and you'll get "smtpdaemon" listed. Exim and Postfix for Fedora Core also provides "smtpdaemon".
It is not much used because there are very few cases where it is reasonable to use it - most applications that require something require a specific library or a specific application to be present, very few requires a capability that is met by many applications.
Why then is triggers not allowed in LSB compliant packages specifically in order to maintain compatibility with Debian based systems? Or is that a restriction due to limitations of Alien and not the .deb format?
What do you want an example of? It works exactly like in Debian, allowing you to specify a "virtual" package name/capability that the package in question can be used to satisfy.
As for the specfile format, that is quite close to the equivalent file for .deb's as far as I can see. What specifically do you have a problem with? I agree the macro format is horrible, but how many people EVER get in a situation where they need/want it? I've written a large number of specfiles over the years, but I've never ever felt the need to use macro's. Can you point me to an example where using the macro's would be useful where the macro format makes it more complicated than need be?
Provides is supported by RPM as well. In fact, I believe the syntax for the package maintainer is exactly the same, but my experience with .deb's is limited so I might be wrong (for RPM you write "Provides: whatever-capability" in the spec file, and that package can satisy the dependency of any package that contains "whatever-capability" in the "Requires:" line).
I don't agree. I don't want 50 versions of some library on my system just because it makes package maintenance better. But if that is what you want, NOTHING is stopping packages from including everything it depends on. The reason it is rarely done is because there's rarely any need to do it.
As for whether or not the dependency is real, how is the way RPM defines dependencies any worse than how the Debian package manager handles them?
You're right, we shouldn't gloat about IE.
The ongoing debate over evolution in the US is certainly more than enough to make it clear to everyone that there are dissenting viewpoints, so this is nothing but an attempt to make people question evolution more than they're expected to question anything else.
Have you ever thought you saw something, and then looked closer to discover what you thought you saw was something different?
That is a perfectly plausible explanation to your problem. If a spider sometimes, maybe once in a trillion times or less, got an advantage over other types of spider because it happened to have a trait that made it look more like a species of ant, then that trait would (if genetic) gradually become more common. If once in a trillion times or less, in a population of spiders with those features another feature that made them look even more similar to ants arose and gave the spider an advantage, their looks would start converging even more.
Same for food. If once in a trillion times an ant with a specific gene got an advantage out of being able to live on what the worm produces, then that gene would be likely to spread, and other mutations might eventually arise to give advantages to ants that got more benefits out of what the worm produced.
What you are questioning is the very foundation of evolution: Natural selection through environmental pressure.
Symbiosis means SYNCHRONIZED evolution, and I don't think that random mutations can do that. Furthermore, HOW are these mutations produced?
Symbiosis requires no such thing. It requires that one species evolve to take advantage of something from another species because it is available, making itself an integral part of the other species environment and thus making it possible for mutations in the other species to spread that are only beneficial because of the first species, creating a bond that may gradually grow into symbiosis.
It is again trivially explained using only natural selection.
As for how mutations are produced, consider that cells in your body mutate all the time as a result of radiation, chemical reactions, errors in replication of DNA etc.. Sometimes this affects reproduction, and sometimes the mutations do something without causing the reproduction to fail.
Again, it would be more remarkable if mutations didn't happen as it would indicate a completely flawless, 100% fault tolerant system.