openSUSE Linux

Well, it's been a long while since my last news ... but I've got some nice news to report - my submissions of redshift and backintime were accepted into openSUSE Factory. So these useful programs will be part of the next openSUSE release ... [More] , hooray!Redshift is a little command-line (and GTK) utility which reduces screen brightness at night (via colour temperature, so your screen becomes more red). Given your location in the world, it automatically calculates sunset and sunrise and gradually ramps up/down the brightness at the right times. I find it makes working at night easier on the eyes, and wrote a little plasmoid to control it easily from the desktop, which I will also release when I get some time.For previous openSUSE versions one can download and install redshift from its OBS devel project, X11:Utilities.Backintime is a backup program, effectively a rsync frontend, with GUIs for KDE and GNOME. Once configured with which folders you want to back up, and where you want to back up to, it can automatically take backups based on a schedule. Also a very nice feature is that on filesystems that support it (not FAT), it uses hardlinks to the previous backup, so each backup is a full backup but only changed files take up space on the backup disk. Each backup is just a normal copy of all the folders, so no special software is needed for recovery, but backintime offers a GUI that allows you to easily navigate through all your backed up versions of a folder. IMO it's the best userfriendly but complete backup software for Linux desktops. backintime used to be packaged by packman and now lives on the OBS in Archiving:Backup.Enjoy! If you have other interesting programs that aren't in openSUSE remember that anyone can contribute to Factory now, so if you are willing to maintain them, go ahead and submit them on the OBS! My next target is byobu, a set of preconfigured GNU screen profiles (I never figured out how to write hardstatus lines!) [Less]

This week in three short achievements: - personal OBS project (playing around, tutored by DimStar), work in progress - code tide-up, ready for merging into master - features, usage and testing documentation, work in progress I’m now focusing on the ... [More] gtk3 part, and also documenting things around. Packaging has decreased priority, waiting for the pygobject release. And done [Less]

Watching season 01 of Falling Skies. Not bad, not bad at all.It can haz alienz in it ! Falling Skies

Started playing a bit with chef and puppet tonight.Chef hasn't been ported to openSUSE yet, it only has some very primitive (and non-functional) support for SLE. Will require to add support for zypp et al.Puppet works out of the box though.Think it's ... [More] about time that I introduce that at work, in order to have something more reproducible and declarative than just fiddling around with config files here and there ;-)Not sure it'll be all that useful for the sysadmins on the AIX, HPUX, ... boxes though ^^ [Less]

