Fishpool

To content | To menu | To search

Tag - hardware

Entries feed - Comments feed

Friday 28 August 2009

Why mobile computers are a bad idea

After my last night's posting, I had a small exchange with @moximilian and @jludwig about my claim that calling the N900 a computer is BS and nobody wants a computer. Somehow, Nokia has gone from calling the N-series devices "multimedia computers" a couple of years back to "mobile computers" today, but it's a totally horrible thing to do from a market positioning point of view. I suppose I should clarify my reasoning a bit.

This is how I imagine the thought process has gone: Nokia, an engineering-led manufacturer of fixed-function devices (phones) has had the ambition to "put the Internet in your pocket" for quite some time. So far, so good. Now, an engineer designs a brilliant package of a high-performance programmable microprocessor, significant amount of working memory and storage memory, and a rich set of input and output mechanisms. To an engineer, this fits the definition of a computer, thus it must be a computer.

However, that is not how the world at large sees computers. The general understanding of a computer is a device which requires constant management, is at risk from viruses and other malware, produces incomprehensible error messages and, despite being a window to the wonderful new world of Twitters, Facebooks and all kinds of information and entertainment, is best left alone when at all possible. Yes, the computer industry has made great progress in the last decades in making their produce more approachable and human-friendly, but it's not there yet. Apple, for all its faults, is generally regarded as the gold standard in "computers for the normal people". Yet who hasn't seen a Mac or even an iPhone (once loaded with applications, at least) bug out in the most bizarre of ways?

Computers don't have any built-in value of their own. The value is completely attached to the applications, services and solutions to which they provide access. If it was left at that, and calling something a "mobile computer" would be simply a bad choice of marketing titles, I wouldn't mind. However, as long as the engineers working on the future devices think it's desirable to think of them as computers, they will carry the problems I mentioned along to future devices, because that's what computers do.

The device in your pocket is a terminal, a window onto the services of the Global Computer, and a flexible access point to things no one has yet to invent. It is programmable, it does have memory, and it can compute. Even so, lets not call it a computer.

Thursday 27 August 2009

Reflections on Nokia Maemo

Earlier today Nokia announced their first handset based on what is likely to be their mobile operating system of the future - the Nokia N900 Maemo. I didn't think I would bother to pay attention, but somehow, I ended up doing so anyway, and this post is a result of that time spent thinking about it. I like quite a few things about it, but can't avoid being deeply bothered by other aspects. I hope by writing this I can make some small contribution to its future.

Why do I care? After the frustrations and disappointments with Nokia devices in the past years, I've tried not to. However, they're impossible to ignore in Finland, I have family reasons to hope this road leads to something good, and it's an attempt to make an open platform -- and I care about open platforms. Why do I feel qualified to comment? Well, because this is not really about devices, it's about software. And software is what I've always done, and managing software organizations is what I think about daily.

There's lot to like about the N900. I haven't seen, let alone played with one, but as far as the specs go, it's a pretty nice set of hardware. Same performance as the iPhone 3GS (which also makes it faster than any Android device announced), 3D acceleration, lots of storage (and a memory card slot), and, as a welcome change from many other Nokia devices, completely standard connectors (3.5mm audio, micro-USB tethering and battery charger). On the hardware side, the only thing not to like about it is the lack of a finger-usable, multi-touch display. This device, like all the other Nokia devices before it, require a stylus or at least long fingernails. It makes up for that by being really high resolution.

It's also based on an open source, Linux-based operating system Nokia has been developing for several years with community participation, Maemo. This makes it more attractive to me on a personal level than iPhone (which is way too closely guarded and controlled by Apple), Palm WebOS (open, but little track record), or even Android (open, but built out of pieces which have far less common with normal Linux than Maemo). It should be fairly clear that all four mentioned are way ahead of things like Symbian S60, which clearly needs to be taken behind the shed and put out of its misery, not matter what Nokia's representatives say about it official capacity.

