Engel, my computer, just freezed. Even Linux hangs sometimes without reason but there's nothing wrong with this, I'm going to check it later.

After this introduction, I must say that everything rebooted fine again but RSSOwl, which seems to be broken, yields a "nice" error everytime I start it: "Read past EOF". It was updating feeds just before the hang.

The way to go with this is so simple but there isn't any trace about. Just copy your subscriptions*.opml files from $HOME/.rssowl2 and delete this folder.

By the way, it's curious that Google doesn't throw any result for this error with RSSOwl in the query. Instead, the error itself seems to be from Lucene.

Shine on you, crazy owl.

Warning: some links go to content in spanish, sorry. And that's my opinion. You can agree or not, you are free!

Today is bad day for the spanish Digg-like Menéame (Shake me). The admins are banning hundreds of users in a tyranic way because these users didn't agree with the decision of one admin, Perl, to ban one of the most active users, MMPET.

This user did a post protesting for some admin attitude. And he was banned for this and publishing a list of public negative voters.

By the way, I'm one of the banned users, of course. I did everything to get banned as protest measure. And I was banned, after posting some troll-like news. That's absolutely right and I assume my actions. I know I provoked them.

That's price to advocate in favour of freedom. I think that nobody can allow to be banned with poor reasoning: MMPET was a very active user and he had been banned for suspicious microblogging, which is not allowed in Menéame, but it didn't matter when sometimes a clearly microblogging new achieved the front page. The real reason, as you can see here

In the net, there is a lot of info about it flowing everywhere, like Twitter, Meneame itself, some other blogs including MMPET's blog, etc.

There is a curious fact. There had been two big waves of banning actions. The second, after a few hours of calm peace, only broke by the trolling news (some mine) in the queue list, had been bloody. They banned more very popular users, just to be against them.

Of course, we can't deny the other side. Here you have the official answer from Menéame's blog.

Actually, it was something that everybody felt in the air (not in a phsycial way, of course). A lot of news were sunken by negative votes from the admins. A lot of arguments, flames, bad manners from everyone, etc.

It's a shame, because it was a great site but this is Internet and the show must go on. New possibilities are available, like Apezz, which seems to be down by the rush of users coming from Menéame, Digg, Reddit, etc.

For more information, check all the links and this one.

Sometimes democratic web goes wrong. Welcome to BAN DAY.

Working on a little tool for me in JRuby/Ruby I found a nasty message while trying to get up the Webrick HTTPServer:

[2009-03-26 22:53:56] INFO WEBrick 1.3.1
[2009-03-26 22:53:56] INFO ruby 1.8.6 (2009-03-16) [java]
[2009-03-26 22:53:56] WARN TCPServer Error: initialize: name or service not known
/home/dario/software/opt/jruby-1.2.0/lib/ruby/1.8/webrick/utils.rb:73:in `new': initialize: name or service not known (SocketError)
from /home/dario/software/opt/jruby-1.2.0/lib/ruby/1.8/webrick/utils.rb:73:in `create_listeners'
from /home/dario/software/opt/jruby-1.2.0/lib/ruby/1.8/webrick/utils.rb:70:in `each'
from /home/dario/software/opt/jruby-1.2.0/lib/ruby/1.8/webrick/utils.rb:70:in `create_listeners'
from /home/dario/software/opt/jruby-1.2.0/lib/ruby/1.8/webrick/server.rb:75:in `listen'
from /home/dario/software/opt/jruby-1.2.0/lib/ruby/1.8/webrick/server.rb:63:in `initialize'
from /home/dario/software/opt/jruby-1.2.0/lib/ruby/1.8/webrick/httpserver.rb:24:in `initialize'
from src/main.rb:26

After googling for a while, I didn't find anything about how to solve it. So, I gave a try to MRI, which throw me this trace:

[2009-03-26 22:48:24] INFO WEBrick 1.3.1
[2009-03-26 22:48:24] INFO ruby 1.8.7 (2008-08-11) [i686-linux]
[2009-03-26 22:48:24] WARN TCPServer Error: Permission denied - bind(2)
[2009-03-26 22:48:24] WARN TCPServer Error: Permission denied - bind(2)
/usr/lib/ruby/1.8/webrick/utils.rb:73:in `initialize': Permission denied - bind(2) (Errno::EACCES)
from /usr/lib/ruby/1.8/webrick/utils.rb:73:in `new'
from /usr/lib/ruby/1.8/webrick/utils.rb:73:in `create_listeners'
from /usr/lib/ruby/1.8/webrick/utils.rb:70:in `each'
from /usr/lib/ruby/1.8/webrick/utils.rb:70:in `create_listeners'
from /usr/lib/ruby/1.8/webrick/server.rb:75:in `listen'
from /usr/lib/ruby/1.8/webrick/server.rb:63:in `initialize'
from /usr/lib/ruby/1.8/webrick/httpserver.rb:24:in `initialize'
from src/main.rb:26:in `new'
from src/main.rb:26

