While it looks slick, using the Apple Aluminium keyboard under Linux has some issues I was not aware of when I bought it. I've started to document it here.
After a few years of only buying laptops with Intel hardware, today I bought something totally different. It's not really what I wanted (which was an HP HDX 16t) but I get the feeling that none of these 16" HD 1080 laptops will make it to New Zealand for a while yet, and the NZ dollar has done such a nosedive recently that it's better not to wait any longer.
In the places that hold stock there seem to be some good specials around at the moment, and as the owner of a new free, open-source consulting business (i.e: a cheap bastard) I went shopping for the cheapest dual-core I could find with a half-decent screen, and I found the Asus X53K for $999 (USD$589) at Dick Smith, including a 2G ram upgrade to take it to 3G. It's entirely non-intel, with a 2GHz Turion dual-core, ATI Radeon X2300 with 1440x900 panel, Atheros AR2425 wifi and 160G HD. I'd bought a replacement 320G hard drive even before I got the laptop, so now I have a pristine, unbooted 160G hard drive with the install files for some other OS on it - no doubt I'll find a use for the disk, at least!
Since AMD got ATI to release all their chip documentation earlier this year I felt able to shell out for this, rather than the extra $100 for the model next to it, and it was nice too to get home and find that Atheros have recently released the HAL for their a/b/g chips. Which presumably means that they haven't done so for their 'n' chipsets, and I should continue to steer clear of that technology for a while yet...
I'm running Debian GNU/Linux 'Sid' on the Asus X53K and, everything pretty much just works out of the box. My installation process was to rsync the old laptop onto a new disk, and boot the new laptop from that - after compiling a new kernel more appropriate to the changed hardware.
After overcoming my own stupidity in not syncing the /dev/ underneath udev, which I easily googled my way out of, the only problem I've found so far is that the free radeon driver doesn't do 3d for me. Presumably the non-free ones would, but they won't compile against my 2.6.27 kernel so I don't know for sure. Fortunately I don't use 3d for anything so it's not a huge inconvenience to me. With 3G RAM and a fast 320G hard drive the laptop actually is an upgrade for me, too, and it has a webcam too, which I expect I'll look at in much the same way as I did the fingerprint reader on the old laptop. It will be good to finally hand that old one back to Catalyst, too, who have given me the flexibility to take my time on this.
Now to try and peel off all these stickers without damaging anything!
the mountain of the LORD's temple will be established as chief among the mountains; it will be raised above the hills, and all nations will stream to it.
When I blogged about water-proof keyboards a few months ago I did not
really expect that there will be water-proof mice (no IP classification
though) so soon, too. (Found in an advertisment in the current issue
of the German c’t
magazine.)
But the idea of water-proof mice in general doesn’t seem to be as new
as I initially expected, at least the web design of http://www.waterproofmouse.co.uk/ is very nineties. ;-)
RuggedTech even
has washable, wireless, IP66 (protected against powerful water jets) mice
with a scroll-wheel and completely
silicone sealed IP68 mice (protected against immersion beyond 1m).
A few years into this running hobby, I realized that my times were getting
better. But I had no feel for by how much, or whether that was a constant
rate of improvement etc pp. Long story short, I started to plot some of the data. What
seemed natural was to record the date, the distance in miles as well as in a
qualitative variable, and finally the average pace. Additionally, I played
with groupings into just three categories 'short', 'mid' and 'long'.
This leads to a natural 'one-factor' model of pace as a function of race date
grouped by race distance. And given how easy it is to do conditional plots in
R,
I quickly arrived at something that
already resembled the following chart:
At first, some of the groups had too few data points to actually reliably
construct regression lines, let alone non-parametric smoothers. But over
time more and more data points were added as I kept running races.
Including for example the somewhat disappointing result from
last
year's Chicago marathon in record heat that resulted in the outlier in
the last panel. It actually made the smooth fit turn upwards! Luckily, the
subsequent times in
New York last fall,
London in April,
and of course in
Berlin last month
helped to dampen the effect of the one outlier, resulting in a more normal straight line for marathon
performance that is comparable to the other four race lengths.
All in all I am now quite happy with the chart. The combination of the non-parametric loess smoother and the robust linear regression (using lrm
from the MASS package
for R)
shows that most groups exhibit very little non-linearity as both regression curves are very close to each other.
The curvature in the '10m' group is probably mostly a small-sample effect. And I am obviously happy with the
fact that three of the five panels show their respective last race as a PR :)
The R script containing the data and code
is available here
but requires some familiarity with the
lattice package for
R (as the
lattice book
would provide).
Yes, I was away... long and sad story involving health issues. :-( I'm trying to get back, hopefully everything will be fine. Let me publicly apologize to some people that was expecting some work from me and I postponed it, not because of slackness but because I was unable to do it. I'm catching up with a lot of tasks and trying to solve long standing issues, feel free to ping me to get some update on a specific matter. I am really sorry!
Do you know about the poll to choose a slogan for the release of Debian 5.0, also known as "lenny"?
No!? Shame on you! :-)
People behind Debian Art started a discussion to get opinions! After some input they prepared a poll, maybe they should try to use a doodle. Right now, The Universal Operating System is quite popular, but a lot of people did some nice suggestions, and some of them would like to see a slogan some way related to the Toy Story (tm) character Lenny:
The discussion is distributed across three lists: Debian Desktop, Debian Publicity and Debian Curiosa, I would also point to the comments made by Gustavo Noronha da Silva (here) and Andre Felipe Machado (here).
If you didn't say anything so far, please do!
As a beta tester for the new email application from Nokia, you will have to give your mail account password:
Most package maintainers might have noticed the longstanding l10n NMU campaign.
It started softly back in March, with the goal to tackle as many po-debconf l10n bug report as possible (while we're at it, we also fix other l10n bug reports, of course).
It became more aggressive after the freeze, with shortened reaction delay given to maintainers and shorter timeframes for translators to use an l10n NMU opportunity to send out new/updated translations.
So, *you*.... Will you be spotted by it?
Just look there. If, in this list, your package line is not pink, then you have already been spotted...or you will be. Actually, if you're above "ferm", you have been spotted. If you're below, you *will* be spotted.
How to avoid that 'shame'? Just upload you package and fix the mentioned bugs. Most of them are Swedish translations, after a few Swedish contributors did a giant campaign during summer to revive the Swedish translation effort.
B rk, b rk..... Make the Swedish chef happy! And save me some work. Avoid the radar spot. Upload!
PS: the current rate is about 5 packages per day. Maintainers have 4 days to react when I send the "intent to NMU" mail, then translators have 7 days to send updates. I *will* shorten this down soon by nearly dropping the translation update round and just NMU (or help the maintainer to upload) with what's in the BTS.
Bjorn mentions that he
doesn't want the nokia internet tablet, because it doesn't have a phone
and he doesn't want to carry two devices with him.
Bottom left, my portable media player. 4G solid-state storage, plays
movies (the display shows a scene from Star Trek: Deep Space Nine that I
converted from DVD), audio, FM radio, and after a firmware update can do
games and some random applications. Does bluetooth. Does not do phone
calls.
Upper right, my cell phone. A simple Nokia 6021. Does bluetooth,
makes phone calls, and (as the display somewhat shows) can do
calendaring, too. With SyncML, I can synchronize it with my laptop.
Together, they perform anything I'd possibly want from a smartphone
(and don't anyone tell me 'SSH', because doing ssh on any screen smaller
than, 7" and without decent keyboard is laughable).
Together, they're smaller and weigh less than a smartphone.
Together, they're less expensive than a smartphone ( 125 for the
phone, 85 for the portable media player).
Why does anyone buy a smartphone?
Anand Kumria wrote:
If IBM were to go bankrupt, would the government step in? Unlikely. Investors would lose (money), staff — another word for investors — would lose (jobs), but customers would win (their computers would keep working). Some customers would win more than others (especially those who had the equipment on lease); if no one is collecting, why pay?I’m wondering here where Anand got the idea that once a company went bankrupt, that you don’t need to pay to that company anymore. When a company goes bankrupt, at least in Germany the following happens: A trustee/liquidator is selected. This liquidator is then collecting the information who owes money to the company and who still needs to get (how much) money from it. The liquidator also has to check the option of selling company assets (which might include the contracts of customers that still have to pay) to fulfill the debts of the bankrupt company. After he turned all assets into money, the money is distributed among those who still have to get money from the bankrupt company. Anyway, regarding his main argument that the (average) customer of a company (bank in this case) should never have to pay for the failed speculations of that company, I somehow have to agree with him. Someone putting money into a regular bank account or papers with fixed interest rate should never lose his money. But there are also customers buying bank shares with a chance of higher revenue than with fixed interest rate papers. These should suffer from failure of the bank management, as they more or less explicitly wanted to be tied to the success (or failure) of the bank. However, this is mostly irrelevant, since the failure of so many “investment banks” has side affects that might cost the average inhabitant of the affected countries even more than the discussed rescue plans. One of these effects is that the banks are now much more conservative regarding lease and mortgage plans, effectively leaving many home owners with no option to fulfill previous obligations (remaining debt after a previous mortgage expired can’t be refinanced by a new mortgage), causing them to have to sell their homes to pay the first mortgage. This is in some way stupid because this causes people who were perfectly paying their mortgage rates to loose their house, while the bank which would be giving them a new mortgage could get a new and good customer, improving their income. On the other hand, if the other side effects of the current crisis cause those “good” mortgage customers to loose their jobs, they might turn into bad customers who are unable to pay their rates. All in all, this is a spiral that could cause the whole economy to break down (a small example: The bank is not giving out mortgages, so no one will build new houses so the builders loose their jobs so they don’t pay their mortgage rates anymore,…. - over simplified, but still shows what I mean). Unless the spiral is terminated in time, before too drastic things happen. All in all, I do understand why the politicians try to rescue those banks (or at least the customers of those banks), though I think that in an economy with slightly higher regulation, there wouldn’t be the need for such a rescue plan. I know there are some german banks affected by the crisis as well (among them Hypo Real Estate and others), but the average private customer of such banks shouldn’t loose money due to the regulations we have in place. In general, there should be some security fund which makes sure that private customers never loose money put into regular bank accounts or fixed interest papers, vice-versa, banks should calculate mortgages so that they can be pretty sure their customers are actually able to pay off their rates - it doesn’t make sense if someone starts off having to pay 500$/month for their mortgage and has to pay over 1000$ a few years (as in 2-3 years) later, because the bank raised the interest that much. I have no problem with people loosing money from shares of banks or other companies directly or indirectly through investment funds.
I won’t repeat my frequent anti-Plesk rant, but suffice to say: it’s a pain.
For some reason, we wanted one file back out of a backup. It took me a few minutes to realise it, but Plesk’s backups are essentially MIMEd and gzipped. So, rather than fighting with their mysterious semi-documented backup-unpack tool, just say:-
zcat backupfile sed -n -e '/name="filename.whatever/,/^--_--/p' >filename.whatever
If you don’t know the filename, zless’ing the head of the file should find it from the XML description blocks pretty quickly. Slight editing of the output file will be necessary, to strip MIME and so on, but it’s easier than installing too much else on a webserver.
Does anyone know why this gzipped-MIME is better than tar.gz or something else common and easy-to-use?
$ cat syms.c
static int local(void)
int global(void)
int __attribute__((weak)) weak(void)
$ gcc -o syms -c syms.c
$ readelf --syms ./syms
Symbol table '.symtab' contains 10 entries:
Num: Value Size Type Bind Vis Ndx Name
...
5: 00000000 8 FUNC LOCAL DEFAULT 1 local
8: 00000008 8 FUNC GLOBAL DEFAULT 1 global
9: 00000010 8 FUNC WEAK DEFAULT 1 weak
...
$ cat file1.c
void common_but_not_part_of_api(void)
$ cat file2.c
extern void common_but_not_part_of_api(void);
void api_function(void)
common_but_not_part_of_api();
$ gcc -shared -fPIC -o library file1.c file2.c
$ readelf --syms ./library
Symbol table '.symtab' contains 60 entries:
Num: Value Size Type Bind Vis Ndx Name
...
53: 00000424 29 FUNC GLOBAL DEFAULT 11 api_function
55: 0000041c 5 FUNC GLOBAL DEFAULT 11 common_but_not_part_of_api
...
$ cat file1.c
void common_but_not_part_of_api(void)
$ cat file2.c
extern void common_but_not_part_of_api(void);
void __attribute__((visibility("default"))) api_function(void)
common_but_not_part_of_api();
$ gcc -fvisibility=hidden -shared -fPIC -o library file1.c file2.c
$ readelf --syms ./library
Symbol table '.symtab' contains 60 entries:
Num: Value Size Type Bind Vis Ndx Name
48: 000003cc 5 FUNC LOCAL HIDDEN 11 common_but_not_part_of_api
54: 000003d4 29 FUNC GLOBAL DEFAULT 11 api_function
In the first example, there was not enough information to tell if
the function would ever be able to be overridden, hence a PLT entry
had to be created and the function called through it (disassemble it
to see the details!). With correct symbol visibility attributes,
there is enough information to know that
common_but_not_part_of_api is never to be overridden, hence
the PLT (and the associated costs of trampolining) can be avoided.
The internal attribute is even stricter; it says that this
function will never be called from outside this module (for
example, we might pass the address of
common_but_not_part_of_api to anyone). This can lead to even
better code, because on many architectures transitioning to another
module might involve flipping global pointer registers or other
similarly expensive operations.
So that's how symbol binding and visibility attributes can work
together to get you the best performance possible from your
program!
You probably noticed by now, that Debian GNU/Linux 5.0 aka Lennyhasn't been released in September. Well, that's a shame, but very easy to explain: Too many release critical bugs. Well, it's pretty hard to estimate, how fast RC bugs will be fixed, and apparently our release team was a bit too optimistic :( The big question is: What can you do, to help release
Lennyat least in this quarter? That's pretty easy: Fix rc-bugs, take care, that the fixed packages are migrated to
Lenny, do upgrade tests, document problems in the release-notes. Pretty simple, isn't it? For users Even as a
simple user(aren't we all just users?) you may help getting
Lennyreleased. Some things you can do:
Etch), you could consider upgrading to
Lennyand see, if everything works fine. Currently there are no detailed release notes documenting the procedure, so you best way to test upgrades are to:
Lenny(perhaps for the next release then?), you could start translating the release notes to a not yet supported language. If you are willing to do so (which can be quite time consuming, especially in the final phase), please contact either your localization team or the debian doc mailing list if there's no local mailing list.
simple userwithout deeper technical knowledge you can help us getting
Lennyin shape to be released. If you have technical knowledge: Very good! You might want to read the next section, too, and see what applies to you, there :) For maintainers It basically boils down to two things: If your packages have RC bugs open in
Lennyfix them and take care, that the fix will propagate to
Lenny. If your packages don't have RC bugs open, fix someone else's RC bug. Surely you don't think, the release team will fix the remaining rc bugs, do you? And surely you understand, that your shiny rc bug free packages are kind of useless, if they aren't released? To search for bugs to be fixed, take a look at the unofficial rc bugs thingy. The URL lists RC bugs open in both
Sidand
Lenny. Obviously they should be fixed ASAP. If no one takes care about these packages, they might be removed from
Lenny(if possible). Again: Try to reproduce the bug, try fix it, upload an NMU (or send your patch to the bug report and search for an sponsor). You'll notice, that some of these bugs already have a patch. In that case, your job would be to test the patch, report that to the bug report and offer to sponsor an NMU. Another interesting list is the list of rc bugs open only in
Lenny. These bugs have been fixed, but the fix hasn't propagated to
Lenny, yet. Normally, the release team will grant freeze exceptions for these packages if possible. However, if the changes to the fixed version are quite grave or the package in
Siddepends on a newer package than in
Lennythat's not possible. In these cases look out for packages marked as
need tpu uploador similar. Oh, and if you could refrain from upload new upstream versions of packages to
Sid, you would make all our lives easier. Some reasons:
Lennyanyway.
Sidmakes it harder to get a fix into
Lennyshould a new bug be found.
Lenny.
Sidand
Lenny, which is the more interesting list of bugs.
Next.