On a more professional level, the inclusion of Flash 9.4 in the platform is a big deal. I'm anxious to get hold of one and see how much work it is to make Habbo work on it. This could be the first handset capable of technically running it (enough performance, enough resolution, good enough software), though obviously tuning our service to a mobile device would still need work on UI and other pieces.

However, like I wrote above, there's also plenty that bothers me. First of all, unlike most people probably realize, this is actually the 4th Maemo device in about as many years that Nokia releases. First was the Nokia 770 Internet Tablet, essentially an early adopter test device. Then came N800 -- running an updated OS which required applications to be ported to it, but which never was officially released for the 770 (putting the early adopter developers in a rather awkward position). Less than a year later N810 added a physical keyboard and an OS upgrade (which fortunately could be installed, with some difficulty, on the N800). That was quite a long time ago, though.

In the meantime, Maemo has been completely reinvented. The original UI toolkit has been switched to QT, which Nokia bought in the meantime, and all of the (rather limited quantity) applications require significant rework to be compatible with the OS release on the N900. The public reasoning for this compatibility break has been pretty weak -- "to ensure compatibility with S60", which also is moving on to QT framework. Why is this weak? Well, because the transition over on the S60 side also requires all of the (somewhat more numerous) applications developed for that platform to be significantly reworked. In other words, Nokia broke compatibility on both its old smartphone platform and the new platform at the same time, and offered little transitionary compatibility layers to either side. Not for the first time, either. S60 applications have been broken between upgrades several times before, too.

This track record is highly worrying. Despite their years of practice and ambitions to have a lively third party mobile applications market, Nokia has clearly not grasped the importance of a stable platform to the developers they mean to attract. This lack of understanding of one of the most basic requirements is enough to counter pretty much everything I wrote about Maemo versus its closest competitions a few chapters earlier.

Contrast the above to iPhone OS 2.0 to 3.0 transition. Sure, a few things did change. However, developers were given months of notice ahead of time, and the changes, apart from added functionality, were all pretty minor. Of course, Apple has a long history of making major upgrades while retaining forwards compatibility, with the Mac OS 68k to PowerPC, then to OS X, then to Intel CPU transitions.

It's also taken a LONG time for this device to be announced. I don't know, but I get the feeling it's something like a year late. The break in launch schedule between N810 and N900, the amount of changes in the Maemo platform, and the design of the device compared to for instance the N97 all scream "last year" to me. Besides, everyone knew this was coming ages ago. In the time between the launches of N810 and N900, Apple has managed to update the iPhone twice. This lack of predictability in the release cycle doesn't bode well for the next device in the line.

There is nothing more important for progress in software development than cycle time. The only cost-effective, productive way of making software today is to get feedback on it often, and the longer it stays unreleased, the more the feedback is late when it comes. This seems to be another area where Nokia has not been able to shake off their "we make hardware" mentality. Unline hardware, software can be updated with no extra cost. That's an advantage nearly everyone else has learned to make use of, and Nokia, if they truly desire to become a software and services powerhouse, has to finally take to heart.

N900 is not an "iPhone killer". I don't think it's meant to be. When its development started, it's unlikely the iPhone had even been announced. However, it's the best chance for Nokia to ever develop a device better than an iPhone. I hope they will - the world needs competition, and I would like to see Nokia be part in that. However, at this rate they will never catch up - Apple will have released two more major updates before the next Maemo device unless Nokia gets their act together.

I'm still hoping.

Friday 27 March 2009

Why OnLive will not be the massive tectonic shift so many are currently predicting

Among the things announced this week in GDC were two developments in entirely different directions on a particular axis of games technology: first, the OnLive network of thin clients showing network-streamed video games rendered on a server cluster somewhere, and second, the Mozilla/Khronos Group initiative to develop an OpenGL-accelerated, JavaScript-programmed 3D canvas in a web browser. Both have one thing in common: make it possible to run 3D apps (games) on standard devices without prior installations. How they go about that goal is radically different. One of them will fail.

