For dinner I decided on a bacon burger, always a delicious choice. But for extra deliciousness I slapped on an extra meat patty, cheese and some fried red onions.
Once again, bacon frying
Frying the red onions
Meat! Gooood!
The finished bacon burger in all its glory
The bacon feast continues. For lunch I made a nice chicken salad with cherry tomatoes, cucumber, corn, maché salad, grilled chicken, mushrooms and, of course, bacon.
Lovely bacon frying
The salad before adding the bacon
Bacon added
Nom nom nom
Praise the divine bacon! See y’all back for dinner!
To celebrate that’s it’s Bacon Day today I’ve decided to include bacon in all of my meals of the day. First out: breakfast!
For breakfast my girlfriend requested pancakes, so pancakes it is but I decided to stuff mine with cheese, arugula and bacon.
Check out the pictures!
Making the pancakes
The delicious bacon
Soon the feast will be ready...
Bacon stuffed pancakes, ready to eat!
Eating the pancakes
And yes, it was absolutely delicious! See you in a couple of hours for lunch. With bacon!
Don’t say I didn’t warn you… 
To anyone who actually gives a hoot, that’s my HTC Hero receiving the officially sanctioned Eclair-update from HTC (rather than the hacked HTC Legend Eclair ROM I’ve been running the past couple of months).
The past couple of weeks I’ve been playing with mobile apps development, both for Android and for iOS (meaning iPhone and iPad in layman’s terms). Being an open source kinda guy and very familiar with Java I immediately felt very comfortable with the Android SDK and the platform as a whole. It really is a great platform and very viable for creating great apps and experiences for mobile devices. However, there are a couple of key issues that I believe need to be fixed in order to push Android to the next level.
First and foremost, paid apps are still not available everywhere. Only users in a few select countries can download apps from Android Market that cost money and, even worse, developers in even fewer countries can publish non-free apps for people to buy. As a mere users there are ways around this but if you’re - like me - a Swedish developer there’s no way to get paid for your efforts. This is a really big deal since developers outside of the nine supported merchant countries also need to eat and pay the bills or whatever it is you use money for. Sure, one might claim that true hardcore developers will develop awesome apps anyway and give them away on Android Market because digital creativity is in our nature and this is true to some extent. But at the end of the day money is one of the best incentives out there and the fact that many potential Android developers can’t charge for their apps is most surely causing a lot of app-awesomeness from happening and keeping the platform from experiencing the kind of “gold-rush” that iOS is having. It may even be driving some developers to the iOS-platform instead since they might reckon that if they can’t paid why should they bother with the platform anyway?
I don’t see what the frackin’ hold-up is here really. So Google, get off your asses and make this happen sooner than later. Market needs to have paid apps and developers getting paid everywhere, OK?
Another thing that is painfully obvious when you look at the variety of Android devices out there is that the hardware companies that sell them, companies like HTC, SonyEricsson and Samsung, care only about selling new devices. They have very little interest in delivering software updates for devices that customers have already bought. I mean, it took HTC a full year to push out an OS-upgrade for the HTC Hero and SonyEricsson is at this moment selling Android 1.6 devices with the plan to update them to 2.1 around New Year. Meanwhile, FroYo (Android 2.2) devices are starting to hit the market and the specs for 3.0 are already out there.
I fully understand that it may not be easy for these companies that are primarily manufacturers of hardware to wrap their business models and brains around the fact that these days, with mobile phones becoming more and more like “real” computers, software matters more than hardware. A mobile phone will become obsolete a lot faster due to an old OS than due to year-old hardware. So something needs to be done about this. HTC and others need to take care of their customers and push out the updates a lot quicker because not everybody wants to (or can) buy a new $500 mobile phone every three months just to get the latest software. Maybe Google should set up some sort of centralized repository that the makers of Android phones could use to make sure they’re all in sync with each other and with what’s new? I don’t know, but something should be done to keep the platform from fragmenting any further.
And finally one other thing that I think can be a real game-changer is Flash-support. Yes, there is Flash-support in FroYo, I haven’t experienced it first-hand myself though so I don’t know how well it works. But my point here is that since Apple is taking a serious stand against Flash on devices running iOS there is a chance for Android (and Adobe naturally) to shine here. Make Flash work flawlessly on all contemporary Android devices and you will have a feature on the platform that the main competition can’t and will not match, which naturally is a great advantage.
These are the major points that bother me at the moment and I believe them all to be more or less critical for the growth of Android. I want to underline here though that although there are flaws - every platform has them - I believe a great deal in Android and will continue to submerge myself in the platform with great joy.
So Google and everybody else involved, time to step it up a notch OK? I’ll be watching you
No one that follows tech-news can possibly have missed that Apple have whipped up a shitstorm of sorts with it’s changes in Section 3.3.1 of the iPhone Developer Program License Agreement resulting in the prohibition of the use of third-party tools for developing iPhone apps. This is what Section 3.3.1 used to look like:
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.
And this is what Section 3.3.1 looks like now:
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
Clearly this is a move that Apple has made in order to even further increase their control and hold over the development done for their mobile platform and shut out any and all apps that are not developed in a manner blessed by Apple. This includes 3D-games developed with Unity3D, all apps that could be built with Flash CS5 and many more.
As a developer I take great offense to this and I consider it to be a real dick-move by Apple. Further, I believe it to be a move that clearly demonstrates that the people making the decisions have completely lost any understanding of what it is to be a software developer and how we developers think and operate.
Some people seem to believe that it’s a good thing that all iPhone OS development is being streamlined into a single set of tools all under the control of the platform-owner (i.e. Apple). Anyone believing this doesn’t get it either and is clearly not a developer themselves. Let me explain.
Developers don’t like being told exactly how to operate and what roads to travel on when on the path to solving a problem or task. There’s always multiple solutions to any given software development issue. There is no such thing as the ultimate tool-set or the IDE to end all IDEs. This is why we like having the freedom to chose what tools to use and how to use them to build software. By putting restrictions on what tools are “allowed” for iPhone OS development Apple is pulling a move with multiple bad consequences.
Firstly, it pisses developers off. Like I said, we don’t like being told how to work and think. In fact, there’s no group of creative people that enjoy that. Can you imagine if MOMA said to all artists that if you want your art displayed in our facilities you have to buy all your supplies in a specific store and hold your brush/chisel/whatever in a specific way? Same thing here. And yes, I’m saying that software development in many ways is an artform. If I want to use a third-party set of tools or some other exotic methods not previously imagined by Apple in order to create an awesome iPhone-app I should be able to do that. If the way my brain works makes this, to me, the most natural path of development, why restrict me and forbid me to do it? It’s ludicrous and any real developer will tell you the same thing.
Sure, I can get behind the idea that Apple want to set up some rules for what apps are allowed into their AppStore (even if the AppStore acceptance process is utterly broken…). Telling developers what to build is sort of OK, but telling them how to build is definitely not OK. It’s bullshit, plain and simple.
Secondly, this dick-move of Apples is ruining business for the companies/people developing these third-party tools as well. Sure, Apple has no responsibility to ensure the business of any other company but this is none the less a really bad side-effect of the changes to Section 3.3.1. People may lose their jobs and companies may possibly go out of business thanks to a really moronic and completely unnecessary change in the iPhone Developer Program License Agreement
The main target here, however a company not very likely to go out of business, is obviously Adobe and their product Flash which currently dominates when it comes to video and other multimedia content on the web. The changes to Section 3.3.1 followed swiftly after Adobe announced that the next version of Adobe Creative Suite would include tools that enabled Flash-developers to build Flash-apps that would run on the iPhone and iPad. That means that developers could use CS5 to create apps that were truly multi-platform and with very little hassle. They wouldn’t have to maintain different simultaneous versions for multiple devices, just one version that they could then deploy on iPhone OS, Android or whatever OS they wanted. One version of the app but multiple markets for it to exist in, which consequently means more business for the developers and, once again, all without having to deal with the mess of having multiple versions of the code. Now imagine how happy that would’ve made all of the world’s Flash-developers! Naturally, Apple couldn’t have that.
So that’s the third reason Section 3.3.1 bites, it causes unnecessary problems for developers that don’t want their apps to be exclusive to the iPhone OS, and what developer really wants that? Even if Apple may have the goal that 100% of the smartphones of the world are iPhones, it is never going to be a reality. Naturally software developers want a shot at pushing their apps and consequently make money in more markets than one, and, if at all possible, with minimal hassle. Clearly that’s not something that Apple wants.
What Apple wants for all the apps running on the iPhone OS is for them to be exclusive for their platform. They don’t want multi-platform development anywhere near their products and this was made even more clear by the open letter from Steve Jobs entitled “Thoughts on Flash” that was published on Apples website a couple of days ago.
In his letter The Steve lists six reasons why Apple hates Flash and wants it to die rather than run on the iPhone OS. Some of these reasons are actually somewhat valid, however most of them are complete and utter hypocritical nonsense. Let’s run through them quickly:
Reason one: Adobe Flash is 100% proprietary and Apple is a supporter of the “open web” having created WebKit and pushing HTML5, CSS, JavaScript and other open standards.
Hello pot, calling the kettle black much? This just makes me laugh. Apple is one of the most proprietary companies in the tech-industry. Their levels of secrecy and unwillingness to give away so much as an ounce of their secret sauces is legendary. Just because you’ve successfully pushed one open source project it doesn’t make you Richard M. Stallman. Get off your high horse. Flash is a well publicized standard and going by your own standards that should be good enough for you. Also, when Apple is pushing the very proprietary video standard H.264 as hard as they are (continue reading and you’ll see that they absolutely love H.264) they really shouldn’t be yapping about who is or isn’t being “open”.
Reason two: Adobe’s claim that Apple’s devices can’t deliver “the full web” since they don’t run Flash is caca because plenty of big websites have video in H.264 now and as for Flash-games there are loads of games on AppStore you can play instead.
There is some truth to this but it is still not valid in my opinion. Just because a long list of Apple-approved sites deliver video in H.264 instead of or as well as Flash it doesn’t mean every website does. It will still cause frustration when you run into that site with that video you wanna watch just have Flash - which is currently the dominant way to show video on the web. As for the games argument, it’s just laughable and shows that Steve isn’t a gamer himself. It’s like this: if I wanna play my game, I wanna play my game NOT another game. So if my game doesn’t run on the iPad it is no consolation at all that there are loads of other quality games available. I still can’t play the game that I wanted to play.
Reason three: Flash has lots of security flaws and the number one reason Macs crash.
I have no idea if the first claim is true or not so I’m not gonna argue against it. I’ve never had any of my Macs crash because of Flash but I’m not gonna argue the second claim either since I have no way to know what the truth is here. If Apple have statistics, which I assume they have, saying this, then it probably is true.
Reason four: Flash eats twice the battery life that H.264 with hardware acceleration does.
Again, whether this is true or not I don’t know but even if it is true I don’t think it’s a valid reason for shutting Flash out. Let the users themselves decide what to spend the juice of their batteries on. What’s next? Blocking games that are CPU-intense and thus eat “too much” battery. It’s just ridiculous. If customers want Flash, and they obviously do, let them have it even if it eats the batteries of their iPads and iPhones. Let people make their own choices.
Reason five: Flash was designed for PCs using mice, not for touch screens using fingers. You can’t “hover” or “rollover” on a touch screen.
This is true, but it is still an invalid reason simply because the controls of an app are up to the developer. It has nothing to do with the technology itself. Don’t you think Flash-developers targeting the iPhone would’ve thought of not to use controls that require “hovering”? Enough said.
Reason six: Apple knows from experience that all software developed using third-party tools suck and are inferior to software developed specifically for a particular device and/or operating system. Relying on third-party tools is also always a bad thing because then you’ll have to wait for the tool-developers to include new OS-features in their product and that can take a long time.
This part of Steve’s letter is so full of stupidity and claims that are in no way backed up by hard facts it’s laughable. What “experience”? Where are the statistics or surveys to prove this? Nowhere is where they are because it’s bullshit, plain and simple. It’s just a vague claim made like it’s the truth just because The Steve said so. Also, I find it amazing that Steve Jobs has taken it upon himself to save developers from using “bad tools”. I’ve said it several times already but I’ll say it one final time: Developers want freedom and choices! Let us decide for ourselves what tools we use and how we use them! We can take responsibility ourselves for our choices. We don’t need Steve Jobs to make them for us. Let us code and develop any way we want. Period.
So in closing all of this is just another scheme of Apple’s to lock people to their platforms attempting to create a sense of exclusiveness for their products in the process. The very same things they’ve in the past scolded Microsoft for. But what differs from previous ploys of theirs is that this is a tremendously nasty move that really benefits nobody, not even Apple themselves in my opinion. I think it is really sad and I don’t like the way Apple has been developing since releasing the iPhone - I think that’s where it all started to go downhill. I love Apple’s products - the hardware, OS X, iLife, all of that good stuff - but the company policies are pissing me off more often than not these days. Steve and his underlings need to step back and take a good look at themselves, the company’s past and the path their currently marching onwards on before it’s too late and Apple really becomes the new Microsoft or IBM. Nobody wants that, least of all me.
Quite a lot of acronyms there don’t ya think?
Anyway… The PS3 is fantastic. I think most people with half a brain will agree on that. It does however have it’s shortcomings and one of them is that it doesn’t play mkv-files. So whenever I stumble upon something in that format I have to perform some sort of black magic on it in order to turn it into an mp4 that the PS3 agrees with.
The easy way to go is to just flush it through HandBrake. That works but then it will be decoded and re-encoded which potentially causes quality degradation and takes foreeeeeever. So that’s not really an option I’m happy with.
However, decoding and re-encoding is actually unnecessary since what’s wrong is the container and not the contents. Luckily unpacking and repackaging the mkv as mp4 can all be done with a bunch of free and open source tools. It’s still a bit of a hassle though so today I spent a couple of hours putting together a script that makes it semi-automatic and a lot easier.
One thing that proved to be a bit more work than I expected was turning DTS 5.1 audio into AAC 5.1. What I came up with should work, but I haven’t been able to verify it since my receiver doesn’t support AAC 5.1. If yours does, please let me know if it works or not. For this reason in my personal version of the script I turn DTS 5.1 into AAC stereo instead (using the last part of the if-elif-else statement), which is OK even if it’s not quite as nice as 5.1 sound would have been.
All of the tools I used are open source software and available for most Linux-flavors (I use Fedora 12), except Nero AAC Encoder which is just free as in beer.
So that nobody else has to suffer through the process of putting a script like this together; here’s the script. It’s fairly self-explanatory and I even commented the code a bit so it shouldn’t be that hard to understand what it does and why. Enjoy!
While putting together the script I found this article very useful for deciphering the mess that is audio codecs. I would also like to give a shout-out to one of my co-workers who introduced me to several of the tools and how they work.
UPDATE:
In further experimenting I found that my original script contained a couple of bugs. I believe I’ve sorted those out now and I’ve updated the code above. I’m still not claiming this script to be bug-free so if you find anything that’s not working, please let me know.
I recently upgraded to Fedora 12 and now find that my own recipe for making Spotify run under Wine doesn’t work anymore. The fix is not that hard though.
First, download the Spotify-installer for Windows from the Spotify-website. Then you install 32-bit Wine with ALSA-support like this:
$ sudo yum -y install wine.i686 wine-alsa.i686
Then make sure you have pulseaudio-utils installed, like this:
$ sudo yum -y install pulseaudio-utils
Then when running winecfg and set wine to use ALSA-drivers you pass it through padsp (which is in the package you just installed) in order to make the sound play nice:
$ padsp winecfg
Now you run the Spotify-installer with wine passed through padsp like so:
$ padsp wine ~/Downloads/Spotify\ Installer.exe
After this you should have Spotify installed. However, when you run it with wine you still need to pass it through padsp in order for it to work, so I suggest making a little script to start Spotify with and putting it somewhere nice like /usr/bin for example. The script would look something like this:
#!/bin/bash
padsp wine “C:\Program Files\Spotify\spotify.exe”
And there you have, 64-bit Fedora 12 running Spotify.
Have you ever wanted to find a specific string in a log-file and then output what comes after that line in the file? I do this every single day at work and can’t be the only one. Somewhere in a huge log-file, XML-file or other type of text-file there’s a line that equals the beginning of some specific type of information that I’m in need of so I need to find that line of text and output a bunch of the lines following it.
I might for example have a backup cron-job that when it starts outputs “Backup started” to /var/log/messages and then follows that with output concerning how the backup went. Sure, theoretically I could open the file in vim and simply search for the line in question but sometimes text-files are frikkin’ huge and opening them up in a text-editor is just not a viable option. For example, I handle XML-files that are several gigabytes in size daily and loading one of those into an editor will mean nothing but pain and suffering I assure you
So to facilitate this procedure I slapped together this script, which I’m giving the easy-to-remember name fsagsl.sh:
#!/bin/bash
# fsagsl.sh Find String And Grab Some Lines
# 2009 (c) IDontGiveASmegWhatYouDoWithIt License
# by FighterHayabusa <fighterhayabusa@barbedwirebytecodebaconburger.com>
# Finds a string in a text-file and then outputs
# a chosen number of lines from that position onwards.
function is_int()
{
[ "$1" -eq "$1" ] > /dev/null 2>&1
return $?
}
PRG=fsagsl.sh
if [ -f $3 ] && is_int $2; then
LINESTART=`grep -n $1 $3 | sed -e 's/\([0-9]*\):.*/\1/g'`
for L in $LINESTART; do
let LINESTOP=$L+$2
sed -n "${L},${LINESTOP}p" $3
done
exit 0
else
echo "ERROR: Invalid parameters."
echo "Usage: ./$PRG string_to_find number_of_lines filename"
echo "Example: ./$PRG \"Backup started\" 5 /var/log/messages"
exit 1
fi
As you may notice the script also has some simple error-handling and handles if there are multiple instances of the string that is being looked for.
So there you go. I hope somebody finds it useful 
Me, and many with me, have reported problems with getting Spotify to run under Wine in Fedora 11. The support pages at the Spotify-website describe how to install and run it if you’re using Ubuntu, but - surprise, surprise - not every Linux-user uses Ubuntu. Well, I think I solved it and it wasn’t all that complicated either.
More and more computers are running a 64-bit OS and especially Linux-users have very widely adopted the x64-platform. However, the problem with running Spotify in Wine in Fedora 11 seem to be specific to the 64-bit version of Wine. So what I did was simply remove every trace of 64-bit Wine and installed the 32-bit version instead along with ALSA-support for Wine (I read somewhere that the Pulseaudio-drivers for Wine don’t play along with Spotify), like this:
$ sudo yum install wine.i586 wine-alsa.i586
Then I ran winecfg and selected the ALSA-driver for the audio and ran the Spotify-installer for 32-bit Windows.
$ winecfg (configure audio...) $ wine ~/Download/Spotify\ Installer.exe
That’s it! Now I’m rocking the latest Slayer-album in Spotify on my Fedora-laptop. Very nice!
