warning: Creating default object from empty value in /home/gwolf/drupal6/modules/taxonomy/ on line 33.

Re: sshfs

Submitted by gwolf on Mon, 08/07/2006 - 09:56
Junichi is delighted with sshfs. So am I - I now keep mounted some directories from several of my servers from my workstation, and it becomes oh-so-much-easier to do basically everything. Besides, sshfs seems to have been planned right security-wise - It is based on FUSE, so any user can just do [code='Bash'] $ mkdir remote_home $ sshfs remote_home [/code] and start working - What I found as a very sensible default is that the mounted pseudofilesystem is not visible by any other local user - Not even to almighty root. Of course, this is overridable. Now, Junichi just misses some performance when -of course- working with large files. I have noticed that, of course (after all, my home DSL connection is 512/128, so... opening by mistake a mere 1MB file makes me quite unhappy). My gripe is that it is slow dealing with directories with too many files, even though directories are (supposed to be?) cached. After thinking on this for a while (and not having straced mutt to assure me I'm right, I think it's because I tried to run a local mutt with remote maildirs - of course, scanning a couple thousand messages for their headers will not be a fast operation. Well, some day or other I'll finish setting up my mailbox at home to be IMAPable. And not even then, I fear, it will be very fast. I think it's time to dust off EOT, which seemed like a good idea, was a neat and easy implementation... But I never really used it.
( categories: )

Gstreamer, versions, documentation, frustration

Submitted by gwolf on Mon, 07/24/2006 - 19:00
I've spent a couple of weeks half-working my way towards an application to capture, recode and stream media, much in the fashion of what the very fine video team managed to do for Debconf6: Recording, encoding and streaming a live video feed via an Icecast server. Why didn't I just follow the easy path? Basically, because it's not friendly enough to be used by our camera operator at the Institute. So, I'm working on a simple GUI that will wrap the process, and provide feedback on its working. Feedback? Yes. We streamed the Mexican economy seminar using the simple commands, but the camera guys were so nervous on whether the process would work reliably that they phoned me every 40 minutes to check if the stream was alive. Originally, I worked on a wrapper to the different processes - but controlling the status on each of them didn't turn out to be as robust as I expected, and it's somewhat unnatural to dynamically plug/unplug elements in the pipeline (i.e. to show/hide a monitor to check the video being captured). I turned to Gstreamer. Anyway... I took this as an opportunity to do my first real Ruby work. Ruby is a very nice language, very natural to write and quite easy to understand so far. What's really lacking in it is the documentation. So far, I've referred to different online books and tutorials when doubting about its syntax, and to the GStreamer tutorial, the Ruby/Gstreamer API reference, and the Application Development Manual. The problem? Simple: I have to refer to online documentation, against what I've grown used to with Perl, having full documentation as part of each of the modules. In general, I've found the Ruby community -both on my first approximation, to Rails, and on this one- make really great tools, but are not very keen on documenting. And rubydoc might come from the same basic ideology as perldoc, but while perldoc is natural to check just as if it was a manpage, a rubydoc set of documentation has to be processed/compiled into its final (and, yes, often beautiful) form... Losing in the process a lot of the usability. In the end, my gripe comes because the documentation does not reflect reality. When the documentation is decoupled from the code. Quite a few methods or even classes are supposed to exist, while they don't. The documents I've been referring to don't show a version number
( categories: )

Fractional sleep

Submitted by gwolf on Mon, 06/19/2006 - 17:49
How cool is this? [code="ruby"] if pid=fork while true puts "#{}: I'm the slow #{}, parent of #{pid}" sleep 1 end else while true puts "#{}: I'm the fast #{}, child of #{Process.ppid}" sleep 1.0/3 end end [/code] What do I get?
18: I'm the fast 9900, child of 9899 18: I'm the slow 9899, parent of 9900 18: I'm the fast 9900, child of 9899 19: I'm the fast 9900, child of 9899 19: I'm the slow 9899, parent of 9900 19: I'm the fast 9900, child of 9899 19: I'm the fast 9900, child of 9899 20: I'm the fast 9900, child of 9899 20: I'm the slow 9899, parent of 9900 20: I'm the fast 9900, child of 9899 20: I'm the fast 9900, child of 9899
And for those of you not familiar with sleep(3), what is so cool about this? Simple: The prototype for sleep in almost any language is: [code="c"] #include unsigned int sleep(unsigned int seconds); [/code] (note the unsigned int part?) Even the Perl documentation clearly says, being compliant with the rest of the world:
For delays of finer granularity than one second, you may use Perl's "syscall" interface to access setitimer(2) if your system supports it, or else see "select" above. The Time::HiRes module (from CPAN, and starting from Perl 5.8 part of the standard distribution) may also help.
But... Well, in this case I just loved the Ruby way: If it does not hurt to cause surprises, then don't cause them! Keep a simple, portable definition, that will work with seconds or with fractions! Why not?
( categories: )

Objects and signals

Submitted by gwolf on Wed, 06/14/2006 - 19:44
So far, Ruby is the only language I have actually liked that imposes a mindset on you. I love Perl's approach of letting you do things your way, whatever you define by that - Ruby forces you to extensively use OOP. But, actually, it is so well implemented that it even makes sense. It is even fun! Of course, that paired to an excellent introspection ability leaves enough room to make the cleverest (and, yes, most obfuscated) code you can think of. Well... But there are limits to everything, and I think I found a spot where all the nice separation and cleanness ends abruptely: When interacting to the always nasty outside world. It might also, of course, have some relation to the fact that I'm too new also for writing GUIs - this is the first nontrivial one I do. And it shows, as it took me some time to properly understand the pairing between the nice Glade elements, how to make a decently modular system, how to properly handle UI (and internal) events... But I've been progressing quite nicely, and I hope to be able to show off my little app to a wider audience soon. At the very least, I hope to be able to show it to my boss by next week, as he is getting impatient ;-) Ok, but where does it all break, according to me? One of the things I must monitor with this app is that a couple of processes spawned by it work happily in the background while I only show a nice interface to my users. Now, how is the best way to do this? Why, by trapping the SIGCHLD signal, of course! Whenever any of the processes in the pipeline die, the parent (controlling) process gets a nice CHLD signal. I trap it, restart the processes, and no harm done. And in Ruby, it looks quite natural: [code="ruby"] Signal.trap(:CHLD) do @processes.each {|p| p.stop if; sleep 1; p.start} done [/code] How nice, how neat... How buggy :-/ It took me quite a few hours to get this right. And it should be obvious, of course... No matter where you declare a signal handler, there is no reason for you to believe it is tied to a particular instance, or for that matter, to a class. A signal handler breaks and jumps in the execution in the ugliest old-school way. Yes, if your signal handler consists of: [code="ruby"]Signal.trap(:CHLD) do { puts self.class }[/code] you will note that your good friend self is nothing but an Object. Once I realized that, yes, things became reworkable, and I now think I am actually better off even OOP-aly than some hours ago - Some of the classes badly needed to adhere to the Singleton pattern and now work with less worries and ugliness. But, hey, it took me quite a while. Anyway, lets see which new challenges Ruby+Glade2 still have for me. I am sure there will be plenty. And I haven't even started playing with GStreamer!
( categories: )

Comas is moving

Submitted by gwolf on Mon, 03/27/2006 - 13:09
Hi! This is Comas, the conference management system we all know and love! Perhaps you remember me from CONSOL 2004 and 2005, Debconf 5 and 6, CICOL, Seminario Globalización, Conocimiento y Desarrollo or other such great conferences! Well, it is a pleasure for me to announce I am moving. That's right - My developers have felt too constrained by CVS to keep being merry and productive, and decided to move away from it and to Subversion. If you are tracking my development history, you should have noticed a new file in my base CVS directory, called DONT_USE_THIS_REPOSITORY_ANYMORE. I will reproduce it here following Gunnar's wishes, and hoping it is useful to you.
PLEASE DON'T USE THIS REPOSITORY ANYMORE! Just in the meantime, while we migrate our current installations to point to the correct server, while our users take note, and while the kind GBorg admins lock down this project: PLEASE DON'T USE THIS REPOSITORY. WE HAVE MOVED. The Comas project will no longer be hosted at GBorg - We are moving to Debian's Alioth. Comas' webpage (although it is still ugly :) ) is still the same as always. The repository will no longer be handled through CVS - We switched to Subversion. Don't worry, the usage is basically the same. You can use anonymous access to get the Subversion tree. If you want to participate in the project, register at Alioth and ask us for commit access. You can also use the very nice SVN Web interface, which allows you to look at each of the files, view the changes, and even subscribe to the Comas RSS feeds! Development goes on. Stay tuned! Greetings, - Gunnar Wolf
Of course, as in any migration, there is still a lot of things to do. Mail the other contributors and interested people notifying them of the move. Migrate (and check the validity of) any tickets we have in the old site. Point all the places where there is Comas-related information to the new repository. Close the existing project page at GBorg. Sanely re-structure the repository in a more standard and functional way (and hope it does not break current installations ;-) ). Rework the documentation that has been neglected in the last months. Rework the bits of logic that never smelt very good but -as a dead rat- now positively stink. Fixe the things that will eventually stink as well... Anyway, I'm sure this will speed up my growth! I am very excited on which way my dear authors will continue to push me - I know I'm quite a lousy program for many things, and I know there is a lot for me to learn until I am a military-grade conference management system - But my many parents have written me with deep love, and I understand they had to write hastily parts of my code. I understand their mistakes, but I hope they make them go away soon.
( categories: )

