So… Not in Gsoc.  It’s a bummer, but in a way I am very happy not being in it this year.  I am very busy as it is, and to fail is worse to me then not getting in at all. I have started my Internship at Miro.  It’s been very productive, at least in my eyes.  [...]

I don’t know why people make such a big deal about Nine Inch Nails‘ With Teeth album. All I ever hear are people complaining that Reznor got lazy, sold out (to get out of his UMG contract), or that the music just plain sucks. I can see how people can argue that With Teeth may not be part of the best of Nine Inch Nails, but it is competing with albums such as The Downward Spiral, The Fragile, and Year Zero. The danger in doing great work such as those albums is that even good stuff can’t even compare. Also, comparing a radio album to concept albums is comparing an apple to oranges. Even still, that apple is still pretty damn good compared to the other apples in the basket. That’s not to say there is no Nine Inch Nails garbage out there. Reznor tends to release anything and everything, including remixes or concept explorations that probably shouldn’t see the light of day. With Teeth is not one of those things. It is still better than 80% of the Industrial/Rock music out there even if it sounds like it was made for the radio. I like it.

I wrote earlier that I was having problems with SUSE Enterprise Linux 10.1 and my wireless card working.  I thought it worked out of the box w/ Ubuntu but I was looking for a different network card.  The Dell D830 that I have and use with Kubuntu is the Intel 3985 and not the 4985.  This card works fine.  Now with the newer card and using 8.04 I can’t get the wireless card to work correctly.  I’ve googled and googled and can’t find a simple and easy step by step guide to get this card to work.   Any help

Dear Lazyweb, Does anyone have any graphs / charts / data comparing each distribution and the amount of commits their respective members did upstream for a project (ie like gnome)? I have seen the kernel ones with Redhat and Novell taking the lead in contributions, didn’t know if their were similar ones for any user space projects?

THANK YOU!

The Ubuntu-ni LoCo Team is holding a Translation Sprint on June 13th. If you don’t live in .ni, you can always join us at #ubuntu-ni in irc.freenode.net What: Ubuntu Translation Sprint When: Friday, June 13th (09:00-16:00) Where: ISI, Managua Be there!! …or… bad things can happen to you!!

Last week's edition of Ciberpaís included a lengthy article which tried to explain Debian's and Ubuntu's OpenSSL problem to unexperienced computer users, it's impact, what should people do and what happens next. Mercè Molist sent in a few questions for me to answer, a small part of which were used in the article. While I don't like a few bits of the article that much, I tried my best to make it clear that Debian is not a bunch of clueless and careless Free Software enthusiasts. The treatment that the incident had in some well known Spanish security-related websites was in my opinion deplorable, so I want to thank Mercè for the opportunity to clarify some of the Debian bashing. I expect the full interview will be published either here or at Mercè's website in the following days.

I have been working pretty hard lately, mainly coding some personal projects. I always used to listen to music whilst coding, these days I tend to listen to podcasts. Is that sad? Maybe, maybe not. Either way, I thought I would post a list of Linux and Ubuntu related podcasts which I listen to on a regular basis [the list is presented in no particular order]:

