I'm not fully convinced about the Windows Phone 7 ideas, but they have some cool videos really taking on me - one called "Really?" and another called "Season of the Witch".
The cool thing about the concept is that Windows Phone is not another mobile OS immersing you in its experience. As Steve Ballmer stated: "You get in, out, and back to life." - so the videos are making fun of everyone always everywhere looking at their mobile phones. And they've got a point there. Maybe we have no need for another "beautiful phone" phones using even more of your time. Not another phone that you just "keep using" because it looks so beautiful and works so well. Maybe it's time for phones using less of your time, that don't go in the way of communicating with others, but still let you do the things you want to do.
Or, maybe it's time for users that can handle priorities. Maybe it's not the phone that needs change. Maybe it's the people and their behaviour, which is not changed by a different type of mobile phone. Even then, the videos are still funny.
To finish: one quote from the developer videos (announcing the most recent tools available): "Go get 'em. Be inspired, be awesome, stay nerdy" :-).
2010/10/12
Android 2.2 - update
Ok, so even Android 2.2 isn't a silver bullet ;-).
After using it for a while, I had to turn of JIT-compiling, because it made my phone .. well .. run slower. The only reason for that I can think of is a lack of internal memory. Binary code simply is larger - and thus uses more memory than bytecode does, and my two year old G1 - being the first Android handset - hasn't that much RAM (around 74 MB, compare that to the myTouch and iPhone 4 having 512 MB).
Still, it's an amazing system. A state-of-the-art Smartphone OS running quite smooth on quite old hardware. Thumbs up for Cyanogen (and a $10-donation).
After using it for a while, I had to turn of JIT-compiling, because it made my phone .. well .. run slower. The only reason for that I can think of is a lack of internal memory. Binary code simply is larger - and thus uses more memory than bytecode does, and my two year old G1 - being the first Android handset - hasn't that much RAM (around 74 MB, compare that to the myTouch and iPhone 4 having 512 MB).
Still, it's an amazing system. A state-of-the-art Smartphone OS running quite smooth on quite old hardware. Thumbs up for Cyanogen (and a $10-donation).
2010/08/15
Android 2.2 - Android grown mature :)
At first, I could hardly believe it - on my two year old (!) G1, I installed a new Android OS and it actually ran faster than any before! After digging in, I could hardly believe another thing - that Google managed to go on for three years with "scripted" apps that knew no compiling... But finally, Android seems to have grown mature.
Highlight for the moment (running it for only two hours now)
- JIT: speeeeeedy :)
- Gallery - integrates with Picasa, and the "stack peek" we know from the iPad is implemented in a really nice way. Ever been looking at a Photo, and after a while realised that is what floating in 3D while following the direction of your hand? It's a WOW. Two thumbs up for Android - (ok, and for Cyanogen, who makes this available for my old G1)
Highlight for the moment (running it for only two hours now)
- JIT: speeeeeedy :)
- Gallery - integrates with Picasa, and the "stack peek" we know from the iPad is implemented in a really nice way. Ever been looking at a Photo, and after a while realised that is what floating in 3D while following the direction of your hand? It's a WOW. Two thumbs up for Android - (ok, and for Cyanogen, who makes this available for my old G1)
2009/04/29
Defaultism
Three decades ago, a software company named Microsoft successfully started to use a new marketing device: the OEM license. With a pre-installed OS on you new-bought PC, users didn't think anymore about which OS to use - the default, pre-installed OS did indeed meet much requirements, so why should you ever take the effort of looking further?
Much has changed since then, but one thing has not: users are still using mainly the software bundled with the computer or OS, until it lacks important possibilities or they already have experience with a piece of software not present by default. Of course, I am guilty of this behavior as well: back in the days I was still using Windows, I started using a Linux distro because I was very sure it was better. But I became disappointed: as an unexperienced user, not all peripherals did work right out of the box, and messing with configuration files in Vi is quite difficult if all you ever worked with was Dreamweaver. I didn't start using Linux until I got a smooth working distribution out of the box by default settings (or by few and very easy configuration). This behavior I call defaultism.
Most of the Linux users don't act that way. At least, they think they don't. Because they install an OS that's not bundled with the computer by default. After some playing around with desktop enivronments they start looking around and they start discovering the shell. And more and more they become aware of the powerful possibilities. But this is where it ends for the most people.
For most Linux distributions, BASH (the GNU Bourne Again Shell) is default. And it's a pretty good one. It's powerful, relatively easy to use, there is a lot of documentation about it on the internet and - hey, it's default! Sometimes users try other shells like the C shell, the Korn shell, TCSH or ZSH. However, by default, the shells aren't configured the way Bash is. So they experience the shell as "difficult", say it has a "lack of possibilities" or isn't "accessible" enough. All because a decent configuration file is absent.
Last months I've become enthusiast about a particular shell - ZSH. But not before I got a useful .zshrc file - the ZSH config file you have to store in your home directory to make it useful. ZSH is much faster than Bash, extremely configurable and available on nearly every Unix-box. Including Mac. Including BSD. Including every Linux distro I've known so far.
Right now I discover I'm falling back into defaultism again - all I do is making some minor tweaks to existing zsh config files to get it working my way. I don't dive deep into the zshrc file structure to fine-tune it to my wishes. Again, I'm sticking with default settings.
Same story with Vim: I discovered Vim, got used to the basics and became very excited about the ease and efficiency of use. Still I didn't dive into the configuration to make it even more useful. I didn't explore all possibilities but a few - although they're very useful and even now Vim outperforms any other editor I've ever used. But still I stick to defaults.
"Never change a winning team" is well-known, but applied somewhat too easy. I think as computer users, sometimes we don't know whether we're winning or not.
Definitely, in many cases we know. As a beginning C programmer, I knew I wasn't winning when I din't use Makefiles. As a decent company, you know you're not winning when you don't have a website (Besides, are you decent at all without a website?). But in that case, as soon as you will get the opportunity, you will leap up and make sure the winning gear will be in house - before losing even more.
However, sometimes we don't know whether we're winning or not. I never knew I was not winning when I used Linux without using the shell. Until I experienced the advantages. I never knew I was not winning while sticking to Eclipse or gedit. Until I discovered the advantages of Vim. And I'm aware I will be winning when I set applications to my preferences.
Undoubtedly there are improvements out there still unknown to me. Everytime I choose the non-defaultist's way there are. So I got to keep my eyes open for the non-default way to keep winning.
(P.S. wanna get excited too about ZSH?
ZSH: the last shell you'll ever need (Fried CPU)
ZSH for productivity (Prashblog)
Phil!'s ZSH prompt
ZSH description from ArchLinux wiki)
Much has changed since then, but one thing has not: users are still using mainly the software bundled with the computer or OS, until it lacks important possibilities or they already have experience with a piece of software not present by default. Of course, I am guilty of this behavior as well: back in the days I was still using Windows, I started using a Linux distro because I was very sure it was better. But I became disappointed: as an unexperienced user, not all peripherals did work right out of the box, and messing with configuration files in Vi is quite difficult if all you ever worked with was Dreamweaver. I didn't start using Linux until I got a smooth working distribution out of the box by default settings (or by few and very easy configuration). This behavior I call defaultism.
Most of the Linux users don't act that way. At least, they think they don't. Because they install an OS that's not bundled with the computer by default. After some playing around with desktop enivronments they start looking around and they start discovering the shell. And more and more they become aware of the powerful possibilities. But this is where it ends for the most people.
For most Linux distributions, BASH (the GNU Bourne Again Shell) is default. And it's a pretty good one. It's powerful, relatively easy to use, there is a lot of documentation about it on the internet and - hey, it's default! Sometimes users try other shells like the C shell, the Korn shell, TCSH or ZSH. However, by default, the shells aren't configured the way Bash is. So they experience the shell as "difficult", say it has a "lack of possibilities" or isn't "accessible" enough. All because a decent configuration file is absent.
Last months I've become enthusiast about a particular shell - ZSH. But not before I got a useful .zshrc file - the ZSH config file you have to store in your home directory to make it useful. ZSH is much faster than Bash, extremely configurable and available on nearly every Unix-box. Including Mac. Including BSD. Including every Linux distro I've known so far.
Right now I discover I'm falling back into defaultism again - all I do is making some minor tweaks to existing zsh config files to get it working my way. I don't dive deep into the zshrc file structure to fine-tune it to my wishes. Again, I'm sticking with default settings.
Same story with Vim: I discovered Vim, got used to the basics and became very excited about the ease and efficiency of use. Still I didn't dive into the configuration to make it even more useful. I didn't explore all possibilities but a few - although they're very useful and even now Vim outperforms any other editor I've ever used. But still I stick to defaults.
"Never change a winning team" is well-known, but applied somewhat too easy. I think as computer users, sometimes we don't know whether we're winning or not.
Definitely, in many cases we know. As a beginning C programmer, I knew I wasn't winning when I din't use Makefiles. As a decent company, you know you're not winning when you don't have a website (Besides, are you decent at all without a website?). But in that case, as soon as you will get the opportunity, you will leap up and make sure the winning gear will be in house - before losing even more.
However, sometimes we don't know whether we're winning or not. I never knew I was not winning when I used Linux without using the shell. Until I experienced the advantages. I never knew I was not winning while sticking to Eclipse or gedit. Until I discovered the advantages of Vim. And I'm aware I will be winning when I set applications to my preferences.
Undoubtedly there are improvements out there still unknown to me. Everytime I choose the non-defaultist's way there are. So I got to keep my eyes open for the non-default way to keep winning.
(P.S. wanna get excited too about ZSH?
ZSH: the last shell you'll ever need (Fried CPU)
ZSH for productivity (Prashblog)
Phil!'s ZSH prompt
ZSH description from ArchLinux wiki)
2008/10/06
VIM tutorial
We hebben gezien dat veel van jullie nog werken met de editor Kate / Kwrite. Weliswaar zijn deze editors toegankelijk en snel te begrijpen, ze werken voor een programmeur behoorlijk inefficient (bedenk alleen al eens hoe vaak je op de spatiebalk moet rammen tijdens een sessie programmeren of wat een moeite het kost om een loop in z'n geheel te indenten).
We zouden jullie willen aanraden om VIM te gaan gebruiken. Uiteraard kunnen we jullie niets verplichten, maar VIM heeft voordelen als:
- alles te bedienen met het toetsenbord ZONDER ingewikkelde toetscombinaties (Ctrl-Shift-Alt Z e.d. zul je niet tegenkomen)
- de aanwezigheid van verschrikkelijk geavanceerde functies (waar veel IDEs niet aan kunnen tippen), maar tegelijkertijd het binnen een seconde opgestart zijn en draaiend op de traagste systemen (of over je SSH-verbinding)
We kunnen hier nog wel even doorgaan met een lofzang op VIM, maar dat doen we niet. We zouden jullie willen aanmoedigen om VIM uit te proberen.
Omdat VIM een kleine drempel heeft om ermee te beginnen, heeft Tim een tutorial geschreven. Deze staat hier.
We zouden jullie willen aanraden om VIM te gaan gebruiken. Uiteraard kunnen we jullie niets verplichten, maar VIM heeft voordelen als:
- alles te bedienen met het toetsenbord ZONDER ingewikkelde toetscombinaties (Ctrl-Shift-Alt Z e.d. zul je niet tegenkomen)
- de aanwezigheid van verschrikkelijk geavanceerde functies (waar veel IDEs niet aan kunnen tippen), maar tegelijkertijd het binnen een seconde opgestart zijn en draaiend op de traagste systemen (of over je SSH-verbinding)
We kunnen hier nog wel even doorgaan met een lofzang op VIM, maar dat doen we niet. We zouden jullie willen aanmoedigen om VIM uit te proberen.
Omdat VIM een kleine drempel heeft om ermee te beginnen, heeft Tim een tutorial geschreven. Deze staat hier.
2008/09/20
SSH & SCP for Windows -> PuTTY
For those first-year students still on Windows, I'll post two articles.
The first one is on how to get the SSH-functionality while you're still running Windows, the second one will be (I hope within a week) to post another article - about migrating to Linux.
When you want to access your UvA-home folder and you have only a Windows environment, here's the solution: PuTTY. PuTTY is a program that has the SSH-functionality, and you can simply run it from the Windows-shell (cmd.exe).
I won't give too many details over here - just try to download it, you won't have to do any installation (many people carry PuTTY with them on a USB-stick because of that). The PuTTY SCP program is called pscp.
Download PuTTY here:
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
(I hope you know how to use a Windows commandline..)
The first one is on how to get the SSH-functionality while you're still running Windows, the second one will be (I hope within a week) to post another article - about migrating to Linux.
When you want to access your UvA-home folder and you have only a Windows environment, here's the solution: PuTTY. PuTTY is a program that has the SSH-functionality, and you can simply run it from the Windows-shell (cmd.exe).
I won't give too many details over here - just try to download it, you won't have to do any installation (many people carry PuTTY with them on a USB-stick because of that). The PuTTY SCP program is called pscp.
Download PuTTY here:
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
(I hope you know how to use a Windows commandline..)
2008/09/19
SCP (follow-up to SSH)
(If you don't know how to use SSH, first read the previous post)
Another post for the first year students of UvA..
SSH starts a remote shell, enabling you to work on a computer and have full control while you're on the other side of the world (but also if you're sitting next to it, of course). A little downside is, that you - when you're physically on another pc - cannot access your local pc from within the same shell. To move files to and from remote pc's over a SSH connection, there's another tool in Linux, called SCP.
(Before copying anything using scp, you don't have to log in to a ssh server. Of course it is possible to copy anything after logging in, but in that case the "local" file is in reality the "remote" file, and the "remote" file is a file on another "remote" server.
Syntax is quite simple if you're used to ssh:
scp user@host:/path/to/sourcefile /path/to/destinationfile
of course it will work in two directions:
scp /path/to/sourcefile user@host:/path/to/destinationfile
and, instead of destinationfile you'll also be able to specify a directory:
scp user@host:/path/to/sourcefile /path/to/destinationfolder/
use of wildcards is also permitted.
scp user@host:/path/to/sourcefolder/* /path/to/destinationfolder/
So, let's copy a all .txt-files from our UvA-home directory to the directory at the pc I'm now working on:
scp scienceaccount@sremote.science.uva.nl:~/*.txt .
(the last "." stands for "current directory")
Or, copy everything in my UvA-home directory to the directory called "uva_homedir" on the PC I'm right now working on:
scp -r scienceaccount@sremote.science.uva.nl:~/* ~/uva_homedir
Another post for the first year students of UvA..
SSH starts a remote shell, enabling you to work on a computer and have full control while you're on the other side of the world (but also if you're sitting next to it, of course). A little downside is, that you - when you're physically on another pc - cannot access your local pc from within the same shell. To move files to and from remote pc's over a SSH connection, there's another tool in Linux, called SCP.
(Before copying anything using scp, you don't have to log in to a ssh server. Of course it is possible to copy anything after logging in, but in that case the "local" file is in reality the "remote" file, and the "remote" file is a file on another "remote" server.
Syntax is quite simple if you're used to ssh:
scp user@host:/path/to/sourcefile /path/to/destinationfile
of course it will work in two directions:
scp /path/to/sourcefile user@host:/path/to/destinationfile
and, instead of destinationfile you'll also be able to specify a directory:
scp user@host:/path/to/sourcefile /path/to/destinationfolder/
use of wildcards is also permitted.
scp user@host:/path/to/sourcefolder/* /path/to/destinationfolder/
So, let's copy a all .txt-files from our UvA-home directory to the directory at the pc I'm now working on:
scp scienceaccount@sremote.science.uva.nl:~/*.txt .
(the last "." stands for "current directory")
Or, copy everything in my UvA-home directory to the directory called "uva_homedir" on the PC I'm right now working on:
scp -r scienceaccount@sremote.science.uva.nl:~/* ~/uva_homedir
Subscribe to:
Posts (Atom)