systemd Status Update

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

It has been a while since my original
announcement of systemd
. Here’s a little status update, on what
happened since then. For simplicity’s sake I’ll just list here what we
worked on in a bulleted list, with no particular order and without
trying to cover this comprehensively:

systemd has been accepted as Feature for Fedora 14, and as it
looks right now everything worked out nicely and we’ll ship F14 with
systemd as init system.

We added a number of additional unit types: .timer for
cron-style timer-based activation of services, .swap exposes
swap files and partitions the same way we handle mount points, and
.path can be used to activate units dependending on the
existance/creation of files or fill status of spool directories.

We hooked systemd up to SELinux: systemd is now capabale of
properly labelling directories, sockets and FIFOs it creates according
to the SELinux policy for the services we maintain.

We hooked systemd up to the Linux auditing subsystem: as first
init system at all systemd now generates auditing records for all
services it starts/stops, including their failure status.

We hooked systemd up to TCP wrappers, for all socket connections
it accepts.

We hooked systemd up to PAM, so that optionally, when systemd runs
a service as a different user it initializes the usual PAM session
setup and teardown hooks.

We hooked systemd up to D-Bus, so that D-Bus passes activation
requests to systemd and systemd becomes the central point for all
kinds of activation, thus greatly extending the control of the
execution environment of bus activated services, and making them
accessible through the same utilities as SysV services. Also, this
enables us to do race-free parallelized start-up for D-Bus services
and their clients, thus speeding up things even further.

systemd is now able to handle various Debian and OpenSUSE-specific
extensions to the classic SysV init script formats natively, on top of
the Fedora extensions we already parse.

The D-Bus coverage of the systemd interface is now complete,
allowing both introspection of runtime data and of parsed
configuration data. It’s fun now to introspect systemd with gdbus
or d-feet.

We added a systemd
PAM module
, which assigns the processes of each user session to
its own cgroup in the systemd cgroup tree. This also enables reliable
killing of all processes associated with a session when the user logs
out. This also manages a secure per-user /var/run-style directory
which is supposed to be used for sockets and similar files that shall
be cleaned up when the user logs out.

There’s a new tool systemd-cgls,
which plots a pretty process tree based on the systemd cgroup
hierarchy. It’s really pretty. Try it!

We now have our own cgroup hierarchy beneath
/cgroup/systemd (though is will move to /sys/fs/
before the F14 release).

We have pretty code that automatically spawns a getty on a serial
port when the kernel console is redirected to a serial TTY.

systemctl got beefed up substantially (it can even draw
dependency graphs now, via dot!), and the SysV compatiblity
tools were extended to more completely and correctly support what was
historically provided by SysV. For example, we’ll now warn the user
when systemd service files have changed but systemd was not asked to
reload its configuration. Also, you can now use systemd’s native
client tools to reboot or shut-down an Upstart or sysvinit system, to
facilitate upgrades.

We provide a reference
implementation
for the socket activation and other APIs for nicer
interaction with systemd.

We have a pretty complete set of documentation
now, some
of it
even extending to areas not directly related to systemd
itself.

Quite a number of upstream packages now ship with systemd service
files out-of-the-box now, that work across all distributions that have
adopted systemd. It is our intention to unify the boot and service
management between distributions with systemd, and this shows fruits
already. Furthermore a number of upstream packages now ship our
patches for socket-based activation.

Even more options that control the process execution environment
or the sockets we create are now supported.

Earlier today I began my series of blog stories on systemd
for administrators
.

We reimplemented almost all boot-up and shutdown scripts of the
standard Fedora install in much smaller, simpler and faster C
utilities, or in systemd itself. Most of this will not be enabled in
F14 however, even though it is shipped with systemd upstream. With
this enabled the entire Linux system gains a completely new feeling as
the number of shells we spawn approaches zero, and the PID of the
first user terminal is way < 500 now, and the early boot-up is
fully parallelized. We looked at the boot scripts of Fedora, OpenSUSE
and Debian and distilled from this a list of functionality that makes
up the early boot process and reimplemented this in C, if possible
following the bahaviour of one of the existing implementations from
these three distributions. This turned out to be much less effort than
anticipated, and we are actually quite excited about this. Look
forward to the fruits of this work in F15, when we might be able to
present you a shell-less boot at least for standard desktop/laptop
systems.

We spent some time reinvestigating the current syslog logic, and
came up with an elegant and simple scheme to provide /dev/log
compatible logging right from the time systemd is first initialized
right until the time the kernel halts the machine. Through the wonders
of socket based activation we first connect the /dev/log
socket with a minimal bridge to the kernel log buffer (kmsg)
and then, as soon as the real syslog is started up as part of the
later bootup phase, we dynamically replace this minimal bridge by the
real syslog daemon — without losing a single log message. Since one
of the first things the real syslog daemon does is flushing the kernel
log buffer into log files, all logged messages will sooner or later be
stored on disk, regardless whether they have been generated during
early boot, late boot or system runtime. On top of that if the syslog
daemon terminates or is shut down during runtime, the bridge becomes
active again and log output is written to kmsg again. The same applies
when the system goes down. This provides a simple an robust way how we
can ensure that no logs will ever be lost again, and logging is
available from the beginning of boot-up to the end of
shut-down. Plymouth will most likely adopt a similar scheme for initrd
logging, thus ensuring that everything ever logged on the system will
properly end up in the log files, whether it comes from the kernel,
from the initrd, from early-boot, from runtime or shutdown. And if
syslogd is not around, dmesg will provide you with access to
the log messages. While this bridge is part of systemd upstream, we’ll
most likely enable this bridge in Fedora only starting with F15. Also
note that embedded systems that have no interest in shipping a full
syslogd solution can simply use this syslog bridge during the entire
runtime, and thus making the kernel log buffer the centralized log
storage, with all the advantages this offers: zero disk IO at runtime,
access to serial and netconsole logging, and remote debug access to
the kernel log buffer.

We now install autofs units for many “API” kernel virtual file
systems by default, such as binfmt_misc or
hugetlbfs. That means that the file system access is readily
available, client code no longer has to manually load the respective
kernel modules, as they are autoloaded on first access of the file
system. This has many advantages: it is not only faster to set up
during boot, but also simpler for applications, as they can just
assume the functionality is available. On top of that permission
problems for the initialization go away, since manual module loading
requires root privileges.

Many smaller fixes and enhancements, all across the board, which
if mentioned here would make this blog story another blog
novel. Suffice to say, we did a lot of polishing to ready systemd for
F14.

All in all, systemd is progressing nicely, and the features we have
been working on in the last months are without exception features not
existing in any other of the init systems available on Linux and our
feature set already was far ahead of what the older init
implementations provide. And we have quite a bit planned for the
future. So, stay tuned!

Also note that I’ll speak about systemd at LinuxKongress
2010
in Nuremberg, Germany. Later this year I’ll also be speaking
at the Linux
Plumbers Conference
in Boston, MA. Make sure to drop by if you
want to learn about systemd or discuss exiciting new ideas or features
with us.

systemd Status Update

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