(Bicycle-) Wheel building is an art. An art perfectly suited for a geek; it requires technical insight, knowledge, feeling and some experience. For those interested, here are some tips and pointers from my own experience.1) Buy "Professional guide to ... [More] Wheel Building" by Roger Musson, it is going to be the best 9GBP you have spent in a long long while. [HINT1]2) Read it, twice!3) Buy the rims and hubs before you buy the spokes (and get the necessary tools too if you haven't already).4) Measure the ERD (Effective Rim Diameter) using the old-spokes with glued-on nipple method that Roger describes [HINT2].5) Buy the spokes that spocalc.xls then calculates for you.5) Lace your wheel like Roger describes, to the letter.6) Tension your wheel like Roger describes, to the letter [HINT3].HINT1: Do not read any other sources, Gerd Schraner's book is just pure nostalgia and does not help you much. Especially his explanation for tensioning your spokes should be ignored: while it might get you a straight wheel, your spokes might have wildly varying tension, and are therefor likely to either break due to fatigue or have the wheel go out of true quickly.HINT2: For creating the cut-off spokes for measuring the ERD as Musson describes; screw your nipples onto your spokes so that your spoke only _just_ comes out of the nipple into the groove for the nipple-driver. This is the measuring length you should use. If you use the absolute top of the nipple for measuring the length, then you will have no room for error, and you will very likely use up all of the thread on the spoke while bringing the wheel up to full tension (this is the experience bit right here). If it is still inside the nipple, then you most likely will end up with too short a spokes, with thread still showing, this too is a nightmare for wheel-building (your nipple-driver will not disengage). Once you bring your wheel up to its final tension, the spoke (especially double butted spokes) will come slightly further out of the nipple as with the measurement-spokes.HINT3: For the final stage of tensioning, where the spokes tend to turn with the spoke-key, I marked the rim-sides of the spokes with different colour alcohol markers. This gave me the ability to view the turning of the spokes, and to undo it, close to the rim and nipple, without hampering the spoke-key. Since this is an alcohol based marker on stainless steel, you can rub it off afterwards, or you could just take some alcohol to wipe it off. I just kept it on now, knowing full well that most of it will disappear soon enough in the rain and mud.I am using Extreme Airline 3s, which i got from Rose. These are rather deep rims that are very stable and sturdy, and they have a wear-indicator still. The joint is not done well, and you will always have a third or so of a mm difference in diameter there, but for trekking or mtb tires, this is no issue, it is just annoying when working on the wheels in the stand. Because these rims are so sturdy, the Schraner method becomes quite unreliable, you can much more easily get away with differently tensioned spokes, as the rim is much more likely to even differences out for you instead of showing where the differences are. You actually need to pluck the spokes instead, like Musson describes, early on in the tensioning process, to get rid of the differences in tone and therefor tension.I ordered a pre-built set of Airline 3s (28" with LX hub and 3N72 dynamo) from Rose more than a year ago, and they seem quite sturdy and have served me well so far. But, sadly, these pre-built wheels were not up to tension, which I could hear on steep climbs as the spokes were rubbing against eachother with heavy and changing load. They were subsequently very hard to tension further, my guess is because of badly oiled nipples before assembly.Recently I built a first set according to the Schraner method, and while this went well, and the wheels feel good, I am not sure how good they really are as I haven't used them yet. It could be that they go out of true quickly, especially after pumping quite a bit of heat in them going down some slope in the Fränkische Schweiss. The spoke lengths I used for the 28" Extreme Airline 3 rims, triple crossed (of course!) and with 12mm nipples are 276mm for the front, 281/283 for the back.For the 26" version of the same rim, with the same hubs, same lacing, same nipples, I used 246mm for the front, and 251/253 for the back. This was calculated with spocalc after measuring the rim, according to Musson, and the ERD is 523mm (after correcting for my mistake). These wheels are for a velotraum cross crmo frame that I am just now building up, so there are no kms on them either, but I have a very very good feeling about them, as I did use Mussons book for them, and the wheels came together as good or even better than described. So while my own handiwork is still untested in real-life conditions, at least I can tell the difference between Schraner and Musson, and the spoke lengths are (now) correct too ;)In any case, if you are into cycling, have done all other jobs around the bicycle, and mastered them, already, then try your hand at wheel-building to complete the skill-set. It is not black magic, it is actually highly logical, but you should not use sentences like "How hard can it be?" or "Right, I'll get my hammer!" when doing so. Read the right book, get the right tools and the correct spokes, and then take your time; it is really very rewarding. [Less]

openSUSE 12.1 is on its way, and recently LXDE got some major updates. I’m personally always been really satisfied of how LXDE works and is integrated into the openSUSE user experience, one defect though , that I’m really sorry about, is that i was ... [More] never able to provide a very nice look&feel. Since I’m not a graphic, and i realized I’m failing, i decide to ask your help now. Here is what we need: 1) A gtk2 + openbox theme (including lxpanel background and icon theme) 2) A theme for lxdm (you can use /usr/share/lxdm/themes/Industrial as template), and eventually a background too Also, i would like to open a contest. Your goal is create a logo for openSUSE-LXDE project. You’ll have more information as soon as possible about this contest on the [email protected] mailing list and here on lizards, please keep in mind that we want to print the winning logo on t-shirts too. Up to date info about the contest will be available in the wiki here I hope lot’s of you will help. Andrea [Less]

In the next few days, I will be posting a couple of trivial short thoughts on some frequently debated “issues” of Bitcoins that keep coming up e.g. on #bitcoin and that I reacted to. The basis of Bitcoin are “blocks”. Sometimes, they are regarded as ... [More] just a magic device for getting bitcoins by the mysterious activity of mining. But the main purpose of blocks is to build a trustworthy distributed database of bitcoin transactions. The trustworthiness comes from the blocks, which confirm the transactions by a “proof of work” – non-trivial computational effort. The reason we want this “trustworthiness”? We are tackling one of the major problems of distributed currencies – double spending. You have a coin tied to an address; at the “same moment”, you could send two transactions to two nodes of the network, in one sending it to Alice, in the other sending it to Bob. Which of the transactions becomes accepted by the network? Half of the network might think you send the money to Alice, half that it goes to Bob. The point of the “block chain” is that no conflicting transactions appear in it, and the transaction with the most computing power behind it wins. Unfortunately, you might need to wait for a block with your transaction in it for anything from five minutes to 1.5 hour, and for your transactions to be trustworthy enough, some followup blocks need to be accepted (the “confirmations”). This is a nuisance if you want to make real-time with bitcoins, of course, be it buying a soda can in vending machine or hefty TV in an electronics shop. It is also sometimes used as an argument against Bitcoin. But there are two ways to deal with the issue. The first way, even mentioned at the Bitcoin wiki, is just not caring about the problem. If the payment is just few bitcents for groceries, it is just not worth the hassle. Hassle drives away customers and the loss may be greater than an occassional double-spend cheater makes. The modern society (including credit card companies) relies on the fact that people tend to be honest when there is non-infinitesimal risk. In case of a hefty TV, non-infinitesimal risk may be worth it. But the solution is again no rocket science: a trusted third party. Two schemes may be possible – with a flexible plan, the service would have a contract with the customer and the merchant. At the time of payment, the service will send the money to the merchant and the customer will pay to the service. If money do not arrive, the service will sue the hell of the customer; the merchant gets their money regardless. Thinking about it, this works a lot like credit cards. With a fixed plan, there is even less hassle for the customer. They just make a deposit to the third party – this is an upper limit to their spending. When they purchase an expensive TV set, the merchant receives guaranteed payment from the third party, while the customer sends the money to the service. If money do not arrive, it gets reimbursed from the deposit. An initial deposit (and thus more trust in the third party) is required, but the customer may remain anonymous and the service can have smaller legal department. Bitcoin Spending Insurance could be a suitable name for one service like this, but you could have countless, like you have multiple credit card companies and many banks. On the merchant side, another service might aggregate them conveniently, and on the customer side, they may compete with their bussiness plans, bonuses, advertisements and other wretched capitalistic means. ;-) I.e., this reduces the decentralization of Bitcoin, but so do currency exchanges and other services – it is an optional addon and if the users do not mind the wait, they are free to avoid it. In short, no need to worry about the fact that transactions are not real-time. Next: Bitcoin and Anonymous Transactions [Less]

