I know that this is not the recommended way of configuring HTTP+HTTPS, but having two separate sections when the configuration is the same except for 3 lines (server certificates and listen 443) doesn’t make much sense.

I initially followed the official tutorial (most likely outdated) and added a part relative to PHP files

server {
    listen 80;
    listen 443 ssl;
    server_name domain.ext;
    ssl_certificate domain.crt;
    ssl_certificate_key domain.key;

    # ... rest of the configuration

    # PHP stuff
    location ~ \.php$ {
    include fastcgi_params;
    fastcgi_intercept_errors on;
    fastcgi_pass 127.0.0.1:9001;
    # Fixes random Bad gateway errors
    fastcgi_buffer_size 128k;
    fastcgi_buffers 4 256k;
    fastcgi_busy_buffers_size 256k;
    fastcgi_temp_file_write_size 256k;
    }
}

Everything worked smoothly on two computers running Ubuntu 10.04 + Nginx and PHP-fpm from the Nginx PPA. I then tried to do the same on Ubuntu 11.10 and PHP-fpm installed from the official repositories: all hell broke lose.

All of a sudden the $_GLOBALS["HTTPS"] variable was not defined anymore even on secure connections. Setting such variable is an Apache specific behaviour, in all truth, but like most of the rest of the PHP community I learned to rely on it for secure connection detection.

Most of the guides I found online referred to setting the HTTPS variable explicitly in the appropriate server section via the fcgi_param directive, but I didn’t want to have two completely separate configuration sections.

I then resorted to a hybrid, which makes use of dual server sections and one include file.

The configuration file looks like this:

# Nginx config file

# HTTP server section
server {
    listen 80;
    include domain.inc;
}

# HTTPS server section
server {
    listen 443 ssl;
    server_name domain.ext;
    ssl_certificate domain.crt;
    ssl_certificate_key domain.key;
    include domain.inc;
    fcgi_param HTTPS on;
}

The include file looks like this:

# Nginx include file: domain.inc

# ... rest of the configuration

# PHP stuff
location ~ \.php$ {
    include fastcgi_params;
    fastcgi_intercept_errors on;
    fastcgi_pass 127.0.0.1:9001;
    # Fixes random Bad gateway errors
    fastcgi_buffer_size 128k;
    fastcgi_buffers 4 256k;
    fastcgi_busy_buffers_size 256k;
    fastcgi_temp_file_write_size 256k;
}

… and the magic is done!

• the Windows 7 installer shows the blue background after “Starting Windows”
• You are still able to move the mouse pointer
• You do not actually have and FDD (Floppy Disk Drive)

Reset your computer, enter the BIOS, and check that your settings regarding FDDs are set to “Disable” (or “None”, depending on the BIOS).

It’s as stupid as it sound and it cost me 30 minutes.

Requirements:

• A computer running FreeNAS 8.0
• SSH access to said computer and root privileges
• A volume with a few megabytes free to download the packages
• A working internet connection

How does this work?

When installing FreeNAS 8.0 on a USB drive (at least when using dd to write the disk image), the UFS image used to mount the root partition has about 22 MiB free. Since MLDonkey (without GUI, made exception for the integrated web-server) and its dependencies require roughly 11 MiBs, there is more than enough space to install it.

Howto:

1. Login in your FreeNAS box as root (the password is the same that you set for the admin user)
2. Change directory to the one that will contain the downloaded files

   cd /path/to/directory/

3. Download this script (code shown below) by running

   fetch http://nexus.thenexus.it/install_mldonkey_freenas8.sh

   Please note that the script has been written by a lazy-bum (myself) and there is no error checking! Any improvements to the script are welcome.

4. Execute the script you just downloaded by running

   sh install_mldonkey_freenas8.sh

5. MLDonkey is now installed, you can launch it by typing mlnet, further information and guides vailable at

Note:

At the time of writing the available packages were the following:

• net-p2p/mldonkey-core-3.0.6
• graphics/jpeg-8_3
• graphics/gd-2.0.35_7,1

You might need to change the file names appearing in the howto according to new releases.

The script’s code

#!/bin/bash

ARCH=`uname -m`
MACHINE=`uname  -r | cut -d- -f1-2 | awk '{print tolower($0)}'`
SERVER=ftp://ftp.freebsd.org
ROOTDIR=/pub/FreeBSD/ports

fetch ${SERVER}${ROOTDIR}/${ARCH}/packages-${MACHINE}/graphics/jpeg-8_3.tbz
fetch ${SERVER}${ROOTDIR}/${ARCH}/packages-${MACHINE}/graphics/gd-2.0.35_7,1.tbz
fetch ${SERVER}${ROOTDIR}/${ARCH}/packages-${MACHINE}/net-p2p/mldonkey-core-3.0.6.tbz

mount -o rw -t ufs /dev/ufs/FreeNASs1a /
pkg_add jpeg-8_3.tbz gd-2.0.35_7,1.tbz mldonkey-core-3.0.6.tbz
mount -o ro -t ufs /dev/ufs/FreeNASs1a /