• LugRadio — one of my favourite podcasts and probably THE podcast which got me hooked on listening to podcasts. LugRadio is released every 2 weeks and is currently in its 5th season. The production quality is always excellent and the content can be very thought provoking. Note, the LugRadio presenters are somewhat notorious for their use of colourful language, therefore it is probably not wise to listen to this podcast while at work [without headphones], or in the company of minors ;)
• The Linux Link Tech Show — again, another personal favourite, and again, a podcast which is not particularly safe for work. TLLTS is released every week and is normally over 2 hours in length. It is also probably [?] the longest running of all Linux related podcasts. Production quality is not always the best; however, the show is presented in a down-to-earth manner and the content is varied and interesting. The presenters often interview influential members of the Open Source community.
• Ubuntu UK Podcast — a fairly new podcast, [just released episode 6], but a very good one; IMHO, it could quite easily become the official Ubuntu podcast. The presenters apply the Ubuntu Code of Conduct to the show and therefore it is safe for work. Production quality is excellent, as is the content; Mark Shuttleworth has already been interviewed twice! Hopefully the presenters will be able to continue to push out this level of quality. The show is published every 2 weeks.
• Launchpod — again, another fairly new podcast. Launchpod is not strictly speaking a Linux podcast, still, due to Launchpad's close ties to Ubuntu it is interesting to hear news from the Launchpad developers. Production quality is fair and content ranges from Launchpad specific news to interviews with Launchpad users. There does not seem to be a set release schedule [very un-Ubuntu like]. Note, listen out for the funky base!
• lottalinuxlinks — a Linux related podcast by Dave Yates, recorded at 75 miles per hour during his drive to and from work. I am not sure it is entirely safe [or legal for that matter] to record a podcast whilst driving, still, I enjoy listening to this podcast as it has character :) Like TLLTS, the presenter has a relaxed, down-to-earth approach to podcasting. Production quality is fair and the content is varied. Released frequently.
• Fresh Ubuntu — an Ubuntu specific podcast which covers news and community happenings. Another podcast which is presented in a down-to-earth manner. Production quality is generally good, as is the content which provides an insight into what is occurring within the Ubuntu community. Released most weeks.
• Linux Basement — "Greetings & Salutations", is how this podcast is commonly introduced, it goes downhill from there :D Just kidding, the Linux Basement is another down-to-earth Linux podcast, although content covers other topics such as Drupal and web development. The presenter, Chad Wallonberg, also entertains by writing and performing songs for the show. Production quality is good and the podcast is released every 2 weeks or so.
• Linux Outlaws — a podcast in which the presenters take a "laid-back" look at Linux and the Open Source scene. The presenters have good chemistry and the show is often amusing and insightful, although not particularly safe for work. Production quality is good and the show is released most weeks.
• The Bad Apples — Linux from the perspective of an ex-Apple user. The show has recently been released less frequently than before; still, when it is released it is often varied and insightful.
• The Talk Show — okay, so it is not Linux related; however, it amuses me to listen to Mac fans. Also, is it not good to mix it up now and again? Released sporadically.
• hashlugradio — a podcast which discusses issues raised by the LugRadio podcast and its community. Has recently been released less frequently than before, when it is released, the quality is good and often amusing. Another show featuring colourful language.
• The Linux Action Show — the Linux podcast presented by Bert 'n' Ernie from Sesame Street. Not :) The real presenters, Bryan 'n' Chris, take an energetic look at the latest Linux related news and releases. Production quality and content is excellent. The show does feature some strong language, though not nearly as colourful as LugRadio. The podcast is released every 2 weeks.

The above pretty much sums up the podcasts I am currently subscribed to. Am I missing any which you think I might enjoy? Tags: linux, podcast, ubuntu

As some may know I have entered, together with a team from my company, Holman Fenwick Willan, in this July’s Water Aid 6 Peaks Challenge. This is a challenge to visit the summits of the highest peaks in each of the six regions of the British Isles, all within 72 hours: Snaefell (Isle of Man), Snowdon (Wales), Scafell Pike (England), Ben Nevis (Scotland), Slieve Donard (Ulster) and Corran Tuathail (Republic of Ireland). The walking amounts to a total of 50 miles with climbs of 20,000 feet, two sea crossings, not to mention 1,000 miles of driving in our trusty camper van. In 72 hours… Our team is made up of 6 walkers and 2 drivers. The challenge is in aid of a very worthy charity, Water Aid, and we have undertaken to raise the very significant sum of £4000. We would be very glad of your support, which can be given at our Just Giving website page. The more donations we receive, the more inspired we will be in our training! Please also feel free to pass these details directly onto any family, friends, colleagues or total strangers who you think may be interested in supporting us in this challenge.

