Aside from amd64, the ports to m68k, sparc, alpha, powerpc, arm, mip, mipsel, hppa, ia64, s390, ppc64, sh, armeb, m32r, hurd-i386, netbsd-i386, netbsd-alpha and kfreebsd-gnu are not yet finished. And that would only cover all the ports of Debian!
If they were to use an open standard, however, anyone would be allowed to create a player for the videos...
AFAIK that's how it works. Compare to DeCSS which has ~400 pre-generated keys, one of which is assigned to each manufacturer.
The difference with AACS is that there are many more keys--enough to have one per model of player. So it will be pretty easy for them to 'revoke' a compromised model of player by neglecting to include its key on future movie releases. Whether they will actually do so will depend on whether they think they can get away with it.
Yeah, they could at least have uesd the official Debian repositories for the packages that are available from them./me shudders at the prospect of letting NVIDIA or ATI's installers crap all over his system
I don't understand the complaint about eliminating the desktop and changing the display resolution. On GNU/Linux you have X11... there is no need to emulate a physical display attached to the machine in the first place!
If you come from a standards point of view, call it ECMAScript. That's the language's official name; JavaScript is the name of Netscape/Sun's implementation and JScript is the name of Microsoft's.
If you come from a historical point of view, call it JavaScript because that is the original language created by Sun and Netscape; they later submitted a subset of the lanugage to ECMA to create the ECMAScript standard, and Microsoft embraced and extended JavaScript to create JScript.
It's not that simple. Preferences would have to be scanned and hardcoded paths (that shouldn't exist in the first place, granted) to exiting files in the old profile would have to be changed... hard to do if you moved the old profile folder before importing (e.g. backed it up by copying, or put an old hard disk in a new computer causing it to be mounted in a different location or assigned a different drive letter).
AFAIK there are plenty. A more import question is whether there are any LSB applications. AFAIK there are two: Real Player and MySQL. Except that MySQL are dropping support for generic Linux distributions, so we're back to one.:)
Not at all. Say I have a program that links against libc.so.42 and uses symbols that were added to it in version 5. But I have version 4 of the package installed. Although I still have a/usr/lib/libc.so.42, I am unable to run the program.
I don not see how 'foo depends on/usr/lib/libc.so.42' can express the fact that foo requires a symbol only present in libc version 5.
dpkg, of course, does it the right way: foo would simply depend on libc42 (>= 5). This dependency is automatically discovered when building the package of foo by looking libc.so.42 up in/var/lib/dpkg/info/libc42.shlibs. All library packages in Debian provide shared library dependency information in this way.
The "fix" is a kludge. What if RPM failed to create a file for another reason: out of disk space, filesystem error, permission denied, and so on. The real bug is that RPM has no way to roll back and/or continue operations that are interrupted (such as a package being unpacked).
dpkg, of course, handles the situation just fine, because it was well-designed in the first place.;)
> For example, a.deb may be built for Debian stable (but I run testing on my notebook so it's unlikely to work for me)
Please file a bug about that. AFAIK partial upgrades have always (or at least since Woody) been supported, and a bug that breaks them is considered release critical.
Remember that dpkg is just a frontend to other dpkg tools: dpkg-deb for manipulating Debian package files (dpkg-deb --contents or -c lists the contents of packages among other things; dpkg-query --list or -l lists packages and --listfiles or -L lists the files in a package, among others).
Also I have to stand up in favour of creating Debian packages. I find dpkg source packages highly sane and very well thought out, and extremely easy to build -- ensure that the build-dependencies are installed, and run dpkg-buildpackage. Although I don't know how to build source RPMs, I assume the process is the same, substituting in the correct rpm command.
You don't want that ability. You will end up with a fucked up system. Instead you want to install the depended-upon package, or fix the QJoyPad package to not depend on it.:)
If you *really* want to tell apt to ignore the dependency then you can build a fake, empty package with the same name, by using the 'equivs' program.
Having said all that, it would be nice to have apt frontends offer to continue to indicate that QJoyPad is broken (a technical term meaning that it is installed but its dependencies are not), but to not try to fix the situation by removing QJoyPad every damn time apt is run.:)
The Debian platform has such a universal packaging system (dpkg) and a set of standards that developers use to correctly integrate their software into the Debian System.
Other distributions (one would hope) have their own standards. The problem is that everyone wants "Linux" to be a platform when it is only a component. And everyone wants "Linux" to be a platform/operating system when really the platforms are Debian, Fedora, etc.
Slashdot Mirror
Aside from amd64, the ports to m68k, sparc, alpha, powerpc, arm, mip, mipsel, hppa, ia64, s390, ppc64, sh, armeb, m32r, hurd-i386, netbsd-i386, netbsd-alpha and kfreebsd-gnu are not yet finished. And that would only cover all the ports of Debian!
If they were to use an open standard, however, anyone would be allowed to create a player for the videos...
Patents.
Finally, a sensible solution. But why stop there? You may as well go the whole way and re-discover PICS.
Can't another maintainer apply to maintain the package?
I think that is correct. It's libdvdcss that brute-forces the key during playback.
AFAIK that's how it works. Compare to DeCSS which has ~400 pre-generated keys, one of which is assigned to each manufacturer.
The difference with AACS is that there are many more keys--enough to have one per model of player. So it will be pretty easy for them to 'revoke' a compromised model of player by neglecting to include its key on future movie releases. Whether they will actually do so will depend on whether they think they can get away with it.
Don't they require both a proprietary (non-redistributable, non-modifiable, no source code) firmware AND "regulatory compliance daemon"?
God, I'm so glad I got off the Apple treadmill when I could!
Yeah, they could at least have uesd the official Debian repositories for the packages that are available from them. /me shudders at the prospect of letting NVIDIA or ATI's installers crap all over his system
So the solution to the problem of having too many GUI toolkits is to create yet another toolkit? That no one will use?
I don't understand the complaint about eliminating the desktop and changing the display resolution. On GNU/Linux you have X11... there is no need to emulate a physical display attached to the machine in the first place!
It's a valid hexatridecimal (base 36) number!
If you come from a standards point of view, call it ECMAScript. That's the language's official name; JavaScript is the name of Netscape/Sun's implementation and JScript is the name of Microsoft's.
If you come from a historical point of view, call it JavaScript because that is the original language created by Sun and Netscape; they later submitted a subset of the lanugage to ECMA to create the ECMAScript standard, and Microsoft embraced and extended JavaScript to create JScript.
It's not that simple. Preferences would have to be scanned and hardcoded paths (that shouldn't exist in the first place, granted) to exiting files in the old profile would have to be changed... hard to do if you moved the old profile folder before importing (e.g. backed it up by copying, or put an old hard disk in a new computer causing it to be mounted in a different location or assigned a different drive letter).
Mozilla? Integrate with the platform it runs on? You jest, sir! ;)
AFAIK there are plenty. A more import question is whether there are any LSB applications. AFAIK there are two: Real Player and MySQL. Except that MySQL are dropping support for generic Linux distributions, so we're back to one. :)
Not at all. Say I have a program that links against libc.so.42 and uses symbols that were added to it in version 5. But I have version 4 of the package installed. Although I still have a /usr/lib/libc.so.42, I am unable to run the program.
/usr/lib/libc.so.42' can express the fact that foo requires a symbol only present in libc version 5.
/var/lib/dpkg/info/libc42.shlibs. All library packages in Debian provide shared library dependency information in this way.
I don not see how 'foo depends on
dpkg, of course, does it the right way: foo would simply depend on libc42 (>= 5). This dependency is automatically discovered when building the package of foo by looking libc.so.42 up in
The "fix" is a kludge. What if RPM failed to create a file for another reason: out of disk space, filesystem error, permission denied, and so on. The real bug is that RPM has no way to roll back and/or continue operations that are interrupted (such as a package being unpacked).
;)
dpkg, of course, handles the situation just fine, because it was well-designed in the first place.
Since dpkg maintainer scripts are idempotent, reinstalling all the packages should have been a very straightforward way to get everything back.
:)
But the easiest way to get everything back would have been to restore your backups...
> For example, a .deb may be built for Debian stable (but I run testing on my notebook so it's unlikely to work for me)
Please file a bug about that. AFAIK partial upgrades have always (or at least since Woody) been supported, and a bug that breaks them is considered release critical.
Now, if only they would fix the embarrassing bug in RPM. :)
Remember that dpkg is just a frontend to other dpkg tools: dpkg-deb for manipulating Debian package files (dpkg-deb --contents or -c lists the contents of packages among other things; dpkg-query --list or -l lists packages and --listfiles or -L lists the files in a package, among others).
Also I have to stand up in favour of creating Debian packages. I find dpkg source packages highly sane and very well thought out, and extremely easy to build -- ensure that the build-dependencies are installed, and run dpkg-buildpackage. Although I don't know how to build source RPMs, I assume the process is the same, substituting in the correct rpm command.
You don't want that ability. You will end up with a fucked up system. Instead you want to install the depended-upon package, or fix the QJoyPad package to not depend on it. :)
:)
If you *really* want to tell apt to ignore the dependency then you can build a fake, empty package with the same name, by using the 'equivs' program.
Having said all that, it would be nice to have apt frontends offer to continue to indicate that QJoyPad is broken (a technical term meaning that it is installed but its dependencies are not), but to not try to fix the situation by removing QJoyPad every damn time apt is run.
-S is just short for --search.
At the end of the day, Linux is just a kernel.
The Debian platform has such a universal packaging system (dpkg) and a set of standards that developers use to correctly integrate their software into the Debian System.
Other distributions (one would hope) have their own standards. The problem is that everyone wants "Linux" to be a platform when it is only a component. And everyone wants "Linux" to be a platform/operating system when really the platforms are Debian, Fedora, etc.