ZeroDev

After (about) two long months, finally i'm back online,
"new" house[1], my "old" adsl connected again.

[1] For the record: after a long search, i moved to another house

Maybe it's old/or and documented[1] but yesterday i was looking for an easy
way to serve static files (for istance css,images,etc.) with Django using the development webserver.

After a quick search i found a solution
(ok maybe it's not the _best_ way to do it but works4me!).
Say that you want to serve images and css in with two different path,
add the following:

settings.py:

#[..]
STATIC_IMG_ROOT = '/fullpath/to/mycontent/img/'
STATIC_CSS_ROOT = '/fullpath/to/mycontent/css/'
#[..]


urls.py:

#[..]
(r'^img/(?P<path>.*)$', 'django.views.static.serve',
{'document_root': settings.STATIC_IMG_ROOT}),

Now in your templates you can link to images and css via:

[..] awesome_header.png" width="137" height="121" [..]

and

[..] rel="stylesheet" type="text/css" href="css/main.css" [..]


Remember to disable these settings in settings.py and urls.py when you are going in production.

[1] http://docs.djangoproject.com/en/1.0/howto/static-files/

Today finally i figured out why with the latest tuxonice kernel
(>=sys-kernel/tuxonice-sources-2.6.26) i wasn't able do a resume
after hibernate (aka suspend to disk).

Currently i'm using:

• sys-kernel/tuxonice-sources-2.6.28-r1
• sys-power/hibernate-script-1.99
• sys-apps/tuxonice-userui-0.7.3

So i unpacked my initrd, i need it because of my current setup, it was done
with genkernel (the kernel is compiled manually) and then i discovered that
the problem was caused by a "missing" statement in my grub config:
real_resume=/foo/bar

Seems like that real_resume= is treated like the resume= statement, i have no idea why, maybe to assure backward compatibility with suspend2 and swsusp.

Anyway update your bootloader configuration and enjoy back the hibernate support.

UPDATE:
after an additional search on bugzilla i found that the "real_resume=" problem was reported here

...with multiple servers and server role ROLE_DOMAIN_PDC

Well,
finally i have an adsl connection, so it's time to sort up things and provide a link between
my desktop pc (Thunder) in my bedroom and the adsl router (Zyxel 660HW) placed in the living room (unluckily the only RJ-11 plug resides there).

The only solution is a wireless link, i can't cable this house, so i went out on saturday and purchased the only wireless pci card available, a D-Link G510 rev B.
(and i was happy because i saw a nice-tuxed-logo "Linux Support" on that card box).

Once returned at house i plugged the new card and fired up an lspci, and i learn a terrible thing:

05:08.0 Network controller: RaLink RT2561/RT61 rev B 802.11g

OH NOES! a ralink chipset!!!
the same vendor who drived me crazy in the past with the DWL-G122 (usb adapter, rt73 driver)

I spent the last to days testing various drivers:
- net-wireless/ralink-rt61 (the original ralink driver)
- net-wireless/rt61 (the legacy reworked driver from serialmonkey)
- the rt2x00 no more in portage because was merged in the linux kernel starting with 2.6.24

I only focused on a wpa-psk/wpa2-psk setup (i don't mind to run the wireless link with wep or without encryption at all), but it was a steaming pile of failures...
wpa_supplicant is not supported by both net-wireless/ralink-rt61 and net-wireless/rt61, 'cause they use a strange set of commands available via iwpriv,
the recently merged in to kernel rt2x00 driver instead supports it but had several problems when used with wpa/wpa2 (is still an experimental driver written from scratch to support all the ralink chipsets), i tested several kernels patches, and snapshots but nothing...

(uhuh someone said ndiswrapper? nevermind i'm on amd64 and there are not 64bit drivers for this chip by d-link)

So atm i resumed my fonera, updated it to DD-WRT v24 std., and configured the client bridge mode (it works fine in this release) and all it's working like a charm with wpa2-psk......this time i learned the lesson, in the future i will never buy again another D-Link/Ralink adapter...

NEVER!