Let me tell you something about “less”: You are probably underrating it for no reason. Of course you know “less” is always there and it does it’s job - showing files while being able to scroll backward - and some even use it instead of “tail”. But, hey, let’s examine some of the command line options to get more out of less: -M: this option extends the prompt on the bottom. By default less in most cases just shows the name of the file it is showing, with “-M” turned on, it also shows how many lines the files has, which lines it is currently showing and how far (in percent) you have gone. No killer feature, but nice to have. -i: this option causes searches to ignore cases. A search for “pattern” therefore also finds “PaTTerN”. You like this, don’t you? You like this even more, as this search still enables you to switch case sensitive search on by searching for a pattern containing at least one uppercase letter. A search for “Pattern” for instance would still be case sensitive. If you even want to prevent this, you could use “-I” which totally ignores cases. -r: Sometimes getting warnings about binary characters? With “-r” you tell less to display raw characters. This can help you when displaying files containing color codes. It is said that log files from Rails contain these types of code. -c: Just a gimmick to redraw the screen more clearly by beginning from the top line instead of scrolling. This might result in a slightly increased data transfer rate when using ssh but can improve usability. -a: This causes less to skip found search patterns when pressing “n” not from item to item but from page to page. You might know the pain when searching for a pattern that comes up more than once on a page and you start hammering “n” getting confused on what you have already seen and what not. This options just skips at least the current page before displaying the next found pattern while still marking all patterns of course. -f: This can help you in conjunction with “-r” to force the display of raw characters without being questioned again. Confused about the sequence of the options? Don’t be: $ less -Mircaf is something you just learn or create an alias for. This one, to sum up the options, will display an extended prompt, ignores cases in searches, while being able to switch them on, skip found search patterns at least per page, display raw characters like color codes without asking and redraws the screen as good as possible. Another feature that should be mentioned is the “follow file” mode that some of you might know. It is similar to tail as it shows you the content of a file that gets appended while viewing. You turn this mode on by pressing “F” (uppercase F). The advantage over tail is that you can interrupt the mode by pressing ctrl-c and scroll back though still being able to return to follow by pressing “F”. Not so familiar is the fact that you also can jump into the follow mode from the command line: $ less +F starts the follow mode immediatly. Of course typing “+F” on the command line is not sophisticated as typing “tail” but you can create an alias for it like “ltail” or whatever you like. As a summary: $ alias eless="less -Mircaf" $ alias ltail="less +F" gives you two new commands. “eless” as an extended less provides you with the described features. “ltail” simulates “tail” but enables you to jump back to the normal less by pressing ctrl-c. Instead of creating an alias for “less -Mircaf” you could also use the environment variable “LESS”: $ export LESS="-Mircaf" A credit goes to mnemonikk, who was just too lazy to blog this. Please note: As less is still being developped, command line options might slightly change. For instance in newer version “-R” instead of “-rf” might lead to the same result. Just try it or check the version of less you are running (”less –version”) against the official less changelog.