It has been a while since my original
announcement of systemd
. Here’s a little status update, on what
happened since then. For simplicity’s sake I’ll just list here what we
worked on in a bulleted list, with no particular order and without
trying to cover this comprehensively:

  • systemd has been accepted as Feature for Fedora 14, and as it
    looks right now everything worked out nicely and we’ll ship F14 with
    systemd as init system.
  • We added a number of additional unit types: .timer for
    cron-style timer-based activation of services, .swap exposes
    swap files and partitions the same way we handle mount points, and
    .path can be used to activate units dependending on the
    existance/creation of files or fill status of spool directories.
  • We hooked systemd up to SELinux: systemd is now capabale of
    properly labelling directories, sockets and FIFOs it creates according
    to the SELinux policy for the services we maintain.
  • We hooked systemd up to the Linux auditing subsystem: as first
    init system at all systemd now generates auditing records for all
    services it starts/stops, including their failure status.
  • We hooked systemd up to TCP wrappers, for all socket connections
    it accepts.
  • We hooked systemd up to PAM, so that optionally, when systemd runs
    a service as a different user it initializes the usual PAM session
    setup and teardown hooks.
  • We hooked systemd up to D-Bus, so that D-Bus passes activation
    requests to systemd and systemd becomes the central point for all
    kinds of activation, thus greatly extending the control of the
    execution environment of bus activated services, and making them
    accessible through the same utilities as SysV services. Also, this
    enables us to do race-free parallelized start-up for D-Bus services
    and their clients, thus speeding up things even further.
  • systemd is now able to handle various Debian and OpenSUSE-specific
    extensions to the classic SysV init script formats natively, on top of
    the Fedora extensions we already parse.
  • The D-Bus coverage of the systemd interface is now complete,
    allowing both introspection of runtime data and of parsed
    configuration data. It’s fun now to introspect systemd with gdbus
    or d-feet.
  • We added a systemd
    PAM module
    , which assigns the processes of each user session to
    its own cgroup in the systemd cgroup tree. This also enables reliable
    killing of all processes associated with a session when the user logs
    out. This also manages a secure per-user /var/run-style directory
    which is supposed to be used for sockets and similar files that shall
    be cleaned up when the user logs out.
  • There’s a new tool systemd-cgls,
    which plots a pretty process tree based on the systemd cgroup
    hierarchy. It’s really pretty. Try it!
  • We now have our own cgroup hierarchy beneath
    /cgroup/systemd (though is will move to /sys/fs/
    before the F14 release).
  • We have pretty code that automatically spawns a getty on a serial
    port when the kernel console is redirected to a serial TTY.
  • systemctl got beefed up substantially (it can even draw
    dependency graphs now, via dot!), and the SysV compatiblity
    tools were extended to more completely and correctly support what was
    historically provided by SysV. For example, we’ll now warn the user
    when systemd service files have changed but systemd was not asked to
    reload its configuration. Also, you can now use systemd’s native
    client tools to reboot or shut-down an Upstart or sysvinit system, to
    facilitate upgrades.
  • We provide a reference
    implementation
    for the socket activation and other APIs for nicer
    interaction with systemd.
  • We have a pretty complete set of documentation
    now, some
    of it
    even extending to areas not directly related to systemd
    itself.
  • Quite a number of upstream packages now ship with systemd service
    files out-of-the-box now, that work across all distributions that have
    adopted systemd. It is our intention to unify the boot and service
    management between distributions with systemd, and this shows fruits
    already. Furthermore a number of upstream packages now ship our
    patches for socket-based activation.
  • Even more options that control the process execution environment
    or the sockets we create are now supported.
  • Earlier today I began my series of blog stories on systemd
    for administrators
    .
  • We reimplemented almost all boot-up and shutdown scripts of the
    standard Fedora install in much smaller, simpler and faster C
    utilities, or in systemd itself. Most of this will not be enabled in
    F14 however, even though it is shipped with systemd upstream. With
    this enabled the entire Linux system gains a completely new feeling as
    the number of shells we spawn approaches zero, and the PID of the
    first user terminal is way < 500 now, and the early boot-up is
    fully parallelized. We looked at the boot scripts of Fedora, OpenSUSE
    and Debian and distilled from this a list of functionality that makes
    up the early boot process and reimplemented this in C, if possible
    following the bahaviour of one of the existing implementations from
    these three distributions. This turned out to be much less effort than
    anticipated, and we are actually quite excited about this. Look
    forward to the fruits of this work in F15, when we might be able to
    present you a shell-less boot at least for standard desktop/laptop
    systems.
  • We spent some time reinvestigating the current syslog logic, and
    came up with an elegant and simple scheme to provide /dev/log
    compatible logging right from the time systemd is first initialized
    right until the time the kernel halts the machine. Through the wonders
    of socket based activation we first connect the /dev/log
    socket with a minimal bridge to the kernel log buffer (kmsg)
    and then, as soon as the real syslog is started up as part of the
    later bootup phase, we dynamically replace this minimal bridge by the
    real syslog daemon — without losing a single log message. Since one
    of the first things the real syslog daemon does is flushing the kernel
    log buffer into log files, all logged messages will sooner or later be
    stored on disk, regardless whether they have been generated during
    early boot, late boot or system runtime. On top of that if the syslog
    daemon terminates or is shut down during runtime, the bridge becomes
    active again and log output is written to kmsg again. The same applies
    when the system goes down. This provides a simple an robust way how we
    can ensure that no logs will ever be lost again, and logging is
    available from the beginning of boot-up to the end of
    shut-down. Plymouth will most likely adopt a similar scheme for initrd
    logging, thus ensuring that everything ever logged on the system will
    properly end up in the log files, whether it comes from the kernel,
    from the initrd, from early-boot, from runtime or shutdown. And if
    syslogd is not around, dmesg will provide you with access to
    the log messages. While this bridge is part of systemd upstream, we’ll
    most likely enable this bridge in Fedora only starting with F15. Also
    note that embedded systems that have no interest in shipping a full
    syslogd solution can simply use this syslog bridge during the entire
    runtime, and thus making the kernel log buffer the centralized log
    storage, with all the advantages this offers: zero disk IO at runtime,
    access to serial and netconsole logging, and remote debug access to
    the kernel log buffer.
  • We now install autofs units for many “API” kernel virtual file
    systems by default, such as binfmt_misc or
    hugetlbfs. That means that the file system access is readily
    available, client code no longer has to manually load the respective
    kernel modules, as they are autoloaded on first access of the file
    system. This has many advantages: it is not only faster to set up
    during boot, but also simpler for applications, as they can just
    assume the functionality is available. On top of that permission
    problems for the initialization go away, since manual module loading
    requires root privileges.
  • Many smaller fixes and enhancements, all across the board, which
    if mentioned here would make this blog story another blog
    novel. Suffice to say, we did a lot of polishing to ready systemd for
    F14.

All in all, systemd is progressing nicely, and the features we have
been working on in the last months are without exception features not
existing in any other of the init systems available on Linux and our
feature set already was far ahead of what the older init
implementations provide. And we have quite a bit planned for the
future. So, stay tuned!

Also note that I’ll speak about systemd at LinuxKongress
2010
in Nuremberg, Germany. Later this year I’ll also be speaking
at the Linux
Plumbers Conference
in Boston, MA. Make sure to drop by if you
want to learn about systemd or discuss exiciting new ideas or features
with us.

systemd for Administrators, Part 1

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/systemd-for-admins-1.html

As many of you know, systemd is the new
Fedora init system, starting with F14, and it is also on its way to being adopted in
a number of other distributions as well (for example, OpenSUSE). For administrators
systemd provides a variety of new features and changes and enhances the
administrative process substantially. This blog story is the first part of a
series of articles I plan to post roughly every week for the next months. In
every post I will try to explain one new feature of systemd. Many of these features
are small and simple, so these stories should be interesting to a broader audience.
However, from time to time we’ll dive a little bit deeper into the great new
features systemd provides you with.

Verifying Bootup

Traditionally, when booting up a Linux system, you see a lot of
little messages passing by on your screen. As we work on speeding up
and parallelizing the boot process these messages are becoming visible
for a shorter and shorter time only and be less and less readable —
if they are shown at all, given we use graphical boot splash
technology like Plymouth these days. Nonetheless the information of
the boot screens was and still is very relevant, because it shows you
for each service that is being started as part of bootup, wether it
managed to start up successfully or failed (with those green or red
[ OK ] or [ FAILED ] indicators). To improve the
situation for machines that boot up fast and parallelized and to make
this information more nicely available during runtime, we added a
feature to systemd that tracks and remembers for each service whether
it started up successfully, whether it exited with a non-zero exit
code, whether it timed out, or whether it terminated abnormally (by
segfaulting or similar), both during start-up and runtime. By simply
typing systemctl in your shell you can query the state of all
services, both systemd native and SysV/LSB services:

[[email protected]] ~# systemctl
UNIT LOAD ACTIVE SUB JOB DESCRIPTION
dev-hugepages.automount loaded active running Huge Pages File System Automount Point
dev-mqueue.automount loaded active running POSIX Message Queue File System Automount Point
proc-sys-fs-binfmt_misc.automount loaded active waiting Arbitrary Executable File Formats File System Automount Point
sys-kernel-debug.automount loaded active waiting Debug File System Automount Point
sys-kernel-security.automount loaded active waiting Security File System Automount Point
sys-devices-pc…0000:02:00.0-net-eth0.device loaded active plugged 82573L Gigabit Ethernet Controller
[…]
sys-devices-virtual-tty-tty9.device loaded active plugged /sys/devices/virtual/tty/tty9
-.mount loaded active mounted /
boot.mount loaded active mounted /boot
dev-hugepages.mount loaded active mounted Huge Pages File System
dev-mqueue.mount loaded active mounted POSIX Message Queue File System
home.mount loaded active mounted /home
proc-sys-fs-binfmt_misc.mount loaded active mounted Arbitrary Executable File Formats File System
abrtd.service loaded active running ABRT Automated Bug Reporting Tool
accounts-daemon.service loaded active running Accounts Service
acpid.service loaded active running ACPI Event Daemon
atd.service loaded active running Execution Queue Daemon
auditd.service loaded active running Security Auditing Service
avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack
bluetooth.service loaded active running Bluetooth Manager
console-kit-daemon.service loaded active running Console Manager
cpuspeed.service loaded active exited LSB: processor frequency scaling support
crond.service loaded active running Command Scheduler
cups.service loaded active running CUPS Printing Service
dbus.service loaded active running D-Bus System Message Bus
[email protected] loaded active running Getty on tty2
[email protected] loaded active running Getty on tty3
[email protected] loaded active running Getty on tty4
[email protected] loaded active running Getty on tty5
[email protected] loaded active running Getty on tty6
haldaemon.service loaded active running Hardware Manager
[email protected] loaded active running sda shock protection daemon
irqbalance.service loaded active running LSB: start and stop irqbalance daemon
iscsi.service loaded active exited LSB: Starts and stops login and scanning of iSCSI devices.
iscsid.service loaded active exited LSB: Starts and stops login iSCSI daemon.
livesys-late.service loaded active exited LSB: Late init script for live image.
livesys.service loaded active exited LSB: Init script for live image.
lvm2-monitor.service loaded active exited LSB: Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling
mdmonitor.service loaded active running LSB: Start and stop the MD software RAID monitor
modem-manager.service loaded active running Modem Manager
netfs.service loaded active exited LSB: Mount and unmount network filesystems.
NetworkManager.service loaded active running Network Manager
ntpd.service loaded maintenance maintenance Network Time Service
polkitd.service loaded active running Policy Manager
prefdm.service loaded active running Display Manager
rc-local.service loaded active exited /etc/rc.local Compatibility
rpcbind.service loaded active running RPC Portmapper Service
rsyslog.service loaded active running System Logging Service
rtkit-daemon.service loaded active running RealtimeKit Scheduling Policy Service
sendmail.service loaded active running LSB: start and stop sendmail
[email protected]:22-172.31.0.4:36368.service loaded active running SSH Per-Connection Server
sysinit.service loaded active running System Initialization
systemd-logger.service loaded active running systemd Logging Daemon
udev-post.service loaded active exited LSB: Moves the generated persistent udev rules to /etc/udev/rules.d
udisks.service loaded active running Disk Manager
upowerd.service loaded active running Power Manager
wpa_supplicant.service loaded active running Wi-Fi Security Service
avahi-daemon.socket loaded active listening Avahi mDNS/DNS-SD Stack Activation Socket
cups.socket loaded active listening CUPS Printing Service Sockets
dbus.socket loaded active running dbus.socket
rpcbind.socket loaded active listening RPC Portmapper Socket
sshd.socket loaded active listening sshd.socket
systemd-initctl.socket loaded active listening systemd /dev/initctl Compatibility Socket
systemd-logger.socket loaded active running systemd Logging Socket
systemd-shutdownd.socket loaded active listening systemd Delayed Shutdown Socket
dev-disk-byx1…x1db22ax1d870f1adf2732.swap loaded active active /dev/disk/by-uuid/fd626ef7-34a4-4958-b22a-870f1adf2732
basic.target loaded active active Basic System
bluetooth.target loaded active active Bluetooth
dbus.target loaded active active D-Bus
getty.target loaded active active Login Prompts
graphical.target loaded active active Graphical Interface
local-fs.target loaded active active Local File Systems
multi-user.target loaded active active Multi-User
network.target loaded active active Network
remote-fs.target loaded active active Remote File Systems
sockets.target loaded active active Sockets
swap.target loaded active active Swap
sysinit.target loaded active active System Initialization

LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
JOB = Pending job for the unit.

221 units listed. Pass –all to see inactive units, too.
[[email protected]] ~#

(I have shortened the output above a little, and removed a few lines not relevant for this blog post.)

Look at the ACTIVE column, which shows you the high-level state of
a service (or in fact of any kind of unit systemd maintains, which can
be more than just services, but we’ll have a look on this in a later
blog posting), whether it is active (i.e. running),
inactive (i.e. not running) or in any other state. If you look
closely you’ll see one item in the list that is marked maintenance
and highlighted in red. This informs you about a service that failed
to run or otherwise encountered a problem. In this case this is
ntpd. Now, let’s find out what actually
happened to ntpd, with the systemctl status
command:

[[email protected]] ~# systemctl status ntpd.service
ntpd.service – Network Time Service
Loaded: loaded (/etc/systemd/system/ntpd.service)
Active: maintenance
Main: 953 (code=exited, status=255)
CGroup: name=systemd:/systemd-1/ntpd.service
[[email protected]] ~#

This shows us that NTP terminated during runtime (when it ran as
PID 953), and tells us exactly the error condition: the process exited
with an exit status of 255.

In a later systemd version, we plan to hook this up to ABRT, as soon as
this enhancement request is fixed
. Then, if systemctl
status shows you information about a service that crashed it will
direct you right-away to the appropriate crash dump in ABRT.

Summary: use systemctl and systemctl
status as modern, more complete replacements for the traditional
boot-up status messages of SysV services. systemctl status
not only captures in more detail the error condition but also shows
runtime errors in addition to start-up errors.

That’s it for this week, make sure to come back next week, for the
next posting about systemd for administrators!

systemd for Administrators, Part 1

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/systemd-for-admins-1.html

As many of you know, systemd is the new
Fedora init system, starting with F14, and it is also on its way to being adopted in
a number of other distributions as well (for example, OpenSUSE). For administrators
systemd provides a variety of new features and changes and enhances the
administrative process substantially. This blog story is the first part of a
series of articles I plan to post roughly every week for the next months. In
every post I will try to explain one new feature of systemd. Many of these features
are small and simple, so these stories should be interesting to a broader audience.
However, from time to time we’ll dive a little bit deeper into the great new
features systemd provides you with.

Verifying Bootup

Traditionally, when booting up a Linux system, you see a lot of
little messages passing by on your screen. As we work on speeding up
and parallelizing the boot process these messages are becoming visible
for a shorter and shorter time only and be less and less readable —
if they are shown at all, given we use graphical boot splash
technology like Plymouth these days. Nonetheless the information of
the boot screens was and still is very relevant, because it shows you
for each service that is being started as part of bootup, wether it
managed to start up successfully or failed (with those green or red
[ OK ] or [ FAILED ] indicators). To improve the
situation for machines that boot up fast and parallelized and to make
this information more nicely available during runtime, we added a
feature to systemd that tracks and remembers for each service whether
it started up successfully, whether it exited with a non-zero exit
code, whether it timed out, or whether it terminated abnormally (by
segfaulting or similar), both during start-up and runtime. By simply
typing systemctl in your shell you can query the state of all
services, both systemd native and SysV/LSB services:

[[email protected]] ~# systemctl
UNIT                                          LOAD   ACTIVE       SUB          JOB             DESCRIPTION
dev-hugepages.automount                       loaded active       running                      Huge Pages File System Automount Point
dev-mqueue.automount                          loaded active       running                      POSIX Message Queue File System Automount Point
proc-sys-fs-binfmt_misc.automount             loaded active       waiting                      Arbitrary Executable File Formats File System Automount Point
sys-kernel-debug.automount                    loaded active       waiting                      Debug File System Automount Point
sys-kernel-security.automount                 loaded active       waiting                      Security File System Automount Point
sys-devices-pc...0000:02:00.0-net-eth0.device loaded active       plugged                      82573L Gigabit Ethernet Controller
[...]
sys-devices-virtual-tty-tty9.device           loaded active       plugged                      /sys/devices/virtual/tty/tty9
-.mount                                       loaded active       mounted                      /
boot.mount                                    loaded active       mounted                      /boot
dev-hugepages.mount                           loaded active       mounted                      Huge Pages File System
dev-mqueue.mount                              loaded active       mounted                      POSIX Message Queue File System
home.mount                                    loaded active       mounted                      /home
proc-sys-fs-binfmt_misc.mount                 loaded active       mounted                      Arbitrary Executable File Formats File System
abrtd.service                                 loaded active       running                      ABRT Automated Bug Reporting Tool
accounts-daemon.service                       loaded active       running                      Accounts Service
acpid.service                                 loaded active       running                      ACPI Event Daemon
atd.service                                   loaded active       running                      Execution Queue Daemon
auditd.service                                loaded active       running                      Security Auditing Service
avahi-daemon.service                          loaded active       running                      Avahi mDNS/DNS-SD Stack
bluetooth.service                             loaded active       running                      Bluetooth Manager
console-kit-daemon.service                    loaded active       running                      Console Manager
cpuspeed.service                              loaded active       exited                       LSB: processor frequency scaling support
crond.service                                 loaded active       running                      Command Scheduler
cups.service                                  loaded active       running                      CUPS Printing Service
dbus.service                                  loaded active       running                      D-Bus System Message Bus
[email protected]                            loaded active       running                      Getty on tty2
[email protected]                            loaded active       running                      Getty on tty3
[email protected]                            loaded active       running                      Getty on tty4
[email protected]                            loaded active       running                      Getty on tty5
[email protected]                            loaded active       running                      Getty on tty6
haldaemon.service                             loaded active       running                      Hardware Manager
[email protected]                            loaded active       running                      sda shock protection daemon
irqbalance.service                            loaded active       running                      LSB: start and stop irqbalance daemon
iscsi.service                                 loaded active       exited                       LSB: Starts and stops login and scanning of iSCSI devices.
iscsid.service                                loaded active       exited                       LSB: Starts and stops login iSCSI daemon.
livesys-late.service                          loaded active       exited                       LSB: Late init script for live image.
livesys.service                               loaded active       exited                       LSB: Init script for live image.
lvm2-monitor.service                          loaded active       exited                       LSB: Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling
mdmonitor.service                             loaded active       running                      LSB: Start and stop the MD software RAID monitor
modem-manager.service                         loaded active       running                      Modem Manager
netfs.service                                 loaded active       exited                       LSB: Mount and unmount network filesystems.
NetworkManager.service                        loaded active       running                      Network Manager
ntpd.service                                  loaded maintenance  maintenance                  Network Time Service
polkitd.service                               loaded active       running                      Policy Manager
prefdm.service                                loaded active       running                      Display Manager
rc-local.service                              loaded active       exited                       /etc/rc.local Compatibility
rpcbind.service                               loaded active       running                      RPC Portmapper Service
rsyslog.service                               loaded active       running                      System Logging Service
rtkit-daemon.service                          loaded active       running                      RealtimeKit Scheduling Policy Service
sendmail.service                              loaded active       running                      LSB: start and stop sendmail
[email protected]:22-172.31.0.4:36368.service  loaded active       running                      SSH Per-Connection Server
sysinit.service                               loaded active       running                      System Initialization
systemd-logger.service                        loaded active       running                      systemd Logging Daemon
udev-post.service                             loaded active       exited                       LSB: Moves the generated persistent udev rules to /etc/udev/rules.d
udisks.service                                loaded active       running                      Disk Manager
upowerd.service                               loaded active       running                      Power Manager
wpa_supplicant.service                        loaded active       running                      Wi-Fi Security Service
avahi-daemon.socket                           loaded active       listening                    Avahi mDNS/DNS-SD Stack Activation Socket
cups.socket                                   loaded active       listening                    CUPS Printing Service Sockets
dbus.socket                                   loaded active       running                      dbus.socket
rpcbind.socket                                loaded active       listening                    RPC Portmapper Socket
sshd.socket                                   loaded active       listening                    sshd.socket
systemd-initctl.socket                        loaded active       listening                    systemd /dev/initctl Compatibility Socket
systemd-logger.socket                         loaded active       running                      systemd Logging Socket
systemd-shutdownd.socket                      loaded active       listening                    systemd Delayed Shutdown Socket
dev-disk-by\x1...x1db22a\x1d870f1adf2732.swap loaded active       active                       /dev/disk/by-uuid/fd626ef7-34a4-4958-b22a-870f1adf2732
basic.target                                  loaded active       active                       Basic System
bluetooth.target                              loaded active       active                       Bluetooth
dbus.target                                   loaded active       active                       D-Bus
getty.target                                  loaded active       active                       Login Prompts
graphical.target                              loaded active       active                       Graphical Interface
local-fs.target                               loaded active       active                       Local File Systems
multi-user.target                             loaded active       active                       Multi-User
network.target                                loaded active       active                       Network
remote-fs.target                              loaded active       active                       Remote File Systems
sockets.target                                loaded active       active                       Sockets
swap.target                                   loaded active       active                       Swap
sysinit.target                                loaded active       active                       System Initialization

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.
JOB    = Pending job for the unit.

