VMware releases Perl WS-Management library
Open Source Meets Business - Day1
The conference was quite well attended, reportedly over 700 participants with approximately 699 from Germany, all in business suites ... Redhat was present with a booth (showing olpc, http://laptop.org). Novell was nowhere to be seen - strange.
Most presentations had about 80% marketing content, 10% about the business model and 10% actual information. Redhats virtualization talk was especially contentless, a marketing talk given by a 'solution architect'. I had to leave early.
Presentations where limited to 30 minutes (incl. Q&A), with 6 to 7 tracks in parallel. I tried to choose the one with systems management or software architecture relevance.
Presentations - Day1
REST
Ralf Wirdemann gave a good and easy to follow introduction to the REST architecture style. Nothing new, but its good to see that such topics are presented to (reportedly) CIO level management.Too bad he had little 'real world' experience with either REST or Rails as his (non-)answers to questions showed.
SugarCRM: Is open source a viable business model ?
Short answer: Yes. Look at recent acquisitions: RedHat/JBoss 420M, Citrix/XenSource 500M, Sun/mySQL 1B. Nothing about SugarSRM as a product, but about the development (open) and business model (service & support).Network Monitoring with Nagios
This was the first of four (!) talks about Nagios.Monitoring is a hot topic for most IT admins. The presenter spend most of the time fighting the incompatibilities of MacOS Powerpoint with Windows Power Point and OpenOffice (doesn't show speaker notes ;-))
Filtering out the company marketing blurb, one learned that Nagios allows for cross-platfrom device and service monitoring. It uses its own client agent (available for Linux, Unix and Windows) but can also process SNMP management information from network devices. The client agent has a pluggable API for gathering information and there is a whole website dedicated to plugins.
The Nagios server, running on Linux only, provides the management infrastructure including a sophisticated alarm and notification system.
Customers seem to be quite happy with Nagios and only miss a reporting function. But this is planned for the future.
WS-Management
I presented my favorite topic, Web Services for Management. A remote management protocol providing true interoperable management capabilities between Linux and Windows.Slides are available in german (I said it was a german conference, didn't I ?)
Reverted
Reasons to use KDE 3.5.8
- It's a stable, well tested system which has had most of the rough edges whittled away over time - and most of the time, it just works. (This reason could be expanded into many bullet points - one for each thing in KDE 3.5.8 which works which is broken in KDE 4.0.0, but I'll leave it rolled up into a single bullet point to save this looking more like a rant than it probably already does - and leave the bug reports in bugs.kde.org).
- I don't have to use AIGLX (the non-compositing version of KDE 4.0.0's KWin isn't very useable), and so everything is much faster, Google Earth works and I can watch videos. (In KDE 4.0.0 kaffeine and codeine just show an empty black box)
- I can set up the panels just how I like them. (One medium sized panel at the bottom for the K-menu, the task list (or whatever it is called), a clock and the lock/logout buttons, and a small one at the top for a 'quick launch' bar, the pager and the system tray.)
- I think the style I use in KDE 3.5.8 is sharper than Oxygen currently is, which looks a bit blurry somehow - I'm not exactly sure why though. But it makes it nicer to use.
- Plasma on the desktop can be pretty (although it tends to crash a lot).
- KWin with compositing looks cool.
- Tabs in the Oxygen style look kind of nice.
- I can find bugs and report them so that KDE 4.0.1/KDE 4.1 can be better.
Never try to catch a train last minute.
Yesterday I tried to catch a train last minute. While running towards it I fell down. I got up again and managed to get it.
While sitting in the train I realized that my arm hurts and at my destination I went into a hospital. The X-rays revealed that my ellbow was broken ;-) Nohting serious --- it'll hopefully heal within two weeks...
So my advice clearly is: Never try to catch a train last minute --- let it pass!
And the moral is: The next train would have departed in only 30 minutes...
Damn!
P.S. In the next two weeks you'll only get short messages from me since I can only type with one hand :-(
KDE 4.0: The First Week
Generally, KDE 4.0 seems a fair bit slower than KDE 3.5, but I think that might be down to the compositing stuff. Also, there are quite a few little niggly bugs which I hope will be fixed by 4.0.1. I've reported a few bugs, but I'm still trying to work out reliable ways of reproducing some of them before I report them.
I said in my last post that I was inspired to start coding for KDE 4.0. Well, as usual, my inspiration has quickly waned as I moved into a new house and have more useful things to do at the moment, such as painting. So don't expect code from me any time soon.
My current tasks
Usually I write blog posts announcing what I have done, but this time it is useless. So I’m going to blog about what I’m going to do. After latest Strigi irc meeting, I came out with this task:
KDE integration: Flavio will coordinate the definition of interfaces over which KDE will handle searching and metadata. He can ask Aaron, Evgeny and Jos for help with the interface design. The interface will cover:
Querying via Xesam
Configuration of the Strigi daemon
Indexing and deindexing of data by passing it to the daemon (allowing for indexing for more than just files)
Controlling the daemon (starting, stopping, pausing)
Once this interface will be ready, it will be easy to integrate Strigi functionalities inside KDE programs. This mean (just reporting the most relevant cases) that it will be possible to create a Strigi krunner, have metadata extraction inside Dolphin and Konqueror, interact with Akonadi…
Talking about Xesam, right in these days I got a mail from Fabrice Colin, author of Pinot. Recently Fabrice made some improvements on Pinot’s XesamQueryLanguage parser (which is also used by Strigi). We’re now figuring out how to share our code in a more convenient way. Maybe we’ll use svn external…
Application Usage Monitoring
Recently I’ve had a couple of ideas for a project (like I need another one of those). The goal would be to make a library which allows applications to easily track their user’s interactions and log them in a central location. Project maintainers/contributors could then look at the collected data to help them make decisions about what they should be spending time on. For instance, a media player might log what types of files are played or if it was synced to an iPod-like device.
As far as technical hurdles go, doing something like this is pretty easy. The main questions I have are around the kind of policies that should exist for such a thing. Obviously, participation should be opt-in. But should it be on a per-app basis, or per-user? Or both? If it is per-app, you would likely get bombarded with a prompt on the first run of every app that uses this system. If that is a small number it might be ok, but hopefully that wouldn’t be the case :). On the other hand, maybe you don’t want certain sensitive applications (email client?) ever sending info.
Then there’s the question of who should have access to the data. My feeling is that the user should always be able to see everything that he has sent. But should he also be able to see everyone else’s individual data? What about the aggregated data? That leads me to the next question. Should there be a cookie that identifies a single user throughout all applications? Or even a cookie per-application? I think having a cookie across all applications would definitely make the data more useful, but I’m not sure if people would be opposed to such a thing. Of course, this leads to yet another question. How do we keep personal information out? I don’t believe there is a technical solution to keep things like this from making its way in. Developers will need to be very careful, and that kind of bothers me. If all of the data on the server is available to everyone then maybe public scrutiny will help keep things in check, but who knows.
These are just a few of the questions I have come up with, and I am sure others can think of plenty more. Is it possible to come up with something that benefits the development community without infringing on user’s privacy? Even so, would users participate? Comments are open.
Living with KDE 4.0
Well, I've had KDE 4.0 on my machine for a day or so now, and I'm getting used to it. I've switched to running AIGLX so that I can use KWin's OpenGL mode instead of the XRender mode, and it's a lot more stable, although I can't run Google Earth any more. With the OpenGL rendering, the desktop look great, and the beauty of the desktop alone is probably enough to stop me switching back to KDE 3.5 at the moment. A few times I have clicked on a window only to have it completely disappear without warning - not sure what that's about. There are a few niggling little bugs in the behaviour of a few things, but I'm sure they'll get sorted in a minor release before too long. (Such as icon widgets not working with a graphics tablet, not being able to hide the plasma blob, konqueror not loading images or styles, etc.)
I am inspired to try writing some plasma applets to do things properly. And when I say properly, I mean how I want them to work. I've had a look at some of the source for existing stuff, and it looks relatively easy, so instead of writing any more of this, I'm now going to go off and write some code. Perhaps. If I can stop gazing at the beautiful desktop.
Giving 4.0 a go
And what are my first impressions? Well, the first impressions are that it has, again, improved over the previous pre-release. A nice new wallpaper, a slightly sleeker panel, and a number 4 instead of a 3.97 or something.
My second impressions are that it's still very unstable, very unpolished and, to be honest, somewhere between an alpha and a beta in quality. I had been expecting the lack of features, as that was well advertised, but I had at least expected the released features to work. Anyway, I'm going to stick it out - it's going to stay on my computer for the next week at least, and I'll start writing bug reports., and looking forward to 4.0.1, or whatever comes next.
Strigi irc meeting
Just giving more voice to original announce: Tomorrow, Saturday 12 January, at 17 UTC an irc meeting will take place on #strigi channel (it’s on freenode if you don’t know).
During the meeting Strigi developers will discuss about the future developments of Strigi.
Special guest: Aaron Aseigo. You’re all welcome.