The scenario here is that we want to deploy multiple web.py applications under the same domain (‘apps.example.com’ for instance). These applications are independent from each other and reside in separate paths. There are quite a number of ways of achieving this using Nginx and uWSGI. What is demonstrated here is a method that uses the VirtualHosting mode and DynamicApps feature of uWSGI to achieve miminal and once for all setup.
The next post contains an advanced version of this guide.
This post is a update to the previous one on the same topic.
The environment is as usual a low-end VPS with freshly installed Ubuntu 10.04.3 Lucid LTS (minimal version). First things first, :
Note: this is work-in-progress. This note will be gone when the post is finished.
Being the distro with the most versatile CPU architecture support, it was no wonder that Debian and its derivative systems were the first to be installed and run on homebrew-enabled Wii once the linux kernel was successfully ported. Debian is equipped with a powerful and easy-to-use Debian Installer, which enables people unfamiliar with linux to install and enjoy Debian without needing any fancy tool or ‘professional help’. Unfortunately, installing Debian-based systems on Wii has always been a headache, because Debian Installer can not output correct colour due to an issue with Wii’s framebuffer data format, and the user is unable to interact with it. It may be a little bit late, but that issue can now be dealt with and it is now possible to install Debian on Wii in the real ‘Debian way’.
This post will guide you through the process of installing Debian on homebrew-enabled Wii using a customized Debian Installer. However, if you prefer to go the lazy/easy way, there is a pre-installed disk image file available for download towards the end of the post, along with explanations on usage.
Checkout WiiBrew if you have no idea what this means.
Note: For background information and ‘take one’, please see the previous post on this topic. There will be as little repetition as possible in this post.
After the previous post on this topic went online, Malcolm Parsons from DSlinux commented that it is possible to track modifications to virtual framebuffer content by using kernel memory management mechanisms and mentioned deferred IO support in kernel framebuffer subsystem as an example. This suggestion was later concurred by GC-Linux guys. In this post, we will take a look at this idea.
This is the raw output of x11perfcomp -ro.
Tests were run under Debian 5.0.8 at 640x480x16bit.
For details on the different driver modes, please see this post.
Continue reading
This post is outdated. See this post for more up-to-date directions.
It should be safe to assume that anyone remotely interested in such a topic must already have a fair understanding of what this post is about, so let’s not waste any time on introductions.
The environment is as usual a low-end VPS with Ubuntu 10.04 Lucid LTS (minimal version). First things first, if you have not already done this:
Update: Take Two
Linux was successfully ported to Wii by the gc-linux team as early as Feb 2008, shortly after the release of the Twilight hack. In the following two years, huge progress and improvements were made to the port and some of the work has already made into mainline Linux kernel.
The fact that Wii resembles its predecessor, GameCube, to such a degree that Wii has often been labeled as ‘not next-gen’, played an important part in making the Wii port possible within such a short time frame, because the gc-linux people had already been working on the GC port of linux for many years. One of the many important similarities between GameCube and Wii is the use of YUY2 colour format in the framebuffer (XFB). There might have been valid reasons for Nintendo to choose such a format for their game consoles, but for the purpose of running Linux on these devices, this choice caused serious inconveniences.
In computer world, colour framebuffers on graphic cards have been predominantly using packed RGB formats for ages. Consequently, computer-oriented OS and software have grown to assume as much about the hardware and generally made no attempt of accommodating the possibility of ‘otherwise’. There certainly were many valid reasons for the choice of RGB for computer graphics, probably way more than there could have been for Nintendo’s choice of YUY2. Unfortunately, this ‘disagreement’ over formats between hardware and software meant more work for the porting guys, as they had to implement converting mechanisms so that the right colour could be displayed on the screen. Continue reading
This is the raw output of x11perfcomp.
Tests were run under Debian 5.0.8 at 640x480x16bit.
For details on the different driver modes, please see this post.
Continue reading
Browser extension developers often want to know how many people have downloaded their work and are actually using them. They may also want to know how often their users interact with the extensions, like accessing options/preferences etc. Although entities behind the browsers usually do offer basic download and maybe installation statistics for extensions hosted by them, for more advanced installation and usage tracking, developers have to find a way themselves.
Tracking extension installation and usage in Google’s Chromium/Chrome browser is a trivial task. One of the reasons for this is because Chromium’s extension system is based on ordinary HTML. An extension, at its minimum, is just one html file termed ‘background page’ that the browser loads automatically at startup. The ‘background page’ may or may not try to alter the browser GUI and/or webpage content, depending on the embedded or included JavaScript code. Adding the usual Google Analytics (GA) code snippet, which asynchronously requests the actual GA tracking code (GATC) file ga.js on GA server, to the background page is all that takes to track an enabled installation of an extension. Usage data such as extension-interaction events can also be easily tracked by defining handlers that send appropriate parameters to GATC. All of these can be done exactly the same way as tracking normal webpages served by an actual web server.
HTML5 introduced the ‘Web Storage‘ specification, which aims to provide a method for web developers to store data persistently on users’ local file system. By using the ‘localStorage’ object, key-value pairs can be stored (as strings) and persist through browser restarts and system power cycles. The process itself is transparent to both the web developer and the user.
This has been a much desired feature for quite a long time and is now officially supported by all major desktop as well as mobile browser implementations. But as is so often the case, all browsers do not behave the same way regarding one commonly-supported feature.
Both Google’s Webkit-based Chromium/Chrome and Mozilla’s Gecko-based Firefox/SeaMonkey/etc. support ‘localStorage’ and they both support extensions. However, due to differences in implementation details and possibly also security policies, Chromium/Chrome provides ‘localStorage’ for both (remote) web content and (local) extensions, whereas Gecko applications only allow webpages served from valid domain names to access ‘localStorage’ and denies extensions and locally-save html files this useful feature. This issue has been raised several times in various contexts on Mozilla’s bugzilla (e.g. 495747, 507361) since 2009, but it seems no forthcoming solution could be expected for now.
Subscribe to this site's RSS feed.