When
Graham
Bell invented the telephone in 1876, he probably didn t expect
the rise of the cellphones we ve been seeing over the last 20
years. At first, there were C-net phone too huge to carry, but
mobile still, as they communicated wireless. Then, devices became
smaller, networks faster and ubiquitous, and today, the number of
cellphones sold worldwide has exceeded the population.
Much like everything else, it used to be better back then .
When phone calls were still ridiculously expensive, people were
able to enjoy their peace and life progressed slow for everyone to
think enough, not do or say without engaging their brains. Then,
when the first cellphones stuffed people s pockets, they did their
job pretty much from the start: you could make phone calls. Some
genius discovered SMS as a splendid tool to
rip off customers, so phones grew pager abilities, but other
than that, they just worked; I remember my first phone, which
didn t break in years.
Obviously, if you re a phone manufacturer, you don t like that,
because once you sell a phone that works, the customer won t come
back to give more monies in ten years. Clever as you are, you
devised two schemes to ensure your cash flow: make phones more
brittle and crap, so that they break within a year, at most two;
and drag ever younger people into the
debt
trap. For the truly stupid, sites and services offer ring tones
and games and what not, and the lesser challenged you keep close by
the continuous addition of new features that noone needs.
So these days, almost every phone can play music files, which is
mighty convenient to spice up your work commute with some tunes,
but our youngsters are overburdened by that, it seems.
I almost soiled myself laughing at a group of five Italians at
Ezeiza Airport in Buenos Aires, who were sitting around waiting for
a bus, every one of them ear plugged and grooving to the beats (you
know how dorky it looks when people silently sing along rap
songs?). That s not the funny part. The funny part is that every
minute, one of them would say something, which would cause the
others to unplug one ear, and form their lips to bleat what
(making sure to add just a little bit extra of the tone of general
disinterest, which is cool ). This elicited one of two responses:
either the original speaker would say oh, nothing and everyone
nodded, or he d repeat his wisdom, causing everyone to laugh and
nod before in both cases they replugged and returned to luff
themselves. I wonder how they made it to the airport themselves,
and why they travel as a group.
Worse than that, however, is that cellphone manufacturers
remembered that their phones had speakers (for fancy ringtones) and
consequently added the ability to blast tunes through them. As a
result, groups of kiddies walk around or sit in trains, with one
(or more) of those cellphones blaring into the environment.
Apart from being generally inconsiderate, what I don t
understand is how they put up with the sound quality. It s mostly
hip-hop music you know that genre that makes some homies out
there install 5000 watt subwoofers into their cars so make sure the
windows rattle with the base but these phones have a frequency
spectrum comparable in width to that of your grandfather s, way
further up the scale (meaning they just don t do base). Playing
hip-hop through those is like putting a flute concerto on a
subwoofer, just worse, because high-pitch tones are harder to
filter by those who don t want to hear them.
And yet, I see it all over the place, kiddies listening to
music through cellphone speakers. Is it because silence would kill
them?
NP:
65daysofstatic:
The Fall of Math
To follow-up on my recent
posting about oldsys-preseed: I uploaded a new version of netcfg
yesterday that can be told via preseeding not to use a gateway. I also
uploaded a new version of oldsys-preseed that will properly handle static
IP configs without a netmask or gateway. Additionally, oldsys-preseed will
now use DHCP when the static IP config is incomplete (i.e. when either the
IP address or DNS are missing). This makes oldsys-preseed much more robust
and will hopefully get rid of many problems users ran into with etch.
Since I'm spending the summer in Israel, I used the opportunity
yesterday to visit the Marvell site in Yoqne'am where the majority of
the NAS software engineering team is located. They first gave me a
tour through the hardware labs which I found incredibly interesting.
It's amazing what equipment those folks use to perform QA tests of new
chips, how they can reverse engineer chips and even make some
modifications to test their theories about hardware bugs. I found it
really amazing and at the same time felt glad that changing things in
software is so easy.
Later they showed me the software lab where they had an exhibition of
various devices based on the Orion chip, including NAS devices, but
also printers, wifi APs and game machines. They also told me some
details of their product roadmap but unfortunately I cannot share that
information. The only thing I can say is that we'll see a lot of new
devices to which it would be cool to port Debian.
Sound Juicer "Stab Stab Stab! This Is More Than A Message" 2.23.3 has been
released. Tarballs are
available 
GMsoft reported a few weeks ago, that kernels on his A500 were hanging on startup with CONFIG_PRINTK_TIME enabled. Knowing that all this does is prefix the kernel messages with a timestamp, I was interested to find out how this could possibly be causing a hard hang.
Obviously, the first thing to do, is to try and reproduce the problem. But I was completely unable to reproduce it on my RP3440… How very strange. Ok, well, let’s poke at the A500 and see if it will happen there.
It does! Spooky…[1]
Well, now I was really interested. Let’s see what CONFIG_PRINTK_TIME actually does… In kernel/printk.c::vprintk, around the if (printk_time) section, we see that after printing the priority level tag, such as KERN_INFO, etc., we attempt to print a timestamp obtained with cpu_clock. The returned value from cpu_clock is in nanoseconds, so before it’s printed, it is munged into two smaller integers, the whole-seconds portion, and the decimal portion.
Ok, this gives us a great place to start looking for ways PA-RISC could be tripping up on these codepaths. The first was a fairly fruitless search of the cpu_clock call chain, which turned up nothing suspicious, aside from a maze of CONFIG_ options. Turned out, on non-x86, this code reduced into some fairly trivial stuff, none of which could really have been causing a hang.
However, we now had a basis for a fairly good hunch. If it wasn’t the cpu_clock going awry, the do_div routine, or sprintf must have been causing it. A quick boot-test to comment out the do_div routine and replace it will a fixed value resulted in a working system. Hooray.
Then it hit me like a freight train, when I saw what was being printed. This was the banner line… the very first thing printed in init/main.c, right after jumping into the kernel in virtual mode at start_kernel.
I recently announced that German and French reached 100% completion in
unstable for po-debconf translations (by the way, both are now 100% in
lenny as well).
However, l10n efforts also happen for many languages in that area, so it's time to highlight them as well:
At