Friday, 09 December 2011

Evolution of shells in Linux From Bourne to Bash and beyond By M. Tim Jones

IBM Developerworks has a writeup on the evolutions of shells in Linux. Covers a fair bit of territory and is a nice read with some scripting comparisons to help get a bit more context.

Here's a brief blurb:

Shells—or command-line interpreters—have a long history, but this discussion begins with the first UNIX® shell. Ken Thompson (of Bell Labs) developed the first shell for UNIX called the V6 shell in 1971. Similar to its predecessor in Multics, this shell (/bin/sh) was an independent user program that executed outside of the kernel. Concepts like globbing (pattern matching for parameter expansion, such as *.txt) were implemented in a separate utility called glob, as was the if command to evaluate conditional expressions. This separation kept the shell small, at under 900 lines of C source (see Resources for a link to the original source).

The shell introduced a compact syntax for redirection (< > and >>) and piping (| or ^) that has survived into modern shells. You can also find support for invoking sequential commands (with ;) and asynchronous commands (with &).

What the Thompson shell lacked was the ability to script. Its sole purpose was as an interactive shell (command interpreter) to invoke commands and view results.


[/technology] permanent link

Thursday, 08 December 2011

Android: A visual history By Chris Ziegler

The Verge[1] has an interesting article on the history of Android. It covers the genesis of Android and has interesting photos of the UI as it has evolved over the years.

Here's a brief blurb from the article:

Google’s Android operating system has undergone a pretty incredible metamorphosis in the three short years since it debuted on the T-Mobile G1. Think about it: three years, eight major releases. Eight. To put that in perspective, there have only been ten major consumer-grade releases of Windows (give or take, depending on how you count) in over twenty-five years of retail availability. You could make a pretty convincing argument that no consumer technology in history has evolved as quickly as the smartphone, and Android has been at the very center of that evolution.

With the release of Android 4.0 — Ice Cream Sandwich — on Samsung’s Galaxy Nexus, we wanted to take a look back through the years at how Andy Rubin’s brainchild has evolved into the industry titan that it is today. What’s changed? What has (sometimes stubbornly) stayed the same?

class="indent"> The Android era officially began on October 22nd, 2008, when the T-Mobile G1 launched in the United States. Initially, many features that we couldn't live without today were missing — an on-screen keyboard, multitouch capability, and paid apps, for instance — but the foundation was in place, and a few lasting trademarks of the platform debuted on those very first G1s to roll off the assembly line:


[/technology] permanent link

Saturday, 03 December 2011

Buffer Bloat and Network Latency/Performance

Slashdot has coverage[1] of an article from ACM Queue [2] that talks about buffers at the network level and its impact on latency and overall network performance/throughput. It makes for very compelling reading on the state of affairs and suboptimal settings at different points in the network and the overall impact on both latency and throughput within the network. There are lots of interesting details in the article and it's a good read.

Here's a blurb from the ACM Queue article:

Today's networks are suffering from unnecessary latency and poor system performance. The culprit is bufferbloat, the existence of excessively large and frequently full buffers inside the network. Large buffers have been inserted all over the Internet without sufficient thought or testing. They damage or defeat the fundamental congestion-avoidance algorithms of the Internet's most common transport protocol. Long delays from bufferbloat are frequently attributed incorrectly to network congestion, and this misinterpretation of the problem leads to the wrong solutions being proposed.

Here's the quote referenced by Slashdot:

"makes the case that the Internet is in danger of collapse due to 'bufferbloat,' 'the existence of excessively large and frequently full buffers inside the network.' Part of the blame is due to overbuffering; in an effort to protect ourselves we make things worse. But the problem runs deeper than that. Gettys' solution is AQM (active queue management) which is not deployed as widely as it should be. 'We are flying on an Internet airplane in which we are constantly swapping the wings, the engines, and the fuselage, with most of the cockpit instruments removed but only a few new instruments reinstalled. It crashed before; will it crash again?'"

There's also a whole website/project[3] dedicated to the effort, it appears.


[/technology] permanent link

Monday, 15 August 2011

Interesting Reads from the Technology World

Happy Independence Day.

Here are some interesting bits and pieces from the technology world.

[/technology] permanent link

Thursday, 14 July 2011

Debian on Patents

Debian has a nice write up on all things patents. It's a good overview of the patent system especially as applied to software in general and FOSS (like Debian) in particular. Definitely worth reading.

Here's a blurb from the page[1]:

Community Distribution Patent Policy FAQ


For whom is this document intended?

This document presents information about patents and patent liability useful for developers working on community distributions of Free and Open Source Software (FOSS). By community distributions, we mean collections of free software packages maintained and distributed by organizations composed of volunteers, where neither the organization nor the volunteers seek to make a profit from the activity. Such community-based distributions may sell as well as give away their work product, possibly on CDs or USB storage media or by paid-for downloads as well as by gratis distribution.

This document has been prepared by lawyers at the Software Freedom Law Center (SFLC) at the request of the Debian project, and may be helpful to similar community FOSS distributions. Its statements about legal matters are accurate as of the date of composition regarding US law, and may be applicable to other legal systems. But this document does not constitute legal advice. It has not been based on analysis of any particular factual situation, and any lawyer providing an opinion on the questions presented below would need to ascertain the particular facts and circumstances that might vary this information in a particular setting. You should not rely upon this document to make decisions affecting your project’s legal rights or responsibilities in a real-life situation without consulting SFLC or other lawyers.


[/technology] permanent link