Given that their solicitors fucked up, they have two choices:
1. Possibly forsake the spamhaus.org domain
2. Waste millions of dollars in legal fees and travel expenses to fight a stupid court case brought by a spammer in another country
I don't think I would waste much time deciding what to do if I were in Spamhaus' situation!
You're leaving out the part where their solicitors requested the venue change without instructions. AFAIK Spamhaus dismissed them and are taking them to court for creating this whole fucking mess in the first place.
In the defence of the ReiserFS, if a disk reports a bad block to the operating system then it means that its internal supply of spare blocks (that are used to transparently replace bad blocks) has been exhausted, and that the disk should be replaced immediatly.
For example:
# smartctl -A/dev/hdg ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 253 253 063 Pre-fail Always - 0
This disk hasn't yet had any bad blocks. As the disk ages and blocks go bad, RAW_VALUE will go up, and VALUE will go down. When VALUE <= THRESHOLD then there are no more spare blocks and bad block errors will be reported to the operating system. At this point the disk should be replaced.
Actually, the zero-filled files is a misfeature of XFS. Having a UPS will not save you. There are two XFS problems:
1. Power loss can destroy your filesystem. Solution: do not use XFS or ReiserFS without a UPS.
2. An unclean shutdown can leave you with zero-filled files. AFAIK this is a design flaw in XFS or, depending how you look at it, a tradeoff of data integrity for performance. If you don't like the tradeoff then your only choice is to use another filesystem.
There have been too many reports in the last couple of months of people whose machines have lost power, and booted up, only to find that every file on their XFS filesystems has been filled with zeroes.
By the way, in theory you could try to create a huge database of all symbols exported by a library, and use that + the library's SONAME to determine which library packages a given package depends upon. However this method falls over when you take into account dependencies that are not specified in a package's binary's DT_NEEDED field, such as libraries loaded at runtime via dlopen(3), or python modules imported by a script in the package, or artwork loaded from a specific location in the filesystem by the package, etc.
In addition, the database would have to keep track of the semantics of each symbol. For instance, a function foo_init might do one thing in version 1 of a library, and do something completley different in version 2. But there is no way for your database to know this without manual investigation. This is why we generally just trust the developers of a library to encode all this information into the library's SONAME, with the simple rule that when backwards-compatibility is broken for any reason (be it the removal of an old symbol, or the repurposing of a symbol, etc), the SONAME is changed.
No, it should not! It doesn't need "GTK version 2.10", it needs a library with the SONAME "libgtk-x11-2.0.so.0". You can read more about this (very tricky) topic in the libtool documentation, among other places. http://www.gnu.org/software/libtool/manual.html#Ve rsioning
Changing the SONAME for every API addition, rather than only when changes are made that break backwards incompatibility is a bad idea because it requires every binary linked against that library to be recompiled. http://www.gnu.org/software/libtool/manual.html#Re lease-numbers.
The only library I know of that does this is OpenSSL, and it is universally despised because of it. Imagine if GTK did such a thing!
The point is that copying an image to your retina is first of all not considered an act of copying, and second of all, naturally protected by the architecture of our physical world. This is different to the act of copying a work to your computer and executing it.
I'm sure Lessig knows of case law to back his statements up, he is a copyright lawyer after all.:)
Copyright law reserves the right of copying a work to the author of the work. You may not copy a work to your computer's disk, to its RAM, or portions thereof to its cache, processor and other components without permission.
You should read Free Culture for an understanding of why copyright controls everything in the digital age, particularly the "PROPERTY" chapter and especially pages 139 onwards.
No one seems to have mentioned the LARGE CAPITOL LETTER SECTION of the GPL that tells you that the author disclaims responsitibility from any damage caused by the program, etc.
Given the choice between inserting the GPL into the EULA section of commonly used installer software, or opening themselves up to huge potential liability, I can't blame software distributors for weaseling out and going with the status quo.
Well, if you can think of a better way to present the info about password sharing to the user, please submit a bug! Remember that you can't rely on the user reading any documentation, and that the password storing feature must be enabled by default, or the user will assume that Firefox doesn't have the feature at all and will go back to IE.
I doubt they will do this though. The password popup window already contains too many buttons: [Yes], [No] and [Never for this site]. End-users are already instantly paralyzed when they see a window with three buttons, like a deer in the headlights of an onrushing car. Adding a fourth button will make their brains melt out of their ears.:)
Probably because most DDs don't want to waste their time getting their.diff.gzs approved by mozilla.com. So far no one seems to want a firefox package in non-free badly enough that they can be bothered to file an RFP for it.
As a user, I am happy that I will be able to run 'apt-get source iceweasel', modify the source code, build my own packages and distribute them without being C&D'd by Mozilla.
Pick a version, then click on the links after 'source package'.
You answered yourself why ldd is useless as a dependency finding mechanism. It fails to account for API additions. For example, let's say I want to install a package of Firefox that uses the new GTK 2.10 printing API.
$ dpkg --status libgtk2.0-0 | grep Version Version: 2.8.20-2
$ firefox/usr/lib/firefox/firefox-bin: undefined reference to gtk_print_new
The problem is that ABI additions do not break backwards-compatibility with binaries linked against older versions of the library. So it is impossible to search for dependencies based purely on the value of a binary's private headers' dynamic section's DT_NEEDED field.
Slashdot Mirror
Given that their solicitors fucked up, they have two choices:
1. Possibly forsake the spamhaus.org domain
2. Waste millions of dollars in legal fees and travel expenses to fight a stupid court case brought by a spammer in another country
I don't think I would waste much time deciding what to do if I were in Spamhaus' situation!
I use 'ext2fsd' to mount ext2/3 filesystems in Windows. Read-only for ext3, unfortunately.
I don't think so. SPF has serious technical problems:
m tp-spf-is-harmful.html
http://homepages.tesco.net/J.deBoynePollard/FGA/s
Not to mention the legal uncertainty surrounding the version hijacked by Microsoft.
You're leaving out the part where their solicitors requested the venue change without instructions. AFAIK Spamhaus dismissed them and are taking them to court for creating this whole fucking mess in the first place.
In the defence of the ReiserFS, if a disk reports a bad block to the operating system then it means that its internal supply of spare blocks (that are used to transparently replace bad blocks) has been exhausted, and that the disk should be replaced immediatly.
/dev/hdg
For example:
# smartctl -A
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 253 253 063 Pre-fail Always - 0
This disk hasn't yet had any bad blocks. As the disk ages and blocks go bad, RAW_VALUE will go up, and VALUE will go down. When VALUE <= THRESHOLD then there are no more spare blocks and bad block errors will be reported to the operating system. At this point the disk should be replaced.
Actually, the zero-filled files is a misfeature of XFS. Having a UPS will not save you. There are two XFS problems:
m l
1. Power loss can destroy your filesystem. Solution: do not use XFS or ReiserFS without a UPS.
2. An unclean shutdown can leave you with zero-filled files. AFAIK this is a design flaw in XFS or, depending how you look at it, a tradeoff of data integrity for performance. If you don't like the tradeoff then your only choice is to use another filesystem.
Source: http://linuxmafia.com/faq/Filesystems/reiserfs.ht
There have been too many reports in the last couple of months of people whose machines have lost power, and booted up, only to find that every file on their XFS filesystems has been filled with zeroes.
By the way, in theory you could try to create a huge database of all symbols exported by a library, and use that + the library's SONAME to determine which library packages a given package depends upon. However this method falls over when you take into account dependencies that are not specified in a package's binary's DT_NEEDED field, such as libraries loaded at runtime via dlopen(3), or python modules imported by a script in the package, or artwork loaded from a specific location in the filesystem by the package, etc.
In addition, the database would have to keep track of the semantics of each symbol. For instance, a function foo_init might do one thing in version 1 of a library, and do something completley different in version 2. But there is no way for your database to know this without manual investigation. This is why we generally just trust the developers of a library to encode all this information into the library's SONAME, with the simple rule that when backwards-compatibility is broken for any reason (be it the removal of an old symbol, or the repurposing of a symbol, etc), the SONAME is changed.
No, it should not! It doesn't need "GTK version 2.10", it needs a library with the SONAME "libgtk-x11-2.0.so.0". You can read more about this (very tricky) topic in the libtool documentation, among other places. http://www.gnu.org/software/libtool/manual.html#Ve rsioning
e lease-numbers.
Changing the SONAME for every API addition, rather than only when changes are made that break backwards incompatibility is a bad idea because it requires every binary linked against that library to be recompiled. http://www.gnu.org/software/libtool/manual.html#R
The only library I know of that does this is OpenSSL, and it is universally despised because of it. Imagine if GTK did such a thing!
$ apt search ~Ddepends:'libgtk2\.0-0' | wc -l
1033
Every time GTK was updated, all 1033 packages that depend upon it would have to be recompiled.
The point is that copying an image to your retina is first of all not considered an act of copying, and second of all, naturally protected by the architecture of our physical world. This is different to the act of copying a work to your computer and executing it.
:)
I'm sure Lessig knows of case law to back his statements up, he is a copyright lawyer after all.
Copyright law reserves the right of copying a work to the author of the work. You may not copy a work to your computer's disk, to its RAM, or portions thereof to its cache, processor and other components without permission.
You should read Free Culture for an understanding of why copyright controls everything in the digital age, particularly the "PROPERTY" chapter and especially pages 139 onwards.
No one seems to have mentioned the LARGE CAPITOL LETTER SECTION of the GPL that tells you that the author disclaims responsitibility from any damage caused by the program, etc.
Given the choice between inserting the GPL into the EULA section of commonly used installer software, or opening themselves up to huge potential liability, I can't blame software distributors for weaseling out and going with the status quo.
Only if you subscribe to the theory that you don't need permission from an author to execute a work on your computer.
I want this feature because there is no way to remember all the passwords I have to use for all the different sites I use.
Well, if you can think of a better way to present the info about password sharing to the user, please submit a bug! Remember that you can't rely on the user reading any documentation, and that the password storing feature must be enabled by default, or the user will assume that Firefox doesn't have the feature at all and will go back to IE.
Did you file a bug?
:)
I doubt they will do this though. The password popup window already contains too many buttons: [Yes], [No] and [Never for this site]. End-users are already instantly paralyzed when they see a window with three buttons, like a deer in the headlights of an onrushing car. Adding a fourth button will make their brains melt out of their ears.
Probably because most DDs don't want to waste their time getting their .diff.gzs approved by mozilla.com. So far no one seems to want a firefox package in non-free badly enough that they can be bothered to file an RFP for it.
Debian users still want a Mozilla/Firefox-a-like browser in main.
Anyone is free to file an RFP for a 'firefox' package to go into non-free.
As a user, I am happy that I will be able to run 'apt-get source iceweasel', modify the source code, build my own packages and distribute them without being C&D'd by Mozilla.
Pick a version, then click on the links after 'source package'.
You answered yourself why ldd is useless as a dependency finding mechanism. It fails to account for API additions. For example, let's say I want to install a package of Firefox that uses the new GTK 2.10 printing API.
The problem is that ABI additions do not break backwards-compatibility with binaries linked against older versions of the library. So it is impossible to search for dependencies based purely on the value of a binary's private headers' dynamic section's DT_NEEDED field.
"Branch maintained outside of the Mozilla project"?
Please show me where the Official Use Logo is actually used in Debian.
Has it not occured to you that the lameness filter was doing its job correctly?
Unfortunately, it is more convenient for the package maintainers to keep the patches lumped together in a private SVN repository. :(
Great! So you'll file the ITP? :)