A damn mess... (This picture is somebody else's, but I couldn't find the author. All credits to him/her)

Things have always been a little confusing on the software side: depending on the operating system there is the chance to have software mixers performing the same task as the hardware one, but they usually require applications to explicitly support their API/communication protocol (e.g. JACK on Linux).

Furthermore, even in the case that the audio protocol is standard for the whole system, the application may not support per-caller streaming, which makes editing and mastering the levels in post-production extremely hard (although there are some tools, such as Levelator, that help in the task).

Now we all have an open-source, multi-platform alternative (runs on Linux, MacOS, Windows), and its name is Mumble.

Mumble is born as an open-source, standards-based, low-latency, high-quality Voice-over-IP communication tool for gamers: as opposed to common alternatives such as Ventrilo, Skype and TeamSpeak that are instead closed-source (TeamSpeak had a particularly bad history of slow upgrades).
While open-source is nice and everything, Mumble was not better suited than the rest of the pack when it came to podcasting, it actually was a little worse than some of the competition (there are multiple plugins for Skype that allow call recording).

But Mumble does now have a trump card to play: since version 1.2.3 it allows to record the conversations going on a channel in a server, either as a mixdown (one file for the whole conversation) or using one file per participant.

Notice the "Multichannel" option, that is what we all waited for!

Not only that, but multiple recording formats are supported: PCM uncompressed (wave), AU uncompressed, FLAC lossless compression, and OGG lossy compression.

There is even FLAC for all of us audiophiles.

The beauty of it all is that such freedom of choice also allows older, or low-power systems to be used as recording stations; while one would require a fairly powerful system to record a party of 10 in FLAC, I was able to record an OGG compressed multi-channel discussion between me and a friend on a 1.5 GHz Pentium-M with lots of headroom.

Now, thought, I have a goo reason to write. It is the time for truth.

What truth? Simple, it is time to know whether Italy is a democracy, and if law applies equally to everyone. It is also the time to discover how stupid, or hypocrites, Italians are.

Il buttasù collettivo

A quando le dimissioni di Nicole Minetti?

Il regno delle chiamate: Rubbi Troia

Nicole Minetti, adesso dimettiti!

“Ho ridato prestigio ed autorevolezza all’Italia in sede internazionale”

News arrive even here in Korea…

 Teenager: Berlusconi gave me 7000 Euros  

Prosecutors; Berlusconi had many prostitutes

“Researcher Vinay Deolalikar from HP Labs claims proof that P != NP. The 100-page paper has apparently not been peer-reviewed yet, so feel free to dig in and find some flaws. However, the attempt seems to be quite genuine, and Deolalikar has published papers in the same field in the past. So this may be the real thing. Given that $1M from the Millennium Prize is involved, it will certainly get enough scrutiny. Greg Baker broke the story on his blog, including the email Deolalikar sent around.”

If this is true, we have one of the most incredible and revolutionary discoveries of the last decennia.

Potete seguire il feed RSS all’indirizzo qui sotto.
http://nexus.thenexus.it/wordpress/podcast/feed/

In alternativa potete fare riferimento al sito di blip.tv, al seguente indirizzo.
http://intothenexus.blip.tv

Speechless.

Facendo una citazione forse inappropriata: “ed ora, per qualcosa di completamente diverso…”

Ecco a voi la prima intervista di “Into the NeXuS”. Ospite odierno mr. Valentino Berto, bassista eccezionale dei “Silenzio è sexy” e “Le cellule dormienti”, nonchè amico di lungo corso del sottoscritto.
Insieme a Valentino scopriremo i “Silenzio è Sexy”, ripercorreremo la sua carriera artistica e faremo quattro chiacchiere davanti ad una birra virtuale sulla distribuzione commerciale della musica al giorno d’oggi.

Con questa puntata introduco anche una nuova forma di scaletta, spero più chiara della precedente: gli argomenti trattati sono marcati da punti, mentre i brani musicali sono numerati progressivamente.

• Intro

1. Rein – Il deserto di Piero

• Intervista – Parte Prima

2. Silenzio ̬ sexy РCi vuole pazienza

• Intervista – Parte Seconda

3. Silenzio ̬ sexy РNostalgia goodbye

Audio only: Download MP3

Into The NeXuS – 02×01 – Live!

Scarica il file video in formato Flash.

Scarica l’MP3 della trasmissione.

NOTA: L’audio del video (lo so, che giro di parole) e’ ancora quello orginale, molto basso. A presto un nuovo video con audio rimsterizzato (come fa fico!).

Io sto con Emergency.

Ho incominciato a scrivere questo artiocolo (il titolo, per l’esattezza) il giorno del mio compleanno, il 7 Aprile. Oggi e’ il 15 e sto scrivendo le prime parole. Il post sara’ comunque datato al 7, potenza della tecnologia.