Ok, it wasn't that hard. I was trying to start up a server, which defaults to port 80, as non-privileged user under Linux.

Actually, it was a little headache but given the poor results found, I decided to report this to JRuby project as an improvement.

In the last days, at work, while deploying our Java servlet-based application we got the following exception's message:

java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

The full stacktrace doesn't matter, really. That was the root-cause of everything and we couldn't deploy anything. So, what is the meaning of this?

After doing some search, we did't find an absolute answer. They were all about "I did and it works now", nothing that solved our problem.

Then, we checked everything in application's files and we found that our trustStore (with certificates), which path is defined in Java property "javax.net.ssl.trustStore", wasn't there! Just moved it where it belongs and it worked!

So, the meaning is: Those anchors are empty because I don't have a valid trustStore to load. Easy, right?

Hay ocasiones en que algún programa (llamémosle Microsoft Word 2003, para preservar su intimidad) en que hacen cosas extrañas, como borrar un fichero de una memoria flash sin motivo alguno.

Y así, luego llaman al vecino informático para que lo recupere.

En ese instante, tú, el vecino informático, te preguntas: ¿Cómo? Las sinapsis saltan y, en un rincón de tu cerebro, una neurona ávida de dar respuestas te recuerda una web: PhotoRec.

Sabes que no la has usado nunca, pero... de perdidos al río. Vas a la web y parece que lo puedes conseguir. Tras bajarlo y usarlo, recuperas el fichero perdido, siguiendo las instrucciones de la documentación.

Por increíble que parezca, PhotoRec es de uso sencillo: sólo debes saber seleccionar la opción correspondiente, guiado por el mismo asistente.

Conclusión: un vecino tranquilo porque no ha perdido horas de trabajo y tú, vecino informático, satisfecho de saber que dispones de una herramienta potente, multiplataforma y que cubre un gran número de sistemos de ficheros para esos casos, propios o ajenos, en los que necesitas recuperar un fichero.

Puntuación: 5 sobre 5.

While trying to setup nginx + php-fpm (PHP with Fastcgi Process Manager) following this post from Homo-Adminus Blog, I got a vexing error: "No input file specified".

After searching through my system logs (an Arch Linux box), I found the following message in /var/log/everything.log:

Oct 18 18:08:27 engel php-cgi: PHP Warning: Unknown: open_basedir restriction in effect. File(/etc/nginx/html/hello.php) is not within the allowed path(s): (/home/:/tmp/:/usr/share/pear/) in Unknown on line 0

Once I changed the open_basedir in /etc/php/php.ini to the correct value, it worked flawlessly.

I hope this post can help to everybody who can find themselves in the same quest to get nginx+php-fpm setup to work.

Just a quick note for my first internationals readers from USA: welcome to my blog (Google Analytics told me about you *wink*).

Byte Fo-ji is intended to collect ideas, projects, serendipities, etc. I started this with xnikt, my little refactoring XSD tool, and reviewing a nice cross-platform and cross-DB Java tool, SQuirreL SQL Client.

I hope you find useful some post and receive your feedback about everything.