I just remembered, the driver works fine for most people with WPA. My problem was that I would have to bring the card up, transmit some packets, then bring it down and up again before I was able to recieve anything. The maintainer and I were unable to debug it further because I had no other wireless hardware to assist in the monitoring of what was really going on.
Works for me. I am using the 'beta3' release. The guy who maintains the driver is very helpful, if you can't get it to work ask for help on the forum.:)
As long as you don't need WPA, get a card with an rt2x00 series chip. The drivers work fine, though they are not yet good enough to be merged into the kernel. http://rt2x00.serialmonkey.com/
It's ironic that in setting out to 'solve' spam, Microsoft all but destroyed the momentum around SPF, fracturing it into several different, incompatible implementations.
According to TFA, "Sony has said that the Reader will be able to display content from RSS feeds and from PDF files in addition to e-books in Sony's own BBeB format". That does not rule out the possibility (more like probability, since we are talking about Sony here) that one must use Sony's Windows-only software to convert files into their proprietary format.
But will it actually read the foreign formats, or are Sony lieing like they usually do?
Chances are, the foreign formats are only 'supported' if you don't mind using their crappy Windows software to convert them to Sony's proprietry formats before copying them to the device.
> And most importantly.......why do I need to know all of this > stuff just to get the printer working in Debian?
Ah, you're a desktop user. Pick 'desktop' when prompted while installing and I believe all this stuff will be installed automatically. You can then go to Desktop -> Administration -> Printing to add your printer.
the GPL ensures that the software it covers will neither be subject to, nor subject other works to, digital restrictions from which escape is forbidden.
This phrase, that you took from the preamble, is describing the GPL itself, not laying out license terms. Multiply out the sentence, and you get:
Software covered by the GPL will not be subject to digital restrictions from which escape is forbidden.
Software covered by the GPL will not subject other works to restrictions from which escape is forbidden.
I am still waiting for you to explain how this means that "if you build DRM software open or closed you loose you right to all GPL 3 software [that] you use".
/etc/init.d/ scripts: Debian doesn't have a nice way to turn these scripts on and off and monitor their status via a command-line tool. Red Hat's system here was very good.
If removing the relevant links from/etc/rc[0-6].d is too difficult, you can use sysv-rc-conf, sysvconfig, or any of your other favourite tools in Apt. GNOME and KDE also provide interfaces to enable/disable services; GNOME's is located under Desktop -> Administration -> Services.
It's true that policy doesn't mandate the existance of a 'status' argument for init scripts; however, it does mandate that init scripts are idempotent, and in the few cases where I have genuinely wanted to check if a daemon is running rather than start/stop/restart/reload it, I just use the tools in procps.
user management: I use LDAP for user management; others use SAMBA and other stuff. But adduser isn't a shim that can interface to any of these back-end data-stores -- it can only do/etc/passwd.
AFAIK, adduser is not supposed to. There can be no general frontend for modifying the data behind NSS, because it can be stored in so many different ways. If there are scripts in another distribution you would like to see packaged, please run 'reportbug wnpp' and fill in a Request For Package bug.
ideology: Debian's ideological bent can be a real pain for those us using the distro for its technical merits. For example, Debian pulled SSL support from all the GPL network services that link to libssl in a fit of ideology that no other distro has had.
This has nothing to do with ideology. The OpenSSL license is not compatible with the GPL, because it imposes additional restrictions on the use/modification of the GPLd code. It is simply illegal for Debian to distribute GPLd binaries linked to OpenSSL; anyone else who does so is opening themselves up to lawsuits. See the archives of debian-legal or OpenSSL and the GPL for further information.
package management: Yeah, apt-get's dependency resolution logic is very cool. Other aspects of the system aren't so cool. Apt-get, aptitude, and other front-ends don't share the same back-end data-store, so if you mix and match these tools, you get inconsistent package data.
I can't say I understand what you mean. I use both apt-get and aptitude, and there are no issues with data consisitancy.
And it's nearly impossible to force-remove a package (just delete all the damn files and forget about it!) if the associated removal script fails.
True, however the failure of such scripts is a critical bug, and will result in a package being kicked out of the release if not fixed. Anyway, when the need arises, it's hardly 'nearly impossible' to edit the offending {pre,post}rm script and (at worst) comment out the failing command.;)
I do not see how any reading of the license could result in your interpretation.
From the preamble:
Some countries have adopted laws prohibiting software that enables users to escape from Digital Restrictions Management. DRM is fundamentally incompatible with the purpose of the GPL, which is to protect users' freedom; therefore, the GPL ensures that the software it covers will neither be subject to, nor subject other works to, digital restrictions from which escape is forbidden.
This statement of intent bears no resemblance to your interpretation. Let's consult the actual terms of the license:
3. Digital Restrictions Management. I must therefore ask you to read the license.
As a free software license, this License intrinsically disfavors technical attempts to restrict users' freedom to copy, modify, and share copyrighted works. Each of its provisions shall be interpreted in light of this specific declaration of the licensor's intent. Regardless of any other provision of this License, no permission is given to distribute covered works that illegally invade users' privacy, nor for modes of distribution that deny users that run covered works the full exercise of the legal rights granted by this License.
No covered work constitutes part of an effective technological protection measure: that is to say, distribution of a covered work as part of a system to generate or access certain data constitutes general permission at least for development, distribution and use, under this License, of other software capable of accessing the same data.
Again, no mention is made of losing any rights granted by the GPL if you create Digital Restrictions Management systems.
Finally, you should realise that Linus has deliberatly made it all but impossible to relicense Linux under a newer version of the GPL. Linux has thousands, maybe tens of thousands of contributors, and therefore copyright holders--some of which are dead. The permission of each and every one of these (or their estates) must be obtained before Linux can be relicensed.
I'd rather live with the unmatched convenience of apt, than try to morph my system into some mix of Plan 9 and GNU/Linux.
At the end of the day, all our software is designed to work with the FHS, and no amount of fraglie automated scripts to create compatability directories for binaries, include files, library files, man pages, info pages, gstreamer elements, pam modules, iptables modules, firmware, bonobo components, gimp plugins, browser plugins, and so on ad infinitum is going to circumvent that.
Any program that requires QT to live in/usr/local/qt3, is *broken* in the first place. The FHS gives us well-defined search paths to locate files:
If you write your programs to #include <qt/qt.h>, not "/usr/local/qt3", and to have the libqt-mt.so.3 SONAME in DT_NEEDED, rather than (ugh) hard-coding in/usr/local/lib/qt3/lib/libqt.so.3, and so on, then you don't have to know where QT's files actually are. If you are curious, you can always find out with dpkg --listfiles libqt3-mt.
If the packages dumped all their stuff in/usr/local/$package, you would have to maintain an ever-growing list of directories in which to search for shared libraries, headers, binaries, man pages, etc. Personally I would prefer not to have PATH, LD_LIBRARY_PATH, MANPATH, CFLAGS, LDFLAGS, etc, environmental variables with 10,000 components!
Something else that you'd lose the ability to do is to share out/usr/share, to make *all* the arch-independant, data in an installation available to machines on a network. This is extremely useful when maintaining a large, heterogeneous network:
This hierarchy is intended to be shareable among all architecture platforms of a given OS; thus, for example, a site with i386, Alpha, and PPC platforms might maintain a single/usr/share directory that is centrally-mounted.
For example, how do we find libssl.so on an FHS-compliant system? Is it/usr/lib/libssl.so or/usr/local/lib/libssl.so, or even/opt/openssl/lib/libssl.so? The FHS ensures we will never have a simple, consistent name, like we would have if the package author madated it to be/package/host/openssl.org/openssl/libssl.so.
Bald erdash. Say you want to run a binary that declares in its DT_NEEDED that it requires SONAME libssl.so.0.9.7. ld-linux will consult ld.so.cache, which contains the mapping of DT_SONAME -> library files. As the user, I don't give a damn where libssl.so.0.9.7 actually lives--the dynamic loader takes care of that for me.
Contrast this with DJB's crackheaded/package system. My binary again has libssl.so.0.9.7 in DT_NEEDED. But now that there is no fixed set of directories for the loader to search for libraries; I am expected to edit/etc/ld.so.conf and re-run ldconfig every time I install a new library.
An alternative is to forsake the shared library cache alltogether, and maintain an ever-growing collection of PATH, LD_LIBRARY_PATH, etc, environmental variables. If I enjoyed hammering nails through my dick in this way, I'd swich to Solaris where this insanity seems to be accepted.:)
Hey, maybe I should I just switch to Windows, where the solution to this problem is for every app to ship private copies of the shared libraries that it requires in the same directory as its binaries, wasting disk space and causing uncounted security problems...:)
Relax, the only regular files under/usr/share/qt3 are arch-independent. Most of the files in there are symbolic links to the files' proper locations, presumably for the benefit of broken software/users who demand that everything lives in one directory.:)
Personally I can't stand Qt, but a cursory examination reveals that you can just pretend that Qt is installed to/usr/share/qt3 instead of/usr/local/qt3:
... and so on. The symlinks shipped by the Debian packages ensure compatibility with the (IME, inflexible and annoying) layout where everything is in a single directory.
Interesting, that's comprarable to the typical high-street price of a three-episode disc in the UK (£20). Entire-season sets seem to be much more affordable however--Amazon have the first season of Standalone Complex for £30, and the entire Cowboy Bebop for £60.
So if there is a comment there saying/* NSA backdoor here! */, you will believe that the flaw was deliberate, but if there is no such comment, you will still believe the flaw was deliberate?;)
Slashdot Mirror
When the kernl shifts to 4k stacks, Ndiswrapper will stop working. http://lwn.net/Articles/160138/
Then you haven't read much about the subject. http://lxr.linux.no/source/Documentation/stable_ap i_nonsense.txt
I just remembered, the driver works fine for most people with WPA. My problem was that I would have to bring the card up, transmit some packets, then bring it down and up again before I was able to recieve anything. The maintainer and I were unable to debug it further because I had no other wireless hardware to assist in the monitoring of what was really going on.
Works for me. I am using the 'beta3' release. The guy who maintains the driver is very helpful, if you can't get it to work ask for help on the forum. :)
As long as you don't need WPA, get a card with an rt2x00 series chip. The drivers work fine, though they are not yet good enough to be merged into the kernel. http://rt2x00.serialmonkey.com/
It's ironic that in setting out to 'solve' spam, Microsoft all but destroyed the momentum around SPF, fracturing it into several different, incompatible implementations.
According to TFA, "Sony has said that the Reader will be able to display content from RSS feeds and from PDF files in addition to e-books in Sony's own BBeB format". That does not rule out the possibility (more like probability, since we are talking about Sony here) that one must use Sony's Windows-only software to convert files into their proprietary format.
But will it actually read the foreign formats, or are Sony lieing like they usually do?
Chances are, the foreign formats are only 'supported' if you don't mind using their crappy Windows software to convert them to Sony's proprietry formats before copying them to the device.
That file is not part of Linux's source code distribution. This one, however, is. ;)
FYI, Debian and Ubuntu use the same installer.
> What's apt-get?
...why do I need to know all of this
http://debian.org/doc/
> What's cupsys?
apt-cache show cupsys
> What's cupsys-driver-gimpprint?
apt-cache show cupsys-driver-gimpprint
> What's cupsys-client?
apt-cache show cupsys-client
> What's cupsys-pt?
apt-cache show cupsys-pt
> And most importantly....
> stuff just to get the printer working in Debian?
Ah, you're a desktop user. Pick 'desktop' when prompted while installing and I believe all this stuff will be installed automatically. You can then go to Desktop -> Administration -> Printing to add your printer.
It's true that policy doesn't mandate the existance of a 'status' argument for init scripts; however, it does mandate that init scripts are idempotent, and in the few cases where I have genuinely wanted to check if a daemon is running rather than start/stop/restart/reload it, I just use the tools in procps.AFAIK, adduser is not supposed to. There can be no general frontend for modifying the data behind NSS, because it can be stored in so many different ways. If there are scripts in another distribution you would like to see packaged, please run 'reportbug wnpp' and fill in a Request For Package bug.This has nothing to do with ideology. The OpenSSL license is not compatible with the GPL, because it imposes additional restrictions on the use/modification of the GPLd code. It is simply illegal for Debian to distribute GPLd binaries linked to OpenSSL; anyone else who does so is opening themselves up to lawsuits. See the archives of debian-legal or OpenSSL and the GPL for further information.I can't say I understand what you mean. I use both apt-get and aptitude, and there are no issues with data consisitancy.True, however the failure of such scripts is a critical bug, and will result in a package being kicked out of the release if not fixed. Anyway, when the need arises, it's hardly 'nearly impossible' to edit the offending {pre,post}rm script and (at worst) comment out the failing command.
From the preamble:This statement of intent bears no resemblance to your interpretation. Let's consult the actual terms of the license:Again, no mention is made of losing any rights granted by the GPL if you create Digital Restrictions Management systems.
Finally, you should realise that Linus has deliberatly made it all but impossible to relicense Linux under a newer version of the GPL. Linux has thousands, maybe tens of thousands of contributors, and therefore copyright holders--some of which are dead. The permission of each and every one of these (or their estates) must be obtained before Linux can be relicensed.
Utter FUD. Please stop posting.
I'd rather live with the unmatched convenience of apt, than try to morph my system into some mix of Plan 9 and GNU/Linux.
At the end of the day, all our software is designed to work with the FHS, and no amount of fraglie automated scripts to create compatability directories for binaries, include files, library files, man pages, info pages, gstreamer elements, pam modules, iptables modules, firmware, bonobo components, gimp plugins, browser plugins, and so on ad infinitum is going to circumvent that.
If you write your programs to #include <qt/qt.h>, not "/usr/local/qt3", and to have the libqt-mt.so.3 SONAME in DT_NEEDED, rather than (ugh) hard-coding in
If the packages dumped all their stuff in
Something else that you'd lose the ability to do is to share out
Did you fill in an installation report, or even mail in a bug report?
Contrast this with DJB's crackheaded
An alternative is to forsake the shared library cache alltogether, and maintain an ever-growing collection of PATH, LD_LIBRARY_PATH, etc, environmental variables. If I enjoyed hammering nails through my dick in this way, I'd swich to Solaris where this insanity seems to be accepted.
Hey, maybe I should I just switch to Windows, where the solution to this problem is for every app to ship private copies of the shared libraries that it requires in the same directory as its binaries, wasting disk space and causing uncounted security problems...
Relax, the only regular files under /usr/share/qt3 are arch-independent. Most of the files in there are symbolic links to the files' proper locations, presumably for the benefit of broken software/users who demand that everything lives in one directory. :)
Personally I can't stand Qt, but a cursory examination reveals that you can just pretend that Qt is installed to /usr/share/qt3 instead of /usr/local/qt3:
/usr/share/qt3/ ../../include/qt3 ../../lib/qt3/plugins
/usr/share/qt3/lib ../../../lib/libqt-mt.prl ../../../lib/libqt-mt.so.3.3.5
$ ls -l
total 16
drwxr-xr-x 2 root root 4096 2006-01-11 02:53 bin
drwxr-xr-x 3 root root 4096 2005-10-04 11:30 doc
lrwxrwxrwx 1 root root 17 2006-01-11 02:52 include ->
drwxr-xr-x 2 root root 4096 2006-01-11 02:52 lib
drwxr-xr-x 61 root root 4096 2006-01-11 02:53 mkspecs
lrwxrwxrwx 1 root root 21 2006-01-11 02:52 plugins ->
$ ll
total 0
lrwxrwxrwx 1 root root 25 2006-01-11 02:52 libqt-mt.prl ->
lrwxrwxrwx 1 root root 30 2006-01-11 02:52 libqt-mt.so ->
... and so on. The symlinks shipped by the Debian packages ensure compatibility with the (IME, inflexible and annoying) layout where everything is in a single directory.
You could call it a 3-cybe, or a 3^3 cube.
Interesting, that's comprarable to the typical high-street price of a three-episode disc in the UK (£20). Entire-season sets seem to be much more affordable however--Amazon have the first season of Standalone Complex for £30, and the entire Cowboy Bebop for £60.
So if there is a comment there saying /* NSA backdoor here! */, you will believe that the flaw was deliberate, but if there is no such comment, you will still believe the flaw was deliberate? ;)