Ebbene si’, e’ l’anno 2010 e come tutti i nati nel 1980 (che anno!) oggi compio 30 anni. 30 anni e non sentirli, a volte, o sentirli troppo tal’altre. 30 anni che sono passati in fretta, troppo in fretta, tanto in fretta che faccio fatica a ricordare i momenti migliori. E’ buffo come la mente umana si fossilizzi, tranne in rari fortunatissimi casi, sui ricordi piu’ brutti, su quelle cose che lasciano i segni piu’ profondi, solo per poi arrivare alla fine della via e domandarsi: “Ma chi me l’ha fatto fare di rovinarmi la vita da solo?”.

Dato che anche io faccio parte della schiera dei non-fortunati, e che per tradizione genetica-familiare son tendente alla depressione, mi costa uno sforzo infinito guardare avanti invece che indietro, concentrarmi su cio’ che di bello ho, invece su ciò che di (più) bello vorrei avere.

Eppure questi trent’anni sono stati segnati da un evento felice: sono infatti uomo accasato da 20 Febbraio di quest’anno. E’ stata una scelta ragionata, ma, come tutte le grandi scelte della vita, non senza qualche dubbio, che tutt’ora permane. Tutto stara’ alla mia capacita’ di pensare in positivo e guardare avanti.

Se poi proprio dovessi dirla tutta avevo pensato di iniziare questo post parlando dei fiori di ciliegio (l’albero, sakura in giapponese, qui si chiama 벚나무 [beotnamu], il bocciolo/fiore 벚꽃 [beotgot]) che ho avuto la fortuna di vedere per la terza volta. Non me ne rendo neanche conto, ma sono già passati tre anni da quando sono approdato in questa buffa terra, quasi per sbaglio, con la sensazione che il Giappone fosse così vicino ed invece…

Ed i fiori di ciliegio, sbocciati da appena una settimana o poco più, sono già caduchi, bellezze di breve vita come le farfalle. Ma sboccerano nuovamente l’anno prossimo e quello seguente ancora, ed io forse avrò modo di conoscere di persona tutte quelli che, come fiori di ciliegio, hanno visitato questo blog e mi hanno scritto per chiedermi qualcosa a proposito della Corea e della mia esperienza in questo paese (di cui noi italiani sappiamo così poco) per poi sparire nel nulla.

Via ByoBlu

I have been lazily following the Go language project for a while now, when it
was suddenly discussed in this post of “Appunti Digitali” (in italian), that
pointed at this post
on Dalke Scientific.

It really got me that S.Python manages to beat Go so
badly, so I decided to run my own tests on my trusty old IBM X-41 (Pentium-M 1.5
GHz).

I compiled the Go toolchain and S.Python, then ran the
test exactly as I found them on the Dalke page. The results are following
hereby:

$ time ./8.out
100000

real 0m5.197s
user 0m1.508s
sys 0m1.352s

$ time
/usr/local/bin/python2.6 test.py
100000

real 0m3.315s
user 0m1.556s
sys 0m0.148s

What really struck me is that
the time spent in userland is roughly the same for both programs. What really
kills the Go execution time is that it spends almost as much time in kernel
mode. I wondered why…

Then I remembered that, in the Google Tech Talk,
Pike said something about the Go runtime managing threads for the user, and I
automatically thought that it would associate user threads with OS threads in
some way (as is the norm). In fact that is what gccgo does (uses NTPL).

On
the other hand, reading Stackless Python documentation, I found this page
regarding Tasklets. The page clearly states: “Tasklets are
characterized by being very lightweight and portable, and make great
alternatives to system threads or processes.”

So I am prone to believe
that S.Python Tasklets are managed by the Python VM itself, requiring no
user-to-kernel mode transitions and no other kernel interaction… because they
are not real threads (as opposed to Go goroutines).

This, with the fact
that Go is mainly intended to cut compile time (not so much running
time), makes me believe the comparison to be pretty unfair, and I think Go
provides quite a performance!

Regarding certain unsafe situations, they
are definitely a problem. Still, I believe that they will be taken care of
quickly: Go is a brand new language and rough edges are to be expected here and
there, but it has quite some room for growth.

Update:

I modified the test program so that each goroutine/Tasklet calls a second
function that loops 1000 times and cumulates the result of “sum = sum+1″.

The results are as expected: the compiled code is one order of magnitude faster
than Stackless Python interpreted code! I also replaced range with xrange, as suggested by Cesare
Di Mauro, but that did not change things much… nor did it when I tried psyco
(a JIT compiler for Python).


$time ./test2 && time /usr/local/bin/python test2.py
100000

real 0m19.567s
user 0m15.697s
sys 0m0.160s


The source code for Python is:
default=100000)

stackless.tasklet(main)()
stackless.run()


And the test code for Go is:
"fmt";
)

func main() {
flag.Parse();
leftmost := make(chan int);
var left, right chan int = nil, leftmost;
for i := 0; i < *ngoroutine; i++ {
left, right = right, make(chan int);
go f(left, right);
}
right <- 0; // bang!
x := <-leftmost; // wait for completion
fmt.Println(x); // 100000
}