- Target Group
Designing a Linux distribution for a beginner, a office user, a gamer or a hardcore geek is very different. - Bleeding edge
Bleeding edge means support for the latest technology but code is less tested/used generally resulting in more bugs and security flaws. - Packet Manager
There is no "best packet manager", instead there are several with different pros and cons. Mainly however this is an inheritance from the "base distribution" the actual distribution is built upon (most distributions are based on one of the big distributions like Debian, Red Hat or Slackware and these in terms are built around different package management systems). Anyhow, it's a difference between distributions. - Interface
A graphical interface is a core component in modern operating systems. In Linux you have tons of options (just to begin with you have split Window Managing and Desktop Environment) and you can customize most to infinity more or less. One very common difference between distributions is which WM/DE they've choosed and how they've choosed to customize it. - Hardware support
This includes which processor architectures a distribution supports, if any specific hardware is supported, some distributions come with tons of drivers others not and so on. - Speed, Looks or Security
Looks (animations, effects etc.) and Security (encryption, real time watchers etc.) comes at a cost of speed. Different distributions balance this differently, some even go to the extremes like distributions with very lightwieght applications, minimal graphics etc. that provides the user with maximal speed or distributions with every possible graphics effect enabled, HD-res wallpapers etc. to give you an astonishing visual expecience. Most however try to balance this to "at least decent values all around". - Preinstalled applications
Office suites, choice of media players etc. is easily customizeable in Linux but different distributions choose different preinstalled sets, some even come without anything not to "get in the way" of the user. - Looks
Something pretty much every distribution customize. This includes background image, color scheme etc. - Completeness
Some distributions come with tons of applications installed and everything preconfigured while others come bare stripped so that after installation you don't even have a graphical interface. To sum it up: Some distributions try to help and guide the user to a complete set of applications while others try not to get in the way of the user, installing only what's considered necessary for it's target audience. - Availability to low level components
As a beginner you want the system to handle itself, new hardware are automatically detected, settings are made i GUIs etc. If you're a performance geek or just like to have complete control over your system however, you don't want the system to accidently override your tweaks or install stuff you've not choosen yourself. - Community / Support
This generally corresponds to the target audience and popularity of a distribution where more technical ones generally (not always) tend to have communities where you're expected to have a fundamental knowledge about Linux. If asking "too simple" questions you might be handed the RTM answer (Read The Manual). On the other hand you might have beginner forums where too technical questions might be overlooked or quickly swarmed by very basic, easy to answer, questions. Size also matters. Big communities often mean someone knows the answer to your question but it might be easier to get personal help in a less populated community. Once again, this is way to simplistic to really tell the truth, but at least you get an idea.
25 August 2012
What differs between Linux distributions?
This article is a shorter version of my old one in Swedish. If you're interested in the original one, please send me a note.
10 July 2012
Lessons from a one year old - a reflection about reflecting
Some time ago I watched my one year old play with one of those shape sorter toys (put the block through the equally shaped hole to get it into the box). The problem is he's a bit too young so he pretty much tried to bang all the four shapes into the circular hole (which actually worked once for the star shape but that's another story) getting more and more frustrated, especially when all the circular blocks were already in the box. So with a stroke of genius he removed the lid and started filling (and emptying) the box with ease looking up at me to recognize his success. My reaction? "No no no, put the lid back on". A few seconds later I started reflecting upon my reaction. This is the result of that reflection.
Lesson: It's not the receiver's fault when you are unclear
In this case it's hard to know exactly how my son was thinking but looking at his action/reaction my guess is he saw the mission as getting the blocks into the box while my idea was to find the right hole for each block, the getting it in the box was just a proof of correct behavior. So I failed at communicating my model and when he acted according to his interpretation (finding a better solution to my problem) I rejected his solution and more or less degraded him by correcting an error he wasn't even aware of.
Lesson: When someone finds a flaw in what you've communicated, that's creativity, not cheating.
I found this very often to be the case in school. If you are creative, finding a solution not thought of/intended (mostly known as "cheats") you are often rejected. Real example:
In one course we were split into groups and built an autonomous robot. In the spec it said "when hit, the robot must continue straight forward for 3 seconds". So we simply made the robot go forward in 3 seconds (the goal was to send all enemy robots of the arena) but also turned down the speed by a factor of 10 when doing so. My idea of a good reaction reaction from the teacher would've been something like, "Well, you pointed out a flaw in my spec, I'll make a positive note about it but please change back to regular speed forward". His reaction? Something like "Well, now you're just trying to cheat, you know very well what I mean!".
Lesson: You need to monitor if the receiver has actually understood you
When I tried to communicate my view, in this case a very simple one, I failed. Since I just assumed we had the same view I didn't really notice that my kid got happy when the darn block was in the box not when he found the right hole. In retrospect waiting expectantly when he actually found the hole and cheering when the block was in box was not very helpful. Of course my intention was to not reveal the solution but all and all it was just a good intention not good communication.
Lesson: It's important to share the same view
Let's pretend I was in my son's position and could speak. In that case I should have asked a whole bunch of questions, mainly: "Why on earth did you put this stupid lid on the box?", that would have saved both me (him) and the dad (me) the frustration.
Lesson: Models limit our creativity
If someone would have told me to, as quickly as possible, get the blocks in the box I would probably not have removed the lid simply because my model is "blocks go into the box through the holes in the lid". The same task given to my kid would have rendered him removing the lid and hence, beating me. Beaten by a one year old?! Just because I'm too stupid to look beyond my assumptions? And I make big money on my thinking skills every month while he is officially a cost!
Lesson: What's obvious to me is not obvious to everybody else
I didn't even think of the fact that my kid might not share the idea of "how to play with a shape sorter", to me it was too obvious. Of course all, or at least a vast majority, of my colleagues share this view but in that case it could instead be "of course they've thought of handling negative values as input". I think you would go mental if you never were to trust anyone about anything but at least question you assumptions.
Lesson: Assumptions must be under constant review
To ensure we don't end up doing bad assumptions and inefficient problem solving we need to constantly question and review the usefulness and relevant context for the assumptions we make. Since assumptions are shortcuts we fall back on to save us from constant tedious repetitive thinking I guess it's in their nature to be hard to monitor. One thing I find helpful is lateral thinking puzzles, since they by design challenge your assumptions.
Lesson: Courage to question is an important skill
Instead of just going with my idea of putting the blocks through the holes in the lid my kid continued to try to remove the lid. That might not always be the best solution, but at the same time I guess you can excuse a one year old for not starting a sophisticated discussion about our different views on the shape sorter. Anyway, the skill to question someone else's assumptions (and therefore uncovering what might be interpreted as facts rather than assumptions) is an important skill to anyone, one that might get you into trouble in the wrong environment but make you a hero in the right one. If you're in an environment where questioning isn't appreciated you might need to question what you're doing there by the way...
Lesson: Being too helpful is not helpful
I had my best intentions when I corrected my kid and in this particular case it might be useful for him to listen. However helping people too much can lead to less thinking, making them scared to go with their own idea or even stop evolution (as in how solutions to problems can evolve over time). Let people think, let people think and before correcting them, ask why they've gone a certain route, maybe we're more right than you?
Lesson: You need to spot assumptions
Finding assumptions require constant observation. At work I recently uncovered that you could actually simulate a certain type of hardware in our system simply by not just accepting "it doesn't work". Once again, of course you can't spend all your life with trying to question every little aspect of every little statement but to challenge common propositions you've not seen/heard any proof of is, to me, a very healthy behavior.
Lesson: Questions is a tool
Well, I've already touched upon this several times but I think it's important enough to highlight again. Questions are an essential tool that you need to use to clear any uncertainty or ambiguity in whatever someone tries to communicate. "Are you sure that..." is often a good start or, if you really want to be considered a genius pain in the butt, go for "why", "why doesn't it work". Never accept something that seems unclear just because you're too afraid to question or afraid that you'll look stupid (hmm, really nice that I write this as a exhortation to you when I'm one of those who really need to work on this).
The most important lesson...?
"You can learn an awful lot from a one year old"? Well, to put it in a more general context: "You can learn an awful lot by just reflecting on an everyday event". I could have come away with tons of lessons like this from reflecting about virtually anything, how I act when I'm cooking, how me and my girlfriend share work at home, how a colleague react to my bug report etc. You could argue some of this is just associations from associations (not immediately related to the example I reflected from) but I guess that pretty much sums up what thinking is (going from one interesting idea to another). You could also argue that a lot of this is just common knowledge and well, it is, just like it's common knowledge not to eat crappy food, don't make up apologies and go to bed in time, sometimes we need reminders, at least I do.
One final question: What else could you learn from this? Well I didn't even start on the psychosocial aspects, parenting in general, I had a lot more interesting associations to school that I didn't bring up, you could question the toy or how it could be redesigned to better set the rules or challenge the user's creativity... well I guess I need to stop otherwise I won't be able to sleep tonight but there you have some more aspects in case you want to continue .)
So to sum it up: Reflect! It's not just a valuable skill to practice, it can also lead to very interesting results.
Lesson: It's not the receiver's fault when you are unclear
In this case it's hard to know exactly how my son was thinking but looking at his action/reaction my guess is he saw the mission as getting the blocks into the box while my idea was to find the right hole for each block, the getting it in the box was just a proof of correct behavior. So I failed at communicating my model and when he acted according to his interpretation (finding a better solution to my problem) I rejected his solution and more or less degraded him by correcting an error he wasn't even aware of.
Lesson: When someone finds a flaw in what you've communicated, that's creativity, not cheating.
I found this very often to be the case in school. If you are creative, finding a solution not thought of/intended (mostly known as "cheats") you are often rejected. Real example:
In one course we were split into groups and built an autonomous robot. In the spec it said "when hit, the robot must continue straight forward for 3 seconds". So we simply made the robot go forward in 3 seconds (the goal was to send all enemy robots of the arena) but also turned down the speed by a factor of 10 when doing so. My idea of a good reaction reaction from the teacher would've been something like, "Well, you pointed out a flaw in my spec, I'll make a positive note about it but please change back to regular speed forward". His reaction? Something like "Well, now you're just trying to cheat, you know very well what I mean!".
Lesson: You need to monitor if the receiver has actually understood you
When I tried to communicate my view, in this case a very simple one, I failed. Since I just assumed we had the same view I didn't really notice that my kid got happy when the darn block was in the box not when he found the right hole. In retrospect waiting expectantly when he actually found the hole and cheering when the block was in box was not very helpful. Of course my intention was to not reveal the solution but all and all it was just a good intention not good communication.
Lesson: It's important to share the same view
Let's pretend I was in my son's position and could speak. In that case I should have asked a whole bunch of questions, mainly: "Why on earth did you put this stupid lid on the box?", that would have saved both me (him) and the dad (me) the frustration.
Lesson: Models limit our creativity
If someone would have told me to, as quickly as possible, get the blocks in the box I would probably not have removed the lid simply because my model is "blocks go into the box through the holes in the lid". The same task given to my kid would have rendered him removing the lid and hence, beating me. Beaten by a one year old?! Just because I'm too stupid to look beyond my assumptions? And I make big money on my thinking skills every month while he is officially a cost!
Lesson: What's obvious to me is not obvious to everybody else
I didn't even think of the fact that my kid might not share the idea of "how to play with a shape sorter", to me it was too obvious. Of course all, or at least a vast majority, of my colleagues share this view but in that case it could instead be "of course they've thought of handling negative values as input". I think you would go mental if you never were to trust anyone about anything but at least question you assumptions.
Lesson: Assumptions must be under constant review
To ensure we don't end up doing bad assumptions and inefficient problem solving we need to constantly question and review the usefulness and relevant context for the assumptions we make. Since assumptions are shortcuts we fall back on to save us from constant tedious repetitive thinking I guess it's in their nature to be hard to monitor. One thing I find helpful is lateral thinking puzzles, since they by design challenge your assumptions.
Lesson: Courage to question is an important skill
Instead of just going with my idea of putting the blocks through the holes in the lid my kid continued to try to remove the lid. That might not always be the best solution, but at the same time I guess you can excuse a one year old for not starting a sophisticated discussion about our different views on the shape sorter. Anyway, the skill to question someone else's assumptions (and therefore uncovering what might be interpreted as facts rather than assumptions) is an important skill to anyone, one that might get you into trouble in the wrong environment but make you a hero in the right one. If you're in an environment where questioning isn't appreciated you might need to question what you're doing there by the way...
Lesson: Being too helpful is not helpful
I had my best intentions when I corrected my kid and in this particular case it might be useful for him to listen. However helping people too much can lead to less thinking, making them scared to go with their own idea or even stop evolution (as in how solutions to problems can evolve over time). Let people think, let people think and before correcting them, ask why they've gone a certain route, maybe we're more right than you?
Lesson: You need to spot assumptions
Finding assumptions require constant observation. At work I recently uncovered that you could actually simulate a certain type of hardware in our system simply by not just accepting "it doesn't work". Once again, of course you can't spend all your life with trying to question every little aspect of every little statement but to challenge common propositions you've not seen/heard any proof of is, to me, a very healthy behavior.
Lesson: Questions is a tool
Well, I've already touched upon this several times but I think it's important enough to highlight again. Questions are an essential tool that you need to use to clear any uncertainty or ambiguity in whatever someone tries to communicate. "Are you sure that..." is often a good start or, if you really want to be considered a genius pain in the butt, go for "why", "why doesn't it work". Never accept something that seems unclear just because you're too afraid to question or afraid that you'll look stupid (hmm, really nice that I write this as a exhortation to you when I'm one of those who really need to work on this).
The most important lesson...?
"You can learn an awful lot from a one year old"? Well, to put it in a more general context: "You can learn an awful lot by just reflecting on an everyday event". I could have come away with tons of lessons like this from reflecting about virtually anything, how I act when I'm cooking, how me and my girlfriend share work at home, how a colleague react to my bug report etc. You could argue some of this is just associations from associations (not immediately related to the example I reflected from) but I guess that pretty much sums up what thinking is (going from one interesting idea to another). You could also argue that a lot of this is just common knowledge and well, it is, just like it's common knowledge not to eat crappy food, don't make up apologies and go to bed in time, sometimes we need reminders, at least I do.
One final question: What else could you learn from this? Well I didn't even start on the psychosocial aspects, parenting in general, I had a lot more interesting associations to school that I didn't bring up, you could question the toy or how it could be redesigned to better set the rules or challenge the user's creativity... well I guess I need to stop otherwise I won't be able to sleep tonight but there you have some more aspects in case you want to continue .)
So to sum it up: Reflect! It's not just a valuable skill to practice, it can also lead to very interesting results.
30 June 2012
EAST pub evening
Knowing that I sometimes rush into things and generally can become a bit over-engaged (worst case ruining the balance in a previously well working group), I was quite anxious after suggesting a pub evening for EAST just a month after finding the group/network. Luckily it turned out just fine with, once again, lots of ideas and inspiration to bring home.
Anyway, the evening started at six o'clock and ended (at least for me) four hours later. All and all we were 8 or 9 people and topics ranged from molecular gastronomy and parenthood to a wide range of software testing related subjects. Also quite a few comments were made regarding the different choices in beer (or in the single case of not choosing beer). As usual (always?) the majority of the participants were from Secra.
I intend to dig down a bit into some of the subjects we talked about when writing these summaries but I really need to get a notebook and make sure to bring it cause for some reason I don't remember too much about the specifics from yesterday (only two beers so shouldn't be that... I hope). I'm pretty sure though I'll go "ohh, yes, now I remember" the day I really need to.
Anyway, after the initial "who are you, where do you work, what do you do" questions, I and a former Ericsson colleague talked a bit about the problems we faced testing a humongous product, with huge simulators, stone age code base and no clear end user. We compared it a little bit with testing other products and also touched upon the automated testing subject both in this particular product as well as in the other companies represented. Don't have many conclusions from this but it was interesting laying out many of the problems.
Another subject we talked about was scrum and mainly the scrum master role. In one company the role were rotated and kept very light weight compared to a very team leader like role in another (with a third in between). We discussed the benefits and problems with rotating and, at least my, conclusion was that as soon as the scrum master role stops being very light weight it's hard to rotate and when the risk of making it a heavy weight team leader role is imminent. You could also turn it the other way around saying as long as the role is rotated the risk of making if heavy weight is less likely. We also talked about a company where scrum master was a full time job and one scrum master could be responsible for one to three teams depending on skill. The idea was interesting as in weird and something I hope never will happen at my own work. Finally we talked about the different approaches to being scrum master where some (not necessarily the participants) considered it a prestige role while others considered it an interruption in the daily work and also how it differed being scrum master as a consultant compared to an employee at the company.
To wrap up the subjects, we talked quite a lot about the responsibility for test, the interesting path of learning programming and testing quite simultaneous so you're neither a top grade programmer nor a top grade tester but a top grade "something in between", we talked about the danger when all responsibility for testing is put on testers (especially in programmer heavy organizations), we talked about how cognitive science is a valuable skill to all testers and how students in cognitive science with computer skills were highly sought after as software testers, especially by consultant firms. Well we talked about tons of other stuff (respect for test, lack of testing skill for newly graduated students, problems with experienced testers with very little testing knowledge etc. etc. etc. etc. etc.) but let's stop here for now.
Finally Bishop's Arms were a great place; quiet, spacious and great selection of beer. Credit to Johan Jonasson for suggesting Bishop's and to Frida Brantvall for discarding Johan's other suggestion. May be relevant to add that the level of noise apparently were a lot lower than usual thanks to the great weather (most people were sitting outside).
Anyway, the evening started at six o'clock and ended (at least for me) four hours later. All and all we were 8 or 9 people and topics ranged from molecular gastronomy and parenthood to a wide range of software testing related subjects. Also quite a few comments were made regarding the different choices in beer (or in the single case of not choosing beer). As usual (always?) the majority of the participants were from Secra.
I intend to dig down a bit into some of the subjects we talked about when writing these summaries but I really need to get a notebook and make sure to bring it cause for some reason I don't remember too much about the specifics from yesterday (only two beers so shouldn't be that... I hope). I'm pretty sure though I'll go "ohh, yes, now I remember" the day I really need to.
Anyway, after the initial "who are you, where do you work, what do you do" questions, I and a former Ericsson colleague talked a bit about the problems we faced testing a humongous product, with huge simulators, stone age code base and no clear end user. We compared it a little bit with testing other products and also touched upon the automated testing subject both in this particular product as well as in the other companies represented. Don't have many conclusions from this but it was interesting laying out many of the problems.
Another subject we talked about was scrum and mainly the scrum master role. In one company the role were rotated and kept very light weight compared to a very team leader like role in another (with a third in between). We discussed the benefits and problems with rotating and, at least my, conclusion was that as soon as the scrum master role stops being very light weight it's hard to rotate and when the risk of making it a heavy weight team leader role is imminent. You could also turn it the other way around saying as long as the role is rotated the risk of making if heavy weight is less likely. We also talked about a company where scrum master was a full time job and one scrum master could be responsible for one to three teams depending on skill. The idea was interesting as in weird and something I hope never will happen at my own work. Finally we talked about the different approaches to being scrum master where some (not necessarily the participants) considered it a prestige role while others considered it an interruption in the daily work and also how it differed being scrum master as a consultant compared to an employee at the company.
To wrap up the subjects, we talked quite a lot about the responsibility for test, the interesting path of learning programming and testing quite simultaneous so you're neither a top grade programmer nor a top grade tester but a top grade "something in between", we talked about the danger when all responsibility for testing is put on testers (especially in programmer heavy organizations), we talked about how cognitive science is a valuable skill to all testers and how students in cognitive science with computer skills were highly sought after as software testers, especially by consultant firms. Well we talked about tons of other stuff (respect for test, lack of testing skill for newly graduated students, problems with experienced testers with very little testing knowledge etc. etc. etc. etc. etc.) but let's stop here for now.
Finally Bishop's Arms were a great place; quiet, spacious and great selection of beer. Credit to Johan Jonasson for suggesting Bishop's and to Frida Brantvall for discarding Johan's other suggestion. May be relevant to add that the level of noise apparently were a lot lower than usual thanks to the great weather (most people were sitting outside).
24 June 2012
Sabayon 9 review
Background
I used Sabayon for the first time when version 5.4 (or 5.5 can't really remember which) was released. The intention back then was just to try it alongside my beloved openSuse. I soon after the installation realized I never booted up openSuse anymore and when I had to choose one of them to replace, Sabayon became my main dist.
The things that really hit me back then was the beauty, the smoothness and the amazing out of the box experience. Later I found Crunchbang, fell in love again and soon replaced Sabayon. The main reasons for that was sheer speed, Openbox (or rather the Openbox implementation in Crunchbang), Debian as base, or more precisely: I finally got tired of Sulfur (graphical front-end to the package manager in Sabayon).
Still, no Linux dist has ever "wow:ed" me as much, out of the box, as Sabayon 5 so it was with great expectations I decided to try the latest release, version 9, especially since I'd heard many positive comments about Rigo, the replacement for Sulfur.
One final note, I decided to go with the Xfce edition this time to get some lightweight options for common tools and to save me from the heavy dependencies in Gnome and KDE. Of course this changes the experience in some cases.
Installation
I decided to give the graphical installer a shot this time. The installer turned out to be fairly standard (Anaconda so maybe I shouldn't had expected anything else), it's stable, quite straight forward, asks the common questions and doesn't really excite you in any way.
I have one thing I certainly dislike though: The first question you get is "what kind of storage do you want to install Sabayon to", soon after you get a question about "install system or only boot loader" after that you have to setup all you passwords, user name, host name etc. before, finally, you get to setup your exact hard drive config. I swear, every time I pressed next before that I just begged that it wouldn't say "Starting to install", meaning I would have wiped both my store partition and my current Crunchbang installation. To me, saving time (and my nerves) by setting up user info during the actual installation would have been a better choice... or at least put hard drive setup immediately after the "system or only boot loader" option.
To end with something positive, the installer after all did its job. The actual file copying felt quick for the size of the system and I liked some of the comments in the presentation shown during the file copying, especially "Debian Stable? Pfft! OLD!", also nice to be able to setup root user's pass.
Summary: Nothing new or fancy (which I actually hoped for a bit) but smooth and solid.
First impression
Boot up and general artwork just didn't feel as beautiful and exciting as it did in version 5, maybe I'm just harder to impress these days but to me it may be slicker but not as impressive. Apart from that all the positive things I loved in version 5 remained or was improved. It's really quick to boot, my notoriously problematic Wireless was handled perfectly as well as graphic card, web cam, sound and all other hardware. When it came to media mp3, mpeg4, flash, wmv etc. worked out of the box, heck it even handled the weird avi codec some of our old LAN movies use (which, in case unclear, most distros don't).
To end all the positive critique it ran smooth, really smooth, especially considering some of the enabled effects.
I only found a couple of problems. The major one was that LibreOffice crashed upon document loading (known bug, apparently present in Sabayon 8 as well) and the other was Midori crashed quite frequently. The two bugs were easy to get around but it still lowers the initial impression.
Summary: With my personal preference in artwork I don't think it beats my old favorite Sabayon 5 but it's close! The only really problem I found was the two bugs I mentioned.
Rigo
One of the big changes in version 9 addressed one of my own concerns my first time around; the GUI for Entropy. The buggy, slow and annoying Sulfur was now changed to Rigo. Before installing I read conflicting reviews, one suggesting that Rigo was a ground breaking tool that will influence Ubuntu's, and other major distros', software center while the other suggested it was just another not mature enough front-end. After trying it myself I stand somewhere in the middle. I think there are stuff to learn from it but to me the search function is not good enough for a tool that lacks a browsing feature and it had some other quirks. However, it did a great job providing me with all essential info without cluttering the interface. It was also a lot snappier than Sulfur and finally on a comparable level as the general tools. Plus for different/innovative design and the general feeling, thumbs down for its lacking maturity and small quirks but then again, this is the first release for Rigo so expect a lot of improvements going forward!
Summary: All and all, it's seems I won't ditch Sabayon for the lack of a decent package manager graphical front-end this time.
Who is Sabayon for?
Sabayon is easy, maybe not Linux Mint easy, but I guess at least openSuse easy. Media is there, hardware supports seems good and the only reason I find it a little less "beginner friendly" is that it's still a bit rough around the edges and I don't think you will survive without open the terminal every now and when. Also, in opposite to the major distros, like Ubuntu and Fedora, the community is a lot smaller making it a little harder to quickly find solutions to your problems.
One thing I have to point out (and I expect this to be true to at least the Gnome version as well) is that it's smoother than for instance Mint. I would say anyone looking for a drama free distro that is actually decent in speed should take a serious look at Sabayon. Personally this one will stay and we'll see if it overtakes Crunchbang or not this time, at the moment I have not used it enough to really tell, but looks promising.
Summary
Really solid distro! Just like the first time around I have this crazy feeling of "this is exactly what I want", only time can tell if that changes. I really recommend you give it a try if you want something really easy but still powerful. Sabayon 9 is definitely not going to disappoint you!
I used Sabayon for the first time when version 5.4 (or 5.5 can't really remember which) was released. The intention back then was just to try it alongside my beloved openSuse. I soon after the installation realized I never booted up openSuse anymore and when I had to choose one of them to replace, Sabayon became my main dist.
The things that really hit me back then was the beauty, the smoothness and the amazing out of the box experience. Later I found Crunchbang, fell in love again and soon replaced Sabayon. The main reasons for that was sheer speed, Openbox (or rather the Openbox implementation in Crunchbang), Debian as base, or more precisely: I finally got tired of Sulfur (graphical front-end to the package manager in Sabayon).
Still, no Linux dist has ever "wow:ed" me as much, out of the box, as Sabayon 5 so it was with great expectations I decided to try the latest release, version 9, especially since I'd heard many positive comments about Rigo, the replacement for Sulfur.
One final note, I decided to go with the Xfce edition this time to get some lightweight options for common tools and to save me from the heavy dependencies in Gnome and KDE. Of course this changes the experience in some cases.
Installation
I decided to give the graphical installer a shot this time. The installer turned out to be fairly standard (Anaconda so maybe I shouldn't had expected anything else), it's stable, quite straight forward, asks the common questions and doesn't really excite you in any way.
I have one thing I certainly dislike though: The first question you get is "what kind of storage do you want to install Sabayon to", soon after you get a question about "install system or only boot loader" after that you have to setup all you passwords, user name, host name etc. before, finally, you get to setup your exact hard drive config. I swear, every time I pressed next before that I just begged that it wouldn't say "Starting to install", meaning I would have wiped both my store partition and my current Crunchbang installation. To me, saving time (and my nerves) by setting up user info during the actual installation would have been a better choice... or at least put hard drive setup immediately after the "system or only boot loader" option.
To end with something positive, the installer after all did its job. The actual file copying felt quick for the size of the system and I liked some of the comments in the presentation shown during the file copying, especially "Debian Stable? Pfft! OLD!", also nice to be able to setup root user's pass.
Summary: Nothing new or fancy (which I actually hoped for a bit) but smooth and solid.
First impression
Boot up and general artwork just didn't feel as beautiful and exciting as it did in version 5, maybe I'm just harder to impress these days but to me it may be slicker but not as impressive. Apart from that all the positive things I loved in version 5 remained or was improved. It's really quick to boot, my notoriously problematic Wireless was handled perfectly as well as graphic card, web cam, sound and all other hardware. When it came to media mp3, mpeg4, flash, wmv etc. worked out of the box, heck it even handled the weird avi codec some of our old LAN movies use (which, in case unclear, most distros don't).
To end all the positive critique it ran smooth, really smooth, especially considering some of the enabled effects.
I only found a couple of problems. The major one was that LibreOffice crashed upon document loading (known bug, apparently present in Sabayon 8 as well) and the other was Midori crashed quite frequently. The two bugs were easy to get around but it still lowers the initial impression.
Summary: With my personal preference in artwork I don't think it beats my old favorite Sabayon 5 but it's close! The only really problem I found was the two bugs I mentioned.
Rigo
One of the big changes in version 9 addressed one of my own concerns my first time around; the GUI for Entropy. The buggy, slow and annoying Sulfur was now changed to Rigo. Before installing I read conflicting reviews, one suggesting that Rigo was a ground breaking tool that will influence Ubuntu's, and other major distros', software center while the other suggested it was just another not mature enough front-end. After trying it myself I stand somewhere in the middle. I think there are stuff to learn from it but to me the search function is not good enough for a tool that lacks a browsing feature and it had some other quirks. However, it did a great job providing me with all essential info without cluttering the interface. It was also a lot snappier than Sulfur and finally on a comparable level as the general tools. Plus for different/innovative design and the general feeling, thumbs down for its lacking maturity and small quirks but then again, this is the first release for Rigo so expect a lot of improvements going forward!
Summary: All and all, it's seems I won't ditch Sabayon for the lack of a decent package manager graphical front-end this time.
Who is Sabayon for?
Sabayon is easy, maybe not Linux Mint easy, but I guess at least openSuse easy. Media is there, hardware supports seems good and the only reason I find it a little less "beginner friendly" is that it's still a bit rough around the edges and I don't think you will survive without open the terminal every now and when. Also, in opposite to the major distros, like Ubuntu and Fedora, the community is a lot smaller making it a little harder to quickly find solutions to your problems.
One thing I have to point out (and I expect this to be true to at least the Gnome version as well) is that it's smoother than for instance Mint. I would say anyone looking for a drama free distro that is actually decent in speed should take a serious look at Sabayon. Personally this one will stay and we'll see if it overtakes Crunchbang or not this time, at the moment I have not used it enough to really tell, but looks promising.
Summary
Really solid distro! Just like the first time around I have this crazy feeling of "this is exactly what I want", only time can tell if that changes. I really recommend you give it a try if you want something really easy but still powerful. Sabayon 9 is definitely not going to disappoint you!
19 June 2012
Skill development list - explanation
LINK TO THE SKILL DEVELOPMENT LIST
After reading this inspiring blog post (about an, probably even more, inspiring keynote by Tobbe Ryber) and long been fascinated by the 101 goals in 1001 days concept, I got the idea of listing the things I want to do to become a more proficient software tester.
You can find the current result in the page listing (skill development list). The idea is to continuously improve the list so any comments on the items are very appreciated. Also, in case you've done something similar, I would really love if you send me a link in the comments section.
Anyway, the list is (currently) divided into 6 sections. Knowledge lists things that would help me improve general knowledge about software testing (theory). I've not listed common stuff I more or less do daily in this section, like "watch presentations" or "read testing articles".
Since I have a long history of "reading stuff that I've then not put into practice" I've added a Practice section. The idea is maily to remind me that learning stuff is fun but the real value is often in actually doing them.
Something I've started to value a lot recently is Social Networking. I found a lot of inspiration in the discussions during my first EAST meetup and I'm looking forward to continue meeting up with other people interested in software testing, especially people not working for the same company as I am.
As a former public speaker and recurring educational writer I've realized teaching is one of the best ways, at least for me personally, to really make things stick. I also hope I can give something back to a testing community that has already helped me a lot. So the section Spread Knowledge is about stuff I can do to others that also helps me excel.
Finally there's the sections Other (simply stuff that doesn't fit any of the other sections) and Continuous/Ambiguous which is stuff that, in one way or another, is hard to really set checkpoints for. Details about these areas will instead end up as individual blog posts.
So what's the purpose with this list? To keep me focused! To make sure I don't end up in the situation I once was where testing didn't feel interesting and exciting. I guess I'll have to evaluate the usefulness in 1001 days.
... regarding 1001 days, before someone corrects me, this list does not contain 101 items, there's no time limit and some of the items are ambiguous thus making this far from a 101 items in 1001 days kind of thing, it's only inspired by it.
After reading this inspiring blog post (about an, probably even more, inspiring keynote by Tobbe Ryber) and long been fascinated by the 101 goals in 1001 days concept, I got the idea of listing the things I want to do to become a more proficient software tester.
You can find the current result in the page listing (skill development list). The idea is to continuously improve the list so any comments on the items are very appreciated. Also, in case you've done something similar, I would really love if you send me a link in the comments section.
Anyway, the list is (currently) divided into 6 sections. Knowledge lists things that would help me improve general knowledge about software testing (theory). I've not listed common stuff I more or less do daily in this section, like "watch presentations" or "read testing articles".
Since I have a long history of "reading stuff that I've then not put into practice" I've added a Practice section. The idea is maily to remind me that learning stuff is fun but the real value is often in actually doing them.
Something I've started to value a lot recently is Social Networking. I found a lot of inspiration in the discussions during my first EAST meetup and I'm looking forward to continue meeting up with other people interested in software testing, especially people not working for the same company as I am.
As a former public speaker and recurring educational writer I've realized teaching is one of the best ways, at least for me personally, to really make things stick. I also hope I can give something back to a testing community that has already helped me a lot. So the section Spread Knowledge is about stuff I can do to others that also helps me excel.
Finally there's the sections Other (simply stuff that doesn't fit any of the other sections) and Continuous/Ambiguous which is stuff that, in one way or another, is hard to really set checkpoints for. Details about these areas will instead end up as individual blog posts.
So what's the purpose with this list? To keep me focused! To make sure I don't end up in the situation I once was where testing didn't feel interesting and exciting. I guess I'll have to evaluate the usefulness in 1001 days.
... regarding 1001 days, before someone corrects me, this list does not contain 101 items, there's no time limit and some of the items are ambiguous thus making this far from a 101 items in 1001 days kind of thing, it's only inspired by it.
06 June 2012
Resume: Details, Profile and Person
Resume and CV
I tried to figure out if CV or resume was the correct word to use for the document I will talk about. My five minute google research pointed towards resume but it didn't seem to be any general agreement on this. Anyway, when I talk about resume in this post I refer to a 1-2 pages long personal summary you generally send to a potential employer.
Details, Profile, Person?
First things first. What does these words mean?
Details - All your content viewed from a general perspective (without context): "what is generally considered most important", "what order would be logical to sort this information in" etc.
Profile - The collective picture you want the reader to get, for example: "A self-reliant nurse who takes responsibility in creating a good working environment".
Person - The picture the reader actually gets of you when reading your resume. This of course varies from reader to reader, for instance, a person trying to communicate the profile described above might by one person be interpreted as "A competent nurse I can put my trust in" while someone else might think "Naive, inexperienced person who oversimplifies this job".
So why is this important? My hypothesis is most of us think almost exclusively from a Details perspective, simply because it's the easiest. Easiest since everything can be handled isolated with no regard to how it fits with everything else (when sorting work experience you can for instance ignore you personality or language skills). This also means you can set up general rules that are easy to follow and that's exactly what I think too many resume guides do.
Still, why is this a problem? Well, Details are easy to handle as a writer but complex as a reader. Complex since the reader wants to find "the essence" and he/she will simplify, generalize, try to find patterns etc. to get a collective picture of who you are (Person). If you haven't thought about this collective picture (Profile) there is a great risk you either communicate the wrong picture (which will be to your disadvantage in an interview) or make it hard for the reader to get any collective picture (risk of being excluded).
Profile
So how to avoid this? First of all think about the collective picture you want to communicate (Profile). I personally do this by writing down the most important items from my experiences (job experience, education, positions of trust), personality, skills and interests. When done I try to find a common theme, some "one liner" that pretty much covers the items you have in front of you:
When you have some kind of profile defined (notice it's still up for change) it's time to read your resume. Try to find things that just don't fit into your profile and either remove them or tone them down (... or reevaluate your profile). Also try to find things you should highlight more and think of gaps compared to your profile. Add stuff or update your profile accordingly. If it doesn't feel like your resume communicates the profile at all you need to make major adjustments to your resume, profile or both.
Notice! Your profile is a lot more than just the "data"/content! Language, design, content order, font/font size, picture (in case you have one), title, length etc. all adds to what your resume communicates. For instance, using a basic template does not communicate creative, misspellings or grammar errors does not communicate careful/professional and not being open about your weaknesses does not communicate self confident. Apart from these extreme examples everything add to how you are perceived.
Person
When you feel your resume is good enough, from a profile point of view, try reading it as if you were someone else (or even better, let other people read it, preferably people with different experiences). Try thinking about how someone else would interpret what you are writing. I find this to be easier if I try to imagine that the resume is not mine but rather someone else, even better, someone I despise :) If you at this point feel that "I don't really sound serious" or "I sound really insecure" you probably have a problem you need to address. Same thing if the resume feels really "stiff" or "impersonal" (which I think is really common). If it isn't really part of your profile, try to loosen up. This might be achieved by changing really formal words or, sometimes, reverting back to an older copy (my experience is that we generally tend to make texts more and more formal/impersonal for every update we do).
Finally try to think about prejudices. This could mean very different things depending on where you're from but to provide you with some examples (which might not apply to you): immigrant = language issues, good looking = stupid, young = inexperienced or naive, old = hard to adjust, high grades = low social skills etc. If you can, try to address these and, when true, disprove them. Notice that prejudices might also work to your advantage like immigrant = knows a second language and culture, young = eager to learn or can find a new perspective etc. The good thing with this is that very little can communicate very much. For instance, being Brazilian, applying for a job in the Europe, just adding anything related to Brazil may indirectly make the employer presume you know Portuguese really well and understand the Brazilian culture (as well as being a kick ass soccer player ;)
Keep reading and keep improving your resume as you develop, but like I said before, beware of becoming too formal as you review and update your resume, common mistake in my experience.
Summary
I tried to figure out if CV or resume was the correct word to use for the document I will talk about. My five minute google research pointed towards resume but it didn't seem to be any general agreement on this. Anyway, when I talk about resume in this post I refer to a 1-2 pages long personal summary you generally send to a potential employer.
Details, Profile, Person?
First things first. What does these words mean?
Details - All your content viewed from a general perspective (without context): "what is generally considered most important", "what order would be logical to sort this information in" etc.
Profile - The collective picture you want the reader to get, for example: "A self-reliant nurse who takes responsibility in creating a good working environment".
Person - The picture the reader actually gets of you when reading your resume. This of course varies from reader to reader, for instance, a person trying to communicate the profile described above might by one person be interpreted as "A competent nurse I can put my trust in" while someone else might think "Naive, inexperienced person who oversimplifies this job".
So why is this important? My hypothesis is most of us think almost exclusively from a Details perspective, simply because it's the easiest. Easiest since everything can be handled isolated with no regard to how it fits with everything else (when sorting work experience you can for instance ignore you personality or language skills). This also means you can set up general rules that are easy to follow and that's exactly what I think too many resume guides do.
Still, why is this a problem? Well, Details are easy to handle as a writer but complex as a reader. Complex since the reader wants to find "the essence" and he/she will simplify, generalize, try to find patterns etc. to get a collective picture of who you are (Person). If you haven't thought about this collective picture (Profile) there is a great risk you either communicate the wrong picture (which will be to your disadvantage in an interview) or make it hard for the reader to get any collective picture (risk of being excluded).
Profile
So how to avoid this? First of all think about the collective picture you want to communicate (Profile). I personally do this by writing down the most important items from my experiences (job experience, education, positions of trust), personality, skills and interests. When done I try to find a common theme, some "one liner" that pretty much covers the items you have in front of you:
- Serious critically thinking engineer with high level computer skills!
- I live, breath and think architecture, simply put, an awesome passionate architect!
- I'm a creative innovator who makes others perform better!
- I'm an experienced easy going electrician who gets things done!
When you have some kind of profile defined (notice it's still up for change) it's time to read your resume. Try to find things that just don't fit into your profile and either remove them or tone them down (... or reevaluate your profile). Also try to find things you should highlight more and think of gaps compared to your profile. Add stuff or update your profile accordingly. If it doesn't feel like your resume communicates the profile at all you need to make major adjustments to your resume, profile or both.
Notice! Your profile is a lot more than just the "data"/content! Language, design, content order, font/font size, picture (in case you have one), title, length etc. all adds to what your resume communicates. For instance, using a basic template does not communicate creative, misspellings or grammar errors does not communicate careful/professional and not being open about your weaknesses does not communicate self confident. Apart from these extreme examples everything add to how you are perceived.
Person
When you feel your resume is good enough, from a profile point of view, try reading it as if you were someone else (or even better, let other people read it, preferably people with different experiences). Try thinking about how someone else would interpret what you are writing. I find this to be easier if I try to imagine that the resume is not mine but rather someone else, even better, someone I despise :) If you at this point feel that "I don't really sound serious" or "I sound really insecure" you probably have a problem you need to address. Same thing if the resume feels really "stiff" or "impersonal" (which I think is really common). If it isn't really part of your profile, try to loosen up. This might be achieved by changing really formal words or, sometimes, reverting back to an older copy (my experience is that we generally tend to make texts more and more formal/impersonal for every update we do).
Finally try to think about prejudices. This could mean very different things depending on where you're from but to provide you with some examples (which might not apply to you): immigrant = language issues, good looking = stupid, young = inexperienced or naive, old = hard to adjust, high grades = low social skills etc. If you can, try to address these and, when true, disprove them. Notice that prejudices might also work to your advantage like immigrant = knows a second language and culture, young = eager to learn or can find a new perspective etc. The good thing with this is that very little can communicate very much. For instance, being Brazilian, applying for a job in the Europe, just adding anything related to Brazil may indirectly make the employer presume you know Portuguese really well and understand the Brazilian culture (as well as being a kick ass soccer player ;)
Keep reading and keep improving your resume as you develop, but like I said before, beware of becoming too formal as you review and update your resume, common mistake in my experience.
Summary
- The reader will generalize to be able to understand what you are communicating, make sure you take this into account.
- Choose your content and way of presenting this in a way that communicates a profile.
- Try reviewing your resume from the perspective of a potential employer, take prejudices into account.
- If you feel your resume sounds insecure, unserious or stiff, there's a great risk an employer will feel the same.
05 June 2012
My first EAST meetup
Yesterday I attended my first EAST meetup here in Linköping, Sweden. I met some amazing people and left with loads of inspiration.
But first things first: What is EAST?
EAST is an open network for software testers in the Linköping area, focused on Context Driven Testing. The group's main forum is a LinkedIn group but they also have a Twitter account in case only knowing about the actual events is enough. Apart from the online presence the group arranges meetups roughly once a month with about 15-20 participants. The group consists of well known testers like Johan Jonasson and Johan Åtting as well as newly graduates.
Anyway, this post was about my own experiences so here we go. As soon as I entered I was warmly welcomed and discussions regarding what I and others did started. When everyone finally had arrived we ate together (ordered pizza, not more glamorous than that) and the discussions continued with subjects like values in testing, skills/education and how to spread the knowledge of what we do.
After the food Hanna Germundsson presented her master thesis (or rather results so far) on testing in an agile environment, with a long interesting discussion as the result. Both the presentation and discussion gave me lots of valuable insights and thoughts on subjects like how to educate testers, if it's possible to measure test progress in a useful way and if it's possible to estimate required test time/effort. I also signed up to participate in an open discussion Hanna would arrange to use for her master thesis, something I'm really looking forward to.
Finally the participants who attended Let's Test 2012 talked a bit about their experiences, memories and learned lessons from the conference. If I weren't enticed enough to attend Let's Test 2013 I definitely am now. Just keeping my fingers crossed that the education budget will allow it (not looking too promising, especially not if I, as I've already requested, get to attend RST with James Bach i November, but I'm sure it's possible to solve). Morgan also provided us with a great two minute summary of Rob Sabourin's Just in time testning presentation on Let's Test.
To summarize; this was a great evening and today I felt really inspired when I left for work. I will definitely attend the next meetup if it doesn't conflict with something really important (with no more kids on the way I doubt that will happen). Hopefully I'll be able to bring a couple of curious colleagues with me as well.
But first things first: What is EAST?
EAST is an open network for software testers in the Linköping area, focused on Context Driven Testing. The group's main forum is a LinkedIn group but they also have a Twitter account in case only knowing about the actual events is enough. Apart from the online presence the group arranges meetups roughly once a month with about 15-20 participants. The group consists of well known testers like Johan Jonasson and Johan Åtting as well as newly graduates.
Anyway, this post was about my own experiences so here we go. As soon as I entered I was warmly welcomed and discussions regarding what I and others did started. When everyone finally had arrived we ate together (ordered pizza, not more glamorous than that) and the discussions continued with subjects like values in testing, skills/education and how to spread the knowledge of what we do.
After the food Hanna Germundsson presented her master thesis (or rather results so far) on testing in an agile environment, with a long interesting discussion as the result. Both the presentation and discussion gave me lots of valuable insights and thoughts on subjects like how to educate testers, if it's possible to measure test progress in a useful way and if it's possible to estimate required test time/effort. I also signed up to participate in an open discussion Hanna would arrange to use for her master thesis, something I'm really looking forward to.
Finally the participants who attended Let's Test 2012 talked a bit about their experiences, memories and learned lessons from the conference. If I weren't enticed enough to attend Let's Test 2013 I definitely am now. Just keeping my fingers crossed that the education budget will allow it (not looking too promising, especially not if I, as I've already requested, get to attend RST with James Bach i November, but I'm sure it's possible to solve). Morgan also provided us with a great two minute summary of Rob Sabourin's Just in time testning presentation on Let's Test.
To summarize; this was a great evening and today I felt really inspired when I left for work. I will definitely attend the next meetup if it doesn't conflict with something really important (with no more kids on the way I doubt that will happen). Hopefully I'll be able to bring a couple of curious colleagues with me as well.
Subscribe to:
Posts (Atom)