I can't count the number of times people have offered $100 bounties for implementing some feature or other in Inkscape. From what I've seen - and I've seen MANY features come into Inkscape from folks who aren't developers - $100 is the wrong way to do it. Not that people are anti-money or anything like that. Certainly we've gotten rabid success out of our Google Summer of Code projects, but these pay out $4500. So maybe $100 just isn't the right price point to stir interest (even a simple feature is going to require 10-20 hrs work, at which point you might make more flipping burgers!) In any case, aside from GSoC, I've not really seen that many successful cash-for-code projects in Inkscape. But I *have* seen a number of similar situations that ended up *quite* successful, but didn't involve money at all. The Mac port of Inkscape is my favorite example. Inkscape started as a Linux-only product but quickly gained a Windows port. A lot users were also very interested in seeing a Mac port, but few of the active developers were all that interested. I think maybe someone even offered a $100 bounty for it, although I'm not certain; in any case none of the existing developers took interest in doing the port. But there was one user that was really interested in getting it, and he sat down and hacked away on it. After a few weeks he talked to me and said it was just too frustrating to get something that worked properly and he was giving up on porting it. (IIRC, he was able to get it to build but not cleanly, and when it ran it didn't work properly.) I sympathized but encouraged him to write up his notes into the Inkscape Wiki, to explain how far he got and the problems he ran into. "Maybe someone else will know how to sort those issues out some day." Meanwhile, people continued to clamor for a Mac port. Eventually, another person took interest in just doing it himself, and when he asked me about it, I pointed him at the wiki page the prior person had written. This was useful in getting a leg up, and he was able to sort out the build problems the first person had run into, but he eventually also gave up frustrated with the limited results he saw. I encouraged him to update the wiki page with his findings. This cycle went on for some time, but eventually enough knowledge had accumulated that someone (JiHo I think) was able to clean it all up into a proper procedure, and to start getting successful builds that more people could use. This enabled people to focus on the next layer up - fixing the Mac-specific bugs. Now there were also complaints that while it ran on Mac, it looked out of place and was hard to install due to its dependence on libx11. People started clamoring for a "Native Mac Inkscape Port". And so the cycle began again... In Inkscape I've seen this pattern repeated again and again. And not just in Inkscape. This seems to be a universal mechanism for how open source works. I'm sure there's an aphorism or law or something that describes it. In any case, the lesson that can be taken from this is that if you want to get some feature or fix into an open source project, rather than offering money, have a go at it yourself. Even if it is well beyond your technical ability or time availability, your efforts may be enough to simulate someone else to eventually have a go at it too. This could be a detailed procedure you followed that got close to working but had a fatal problem. Or a messy patch you made that *should* work but doesn't. Or it might be a list of possible solutions you've ruled out and why. If you think, "I want a way to just throw money at the problem and make it just work," then remind yourself, "Time is money" and throw time at the problem instead of cash. Spend $100 worth of your time banging your head on the issue, trying out ideas and hacking on code if possible, and posting the results even if they turned up negative. They may give someone enough of a clue to stand on your shoulders and reach the goal.

I am pleased to announce that the Michigan LoCo Team is holding a Bug Jam on June 9th at 6:30 pm. What is a Bug Jam? Every day people report bugs about Ubuntu in the bug tracker Launchpad [0] but the number of bugs reported is more than the current bug triagers can effectively handle. In short, the Ubuntu community needs more bug triagers. But how do you triage bugs? Bug Jams are events where people who are interested in learning how to triage bugs get together to learn how to do this and answer everyone’s questions. It is a fun learning event. Also, it is a great way to get started doing your 5-a-day and add your name to this list and increase our team’s ranking: http://daniel.holba.ch/5-a-day-stats/ When and where is our Bug Jam? It is Monday June 9th at 6:30pm at the Main branch of the Clinton-Macomb Public Library [1]. We will be in a conference room with free wifi to library card holders. People without local library cards can sign up for one in 5 minutes, but if you are planning on doing that, please try to show up a little bit early. Directions can be found here: http://tinyurl.com/5rygg3 . What should I do before the Bug Jam? Check out some of the bug triaging resources online right now like: https://wiki.ubuntu.com/HelpingWithBugs and https://wiki.ubuntu.com/Bugs/HowToTriage There is a wealth of information linked to from this page: https://wiki.ubuntu.com/BugSquad/KnowledgeBase What do you do after the Bug Jam? There are plenty of restaurant/bar options in the area to celebrate a jam well done and eat dinner. Feel free to email the mailing list[2] for coordinating rides and asking questions before hand. [0] https://launchpad.net/ [1] http://cmpl.org/ [2] https://lists.ubuntu.com/mailman/listinfo/ubuntu-us-mi

Found this in my feed reader today. Classic.

I have been using 4.0.x since January, so I have learned to live with some of the quirks such as suddenly disappearing panels. The KDE4.1 beta fixes many of these problems, as well as gives the desktop a tremendous speed boost. Some other improvements I’ve noticed are: * Smooth scrolling in Dolphin and Konqueror, even on pages/directories containing lots of images. * Drag and drop icons from the menu to the panel and desktop for shortcut launchers * Add more than one panel! * Very good and fast desktop effects with Xrender. Fglrx is currently broken for me, so this is a big issue. * Ozone lets you have differently colored window borders * the Display systemsettings module actually seems to work * Plasma stability (especially nice for a beta) * very innovative “+” and “-” in dolphin when hovering over icons for selecting multiple files/directories * When you resize the panel, the various applets are resized as well. As a side note, I have been using Neon (nightly amarok builds).The default Neon color scheme does match the default plasma color scheme, but it does not match my slightly tweaked scheme. Apachelogger handily came to my rescue and told me to copy the kde4 kdeglobals to the neon config directory. “cp .kde4/share/config/kdeglobals .amarok-nightly/share/config/” will do this for you nicely.