221 units listed. Pass --all to see inactive units, too.
[[email protected]] ~#

(I have shortened the output above a little, and removed a few lines not relevant for this blog post.)

Look at the ACTIVE column, which shows you the high-level state of
a service (or in fact of any kind of unit systemd maintains, which can
be more than just services, but we’ll have a look on this in a later
blog posting), whether it is active (i.e. running),
inactive (i.e. not running) or in any other state. If you look
closely you’ll see one item in the list that is marked maintenance
and highlighted in red. This informs you about a service that failed
to run or otherwise encountered a problem. In this case this is
ntpd. Now, let’s find out what actually
happened to ntpd, with the systemctl status
command:

[[email protected]] ~# systemctl status ntpd.service
ntpd.service - Network Time Service
	  Loaded: loaded (/etc/systemd/system/ntpd.service)
	  Active: maintenance
	    Main: 953 (code=exited, status=255)
	  CGroup: name=systemd:/systemd-1/ntpd.service
[[email protected]] ~#

This shows us that NTP terminated during runtime (when it ran as
PID 953), and tells us exactly the error condition: the process exited
with an exit status of 255.

In a later systemd version, we plan to hook this up to ABRT, as soon as
this enhancement request is fixed
. Then, if systemctl
status
shows you information about a service that crashed it will
direct you right-away to the appropriate crash dump in ABRT.

Summary: use systemctl and systemctl
status
as modern, more complete replacements for the traditional
boot-up status messages of SysV services. systemctl status
not only captures in more detail the error condition but also shows
runtime errors in addition to start-up errors.

That’s it for this week, make sure to come back next week, for the
next posting about systemd for administrators!

Маки суши

Post Syndicated from Илия Горанов original http://9ini.babailiica.com/makisushi/

Маки сушиОт доста време се каним да си спретнем едно домашно приготвено суши. Откакто откриха новия мол на Цариградско шосе, редовно хапваме рибките в Happy-то на последния етаж – при кината.
Може би трябва да уточним, че съществуват много и различни видове суши. Аз лично съм фен на макитата – това са може би най-разпространения вид, който се навива в кори от водорасли във вид на големи пури, а след това пурите се режат на шайби.
Напазарувахме необходимите продукти от няколко магазина в същия мол:

Листове нори от сушени водорасли – 5 листа
Ориз за суши – 500 гр.
Пушена сьомга 100 гр.
Скариди – 250 гр.
Сурими (рулца от раци) – 100 гр.
Авокадо – 1 бр.
Краставица (по-плътна) – 1 бр.
Бамбукова подложка за навиване

Прибрахме се и action! Първо проверихме в наличната домашна готварска литература какво пише по темата – почти нищо. После проверихме какво пише в Интернет по темата – доста.
Оризът: преди да се вари се маринова със сол, захар и оцет. В някои рецепти в маринатата слагат оризов оцет, също слагат и саке (оризова ракия)… ама ми се вижда много оризово. А и поради липсата на оризов оцет и саке – използвахме просто балсамов оцет. Първо оризът се мие със студена вода, докато не спре да пада бяло от него. После се накисва в студена вода 1½ количеството ориз за ½ час. След това, без да се изцежда водата, в която е киснал се слага да заври на слаб огън и се вари, докато попие всичката вода, като се бърка непрекъснато (около 10 – 15 минути). След като се свари, оризът се маринова и се разбърква хубаво и се захлупва с капака. Така втасва още 10 – 15 минути. Пропорцията за маринатата е следната: за 5 листа нори – 250 гр. ориз; на този ориз се слагат 1½ ч.л. сол, 1½ кафява захар, оцет на око – докато потъмнее леко.
Плънката: по заведенията я пестят, а като гледам цените на продуктите, не мисля, че тя е най-скъпата съставка. Освен това в зависимост от вида на маки сушито има такива, които са с един вид плънка и такива които са с различни плънки. Ние избрахме с различни. Нарязахме едно авокадо на лентички – то има приятен мазен вкус, по-скоро няма вкус, а просто придава мазно усещане… странно е, трябва да сте опитвали авокадо, иначе не може да се опише. Освен него и една краставица на лентички. По оригиналната рецепта краставицата не се бели. Също и пушената сьомга. Може и сурова, но се препоръчва да се замрази дълбоко за 24 – 48 часа, за да няма паразити в нея. При мариноването за опушване също умират. Всъщност рискът при сушито е от паразити в суровата риба. Подозирам, че с маринована червена херинга също може да се получи доста добре – продава се в на салатния щанд в Кауфланд и другаде почти не съм я намирал. Също 250 гр. замразени скариди ги сварихме в подсолена вода. Беленето си е пипкава работа, но ако скаридите са едри и хубави – не е толкова страшно. Също сурими, известни сред народа като ролца от раци, но в действителност е мляно месо от риба, което се овкюсява с подправки, пресова се и се боядисва – за да наподоби рачешко месо.
Нори – това са листовете от сушени водорасли, от които се навива маки сушито. В био магазина в мола продават няколко вида. Качеството на листовете зависи от няколко неща – да не се чупят лесно, да са светло зелени на цвят – като остареят стават тъмно зелени или дори кафяви. Да нямат дупки.
Навиването – става по-лесно с подложка от бамбукови пръчици. Листът нори се слага върху подложката и върху него се разстила тънък слой ориз. Разстилането е една от най-големите тънкости при сушито или по друг начин казано – беше една от най-сложните операции за нас. Слоят трябва да е възможно най-тънък, като в същото време не трябва да има дупки. Задачата се усложнява от факта, че оризът е доста лепкав. Задължително трябва да е истинал към момента на полагането му. В горния край на листа трябва да се остави ивица около 1 см. за да се загърне накрая.
След като се растели оризът, в долния край на листа, но не съвсем близо до ръба се подрежда плънката. Ние слагахме няколко стръка авокадо, няколко стръка краставица и един от видовете морски продукти – сьомга, скариди или сурими. В различните рецепти се слагат още маринован кисел лук, крема сирене тип Филаделфия, риба тон и други мариновани риби, както и други зеленчуци.
Навиването започва от долния край постепенно нагоре. Когато се стигне горния край – оставената свободна ивица загръща цилиндъра и така не остава откъде да се изсипе оризът или плънката. След това се стиска, така че да се пресова – да не остават рехави места в ориза и между плънката. Понеже оризът е лепкав – цялото маки се стяга и не се разпада лесно. Тази операция става най-лесно с въпросната подложка за навиване. Тя е от бамбукови пръчици сплетени с тънко канапче. Като се навие макито, може отвън да се стисне с ръка – въженцата се свиват, а клечките се сгъстяват и сплескването е лесно. Понеже отвътре клечките са овалки – не разкъсват листа нори.
Нарязването беше вторият момент, в който срещнахме проблем. Всъщност проблемът беше в ножа – не беше достатъчно остър. След като сплескахме първото маки, специално наточих един голям нож. На второто и третото вече нямаше проблеми. Добре е при рязането да има още две ръце, които да помагат, като държат от другия край макито, за да не се разкъса нори листът и да не се развие. Също проблем прави лепкавостта на ориза и твърдостта на плънката. Когато ножът започне да минава през макито, оризът е мек и ножът потъва до сърцевината. Там среща авокадото, което е твърдо и ножът запира. Ако се натисне по-силно – има опасност да се сплеска цялото маки. Затова рязането трябва да става с прав, а не назъбен нож с дълги постъпателно-възвратни движения. Да обаче, понеже оризът лепне – залепва за ножа, затова след всяко маки трябва да се измие с гореща вода.
След като се нареже на шайби, добре е да се охлади в хладилник за час два, освен ако всички продукти не са предварително охладени. Също е добре да се завие със стреч фолио или капак, защото 1) оризът поглъща всички миризми от хладилника; 2) рибата омирисва всичко останало в хладилника; 3) ако имате no frost система, всичко ще изсъхне за 2 часа в хладилника.
Вече охладеното суши се сервира с уосаби и/или паста от хрян. Понеже и двете са люти ги пропуснахме. Освен това се сервира и малка купичка със соев сос. Всяка шайба се топи в соса и се яде.
В интерес на истината – получи се доста над очакванията ми. Още първото маки суши имаше автентичен вкус. Поне сравнено със сушитата от три заведения, които вече съм ял. Е – първото се сплеска при рязането и се наложи да го изядем с ръце. Но на последния лист вече придоби направо търговски вид. Явно не е чак толкова трудно. Като изключим времето за подготовка на ориза – останалите неща стават относително лесно и бързо. Аз съм доволен и подозирам, че занапред ще го правим още доста пъти.
Между другото – не всички хора харесват вкуса на сушито. Ако имате съмнения или ако не обичате сладко-кисели ястия или риба, по-добре първо опитайте суши в ресторант. Вече не е чак толкова скъпо удоволствие. Малки порции от 4 шайби се сервират между 2 и 5 лв. Ако сте опитали и вече знаете, че ви харесва – опитайте и вкъщи!
Тук малко снимки

