Tag Archives: mail

avahi-autoipd Released and ‘State of the Lemur’

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/avahi-0.6.14.html

A few minutes ago I released Avahi 0.6.14
which besides other, minor fixes and cleanups includes a new component avahi-autoipd.
This new daemon is an implementation of IPv4LL (aka RFC3927, aka
APIPA), a method for acquiring link-local IP addresses (those from the range
169.254/16) without a central server, such as DHCP.

Yes, there are already plenty Free implementations of this protocol
available. However, this one tries to do it right and integrates well with the
rest of Avahi. For a longer rationale for adding this tool to our distribution
instead of relying on externals tools, please read this
mailing list thread
.

It is my hope that this tool is quickly adopted by the popular
distributions, which will allow Linux to finally catch up with technology that
has been available in Windows systems since Win98 times. If you’re a
distributor please follow these
notes
which describe how to integrate this new tool into your distribution
best.

Because avahi-autoipd acts as dhclient plug-in by default,
and only activates itself as last resort for acquiring an IP address I hope
that it will get much less in the way of the user than previous implementations
of this technology for Linux.

State of the Lemur

Almost 22 months after my first SVN commit to the flexmdns (which was the
name I chose for my mDNS implementation when I first started to work on it)
source code repository, 18 months after Trent and I decided to join our two
projects under the name “Avahi” and 12 months after the release of Avahi 0.1,
it’s time for a little “State of the Lemur” post.

To make it short: Avahi is ubiquitous in the Free Software world. 😉

All major (Debian, Ubuntu, Fedora, Gentoo, Mandriva, OpenSUSE) and many
minor distributions have it. A quick Google-based poll I did a few weeks ago
shows that it is part of at least 19 different
distributions
, including a range of embedded ones. The list of applications
making native use
of the Avahi client API is growing, currently bearing 31
items. That list does not include the legacy HOWL applications and the
applications that use our Bonjour compatibility API which can run on top of
Avahi, hence the real number of applications that can make use of Avahi is
slightly higher. The first commercial hardware appliances which include Avahi are
slowly appearing on the market. I know of at least three such products, one
being Bubba.

If you package Avahi for a distribution, add Avahi support to an
application, or build a hardware appliance with Avahi, please make sure to add
an item to the respective lists linked above, it’s a Wiki. Thank you!
(Anonymous registration without Mail address required, though)

avahi-autoipd Released and ‘State of the Lemur’

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/avahi-0.6.14.html

A few minutes ago I released Avahi 0.6.14
which besides other, minor fixes and cleanups includes a new component avahi-autoipd.
This new daemon is an implementation of IPv4LL (aka RFC3927, aka
APIPA), a method for acquiring link-local IP addresses (those from the range
169.254/16) without a central server, such as DHCP.

Yes, there are already plenty Free implementations of this protocol
available. However, this one tries to do it right and integrates well with the
rest of Avahi. For a longer rationale for adding this tool to our distribution
instead of relying on externals tools, please read this
mailing list thread
.

It is my hope that this tool is quickly adopted by the popular
distributions, which will allow Linux to finally catch up with technology that
has been available in Windows systems since Win98 times. If you’re a
distributor please follow these
notes
which describe how to integrate this new tool into your distribution
best.

Because avahi-autoipd acts as dhclient plug-in by default,
and only activates itself as last resort for acquiring an IP address I hope
that it will get much less in the way of the user than previous implementations
of this technology for Linux.

State of the Lemur

Almost 22 months after my first SVN commit to the flexmdns (which was the
name I chose for my mDNS implementation when I first started to work on it)
source code repository, 18 months after Trent and I decided to join our two
projects under the name “Avahi” and 12 months after the release of Avahi 0.1,
it’s time for a little “State of the Lemur” post.

To make it short: Avahi is ubiquitous in the Free Software world. 😉

All major (Debian, Ubuntu, Fedora, Gentoo, Mandriva, OpenSUSE) and many
minor distributions have it. A quick Google-based poll I did a few weeks ago
shows that it is part of at least 19 different
distributions
, including a range of embedded ones. The list of applications
making native use
of the Avahi client API is growing, currently bearing 31
items. That list does not include the legacy HOWL applications and the
applications that use our Bonjour compatibility API which can run on top of
Avahi, hence the real number of applications that can make use of Avahi is
slightly higher. The first commercial hardware appliances which include Avahi are
slowly appearing on the market. I know of at least three such products, one
being Bubba.

If you package Avahi for a distribution, add Avahi support to an
application, or build a hardware appliance with Avahi, please make sure to add
an item to the respective lists linked above, it’s a Wiki. Thank you!
(Anonymous registration without Mail address required, though)