No antialiased fonts here, thank you

Submitted by gwolf on Tue, 01/17/2006 - 10:00
Edd Dumbill writes from time to time about hinting or using the right fonts so they look nicer - At the first glance, I found three such articles in ~six weeks. I don't know if I'm too atypical in this area as well... But for most of my work, I prefer fonts not to be beautified by antialiasing. Strangely, it seems to depend on which program (or, maybe, activity) I am working - I have no grudge against antialiasing in a web browser, but I swear to God that if you antialias my emacs or my xterms, I will hate you. It just gets more tiring. I have no rational explanation for this - I just noticed the fact after using it for a while. I get more tired if the borders of the letters are not crisp - and I don't really care about the little details in smaller sized fonts. Maybe that's part of the reason antialiasing is nicer in the browser - After all, it is common to find text too small to read there. At 1280x1024 (or 1400x1050 on the laptop) with the usual font size, I get a nice 170x66 rxvt. That's quite OK for most of the work that requires attention - and for following large amounts of text, decreasing the font size to a somewhat tiring size gives me a nice 200x92 window - almost always enough room. Crisp fonts. Easy to read. Does anybody else feel the same, or am I just too looney?
( categories: )

Re: Tabs

Submitted by gwolf on Thu, 01/05/2006 - 10:59
Matt: Please don't forget you are talking about the language with the "there should be only one way to do it" motto, where you have to "program the way Guido indented it". I also feel much more at home where I can play with the way my program works and looks like. I like whitespace to be irrelevant - Yes, Python is a nice beast alltogether, but you cannot expect much space for personal preferences once you understand how it was designed. And yes, as a Perl guy I often hate the style some of the modules I maintain are written in, but then again... It's the most comfortable style for the main upstream author, the person who will do most work with the beast! ...But anyway... Emacs knows best. I just press tab and it works magically, either becoming a set of spaces or becoming a proper tab. And as long as other people understand what I wrote (which can become messy if some lines have supposedly eight-spaces-tabs and some are made up just of eight spaces), and specially the compiler doesn't barf at me, I'm OK with it. Using a decent editor helps you a lot when writing Python, YAML or such things..
( categories: )