I got the opportunity to sit down at UDS/FOSSCamp with the Brainstorm guys: Stéphane Graber and Nicolas Deschildre. These guys have done an amazing job implementing Brainstorm and adapting it to user feedback, but while they're busy writing the software and finishing school it was clear that they needed help getting developer involvement in the site. One thing we're always cognizant about in the back of our heads is how transparent Ubuntu's development and processes are. It wouldn't be useful if people just posted ideas and got no feedback on the feasibility of their ideas. So I've been collecting developer responses to the big ideas. Today I posted the first response from our X.org maintainer Bryce Harrington to Idea 322. I've also added Chris Cheney's OpenOffice.org responses to Idea 298 and Idea 3395. I'll be posting more responses to ideas over the coming days. I will also be hunting down developers for more responses and getting them more involved in answering ideas. Of course if you're an Ubuntu Developer and would like to post in the developer comments section then we gladly will accept any feedback you can give our users. Get ahold of us and we''ll put you to work. :) These responses will hopefully illuminate the progress of different areas of Ubuntu and educate users on How Things Work(tm). Of course, I also recommend the YouTube Ubuntu Developer Channel for more information. Stéphane and Nicolas have larger plans for Brainstorm so stay tuned!

Ubuntu X.org maintainer Bryce Harrington writes in a response to Brainstorm idea 322: Configuring X has been a long standing issue in Linux, and there's still room to improve. Brainstorm 322 and its comments touch on a bunch of (partly unrelated) problems: a) mis-detecting monitor resolution/refresh rates b) supporting new hardware (and upcoming USB monitors) c) binary driver issues d) Importing Windows .inf/.icc files e) multi-monitor configuration / detection; multi-card support To cover this range of issues, I need to give some background on where things are at, so please pardon the length of this reply: Xorg upstream's vision is that no configuration should be needed. In the vast bulk of cases, the hardware reports its capabilities and xserver can set things up properly. Besides, few users wish to deal with hacking on config files, and some are even put off by gui config tools. This is a very good vision, and in fact something like 90-95% of the time it holds true. I remember in Feisty the most common complaint by Ubuntu reviewers was "it didn't get my resolution right"; thankfully that is a thing of the past - reviewers hardly ever mention resolution problems these days. This was largely due to installation scripting bugs, that were relatively straightforward to sort out. Yet, there is still that last 5-10% or so that causes our problem (a) in the list above, which aren't due to install scripts (we've essentially eliminated install scripts these days). This 5-10% can be broken into three classes: A. Defective hardware, requiring quirks to work around issues B. Legitimate Xserver or misc driver bugs C. New hardware, not yet supported Class A is the easiest to deal with, since the symptoms are quite common, relatively easy to detect, and with patches that can be safely backported. It use to be that we would work around these issues in our installation scripts, but over time the pile of workarounds got to be complicated and hard to maintain. These days we work with upstream and pass bugs and patches to them and include them in the new development version of Ubuntu (and sometimes where feasible we backport/SRU them to the stable version too). This is beneficial because it helps all distros not just Debian/Ubuntu, and it gains upstream's help in maintaining the workarounds down the road. Class B is harder to deal with, but also a priority that we hope continues to reduce in magnitude. Often these issues are exposed by new technologies coming on line (RandR, compiz, etc.) which is normal for actively developing software. Other times they're due to the evolving needs of users or the evolving capabilities of newly released hardware. It would be nice if we had better testing tools. Indeed, this was a hot topic at XDC2008 last month, and it's been an item on my own todo list lately (see the 'x-testing-infrastructure' blueprint). But honestly, due to Xorg's nature even the best testing tools would be only able to catch a fraction of the possible bugs. So this makes human testers (i.e. YOU) very, very important. Thus, the approach I've focused on for Class B bugs is to help strengthen the human testing side of things through improving documentation for bug reporting, troubleshooting, and so on - see http://wiki.ubuntu.com/X/ - and through creating tools and resources that help users and testers more easily help us (pre-built driver binaries, etc.) Also see this Ubuntu Open Week for discussion: https://wiki.ubuntu.com/MeetingLogs/openweekhardy/ImproveX Class C is a different situation, because there is continually new hardware coming out, as problem (b) in our list above indicates. Fortunately, we are seeing upstream vendors (Dell, Intel, AMD, VIA, others) putting a priority on Linux support for their newest hardware. Indeed, these companies have begun collaborating with us at Canonical to test and ensure that support for their hardware is in place well before the general public sees it. I'm very optimistic about this and think it will make a huge difference moving forward in eliminating this whole topic as an issue, especially if the other graphics card vendors come on board. Proprietary binary drivers (problem (c) above) are in a special category, since we don't have a way to patch them ourselves and since we can't troubleshoot them as easily (no debug symbols for backtraces, etc.) However, these days both AMD and nVidia are releasing their drivers on a quite regular schedule, and have made steady progress towards solving the bugs people see. (I suspect the bugs people do encounter are quite memorable, so the drivers may have a reputation for being buggier than they actually are when you look at the actual bug counts in Launchpad.) In any case, AMD/ATI has recently established a relationship with us for forwarding triaged -fglrx bugs their way. Due to all the work going on in all the above areas, I think we can safely expect to see the number of problems in classes A, B, and C decrease from the 5-10% or whatever, to something quite vanishingly small. Given how far we got since Feisty, I have high hopes for Intrepid and Intrepid+1. So, all of this is building the background for the following point I want to make regarding X configuration tools: Tools to work around X config issues may not be worth the time to craft them. The issues they address may go away completely by the time we're done, or X may change in such a way that keeping the config tool bug-free becomes hard. Hopefully all the foregoing answers half the issues raised in Idea 322. The other half of 322 focuses on multi-head configuration problems. A large part of the problem with multi-head is that we're in the midst of a lengthy transition from Xinerama to Xrandr for managing multiple displays. This transition is not fully complete yet, and while it has brought advances in some areas, it's resulted in feature regressions in others. For example, monitor hotplugging - such as plugging a projector into a running laptop - now works quite well (esp. for Intel graphics). However, the new Xrandr is designed in such a way that it can only establish one combined screen for one video card. This means that dual-head layouts are possible with a 2-output video card, but four-head layouts using two video cards won't work (or at least will be very hard to get set up). In Gutsy, we supplied a tool called displayconfig-gtk which provided for doing multi-head layouts via Xinerama, and had some other nifty features such as monitor .inf import (problem (d)). For Hardy since so many drivers use Xrandr rather than Xinerama, we've deprecated that tool in favor of a new Screen Resolution tool. For more information on this transition, please see: https://wiki.ubuntu.com/X/DisplayConfigGtk For .inf import, rather than doing this in a local config tool, a thought we've had is to replace that functionality with an online monitors database - see https://wiki.ubuntu.com/X/MonitorsDatabaseOnline - however the quirking approach has been so effective in solving monitor resolution detection issues, I wonder if time is better spent there...? In any case this is something I hope to see discussed at UDS. Screen Resolution uses Xrandr to do dual-head layouts on the fly. We have some tips for getting the most use out of it (and working around a couple issues) at https://wiki.ubuntu.com/X/Config Screen Resolution does not touch xorg.conf at all. This is a good thing, in that it avoids a lot of problem scenarios that displayconfig-gtk would run into. It also means screen config can be done without a root password! However, video drivers have some Options that can be set in xorg.conf but not on the fly (the Virtual option is a particularly needed case in point), and it would be nice to have a way to set them. It may be nice to have a tool that can be run from an Advanced button in Screen Resolution or something, that allows "editing" the xorg.conf file in a more GUI-oriented fashion. Going forward, one of the next big, high-priority changes in the Xinerama->Xrandr transition involves abstracting the way video card memory is handled. This will permit the memory in several cards to be pooled and thus allow mapping a screen over multiple cards (which will finally solve problem (e)). When that happens, Xrandr will finally have the framework for supporting >2 heads. I hope to see an initial version of this in Intrepid for experimentation purposes, with a stabilized version available by Intrepid+1. A lot of this depends on the quality of testing efforts by community members, so if this is something you're passionate about and want to put some effort in, you can get involved in Ubuntu X to help push it forward. Finally is the topic of binary drivers and multi-head layouts. In some cases the binary drivers have much different support for this than the open drivers; sometimes this is because those drivers still use Xinerama, in other cases it's because they have their own solutions to the problem. I would expect as these drivers switch over to using Xrandr, you may also see some regressions in >2 monitor support here. Hopefully the above covers the 5 problems stated in brainstorm 322, illustrates where we are now and gives you an idea on a timeframe for the remaining improvements.