Dear Lazy Web,

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/lenovo-laptop-codes.html

does anybody know how to decode those Lenovo ThinkPad model IDs? I am
interested in the T410s. For example, there’s the model NUK3AGE, and there’s
NUHFXGE, and there’s NUHYXGE. Some web sites claim NUK3AGE has Nvidia graphics,
others claim VGA is Intel-only. Some web sites claim it has a touch screen,
others say the contrary. The Lenovo web site isn’t helpful to figure out the
differences between the models and what the feature set of the various models
really is. I figured out the GE suffix indicates a german keyboard, but what
about the remaining code? Anybody knows how to decypher those IDs or knows a
reliable source explaining their feature set?

Love,

Lennart

Dear Lazy Web,

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/lenovo-laptop-codes.html

does anybody know how to decode those Lenovo ThinkPad model IDs? I am
interested in the T410s. For example, there’s the model NUK3AGE, and there’s
NUHFXGE, and there’s NUHYXGE. Some web sites claim NUK3AGE has Nvidia graphics,
others claim VGA is Intel-only. Some web sites claim it has a touch screen,
others say the contrary. The Lenovo web site isn’t helpful to figure out the
differences between the models and what the feature set of the various models
really is. I figured out the GE suffix indicates a german keyboard, but what
about the remaining code? Anybody knows how to decypher those IDs or knows a
reliable source explaining their feature set?

Love,

Lennart

Considerations For FLOSS Hackers About Oracle vs. Google

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/08/16/oracle-google.html

Many have already opined about the Oracle v. Google lawsuit filed last
week. As you might expect, I’m not that worried about what company sues
what company for some heap of cash; those sort of for-profit wranglings
just aren’t what concerns me. Rather, I’m focused on what this event
means for the future of software freedom. And, I think even at this
early stage of the lawsuit, there are already a few lessons for the Free
Software community to learn.

Avoid Single-Company-Controlled Language Infrastructure

Fourteen months ago, before the Oracle purchase of Sun,
I wrote
about the specific danger of language infrastructure developed by a
single for-profit patent-holding entity
(when such infrastructure is
less than 20 years old). In that blog post, I wrote:

[Some] might argue that with all those patents consolidated [in a single
company], patent trolls will have a tough time acquiring patents and
attacking FaiF
implementations. However, while this can sometimes be temporarily true,
one cannot rely on this safety. Java, for example, is in a precarious
situation now. Oracle is not a friend to Free Software, and soon will
hold all Sun’s Java patents — a looming threat to FaiF Java
implementations … [A]n Oracle attack on FaiF Java is a possibility.

I’m sorry that I was right about this, but we should now finally learn
the lesson: languages like Java and C# are dangerous. Single companies
developed them, and there are live, unexpired patents that can easily be
used in a group to attack FaiF implementations. Of course, that doesn’t
mean other language infrastructures are completely safe from patents,
but I believe there is greater relative risk of a system with patent
consolidation at a single company.

It also bears repeating the point I made
on Linux
Outlaws last July
: this doesn’t mean the Free Software community
shouldn’t have FaiF implementations of all languages. In fact,
we absolutely should, because we do want developers who are
familiar with those languages to bring their software over to GNU/Linux
and other Free Software systems.

However, this lawsuit proves that choosing some languages for newly
written Free Software is dangerous and should be avoided, especially
when there are safer choices like C, C++, Python, and Perl0. (See
my blog
post from last year for more on this subject
.)

Never Let Your Company File for Patents on Your Work

James Gosling is usually
pretty cryptic in his non-technical writing, but I think if you read
carefully, it seems to me
that Gosling
regrets
that Oracle now holds his patents on Java. I know developers
get nice bonuses if they let their company apply for patents on their
work. I also know there’s pressure in most large companies to get more
patents. We, as developers, must simply refuse this. We invent
this stuff, not the suits and the lawyers who want to exploit our work for
larger and larger profits. As a community of developers and computer
scientists, we must simply refuse to ever let someone patent our work. In
a phrase: just say no.

Even if you like your company today, you never know who will own those
software patents later. I’m sure James Gosling originally never
considered the idea that a company as revolting as Oracle would have
control of everything he’s invented for the last two decades. But they
do, and there’s nothing Gosling can do about what’s done with his work
and “inventions”. Learn from this example; don’t let your
company patent your work. Instead, publish online to establish prior
art as quickly as possible.

Google Is Not Merely a Pure Free Software Distributor

Google
has worked hard to cast themselves as innocent
,
Free-Software-producing victims. That’s good PR because it’s true, but
it’s also not telling the whole
truth. Google
worked hard to make sure Android was completely Apache-2.0 (or even more
permissively) licensed
(except for Linux, of course). There was
already plenty
Java stuff
available under the GPL that Google could have used. Sadly, Google was
so allergic to GPL for Android/Linux that they even avoided LGPL’d
components like uClibc
and glibc (in favor of
their own
permissively-licensed C library based on a BSD version
).

Google’s reason for permissive-only licensing for “everything but
the kernel” was likely a classic “adoption is more important
than software freedom” scenario. Google wants Android/Linux in as
many phones as possible, and wants to eliminate any
“barrier” to such adoption, even if such a
“barrier” would defend software freedom.

This new lawsuit would be much more interesting if Google had chosen
GPL and/or LGPL for Android. In fact, if I fantasize about being
empowered to design a binding, non-financial settlement to the lawsuit,
the first item on my list would be a relicense of all future
Android/Linux systems under GPL and/or LGPL. (Basically, Google would
license only enough under LGPL to allow proprietary applications, and
license all the rest as GPL, thus yielding the same licensing
consequences as GNU/Linux and GNOME). Then, I’d have Oracle explicitly
license all its patents under GPL and/or LGPL
compatible licenses that would permit Android/Linux to continue
unencumbered, but under
copyleft. (BTW, Mark
Wielaard has a blog post that discussed more about the issue of
GPL’d/LGPL’d Java implementations and how they relate to this
lawsuit
.)

I realize that’s never going to happen, but it’s an interesting thought
experiment. I am of course opposed to software patents, and I certainly
oppose companies like Oracle that produce almost all proprietary
software. However, I can at least understand the logic of Oracle not
wanting its software patents exercised in proprietary software. I think
a trade off, whereby all software patents are licensed freely and
royalty-free only for use in copylefted software is a reasonable
compromise. OTOH, knowing Oracle, they could easily have plans to
attack copyleft implementations too. Thus, we must assume they won’t
accept this reasonable compromise of “royalty-free licensing for
copyleft only”. That brings me to my next point of FaiF hackers’
concern about this lawsuit.

Never Trust a Mere Patent Promise; Demand Real Patent Licenses

I wrote after Bilski
that patent
promises just aren’t enough
, and this lawsuit is an example of why.
I presume that Oracle’s lawyers have looked carefully as the various
promises and assurances that Sun made about its Java patents and have
concluded Oracle has good arguments for why those promises don’t apply
to Android. I have no idea what those arguments are, but rarely do
lawyers file a lawsuit without very good arguments already prepared. I
hope Oracle’s lawyers’ arguments are wrong and they lose. But, the fact
that Oracle even has a credible argument that Android/Linux doesn’t
already have a patent license shows again that patent promises are just
not enough.

Miguel de Icaza
used this
opportunity to point out how the Microsoft C# promises are
“better” by comparison
, in his opinion.
But, Brett Smith at
FSF already found huge holes in those Microsoft promises that haven’t
been fixed
. In fact, any company making these promises always tries
to hide as much nasty stuff as it can, to convince the users that they
are safe from patent aggression when they really aren’t. That’s why the
Free Software community must demand simple, clear, and permanent
royalty-free patent licenses for all patents any
company might hold. We should accept nothing less. As mentioned above,
those licenses could perhaps require that a certain Free Software
copyright license, such as GPLv3-or-later, be used for any software that
gets the advantage of the license. (i.e., I can certainly understand if
companies don’t want to accidentally grant such patent licenses to their
proprietary software competitors).

Indeed, it’s particularly important that the licenses
cover all patents and those possibly exercised in future
improvements in the software. This lawsuit has clearly shown that even
if patent pools exist for some subsets of patents for some subsets of
Free Software, patent holders will either use other patents for
aggression, or they’ll assert patents in the patent pools against Free
Software that’s not part of the pool. In essence, we must assume that
any for-profit company will become a patent troll eventually
(they always do), and therefore any cross-licensing pools that don’t
include every patent possible for any possible Free Software will always
be inadequate. So, the answer is simple: trust no
software-patent-holding company unless they give an explicit
GPLv3-compatible license for all their patents.

We Must End Software Patents

The failure of the Bilski case to end software patents in the USA means
much work lies ahead to end software patents.
The End
Software Patents Wiki has some good stuff about this case
as well as
lots of other information related to software patents. There are now
heavily funded for-profit corporate efforts that seek to convince the
Free Software community
that patent
reform is enough. But, it’s not!
For example, if you see
presenters at
FLOSS
conferences claiming to have solutions to patent problems, ask them if their
organization opposes all software patents, and ask them if their funders
license all their patents freely for GPLv3-or-later software
implementations. If you hear the wrong answers, then their motives and
mission are suspect.