First CPAN upload!

Submitted by gwolf on Wed, 06/15/2005 - 13:48
Some weeks ago, I registered via PAUSE as a CPAN author - I did this because I am a frequent user of the CPAN request tracker, because of the modules I maintain in Debian. But... Well, now that I am in there, why not clean up some of my own modules and, if they are somehow interesting/useful to the general public, upload them there as well? Well, as of today, I just became a CPAN contributor: I uploaded User::Simple, a simple user sessions management, much lighter to use than other tools I have seen, and not married to any particular framework (Well... Yes, it requires you to have a RDBMS, but can be used for any front-end you wish). Of course, I already filed an ITP for it, and you'll all be able to laugh at it from within a clean, nice Debian install quite soon.
( categories: )

mod_perl2 API madness

Submitted by gwolf on Thu, 05/12/2005 - 17:57
Yesterday was hellish. Apache might be the Free Software most notorious project. mod_perl is one of the best things that could happen both to the Perl and Apache communities. Apache2 is the largest Apache milestone, a major rewrite, and was declared golden almost three years ago. mod_perl, as it wraps the Apache C API and offers it to Perl, was expected to take some time to adapt to the new API and idiosincracy of this major version... Anyway, on to my life. I had some work to do on two systems I developed using mod_perl - the Comas one for Debconf and an internal project for the institute. Both stopped working on my development machine. Shit. Go to the logs - What do I find? [Wed May 11 12:04:03 2005] [error] [client] Can't locate object method "dir_config" via package "Apache2::RequestRec" at /usr/share/perl5/Apache/ line 51 Ok, this is clearly a mod_perl2 thingy... Things like this one had bitten me before, when I had to comment (and later uncomment) Apache::Upload. Oh, of course, then again some months ago, when I migrated from Apache 1.3 to Apache 2.0, when the nice mod_perl Apache2 migration wasn't really in sync with the reality... There have been a couple of episodes. After some stumbling, I came across the changelog. In my Sid system, it read:
(...) =item 1.999_22 - April 14, 2005 ******************** IMPORTANT ******************** this version of mod_perl is completely incompatible with prior versions of mod_perl, both 1.XX and 1.99_XX. Please read the below changes carefully. ***************************************************
Ok, that explains it... Although a big API change is not what I'd expect between version 1.999_21 and 1.999_22, right? The most upsetting thing is that my main development box is running Sid - And the servers I deploy on run Sarge... So I guess this means I'll have to set up a chroot environment so I can develop on my own workstation :-/ Ok, do some changes. It works on my Sarge machine, frozen at 1.999.21-1 - Everything looks fine. Send the module over to the Debconf server. Notify Apache of the changes. Reload, and... SHIT. Internal server error. I am not the machine's admin - Spend a couple of hours trying to locate the good folks in Finland, asking them to give me read access to the Apache logs. Meanwhile, try to blindly fix the problem. Of course, once I saw the log, it was obvious I couldn't have found it by myself:
(...) Can't locate object method "remote_ip" via package "Apache::Connection" at /home/gwolf/cvs/comas/perl/Apache2/ line 279
WTF?! Now, both machines are running Sarge, but Murphy couldn't just forgive me - At my machine I am running 1.999.21-1, but at Debconf's server we have 1.999.20-1 - And I couldn't get remote_ip to work. And no change regarding it is documented. Ok, fortunately I did not _really_ depend on it save for a feature I had just implemented, and was able to work around it... Anyway, it was a lost day, due to unexpected, practically not documented API changes, in what really seemed like a very minor update. For ${THAT}'s sake, a version bump of 0.000.01 for a completely incompatible version?!
( categories: )

