sorted by: recent | see :
popular
Content Tagged opensuse
Andrew Wafaa: Public Apology
I have opened up a ticket with Nokia as their email.nokia.com service seems to insist on re-sending the same e-mail over and over at random times
Hopefully I have rectified it by deleting the originals and upgrading to the latest version of the software. This has been the only real issue I have experienced in almost 3 months of use, and granted it is still classed as Beta quality. Once again, I AM VERY SORRY!!
UPDATE: Looks like my fix attempt failed badly
Apparently I have managed to get some messages stuck in an endless loop on Nokia's SMTP queue which get triggered when I sync!
Ben Kevan: My recession proof investment plan, guarnteed 3+% return.
So with the US (and Global) economy in ruins, I decided to take another look at the way I have been investing. With my individual stock portfolio falling about 50% in the last 2 weeks, I’ve decided to guarntee myself an investment return. How you may ask? I opened a new account with E-Trade who gives a 3.3% return on their savings accounts.
Hope you all the best in these rough times also..
Aaron Bockover: Andreas Nilsson, stifling innovation, one virtual brick at a time
Too much time spent playing with legos today...
openSUSE News: Power Outage: Nearly All Systems are Running Again
Our admins and developers - in Nuernberg, Provo and from home offices - worked hard today to get all openSUSE services up and running again. Thanks a lot to all of them!
Nearly all services are be up and running again. The only exceptions are the services features and ideas, these will be restarted latest by Monday.
Ben Kevan: Gmail Advanced IMAP Features speeds up IMAP and dIMAP on Kmail (and others)
I currently use my gmail account with Kmail using dIMAP on openSUSE 11.0 running on KDE 3.5.10. I at times thought of moving to straight IMAP, but I loved having the offline features. However, this was painfully slow since it had to download everything twice (once in your “All Mail” and once in each of your folders which contain your messages that have been “labeled”). Not to mention another download once you moved them to your trash etc.
However, this has all changed with the Advanced features for IMAP in Google Labs. To enable this features log into your Gmail account, go to Settings, Labs and enable the following feature:
Now click on “Labels”.
Here you can uncheck All Mail and Trash. This limits the amount of mail that actually gets replicated (if using dIMAP), or refreshed (if using standard IMAP).
Now click on “Forwarding POP/IMAP” to configure some other great features. Why would you change these? Well because now, you don’t have to keep dragging the message to the Gmail trash folder, you can just delete in your local client, and it’ll move it to Gmail Trash automatically (about time).
Here are the settings I chose:
Read to official Gmail Advanced IMAP Blog Post
Now with IMAP I have the convenience of POP, with the great features and abilities of IMAP.
Need to set up Gmail IMAP / POP?, find that here
Need to download openSUSE? Get that here
Ben Kevan: OpenOffice 3.0 Your Way, Right Away
As you may know the next series of ooffice (OpenOffice) is due out October 13th as outlined in their RoadMap. However, that date is typically the date where it is widely avaliable to everyone. I am actually quite please to annouce, you can actually find it NOW from most external mirrors Listed Right Here and Right Now.
Are you wondering what OpenOffice 3.0 will bring to you? Wonder no longer, as we have some of the major enhancements listed for you here:
http://wiki.services.openoffice.org/wiki/
You can also find a great walkthrough of many of the features from an earlier version of 3.0 here:
http://www.oooninja.com/2008/03/openofficeorg-30-new-features.html
Here’s some direct links:
Linux tar.gz download US Mirror
Windows .exe download US Mirror
Micheal Meeks Measures and Defines the Success of openoffice.
Also, I imagine the openSUSE repository will be setup shortly after the repository servers come back on line (they are experiencing a major power outtage). The opensuse 11.0 openoffice stable repo can be found here:
http://download.opensuse.org/repositories/OpenOffice.org:/STABLE/openSUSE_11.0/
Enjoy.
Masim Sugianto: Zimbra Mail Server : How to Make an Archive for Every Incoming & Outgoing Mail
I’m running Zimbra Mail Server on openSUSE since last 2 years. I’m quite satisfied with the great features on Zimbra but I lost one nice feature as included on my old MDaemon Mail Server while still using Windows on 2003-2005. It was an Archival Feature.
One of the important features that are needed on a mail server is archiving, the backup copy of all incoming and outgoing mail.
Although we can do the backup process periodically for every account, archiving more better and efficient because we have all of copy email which 100% similar with the original.
I’m writing a simple tutorial and it’s impact in my personal blog. Click here to go to the article.
Michael Meeks: 2008-10-10: Friday.
- Up early, experimented cycling H. to school before punting that to J. hmm. Baby-sat a bit, and onto compiz - Beta3 should be in rather good shape, osc down so filed bugs variously. Poked at yast2.
- Prodded at boot charts; it seems on my machine, Jon's sexy new gdm - complete with nice a11y features, speech and so on, appears to start an entire session before noticing it is in auto-login mode & tearing it down again, poked at that.
-
Lunch, sidetracked by an interesting OO.o crasher. Poked at
gdm again; halfline pointed me at
daemon/INTERNALSwhich is somewhat helpful, but these async, multi-process, intensive IPC designs are still hard to grok; bother.
Vincent Untz: News from the User Experience Hackfest
It turns out we've not been really effective in communicating what's going on in the User Experience Hackfest that's going on right now in Cambridge. It's kind of good and bad at the same time: bad, because it's important to keep everybody in the loop; good, because it means we've been quite good on focusing on work :-) So here's a short summary of things, and hopefully more will come (especially a few mockups/whiteboard pictures that people are working on right now).
First, a big thanks to everybody involved -- artists, designers, hackers: we have some good range of skills represented here. Also a big thanks to the companies involved, who accepted to let their people come and actually even pay for the travel and accomodation. We have people from Canonical, Imendio, Intel, Novell (who is also hosting the hackfest) and Red Hat here, which is quite awesome. That's quite an investment from those companies, and it's really cool to see them step up like that. Novell has also sponsored a dinner for all participants on Tuesday; it was funny to have a seafood-lovers table and a vegetarian+others table ;-)
On Monday, we started by discussing the current status of GNOME, where we're good at, where we're lacking, etc. We then started focusing on a few topics. Those topics turned out to be well adopted and that's mostly what we worked for most of the week; more details on them in a few sentences. On Tuesday, we had some great presentations from Dave Richards and OLPC people, and both were quite helpful in different ways: getting closer to our users, and thinking out of the box. They definitely had an impact on what we did afterwards.
So, since Wednesday, we're working on the three topics that emerged during the first day: desktop shell, access to documents, and adding effects/animation to the desktop experience. I won't detail everything here, but I think we've ended up with some good stuff:
- effects/animation: this focused on adding the tiny touch that makes a difference for the user. This is actually quite useful to make things more understandable and intuitive for the user. People had some nice ideas there, some simple, sand sme less simple...
- access to documents: broad topic here, and I wasn't there for most of the discussions. I think many people liked the OLPC journal (hrm, can't find a good link for that with screenshots), and there's some kind of will to at least hide the hierarchical directory structure. A time-based view of the documents, some tag-based search and various other approaches were discussed, I believe. As was adding more context to documents (at least according to the whiteboard I'm looking at right now ;-)) -- the typical example being this document was attached to a mail from Jane received on Tuesday. I didn't look at the mockups, but it all sounds good to me, and I hope that having some of the right people talking together here will help make this all happen.
- desktop shell: this has been the topic I've been following. We started out by thinking about window management, workspaces, applets, sidebar and notifications. Many things :-) And we now have some good mockup which is quite different from what exists and also quite familiar -- probably because it makes a lot of sense (to me, at least). Some highlights are: making workspaces actually useful and discoverable for all users, fixing the way we find and launch applications, having a central piece of the shell in the form of a panel which makes it easy to access what's important, etc. It's quite hard to explain all that without the mockups, but we're re-doing them so they are in a publishable state ;-)
I guess it's quite hard to get a good feeling of all this right now, but once the wiki page will be a bit more filled, things should get clearer. We still have a few hours ahead of us, but I already feel like it was a good and productive week, with great results. And I'm getting really excited about what we'll do in the next 1-2 years!
James Ogley: Mum's gone to...
We're well used to hearing about states that allegedly sponsor terrorism - indeed, we can name the usual suspects easily: Iran, North Korea, the USA, Israel (sorry, two of those just enact terrorism themselves directly).
Now it seems we can add a new name to the list. Icelandic bankers are apparently terrorists. Why else would our government have employed anti-terror legislation to freeze Icelandic assets in the the UK? Surely those lovely Nordic types (statistically the most beautiful nation on earth apparently) with the coolest named banks in the world (Landsbankinn anyone?) can't be that big a threat to global peace and security?
A cynic might suggest that this demonstrates that the laws in question are framed in such a way as to allow the government to do pretty well whatever it likes. Yesterday, in the Lords, Lord Onslow said roughly that.
James Ogley: The Second "Debate"
I caught some of the second presidential "debate" via The Daily Show and what struck me was not McCain's derisory referral to Obama as "That One" nor his addled wanderings around the dais as Obama was speaking.
No, what amazed me was how almost life-like he looked.
Michelle Obama did a great job too. If you missed her, take a look.
Thomas Biege: °°°°°<*>Zipp<*>°°°°°
We have a power outage at the Nuremberg HQ... :-(
The views expressed on this website/weblog are mine alone and do not necessarily reflect the views of my employer. Note to journalists and other readers: Unless you receive express written permission to the contrary from the author of the content of this blog/website, reproduction or quotation of any statements appearing on this blog/website is not authorized. |
-
openSUSE News: Power Outage in Area where most openSUSE Servers are Located
Just a quick note: We have a power outage in the part of the city of Nürnberg where the Novell office and the main server room is. This means that many of our servers are right down, especially the download redirector, the mailing lists, the openSUSE build service and users.opensuse.org.
I will post a message once the power has been restored and all machines are running again. Current estimate (11am Nuernberg time) is that it will take another 4 hours (until 3pm Nuernberg time which is 13:00 UTC) at least to restore power.
Note: the power companies do not know yet exactly where the problem is.
This server and the wiki are located in another data center and are therefore available.
Updates:
13:15 CEST: New rumor: Current estimate for power restoring is six more hours, they need to dig up the street.
16:45 CEST: Bad news: It will take longer until power gets restored. The local power company just stated “22:00 to 23:00″. We will try to get then the first machines up but might not get everything running during the night. Btw. currently it seems that it’s only our office complex that is without power, the rest of the area has power again.
17:15 CEST: I just chatted with our admins, and they currently hope to have everything up Saturday around 13:00 CEST (11:00 UTC) if - and only if - there are no major problems like hardware failures.
18:05 CEST: The admins will start early tomorrow morning - there’s no sense waiting for the power company this night. The estimate stays at 13:00 CEST (11:00 UTC). We’ve never experienced such a long outage before, this is exceptionally bad.
19:02 CEST: Beineri has uploaded some photos from the construction site (thanks!).
20:04 CEST: Marko has uploaded some photos as well (thanks!). Some notes: I’ve heard (no official confirmation) that our office building has two power lines and currently both are getting repaired, they started with the first one and now dig out the second one as well. Our building seems to be the last one in the area to get power back since it’s the only one with a 20kV line.
1:30 CEST: Power is back in the office - later than estimated.
9:20 CEST: Our admins have brought the basic net infrastructure up and will work on the rest now.
9:45 CEST: The first servers coming up, download.opensuse.org is available again.
10:20 CEST: lists.opensuse.org is up again, I’ve send an announcement out to the mailing lists. I just don’t know when it will go through since some other systems are not running and I guess the mail queue is rather long.
10:33 CEST: After I approved my announcement, it went through directly and was sent out - this means, the infrastructure is indeed up and runing 
13:00 CEST: Most systems should be up, the only problems right now are login on users.opensuse.org and the build service.
15:00 CEST: Info from our admins:
It has turned out that the electric feeder cable outside the building was blown which had to be digged out and then repaired, so the first estimation of the energy provider was a little bit optimistic. Connection was re-established Friday night at about 1AM (localtime) and reconstruction started this morning at 7AM and most important services were back at about 9AM.
15:08 CEST: We’re still working on users.o.o and the build service, everything else should be ok.
18:50 CEST: users.opensuse.org and build.opensuse.org are back online. We should now be good enough for the weekend. Currently still down are ideas.o.o, features.o.o and tracker.opensuse.org (for our torrents). We will have these restored on monday.
20:18 CEST: tracker.opensuse.org (for torrents) is running again.
Michael Meeks: <h1>Measuring the true success of OpenOffice.org</h1>
What is success ?
Is success measured in downloads, or up-loads ? are bugs filed as good as bugs fixed ? are volunteer marketers as valuable as volunteer developers ? If we have lots of bugs filed and lots of volunteer management material is that success ? is the pace of change important ? Does successful QA exist to create process to slow and reject changes, or by accelerating inclusion of fixes improve quality ? Is success having complete, up-to-date and detailed specifications for every feature ? Is success getting everyone to slavishly obey laborious multi-step processes, before every commit ? Alternatively does success come through attracting and empowering developers, who have such fun writing the code that they volunteer their life, allegiance and dreams to improve it ?
I encourage people to download & use OpenOffice.org in one of it's derivatives. I'm pleased when people file bugs, help with the QA burden, promote the projet etc. However, in a Free Software project the primary production is developing and improving the software - ie. hacking. So the question is: how is OpenOffice.org doing in this area ? Are we a success in attracting and retaining hackers ? Is the project sufficiently fun to be involved in that lots of people actually want to be involved ?
As we are finally on the brink of switching away from the creaking (22 years old) CVS (provided by Collab.net), to an improved Sun hosted Subversion (sadly not a DRCS) - Kohei and I created a set of scripts to crunch the raw RCS files as they go obsolete. They reveal an interesting picture.
Caveats
As with any measurement task, we believe these numbers are fairly reasonable; and we try to make them meaningful. On the other hand perhaps there is some horrendous thinko in the analysis, bug reports appreciated. It'd also be nice to see if the internal Sun statistics match these.
Firstly - the data is dirty; since we're analysing RCS files; so - when files are moved to the binfilter, or even renamed they have been simply re-committed - causing huge commit spikes. Similarly license changes, header guard removals and various other automated clean-ups, or check-ins of external projects cause massive signal swamping spikes. We have made some (incomplete) attempts to eliminate a few of these. In recentish times all work happens on a CVS branch, which is later merged release engineers (who appear to have done ~50% of the commits themselves), so we filter their (invaluable) contribution out by account name (cf. rt's oloh score).
Secondly - another distorting factor is that we chart only lines added: in fact when you change a line it is flagged as an add and a remove; so the number is more correctly lines added or changed. This of course fails to capture some of the best hacking that is done: removing bloat, which should be a prioirity. In the Linux kernel case this metric also gives extra credit to bad citizens that dump large drivers packed with duplicated functionality, and worse it rewards cut & paste coding. I don't often agree with Bill Gates but:
Measuring programming progress by lines of code is like measuring aircraft building progress by weight.still at least the 'lines changed' facet should be helpful.
Thirdly - release cycles cause changes in contribution patterns, clearly frantic activity during feature development lapses into more bug-fixing later in the cycle. Thus we expect to see some sort of saw-shape effect.
Fourthly, working on OO.o is infernally difficult, getting code up-stream is extremely and unnecessarily painful - this results in many contributors leaving their code in patches attached to bugs in the issue tracker, and we make no account for these; these changes (if they are committed at all) would appear to be Sun commits. Thus it is possible that there is at least somewhat wider contribution than shown. Clearly we would hope that full-time contributors would tend to commit directly to CVS themselves.
Magnitude of contributions
This graph is more meaningless than it might first appear, the raw data still shows noise like individuals committing obvious sillies copying chunks of OO.o to the binfilter eg. To some extent it is further distorted by us trying to clean this up for the past couple of years before giving up:
So the data is not that useful. Is it more useful to look at an individual to see if they are contributing something ? If we threshold the data we can at least approximate an activity metric / boolean. The graph below shows two developers - the Sun developer Niklas Nebel, and the Novell hacker Kohei Yoshida. Both work primarily on calc, and you can see the large bar when Kohei committed his solver to a branch at the end of 2006.
It seems clear that we can at least approximate activity with some thresholding. More interesting than this though, we can see a most curious thing. Despite Calc (apparently) being the relative weakness of OO.o, and Niklas being the maintainer of the calc core engine, and the calc "Project Lead" (with special voting privileges for the 'community' council), in fact he hasn't committed any real amount of code recently. That jumps out in the comparison with (vote-less) Kohei in the last six months. It is very sad indeed to all but loose Niklas from the project, though at least we'll see him at OOoCon. Verifying this counter-intuitive result with bonsai reveals the same picture.
Activity graphs
Extending this metric to the entire project we see perhaps a more interesting picture. By thresholding contributions at one hundred lines of code added/changed per month, we can get a picture of the number of individuals committing code to OO.o. Why one hundred ? why not ? it's at least a sane floor. Clearly we get a metric that is very easy to game, but luckily that's hard to do retrospectively.
It is clear that the number of active contributors Sun brings to the project is continuing to shrink, which would be fine if this was being made up for by a matched increase in external contributors, sadly that seems not to be so. Splitting out just the external contributors we see some increase, but not enough:
Novell's up-stream contribution appears small in comparison with the fifteen engineers we have working on OO.o. This has perhaps two explanations: of course we continue to work on features that are apparently not welcome in Sun's build cf. the rejection of Kohei's solver late in 2007, and much of the rest of our work happens in ooo-build, personal git repositories, and is subsequently filed as patches in IZ.
A comparison
So, it should be clear that OO.o is a profoundly sick project, and worse one that doesn't appear to be improving with age. But what does a real project look like that is alive ? By patching Jonathon Corbet's gitdm I generated some similar activity statistics for the Linux kernel, another project of equivalent code size, and arguably complexity:
Graph showing number and affiliation of active kernel developers (contributing more than 100 lines per month).
Quick affiliation key, from bottom up: Unknown, No-Affiliation, IBM, RedHat, Novell, Intel ...
There are a number of points of comparison with the data pilot of active developers aggregated by affiliation for OO.o.
Similarities: both graphs show the release cycle. Spikes of activity at the start reducing to release. Linux' cycle is a loose 3 months, vs. OO.o's 6 months.
Differences: most obviously, magnitude and trend: OO.o peaked at around 70 active developers in late 2004 and is trending downwards, the Linux kernel is nearer 300 active developers and trending upwards. Time range - this is drastically reduced for the Linux kernel - down to the sheer volume of changes: eighteen months of Linux' changes bust calc's row limit, where OO.o hit only 15k rows thus far. Diversity: the linux graph omits an in-chart legend, this is a result of the 300+ organisations that actively contribute to Linux; interestingly, a good third of contribution to Linux comes from external (or un-affiliated) developers, but the rest comes from corporates. What is stopping corporations investing similarly in OO.o ?Conclusions
Crude as they are - the statistics show a picture of slow disengagement by Sun, combined with a spectacular lack of growth in the developer community. In a healthy project we would expect to see a large number of volunteer developers involved, in addition - we would expect to see a large number of peer companies contributing to the common code pool; we do not see this in OpenOffice.org. Indeed, quite the opposite we appear to have the lowest number of active developers on OO.o since records began: 24, this contrasts negatively with Linux's recent low of 160+. Even spun in the most positive way, OO.o is at best stagnating from a development perspective.
Does this matter ? Of course, hugely ! Everyone that wants Free software to succeed on the desktop, needs to care about the true success of OpenOffice.org: it is a key piece here. Leaving the project to a single vendor to resource & carry will never bring us the gorgeous office suite that we need.
What can be done ? I would argue that in order to kick-start the project, there is broadly a two step remedy:
- Kill the ossified, paralysed and gerrymandered political system in OO.o. Instead put the developers (all of them), and those actively contributing into the driving seat. This in turn should help to kill the many horribly demotivating and dysfunctional process steps currently used to stop code from getting included, and should help to attract volunteers. Once they are attracted and active, listen to them without patronizing.
- Distance the project from Sun: perhaps less branding, certainly less top-down control, reduce the requirement to 'share' all your rights over to Sun before you can contribute to the project. Better still, share ownership of the code with a non-profit foundation to guarantee stability and an independent future for the code-base.
Unfortunately, the chances of either of these points being addressed in full seem fairly remote - though, perhaps there will continue to be some grudging movement in these directions.
A half-hearted open-source strategy (or execution) that is not truly 'Open' runs a real risk of capturing the perceived business negatives of Free software: that people can copy your product for free, without capturing many of the advantages: that people help you develop it, and in doing so build a fantastic support and services market you can dominate. It's certainly possible to cruise along talking about all the marketing advantages of end-user communities, but in the end-game, without a focus on developers, and making OO.o truly fair and fun to contribute to - any amount of spin will not end up selling a dying horse.
Postscript
Why is my bug not fixed ? why is the UI still so unpleasant ? why is performance still poor ? why does it consume more memory than necessary ? why is it getting slower to start ? why ? why ? - the answer lies with developers: Will you help us make OpenOffice.org better ? if so, probably the best place to get started is by playing with go-oo.org and getting in touch, please mail us.
Finally - we invite you to repeat the analysis, the raw spreadsheet data (for data-miners) is here: ooo-stats.ods linux-stats.ods and the RCS parsing scripts parse_rcs.py with dependants in that same directory.
Jan Nieuwenhuizen: 2008-10-09: Thursday
-
Look at why LanguageBox is empty. This is the easy part.
sal_uInt16 SvxLanguageBox::InsertLanguage (LanguageType const, sal_uInt16) { return 0; } sal_uInt16 SvxLanguageBox::InsertLanguage (LanguageType const, bool, sal_uInt16) { return 0; }SvxLanguageBox is a 400 loc wrapper that looks up the string to insert for LanguageType SvtLanguageTable, which is a 100 loc wrapper for an arraySvtLanguageTable::SvtLanguageTable () : ResStringArray (SvtResId (STR_ARR_SVT_LANGUAGE_TABLE))I wonder if we can do away with all this Res, Sv and Svx cruft and just have a std::map with languages, even if we have to fill them from Res* for now. Sometimes I wonder why so much of our code is made up of wrappers and or reimplementations of std::*. - Looking at why our Format listbox is such a mess, I find that SvxFontListBox is *not* a vcl/listbox as it's implemented now in layout::. It is a SvTabListBox, which is a SvTreeListBox, which is a SvLBox, which is a Control and SvListView. Interesting. And I always thought gui code was easy, I wonder why we seem to need so many listbox code.
- Conny phones, notices some discouragement and coaches me on three grand primaries. What coincidence! ;-) Experiencing that discouragement is "just" a state of mind (victim flavour) brings rest and widens your perspective. A good giveaway is that whenever you feel discouraged you see it everywhere.
-
When reducing the number of entries in the format listbox so that it is not taller than the TabControl window, a vertical scrollbar appears. Nice. So if we can enforce a maximum height for listboxes, things should be fine here. -
Something interesting shows up when not running Format Cells on a remote X: the width of the whole dialog seems to be that at which the layout::TabPage is truncated. It seems that layout::TabPage sometimes gets the width from the wrong source. - Found why our Category listbox is empty: the entries are specified as a static string item list in the numfmt.src. Alas, src2xml.py does not handle that yet.