Finally, I’d like to note that, in some sense, these patent battles
help Free Software, because it may actually teach companies that the
expense of having software patents is not worth the risk of patent
lawsuits. It’s possible we’ve reached a moment in history where it’d be
better if the Software Patent Cold War becomes a full Software Patent
Nuclear War. Software freedom can survive that “nuclear
winter”. I sometimes think that in the Free Software community,
we may find ourselves left with just two choices: fifty more years of
Patent Cold War (with lots of skirmishes like this one), or ten years of
full-on patent war (after which companies would beg Congress to end
software patents). Both outcomes are horrible until they’re resolved,
but the latter would reach resolution quicker. I often wonder which one
is the better long term for software freedom.

But, no matter what happens next, the necessary position is: all software
patents are bad for software freedom. Any entity that supports anything
short of full abolition of software patents is working against software
freedom.

0I originally had PHP listed here,
but jwildeboer
argued that Zend Technologies, Ltd. might be a problem for PHP
in
the same way Oracle is for Java and Microsoft for C#. It’s true that
Zend is a software patent holder and was involved in the development
of later PHP versions. I don’t think the single-company-controlled
software patent risks with PHP are akin to those of Java and C#, since
Zend Technologies isn’t the only entity involved in PHP’s development,
but certainly the other languages listed are likely preferable to
PHP.

GNOME Copyright Assignment Policy

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/08/13/gnome-copyright.html

Vincent
Untz announced
and blogged
today
about
the GNOME Copyright
Assignment Policy
and
a longer
guidelines document about the GNOME policy
. I want to thank both
Vincent and Michael
Meeks
for their work with me on this policy.

As I noted in
my blog last
week, GUADEC really reminded me how great the GNOME community is
.
Therefore, it’s with great pride that I was able to assist on this
important piece of policy for the GNOME community.

There are a lot of forces in the corporate side of Free Software right
now that are aggressively trying to convince copylefted projects to
begin assigning copyright of their code (or otherwise agree to CLAs) to
corporations without any promises that the code will remain Free
Software. We must resist this pressure: copyleft, when used correctly,
is the force that keeps equality in the
community, as
I’ve written about before
.

I thank the GNOME Board of Directors for
entrusting us to write the policy, and am glad they have adopted it.

May They Make Me Superfluous

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/08/10/may-they-make-me-superfluous.html

The Linux
Foundation announced
today

their own
FLOSS license compliance program
, which included the launch of a
few software
tools under a modified BSD license
. They also have offered
some training
courses
for those that want to learn how to comply.

If this Linux Foundation (LF) program is successful, I may get
something I’ve wished for since the first enforcement I ever worked on
back in late 1998: I’d like to never do GPL enforcement again. I admit
I talk a lot about GPL enforcement. It’s indeed been a major center of
my work for twelve years, but I can’t say I’ve ever
really liked doing it.

By contrast, I have been hoping for years that someone would eventually
come along and “put me out of the enforcement business”.
Someday, I dream of opening up the <[email protected]> folder and
having no new violation reports (BTW, those dreams usually become
real-life nightmares, as I typically get two new violations reports each
week). I also wish for the day that I don’t have a backlogged queue of
200 or more GPL violations where no source nor offer for source has been
provided. I hate that it takes so much time to resolve violations
because of the sheer magnitude that exist.

I got into GPL enforcement so heavily, frankly, because so few others
were doing it. To this day, there are basically three groups even
bothering to enforce GPL on behalf of the
community: Conservancy (with
enforcement efforts led by
me), FSF (with
enforcement efforts led
by Brett Smith),
and gpl-violations.org (with
enforcement efforts led
by Harald Welte).
Generally, GPL enforcement has been a relatively lonely world for a long
time, mainly because it’s boring, tedious and patience-trying work that
only the most dedicated (masochistic?) want to spend their time
doing.

There are a dozen of very important software-freedom-advancing
activities that I’d rather spend my time doing. But as long as people
don’t respect the freedom of software users and ignore the important
protections of copyleft, I have to continue doing GPL enforcement. Any
effort like LF’s is very welcome, provided that it reduces the number of
violations.

Of course, LF (as GPL educators) and Brett, Harald, and I (as GPL
enforcers) will share the biggest obstacle: getting communication going
with the actual violators. Fact is, people who know the LF exists or have
heard of the GPL are likely to already be in compliance. When I find a
new violation, it’s nearly always someone who doesn’t even know what’s
going on, and often doesn’t even realize what their engineering team put
into their firmware. If LF can reach these companies before they end up as
a violation report emailed to me, I’ll be as glad as can be. But it’s a
tall order.

I do have a few minor criticisms of LF’s program. First, I believe
the directory
of FLOSS Compliance Officers
should be made publicly available. I
think FLOSS Compliance Officers at companies should make themselves
publicly known in the software freedom community so they can be
contacted directly. As LF currently has it set up, you have
to make a request of the LF to put you in touch with a company’s
compliance officer.

Second, I admit I’d have liked to have been actively engaged in LF’s
process of forming this program. But, I presume that they wanted as
much distance as possible from the world’s most prolific GPL enforcer,
and I can understand that. (I suppose there’s a good cop/bad cop
metaphor you could make here, but I don’t like to think of myself as the
GPL police.) I did offer to help LF on this back in April when they
announced it at the Linux Collaboration Summit, but they haven’t been in
touch. Nevertheless, I’ll hopefully meet with LF folks on Thursday at
LinuxCon about their program. Also, I was invited a few months ago by
Martin Michlmayr to join one subset of the project, the
SPDX
working group
and I’ve been giving it time whenever I can.

But, as I said, those are only minor complaints. The program as a
whole looks like it might do some good. I hope companies take advantage
of it, and more importantly, I hope LF can reach out to the companies
who don’t know their name yet but have BusyBox/Linux embedded in their
products.

Please, LF, help free me from the grind of GPL enforcement work. I
remain committed to enforcing GPL until there are no violations left,
but if LF can actually bring about an end to GPL violations sooner
rather than later, I’ll be much obliged. In a year, if I have an empty
queue of GPL violations, I’ll call LF’s program a unmitigated
success and gladly move on to other urgent work to advance software
freedom.

“Have To” Is a Relative Phrase

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/08/09/have-to-use.html

I often hear it. I have to use proprietary software, people
say. But usually, that’s a justification and an excuse. Saying have
to implies that they’ve been compelled by some external force to do
it.

It begs the question: Who’s doing the forcing? I don’t deny
there might be occasions with a certain amount of force. Imagine if
you’re unemployed, and you’ve spent months looking for a job. You
finally get one, but it generally doesn’t have anything to do with
software. After working a few weeks, your boss says you have to use a
Microsoft Windows computer. Your choices are: use the software or be
fired and spend months again looking for a job. In that case, if you
told me you have to use proprietary software, I’d easily
agree.

But, imagine people who just have something they want to do, completely
unrelated to their job, that is made convenient with proprietary
software. In that case, there is no have to. One doesn’t have
to do a side project. So, it’s a choice. The right phrase
is wanted to, not have to.

Saying that you’re forced to do something when you really aren’t is a
failure to take responsibility for your actions. I generally don’t
think users of proprietary software are primarily to blame for the
challenges of software freedom — nearly all the blame lies with
those who write, market, and distribute proprietary software. However,
I think that software users should be clear about why they are using the
software. It’s quite rare for someone to be compelled under threat of
economic (or other) harm to use proprietary software. Therefore, only
rarely is it justifiable to say you have to use proprietary
software. In most cases, saying so is just making an excuse.

As for being forced to develop proprietary software, I think it’s
even rarer yet. Back in 1991 when I first
read the GNU
Manifesto
, I was moved by RMS’ words about the issue:

“Won’t programmers starve?”

I could answer that nobody is forced to be a programmer. Most of us
cannot manage to get any money for standing on the street and making
faces. But we are not, as a result, condemned to spend our lives standing
on the street making faces, and starving. We do something else.

But that is the wrong answer because it accepts the questioner’s
implicit assumption: that without ownership of software, programmers
cannot possibly be paid a cent. Supposedly it is all or nothing.

Well, even if it is all or nothing, RMS was actually right
about this: we can do something else. By the mid 1990s, these words had
inspired me to make a lifelong plan to make sure I’d never have to write
or support proprietary software again. Despite being trained primarily
as a computer scientist, I’ve spent much time building contingency plans
to make sure I wouldn’t be left with proprietary software support or
development as my only marketable skill.

During the 1990s, it wasn’t clear that software freedom would have any
success at all. It was a fringe activity; Cygnus was roughly
the only for-profit company able to employ people to
write Free Software. As such, I of course started learning the GCC
codebase, figuring that I’d maybe someday get a job at Cygnus. I also
started training as an American Sign Language translator, so I’d have a
fallback career if I didn’t get a job at Cygnus. Later, I learned how
to play poker really well, figuring that in a worst case, I could end up
as a professional poker player permanently.

As it turned out, I’ve never had to rely fully on these fallback plans,
primarily because I was hired by the FSF in 1999. For the last eleven
years, I have been able to ensure that I’ve never had a job that
required that I use, support, or write proprietary software and I’ve
worked only on activities that directly advanced software freedom. I
admit I was often afraid that someday I might be unable to find a job,
and I’d have to support, use or write proprietary software
again. Yet, despite that fear, since 1997, I’ve never even been close
to that.