The Ubuntu Develpers Summit finnished a week ago in Prague. Unlike conferences, summits have written output in the form of specifications which form the basis for work on Kubuntu for the next six months. You can find the Kubuntu ones on this wiki page. We started with kubuntu-release-schedule where we discussed the possibility of moving the Kubuntu release schedule to match that of KDE. We decided against this in the end, but I think it was a worthwhile discussion to have. There would be goodness in the form of the latest and greatest KDE with each release, but it would also be a more buggy .0 version, would mean releasing with a 4 month old platform and would be quite a bit of extra work. Kubuntu Intrepid Version makes the decision to move to KDE 4 by default (anything else is history). KDE 3 libs will still be available for applications without a KDE 4 version, but the desktop won't be. It's a good time to move to KDE 4 since Intrepid is intended to be a more cutting edge release. KDE 4 Porting lists the various bits that need to be ported to KDE 4. From the upgrade tool to printer configuration, there's quite a few here. Kubuntu Intrepid Council says we'll be needing new council members for the group who vote on memberships and occasionally other decisions. We'll be implementing this at the Kubuntu council meeting on Wednesday 22:00UTC in #ubuntu-meeting, all welcome. With Kubuntu Filesharing we specified how sharing files should be made easy for users. This is something which has annoyed me for a while and it wouldn't be hard to fix, a daemon which launches a webdav server or pokes Samba in the right way plus integration into the file manager. Kubuntu Intrepid Website looks at changes we'd like to our website, although currently the main blocker is getting the new Drupal version launched at all. Finally Kubuntu Intrepid Defaults decided to go with the lovely KDE 4 defaults, stripy window bars and all. But we came up with some changes to Kickoff we'd like. So plenty of work there to do, we'd love you to join us in #kubuntu-devel to help out. Happy Summit Group Photo