Once again today I was reading the openSUSE Strategy community statement and I can get out of my head how wonderful the begging of the statement sounds: 'We are the openSUSE Community - a friendly, welcoming, vibrant, andactive community. This ... [More] includes developers, testers, writers,translators, usability experts, artists, promoters and everybody elsewho wishes to engage with the project.'The greater of all is that all of the people of openSUSE are making this more than a statement, people around the globe are working hard for this to be a reality. You can come to the openSUSE Conference in Nuremberg and feel that in person. Learn what RWX³ means in action.You still have time to join us. [Less]

Tonight, the new board of directors of KDE e.V. went out for dinner, generously (!) treated by our constituency. It was a nice and relaxed dinner, gave us some good opportunity to brief Lydia (our newest board member) on how we work, boring stuff ... [More] like where we store our documents, what to expect from our bi-weekly conference calls, what granularity of emailing we found to be productive, and so on. One official thing we always have to do (according to German foundation regulations, so-called “Vereinsrecht”) is appointing roles. Cornelius was volunteered as president, Frank as treasurer, both accepted their new and old responsibilities. I promoted from regular board member to vice president (which really only has a a theoretical meaning). The vote was, as usual a formal thing and we got it done between dumpling 2 and 3 on my plate, it took all of 3 minutes. Serious, effective, yet duely diligent. :P We also used the opportunity to talk about non-board stuff, about our other projects in KDE (we’re also pretty active in the community outside of the board chores), private going ons, random fun things. I came back happy about our team, and looking forward to our work in the coming year. Just right. Earlier this afternoon, we met with the GNOME board. There were also some personal changes in the new GNOME board, I especially enjoyed Ryan Lortie (desrt) having joined the board of directors of the GNOME foundation. I’ve met Ryan at several occasions in the past, and always found that we got a good click, enough differences to keep conversations interesting, but very much one the same line of communication. One of the topics was communications across the boards, and we thought that having some kind of ‘open communication channel’ for situtations which might turn unproductive would be good. Ryan and me volunteered, and we took immediate opportunity and went out for an afternoon drink, which I very much enjoyed. While going to our dinner appointment, I had really two things in mind, love and hate. Not sure why those two words sprang to my mind, but I really hate saying goodbye to the people I love. Even if it’s very much a temporary thing (our meetings in the Plasma team have become pretty frequent, especially with Plasma Active One being on the horizon), having people leave after an intensive week of excellent collaboration always makes me kind of sad. That’s of course just an indication of how much I enjoy working in this excellent team, or maybe just a sign of exhaustion after a week of pushing the Free desktop to the next level with peers who are as passionate about this as I am. Tomorrow in the afternoon, I’ll take a train back home to the Netherlands, and will commence putting our plans (and continuation, tweaks thereof) to action. Exhausted after week of frantic Free software conferencing, but just as energized as if it were my first Akademy. The coming weekend will be used for catching up on sleep, then next weekend, I’ll be at Froscon, where I’ll be presenting Plasma Active. Be there if you want to touch it yourself. :) [Less]

Should you read this article in a blog roll, here is a clue what it is about: a) the SMB Traffic Analyzer project (SMBTA), b) the openSUSE conference, and c) Samba. You guess it, we finally got a slot for a presentation at the wonderful openSUSE ... [More] conference for SMBTA. To me, it is remarkable to see a project like SMBTA being presented at OSC because it is not really something related to openSUSE. It’s not that SMBTA improves your boot time, or discusses details of the buildservice, or makes your life with the openSUSE distribution better in any way. SMBTA is very likely not even interesting to the casual user, except for some administrators. That said, SMBTA was born inside of the openSUSE infrastructure, growing to a project used on different distributions and operating systems, such as Solaris. And the one thing we can really say is that we exploited all the services that make up openSUSE to the core. We used the openSUSE Buildservice from the beginning, and we use appliances created by SUSE Studio for both demoing and developing SMBTA. With the recent release of Samba 3.6.0, among it’s top changes like full SMB2 support and other major features, it is also prime time for SMBTA. The Virtual File System layer module that supports our current infrastructure is included in this release of the Samba CIFS server and that marks a milestone for our project. SMBTA is already used in production at some sites, and the release of Samba 3.6.0 will hopefully forward this trend. Benjamin Brunner and me will give an introduction talk to SMB Traffic Analyzer at the openSUSE conference and most likely live-demo the software chain. We’ll welcome anyone interested to join our presentation at OSC! [Less]