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 firstname.lastname@example.org 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
Headset w/ earplugs
Samsung Galaxy S:
4,0″ 480×800 S-AMOLED
Weight: 119 g
5MP camera w/o any light
RAM 512 MB
internal memory 8GB
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.
I’m just back from the Mozilla Summit 2010 and I’m pretty excited about the demos I’ve seen there about the future of Firefox and the open web.
HTML5/CSS3 is most likely the next big thing on the web and Firefox 4 will be there to support it.
There is a really cool demo I would like to share: (note the dynamic real time content from twitter and flickr and also that this animation is not a video)
And once Firefox 4 with WebGL support will be out we will hit again the problematic situation on Linux about X.org, OpenGL and graphics drivers. (And for this moment I still need to embed the above video as Flash object to not ignore the people using non-WebM enabled browsers ;-))
Two days ago the initial support for the new WebM Media Format landed in Mozilla’s official version control system. So I finally had a good reason to start preparing the first set of Firefox 3.7/4 alpha packages for openSUSE.
As expected they are available through OBS’ mozilla:alpha repository. For easier testing the package can be installed in parallel to your stable Firefox release and does not use the official branding yet. Please note that firefox4 is using the existing profile directory and it’s strongly recommended to use either -P to get the profile selection dialog or back up the profile in ~/.mozilla/firefox. It’s not fully ported with all openSUSE specific settings, KDE integration and lockdown functionality yet. All this will be done along the way of regular updating to newer snapshots. Firefox 4 is still under heavy development and far away from a final (or even beta?) release.
Mozilla is going to release the next Firefox 3.6 maintenance update (3.6.4) with a new feature to run browser plugins outside of the main process. The biggest advantage about that is that crashing plugins do not crash the whole browser anymore which can be a great improvement for people experiencing regular Flash crashes. Actually for Firefox 3.6.4 that feature only is enabled for Adobe’s Flash plugin and only makes a difference on 32bit installations (as 64bit still uses nspluginwrapper which does a similar thing anyway).
In addition to that there was some rework on the crashreporter which should work for x86-64 and is using DWARF symbols now which makes breakpad’s symbol creation compatible again with our default debuginfo packages.
To get some testing on these new features I have prepared packages for the upcoming release in the mozilla:beta OBS repository. Feel free to provide any feedback as comment to that post, Bugzilla, email@example.com or via IRC to me.
Starting with Firefox 3.6 I’ve enabled the Mozilla internal crashreporter for 32-bit builds. Some people have seen that already unfortunately 😉 But anyway that is still a good thing as it makes your and my life easier to analyze what’s going on. This is more kind of a testing phase currently but my plan is go that direction because Apport seems to be no efficient solution in openSUSE just yet and Mozilla was interested in helping distributors to use their infrastructure (they also have the advantage of having more crash data available on Linux systems).
There are still some technical issues which are being worked on. There is no full 64-bit support in Gecko 1.9.2 and the breakpad implementation lacks DWARF support so if we support stabs+ debug symbols as used there we loose RPM’s feature of generating correct debuginfo packages.
Both issues are almost fixed but it’s unclear if we can fully support it with Firefox 3.6 already.
(The number of my blog posts is getting inflationary somehow so I’ll keep it short)
Firefox 3.6 has been released and obviously it’s already available for download from the openSUSE Mozilla repository for all openSUSE versions back to 11.0.
(As it is really fresh, some Addons might not be updated yet and as always the latest previous version 3.5.x is still available in the mozilla:legacy repo.)
As mentioned in blogs here and herePrism 1.0b3 got somehow released.
I have updated the version I had in mozilla:beta and moved it to the openSUSE mozilla repository (even if it’s officially beta but then there is no previous version so it makes sense).
As the previous version it’s based on XulRunner and does not contain a full Gecko release which also means if you run Prism it will find a matching XulRunner automatically (not necessarily the latest one though what I consider bad behaviour and intend to fix).
Again my last post was quite some time ago and I think I need to summarize what happened since in openSUSE’s Mozilla land anyway (if I can remember all details).
Thunderbird 3.0 got released and is available as official update for openSUSE 11.2
I’ve prepared new Sunbird testing packages in mozilla:beta which also include Lightning addon packages to be used in Thunderbird and SeaMonkey as calendar extension. Those already landed in Factory as well.
For a long time I wondered how to manage my patchset and packages more comfortable and now started to try it with a Mercurial repository which holds the patchset and source RPM contents for XULRunner and Firefox (1.9.2/3.6 series for now). The repository is actually based on Mercurial Queues and can be found here. I made it available public to allow interested people to follow what’s going on there and also make it easier to contribute.
Firefox 3.6 is nearing a final release and can be found in the mozilla:beta repository in its RC1 incarnation. Factory contains the beta5 version of xulrunner (w/o Firefox) currently.
I plan to add (and already added) some new packages to the mozilla repository which are not directly related to the Mozilla desktop applications but providing lower level interfaces (e.g. mozldap and related things).
I spent some time to fix the GConf backend changes in XULRunner which are part of the lockdown infrastructure but disabled for openSUSE 11.2 because they broke a11y support in its original state. So Firefox 3.5.7 and 3.6.x have the feature integrated again.
Not sure if I haven’t forgotten anything but it probably still was worth a post.
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.