Re:standardized locations, etc.
on
Is RPM Doomed?
·
· Score: 2
I hate having to have 2-10 different versions of libraries due to prorams requesting their own version, even though the newer libraries could do the job of the old ones
Any program linked against a library with the same major version number and the same or lower version number than the library installed should work. If the program depends on a specific minor version (as opposed to "a specific minor version or greater"), it's broken. If you have libfoo.so.1.0.1, libfoo.so.1.0.5 and libfo.so.1.0.7 you should be able to delete all of them except for the last and expect things to keep working. Applications are linked against the major version number, so they'll be using the more recent version already (run ldd on a binary and look at the first column - that's what the program is looking for, and the last column is what it's using)
Now, the problem arises when you have applications linked against different major versions. The major version is supposed to be incremented when an incompatible change in the ABI is made - that is, without recompilation, a program linked against libfoo.so.1 will not work with libfoo.so.2 (well, it might - the change may be limited to a specific part of the library that the program doesn't use. But you can't guarantee that).
So, if you have dependencies on lots of libraries with the same major version but different minor versions, your packages are broken. If you have dependencies on lots of libraries with different major numbers, then that's unavoidable and nothing to do with the packaging system.
Re:RPM not the problem..
on
Is RPM Doomed?
·
· Score: 5, Informative
Why do we still throw library files from different packages together in the same directory?!
Mostly because that's the point of libraries. Libraries allow code to be reused between applications - sticking them in application specific locations makes it somewhat harder for application A to use library B.
For instance take one of the hundreds of utils to encrypt the password.
You mean passwd? This is generally done with something like PAM nowadays. People want to be able to authenticate from things like RADIUS, Kerberos and LDAP, so applications which fuck about with/etc/passwd directly are already dead in the water.
You could defeat this if the program uses the crypt library but what if said programmer was following standard and wrote his own library.
Applications should not be encrypting passwords themselves and writing them to/etc/passwd. It wouldn't even work with shadow passwords. It certainly wouldn't work on *BSD (On the BSDs,/etc/passwd is generated from/etc/master.passwd./etc/master.passwd is a different format to/etc/passwd. Oops. Your "hundreds of utilities" don't work on several OSs already).
It's really not a security hole and maybe someday someone will sit down and change it.
They have. Linux, at least, supports using MD5 rather than crypt for hashing passwords. I believe that the BSDs do something similar (of course, the BSDs only provide/etc/passwd as a compatibility measure for applications that process user information by hand - the crypted passwords themselves are only in/etc/master.passwd and the binary databases generated from there).
Just be prepared to break compatibility with alot of programs.
Eh? If you've got shadow passwords, any user apps won't be able to see the crypted password anyway. What applications are you thinking of, and why the hell are they trying to do anything with my passwords?
our eyes have receptors that are sensitive to YGBL (Yellow, Green, Blue and Luminance)
Nope. Cones are sensitive to red, green and blue (hence the use of RGB in TVs). Rods (which I assume you're referring to when you say "luminance") pretty much don't exist at the focal point where the cones are clustered. The reason for extra sensitivity to green is simply down to the wavelengths picked up - green is central, so a green object will stimulate the blue and red receptors to some extent as well. Luminance really isn't that important. Studies on neural activity suggest that the colour perception pathway in the brain doesn't include input from the rods, so colour perception is entirely based on red, green and blue input.
If you're in the EU, then the EUCD creates many of the same issues. It's been passed by the European parliament, so member states are now obligied to implement it in the near future.
So use xpdf or some similar PDF reading software. The PDF specification is freely available and there are Free readers for it. You can generate it without having to use Adobe products, and you can read it without having to use Adobe products.
Obligatory spelling flame
on
Mini Microbes
·
· Score: 2, Informative
I assume you're talking about the source RPM they provide? Sure, it's a source RPM (in that you can't install it directly and it lets you build a binary RPM). It doesn't actually have any source, though. Everything in it is a binary, and the Makefile's only target is "install".
the actual kernel module
You're right, we do have some source here. It gets built and then linked against a file called Module-nvkernel to give the final kernel module. Module-nvkernel doesn't have any source included with it. It's almost a megabyte of something that file claims is
Module-nvkernel: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
See that "Intel 80386" bit there? Oddly enough, that's not going to run terribly well on an Alpha. We have 280K of source which is possibly portable to other architectures and a 1MB binary file that's required and which isn't in any way portable to other architectures.
Its as simple as make and wowee, you have a brand spanking new driver compiled against your kernel headers.
Yes, as long as you're running on x86. Which Alpha isn't. If you're going to try to correct me, could you please put some effort into checking your facts beforehand?
IBM have a driver for their MWave software modems in the main kernel tree. PCTel have an open driver for theirs, too. Conexant are actively supporting the development of drivers for their HCF and HSF chipsets. Lucent, on the other hand, have an unofficial binary driver that seems quite happy to crash.
No, NVidia actively support Linux/x86. Want to use a GeForce in an Alpha? Oops. By releasing documentation, ATI allow their hardware to be used on all Linux platforms rather than a subset of the popular ones.
The GPL gives you rights that you would not otherwise have under copyright law. The Microsoft EULA restricts your rights beyond what you would otherwise have under copyright law. Comparing the two as if they're morally equivalent is misleading.
If they've made an alteration to a piece of software that I'd find useful now, I have to wait a few months or reimplement it myself. If they go bust between now and finally releasing the source, we may never get our hands on it.
People who release their software under the GPL are explicitly stating that they don't want their software redistributed unless source is available. They weren't under any obligation to do that (unless they based it on already GPLed code, but they weren't under any obligation to do that, either), but they did. Perhaps they did that because they don't like the idea of commercial organisations modifying and selling their code without them being able to get at the improvements. Maybe they thought that it was important for users to be able to get the source of the software they use. Possibly they were mad. Who knows? Whatever the reason was, that code was released with an explicit statement requiring companies provide source to software they distribute based upon that code.
Now, you may not think that that's important. The Freeness (in the GNU sense) of software may not be much of an issue to you. But that doesn't change the fact that Lindows is distributing people's software in a way that they have no intrinsic right to do, and which the authors of the software have specifically stated they do not wish to occur. Lindows didn't need to do that. They could have based their product on non-GPLed code.
These dirty-laundry-in-public attacks damage open-source credibility, and that is not a good thing.
One of the most important things about the GPL is that the source is available. Not complaining about companies ignoring that is significantly more damaging to open-source credibility.
This isn't about eating our young. This is about pointing out that the reason much of this code is under this license is because we care about the implications, and companies who want to use this code should abide by the wishes of those who wrote it.
They only have to do that if a) they are selling the binaries and b) someone requests it.
Any distribution (other than internal distribution) requires the source to be available. And yes, it's only required that they distribute it to people who have the binaries and request it. However, the implication of his statements is that they wouldn't do so anyway.
The really terrible thing is the kernel mods that are necessary to necessary to put the hooks in for their point-n-drool API. I know Linus has the guts to tell them no, but unfortunately all the major distros have started including those patches.
That's what the distrbutions are there for. Linus produces what he thinks should be produced, and as the baseline kernel distribution it's inherently going to be somewhat conservative. Distributions then modify this to suit what their customers want, regardless of whether it's something that Linus would want in the kernel or not (see supermount, for instance - users want the convenience of being able to use removable media without messing about mounting and unmounting it. It's an ugly patch and Linus is never going to include it in his kernel. Distributions add the patch. Everyone's happy)
I guess that's the downside of Open Source. You can't make everyone learn the CLI like they should.
There should be no requirement to use the CLI. Many users just want to be able to turn on the computer, send an email and turn it off again. In what way does forcing them to use a CLI improve their life?
So after only 12, the low-latency patch degraded by an ungodly amount (1.3 -> 215.2 ms)!!
You're misinterpreting the figures. After a short benchmarking, the worst figure recorded was 1.3ms. After the machine had been left up for 12 hours (thereby allowing there to be much more time for something odd to crop up), the worst figure recorded was 215.2ms. That doesn't mean that the performance had degraded - it means that over the course of those 12 hours, something happened that caused latency to peak at 215.2ms. It might be something that happens once every 12 hours, for instance.
Not the only sed game
on
SedSokoban
·
· Score: 3, Informative
http://ds.dial.pipex.com/ap2/ is probably what you're looking for. This page is especially topical, but the rest of the site gives a great deal of insight into what the games magazine industry is really like.
I don't know about in the U.K., but in most of the United States, "conditions imposed after sale" are invalid.
In this case, it's not a condition imposed after sale. Buying the CD doesn't give you an intrinsic right to copy the code into memory (seriously, section 17 of the CD&P 1988 is very clear on this), so it's a license that gives you rights above what you already have. In this it's like the GPL - you're being granted permission to do something that you wouldn't otherwise be allowed to do. In the UK, at least.
1. Physical RAM is smaller than the entirety of the game, therefore
True.
The entire game is not copied, only an excerpt
True.
3. This is acceptable under fair use provisions, especially considering that it is neither distributed to multiple people or attributed to anyone otehr than the creator.
Wrong. Your rights under UK copyright law are very clear - you're allowed to include sections of copyrighted material in reviews or criticism, if it's incidental in the background of another work, for certain research purposes, for teaching purposes, if you're a library, if you're parliament and for a few other fringe cases. Section 17 explicitly prohibits you from making transient copies, and a copy does not have to be the entirity of the work.
I guess they needed a more technically astute lawyer. Missing that one in the courtroom was a litigation flub.
The usual reasoning is that since the games are sold as objects with no contract or recurring charge, exactly like music CDs, then they are covered by copyright law.
Yes, but copying the game into memory is unauthorised unless the copyright holder gives you permission under UK law. The copyright holder is at liberty to only give you permission in certain areas of the world.
That means that i can buy a Japanese game from Tokyo and play it in DC and there's fuck all Sony can do about it.
Maybe I am just being dense, but could someone please show me where it says you aren't allowed to move somewhere and play your game?
Under UK law, you don't have an intrinsic right to make the copy of the game in memory that is required for the game to be playable. Unless the license associated with it grants you permission, you're stuck. Most licenses only seem to grant you permission in certain regions, hence playing imported games is illegal.
Slashdot Mirror
I hate having to have 2-10 different versions of libraries due to prorams requesting their own version, even though the newer libraries could do the job of the old ones
Any program linked against a library with the same major version number and the same or lower version number than the library installed should work. If the program depends on a specific minor version (as opposed to "a specific minor version or greater"), it's broken. If you have libfoo.so.1.0.1, libfoo.so.1.0.5 and libfo.so.1.0.7 you should be able to delete all of them except for the last and expect things to keep working. Applications are linked against the major version number, so they'll be using the more recent version already (run ldd on a binary and look at the first column - that's what the program is looking for, and the last column is what it's using)
Now, the problem arises when you have applications linked against different major versions. The major version is supposed to be incremented when an incompatible change in the ABI is made - that is, without recompilation, a program linked against libfoo.so.1 will not work with libfoo.so.2 (well, it might - the change may be limited to a specific part of the library that the program doesn't use. But you can't guarantee that).
So, if you have dependencies on lots of libraries with the same major version but different minor versions, your packages are broken. If you have dependencies on lots of libraries with different major numbers, then that's unavoidable and nothing to do with the packaging system.
Why do we still throw library files from different packages together in the same directory?!
Mostly because that's the point of libraries. Libraries allow code to be reused between applications - sticking them in application specific locations makes it somewhat harder for application A to use library B.
For instance take one of the hundreds of utils to encrypt the password.
/etc/passwd directly are already dead in the water.
/etc/passwd. It wouldn't even work with shadow passwords. It certainly wouldn't work on *BSD (On the BSDs, /etc/passwd is generated from /etc/master.passwd. /etc/master.passwd is a different format to /etc/passwd. Oops. Your "hundreds of utilities" don't work on several OSs already).
You mean passwd? This is generally done with something like PAM nowadays. People want to be able to authenticate from things like RADIUS, Kerberos and LDAP, so applications which fuck about with
You could defeat this if the program uses the crypt library but what if said programmer was following standard and wrote his own library.
Applications should not be encrypting passwords themselves and writing them to
It's really not a security hole and maybe someday someone will sit down and change it.
/etc/passwd as a compatibility measure for applications that process user information by hand - the crypted passwords themselves are only in /etc/master.passwd and the binary databases generated from there).
They have. Linux, at least, supports using MD5 rather than crypt for hashing passwords. I believe that the BSDs do something similar (of course, the BSDs only provide
Just be prepared to break compatibility with alot of programs.
Eh? If you've got shadow passwords, any user apps won't be able to see the crypted password anyway. What applications are you thinking of, and why the hell are they trying to do anything with my passwords?
our eyes have receptors that are sensitive to YGBL (Yellow, Green, Blue and Luminance)
Nope. Cones are sensitive to red, green and blue (hence the use of RGB in TVs). Rods (which I assume you're referring to when you say "luminance") pretty much don't exist at the focal point where the cones are clustered. The reason for extra sensitivity to green is simply down to the wavelengths picked up - green is central, so a green object will stimulate the blue and red receptors to some extent as well. Luminance really isn't that important. Studies on neural activity suggest that the colour perception pathway in the brain doesn't include input from the rods, so colour perception is entirely based on red, green and blue input.
If you're in the EU, then the EUCD creates many of the same issues. It's been passed by the European parliament, so member states are now obligied to implement it in the near future.
So use xpdf or some similar PDF reading software. The PDF specification is freely available and there are Free readers for it. You can generate it without having to use Adobe products, and you can read it without having to use Adobe products.
It's viruses, not virii. http://language.perl.com/misc/virus.html has a good overview of this argument, or check any dictionary or biology text.
Think there are ONLY binary drivers?
Yes, if you want 3D support.
You can download source for the NVIDIA GLX
I assume you're talking about the source RPM they provide? Sure, it's a source RPM (in that you can't install it directly and it lets you build a binary RPM). It doesn't actually have any source, though. Everything in it is a binary, and the Makefile's only target is "install".
the actual kernel module
You're right, we do have some source here. It gets built and then linked against a file called Module-nvkernel to give the final kernel module. Module-nvkernel doesn't have any source included with it. It's almost a megabyte of something that file claims is
Module-nvkernel: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
See that "Intel 80386" bit there? Oddly enough, that's not going to run terribly well on an Alpha. We have 280K of source which is possibly portable to other architectures and a 1MB binary file that's required and which isn't in any way portable to other architectures.
Its as simple as make and wowee, you have a brand spanking new driver compiled against your kernel headers.
Yes, as long as you're running on x86. Which Alpha isn't. If you're going to try to correct me, could you please put some effort into checking your facts beforehand?
IBM have a driver for their MWave software modems in the main kernel tree. PCTel have an open driver for theirs, too. Conexant are actively supporting the development of drivers for their HCF and HSF chipsets. Lucent, on the other hand, have an unofficial binary driver that seems quite happy to crash.
NVidia activey supports linux
No, NVidia actively support Linux/x86. Want to use a GeForce in an Alpha? Oops. By releasing documentation, ATI allow their hardware to be used on all Linux platforms rather than a subset of the popular ones.
Except for the NuBus PPC's (when you're using a NuBus slot!)
Have you seen http://nubus-pmac.sourceforge.net/?
The GPL gives you rights that you would not otherwise have under copyright law. The Microsoft EULA restricts your rights beyond what you would otherwise have under copyright law. Comparing the two as if they're morally equivalent is misleading.
what's wrong with waiting a few months?
If they've made an alteration to a piece of software that I'd find useful now, I have to wait a few months or reimplement it myself. If they go bust between now and finally releasing the source, we may never get our hands on it.
People who release their software under the GPL are explicitly stating that they don't want their software redistributed unless source is available. They weren't under any obligation to do that (unless they based it on already GPLed code, but they weren't under any obligation to do that, either), but they did. Perhaps they did that because they don't like the idea of commercial organisations modifying and selling their code without them being able to get at the improvements. Maybe they thought that it was important for users to be able to get the source of the software they use. Possibly they were mad. Who knows? Whatever the reason was, that code was released with an explicit statement requiring companies provide source to software they distribute based upon that code.
Now, you may not think that that's important. The Freeness (in the GNU sense) of software may not be much of an issue to you. But that doesn't change the fact that Lindows is distributing people's software in a way that they have no intrinsic right to do, and which the authors of the software have specifically stated they do not wish to occur. Lindows didn't need to do that. They could have based their product on non-GPLed code.
These dirty-laundry-in-public attacks damage open-source credibility, and that is not a good thing.
One of the most important things about the GPL is that the source is available. Not complaining about companies ignoring that is significantly more damaging to open-source credibility.
This isn't about eating our young. This is about pointing out that the reason much of this code is under this license is because we care about the implications, and companies who want to use this code should abide by the wishes of those who wrote it.
They only have to do that if a) they are selling the binaries and b) someone requests it.
Any distribution (other than internal distribution) requires the source to be available. And yes, it's only required that they distribute it to people who have the binaries and request it. However, the implication of his statements is that they wouldn't do so anyway.
The really terrible thing is the kernel mods that are necessary to necessary to put the hooks in for their point-n-drool API. I know Linus has the guts to tell them no, but unfortunately all the major distros have started including those patches.
That's what the distrbutions are there for. Linus produces what he thinks should be produced, and as the baseline kernel distribution it's inherently going to be somewhat conservative. Distributions then modify this to suit what their customers want, regardless of whether it's something that Linus would want in the kernel or not (see supermount, for instance - users want the convenience of being able to use removable media without messing about mounting and unmounting it. It's an ugly patch and Linus is never going to include it in his kernel. Distributions add the patch. Everyone's happy)
I guess that's the downside of Open Source. You can't make everyone learn the CLI like they should.
There should be no requirement to use the CLI. Many users just want to be able to turn on the computer, send an email and turn it off again. In what way does forcing them to use a CLI improve their life?
So after only 12, the low-latency patch degraded by an ungodly amount (1.3 -> 215.2 ms)!!
You're misinterpreting the figures. After a short benchmarking, the worst figure recorded was 1.3ms. After the machine had been left up for 12 hours (thereby allowing there to be much more time for something odd to crop up), the worst figure recorded was 215.2ms. That doesn't mean that the performance had degraded - it means that over the course of those 12 hours, something happened that caused latency to peak at 215.2ms. It might be something that happens once every 12 hours, for instance.
See http://www-jcsu.jesus.cam.ac.uk/~gsb29/sedgames.ht ml for sed versions of pong, noughts and crosses (tic tac toe in the US, I think), a webserver and a program for translating bf into C.
http://ds.dial.pipex.com/ap2/ is probably what you're looking for. This page is especially topical, but the rest of the site gives a great deal of insight into what the games magazine industry is really like.
I don't know about in the U.K., but in most of the United States, "conditions imposed after sale" are invalid.
In this case, it's not a condition imposed after sale. Buying the CD doesn't give you an intrinsic right to copy the code into memory (seriously, section 17 of the CD&P 1988 is very clear on this), so it's a license that gives you rights above what you already have. In this it's like the GPL - you're being granted permission to do something that you wouldn't otherwise be allowed to do. In the UK, at least.
1. Physical RAM is smaller than the entirety of the game, therefore
True.
The entire game is not copied, only an excerpt
True.
3. This is acceptable under fair use provisions, especially considering that it is neither distributed to multiple people or attributed to anyone otehr than the creator.
Wrong. Your rights under UK copyright law are very clear - you're allowed to include sections of copyrighted material in reviews or criticism, if it's incidental in the background of another work, for certain research purposes, for teaching purposes, if you're a library, if you're parliament and for a few other fringe cases. Section 17 explicitly prohibits you from making transient copies, and a copy does not have to be the entirity of the work.
I guess they needed a more technically astute lawyer. Missing that one in the courtroom was a litigation flub.
How about taking a look at the law first?
I don't know about the UK, but in the USA, copying programs from a legit copy to RAM in order to run them is perfectly lawful.
Section 17 of the Copyright, Design and Patent act 1988
(6) Copying in relation to any description of work includes the making of copies which are transient or are incidental to some other use of the work.
So yes, it is illegal in the UK.
If not, then how were Sony allowed to get away with this argument?
Because the license in question gives you rights above what copyright law (in the UK at least) provides you with.
The usual reasoning is that since the games are sold as objects with no contract or recurring charge, exactly like music CDs, then they are covered by copyright law.
Yes, but copying the game into memory is unauthorised unless the copyright holder gives you permission under UK law. The copyright holder is at liberty to only give you permission in certain areas of the world.
That means that i can buy a Japanese game from Tokyo and play it in DC and there's fuck all Sony can do about it.
Except, of course, they can.
Maybe I am just being dense, but could someone please show me where it says you aren't allowed to move somewhere and play your game?
Under UK law, you don't have an intrinsic right to make the copy of the game in memory that is required for the game to be playable. Unless the license associated with it grants you permission, you're stuck. Most licenses only seem to grant you permission in certain regions, hence playing imported games is illegal.