Bug#509689: ITP: libjinput-java -- portable joystick and gamepad library for java
Package: wnpp Severity: wishlist Owner: Johan Henriksson * Package name: libjinput-java Version : 0.0.20081224 Upstream Author : Jeff Kesselman et al * URL : https://jinput.dev.java.net/ * License : BSD3 Programming Lang: Java+C Description : portable joystick and gamepad library for java The JInput Project hosts an implementation of an API for game controller discovery and polled input. It is part of a suite of open-source technologies initiated by the Game Technology Group at Sun Microsystems with intention of making the development of high performance games in Java a reality. . The API itself is pure Java and presents a platform-neutral completely portable model of controller discovery and polling. It can handle arbitrary controllers and returns both human and machine understandable descriptions of the inputs available. . The implementation hosted here also includes plug-ins to allow the API to adapt to various specific platforms. These plug-ins often contain a native code portion to interface to the host system. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Atlas proposal
Just ship two packages: libatlas3gf-base and libatlas3gf-auto, with appropriate Conflicts/Provides just as we have now. And have libatlas3gf-auto depend on all build-dependencies, ship the source, and build itself in its postinst. Gentoo-style. was about to suggest this, this is the only feasible way. changing atlas to be dynamic (with maximum performance kept) might not require anything less than a rewrite, fftw-style. that in turn might require changes to all code invoking the library. while I don't mind having it done, this is not for debian developers. /Johan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c6b821d.2040...@areta.org
Re: deprecating /usr as a standalone filesystem?
> Well, some people argued for that. Like you, I'm wondering how one > actually does this in practice! However there are some rather more > reasonable uses which have been mentioned: > > - read-only /usr (for security) > - backups > - recovery (ability to mount root only; important if there's fs corruption) > - on-line resizing > - using LVM and/or RAID > (Note: With modern Debian initramfs it is quite possible to have >/ on LVM [on RAID] since so long as /boot lives outside the >initramfs can bring up RAID and initialise LVM to mount the >rootfs. The system I'm physically typing this on has such a >setup.) > I keep a /usr because I suspect it gives more performance. unlike the rest of the disk, one doesn't read and write it all the time, so fragmentation should be less if it is kept separate. one can also use a filesystem type more suitable for this behaviour (reiserfs is probably not optimal) /Johan -- -- Johan Henriksson MSc Engineering PhD student, Karolinska Institutet http://mahogny.areta.org http://www.endrov.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#531221: okular: Arbitrarily enforces DRM
Mike Hommey wrote: > On Sun, May 31, 2009 at 03:54:29PM +0200, Sune Vuorela wrote: > >> On Sunday 31 May 2009 15:32:25 John Goerzen wrote: >> >> >> >>> #2 and #4 especially should be exceptionally trivial patches. >>> >>> Why are you tagging it wontfix, Sune? >>> >> I see no reason to deviate from upstream's choices here, no matter how >> trivial >> the patches are. >> >> Here is no bug, so here is nothing to fix. >> >> There is a design decision you don't like, well. Learn to live with it. >> >> If upstream changes, we will follow, though. >> Just because we *can* patch things does not mean we should. >> >> And I consider this debate closed, and please find a different battle field >> that >> doesn't involve me for fighting DRM. >> > > Note that consistency between the pdf readers within the distro is > worth keeping the debate open. > if we wanted consistency then we would stick to a single PDF reader and throw out the rest. if they all work the same then what's the point in maintaining all of them? /Johan > Mike > > > -- -- Johan Henriksson MSc Engineering PhD student, Karolinska Institutet http://mahogny.areta.org http://www.endrov.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Let’s turn DEP5 into something usefu l
managed to ignore this discussion until now but anyway tossing in a coin. would it not be more interesting to standardize the format beyond debian? if you get upstream authors and language designers to supply the files then more "expensive" formats can be used, with less cost for us. and it would benefit other distributions as well. -- -- -------- Johan Henriksson MSc Engineering PhD student, Karolinska Institutet http://mahogny.areta.org http://www.endrov.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Long] UEFI support
On Fri, Jan 6, 2012 at 6:55 PM, Ben Hutchings wrote: > On Fri, Jan 06, 2012 at 02:41:41PM +, Tanguy Ortolo wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > Hello all, > > > > UEFI (often called EFI, which was the name of its previous version) is a > > new firmware interface, which is expected to replace the BIOS on new > > PCs, as at has already done so on Apple PCs. While modern operating > > system do not rely much on firmware calls for normal operation, the boot > > loader does. > > As I understand it, almost all new PCs for sale today have UEFI and a > BIOS compatibility layer on top. So this replacement has already > happened. > I recently set up a linux server and do see a need for linux to boot on UEFI without relying on BIOS. The reason is the limitations of the size of the booting harddrive. there are hacks around this (multiple MBRs) but these would upset for example a dual-booting windows. this also doesn't chime well when persuading new users to try out linux. so, in my opinion, debian should be among the first to support UEFI well and to show that linux can be first rate in hardware support. one challenge for the installer will be how to support manual partitioning while making installation of the uefi boot partition easy. if there is none then debian should suggest to create it, with good default settings. /Johan -- --- Johan Henriksson PhD student, Karolinska Institutet http://mahogny.areta.org http://www.endrov.net
Re: Bug#656142: ITP: duff -- Duplicate file finder
> > Ah, right. So you'll start writing yet another tool? ;) > > I've implemented pretty much that (http://liw.fi/dupfiles), but my > duplicate file finder is not so much better than existing ones in > Debian that I would inflict it on Debian. But the algorithm works > nicely, and works even for people who research hash collisions. > > since we're onto this topic - a while ago I needed a duplicate finder that could identify not only identical files but also identical folders. it has a bunch of algorithms in there, and can make approximate searches as well (for performance). but does anyone know if there is a tool like this already or do I have a reason to continue developing it? /Johan -- ------- Johan Henriksson PhD student, Karolinska Institutet http://mahogny.areta.org http://www.endrov.net
