Finally got around to find time to write a bit about my attendance of the openSUSE Conference 2012 in Prague.
Overall I found it a quite successful event even when I could think of a few improvements for next time. I’ve attended quite some talks during the days and also helped recording some of them. But to me the most important thing was to meet and talk to people. Since openSUSE 11.4 is going to go Evergreen very soon there were quite some discussions including two related BOFs and a maintenance hands-on with Marcus from the SUSE Maintenance team as we are planning to use OBS’ maintenance features for the upcoming 11.4.
What I missed was a bit more space to meet and hack a bit. Both venues were a bit short on seats outside of the talks or BOF rooms. But congratulations for a pretty stable wifi network during the conference. I missed it at the hotel though
Apart from that I’ve met some new (to me) people and missed some other community members including some from the board which is a bit unfortunate for the main community event but still there were many good conversations.
Special thanks to Petr from SUSE showing us the city and helping me to find my hotel when I arrived (and everything else) and also the openSUSE travel support program which was sponsoring my travel to the conference.
I’m looking forward to next year’s conference and hope I can attend there as well again.
A quick update about recent changes in Mozilla applications for openSUSE.
With the release of Firefox and Thunderbird 11 (and Seamonkey 2.8) the older versions (10) got obsolete as always. But Mozilla created ESR (Extended Support Release) for Firefox and Thunderbird based on versions 10 and will maintain them for a longer time. Please read the FAQ about the details. For openSUSE we will not switch to these versions for different reasons but I’ll provide these from the buildservice repository mozilla. You should be able to install the current versions (10.0.3) of Firefox and Thunderbird by choosing firefox-esr or thunderbird-esr (there is also xulrunner-esr) in your package manager if you added that repository before. Please note that this is opt-in only and it’s not possible to install latest normal version and ESR versions in parallel. They are using the same profile directory and therefore I didn’t give them a separate installation directory neither. It’s also a bit risky to jump between ESR and normal versions because of the profile. So as normal version gets higher every six weeks the riskier to jump back and forth. Basically those ESR versions should probably be used only if really necessary but I still wanted to provide that possibility. If you install the ESR versions and found issues please let me know. Because of the renaming and parallel usage of the branding packages I might have missed some packaging foo to make updates in every case smooth.
A similar topic is about Firefox 3.6 and Thunderbird 3.1. The latest round of updates (3.6.28 / 3.1.20) was most likely the last one and people should start switching to more recent versions. That also means that 11.4 will get Thunderbird 12 as replacement for 3.1.20 with the next round. Other versions are already on the latest packages. (Evergreen will likely switch to the ESR versions btw.)
And about the last announcement (from my “quick update”) people might notice that Thunderbird 11 now got at least some of the KDE integration from Firefox as people kept pinging me about it. (And Firefox’ KDE integration is also back for the official updates!)
I’m not a web designer really but I happen to be kind of responsible for packaging two web authoring applications in openSUSE which are SeaMonkey’s Composer and KompoZer. While the SeaMonkey integrated editor is somewhat limited (AFAIK) KompoZer (which was forked from Nvu at some point) has more advanced features. But KompoZer development seems to be pretty slow and it misses quite some of the new web stuff which is around nowadays. In addition the current version is BETA for quite some time now and seems to have a major issue in openSUSE 11.4 and 12.1.
Because of that I finally had a look at BlueGriffon (written by the same developer as the Netscape/Mozilla/SeaMonkey Composer and Nvu) as it seems to be in active development and supports quite some of the new HTML5 and CSS3 stuff and created an initial openSUSE package available in the mozilla OBS repository for testing now. There is also an openSUSE feature request to make it available.Â If you are a web developer or already know BlueGriffon please give the package a try and send your feedback.
My plan for the openSUSE distribution would be to keep SeaMonkey’s Composer (basically anyway because it’s a part of SeaMonkey which is to stay), add BlueGriffon and drop KompoZer. If you see a reason why that might be a bad idea based on your experience as a web authoring application user please let me know.
Looking forward to your feedback!
I guess it’s time for another Evergreen status update.
I cannot tell much about 11.2 (but as far as I can see Stefan does an awesome job in maintaining it) but will share my thoughts about the 11.1 flavour of Evergreen.
When I started that project it was clearly an experiment as I haven’t had an idea how much work it would be and if people would use it or even help with it. Looking back at what we’ve created it finally is more than I expected. Compared to what I announced in the beginning it was almost possible to maintain every part of the distribution and not only server packages. There are things which turned out be quite hard (e.g. kernel) but overall most issues were covered for 11.1. I think what I was able to prove is that it’s possible to somehow maintain a distributionÂ with very few manpower.
Now as 11.1 is nearing its 3rd birthday on December, 18th and given the fact that it’s getting harder having stuff updated while still being more or less compatible and stable I found that I cannot keep the pace with my limited spare time and without neglecting my other volunteer projects (remember Mozilla’s rapid release cycle?). For that reason I’m announcing that I’ll step back from being the Evergreen/11.1 project leader by end of this year. As of now noone else has stepped up so I need to announce that 11.1 will most likely be unmaintained as of end of this year. This does not affect 11.2 and I’ll also try to keep my packages updated for maintained Evergreen projects in the future. I’ll also stay involved and help out with organizational and administrative stuff where needed.
It’s still possible to step up taking over the 11.1 maintenance but in the end I think 3 years is already a good timeframe for a community distribution.
I hope that I find a bit of time in december to post a (statistical) summary about Evergreen/11.1 to let you know about some details.
Thanks for your support during the last year!
With Firefox 4 released a few weeks ago it’s time for me to look into what comes next.
The first to follow are maintenance updates for Firefox 4 which are now codenamed Macaw. 4.0.1 is in upstream beta testing for a few days now. At some point in future we will have a SeaMonkey 2.1 release which willÂ be (most likely) based on the same Gecko version as Firefox 4 and you can get 2.1b3 snapshots for that from mozilla:beta. From the same repository you can also install a new Thunderbird 3.3a4 (codename Miramar). Please note that this early package has no Enigmail support yet.
Now to some interesting changes which are coming up with Firefox development and releases. Mozilla switched to a “rapid release cycle” after the release of FF4. This means that we will see new Firefox major releases around every 6 weeks. Firefox 5 is currently planned for end of June 2011. Firefox now is developed through different stages before the final release where Aurora is branched already for FF5 and will enter the beta stage in a few weeks. A current Firefox Aurora build is available in mozilla:alpha.
This changed release process also means that there won’t be long maintained branches anymore which has an impact on how we deal with updates during a distribution lifetime. Nothing has been discussed on that topic yet though. Another fallout is that our Firefox packages will be standalone packages again after several years of being based on XULRunner. What will happen to XULRunner in the distribution is yet another thing we need to figure out.
I’ve just noticed that I haven’t written about Evergreen here since the beginning. I actually did post at least one status update on our list but I think it would be good to give some information to a wider audience (hoping that this blog is read by more people).
In general we are in good shape. Up to now we have released around 55 source updates. You can find the list here. So looking back that means that we were able to update almost everything including desktop applications which was not clear in the beginning how that would work out. Also the Packman team decided to support Evergreen by keeping the Essentials repository available. Unfortunately it is not quite usable at the moment since it contains RPM packages signed with keys not supported by the RPM version in 11.1 which means zypper refuses to install those.
Another milestone is that it seems we will also support 11.2 when it runs out of Novell’s maintenance on May 12th, 2011. Another community member agreed toÂ lead the effort. More details on that to come soon.
But not everything is working perfectly fine though. Besides some rare cases where community members submitted packages to Evergreen/11.1 all the backporting/packaging work up to now was done by myself. At some points in time I was quite on the limit of my time for the project and there is no redundancy if something bad happens to me. We really need more people contributing to Evergreen. That said it would be really nice if maintainers (especially community maintainers) wouldÂ prepare updates for 11.1 as well. Obviously there is no obligation in doing so but I somehow think that in some cases they are just missing the fact that Evergreen exists at all.
So if anyone out there has interest in helping maintaining 11.1 and/or 11.2 please contact us through our mailinglist or contact me directly.
Following up on my previous blogpost I would like to give a small update on what happened so far about a longer supported (open)SUSE release.
We had a longer discussion on the mailing list if an openSLES (a’la CentOS) or “openSUSE LTS” would be the better or easier solution. There are pros and cons for both while the required infrastructure differs a lot. I’m not diving into details here though. While I would find a SLES clone appealing I’m not in the position to drive such an effort. I also do not think that having both makes sense and therefore I decided to go on with the other approach for now trying to extend the lifetime of an existing openSUSE release.
People in the community came up with the project name Evergreen and I think that matches what we try to build pretty well. I proposed to give the whole effort a trial with openSUSE 11.1 which went unsupported with the new year. At the moment we still have organizational and technical issues and most likely won’t be able to utilize all the update features (deltarpms, zypp patches) but still we will try to deliver updates from a certain update repository. Because of the holiday season we couldn’t figure out the details yet but hopefully will get it sorted out in time. Stay tuned for further detailed information here and on the mailing lists.
Please note that this effort is in experimental state still and didn’t attract that many contributors yet unfortunately. So at the moment it’s still unclear if we will be able to deliver as we would like to.
If you are interested in this project feel free to join our (current) project list.
Just recently I found again that openSUSE is not really positioned for some usecases. In my personal case that is especially the usage as a web/mail/dns/etc server on hosted environments. IMHO it just doesn’t make sense to roll out a distribution which is supported for only 18 months to a hosted system with limited access to it. I still have been doing that with previous openSUSE releases but it’s so annoying that I really regret it. Also the possibility to zypper dup doesn’t really fix that issue for different reasons. Anyway this post is not about whining about that fact or to explain why I don’t like to update these type of systems remotely every <= 18 months.
A possible solution?
Sometime last year there was a discussion about options for something like an “openSLE” or “openSUSE LTS” distribution. There is an external page where some outcome was documented here. The dicussions stopped mainly because of health issues of the main initiator. There was done some planning and voting on the different options but no real results ever happened (as far as I know). So I’m trying to resurrect that topic a bit once again:
The amount of work related to such a project is the critical part and therefore my proposal is to try to start off with a “lightweight” approach.
This would be something like an openSUSE LTS version. That means that the community would take over (security) maintenance after Novell as main contributor drops it out of official maintenance after around 18 months. This will likely only work for a subset of packages which were delivered with the original distribution but the focus might be on server services anyway. Using the openSUSE release which also is the base for SLE could help us a bit as the work is done anyway (some of the Novell employees who are also openSUSE community members would hopefully help us here?). There are quite some details to work out still but it could be doable.
While I think we wouldn’t need a lot of people we at least need some and the more the better.Â We will bring that topic up again on email@example.com as well. The main intention of this post is to get feedback if there is enough interest and contributors to do further planning. I’m very interested in hearing from you via comments, mailing lists or personal mail.
Recently I got my first Android based mobile phone (Samsung Galaxy S 9000) and shortly after another one from my employer (HTC Desire). So people asked me to write up some comparison and here we go:
Both phones are still running on Android 2.1. No official updates to 2.2 available yet from T-Mobile for Desire and Samsung. HTC already released an update but the Desire is T-Mobile branded so no fun yet. Both vendors promised an update to 2.2 in September though.
Technical details (mainly where both phones differ):
- 3,7″ 480×800 AMOLED (S-LCD in future revisions)
- Weight: 135 g
- 5MP camera with flashlight
- RAM 576 MB
- internal memory 512MB
- microSD slot
- Headset w/ earplugs
- notification LED
Samsung Galaxy S:
- 4,0″ 480×800 S-AMOLED
- Weight: 119 g
- 5MP camera w/o any light
- RAM 512 MB
- internal memory 8GB
- microSD slot
- Headset w/ in-ear plugs
- no! notification LED
- additional front camera
In addition to what you can see above here are some comments when it comes to real use. I would call the display the biggest advantage of the Galaxy. It’s bigger, it looks black (compared to the grey of the Desire) and it’s less reflecting than HTC’s. Fingerprints are also not that striking. The downside is that the size is pretty much at the limit what you want to control with one hand. The case of the Desire feels a bit higher quality to me mainly because it’s heavier and not glossy. The Galaxy is pretty much designed as the iPhone3. The USB connector on the Galaxy is at the top right and has a little slider to close it. The HTC’s connector is at the bottom centric and it looks much more likely that there will be car kits or other cradles what I pretty much doubt for the Galaxy because of the connector’s position. As you can see above the difference in memory capacity is pretty stunning. The internal memory compares between 512MB and 8GB. On the memory side there is also to mention that you can replace the microSD card in the Galaxy while the phone is powered on what you cannot do with the Desire as the battery has to be removed to access the slot. The thing what I miss most on the Galaxy is a the LED to see if there are any new notifications.
Both handsets are coming with a similar set of preinstalled applications. HTC ships a home screen extension named HTC Sense which is similar to the design they ship with their Windows Mobile devices and looks appealing (at least) to me. (I like their animated weather applet ;-)). Samsung has another design and other included widgets. The main set of apps is quite different. They seem to have different EMail, Calendar, ActiveSync, Music components for example. (I have no idea if any of these is the original Android default application.) The Samsung EMail app has some usability issues as they list the IMAP folders at the top side by side and shorten the folder name. So I end up seeing something like “INBOX/Archi|INBOX/Arch|INBOX/Arch” at the top because I have subfolders under INBOX/Archive. Apparently more than one sublevel is not really usable. Samsung ships an application called AllShare which is basically a full? DNLA framework . I haven’t found such a feature on the HTC. But then again the Desire comes with a backup feature which can save stuff to the microSD card. The Galaxy lacks a built in backup feature. General responsiveness of the phone seems to be better on the Desire. For whatever reason I sometimes get lagging in the UI animations and application startups on the Galaxy for unknown reasons. I have to add that I use more apps on the Galaxy than I do on the Desire but I don’t think that’s the full truth. So I’m awaiting eagerly the arrival of the new Android 2.2 based firmware which hopefully fixes other issues as well.
A short note about the general handling of data connections in Android 2.1 which is the same on both devices: For the case of roaming you can disable the use of data connections (except WiFi) completely. There is no official way to turn off data in your home network. There might be apps to do that.
I cannot go into details yet because I haven’t done that many phone calls and haven’t tried the headsets for calling yet. Also I use different carriers with the phones which makes it hard to compare the right things. From my small experience I feel that the Desire has worse sound quality as I hear overdrive artifacts with it what I didn’t notice with the Galaxy. Connecting hands-free sets to both phones worked flawlessly.
This comparison is by far not complete but includes the things I found important after using both for only three weeks now.
Yesterday I’ve updated my JF3 firmware to JM1 (which is not Froyo yet) and apparently these mysterious lags are gone now from my Galaxy.
If you are brave enough feel free to update to Firefox 4.0b4 from the mozilla:beta repository. It will not install in parallel to previous versions but will replace your existing Firefox package. As always you want to backup your profile before so you can go back to your previous version without problems.
The latest package contains the KDE integration patches we had in FF3.x which are pretty much untested. So if you run KDE and want to give it a try please report issues you find in Novell’s Bugzilla.