OnLive is not the first company to attempt their idea. It's a basic extension to the same theme that has been around since at least the inception of the X Window System and Sun NeWS in early 80s - graphical thin clients showing applications running somewhere in the network. Further, the idea was explored for 3D games in the late 90s by G-Cluster, which apparently is still around in Japan in some form or another. In my opinion, it's a misguided approach. Certainly there's value to server-side processing, even of graphics, but the final rendering just makes so much more sense to be done on the client even when all of the application logic is remote.

What kind of client? Well, anything that can run a high-performance VM for Java or JavaScript (ie, a modern browser), and has 3D acceleration functionalities built into the graphics pipeline. This includes basically every network-connected device from the cost of $200 upwards: all smart phones, all netbooks, all laptops, all games consoles, and so on. Some of those devices are still intentionally crippled by their manufacturers in terms of operating system support for the required features, and clearly the 3D Canvas development hasn't been finished yet. The hardware capabilities, however, are already deployed to hundreds of millions of consumers.

Ignoring that deployed base and trying to scale a server-side rendering solution to the same figures is just mad. And that's not even considering the framerate and responsiveness constraints that are inescapable simply because of the round-trip network latency of such a system: on a high-bandwidth wired network 10s of milliseconds (not everyone can be situated within a few kilometers of the server cluster), and on radio networks, 100s of ms. Developing high-framerate games under those circumstances is hard enough when you only need to deal within transmitting positional data and adjusting for lag and jitter in both ends - making the games playable when every action made by the player needs to go to the server and back before it shows up is practically speaking impossible.

(Update an hour later) I suppose I should acknowledge that clearly the OnLive approach does have certain benefits to it: no piracy, little hacking of the typical kinds, little opportunity to cheat, and no need for investing in PunkBuster-type technology in the game clients, since none of that is running locally. However, all that just simply will not matter when weighed against the enormous brunt of having to run all that rendering in the wrong end of the MMO network and ignoring the opportunities to disperse so much of the investment and energy requirements to the gamers.

Sunday 23 September 2007

Non-root libgphoto2 access

I can be a total bitch to make a digital camera that does not look like a flash drive accessible to a normal user under Fedora 7. It sure was for me. Gphoto2 works, but only for the root user, and the net is full of instructions for messing with usbfs mount group, special udev rules, special HAL rules, and so forth. The problem is, nearly all of that discussion is obsolete or at least conflicts between different distributions.

For Fedora, two tricks are necessary: First of all, udev needs to be told the USB devices which should be user-accessible, and second, the PAM console permissions map is missing a class of devices useful for this purpose. It is unfortunate that otherwise such a usable operating system needs this kind of tweaking, but it does.

The first is achieved by creating a special udev rule file such as  /etc/udev/rules.d/52-canon.rules:

SUBSYSTEM=="usb_device", ACTION=="add", SYSFS{idVendor}=="04a9", SYSFS{idProduct}=="306e", SYMLINK+="camera-%k" 

Every camera will have different vendor/product codes, of course. To make this change effective, reboot or restart udev with 'sudo killall udevd; sudo /sbin/start_udev'. Second trick is to change console permissions with a file such as /etc/security/console.perms.d/52-camera.perms:

# device classes -- these are shell-style globs
<usbcamera>=/dev/camera*
# permission definitions
<console> 0600 <usbcamera>

This is a "play-by-the-book" type of solution. If you're less interested in keeping some devices inaccessible from a normal account, a simpler permission scheme will make all USB devices available. In this latter case, no udev changes are needed, only a file in /etc/security/console.perms.d/usb.perms:

<usbdevices>=/dev/bus/usb/*/*
<console> 0600 <usbdevices>

Wednesday 29 August 2007

Working 3D on the 965GM

I took a second (third, whatever) look at how to get 3D acceleration enabled with the TravelMate, and finally found the clue to avoiding a display lockup the moment an OpenGL application was started.

Fedora 7 will not support it as-is. You'll need at least kernel 2.6.22.1 (2.6.22.4 is now in updates) and Mesa 6.5.3. I found it easiest to install Richard Hughes' "Utopia" builds of mesa-libGL and libdrm and a rebuilt fc8 xorg-x11-drv-i810. With these three packages, DRI can now be enabled and the machine is stable. Performance isn't stellar, but it's plenty enough to enjoy compiz and a slightly blinged up desktop, which is essentially what I was looking for, anyway. Ready-made binary attached. Remember, you need to update the kernel and drm bits too with the linked stuff.

Tuesday 21 August 2007

Acer Crystal Eye and GStreamer

The Crystal Eye webcam in new Acer laptops, my TravelMate 6292 included, works with the linux-uvc driver, as I noted before. To use it in GStreamer applications, you need to have the v4l2src component, which recently moved from the gstreamer-plugins-bad collection to gstreamer-plugins-good. In Fedora 7, you must have g-p-g version 0.10.6, which was just released to updates-testing (in a few days in updates, I would expect).

Update: With Fedora 9 or 10, you need nothing extra: the default installs of gstreamer-plugins-good and kernel already have everything built-in. Just set your default video input to Video for Linux 2 in gstreamer-properties.

If you don't want to build linux-uvc yourself (it's very easy), you may want to enable the drpixel yum repo that has it pre-built for Fedora kernels.

rpm -ivh http://download.tuxfamily.org/rpm/drpixel/fedora/7/i386/repodata/repoview/drpixel-release-0-1-2.html
yum --enablerepo=updates-testing --enablerepo=drpixel install gstreamer-plugins-good kmod-uvc

To test it, run:

gst-launch v4l2src queue-size=2 !  ffmpegcolorspace ! ximagesink

Wednesday 1 August 2007

Sound on Acer Travelmate 6292 under Linux

I know I said I'd wait until the end of my vacation to tinker with audio on this laptop, but I couldn't help it -- I wanted to watch DVDs, and movies without sound aren't all that great an experience. So, I had to dig in and see what the solution is.

Not all that easy, it turns out. Fedora 7's latest update kernel still has no support for the Realtek ALC268 sound codec, despite supporting a number of other codecs in Santa Rosa-based laptops. The latest development version of ALSA does have support for a couple of laptops with the 268 chip, but not the TM 6292. Another patch does exist that gets closer, and I made a version on top of that one that provides rudimentary support.

That is, the speakers work now, and so does the headphone jack. However, plugging in the headphones doesn't mute the speakers, and there is only one volume control for both of them. Actually, there are three (called Headphone, PCM, and Front), but only two of them do anything, and they do the same thing (control the volume of both speakers and headphones). Microphone input doesn't work at all. However, all those details are way beyond what I want to know about audio hardware control, and I'm satisfied enough to simply get some sound out of the machine for now. Some other enterprising soul may fill in the blanks.

Patch filed at ALSA's bug tracker. If you're using the 2.6.22.1-33.fc7 kernel (the latest update Fedora 7 kernel as of this moment), you can download a replacement snd-hda-intel.ko kernel module that should enable sound for this machine. Install with

rm /lib/modules/2.6.22.1-33.fc7/kernel/sound/pci/hda/snd-hda-intel.ko
cp snd-hda-intel.ko /lib/modules/2.6.22.1-33.fc7/extra/
depmod -ae
kill $(lsof -t /dev/snd/*)
modprobe -r snd-hda-intel
modprobe snd-hda-intel

Wednesday 18 July 2007

Acer TravelMate 6292 and Fedora 7 Linux

As I mentioned in my previous note, my previous laptop destroyed its fan last week. Since it had started to show its age in other respects as well and was deemed not worth repairing, I got a new one yesterday -- an Acer TravelMate 6292. This is a Core 2 Duo / Santa Rosa chipset based model, with some pretty cutting-edge technology inside. I'll write down the details later when typing is easier, but for anyone who might be considering one to use with Linux: yes, it does work, quite well in fact, but a bit of tweaking is required due to its very new components.

Update: it's been 17 months since I wrote this post, and it keeps being one of the more popular things in this blog. Time to add some up-to-date detail.

  • Fedora 7 LiveCD didn't like to boot, possibly due to a missing driver (it didn't like my previous laptop's external Firewire CD drive either). It might be possible to work around by changing BIOS settings, but I borrowed a USB CD drive instead. Update: this hasn't been a problem since F8.

  • Otherwise, the LiveCD install experience (including resizing and moving the Windows partition out of the way) was a very smooth one. I hadn't done this before, and was positively surprised. I'm certain Microsoft hasn't made their install this smooth, and I doubt Apple has, either. Much recommended, if you're even a little bit curious.

  • Network-based update post-install no problem using a wired network. All in all, the install took about 1 hour to move Windows partition, 20 minutes to install Fedora, and 30 minutes for it to load updates afterwards (this was surprisingly slow for some reason).

  • Wireless (Intel Wireless 4965 A/G/N adapter) driver (iwlwifi) was preinstalled, but the required firmware wasn't (the package only included firmware for the previous model, 3945). No problem, just install iwlwifi-4965-ucode from ATrpms. Update: Intel has an official wireless site for the firmware.

  • Things which worked without any effort at all: battery monitoring, CPU frequency control, temperature monitoring, wired Ethernet, Bluetooth, docking station, and many other things I take for granted. In fact, the machine was entirely functional save for the missing wireless adapter microcode straight off the LiveCD, and all that I did for it was to improve performance past the "functional" stage.

  • Display was a bit fuzzy, and 3D acceleration didn't work. This was because the preinstalled Xorg Intel driver v 2.0 includes only basic support for GMA X3100. Both problems disappear by installing a new kernel (for updated 3D/DRI driver) and Xorg 1.3.0/Intel 2.1.0 (for 2D etc), ie by running this command: Update: Display has worked perfectly since F8 and the Intel driver keeps improving in capabilities and performance
  • Both suspend-to-ram (S3) and hibernate-to-disk work fine, once the usb drivers are forced out of the kernel prior to suspend. Create /etc/pm/config.d/unload_modules with one line:

    SUSPEND_MODULES="ehci_hcd ohci_hcd uhci_hcd"
    
  • Update: The Crystal Eye webcam (USB ID 064e:a101) works using the linux-uvc driver, which needs to be installed from source (download, extract, make, make install) is included in the kernel since F9. Make sure you configure each application to use V4L2 instead of the old V4L API. For example with Ekiga, choose V4L2 instead of V4L in the configuration druid or in the Video Devices Preferences. Same goes for anything based on GStreamer.
  • Something still to do about audio, apparently common to many Santa Rosa laptops and the ALSA Intel HD Audio driver, at least ones which use a Realtek codec. Notes from Ubuntu might guide you along - me, I'll try again after my vacations. Perhaps someone else will bother to fix this one. :) Update: Sound playback as well as recording work - though the recording quality isn't quite what I would expect from a "noise cancelling" three-mic setup the hardware has. I never tested it under Windows, though, so I can't say how close this is to intended quality.

  • Haven't tried to use the fingerprint reader (USB ID 147e:2016) yet, the biometrics libraries required look a bit overwhelming to install. Update: this is still not out-of-the-box functional, but the ever-industrious Bastien Nocera has recently packaged libfprint and fprintd for inclusion in Fedora 11. I've tested those packages, and they support the hardware - not quite ready for end-users, though.

Saturday 12 August 2006

More about the 770

I've been playing with the Nokia 770 more the past few days, and figuring out how to make it more useful. Still haven't figured out a usable calendar application for it - not that GPE Calendar and Maemo Dates aren't good as such, but without a sync application, they're not usable for me. Otherwise, it's proving pretty good - I've managed to mostly tame the handwriting recogniser, too.

Continue reading...

Sunday 30 July 2006

New toys again - Nokia 770

Back in town from vacation trips - Sanna is back to work on Monday, but I still have one week in which I was thinking of doing some work around the home, etc. But I also finally bought a Nokia 770 I've been planning to get for some time. After one evening of playing with it, I'm not really sure what to think of it...

Continue reading...

- page 1 of 2