< mari
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
chi >
[ Page 36 of 76 ]
From: Rafael Garcia-Suarez
Date: 08:33 on 15 Mar 2006
Subject: Some fresh rpm hate
And now, some hate for developers. Sorry in advance for our
non-C-fluent readers.
Somewhere in the rpm library headers, up to version 4.4.4, you have
this nice typedef:
typedef void * (*rpmCallbackFunction)
(/*@null@*/ const void * h,
const rpmCallbackType what,
const unsigned long amount,
const unsigned long total,
/*@null@*/ fnpyKey key,
/*@null@*/ rpmCallbackData data)
So far so good. Except that in 4.4.5 the "amount" and "total"
arguments were changed to unsigned long long (without any mention in
the release changelog, of course, that would be telling).
So, if you have some C program that defines an rpmCallbackFunction,
when it gets called, the call stack is blown, your program segfaults
and gdb is confused. Hard to trace. Depending on the C application,
this might also have unnice consequences on your system's rpm
database, I suppose.
But it doesn't stop there. I haven't been able to figure out a way to
check for the version of the rpmlib you're linking against via plain
#ifdefs. Which means that I have to fallback to some Makefile magic to
add a CPP symbol that says whether I need an unsigned long or an
unsigned long long here. Duh.
From: Scott Evans Date: 05:38 on 11 Mar 2006 Subject: dear native instruments, fuck you. stop fucking asking me to insert my battery cd. i bought the thing. stop punishing me for it. also, kontakt really sucks. you took everything fun about using samplers and ruined it with your shitty first-year design student sense of user interface. i worked faster on my goddamn akai in 1996. i'm about ready to buy another hardware sampler just so i never have to use your piece of crap again. also, fuck you, scott
From: Abigail Date: 23:31 on 10 Mar 2006 Subject: Reason #1781 to hate Mosa^H^H^H^HNets^H^H^H^HMozil^H^H^H^H^HFirefox. --QRj9sO5tAVLaXnSD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline So, you're the son of the son of the son of Mosaic, and half the geeks think you're the best thing since sliced bread. And you're supposed to be able to surpress popups - a feat you display prominently each and every time *you display a popup*. Not only do you annoy me with the popups, you also lie to me, claiming you did something you didn't. Too bad Internet Explorer doesn't run on Linux. Abigail --QRj9sO5tAVLaXnSD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFEEgw3BOh7Ggo6rasRAlRfAKCfgYNNb72hAHGshCF2iB5UbIiVFACgwyRq w5NRI56XddRP5V3eSjusp18= =fKuh -----END PGP SIGNATURE----- --QRj9sO5tAVLaXnSD--
From: Simon Wistow
Date: 14:25 on 21 Feb 2006
Subject: mplayer's frame extraction
I want to extract some frames from a movie and mplayer has the necessary
codec chops to cover it.
Handily it provides a video out codec of 'png' which writes each frame
as a png. Kudos to mplayer. Kudos.
Enjoy it though, you weasley bit of software sputum, it's the last
you'll get.
In my handy dandy wrapper to extract movies into frames I want to
provide the ability to extract only a range of frames. So we have five
options
1) $start-$end (i.e 1-$end)
2) $start-$m
3) $n-$n (i.e a single frame)
4) $n-$end
5) $n-$m
The first one is easy - we just extract everything. This, hwoever is
where it stops being straight forward.
mplayer provides two relevant options: -frames which takes an integer
and only extracts that many frames. And -ss. Which takes a floating
point number of seconds offset.
*sigh*
That's no problem though - we can just get the FPS of the movie subtract
1 from our start frame and then divide by the FPS to get the start
second of the frame we want.
Easy. Right?
No.
Let's try it shall we
----------------------------------------------
o Case 1 - $start-$end (i.e 1-$end)
----------------------------------------------
Do nothing.
----------------------------------------------
o Case 2 - $start-$m
----------------------------------------------
% mplayer -frames 1 -vo png test.mov
...
% ls *.png
00000001.png 00000002.png
%
WTF? I asked you for one frame. You gave me two.
% mplayer -frames 2 -vo png test.mov
...
% ls *.png
00000001.png 00000002.png 00000003.png
%
*breathe*
No, it's ok. We can deal with this. We just delete the extra one.
Right that takes care of cases 1 and 2. Let's try with an offset and
extracting only 1 frame (i.e case 3).
----------------------------------------------
o Case 3 - $n-$n (i.e a single frame)
----------------------------------------------
Well, in the case of $start=1 and $end=1 - frame 1 is time offset 0 so
that's just the case above.
Let's try $start=2 and $end=2.Frame 2 should be at (assuming 24 FPS) at
time offset 0.04166666667.
% mplayer -ss 0.04166666667 -frames 1 -vo png test.mov
...
% ls *.png
00000001.png 00000002.png
%
ok, well it's generated that extra frame again so all we have to do is
delete the last one and ...
Oh. Wait. No. the first image is actually frame 1. So we delete that,
right?
If only it was that simple. 00000002.png is actually ... frame, err, 4.
Well, what happens if try and get frame 3
% mplayer -ss 0.08333333334 -frames 1 -vo png test.mov
^^^^^^^^^^^^^ (3-1/24)
Again we get 2 frames but this time 00000002.png is actually frame 5.
And 00000001.png is *still* frame 1.
Fortunately this progresses linearly so we can deal fairly sanely with
case 3 with just 2 special cases for when $n is 1 or 2.
----------------------------------------------
o Case 4 - $n-$end
----------------------------------------------
'Fortunately' enough we have the same issues that we do with case 3 i.e
the spurious frame 1 always being there and weird jump at the start of
the frame offset but no matter - we can deal with this.
Again 'just' 2 special cases for frames 1 and 2.
Running tally so far
4 cases + 4 special cases.
----------------------------------------------
o Case 5 - $n-$m
----------------------------------------------
Let's break this down shall we.
=============================================
* 5a) $n == 1
=============================================
Same as Case 1
=============================================
* 5b) $m == $end
=============================================
Same as Case 4
=============================================
* 5b) $n=2 $m=3
=============================================
Almost the same as Case 3 but with another special case because mplayer
can't seek to frame 2 because ...
....
....
and this goes on with an ever increasing number of special cases. I
think I'm up to about 10 at the moment. And my logic, written in tcsh
(don't ask) is getting ever more complicated. And basically I can't be
arsed.
Weirdly it turns out to usually be quicker to just dump everything out
and then nuke the stuff you don't want because see because seeking is so
slow.
So fuck it.
From: Peter Pentchev Date: 08:40 on 17 Feb 2006 Subject: Core Banking Systems --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear Great Big Smelly Piece of S... S... Software, that shall remain unnamed not to protect the guilty, not even to protect the innocent, but merely because if I have to once more utter, write, or type its German-sounding name, its three-letter acronym, or its trade name that brings up associations of both physics and topology, I *will* be violently sick all over the desk and the floor, and the cleaning lady has done absolutely nothing to deserve the extra amount of work. We have known each other for a full year now. We've been through good times and bad times - or, at least, that's how the saying goes, while actually it feels more like bad times and worse times, and I'm kinda reminded of the English joke about the doctor's son who, when asked for the comparative and superlative degree of "bad", promptly answered "bad, worse, dead". Some people might say that such intimacy over the course of an year is grounds for a nice, healthy, long-standing relationship. Some people might go steal an H-bomb, drop it into the crater of an active volcano, watch the blast from a respectful distance, then briskly walk over to the gap of the newly-formed crater, and do a double somersault - backwards - into the hot, spicy, bubbling, radioactive lava. How do I hate you? Let me count the ways... Way the First - Message Queueing. Okay, so you're based on a well-thought-out, industry standard, fully buzzword-compliant message queueing architecture from a certain bluish software and hardware company. So far, so good. But did you really *need* to take the concept of message queues, turn it inside out, marvel at the shiny bits inside, *then* turn it upside down, shake it violently, and run with it? Did you really, really have to define a separate queue model for pretty much every single query (oh, excuse me, those are not queries, those are not even messages, those are *processes* now), then squeal, throw a hissy fit, roll over and die each time somebody sends you a message with the wrong queue model? And oh, certainly, every now and then some part of you decides to send a reply on the *wrong* dynamic queue, then just sits and waits until Somebody(tm) comes along and fetches the message that nobody expects to be there - in the meantime, refusing to process any further messages, since "nobody fetched the response of the previous one yet". What's that you're saying? Timeouts? Ah, sure, there are timeouts - and pretty much reasonable timeouts, too - reasonable for your friendly neighbourhood planetologist, I mean! Way the Second - Error Reporting. Security measures? Oh, of course you've implemented security measures, no question about it! Like... let me tell you a story of many moons ago, painful as it is for me to even remember... So we're on site, fighting with said core banking system for the finishing touches of the pilot project. Suddenly, with absolutely NOTHING changed on our end, the system stops responding to our queries. Yep, we send a message, we send another one, we send fifteen different kinds of queries that worked, like, what, two minutes ago - and just like with the Fab Four, "No Reply". For two hours - two whole goddam hours - we work with the bank's IT guys, trying to diagnose all sorts of problems - all the way from network connectivity through protocols up to the system being up in the first place, which it obviously is, since no one at the bank is running around in panic and tearing his hair out - no one but us, I mean. Finally, one of the IT junkies comes up with a bright idea: "What account are you trying to use? THAT one?! Oh, it was just a temporary one, it expired today!" "Er, what?! Why didn't you tell us that two hours ago?" "I just thought of it..." "Uhm, wasn't it in the logs or something?" "Logs? What logs? It doesn't log this kind of problem anywhere, it just drops your query on the floor." Uhm. Whiskey Tango Foxtrot, over?! Now I'm not exactly what you'd call an omniscient security guru or anything, but... Correct me if I'm wrong, but if the core banking system receives - via the bank's internal network, no less - a query with the wrong auth credentials, there are two, and only two, plausible explanations: - something is misconfigured on the bank's internal network, and the bloody administrator freakin' needs to know about it - NOW! - somebody is trying something nasty ON THE BANK'S INTERNAL NETWORK, and the bloody administrator freakin' needs to know about it - NOW! What am I missing? Please tell me, what the hell am I missing? Way the Third - Fragility... or Reversibility... or Something So our application has to report the last 15 transactions on the customer's account. There's a query - uh, 'scuse me, a process - that returns the full information about the transactions on the account for a given time period, 60 at a time. We run it, fetch 'em all, the use the last 15. Of course, a Corporate Customer comes in with many, many transacions per day, and the "fetch 'em all" strategy leads to a wee bit of waiting on the line. Fine, so the query we are using has a "direction" parameter that lets us fetch the transactions going back in time. Clickety-click - ten lines changed in the code, a *single character* changed in the query sent to the core banking system. Half an hour of testing, everybody goes home happy. The next morning, five frantic phone calls in as many minutes: "We are missing transactions! We are not reporting transactions! We can see the transactions on our system, but your app does not show them!" Nah, impossible, innit? Well, let's humor them, let's go over and check. Yep, our app is missing transactions all right. An hour and a half later, after I've made each and every test known to humanity and then some, I go back to the bank's IT department, and, in exasperation, ask them, "Look, I *know* this sounds silly, but I just have to cover everything now... have you heard about any problems with such-and-such query when going back in time?" "Oh, of course! That's a known problem - you're not actually using it, are you now?" Must... not... explode... Must... not... climb... walls... Must... not... bring... walls... down... A single-character change in the query. Reverse the order that the results are returned in. Get a whole different batch of results. Yep, not only were some transactions missing, the banking system actually made up a couple of new ones, just to keep us giggling happily until the straitjackets are cut to size! Way the Fourth... oh, well, nevermind, I *really* could go on like this all day - nay, all week, if I have to - but there just ain't enough sedatives in the world, not even of the triple-distilled variety, to help me up afterwards! So, Dear Great Big Smelly Piece of S... S... Software! There was a certain Monk in a certain Monastery who came up with the idea that there is indeed a Biblical way of expressing the sentiment usually dished out as a four-letter acronym that starts with an 'F', ends with a 'D', and somewhere in the middle there's an 'O' and an 'A'; the Biblical quote in question was "Go forth and multiply!" Well, if "multiply" is extended to cover "do not, under any circumstances, create ANY ADDITIONAL COPIES of yourself, but simply use a high-power charge to create many, many disjoint small parts of you, all subtly different"... then by all means, dear core banking system, do kindly go forth and multiply! And no, I do *not* need to know when this happens - for if I never, ever hear anything about you again, it will have been an year too late! Loping off to scream, leap out of the long grass, and rip soft bits off small furry animals, Peter --=20 Peter Pentchev roam@xxxxxxx.xxx roam@xxxxx.xx roam@xxxxxxx.xxx PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 What would this sentence be like if pi were 3? --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (FreeBSD) iD8DBQFD9Yvt7Ri2jRYZRVMRArMlAJ9JZk8InMjT6CIY2iGUecPNf4fBmQCgtMfU On5sxWls/aSCBhbdBe5zjmI= =RdHV -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J--
From: Abigail Date: 19:54 on 15 Feb 2006 Subject: Locked user --1SQmhf2mF2YjsYvc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable So, there's this AIX box I've to work with. And on this AIX box, there's a user account I often need to work with. So, I want to be able to ssh to that user directly, instead of using ssh & su. I add my public key to the users authorized_keys file, and try to ssh. Failure. Checking the logs, it turns out that permission is denied because there are to many failed attempts. Now I have root on the box, but it's been more than a decade since I=20 last did any administration on an AIX box. Hence, I dive in the manual pages to find out how to fix this. After some digging, there's the command 'chkusr' that looks promising. Indeed, it reports the user has too many failed login attempts, and there's even an option to fix this. So, I run chkusr with the repair option, and it's fixed. Except that it now reports that the account is locked, and it can't fix that. And of course, ssh still doesn't work. Back to the manual pages. Ah, there's SMIT with the 'chuser' argument - for changing user parameters. Just what I need. And there it is, "account locked" is set to true. I switch it to false. Save and quit. Try ssh again. Failed. Too many failed login attempts. WTF? Run SMIT again. The account isn't locked. 'chkusr' says the user has too many failed login attempts, but it can fix that. And so it does. But that results in the account being locked again. Each time when I run 'SMIT chuser' to unlock the account, it starts thinking that the account has too many failed login attempts, and when I use 'chkusr' to unset this flag, the account becomes locked. Only later I learn that if you run SMIT with a different command, you can set even more user parameters, including both the 'locked' and the 'too many failed login attempts' flags. Abigail --1SQmhf2mF2YjsYvc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFD84cFBOh7Ggo6rasRAhQ4AKCr9qiUu5WOSNVKJkRx0DLj5lWnqACgpDrf bJJq5UXIFKsJvAz9uVCXYa8= =+smE -----END PGP SIGNATURE----- --1SQmhf2mF2YjsYvc--
From: Nicholas Clark
Date: 20:12 on 14 Feb 2006
Subject: The Internet
$ scp -p saigo.etla.org:bin/assimilate ~/bin
ssh: connect to host saigo.etla.org port 22: No route to host
What do you mean "No route to host"?
I'm only fucking logged in here from saigo.etla.org.
There must be a route for that error message to have reached my terminal.
And attempting to route from 1 machine (in France) to another (also in France)
via Seattle (not in France, not even in Europe) considered, well, brain dead.
Please just be working. Thanks in advance.
Nicholas Clark
From: David Cantrell Date: 12:40 on 29 Jan 2006 Subject: apt-get david@farmer-giles:/etc$ sudo apt-get update ... W: GPG error: ftp://ftp.demon.co.uk unstable Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 010908312D230C5F W: You may want to run apt-get update to correct these problems HATE
From: Martin Ebourne Date: 19:58 on 26 Jan 2006 Subject: Hates people Some fuckwit has signed paypal.com up to this list. Now every time I send an email to the list I get a paypal autoresponder reply telling me to enter the email in a stupid webpage. Half tempted to do it for sport value. Martin.
From: Yoz Grahame Date: 19:09 on 26 Jan 2006 Subject: Yet another Mac hate Be warned: The next smug Mac owner I see who publicly makes the mistaken statement that lovely shiny OS X is a whole world more stable than that Blue Screening crock of shit XP is getting this fucking useless Mac Mini (currently beachballing its little heart out, yet again, while I type this on my XP-running laptop) shoved down their latte-scalded throat. One of the main causes of the problem is this Mac running with "only" 512MB of RAM (an amount that I've happily used on Windows for twice the amount of work). We've had a 1GB stick sitting in the office for two weeks, but can we get it installed? Can we bollocks. Reason: Can't get the fucking super-small white object of desire open. Bought a putty knife as recommended by the interblogs - putty knife not thin enough to get into submolecular-sized gap in casing. Putty knife will be finding new home in the behind of Jonathan Ive or the next member of his team that crosses my path. -- Yoz, author of the upcoming Apple-switch memoir, "A Day At The Race Conditions"
< mari
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
chi >
[ Page 36 of 76 ]
Generated at 10:28 on 16 Apr 2008 by mariachi