Launchpad is Evil

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/launchpad-stole-my-name.html

I always think twice before entering my name in any web form or posting to a
mailing list. Is the web site/list respectable? Do the owners of the web site
have any commercial interest in my name (spam, marketing, …)? Would I ever
regret that my name can be found with Google in context with this web
site/mailing list? If I enter my name is it used for collecting data about me?
Is there any reasonable privacy policy?

Often enough I refrain from entering my name after deciding that the answers
to these questions are unsatisfactory. I like to be in control of my name. If I
am not confident that I remain in control I don’t enter my name to any
service.

Recently it came to my attention that Canonical decided to create an account (!) for me in their
commercial, proprietary bug tracker called “Launchpad”. I never asked for one!
I never even considered having one, because their service clearly is nothing
that would pass the tests mentioned above. They are a commercial service, my
account data is apparently “content” for them, they don’t seem to have any
privacy policy. (At least I couldn’t find any, the navigation is pretty
crappy.)

Canonical’s nimbus of being “the good guys” doesn’t hinder them to
incorporate data from free sources (apparently they got my data from the Debian
BTS) and make a commercial service of it, without even asking the original
contributors if that would be OK with them, or if it is OK to incorporate their
name or personal profile in the service. Apparently Canonical is not much
better than a common spam harvester: generating personal profiles for
business, without consent of the “victim”.

If anyone from Canonical reads this: It is not OK for me to use my name as
“content” for your commercial, proprietary service. Please remove any
reference to my name from your “account” database. I don’t want to have a
Launchpad account. I don’t plan to use Launchpad. Let me decide if I ever want to
join! Thank you very much.

Update: I especially dislike the fact that they created an account for me in
a service where Hitler apparently already has six (!) accounts. I am very sure
that I don’t want to be part of that community.

Launchpad is Evil

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/launchpad-stole-my-name.html

I always think twice before entering my name in any web form or posting to a
mailing list. Is the web site/list respectable? Do the owners of the web site
have any commercial interest in my name (spam, marketing, …)? Would I ever
regret that my name can be found with Google in context with this web
site/mailing list? If I enter my name is it used for collecting data about me?
Is there any reasonable privacy policy?

Often enough I refrain from entering my name after deciding that the answers
to these questions are unsatisfactory. I like to be in control of my name. If I
am not confident that I remain in control I don’t enter my name to any
service.

Recently it came to my attention that Canonical decided to create an account (!) for me in their
commercial, proprietary bug tracker called “Launchpad”. I never asked for one!
I never even considered having one, because their service clearly is nothing
that would pass the tests mentioned above. They are a commercial service, my
account data is apparently “content” for them, they don’t seem to have any
privacy policy. (At least I couldn’t find any, the navigation is pretty
crappy.)

Canonical’s nimbus of being “the good guys” doesn’t hinder them to
incorporate data from free sources (apparently they got my data from the Debian
BTS) and make a commercial service of it, without even asking the original
contributors if that would be OK with them, or if it is OK to incorporate their
name or personal profile in the service. Apparently Canonical is not much
better than a common spam harvester: generating personal profiles for
business, without consent of the “victim”.

If anyone from Canonical reads this: It is not OK for me to use my name as
“content” for your commercial, proprietary service. Please remove any
reference to my name from your “account” database. I don’t want to have a
Launchpad account. I don’t plan to use Launchpad. Let me decide if I ever want to
join! Thank you very much.

Update: I especially dislike the fact that they created an account for me in
a service where Hitler apparently already has six (!) accounts. I am very sure
that I don’t want to be part of that community.

MSI S270 Laptop Linux Kernel Driver

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/s270-kernel.html

Earlier this year I worked on reverse engineering the
brightness control of my MSI
S270 laptop
. Turning this work into a proper kernel driver was still left
to be done. Until yesterday… The result of yesterday’s work are two kernel patches I already posted
for upstream inclusion.

If you want to test these drivers, download the latest kernel patches:

acpi-ec-transaction.patch
acpi-s270.patch

The two patches apply to kernel 2.6.17. After patching activate “MSI S270
Laptop Extras” under “Device Drivers”/”Misc devices” and recompile and install.
After loading the s270 module, you now have a backlight class driver
exposing its innards in /sys/class/backlight/s270bl/. For
changing the screen brightness issue as root:

echo 8 > /sys/class/backlight/s270bl/brightness

This will set the screen brightness to maximum. The integer range is 0..8.

