Fedora People
Michael DeHaan: By the power ... of .. Greyskull?
Recently on the cobbler development branch several of us have been working to integrate power management features, among other things, for Cobbler 1.4. Patch activity has been huge lately and I'm enormously thankful for everyone involved.
Anyway, the idea is, since we're already handling all the low-level services needed for automated datacenter deployment and re-deployment (DNS, DHCP, TFTP, HTTP, syslog, etc) -- why not also do power management? It's easy.
You can read about this here: PowerManagement.
Shortly all of this will also be available to XMLRPC consumers of Cobbler, so I expect to see a lot more applications using it to provide install and low-level datacenter-management services.
The next feature to conquer is probably Roomba integration.
Sami Wagiaalla: GDB (Archer) Updates
So! I have been working on GDB for a while now as part of the Archer project. Specifically C++ expression evaluation. More specifically lookup issues.
GDB has a lot of issues around namespace lookup a good chunk of which are hopefull fixed now in my branch.
Here are some issues that have been fixed:
namespace imports:
namespace A{ int x = 9; } int main(){ using namespace A; x; } (gdb) break main ... (gdb) run ... (gdb) print x $1 = 9namespace aliases:
namespace A{ int x = 9; } namespace B=A; int main(){ B::x; } (gdb) break main ... (gdb) run ... (gdb) print B::x $1 = 9Imports if individual elements from namespaces:
namespace A{ int x = 9; int y = 99; } using A::x; int main(){ x; } (gdb) break main ... (gdb) run ... (gdb) print x $1 = 9 (gdb) print y No symbol "y" in current context.If you want to try the above you can checkout the archer gdb branch:
git clone git://sourceware.org/git/archer.gitThen checkout my branch:
cd archer; git branch archer-swagiaal-using-directive origin/archer-swagiaal-using-directive; git checkout archer-swagiaal-using-directiveNext post I will talk about issues that I am still working on.
Sebastien Bilbeau: Linux distros VS Microsoft’s homepage uptime
Toutes les distributions Linux ont aujourd’hui leur propre site Internet. On peut donc supposer qu’ils sont hébergés sur le même système d’exploitation, que celui dont ils font la promotion.
En partant de ce principe, Pingdom a réalisé une enquête pendant un mois pour savoir quels étaient les sites qui plantaient le moins souvent. Afin de rendre cette étude encore plus intéressant, ils ont décidé de rajouter ceux de Microsoft et d'Apple.
Et voici le résultat obtenu :
Apple s'en sort pas trop mal, par contre pour Microsoft c'est légèrement moins bien. On notera également que les distributions à base de Redhat (Fedora, Knoppix, CentOS...) sont en haut du podium avec moins de 2 minutes d'indisponibilité.
L'article complet est lisible ici :
royal.pingdom.com
Sebastien Bilbeau: Linux distros VS Microsoft’s homepage uptime
Toutes les distributions Linux ont aujourd’hui leur propre site Internet. On peut donc supposer qu’ils sont hébergés sur le même système d’exploitation, que celui dont ils font la promotion.
En partant de ce principe, Pingdom a réalisé une enquête pendant un mois pour savoir quels étaient les sites qui plantaient le moins souvent. Afin de rendre le résultat encore plus intéressant, ils ont décidé de rajouter ceux de Microsoft et d’Apple.
Et voici le résultat obtenu :
Apple s’en sort pas trop mal, par contre pour Microsoft c’est légèrement moins bien. On notera également que les distributions à base de Redhat (Fedora, Knoppix, CentOS…) sont en haut du podium avec moins de 2 minutes d’indisponibilité.
L’article complet est lisible ici :
royal.pingdom.com
Richard Jones: LWN.net has an interview with us about MinGW Windows cross-compiler
http://lwn.net/Articles/307732/
If you're not an LWN subscriber, you can use this free link to get to the article:
http://lwn.net/SubscriberLink/307732/0efc7b75c5696ae5/
Please consider subscribing to LWN!
Rakesh Pandit: Entrans plugin sort of ready - FOSS.in workout update
Still needs some work. Patch here. Pootle, kbabel, lokilizer are all on cards. Lets see where it reaches.
Note: Download and open in an desktop editor rather then checking in browser. Browser renders patch.
Greg DeKoenigsberg: La Dolce Vita: chapter 2
Why did we choose Matchbox to run Sugar? Because (a) we cared chiefly about a full-screen windowing mode, and (b) Matchbox fit nicely into the small memory footprint on the XO, and (c) we didn't care about compatibility with legacy applications, because Sugar activities were going to RULE THE WORLD!
It's probably time to move beyond Matchbox, and it shouldn't be too difficult to do -- one of the nice things about the structure of X is that the window manager really is quite modularized. And the big new requirement, which Matchbox doesn't deal with well, is to deal gracefully with applications that really do need multiple windows. For instance: running Gimp would be truly nightmarish under Sugar, and would be very difficult to Sugarize. It would be mighty nice if such applications "degraded" gracefully.
Scott is looking at Awesome, which is a tiled window manager that also has a compatibility mode that allows for floating layers. There are other tiled window managers being considered; everyone's got their favorite, of course, but it does look like Awesome is in the lead right now.
We should also be using the standard notification, alert mechanisms, and system tray specs that freedesktop.org supports. (Seems like the only reason this hasn't been done so far has been time.) Here's what that means to me: when I use my IRC client in GNOME and someone says "hello gregdek," I get a glowing icon on my system tray. (Yaaay! Somebody likes me!) But XoIRC, right now, is incapable. Which makes IRC much less useful for me (although I'll probably get more done.) This is an opportunity to work directly with the folks at freedesktop.org, and this is important; if Sugar is to be viable, we must learn to work with other projects and take advantage of the work they've already done. What will these notifications look like in Sugar, exactly, which currently doesn't have a "system tray", per se? Unclear, but thankfully Eben is really good at solving these kinds of problems.
Finally, there is the question about the fundamental difference between "Sugar activities", which the current UI relies upon and expects, and "Linux applications", which the current UI completely ignores. As the real-world deployments grow, the need to consume non-Sugarized Linux applications grows with it. Having a window manager that handles this problem gracefully is only a first step: necessary, but not sufficient. Follow-on questions come up quickly. If Audacity isn't Sugarized, how do you even find it? Do you put a lightweight Sugar "launching" wrapper around Linux applications?
Seems like most of these things are making their way on the roadmap this week. That's a Good Thing. It's been a really productive session.
Harish Pillay 9v1hp: Chumby, my Chumby!
Harish Pillay 9v1hp: Thanks for a good reference
Nicu Buculei: Photoblog
Of course I could use tags to filter the topics, but I don't want to be that restrictive and let from time to time some offtopic posts, so after some deliberation I decided to start a new blog, dedicated to photography (don't hurry up there, you won't find any upskirt photo), this way I can have a cleaner layout, a simpler navigation and a better URL.
With the launch of the new blog I did an important amount of preparation work: using scheduled post with a date in the past I populated the blog with photos from all those months since I have my current camera.
Of course I will still post photos here, but only when I think the subject is worthy. And, of course, the content on the new blog is also Free.
Harish Pillay 9v1hp: 2008 E&Y Entrepreneur of the Year
Kulbir Saini: Fedora: How to configure caching-nameserver (named) in cascading mode
To configure a caching nameserver on a local machine which will cascade to another previously configured and functional nameserver (may or may not be caching. It'll generally be your ISP nameserver or the one provided by your organization).
Advantage- Reduces the delay in domain name resolution drastically as the requests for frequently accessed websites are served from cache.
- named gets a request for domain resolution.
- It checks whether the request can be satisfied from cache. If the answer is in cache and not stale, the request is satisfied from cache itself saving a lot of time :)
- If request can't be satisfied from cache, named queries the first parent. If it replies with the answer, then named will cache the response and subsequent requests for the same domain name will be satisfied from the cache.
- In case first parent fails to reply, named will query the second parent and so on.
(The working is my understanding of caching-nameserver using wireshark as traffic analysis tool and caching-nameserver may not behave exactly as explained above.)
How to installnamed is by default on most of the systems by the package name 'caching-nameserver'. If its not present on your system, install using
[root@localhost ~]# yum install caching-nameserver [ENTER]
<!--break-->
How to configureThe main configuration file for named resides in /var/named/chroot/etc/named.caching-nameserver.conf which is also soft linked from /etc/named.caching-nameserver.conf . named configuration file supports C/C++ style comments.
For a caching nameserver which will cascade to another nameserver, there is nothing much to be configured. You need to configure "options" block. Below is a configuration file for a machine with IP address 172.17.8.64 cascading to two nameserver 192.168.36.204 and 192.168.36.210. The comments inline explain what each option does.
options { // Set the port to 53 which is standard port for DNS. // Add the IP address on which named will listen separated by semi-colons. // It'll be your own IP address. listen-on port 53 {127.0.0.1; 172.17.8.64;}; // These are default. Leave them as it is. directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; // The machines which are allowed to query this nameserver. // Normally you'll allow only your machine. But you can allow other machines also. // The address should be separated by semi-colons. To allow a network 172.16.31.0/24, // the line would be // allow-query {localhost; 172.16.31.0/24; }; // Don't forget the semi-colons. allow-query { localhost; 172.17.8.64; }; recursion yes; // The parent nameservers. List all the nameserver which you can query. forwarders { 192.168.36.204; 192.168.36.210; }; forward first; }; logging { channel default_debug { file "data/named.run"; severity dynamic; }; }; zone "." IN { type hint; file "named.ca"; }; include "/etc/named.rfc1912.zones"; Start caching-nameserver
Now start the caching-nameserver using the following command
[root@localhost ~]# server named start [ENTER]
OR
[root@localhost ~]# /etc/init.d/named start [ENTER]
To make named start every time your reboot your machine use following command
[root@localhost ~]# chkconfig named on [ENTER] Using caching-nameserver
To use your caching-nameserver, open /etc/resolv.conf file and add the following line
nameserver 127.0.0.1
Comment all other lines in the file, so that finally the file looks like
; generated by /sbin/dhclient-script #search wlan.iiit.ac.in #nameserver 192.168.36.204 #nameserver 192.168.36.210 nameserver 127.0.0.1
Now your system will use your own nameserver (in caching mode) for resolving all domain names. To test if your nameserver use the following command
[root@localhost ~]# dig fedora.co.in [ENTER]
Now if you use that command for the second time, the resolution time will be around 2-3 milli seconds while first time it would be around 400-700 milli seconds.
Example
Below is two subsequent runs of dig for fedora.co.in . Notice the Query time.
[root@bordeaux SPECS]# dig fedora.co.in ; <<>> DiG 9.4.2rc1 <<>> fedora.co.in ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7839 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;fedora.co.in. IN A ;; ANSWER SECTION: fedora.co.in. 83629 IN A 72.249.126.241 ;; AUTHORITY SECTION: fedora.co.in. 79709 IN NS ns.fedora.co.in. ;; ADDITIONAL SECTION: ns.fedora.co.in. 79709 IN A 72.249.126.241 ;; Query time: 531 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Nov 19 18:04:47 2008 ;; MSG SIZE rcvd: 79 [root@bordeaux SPECS]# dig fedora.co.in ; <<>> DiG 9.4.2rc1 <<>> fedora.co.in ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64233 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;fedora.co.in. IN A ;; ANSWER SECTION: fedora.co.in. 83625 IN A 72.249.126.241 ;; AUTHORITY SECTION: fedora.co.in. 79705 IN NS ns.fedora.co.in. ;; ADDITIONAL SECTION: ns.fedora.co.in. 79705 IN A 72.249.126.241 ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Nov 19 18:04:51 2008 ;; MSG SIZE rcvd: 79 [root@bordeaux SPECS]#
Marek Mahut: Multiple host names in a single kerberos key tab
If you are using clustered service with kerberos, you may want to merge hostnames keytab files to one for simple distribution.
- Create host and service principals.
- Save them to only one file (cluster.keytab).
- As alternative, you can use command ktutil if you already have a bunch of keytab files.
Voila.
Ismael Olea: Huelga de informáticos
Tanto OSOR.eu parriba y OSOR pabajo ni me había dado cuenta de que no había escrito nada sobre la huelga de informáticos. Aprovechando que no me la ha pedido nadie, he aquí mi opinión.
Estoy a favor de una huelga general del sector, porque nuestro sector es una mierda. Y esta cuestión forma parte de mi discurso habitual.
Estoy en contra de ésta huelga porque está convocada por los colegios de informática para los intereses de los colegios de informática, que ni son los mismos que los del sector ni, en mi opinión, de la mayoría de los que somos titulados informáticos.
Los colegios son un monopolio legal y llevo más de 10 años de actividad y resistencia contra toda clase de monopolios.
Realmente me encantaría poder ofrecer un análisis razonado de esta postura, pero las limitaciones de tiempo y mi escala de prioridades lo impiden de momento.
Guillaume Kulakowski: MSI Wind, Fedora 10 et la webcam out-of-the-box
Je viens de réussir à faire marcher la webcam de mon MSI Wind sans aucun autre module que ceux compris de base dans le kernel 2.6.27.
Pour cela, c'est simple, on décharge le module uvcvideo d'origine et on le recharge avec le bon paramètre :
root@saratoga ~> rmmod uvcvideoroot@saratoga ~> modprobe uvcvideo quirks=2
L'autre solution est de faire un fichier /etc/modprobe.d/webcam
options uvcvideo quirks=2Grâce aux efforts fait dans Fedora 10 pour avoir le meilleur des supports webcam, Cheese et autres Ekiga fonctionnent parfaitement avec V4L2 et la compatibilité V4L1 reste assurée.
Fabian Affolter: Analysing tool for Sugar
Dimitris Glezos: FLSCo elections “F10″ coming up
A Fedora release is approaching, and so does the elections for the Fedora Localization Steering Committee. The Nominations page is open.
Six months ago, a few folks in L10n proposed to have a SCo for translations. Ηaving a group of people as a SCo serves to complement and augment a bigger project like Fedora translations, which belongs to an even bigger project and community. It does so by encouraging work within reasonable bounds of efficiency and sanity, and help guide and answer questions which come to the surface as a result of the community activity.
Getting down to business, what does FLSCo exactly provide?
- Guidance: Some of FLP’s most experienced people have served on FLSCo, and are often expected to provide answers to tough questions about FLP’s position on the map of Fedora’s sub-projects, its infrastructure and path, etc.
- Confidence: Act as the community’s stamp of approval, so that folks both from outside and inside the FLP can feel confident that a decision represents the whole project.
- Accountability: Maintain core bits of the FLP’s tools, ensuring things are working when they really should.
- Frequent meetings: Meet frequently to discuss any topics which haven’t been discussed on our lists and give an open floor to anyone wanting to raise any other issue, in addition to the mailing list.
What do we usually practically do as FLSCo?
- Meet frequently (every two weeks more or less) on an open IRC meeting
- Take typical decisions that affect other projects, like how to deal with a string freeze, etc
- Represent FLP’s needs in Fedora Release and Board meetings
- Meet face to face in Fedora conferences and talk about translations
- New: Spend on average 1-2 hours per week on FLP stuff
If you’d like to be part of this group, do put your name up on the nominations page. This time we’ve got 3 seats for election.
Guillaume Kulakowski: Communiquez
L'actualité autour de Fedora va s'avérer riche en évènements, alors, communiquez dessus...
Le compteur annonçant la sortie de Fedora 10 alias Cambridge :
<script id="fedora-banner" type="text/javascript" src="http://fedoraproject.org/static/js/release-counter-ext.js?lang=fr"></script>Les bannières pour annoncer l'Install Party Parisienne :
Dave Airlie: lessons learned writing a kernel memory managed driver
2. X does rendering without the vtSema, including hw calls. So if you invalidate the 3D state flags in EnterVT its too late, X has already sent command to the card without resending the state. So invalidate your state in LeaveVT as well.
3. Kernel memory management is a messy problem. The GPU has a finite amount of addressable memory it can use. On modern GPUs, this is either a single GART (like Intel) or VRAM + GART (like everyone else). So userspace applications like X or 3D apps, submit command buffers to the kernel, and along with a single command buffer there is a list of referenced data buffers. These data buffers can be pixmaps src/dst/mask, textures, vbos, fbos whateva. The userspace gives the kernel this list along with acceptable placement parameters. (GEM API uses a set of read domains, and a single write domain). If the buffer is to be written to it needs to end up in the write domain, for reading it might be acceptable in a few places. So on my radeon driver for example it is acceptable to read the buffer from either GART or VRAM, but only write to VRAM buffers. So when the kernel gets this list of buffers it tries to fit them in as well as it can. Now if the kernel can't fit these buffers in, we are in a bind. The naive person would just say fallback to software, and I spit on them. Because building the command buffers happens over time, the operation list and codepaths that generated the command stream have all been done. So we can't just go back and redo the operations in software fallbacks. So we run into the problem that userspace cannot reference more buffers in the command stream than the kernel can relocate into memory at once.
Rule 1: The kernel cannot fail to complete the command stream under any circumstances.
The two ways around this - are insert places in the command stream where its legal to break it up or have userspace flush the command stream when it hits a limit on the buffers.
For radeon I've done the latter. At startup the kernel tells X the amount of dynamic VRAM and GART it has to play with.
Then before each operation in the 2D driver, I sum up all the buffers it references for read and write, and then compare the write with the amount of VRAM and read with the amount of GART. If a single operation cannot fit at all in VRAM/GART, then sw fallback it. If the current op + total of ops in the list doesn't fit, flush before the current op and try again.
Now this works up until it falls over in a heap.
Why? Well firstly if a buffer was just written to in a previous cycle, it will be in VRAM, however X doesn't know or care where the buffer lives, so when it submits a read for it, it totals it against the GART read space, and when the kernel goes to fit everything in, it already has left that buffer in VRAM taking away from the write space. So to solve that I have the kernel do a two pass, it validates all the writeable buffers first (which if not enough space will kick out the readable buffer), the validates all the readable buffers (which will pull it back into the GART).
So this works great until it falls over in a heap.
So you submit the kernel a load of command streams over time, and VRAM gets a bit fragmented. So you have 20MB of dynamic VRAM,
you have 5MB of 1MB buffers, then 10MB free, then 5MB of 1MB buffers, you have 13MBs in 3 buffers (1MB, 1MB, 11MB), the two 1MB buffers are just before the 10MB and just after it. So the command stream validates those two buffers at those two points, then goes to validate the 11MB buffer, and goes all wtf? and it fails. See rule. 1.
Of course per-context GART tables ma
So now I needz defragmenation. Simple defragmentation is to kick out all the dynamic buffers from VRAM and revalidate them in order so they all fit in. Its messy but it should mean I get a system that doesn't violate Rule. 1.
Now I'll probably like to think about inserting scheduling points in the stream, but I'm not sure how well that wins, and whether I'd still have to worry about the fragmentation issue somehow.
Of course per-context GART tables and page table addressable VRAM makes all of this stuff a lot easier, or at least push the problem out to a lot harder to hit boundary, however see the first point I made.
So if you are ever in the enviable position of writing a kernel memory manager for a graphics card, allow me to buy you some spirits.
Peter Hutterer: evdev 2.1 is out
One of the important things here (especially if you're a distributor): evdev 2.1 does not call EVIOCGRAB on the device anymore. Either patch it in again, or update your server to one that doesn't require it (1.5.3 will do).
Here's a short list of new features that have been added since 2.0:
- axis inversion
- touchscreen support (those that don't report BTN_LEFT)
- run-time calibration for absolute devices
- axis swapping
- mouse wheel emulation
- drag lock
Also included is property support for run-time configuration. We don't have a released server that provides this option yet, but it'll be good for a test-bed until 1.6 comes out.
The properties also caused the long wait for the release, I wanted to wait until the server API had settled down. The next release will be sooner. The proposed release date for X server 1.6 is
Jan 5 2009. Evdev 2.2 will be released by Jan 5 2009 as well.
A great thanks to Adam Jackson, Ander Conselvan de Oliveira, Chris Salch, Dan Nicholson, Daniel Stone, Fernando Carrijo, Julien Cristau, Keith Packard, Michel Dänzer, Simon Munton, and Søren Hauberg for their patches.