It's Monday, and I think we are all still tired from last weeks event. At least the brain is regenerating, but the body is still in rescue mode. The last day of LinuxTag was very crowded...many visitors, even that we were fighting against the "Internationale Luftfahrt Ausstellung 2008". There were still many good keynotes and talks on this day and I think one of the best keynotes we've seen was held by Jono Bacon. One Man, One Hour, A volcanic eruption of a Keynote. There were only 3 keynotes I heard of, where people were afterwards really excited about..Aaron Seigos, Jonos and one of the Trolls (I missed it, and I somehow lack the name...so if someone give me a clue, I'll update it..) Anyways...I think you'll find enough pointers where you can read the "official" opinions...but you know, "dry" texts are boring...what you want is the "inofficial" part...(That's why our famous "Bild" Newspaper is so good...Politics is nothing, but the girl on page 1 is important and the news about Angelina Jolie or Britney Spears...but most people won't tell you that ,->) So, after last year, Ubuntu/Canonical was inviting people to their Ubuntu BBQ at the C-Base in Berlin. And it was great...good location, good beer, good food...and tired people. Introducing Monika from the Kubuntu-de.org Booth team...secured by Tux feet...I wonder what she dreamed of ;) Everyone needs groupies ;) so, meet Franziska...she's really awesome, and it looks like that our "Groupy-Troll" Thomas liked her, too (not to mention her BF Arthur, who really is a lucky man :)) Speaking of groupies...I'm a groupy of this guy: Marcus...without him, really, nothing works. He rocks, he's humble. He organized the event, he's packaging software, he is the mother of kubuntu-de.org booth team for Berlin, he takes care that everything is in place (even the kubuntu-de.org content). Actually, he needs all the hugs and kisses from the team. You did see our Kubuntu-Dev, Amarok fanboy and Daily Build Master Harald (apachelogger) how he is doing everything to please the community, that he sleeps in Bathtubs, sleeps at tables and wearing really sexy underwear ;) But to push all this, you need really much energy. Energy just comes from good food...and Harald really needs a lot of energy...so look at this, how "charming" it can be to eat a "Triple Whopper" by Burger King. CAUTION: Don't look at this if you have a nervous stomach or you are not a fan of horror movies... I heard , that the word "Whopper" in the US has the meaning of "an extravagant or monstrous lie"...believe me, everything written in here is true...there is no lie, never ever, really, trust me...everything is true, it happened exactly as I wrote...if someone is telling you otherwise, don't trust him/her, only trust me... In other words: LinuxTag 2008 was great...great people, good organisation, good drinks, awesome parties, and as always less sleep. Happenings on Sunday: We were taking a car to travel back home, and around 100km before Karlsruhe, one stupid car-driver had the bad idea to pull from the right lane to the left lane, while our car was still at 160km/h running on the left lane. Thanks to Manuel (Quassel Developer) and a working ABS+ESP logic in the Mercedes C Class we didn't bang into the guard railing...but after this event, the board computer of the car broke down...no ABS, no ESP, no Speedometer, no navigation...the whole board computer part crashed away. We had to drive to a Mercedes Partner, who told us, that we had luck, that the computer actually was working...without it, we could have been killed. Damn, we are lucky people, I wonder if it was just because we were wearing geek shirts and especially the KDE one. Personal News: When I came back home this morning around 3am (UTC+2) I learned that one accident could lead to publicity. Last year, one day before the 31st December 2007, I showed my GF and some of her familiy members this strange YouTube Video "Kleiner Hai" (Little Shark). While we were discussing the "wow, how crazy is this now" and "how many pills she took to become so crazy", I said, "why don't we create a cameroonian version of this...". The working title "Der Hai Wahnsinn geht nach Afrika" (The Shark Crazyness moves to Africa). We captured two versions and I think the linked one is the craziest of those two... But, that this "meme" would become a import public  newsevent, we never expected that. Now, I was told, that our video (one of the two we took) is linked from the "Sueddeutsche Zeitung". Furthermore, the girl who made the very first video, she's now a famous "Techno" Star...and for the official video they took some snippets from other peoples "Kleiner Hai" videos on YouTube. I think 3 or 5 secs of our video is also in there. Much more worse, or let's say crazy: RTL Explosive, it's somewhat of a TV boulevard magazine, made a report of this phenomenon on the 30th of May...they took around 5 or more seconds out of the really crazy african version ;) and I was shocked, to see my bald head on TV... Now, what does it mean: Never ever do stupid things, even when you have a nice party, the people are somewhat crazy, never put your face on a video, never publish it on YouTube...because you don't know what will happen...I wonder what will happen tomorrow morning when I'm going back to work... Anyways those news gave me the final blow...and now it's time to go back to bed to get some more sleep.  

[10:29:10 AM] Dude: there’s way too many “social” networks to keep track of nowadays [10:29:51 AM] Og Maciel: hehehe [10:30:01 AM] Og Maciel: I’ve been using Tweet these days [10:30:10 AM] Og Maciel: but not as aggressively as some people [10:30:22 AM] Dude: the one that says what you are doing every hour? [10:30:25 AM] Og Maciel: sheesh, they “tweet” [...]

I am pleased to announce another new video on the Ubuntu Developer Channel. This one is the first in a series of instructional MOTU videos, that Daniel Holbach and I shot in London a little while back. If you are primed and ready to get going on your MOTU journey, this is a great place to start. See the video here.