So, honestly, I just don’t believe those who say they have to
use proprietary software. Almost always, they chose to use
it, because it’s more convenient than the other things they’d have to
do to avoid it. Or, perhaps, they’d rather write or use proprietary
software than write or use no software at all, even when avoiding
software entirely was a viable option.

In summary, I want to be clear that I don’t judge people who use
proprietary software. I realize not everyone wants to live their life
as I do — with cascading fallback plans to avoid using, writing or
supporting proprietary software. I nevertheless think it’s disingenuous
to say you have to use, support or develop proprietary
software. It’s a choice, and every year that goes by, the choice gets
easier, so the statement sounds more like an excuse all the time.

ISO 27001 в столовата

Post Syndicated from RealEnder original http://alex.stanev.org/blog/?p=248

Сигурен съм, че сте чели старата история за хакера в стола. Тъй като отново съм на тема ISO 27001:2005, нека направим едно упражнение, при което ще проследим как ще се развие събитието, ако в стола има внедрена Система за управление на информационната сигурност.
Ден 1-ви
Хакер влиза в обществена столова и с възмущение забелязва, че всеки може да развие солницата и да сипе вътре каквото и да е. Прибира се той вкъщи и пише гневно писмо на директора: “Аз, [email protected]|, открих уязвимост на солниците във Вашата столова. Злоумишленик може да сипе в тях отрова. Вземете мерки спешно!”
Ден 2-ри
Директорът сред прочие делови писма прочита горното и вдига рамене: “На кой идиот може да му дойде това на ума?”
Директорът на столовата разпределя документа на Отговорника по информационна сигурност по компетенция. Последният размишлява известно време дали да попълни Доклад за инцидент, Предложение за превантивно действие, направо Искане за коригиращо действие или някой друг документ, на който не му помни името. Свързва се с Консултантите, които обаче са заети с други клиенти и така или иначе не помнят какво са писали в Процедурите и Политиките за информационна сигурност. Те го финтират финно, като му обясняват, че откато са предали системата в ръцете на клиента, вероятно е имало развитие и не искат в желанието си да помогнат да навредят. На финала на разговора, му споменават, че всякакви ги имало и да не обръща внимание на такива простотии.
Спокоен, отговорникът забутва писмото в “шкафа, където одиторите не гледат” и забравя за случая.
Ден 5-ти
Хакерът идва в столовата и сипва във всички солници отрова. Загиват 300 души, директора три месеца го влачат в следствие и съд и го оправдават за липса на престъпен състав. Хакерът пише писмо в стил “Видяхте ли?!!”
Вече съмнение няма и машината се задейства. Събира се Форумът по информационна сигурност, Консултантите са викнати по спешност, срещу съответното възнаграждение. Отговорникът прилежно е попълнил Доклад за инцидент, добавил го е в Регистъра на инцидентите, запознал е чрез Докладна-записка Групата за връзки с обществеността (Главният готвач и една от по-приказливите лелички), прегледал е окло 18 пъти Планът за непрекъсваемост на дейността, Матрицата за достъп, както и други странни документи. Консултантите проверяват всички записи и уверяват клиента, че системата работи.
След освобождаването на Директора от предварителния арест, на заседание на Форумът по информационна сигурност се набелязват допълнителните контроли, с които ще се третира критичният ресурс (солниците), получава се одобрение за финансиране на дейността, а Планът за третиране на риска се допълва с още множество записи с отстояние близкото бъдеще.
Ден 96-ти
Директорът купува солници със специално проектиран катинар с код. Посетителите чувстват, че някаква идея в тоя живот им убягва.
Ден 97-ми
Хакерът забелязва, че дупките в солниците пропускат сол в двете посоки. И не само сол. Той пише възмутено писмо на директора и пикае във всички солници. 300 човека престават да посещават столовата, 30 попадат в болница с отравяне. За капак пише на директора СМС “Как е?” Директора три месеца го мотаят по съдилища и му дават година условно.
След повторното поругаване на Системата, което съвпада с ресертификационният одит, Сертификаторът отнема издадения сертификат и обяснява, че го правят с ясното съзнание, че това е в полза на клиента(обществения стол). Форумът по информационна сигурност се събира и единодушно хвърля вината върху “калпавите консултанти, които нищо не разбират”. Намират нови и поканват нов Сертификатор от чужбина, който в желанието си да стъпи на местна територия си затваря очите за събитията от последните месеци.
Новите консултанти преглеждат внимателно всичко, обясняват колко погрешен и несъобразен е бил подходът на предходните и как доказателствата за това са в папката с Инцидентите.
Обръщат системата с главата надолу, правят опресняващо обучение на персонала и проверяват осъзнатостта. Наемат се технически експерти, които правят penetration тестове и пишат дълги назидателни доклади.
Ден 188-ми
Директорът се заклева до края на живота си да няма нищо общо със заведения за хранене и мирно да пренася дървени трупи в Сибир. Инженерите разработват нова конструкция солници с едностранна клапа. Междувременно сервитьорките прибират старите солници и раздават сол по заявка.
Ден 190-ти
Хакерът гепва 1 нова солница от стола и вкъщи изучава устройството й. Пише гневно писмо на новия директор: “Аз, [email protected]|, задигнах 1 солница и намирам този факт за възмутителен! Всеки може да задигне солница от Вашата столова!” Директорът – заклет трезвеник – прочита писмото, прибира се вкъщи и удря една водка.
На другия ден, след пълна инвентаризация, отново се попълва Доклад за инцидент. Преглеждат се записите от видеонаблюдението и Дневниците на на сервитьорките с раздадените солници срещу подпис. С помощта на консултантите се извършва кросчек на обективните доказателства, който ограничава кръга на заподозрените до около 50 човека. Междувременно, Отговорникът по информационна сигурност наказва с Искания за коригиращи действия всеки, който срещне случайно в коридорите, в резултат на което служебните и клиентски тоалетни се препълват с изпокрили се служители на стола.
Ден 193-ти
Хакерът отива в стола и вижда, че всички солници са закрепени към масите с вериги. На поредната сбирка на хакерите се похвалва със своите успехи и получава заслужена награда за защита интересите на обществото и потребителите. За щастие директорът не научава за това и няма да се пропие преждевременно.
 
Ден 194-ти
В рамките на гениално обмислена операция всички хакери от сбирката се промъкват в столовата и изсипват всичката сол в джобовете си. Хакерът [email protected]| пише възмутено писмо на директора, че в тази столова няма никаква грижа към потребителя и всеки може да лиши честния човек от сол за един миг. Спешно са нужни дозатори на солта, работещи след логване с парола.
Системата обаче вече работи. Тъй като за инцидента не се разчува, а и от столовата са нямали време за цялата хамалогия около внедряването, консултантите дават умната идея документално нещата да се оформят като тренировка на Плана за непрекъсваемост на дейността. Допълнително се добавят записи и за сценариите “Земетресение” и “Луда крава”.
Относно идеята за паролата, местния админ гуру обяснява, че тези неща не се правят така на парче и ще се помисли за цялостно решение, в унисон с най-добрите световни практики. Изпращат го навън за няколко месеца, за да почерпи знание от извора. Благодарение на обширните си познания и практика по ISO 27001, там си намира по-добра работа и се спасява с декларацията, че вече нещата са стабилни и полето за изява в столовата е му е отесняло.
Работата му се поема от висококвалифициран инженерен екип, който разработва envisioning документ за внедряване на Enterprise Architecture в столовата, след това работи и по проблема със солниците.
Ден 196-ти
Инженерите с пот на лицата работят над нов модел солница, докато сервитьорките пак раздават сол по заявка. Директорът си взема отпуск и заминава на Сейшелските острови, където се храни само в стаята си в хотела, избягвайки закусвални, ресторанти и барове.
 
Ден 200
Посетителите на столовата с ужас откриват, че за да си сипят малко сол, трябва да отидат при сервитьорката и да си покажат личната карта, за да получат специален 8-символен код за еднократна употреба за активиране на солницата. За черния пипер процедурата се повтаря.
Доволен от постигнатото, директорът изпраща поздравителен мейл към служителите, като им напомня, че това е само началото и предстои сертификация и по още няколко наболели стандарта.

GUADEC 2010: Rate Conferences by Inspiration Value

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/08/05/guadec.html

Conferences are often ephemeral. I’ve been going to
FLOSS
conferences since before there were conferences specifically for the
topic. In the 1990s, I’d started attending various USENIX conferences.
Many of my career successes can be traced back to attending those
conferences and meeting key leaders in the FLOSS world. While I know
this is true generally, I can’t really recall, without reviewing notes
from specific conferences, what happened at them, and how specifically it
helped me personally or FLOSS in general. I know they’re important to me
and to software freedom, but it’s tough to connect the dots perfectly
without looking in detail at what happened when.

Indeed, for most of us, after decades, conferences start to run
together. At GUADEC this year, I had at least two conversations of the
nature: What city was that? What conference was that? Wait, what
year was that?. And that was just discussions about past
GUADECs specifically, let alone other events!

For my part, after checking my records, I discovered that I hadn’t been
to a GUADEC since 2003. I’ve served as FSF’s representative on the
GNOME Advisory Board straight through from 2001 until today, but
nevertheless I hadn’t been able to attend GUADECs from 2004-2009. Thus,
the 2010 GUADEC was somewhat of a reintroduction for me to the in-person
GNOME community.