Ternary operators, conditionals in the middle

Submitted by gwolf on Wed, 03/02/2005 - 11:54
Daniel Silverstone asked on our opinions on ternary operators, and as it seems his blog doesn't like comments (boo!). I just love them. I really like being as concise as possible, without being cryptic - I find it awful to say [code="C"]if (condition) var = val1; else var = val2;[/code] Not only it hides the real intention of your statement (you want to assign a value to var, not just to check for a condition), but it is much more error prone (when I typed the line the first time I did an assignment to var and one to val. Daniel says someone suggested the use of functions... Well, yes, sometimes a function would be fine, as in the classical example - I agree that [code="C"]var = max(val1, val2);[/code] is better than [code="C"]var = val1 > val2 ? val1 : val2;[/code] ...But that's hardly the most common case. Now, I know we Perl guys are seen by the rest of the world as bizarre creatures with the strangest sense of code grokking abilities... But I love how Perl allows us to show where emphasis is in our statements. For example, [code="Perl"]$result = 0 unless $success;[/code] shows the reader the important part in this statement is the assignment (which only happens if $success is true), while [code="Perl"]$success or $result = 0;[/code] is semantically equivalent, but puts the reader's attention on the fact we are checking for $success, and the assignment happens as a consequence of that. There is more to programming than letting the computer understand your intentions. Although it is often seen as a write-only language by speakers of other tongues, this level of expresiveness helps reading code. A lot. I happen to like Python quite a bit, but this limits it puts on the programmer always put me off while deciding on using it for a new project. BTW, back to ternary operators: It seems not many Perl programmers use them as often as I do, as for Perl6 there will be a language redesign involving operator Huffman-encoding (this means, the shortest and easiest-to-type operators will be the most common ones)... And the current ternary operator ( ? and : ) will be replaced by a more visible, more lengthy ones ( ?? and :: ) :-(
( categories: )

MD5 to be considered dangerous?

Submitted by gwolf on Wed, 12/08/2004 - 14:13
Today I found a quite disturbing mail sent to Bugtraq, in which Dan Kaminsky shortly describes a way to generate more than one file with the same MD5 hash, and links to a paper explaining it further. And if that were not enough, Pavel Machek sent another mail telling a little story and demonstrating Kaminsky's claims with a little story about a scam. I checked the files attached to his mail, and yes, we have two similar (but different) files with the same MD5 hash: [code="bash"]~$ md5sum /tmp/msg1 /tmp/msg2 ; diff --brief /tmp/msg1 /tmp/msg2 57ce330a6c6ca8e9ffab4f3b36b2a1a5 /tmp/msg1 57ce330a6c6ca8e9ffab4f3b36b2a1a5 /tmp/msg2 Files /tmp/msg1 and /tmp/msg2 differ [/code] This attack is still not practical for real scamming or supplantation. If we are signing files that will be processed by a computer (say, Debian packages, .tar.gz, ISO images, whatever), they will not be in a valid format to be installed. If, as in Machek's story, the files are to be human-parsed, there is too much cruft around the text for a human not to get suspicious. But anyway, this is a proof of concept, and it will surely be refined in the future... All hashing functions will somehow present collisions, I know. They must, however, not be artificially generable with choosable content. I am not a cryptologist, nor I claim I will ever be.. But anyway, probably we will end up losing confidence in MD5 hashes, in favor of another hashing algorithm. Directly signing/verifying the whole file is not quite feasible, as assymetric keys are just too heavy to do such work. However, the installed base and trust that MD5 currently has will be challenged... Let's see what comes out of this.
( categories: )
Syndicate content