Luc Verhaegen
posted at
libvOld and new limare code, and management overhead...
I just pushed updated limare code and a fix to ioquake3.
In almost 160 patches, loads of things change:
As for performance, this is no better or worse than the FOSDEM code. 47fps on timedemo on the Allwinner A10 at 1024x600. But now on the Exynos 4, there are some new numbers... With the CPU clocked to 2GHz and the Mali clocked to 800MHz (!!!) we hit 145fps at 720p and 127fps at 1080p. But more on that a bit further in this post.
Shortly after FOSDEM, i blogged about the 2% performance advantage over the binary driver when running Q3A.
As you might remember, we are using ARMs kernel driver, and despite all the pain that this is causing us due to shifting IOCTL numbers (whoever at ARM decided that IOCTL numbers should be defined as enums should be laid off immediately) I still think that this is a useful strategy. This allows us to immediately throw in the binary driver, and immediately compare Lima to the binary, and either help hard reverse engineering, or just make performance comparisons. Rewriting this kernel driver, or turning this into a fully fledged DRM driver is currently more than just a waste of time, it is actually counterproductive right now.
But now, while bringing up a basic mesa driver, it became clear that I needed to work on some form of memory management. Usually, you have the DRM driver handling all of that, (even for small allocations i think - not that i have checked). We do not have a DRM driver, and I do not intend to write one in the very near future either, and all I have is the big block mapping that the mali kernel driver offers (which is not bad in itself).
So in the train on the way back from linuxtag this year, I wrote up a small binary allocator to divide up the 2GB of address space that the Mali MMU gives us. On top of that, I now have 2 types of memory, sequential and persistent (next to UMP and external, for mapping the destination buffer into Mali memory), and limare can now allocate and map blocks of either at will.
The sequential memory is meant for per-frame data, holding things like draws and varyings and such, stuff that gets thrown away after the frame has been rendered. This simply tracks the amount of memory used, adds the newly requested memory at the end, and returns an address and a pointer. No tracking whatsoever. Very lightweight.
The persistent memory is the standard linked list type, with the overhead that that incurs. But this is ok, as this memory is meant for shaders, textures and attribute and element buffers. You do not create these _every_ draw, and you tend to reuse them, so it's acceptable if their management is a bit less optimized.
Normally, more management makes things worse, but this memory tracking allowed me to sanitize away some frame specific state tracking. Suddenly, Q3A at 720p which originally ran at 145fps on the exynos, ran at 176fps. A full 21% faster. Quite some difference.
I now have a board with a Samsung Exynos 4412 prime. This device has the quad A9s clocked at 1.7GHz, 2GB LP-DDR2 memory at 880MHz, and a quad PP Mali-400MP4 at 440MHz. This is quite the powerhouse compared to the 1GHz single A8 and single PP Mali-400 at 320MHz. Then, this Exynos chip I got actually clocks the A9s to 2GHz and the mali to a whopping 800MHz (81% faster than the base clock). Simply insane.
The trouble with the exynos device, though, is that there are only X11 binaries. This involves a copy of the rendered buffer to the framebuffer which totally kills performance. I cannot properly compare these X11 binaries with my limare code. So I did take my new memory management code to the A10 again, and at 1024x600 it ran the timedemo at 49.5fps. About a 6% margin over the binary framebuffer driver, or tripling my 2% lead at FOSDEM. Not too bad for increased management, right?
Anyway, with the overclocking headroom of the exynos, it was time for a proper round of benchmarking with limare on exynos.
The above picture, which I quickly threw together manually, maps it out nicely.
Remember, this is an Exynos 4412 prime, with 4 A9s clocked from 1.7-2.0GHz, 2GB LP-DDR2 at 880MHz, and a Mali-400MP4 which clocks from 440MHz to an insane 800MHz. The test is the quake 3 arena timedemo, running on top of limare. Quake 3 Arena is single threaded, so apart from the limare job handling, the other 3 A9 cores simply sit idle. It's sadly the only good test I have, if someone wants to finish the work to port Doom3 to gles, I am sure that many people will really appreciate it.
At 720p, we are fully CPU limited. At some points in the timedemo (as not all scenes put the same load on cpu and/or gpu), the difference in mali clock makes us slightly faster if the cpu can keep up, but this levels out slightly above 533MHz. Everything else is simply scaling linearly with the cpu clock. Every change in cpu clock is a 80% change in framerate. We end up hitting 176.4fps.
At 1080p, it is a different story. 1080p is 2.25 times the amount of screen real estate of 720p (if that number rings a bell, 2.25MB equals two banks of Tseng ET6x00 MDRAM :p). 2.25 times the amount of pixels that need to pushed out. Here clearly the CPU is not the limiting factor. Scaling linearly from the original 91fps at 440MHz is a bit pointless, as the Q3A benchmark is not always stressing CPU and GPU equally over the whole run. I've drawn the continuation of the 440-533MHz increase, and that would lead to 150fps, but instead we run into 135.1fps. I think that we might be stressing the memory subsystem too much. At 135fps, we are pushing over 1GBps out to the framebuffer, this while the display is refreshing at 60fps, so reading in half a gigabyte. And all of this before doing a single texture lookup (of which we have loads).
It is interesting to see the CPU become measurably relevant towards 800MHz. There must be a few frames where the GPU load is such that the faster CPU is making a distinguishable difference. Maybe there is more going on than just memory overload... Maybe in future i will get bored enough to properly implement the mali profiling support of the kernel, so that we can get some actual GP and PP usage information, and not just the time we spent waiting for the kernel job to return.
I have recently learned, from a very reliable source, that ARM management seriously dislikes the Lima driver project.
To put it nicely, they see no advantage in an open source driver for the Mali, and believe that the Lima driver is already revealing way too much of the internals of the Mali hardware. Plus, their stance is that if they really wanted an open source driver, they could simply open up their own codebase, and be done.
Really?
We can debate endlessly about not seeing an advantage to an open source driver for the Mali. In the end ARMs direct customers will decide on that one. I believe that there is already 'a slight bit of' traction for the general concept of open source software, I actually think that a large part of ARMs high margin products depend on that concept right now, and this situation is not going to get any better with ARMv8. Silicon vendors and device makers are also becoming more and more aware of the pain of having to deal with badly integrated code and binary blobs. As Lima becomes more complete, ARMs customers will more and more demand support for the Lima driver from ARM, and ARM gets to repeat that mantra: "We simply do not see the advantage"...
About revealing the internals of the Mali, why would this be an issue? Or, let me rephrase that, what is ARM afraid of?
If they are afraid of IP issues, then the damage was done the second the Mali was poured into silicon and sold. Then the simple fact that ARM is that apprehensive should get IP trolls' mouths watering. Hey IP Trolls! ARM management believes that there are IP issues with the Mali! Here is the rainbow! Start searching for your pot of gold now!
Maybe they are afraid that what is being revealed by the Lima driver is going to help the competition. If that is the case, then it shows that ARM today has very little confidence in the strength of their Mali product or in their own market position. And even if Nvidia or Qualcomm could learn something today, they will only be able to make use of that two years or even further down the line. How exactly is that going to hurt the Mali in the market it is in, where 2 years is an eternity?
If ARM really believes in their Mali product, both in the Mali's competitivity and in the originality of its implementation, then they have no tangible reason to be afraid of revealing anything about its internals.
Then there is the view that ARM could just open source their own driver. Perhaps they could, it really could be that they have had very strict agreements with their partners, and that ARM is free to do what they want with the current Mali codebases. I personally think it is rather unlikely that everything is as watertight as ARM management imagines. And even then, given that they are afraid of IP issues... How certain are ARMs lawyers that nothing contentious slipped into the code over the years? How long will it take ARMs legal department to fully review this code and assess that risk?
The only really feasible solution tends to be a freshly written driver, with a full development history available publically. And if ARM wants to occupy their legal department, then they could try to match intel (AMD started so well, but ATI threw in the towel so quickly, but luckily the AMD GPGPU guys continued part of it), and provide the Technical Reference Manual and other documents to the Mali. That would be much more productive, especially as that will already be more legal overhead than ARM management would be willing to spare, when they do finally end up seeing the light.
So. ARM management hates us. But guess what. Apart from telling us to change our name (there was apparently the "fear" of a trademark issue with us using Remali, so we ended up calling it Lima instead), there was nothing that they could do to stop us a year and a half ago. And there is even less that ARM can do to stop us today :)
A full 6.0%...
In almost 160 patches, loads of things change:
- clean FOSDEM code supporting Q3A timedemo on a limare ioquake3.
- support for r3p2 kernel and binary userspace as found on the odroid-x series.
- multiple PP support, allowing for the full power of the mali 400MP4 to be used.
- fully threaded job handling, so new frames can be set up while the first is getting rendered.
- multiple textures, in rgb888, rgba8888 and rgb565, with mipmapping.
- multiple programs.
- attribute and elements buffer support.
- loads of gl state is now also handled limare style.
- memory access optimized scan pattern (hilbert) for PP (fragment shader).
- direct MBS (mali binary shader) loading for pre-compiled shaders (and OGT shaders!!!).
- support for UMP (arm's in kernel external memory handler).
- Properly centered companion cube (now it is finally spinning in place :))
- X11 egl support for tests.
- ...
As for performance, this is no better or worse than the FOSDEM code. 47fps on timedemo on the Allwinner A10 at 1024x600. But now on the Exynos 4, there are some new numbers... With the CPU clocked to 2GHz and the Mali clocked to 800MHz (!!!) we hit 145fps at 720p and 127fps at 1080p. But more on that a bit further in this post.
Upcoming: Userspace memory management.
Shortly after FOSDEM, i blogged about the 2% performance advantage over the binary driver when running Q3A.
As you might remember, we are using ARMs kernel driver, and despite all the pain that this is causing us due to shifting IOCTL numbers (whoever at ARM decided that IOCTL numbers should be defined as enums should be laid off immediately) I still think that this is a useful strategy. This allows us to immediately throw in the binary driver, and immediately compare Lima to the binary, and either help hard reverse engineering, or just make performance comparisons. Rewriting this kernel driver, or turning this into a fully fledged DRM driver is currently more than just a waste of time, it is actually counterproductive right now.
But now, while bringing up a basic mesa driver, it became clear that I needed to work on some form of memory management. Usually, you have the DRM driver handling all of that, (even for small allocations i think - not that i have checked). We do not have a DRM driver, and I do not intend to write one in the very near future either, and all I have is the big block mapping that the mali kernel driver offers (which is not bad in itself).
So in the train on the way back from linuxtag this year, I wrote up a small binary allocator to divide up the 2GB of address space that the Mali MMU gives us. On top of that, I now have 2 types of memory, sequential and persistent (next to UMP and external, for mapping the destination buffer into Mali memory), and limare can now allocate and map blocks of either at will.
The sequential memory is meant for per-frame data, holding things like draws and varyings and such, stuff that gets thrown away after the frame has been rendered. This simply tracks the amount of memory used, adds the newly requested memory at the end, and returns an address and a pointer. No tracking whatsoever. Very lightweight.
The persistent memory is the standard linked list type, with the overhead that that incurs. But this is ok, as this memory is meant for shaders, textures and attribute and element buffers. You do not create these _every_ draw, and you tend to reuse them, so it's acceptable if their management is a bit less optimized.
Normally, more management makes things worse, but this memory tracking allowed me to sanitize away some frame specific state tracking. Suddenly, Q3A at 720p which originally ran at 145fps on the exynos, ran at 176fps. A full 21% faster. Quite some difference.
I now have a board with a Samsung Exynos 4412 prime. This device has the quad A9s clocked at 1.7GHz, 2GB LP-DDR2 memory at 880MHz, and a quad PP Mali-400MP4 at 440MHz. This is quite the powerhouse compared to the 1GHz single A8 and single PP Mali-400 at 320MHz. Then, this Exynos chip I got actually clocks the A9s to 2GHz and the mali to a whopping 800MHz (81% faster than the base clock). Simply insane.
The trouble with the exynos device, though, is that there are only X11 binaries. This involves a copy of the rendered buffer to the framebuffer which totally kills performance. I cannot properly compare these X11 binaries with my limare code. So I did take my new memory management code to the A10 again, and at 1024x600 it ran the timedemo at 49.5fps. About a 6% margin over the binary framebuffer driver, or tripling my 2% lead at FOSDEM. Not too bad for increased management, right?
Anyway, with the overclocking headroom of the exynos, it was time for a proper round of benchmarking with limare on exynos.
Benchmark, with a pretty picture!
The above picture, which I quickly threw together manually, maps it out nicely.
Remember, this is an Exynos 4412 prime, with 4 A9s clocked from 1.7-2.0GHz, 2GB LP-DDR2 at 880MHz, and a Mali-400MP4 which clocks from 440MHz to an insane 800MHz. The test is the quake 3 arena timedemo, running on top of limare. Quake 3 Arena is single threaded, so apart from the limare job handling, the other 3 A9 cores simply sit idle. It's sadly the only good test I have, if someone wants to finish the work to port Doom3 to gles, I am sure that many people will really appreciate it.
At 720p, we are fully CPU limited. At some points in the timedemo (as not all scenes put the same load on cpu and/or gpu), the difference in mali clock makes us slightly faster if the cpu can keep up, but this levels out slightly above 533MHz. Everything else is simply scaling linearly with the cpu clock. Every change in cpu clock is a 80% change in framerate. We end up hitting 176.4fps.
At 1080p, it is a different story. 1080p is 2.25 times the amount of screen real estate of 720p (if that number rings a bell, 2.25MB equals two banks of Tseng ET6x00 MDRAM :p). 2.25 times the amount of pixels that need to pushed out. Here clearly the CPU is not the limiting factor. Scaling linearly from the original 91fps at 440MHz is a bit pointless, as the Q3A benchmark is not always stressing CPU and GPU equally over the whole run. I've drawn the continuation of the 440-533MHz increase, and that would lead to 150fps, but instead we run into 135.1fps. I think that we might be stressing the memory subsystem too much. At 135fps, we are pushing over 1GBps out to the framebuffer, this while the display is refreshing at 60fps, so reading in half a gigabyte. And all of this before doing a single texture lookup (of which we have loads).
It is interesting to see the CPU become measurably relevant towards 800MHz. There must be a few frames where the GPU load is such that the faster CPU is making a distinguishable difference. Maybe there is more going on than just memory overload... Maybe in future i will get bored enough to properly implement the mali profiling support of the kernel, so that we can get some actual GP and PP usage information, and not just the time we spent waiting for the kernel job to return.
ARM Management and the Lima driver
I have recently learned, from a very reliable source, that ARM management seriously dislikes the Lima driver project.
To put it nicely, they see no advantage in an open source driver for the Mali, and believe that the Lima driver is already revealing way too much of the internals of the Mali hardware. Plus, their stance is that if they really wanted an open source driver, they could simply open up their own codebase, and be done.
Really?
We can debate endlessly about not seeing an advantage to an open source driver for the Mali. In the end ARMs direct customers will decide on that one. I believe that there is already 'a slight bit of' traction for the general concept of open source software, I actually think that a large part of ARMs high margin products depend on that concept right now, and this situation is not going to get any better with ARMv8. Silicon vendors and device makers are also becoming more and more aware of the pain of having to deal with badly integrated code and binary blobs. As Lima becomes more complete, ARMs customers will more and more demand support for the Lima driver from ARM, and ARM gets to repeat that mantra: "We simply do not see the advantage"...
About revealing the internals of the Mali, why would this be an issue? Or, let me rephrase that, what is ARM afraid of?
If they are afraid of IP issues, then the damage was done the second the Mali was poured into silicon and sold. Then the simple fact that ARM is that apprehensive should get IP trolls' mouths watering. Hey IP Trolls! ARM management believes that there are IP issues with the Mali! Here is the rainbow! Start searching for your pot of gold now!
Maybe they are afraid that what is being revealed by the Lima driver is going to help the competition. If that is the case, then it shows that ARM today has very little confidence in the strength of their Mali product or in their own market position. And even if Nvidia or Qualcomm could learn something today, they will only be able to make use of that two years or even further down the line. How exactly is that going to hurt the Mali in the market it is in, where 2 years is an eternity?
If ARM really believes in their Mali product, both in the Mali's competitivity and in the originality of its implementation, then they have no tangible reason to be afraid of revealing anything about its internals.
Then there is the view that ARM could just open source their own driver. Perhaps they could, it really could be that they have had very strict agreements with their partners, and that ARM is free to do what they want with the current Mali codebases. I personally think it is rather unlikely that everything is as watertight as ARM management imagines. And even then, given that they are afraid of IP issues... How certain are ARMs lawyers that nothing contentious slipped into the code over the years? How long will it take ARMs legal department to fully review this code and assess that risk?
The only really feasible solution tends to be a freshly written driver, with a full development history available publically. And if ARM wants to occupy their legal department, then they could try to match intel (AMD started so well, but ATI threw in the towel so quickly, but luckily the AMD GPGPU guys continued part of it), and provide the Technical Reference Manual and other documents to the Mali. That would be much more productive, especially as that will already be more legal overhead than ARM management would be willing to spare, when they do finally end up seeing the light.
So. ARM management hates us. But guess what. Apart from telling us to change our name (there was apparently the "fear" of a trademark issue with us using Remali, so we ended up calling it Lima instead), there was nothing that they could do to stop us a year and a half ago. And there is even less that ARM can do to stop us today :)
A full 6.0%...
Tor Lillqvist
posted at
You can't win an argument against conspiracy theorists
Whatever you say, or don't say, will be taken as proof. If something is done, or is not done, in both cases that is a proof of the conspiracy.
An example, from the open source world: Mentioning a competitor project from which some of your code comes will be seen as proof that you unfairly want their fabulous reputation to rub over onto your project. On the other hand, not mentioning it will be seen as proof that you don't want people to know where your good stuff comes from.
Agustin Benito Bethencourt
posted at
Insides about the new openSUSE Team at SUSE blog
Yesterday we created a new blog [1]to communicate to our community and readers what do we do as a team within the openSUSE project. It is a collective effort and it will be part of our duties to create and publish contents for it.
Its main goal is to talk about what we do so in the long run, it becomes a reference channel to follow up the activity of the group of people that SUSE employs to work full time in openSUSE.
Once of the discussion topics we faced was how to make compatible this blog, that has a corporate nature, with our personal blogs, our work in the community and the motivations of our team members. It is a very interesting topic since it is not trivial in practice to separate the information you handle as employee and your work within a community, in a case like our ours, employees that work for a community.
The easy approach is to say that, by default, all what we do is public and treated as "community" work, or the opposite, but there are many corner cases, some of them relevant, that are not cover by these general approaches. Usually this topic has no relevance until something happens, usually bad. We need to understand that, as employees, we hold a responsibility that, if non properly managed, can potentially harm our company. It also can hurt us as professionals or affect our community. Often you are not a perceived as a regular community member only, but as a company advocate/representative too.
As a manager, I have to make compatible the community interest, the personal interest of the people under my responsibility and the company interest. In a company like SUSE, specially when talking about openSUSE, conflicts are small in this regard. We are a very open company in general and in my area in particular. I am glad of being part of a company that understand Free Software.
But under certain situations, nobody is out of risk. I even face this limitations being the KDE Treasurer. Being open is one thing and publishing all the information is another one. Obvious in theory but....where are the limits in practice? Who should take care of ensuring those limits are respected? What measures should be taken to satisfy all parties interest? When managing information, how to be fair with your community, yourself and your company at the same time?
It is impossible to clearly define how to react in every case, what things should be kept private and what things don't, how to deal with the information you get as an employee but should be publish as part of your everyday activity within the community....
But what is possible is to create a clear field in which the people involved can move as freely as possible, making sure that some processes are put in place to avoid harmful mistakes. But above all, you have to rely on people, train them and be close to them so they understand the risks and the possible conflicts. Experience usually helps a lot in this field.
Behind this team blog, there are some processes that try to answer some of the previous questions and concerns, reducing the risk for the company and the authors but, at the same time, keeping the spirit of our work and goals: being open. I will talk about the concrete measures in a couple of months, when we get some conclusions about their efficiency.
I hope you will find the blog interesting.
[1] Link to the blog: https://lizards.opensuse.org/author/calumma/
Fridrich Strba
posted at
LibreOffice Google Summer of Code 2013 - selected projects
There is now again the period of the year when the results of Google Summer of Code selection are public. As for LibreOffice project, we have got 13 slots this year. We love you, Google! We really do!
Nonetheless, we had much more good applications then the slots and we had to do hard choices based on a variety of parameters. And the final line-up that came out is:
| Project | Student | |
| Adding alterating row coloring to database ranges and supporting new structured reference syntax | she91 | |
| Code completion in the Basic IDE | stalker08 | |
| Extend support for Document Management Systems | Cuong Cao Ngo | |
| Implement Firebird SQL connector for LibreOfficeBase | Andrzej Hunt | |
| Implementing an about:config functionality | Efe Gürkan YALAMAN | |
| Implementing Proper Table Styles in Writer | Ivan Nicolae-Alexandru | |
| Impress Remote Control for iOS | LIU Siqi | |
| Improve toolbars in LibreOffice | Prashant Pandey | |
| Improved Android / Impress Remote Control | Artur Dryomov | |
| Slide Layout Extendibility | Vishv Brahmbhatt | |
| Use Widget Layout for the Start Center | Krisztian Pinter | |
| VLC integration into LibreOffice | Minh Ngo | |
| Writer: Border around characters | Zolnai Tamás |
Congratulations to the selected students. We expect you to be bonding hard during the community bonding period that just started. Your presence on IRC and even start of the hacking is required now!
For the students that unfortunately could not be selected, do not be discouraged. Your Easy Hack patches made a real difference, sorry it did not work out this time. The LibreOffice community is always welcoming and you can learn a lot just by staying around and working at your pace on your chosen Easy Hack.
Tor Lillqvist
posted at
Another marketing achievement in LibreOffice: $(OUTDIR)/inc is gone
Thanks to the great work of our marketing experts like dtardon and mst__, no headers are any more copied ("delivered"), not even from 3rd-party packages, and thus $(OUTDIR)/inc is no more. Bye bye and good riddance! This makes the build tree again a bit cleaner, reduces build time somewhat, and can in cases avoid unneeded re-compilation of some source files.
Alex-P. Natsios
posted at
MemberMy project idea for GSoC 2013
Greetings everyone!
With the GSoC proposal reviews coming to a close and the start of the GSoC period I thought it would be a good idea to make a blog post about my proposed project in order to discuss and clarify a few things.
In this year’s Google Summer of Code(GSoC) I have submitted a proposal with the Plan9 operating system. I have proposed the rewrite of some of plan9’s userland tools in Google’s fairly new Go-lang.
A few words on both from wikipedia.
plan9
Plan 9 from Bell Labs is a free software distributed operating system. It was developed primarily for research purposes as the successor to Unix by the Computing Sciences Research Center at Bell Labs between the mid-1980s and 2002. Plan 9 continues to be used and developed by operating system researchers and hobbyists.
Go-lang
Go, otherwise known as Golang, is an open source, compiled, garbage-collected, concurrent system programming language. It was first designed and developed at Google Inc. beginning in September 2007 by Robert Griesemer, Rob Pike, and Ken Thompson.
10 days ago (May 13) it had a new stable release 1.1!
About the project (why?)
“Goblin” will be a portable Golang based userland suite featuring tools and commands one would expect in a basic system that emulates the way a vanilla plan9 system runs. The general idea is to be able to completely replace the plan9 userland with a cross-platform environment that will be highly compatible to vanilla plan9 keeping API compatibility to avoid breakages with existing infra and be as transparent as possible while used in a multitude of systems (be it plan9, linux, unix, etc).
How?
The commands will be written in Go-lang, the details of the structure and licensing will be posted post-acceptance once desided with the mentor along with where the project will be hosted (most probably bitbucket with a mirror in contrib/). It is decided that the project will be written in a mostly “idiomatic Go” way while remaining as portable as possible (with plan9 and linux as the primary project’s targets). Since Go provides many things that were simply not there when writing in C the code won’t be that close (both design and implementation wise thus getting rid of the LPL licensed code while still keeping the LPL manpages since we will have 100% API compatibilty so no point in rewritting them) in other words i will not simply translate the C lines in Go-lang but will rewrite the commands from scratch.
Outline
| Commands ||| | :———: | :—: | :—-: | —-: | | ascii | cal | date | diff | | basename | cat | du | ed | | cleanname | cmp | dd | fmt | | getflags | freq | echo | grep | | join | look | ls | mkdir | | mtime | pwd | read | sed | | sleep | seq | sort | split | | strings | tail | tee | test | | touch | tr | troff | uniq |
timeline
- Milestone 1: From acceptance until the coding start period i will be discussing last minute details with the mentor (like the aforementioned final decision on license, hosting and project structure.) Will also discuss the testing procedure for the userland and probably setup a couple virtual machines to replicate the development and later testing environment (either setup of certain services or trivial unit tests (or both for some cases)). At this stage we will also finalize the batches of commands and the order in which i will work on them ranking them by matter of importance.
- Milestone 2: From coding period start until the end of june i will implement the first batch of trivial commands, effectively starting the real work and testing through the decided way.
- Milestone 3: From July 1 to 14 i will implement another batch of commands.
- Milestone 4: From July 16 to mid term evaluation i will have written tests for the implemented commands and run a hybrid system serving werc with my cmds instead of the originals.
- Milestone 5: From mid term to August 14 i will imlement another set of commands.
- Milestone 6: From August 16 to Soft Pencils Down date i will dedicate to editors and rest big commands.
- Milestone 7: From then on i will try to finish what is left or complete make tests more “complete”.
testing & community call
Being a userland suite, testing, a quantifiable metric of success or the involvement/improvement of the plan9 community as a whole is hard to be assesed. To me and most probably my mentor success will be reached if we can run a plan9 environment and assosiated services with it being transparent (as in without noticing that the userland has changed) and be able to also use the same userland on a *nix keeping a consistent feel. When in comes to testing first thoughts were to write a few unit tests for the commands and setup systems with the produces userland instead of their stock one. At key points of development i will publish images with it and also urge the community to test them under their own unique environments and report thoughts, problems and ideas concerning the implemented commands.
Nathan Cutler
posted at
Request Tracker: set up external authentication via LDAPS
This is a description of how I set up my Request Tracker instance to use external authentication via LDAPS (LDAP over SSL on port 636).
- In the previous installment, I already added the
devel:languages:perlrepository. Now I install the package containing theRT::Authen::ExternAuthRT extension that will provide the external-authentication-against-LDAP functionality.
# zypper ref # zypper in perl-RT-Authen-ExternalAuth # zypper in perl-Net-SSLeay # zypper in perl-ldap-ssl
- I set up SSL on my system (beyond the scope of this blog entry). At the very least, the
opensslpackage should be installed and configured, and my LDAP server's certificates should be present in the/etc/ssl/certsdirectory. - I tweak my
openldapconfiguration for CA CERT as per this blog entry - I read up on the
RT::Authen::ExternalAuthextension (plugin). Here are the principal documentation resources I was able to find:
- the README file
- the sample configuration file, which I installed on my system in step 1, above, at the following location:
/usr/share/request-tracker/local/plugins/RT-Authen-ExternalAuth/etc/RT_SiteConfig.pm
I read it usingless.
- And then there is the RT::Authen::ExternAuth page on MetaCPAN and, in particular, this subpage of that page.
- Thanks to Thomas Sibley (Tsibley) over at the Request Tracker Wiki, I now know that the
RT::Authen::ExternalAuthextension supports LDAPS out of the box by simply specifying the LDAP server with a ldaps:// prefix -- see the Net::LDAPS documentation for more details on this.
- After reading the documentation and protracted trial and error, I finally came up with the following working configuration (in
RT_SiteConfig.pm):
Set($ExternalServiceUsesSSLorTLS, 1); Set($ExternalSettings, { 'MY_LDAP' => { 'type' => 'ldap', 'server' => 'ldaps://ldap.example.com', 'tls' => 0, 'ssl_version' => 3, ... - At this point, I fire up
request-trackerand am able to log in with my LDAP credentials!
Nagappan Alagappan
posted at
[Ann]: Cobra 3.5 - Windows GUI test automation tool
New features:
* ooldtp python client
* Support setting text on combo box
* Added simple command line options
* Support state.editable in hasstate
* Handle valuepattern in click API
* Support ToolBar type on click
* Write to log file if environment variable is set (set LDTP_LOG_FILE=c:\ldtp.log)
* Support control type Table, DataItem in Tree implementation
* Added scrollbar as supported type
New API:
* MouseMove
* setcellvalue
* guitimeout
* oneup
* onedown
* oneleft
* oneright
* scrollup
* scrolldown
* scrollright
* scrollleft
Bugs fixed:
* Fix to support taskbar with consistent index
* istextstateenabled API
* Fallback to object state enabled if value pattern is not available
* Fix to support InvokePattern on Open button
* Use width, height if provided while capturing screenshot
* Work around for copying text to clip board
* QT 5.0.2 specific changes
* Check errno attribute to support cygwin environment
* Fix keyboard APIs with new supported key controls (+, -, :, ;, ~, `, arrow up, down, right, left)
* Don't grab focus if type is tab item
Java client:
* Fixed selectRow arguments
* Fixed compilation issues
Python client:
* Fix optional argument issue in doesrowexist
C# client:
* Added new APIs (scrollup, scrolldown, scrollleft, scrollright, oneup, onedown, oneleft, oneright)
Ruby/Perl client: No changes
Credit:
Nagappan Alagappan, John Yingjun Li, Helen Wu, Eyas Kopty, VMware colleagues
Please spread the word and also share your feedback with us (email me).
About LDTP:
Cross Platform GUI Automation tool Linux version is LDTP, Windows version is Cobra and Mac version is PyATOM.
* Linux version is known to work on GNOME / KDE (QT >= 4.8) / Java Swing / LibreOffice / Mozilla application on all major Linux distribution.
* Windows version is known to work on application written in .NET / C++ / Java / QT on Windows XP SP3 / Windows 7 / Windows 8 development version.
* Mac version is currently under development and verified only on OS X Lion. Where ever PyATOM runs, LDTP should work on it.
Download source / binary (Windows XP / Vista / 7 / 8)
System requirement: .NET 3.5, refer README.txt after installation
Documentation references: For detailed information on LDTP framework and latest updates visit http://ldtp.freedesktop.org
LDTP API doc / Java doc
Report bugs
About LDTP:
Cross Platform GUI Automation tool Linux version is LDTP, Windows version is Cobra and Mac version is PyATOM.
* Linux version is known to work on GNOME / KDE (QT >= 4.8) / Java Swing / LibreOffice / Mozilla application on all major Linux distribution.
* Windows version is known to work on application written in .NET / C++ / Java / QT on Windows XP SP3 / Windows 7 / Windows 8 development version.
* Mac version is currently under development and verified only on OS X Lion. Where ever PyATOM runs, LDTP should work on it.
Download source / binary (Windows XP / Vista / 7 / 8)
System requirement: .NET 3.5, refer README.txt after installation
Documentation references: For detailed information on LDTP framework and latest updates visit http://ldtp.freedesktop.org
LDTP API doc / Java doc
Report bugs
Kostas Koudaras
posted at
Organizing oSC13 - 57 days before
When I started this series of 'Organizing oSC13' posts I wanted to make three main things.
- Blog about what it takes to make oSC13
- Include things that could be useful in the future to people who will take over the next conferences
- Inform people how things are going out of a strictly personal sight
Having said that I continue :D
Now so far I haven't wrote anything about the actual progress of the conference. Today I will write about it.
So far we have 36 people working on tasks on https://trello.com/osc13 which is where we put tasks and work on them.
Now let's talk in numbers:
So far we have 111 total tasks separated in 3 sections. The Sections are Program - Promo - Venue.
We have a total of 22 tasks in Program. From those 22 tasks we have 17 on 'To Do', 1 on 'Doing' and 4 on 'Done'.
We have a total of 64 tasks in Promo. From those 64 tasks we have 11 on 'To Do', 15 on 'Doing' and 38 on 'Done'.
We have a total of 25 tasks in Venue. From those 25 tasks we have 15 on 'To Do', 4 on 'Doing' and 6 on 'Done'.
We also have tasks that were finished even before reaching https://trello.com/osc13 , like articles or gathering some equipment that we already have in our possession.
In order to finish all that tasks many work hours where spent, many people were on to them and many fights between us where given so that we succeed the best possible result. This is something I really want to point out. We fight over a lot of things, mostly because we want to do things perfect, have in mind that this is a good thing and in the end of the day we are more bonded than before. We are closer because we understand more the person we are working with. This leads to less fights and better results as we continue. If you have a solvent character those fights make you better in many ways.
One thing I really like this year is that everyone of the people I've worked with so far is ready to take one for the team. Another is that we all want the same thing, to make this Conference the best possible.
If you have some time and you want to be a part of this team then join us at https://trello.com/osc13 and help. If you have the will to do things, even if you feel you can't do anything, there are people there who will be happy to help you finishing tasks. Help needed, help wanted and help can be provided.
Kostas Koudaras
posted at
Organizing oSC13 - 58 days before
Meetings-planning-searching-meetings and here we go again meetings-planning-searching-meetings. Of course not always with that turn and some times with even more meetings. Having A LOT of meetings is the necessary 'evil' when organizing a conference. In meetings you get to interact with other people, get feedback and generate new ideas out of the interaction. You get to know what is going well and what it does not, where you need more things to be done and where you need less things to be done. What works and what it doesn't. Nevertheless meetings although they are necessary for the organization hide what I think is the biggest enemy of an organization. This enemy is Paralysis by analysis.
An experienced person should be able to recognize this after a while but the thing here is that if you fall into this loop, you will have time lost and time as I said before is really precious when you organize an event. Given the fact that within reasonably boundaries anything that you plan can take place, time is your only obstacle. It is the mail reason why many good ideas are left out of the organization of many conferences over the years.
This leads to the conclusion that recognition of Paralysis by analysis after the fact is not enough. When starting to organize something always have that in the back of your head. Avoiding it is not that difficult but at some points require to have a good programming of the meetings. What I've noticed over the year is that most of the times people who cause this are the people who lead and most of those times this happens for 2 reasons.
Case 1: Someone has an idea and you know that this idea is either not viable at the timeline you have or it has failed in the past(there are other reasons too but those are the most common). Now you try to convince this person that you should not do that for X reasons. The person is convinced that the idea is perfect and disagrees with you and you all fall in the loop of trying to prove your point. So after a while you spend more time talking that the actual time that would take for this to be done or for this to be failed. You should have a vision of either let the person do this (if you can afford it) or to have this person directed to documentation or other people so that the person will go look for it and see your point. This problem can be partially predicted while reading the agenda of the meeting and knowing the people you work with. Reading the agenda of the meeting before is always important.
Case 2: I often call that The conference bag problem. You and your team have an idea that will make the conference great. There should be a certain limit of how much time you will spent on talking about anything. Normally ideas like conference bags or conference t-shirts are the ones that make you fall into the loop of Paralysis by analysis. This often happens because subjects like that are more light and have unlimited possibilities.
Having a good programming of the conference meetings can save you from those things if you stick to that. Always have in mind that the only thing that you don't have most of the times is time itself.