With fresh eyes, what I saw had great impact on me. GNOME seems to be
a vibrant, healthy community, with many contributors and incredible
diversity in both for-profit and volunteer contributions. GNOME’s
growth and project diversity has greatly exceeded what I would have
expected to see between 2004 and 2010.

It’s not often I go to a conference and am jealous that I can’t be more
engaged as a developer. I readily admit that I haven’t coded regularly
in more than a decade (and I often long to do it again). But, I usually
talk myself out of it when I remember the difficultly of getting
involved and in shepherding work upstream. It’s a non-trivial job, and
some don’t even bother. The challenges are usually enough to keep the
enticement at bay.

Yet, I left GUADEC 2010 and couldn’t see a downside in getting
involved. I found myself on the flight back wishing I could do more,
thinking through the projects I saw and wondering how I might be a coder
again. There must be some time on the weekends somewhere, I
thought, and while I’m not a GUI programmer, there’s plenty of system
stuff in GNOME
like dbus
and systemd;
surely I can contribute there.

Fact is, I’ve got too many other FLOSS-world responsibilities and I
must admit I probably won’t contribute code, despite wanting to. What’s
amazing, though, is that everything about GUADEC made me want
to get more involved and there appeared no downside in doing
so. There’s something special about a conference (and a community) that
can inspire that feeling in a hardened, decade-long conference attendee.
I interact with a lot of FLOSS communities, and GNOME is probably the
most welcoming of all.

The rest of this post is a random bullet list of cool things that
happened at GUADEC that I witnessed/heard/thought about:

There was a lot of debate and concern about
the change
in the GNOME 3 release schedule
. I was impressed at the community
unity on this topic when I heard a developer say in the hall: The
change in GNOME 3 schedule is bad for me, but it’s clearly the right
thing for GNOME, so I support it. That’s representative of the
“all for one” and selfless attitude you’ll find in the GNOME
community.

Dave
Neary presented

a very
interesting study on GNOME code contributions
, which he was
convinced to release under CC-By-SA. The study has caused some rancor
in the community about who does or does not contribute to GNOME
upstream, but generally speaking, I’m glad the data is out there, and
I’m glad Dave’s released it under a license that allows people to
build on the work and reproduce and/or verify the results. (Dave’s
also assured me he’ll release the tools and config files and all other
materials under FaiF licenses
as well; I’ll put a link here when he has one.) Thing is, the most
important and wonderful datum from Dave’s study is that
a plurality of GNOME contribution comes from
volunteers: a full 23%! I think every FLOSS project needs a plurality
of volunteer contribution to truly be healthy, and it seems GNOME has
it.

My talk on GPLv3 was reasonably well received, notwithstanding some
friendly kibitzing
from Michael Meeks.
There had been push back in previous discussions in the GNOME community
about GPLv3. It seems now, however, that developers are interested in
the license. It’s not my goal to force anyone to switch, but I hope
that my talk
and my
participation
in
this recent
LGPLv3 thread on desktop-list
might help to encourage a
slow-but-sure migration to GPLv3-or-later (for applications) and
(GPLv2|LGPLv3-or-later) (for platform libraries) in GNOME. If folks
have questions about the idea, I’m always happy to discuss them.

I enjoyed rooming
with Brad Taylor.
We did wonder, though, if the GNOME Travel Committee assigned us rooms by similar
first names. (In fact, I was so focused that on the fact that we shared
the same first name, I previously had typed Brad’s last name wrong
here!) I liked hearing about
his TomBoy online project,
Snowy
. I’m obviously delighted to see adoption
of AGPLv3, the
license
I helped create
. I’ve promised Brad that I’ll try to see if I can
convince the org-mode community to use Snowy for its online storage as
well.

Owen Taylor demoed and spoke
about GNOME
Shell 3.0
. I don’t use GUIs much myself, but I can see how
GUI-loving users will really enjoy this excellent work.

I met Lennart Poettering and
discussed with him in detail
the systemd
project. While I can see how this could be construed as a Canonical/Red
Hat fight over the future of what’s used for system startup, I still was
impressed with Lennart’s approach technically, and find it much
healthier that his community isn’t requiring copyright assignment.

Emmanuele Bassi‘s
talk on Clutter was
inspiring, as he delivered heartfelt slide indicating that he’d overcome
the copyright assignment requirements and assignment is no longer
required by Intel for Clutter upstream contributions. I like to believe
that
Vincent
Untz
‘s, Michael
Meeks
‘ and my work on the (yet to be
ratified) GNOME
Copyright Assignment Policy
was a help to Emmanuele’s efforts in
this regard. However, it sounds to me like the outcome was primarily
due to a lot of personal effort on Emmanuele’s part internally to get
Intel to DTRT. I thank him for this effort and congratulate him on that
success.

It was great to finally meet Fabian
Scherschel
in person. He kindly brought me some gifts from
Germany and I brought him some gifts from the USA (we prearranged it;
I guess that’s the “outlaw” version of gifts). Fab also
got some good interviews
for the Linux Outlaws podcast
that he does
with Dan Lynch. It seems that
podcast has been heavily linked to in the GNOME community, which is
really good for Dan and Fab and for GNOME, I think.

Sponsored by the GNOME Foundation!

That’s about all the random thoughts and observations I have from
GUADEC. The conference was excellent, and I think I simply must readd
it to my “must attend each year” list.

Finally, I want to thank the GNOME Foundation for sponsoring my travel
costs. It allowed me to take some vacation time from my day job to attend
and participate in GUADEC.

More GPL Enforcement Progress

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/08/03/more-gpl-success.html

LWN is reporting a
GPL
enforcement story
that I learned about during last week while at
GUADEC (excellent conference, BTW,
blog post on that later this week). I wasn’t sure if it was really of
interest to everyone, but since it’s hit the press, I figured I’d write
a brief post to mention it.

As many probably know, I’m president of
the Software Freedom
Conservancy
, which is the non-profit organizational home of the
BusyBox project. As part of my role at
Conservancy, I help BusyBox in its GPL enforcement efforts.
Specifically and currently,
Conservancy is in litigation against a number of defendants who have
violated the GPL and were initially unresponsive to Conservancy’s
attempts to bring them into compliance with the terms of the
license.

A few months ago, one of those defendants, Westinghouse Digital
Electronics, LLC, stopped responding to issues regarding the lawsuit.
On Conservancy’s behalf, SFLC asked the judge to issue a default
judgment against them. A “default” means what it looks
like: Conservancy asked to “win by default” since
Westinghouse stopped showing up. And, last
week, Conservancy
was granted a default judgment against Westinghouse
, which included
an injunction to stop their GPL-non-compliant distributions of
BusyBox.

“Injunctive Relief”, as the lawyers call it, is a really
important thing for GPL enforcement. Obviously our primary goal is full
compliance with the GPL, which means giving the complete and
corresponding source code (C&CS, as I tend to abbreviate it) to all
those who received binary distributions of the software. Unfortunately,
in some cases (for example, when a company simply won’t cooperate in the
process despite many efforts to convince them to do so), the only option
is to stop further distribution of the violating software. As many
parts of the GPL itself point out, it’s better to not have software
distributed at all, if it’s only being distributed as (de facto)
proprietary software.

I’m really glad that a judge has agreed that the GPL is important
enough a license to warrant an injunction on out-of-compliance
distribution. This is a major step forward in GPL enforcement in the
USA. (Please note
that Harald Welte had
past similar successes in Germany, and deserves credit and kudos for
getting this done the first time in the world. This success follows in
his footsteps.)

Dear Canonical,

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/sound-theme-canonical.html

#ignore yes

Today I came
across this blog post of your design team
. In context of the recent
criticism you had to endure regarding upstream contributions I am disappointed
that you have not bothered to ping anybody from the upstream freedesktop sound
theme (for example yours truly) about this in advance. No, you went to cook
your own soup. What really disappoints me is that we have asked multiple times
for help and support and contributions for the sound theme, to only very little
success, and I even asked some of the Canonical engineers about this topic and
in particular regarding some clarifications of the licensing of the old Ubuntu
sound theme. I am sorry, but if you had listened, or looked, or asked you would
have been aware that we were looking for somebody to maintain this actively,
upstream — and because we didn’t have the time to maintain this we only
did the absolute minimum work necessary and we only maintain this ourselves
because noone else wanted to.

It should be upstream first, downstream second.

I am sorry if I sound like an always complaining prick to you. But believe
me, I am not saying this because I wouldn’t like you or anything like that.
I am just saying this because I believe you could do things
oh so much better.

Please fix this. We want your contributions. Upstream.

Dear Canonical,

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/sound-theme-canonical.html

#ignore yes

Today I came
across this blog post of your design team
. In context of the recent
criticism you had to endure regarding upstream contributions I am disappointed
that you have not bothered to ping anybody from the upstream freedesktop sound
theme (for example yours truly) about this in advance. No, you went to cook
your own soup. What really disappoints me is that we have asked multiple times
for help and support and contributions for the sound theme, to only very little
success, and I even asked some of the Canonical engineers about this topic and
in particular regarding some clarifications of the licensing of the old Ubuntu
sound theme. I am sorry, but if you had listened, or looked, or asked you would
have been aware that we were looking for somebody to maintain this actively,
upstream — and because we didn’t have the time to maintain this we only
did the absolute minimum work necessary and we only maintain this ourselves
because noone else wanted to.

It should be upstream first, downstream second.

I am sorry if I sound like an always complaining prick to you. But believe
me, I am not saying this because I wouldn’t like you or anything like that.
I am just saying this because I believe you could do things
oh so much better.

Please fix this. We want your contributions. Upstream.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close