In addition to this backlight class driver we export a platform driver which
allows reading the current state of the WLAN/Bluetooth subsystem. The platform
drivers also allows toggling the automatic brightness control feature:

cat /sys/devices/platform/s270pf/wlan # Show WLAN status
cat /sys/devices/platform/s270pf/bluetooth # Show Bluetooth status
echo 1 > /sys/devices/platform/s270pf/auto_brightness # Enable automatic brightness control

If the driver refuses to load (returning ENODEV) and you are sure you have
an MSI S270 the machine is probably not recognized correctly by its DMI data.
In that case you can pass force=1 to the driver which will force the
driver load even when the DMI data doesn’t match. YMMV. If everything works
correctly please make sure to send me the output of dmidecode, so that
I can add the DMI data to the list of known laptops in the driver.

There might even be a chance that this driver works on other MSI laptop
models, too (such as S260). YMMV. But don’t come running when the driver causes
your machine to explode! MSI laptops such as the S270 or S260 are often sold as
OEM hardware under different brands (such as Cytron/TCM/Medion/Tchibo MD96100
or “SAM2000”), so if your laptop looks remotely like this one and dmidecode |
grep MICRO-STAR yields at least a single line, and you are adventurous
than you might want to test this driver on it. And don’t forget to send me your
dmidecode output if it works for you!

Unfortunately HAL (at least in my version 0.5.7) doesn’t support the generic
backlight device class yet, which means no gnome-power-manager support
for now.

Although this driver is based on reverse engineered data it should be
legally safe even in the US. After I did my initial work on the S270 controls
MSI supplied me with a register table of their ACPI Embedded Controller
(which is what this driver interfaces with) and one of their engineers even
tested my work.

Last but not least I created a mailing list for
discussion of Linux on the MSI S270
. Please join if you run Linux on one of
these machines! I will announce future driver work for the S270 there.

MSI S270 Laptop Linux Kernel Driver

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/s270-kernel.html

Earlier this year I worked on reverse engineering the
brightness control of my MSI
S270 laptop
. Turning this work into a proper kernel driver was still left
to be done. Until yesterday… The result of yesterday’s work are two kernel patches I already posted
for upstream inclusion.

If you want to test these drivers, download the latest kernel patches:

  1. acpi-ec-transaction.patch
  2. acpi-s270.patch

The two patches apply to kernel 2.6.17. After patching activate “MSI S270
Laptop Extras” under “Device Drivers”/”Misc devices” and recompile and install.
After loading the s270 module, you now have a backlight class driver
exposing its innards in /sys/class/backlight/s270bl/. For
changing the screen brightness issue as root:

echo 8 > /sys/class/backlight/s270bl/brightness

This will set the screen brightness to maximum. The integer range is 0..8.

In addition to this backlight class driver we export a platform driver which
allows reading the current state of the WLAN/Bluetooth subsystem. The platform
drivers also allows toggling the automatic brightness control feature:

cat /sys/devices/platform/s270pf/wlan                 # Show WLAN status
cat /sys/devices/platform/s270pf/bluetooth            # Show Bluetooth status
echo 1 > /sys/devices/platform/s270pf/auto_brightness # Enable automatic brightness control

If the driver refuses to load (returning ENODEV) and you are sure you have
an MSI S270 the machine is probably not recognized correctly by its DMI data.
In that case you can pass force=1 to the driver which will force the
driver load even when the DMI data doesn’t match. YMMV. If everything works
correctly please make sure to send me the output of dmidecode, so that
I can add the DMI data to the list of known laptops in the driver.

There might even be a chance that this driver works on other MSI laptop
models, too (such as S260). YMMV. But don’t come running when the driver causes
your machine to explode! MSI laptops such as the S270 or S260 are often sold as
OEM hardware under different brands (such as Cytron/TCM/Medion/Tchibo MD96100
or “SAM2000”), so if your laptop looks remotely like this one and dmidecode |
grep MICRO-STAR
yields at least a single line, and you are adventurous
than you might want to test this driver on it. And don’t forget to send me your
dmidecode output if it works for you!

Unfortunately HAL (at least in my version 0.5.7) doesn’t support the generic
backlight device class yet, which means no gnome-power-manager support
for now.

Although this driver is based on reverse engineered data it should be
legally safe even in the US. After I did my initial work on the S270 controls
MSI supplied me with a register table of their ACPI Embedded Controller
(which is what this driver interfaces with) and one of their engineers even
tested my work.

Last but not least I created a mailing list for
discussion of Linux on the MSI S270
. Please join if you run Linux on one of
these machines! I will announce future driver work for the S270 there.