As a matter of fact, some people are fed up with Vista enough to switch to a Mac or Linux. Fedora Linux has come a long way which provides a free operating system and desktop applications, all for free.
squalyl (./639) :
ceci dit ils sont un peu cons de pas dire que le soft est totalement en vrac et n'évolue plus en attendant une refonte complète de tous les frameworks...
squalyl (./638) :
on t'a déja dit que tu te touchais avec le tpm.
http://www.gizmodo.fr/2008/07/02/microsoft_midori_un_systeme_dexploitation_postwindows_secret.html
de Holger Freyther <zecke@openmoko.org>
à distro-devel@lists.openmoko.org
date 23 juin 2008 04:05
objet Qtopia/X11 Weekly Status (15)
liste de diffusion distro-devel.lists.openmoko.org
envoyé par lists.openmoko.org
Hey,
another late update on the Qtopia/X11 ASU work we did.
distro work:
- Upgrading of Openmoko developed software (exposure, illume..)
- opkg fixes by thos and tick
- testing building ASU stable on fedora9 and creating patches
- merged gmp-native and ipkg-utils fixes/changes from OE.dev to fix
buildproblems.
asu work:
- Upgraded to latest stable kernel (currently without the big suspend/resume
changes by Andy) to make hald enumerate the wireless device
- moved xglamo to git.openmoko.org and fixed the keyboard "bug". power key
and other keys should be reported (not yet in stable)
qtopia work:
- Attempt at easy optimisation for speed increase by not doing a debug build,
by disabling most qLog statements. No real success
- setting datetime didn't work, fixed a bug in QtopiaApplication::exec for
that.
- reworked the softmenu handling to be race free, success.
- fixed various bugs QA reported (see the ASU milestone in the bugtracker)
kernel (mostly andy):
- work on suspend/resume fixes continue
- charging LED support
- improving the touchscreen support.
upcoming work:
- Work on "latency" of call handling
- Call handling
- Qt/X11 performance with xglamo
- Bug fixes for whatever QA reports
as usual, questions and comments to the list are welcome
z.
squalyl (./643) :
c'est by design, pas une limitation des composants.
correct. yuv will be w * h * 1.5 bytes for 1 frame (standard video yuv). so 3240x240*1.5*30 (320x240 @ 30fps) = 3.4m/sec - BUT... when u are copying you have ZERO cpu cycles to decode the next video frame. so that means 50% of cpu cycles will be spent ONLY copying video data to video ram. the other 50% u have left to decode the mpeg1/2/4 or whatever video in system ram to a yuv buffer. i would say this is the realistic highest resolution you will get. 480x320@30fps is the MOST you will get (6.9m/sec), but u have ZERO (or almost) cpu cycles to actually decode the video into yuv. remember here i am assuming use of xvideo and the yuv to rgb conversion and scaling on the glamo - which xglamo does support. if you do software yuv->rgb + scale then its even less fun. with software. the best u will get is 11fps at 640x480 - and this is NO cpu cycles to actually decode the video, convert it to 16bit rgb and scale. in reality i expect you to see 2-5fps in this scenario, maybe eve 1fps.
squalyl (./643) :
Kevin> inscris toi à la mailing list openmoko-distro-devel tu verras dans quel état il est le qtopia-x11
squalyl (./646) :
ils ont mal gaulé le bus système du coup il peut pas trimballer assez de débit pour faire du fullscreen vga!
j'espère que ça donnera pas raison à jul (mais y'a pas carcassonne, dommage )
Lionel Debroux (./640) :
Le TPM permet de faire des choses mauvaises pour l'utilisateur... mais si tu ne chiffres pas le contenu du disque en utilisant Bitlocker (à supposer qu'il utilise le TPM unique à chaque machine pour le chiffrage), le contenu du disque ne va pas être illisible sur une autre machine
