Agrégateur de flux

Erich Schubert: Avoiding systemd isn't hard

Planet Debian - mar, 21/10/2014 - 14:17
Don't listen to trolls. They lie. Debian was and continues to be about choice. Previously, you could configure Debian to use other init systems, and you can continue to do so in the future. In fact, with wheezy, sysvinit was essential. In the words of trolls, Debian "forced" you to install SysV init! With jessie, it will become easier to choose the init system, because neither init system is essential now. Instead, there is an essential meta-package "init", which requires you to install one of systemd-sysv | sysvinit-core | upstart. In other words, you have more choice than ever before. Again: don't listen to trolls. However, notice that there are some programs such as login managers (e.g. gdm3) which have an upstream dependency on systemd. gdm3 links against libsystemd0 and depends on libpam-systemd; and the latter depends on systemd-sysv | systemd-shim so it is in fact a software such as GNOME that is pulling systemd onto your computer. IMHO you should give systemd a try. There are some broken (SysV-) init scripts that cause problems with systemd; but many of these cases have now been fixed - not in systemd, but in the broken init script. However, here is a clean way to prevent systemd from being installed when you upgrade to jessie. (No need to "fork" Debian for this, which just demonstrates how uninformed some trolls are ... - apart from Debian being very open to custom debian distributions, which can easily be made without "forking".) As you should know, apt allows version pinning. This is the proper way to prevent a package from being installed. All you need to do is create a file named e.g. /etc/apt/preferences.d/no-systemd with the contents: Package: systemd-sysv Pin: release o=Debian Pin-Priority: -1 from the documentation, a priority less than 0 disallows the package from being installed. systemd-sysv is the package that would enable systemd as your default init (/sbin/init). This change will make it much harder for aptitude to solve dependencies. A good way to help it to solve the dependencies is to install the systemd-shim package explicitly first: aptitude install systemd-shim After this, I could upgrade a Debian system from wheezy to jessie without being "forced" to use systemd... In fact, I could also do an aptitude remove systemd systemd-shim. But that would have required the uninstallation of GNOME, gdm3 and network-manager - you may or may not be willing to do this. On a server, there shouldn't be any component actually depending on systemd at all. systemd is mostly a GNOME-desktop thing as of now. As you can see, the trolls are totally blaming the wrong people, for the wrong reasons... and in fact, the trolls make up false claims (as a fact, systemd-shim was updated on Oct 14). Stop listening to trolls, please. If you find a bug - a package that needlessly depends on systemd, or a good way to remove some dependency e.g. via dynamic linking, please contribute a patch upstream and file a bug. Solve problems at the package/bug level, instead of wasting time doing hate speeches.
Catégories: Elsewhere

undpaul: Make your styleguide a living styleguide!

Planet Drupal - mar, 21/10/2014 - 08:09

Don't you know that, too? You or your team is building a site and during this process all implemented parts are styled through templates and CSS. The CSS files (at best you are using a CSS preprocessor like SASS) are getting bigger, more sophisticated and even more confusing - not to mention that these files are getting almost unmaintainable and more and more error-prone.

drupal planet englishCSS
Catégories: Elsewhere

Thomas Goirand: OpenStack Juno is out, Debian (and Ubuntu Trusty ports) packages ready

Planet Debian - mar, 21/10/2014 - 07:45

This is just a quick announce: Debian packages for Juno are out. In fact, they were ready the day of the release, on the 16th of October. I uploaded it all (to Experimental) the same day, literally a few hours after the final released was git tagged. But I had no time to announce it.

This week-end, I took the time to do an Ubuntu Trusty port, which I also publish (it’s just a mater of rebuilding all, and it should work out of the box). Here are the backports repositories. For Wheezy:

deb http://archive.gplhost.com/debian juno-backports main

deb http://archive.gplhost.com/debian juno main

For trusty:

deb http://archive.gplhost.com/debian trusty-juno-backports main

But of course, everything is also available directly in Debian. Since Sid/Jessie contains OpenStack Icehouse (which has more chance to receive long enough security support), and it will be like this until Jessie is released. So I have uploaded all of Juno into Debian Experimental. This shows on the OpenStack qa page (you may also notice that the team is nearly reaching 200 packages… though am planning to off-load some of that to the Python module team, when the migration to Git will be finished). On the QA page, you may also see that I uploaded all of the last Icehouse point release to Sid, and that all packages migrated to Jessie. There’s only a few minor issues with some Python modules which I fixed, that haven’t migrated to Jessie yet.

I can already tell that all packages can be installed without an issue, and that I know Horizon at least works as expected. But I didn’t have time to test it all just yet. I’m currently working on doing even more installation automation at the package level (by providing some OVS bridging init script and such, to make it more easy to run Tempest functional testing). I’ll post more about this when it’s ready.

Catégories: Elsewhere

Drupal @ Penn State: Drupal speed tuning: analyzing and further optimizing Pressflow

Planet Drupal - lun, 20/10/2014 - 22:46

TL;DR: I've created a fork of Pressflow for the purposes of conversation and analysis -- https://github.com/btopro/Presser-Flow-FORK

History lesson

Catégories: Elsewhere

Acquia: DrupalCon Amsterdam Top Ten – Part 1 of 2 with Kris Vanderwater

Planet Drupal - lun, 20/10/2014 - 19:34

Part 1 of 2 – Kris Vanderwater (EclipseGc), Acquia’s Developer Evangelist, and I got together in a Google Hangout to catch up on our impressions of DrupalCon Amsterdam. We prepared a list of our top ten sessions from the Con for you to catch up with at home (technically nine sessions and one “other cool thing”). In our list, there’s a little something for most everyone, from coders, to themers, to site builders, to those of us who pitch sell Drupal to clients – but we would recommend all of these sessions to anyone involved in Drupal. See how the other side lives!

Catégories: Elsewhere

SitePoint PHP Drupal: Drupal 8 Hooks and the Symfony Event Dispatcher

Planet Drupal - lun, 20/10/2014 - 18:00

With the incorporation of many Symfony components into Drupal in its 8th version, we are seeing a shift away from many Drupalisms towards more modern PHP architectural decisions. For example, the both loved and hated hook system is getting slowly replaced. Plugins and annotations are taking away much of the need for info hooks and the Symfony Event Dispatcher component is replacing some of the invoked hooks. Although they remain strong in Drupal 8, it’s very possible that with Drupal 9 (or maybe 10) hooks will be completely removed.

In this article we are going to primarily look at how the Symfony Event Dispatcher component works in Drupal. Additionally, we will see also how to invoke and then implement a hook in Drupal 8 to achieve similar goals as with the former.

To follow along or to get quickly started, you can find all the code we work with here in this repository. You can just install the module and you are good to go. The version of Drupal 8 used is the first BETA release so it’s preferable to use that one to ensure compatibility. Alpha 15 should also work just fine. Let’s dive in.

What is the Event Dispatcher component?

A very good definition of the Event Dispatcher component can be found on the Symfony website:

The EventDispatcher component provides tools that allow your application components to communicate with each other by dispatching events and listening to them.

I recommend reading up on that documentation to better understand the principles behind the event dispatcher. You will get a good introduction to how it works in Symfony so we will not cover that here. Rather, we will see an example of how you can use it in Drupal 8.

Continue reading %Drupal 8 Hooks and the Symfony Event Dispatcher%

Catégories: Elsewhere

Drupal core announcements: Let's fix critical Drupal 8 issues together!

Planet Drupal - lun, 20/10/2014 - 17:57

Every Friday at noon Pacific (3pm New York, 9pm Berlin, 6am Saturday in Sydney) I will be in #drupal-contribute helping people fix critical issues. I will prepare 2-3 issues with up to date, actionable issue summaries, familiarize myself with the problems and the suggested solution in the issue so that I can answer questions.

If you're someone who has already worked some in the Drupal.org issue queue (so are familiar with patches, coding standards, etc.), even if your experience is not in the core queue, please come by! It's helpful if you know something of Drupal 8 as well, but not necessary.

If you're new to contributing to Drupal in general, you can go to https://www.drupal.org/core-mentoring for a session or two to learn the skills you need to fix critical issues. If you're new to Drupal 8, https://api.drupal.org/api/drupal/8 is a great starting point.

Hope to see you there!

Catégories: Elsewhere

Phase2: Simplify Your Logstash Configuration

Planet Drupal - lun, 20/10/2014 - 16:16

As I mentioned in my recent post, I got a chance to upgrade the drupal.org ELK stack last week. In doing so, I got to take a look at a Logstash configuration that I created over a year ago, and in the course of doing so, clean up some less-than-optimal configurations based on a year worth of experience and simplify the configuration file a great deal.

The Drupal.org Logging Setup

Drupal.org is served by a large (and growing) number of servers. They all ship their logs to a central logging server for archival, and around a month’s worth are kept in the ELK stack for analysis.

Logs for Varnish, Apache, and syslog are forwarded to a centralized log server for analysis by Logstash. Drupal messages are output to syslog using Drupal core’s syslog module so that logging does not add writes to Drupal.org’s busy database servers. (@TODO: Check if these paths can be published.) Apache logs end up in/var/log/apache_logs/$MACHINE/$VHOST/transfer/$DATE.log, Varnish logs end up in/var/log/varnish_logs/$MACHINE/varnishncsa-$DATE.log and syslog logs end up in /var/log/HOSTS/$MACHINE/$DATE.log. All types of logs get gzipped 1 day after they are closed to save disk space.

Pulling Contextual Smarts From Logs

The Varnish and Apache logs do not contain any content in the logfiles to identify which machine they are from, but the file input sets a path field that can be matched with grok to pull out the machine name from the path and put it into the logsource field, which Grok’s SYSLOGLINE pattern will set when analyzing syslog logs.

Filtering on the logsource field can be quite helpful in the Kibana web UI if a single machine is suspected of behaving weirdly.

Using Grok Overwrite

Consider this snippet from the original version of the Varnish configuration. As I mentioned in my presentation, Varnish logs are nice in that they inclue the HTTP Host header so that you can see exactly which hostname or IP was requested. This makes sense for a daemon like Varnish which does not necessarily have a native concept of virtual hosts (vhosts,) whereas nginx and Apache default to logging by vhost.

Each Logstash configuration snippet shown below assumes that Apache and Varnish logs have already been processed using theCOMBINEDAPACHELOG grok pattern, like so.

filter { if [type] == "varnish" or [type] == "apache" { grok { match => [ "message", "%{COMBINEDAPACHELOG}" ] } } }

The following snippet was used to normalize Varnish’s request headers to not include https?:// and the Host header so that therequest field in Apache and Varnish logs will be exactly the same and any filtering of web logs can be performed with the vhost andlogsource fields.

filter { if [type] == "varnish" { grok { # Overwrite host for Varnish messages so that it's not always "loghost". match => [ "path", "/var/log/varnish_logs/%{HOST:logsource}" ] } # Grab the vhost and a "request" that matches Apache from the "request" variable for now. mutate { add_field => [ "full_request", "%{request}" ] } mutate { remove_field => "request" } grok { match => [ "full_request", "https?://%{IPORHOST:vhost}%{GREEDYDATA:request}" ] } mutate { remove_field => "full_request" } } }

As written, this snippet copies the request field into a new field called full_request and then unsets the original request field and then uses a grok filter to parse both the vhost and request fields out of that synthesized full_request field. Finally, it deletesfull_request.

The original approach works, but it takes a number of step and mutations to work. The grok filter has a parameter calledoverwrite that allows this configuration stanza to be considerably simlified. The overwrite paramter accepts an array of values thatgrok should overwrite if it finds matches. By using overwrite, I was able to remove all of the mutate filters from my configuration, and the enture thing now looks like the following.

filter { if [type] == "varnish" { grok { # Overwrite host for Varnish messages so that it's not always "loghost". # Grab the vhost and a "request" that matches Apache from the "request" variable for now. match => { "path" => "/var/log/varnish_logs/%{HOST:logsource}" "request" => "https?://%{IPORHOST:vhost}%{GREEDYDATA:request}" } overwrite => [ "request" ] } } }

Much simpler, isn’t it? 2 grok filters and 3 mutate filters have been combined into a single grok filter with two matching patterns and a single field that it can overwrite. Also note that this version of the configuration passes a hash into the grok filter. Every example I’ve seen just passes an array to grok, but the documentation for the grok filter states that it takes a hash, and this works fine.

Ensuring Field Types

Recent versions of Kibana have also gotten the useful ability to do statistics calculations on the current working dataset. So for example, you can have Kibana display the mean number of bytes sent or the standard deviation of backend response times (if you are capturing them – see my DrupalCon Amsterdam slides for more information on how to do this and how to normalize it between Apache, nginx, and Varnish.) Then, if you filter down to all requests for a single vhost or a set of paths, the statistics will update.

Kibana will only show this option for numerical fields, however, and by default any data that has been parsed with a grok filter will be a string. Converting string fields to other types is a much better use of the mutate filter. Here is an example of converting the bytes and the response code to integers using a mutate filer.

@TODO: Test that hash syntax works here!

filter { if [type] == "varnish" or [type] == "apache" { mutate { convert => { [ "bytes", "response" ] => "integer", } } } }

Lessons Learned

Logstash is a very powerful tool, and small things like the grokoverwrite parameter and the mutate convert parameter can help make your log processing configuration simpler and result in more usefulness out of your ELK cluster. Check out Chris Johnson’s post about adding MySQL Slow Query Logs to Logstash!

If you have any other useful Logstash tips and tricks, leave them in the comments!

 

Catégories: Elsewhere

4Sitestudios.com Drupal Blog: Major Drupal 7 Security Vulnerability - Update Now!

Planet Drupal - lun, 20/10/2014 - 16:13

Last week the Drupal security team announced the existence of a major security vulnerability in all versions of Drupal 7. This vulnerability is rated as “highly critical” because it allows an attacker to take full control of your site remotely, without needing to log in as a privileged user. Attacks using this vulnerability are already being reported.

If 4Site built your Drupal 7 site, if we handle your site maintenance, or if you're just looking for someone to help you apply the update on your site and keep your site secure, please contact us!

Catégories: Elsewhere

Michal Čihař: Hosted Weblate has new UI

Planet Debian - lun, 20/10/2014 - 15:00

The biggest part of this HackWeek will be spent on Weblate. The major task is to complete new UI for it. There have been already some blog posts about that here, so regular readers of my blog already know it is using Twitter Bootstrap.

Today it has reached point where I think it's good enough for wider testing and I've deployed it at Hosted Weblate (see Weblate website for conditions for getting hosting there).

I expect there will be some rough edges, so don't hesitate to report any issues, so that I can quickly fix them.

Filed under: English phpMyAdmin SUSE Weblate | 0 comments | Flattr this!

Catégories: Elsewhere

Bluespark Labs: Uninstalling and purging field modules all at once

Planet Drupal - lun, 20/10/2014 - 13:14

Sometimes we want to uninstall a module from our Drupal site but we can't do it because we get this dependency: "Required by: Drupal (Field type(s) in use - see Field list)". Even if you delete the fields provided by the module via the UI or programmatically by executing field_delete_field() function you will get a new dependency "Required by: Drupal (Fields pending deletion)".

These dependencies are created by Drupal core to avoid that a module is uninstalled until all the data related to its fields is removed from the database, in order to maintain consistency.

This has several drawbacks, the first one being that you can't uninstall your module when you want, and you have to wait until all the field data values are removed from the database (The rather strangely named field_deleted_data_XX and field_deleted_revision_XX tables) and the meta-information stored in field_config and field_config_instance tables is removed. And most importantly, nobody actually knows when this is going to happen! These database rows are removed in batches on each cron task execution. So depending on our cron regularity and the amount of data stored in our field tables, this tasks can last for minutes to weeks.

This is a problem because, naturally, we want to uninstall our module now and not be forced to check periodically our production database to see if we are allowed to uninstall the module once all that information has been removed from the database.

To avoid such situations and regain control, you can perform all these tasks in a hook_update_N() function, forcing the deletion of all the information and finally uninstalling the module. You can check the code in the gist below:

The job is divided in three parts: The data definition, field data purge and module list clean.

In the data definition task we provide all the required data we need to perform the task, the name of the field to delete, and given that information, we get the field_info array and the name of the module to be uninstalled. Finally, field_delete_field() is executed.

After that the field data is purged in the batch body, and since we don't know how much data we will have to purge, we remove just 100 database rows per batch execution. After each purge we check if all the data has been removed to decide if we have to remove more data from the database or continue to the final part.

Once all the data and metadata related to the module is removed from the database, the Drupal field types dependency is gone and we are granted the ability to disable and uninstall our module cleanly. Finally, we can drop the empty field_deleted_data_XX and field_deleted_revision_XX tables to keep clean our database.

Using this approach, we have two key benefits: a. we are sure that the module is disabled and our database is clean, and b. we are confident that we can remove the module from our repository, given that in the next deploy we won't get any dependency conflict with that module.

Tags: Drupal Planet
Catégories: Elsewhere

Visitors Voice: That is why we sponsor the Search API Solr module

Planet Drupal - lun, 20/10/2014 - 12:03
Since june 2014 we sponsor the Search API Solr module. There are no strings attached, and we sponsor the maintainer Thomas Seidl a.k.a Drunken Monkey with a couple of hours every month that he can spend as he likes. It could be bug fixing, features asked for or working on the Drupal 8 version. We […]
Catégories: Elsewhere

Michal Čihař: Enca 1.16

Planet Debian - lun, 20/10/2014 - 10:00

As a first tiny project in this HackWeek, Enca 1.16 has been just released. It mostly brings small code cleanups and missing aliases for languages, but fixes also some minor bugs found by Coverity Scan.

If you don't know Enca, it is an Extremely Naive Charset Analyser. It detects character set and encoding of text files and can also convert them to other encodings using either a built-in converter or external libraries and tools like libiconv, librecode, or cstocs.

Full list of changes for 1.16 release:

  • Fixed typo in Belarusian language name
  • Added aliases for Chinese and Yugoslavian languages

Still enca is in maintenance mode only and I have no intentions to write new features. However there is no limitation to other contributors :-).

You can download from http://cihar.com/software/enca/.

Filed under: Enca English SUSE | 0 comments | Flattr this!

Catégories: Elsewhere

Francois Marier: LXC setup on Debian jessie

Planet Debian - lun, 20/10/2014 - 04:00

Here's how to setup LXC-based "chroots" on Debian jessie. While this is documented on the Debian wiki, I had to tweak a few things to get the networking to work on my machine.

Start by installing (as root) the necessary packages:

apt-get install lxc libvirt-bin debootstrap Network setup

I decided to use the default /etc/lxc/default.conf configuration (no change needed here):

lxc.network.type = veth lxc.network.flags = up lxc.network.link = virbr0 lxc.network.hwaddr = 00:FF:AA:xx:xx:xx lxc.network.ipv4 = 0.0.0.0/24

but I had to make sure that the "guests" could connect to the outside world through the "host":

  1. Enable IPv4 forwarding by putting this in /etc/sysctl.conf:

    net.ipv4.ip_forward=1
  2. and then applying it using:

    sysctl -p
  3. Ensure that the network bridge is automatically started on boot:

    virsh -c lxc:/// net-start default virsh -c lxc:/// net-autostart default
  4. and that it's not blocked by the host firewall, by putting this in /etc/network/iptables.up.rules:

    -A INPUT -d 224.0.0.251 -s 192.168.122.1 -j ACCEPT -A INPUT -d 192.168.122.255 -s 192.168.122.1 -j ACCEPT -A INPUT -d 192.168.122.1 -s 192.168.122.0/24 -j ACCEPT
  5. and applying the rules using:

    iptables-apply
Creating a container

Creating a new container (in /var/lib/lxc/) is simple:

sudo MIRROR=http://ftp.nz.debian.org/debian lxc-create -n sid64 -t debian -- -r sid -a amd64

You can start or stop it like this:

sudo lxc-start -n sid64 -d sudo lxc-stop -n sid64 Connecting to a guest using ssh

The ssh server is configured to require pubkey-based authentication for root logins, so you'll need to log into the console:

sudo lxc-stop -n sid64 sudo lxc-start -n sid64

then install a text editor inside the container because the root image doesn't have one by default:

apt-get install vim

then paste your public key in /root/.ssh/authorized_keys.

Then you can exit the console (using Ctrl+a q) and ssh into the container. You can find out what IP address the container received from DHCP by typing this command:

sudo lxc-ls --fancy Fixing Perl locale errors

If you see a bunch of errors like these when you start your container:

perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LANG = "fr_CA.utf8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C").

then log into the container as root and use:

dpkg-reconfigure locales

to enable the same locales as the ones you have configured in the host.

Catégories: Elsewhere

Neil Williams: OpenTAC – an automation lab in a box

Planet Debian - lun, 20/10/2014 - 00:34

I’ve previously covered running LAVA on ARM devices, now that the packages are in Debian. I’ve also covered setting up the home lab, including the difficulty in obtaining the PDU and relying on another machine to provide USB serial converters with inherent problems of needing power to keep the same devices assigned to the same ser2net ports.

There have been ideas about how to improve the situation. Conferences are a prime example – setting up a demo involving LAVA means bringing a range of equipment, separate power bricks, separate network switches (with power bricks), a device of some kind to connect up the USB serial converters (and power brick) and then the LAVA server (with SATA drive and power brick) – that is without the actual devices and their cables and power. Each of those power cables tend to be a metre long, with networking and serial, it quickly becomes a cable spaghetti.

Ideas around this also have application inside larger deployments, so the hardware would need to daisy-chain to provide services to a rack full of test devices.

The objective is a single case providing network, power and serial connectivity to a number of test devices over a single power input and network uplink. Naturally, with a strong free software and open development bias, the unit will be Open Hardware running Debian, albeit with a custom Beaglebone Linux kernel. It’s a Test Automation Controller, so we’re using the name OpenTAC.

Progress

Open hardware ARM device running Debian to automate tests on 4 to 8 devices, initially aimed at LAVA support for Linaro engineers. Power distribution, serial console, network and optional GPIO extensions.

The design involves:

  • A Beaglebone Black (revC)
    • USB hotplug support required, certainly during development.
  • Custom PCB connected as a Beaglebone Cape, designed by Andy Simpkins.
  • Base board provides 4 channels:
    • 5V Power – delivered over USB
    • Ethernet – standard Cat5, no LEDs
    • Serial connectivity
      • RS232
      • UART
    • GPIO
  • Internal gigabit network switch
  • Space for a board like a CubieTruck (with SATA drive) to act as LAVA server
  • Daughter board:
    • Same basic design as the base board, providing another 4 channels, equivalent to the base channels. When the daughter board is fitted, a second network switch would be added instead of the CubieTruck.
  • Power consumption measurement per channel
    • queries made via the Beaglebone Black over arbitrary time periods, including during the test itself.
  • The GPIO lines can be used to work around issues with development boards under test, including closing connections which may be required to get a device to reboot automatically, without manual intervention.
  • Serial connections to test devices can be isolated during device power-cycles – this allows for devices which pull power over the serial connection. (These are typically hardware design issues but the devices still need to be tested until the boards can be modified or replaced.)
  • Thermal control, individual fan control via the Beaglebone Black.
  • 1U case – rackable or used alone on the desk of developers.
  • Software design:
    • lavapdu backend module for PDU control (opentac.py) & opentac daemon on the BBB
      • telnet opentac-01 3225
    • ser2net for serial console control
      • telnet opentac-01 4000

The initial schematics are now complete and undergoing design review. A lot of work remains …

Catégories: Elsewhere

Dirk Eddelbuettel: littler 0.2.1

Planet Debian - dim, 19/10/2014 - 23:09

A new maintenance release of littler is available now.

The main change are a few updates and extensions to the examples provided along with littler. Several of those continue to make use of the wonderful docopt package by Edwin de Jonge. Carl Boettiger and I are making good use of these littler examples, particularly to install directly from CRAN or GitHub, in our Rocker builds of R for Docker (about which we should have a bit more to blog soon too).

Full details for the littler release are provided as usual at the ChangeLog page.

The code is available via the GitHub repo, from tarballs off my littler page and the local directory here. A fresh package has gone to the incoming queue at Debian; Michael Rutter will probably have new Ubuntu binaries at CRAN in a few days too.

Comments and suggestions are welcome via the mailing list or issue tracker at the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Catégories: Elsewhere

Thorsten Alteholz: Key transition, move to stronger key

Planet Debian - dim, 19/10/2014 - 22:44

Finally I was able to do the enormous paperwork (no, it is not that much) to switch my old 1024D key to a new 4096R one. I was a bit afraid that there might be something bad happening, but my fear was without any reason. After the RT bug was closed, I could upload and sent signed emails to mailing lists. So thanks alot to everyone involved.

old key, 0xD362B62A54B99890 pub 1024D/54B99890 2008-07-23 Key fingerprint = 36E2 EDDE C21F EC8F 77B8 7436 D362 B62A 54B9 9890 uid Thorsten Alteholz (...) sub 4096g/622D94A8 2008-07-23 new key, 0xA459EC6715B0705F pub 4096R/0xA459EC6715B0705F 2014-02-03 Schl.-Fingerabdruck = C74F 6AC9 E933 B306 7F52 F33F A459 EC67 15B0 705F uid [ uneing.] Thorsten Alteholz (...) sub 4096R/0xAE861AE7F39DF730 2014-02-03 Schl.-Fingerabdruck = B8E7 6074 5FF4 C707 1C77 870C AE86 1AE7 F39D F730 sub 4096R/0x96FCAC0D387B5847 2014-02-03 Schl.-Fingerabdruck = 6201 FBFF DBBD E078 22EA BB96 96FC AC0D 387B 5847
Catégories: Elsewhere

Benjamin Mako Hill: Another Round of Community Data Science Workshops in Seattle

Planet Debian - dim, 19/10/2014 - 03:15
Pictures from the CDSW sessions in Spring 2014

I am helping coordinate three and a half day-long workshops in November for anyone interested in learning how to use programming and data science tools to ask and answer questions about online communities like Wikipedia, free and open source software, Twitter, civic media, etc. This will be a new and improved version of the workshops run successfully earlier this year.

The workshops are for people with no previous programming experience and will be free of charge and open to anyone.

Our goal is that, after the three workshops, participants will be able to use data to produce numbers, hypothesis tests, tables, and graphical visualizations to answer questions like:

  • Are new contributors to an article in Wikipedia sticking around longer or contributing more than people who joined last year?
  • Who are the most active or influential users of a particular Twitter hashtag?
  • Are people who participated in a Wikipedia outreach event staying involved? How do they compare to people that joined the project outside of the event?

If you are interested in participating, fill out our registration form here before October 30th. We were heavily oversubscribed last time so registering may help.

If you already know how to program in Python, it would be really awesome if you would volunteer as a mentor! Being a mentor will involve working with participants and talking them through the challenges they encounter in programming. No special preparation is required. If you’re interested, send me an email.

Catégories: Elsewhere

Gizra.com: Gizra - We've Got Your Headless Covered

Planet Drupal - sam, 18/10/2014 - 23:00
What's the name of the Angular component for login?

The difficulties in creating a semi or fully decoupled site isn't in the RESTful part. Spitting out JSON is now covered by several modules, including RESTful which aims for a "best practices" solution.

One of the real problems, though, is how to prevent us, the community, from re-inventing the wheel over and over again. Basically, how do we package our frontend code similarly to how we package our generic backend code - AKA "modules". I discussed these problems, and offered some solutions in my "BoF" persentation:

Continue reading…

Catégories: Elsewhere

Erich Schubert: Beware of trolls - do not feed

Planet Debian - sam, 18/10/2014 - 19:15
A particularly annoying troll has been on his hate crusade against systemd for months now. Unfortunately, he's particularly active on Debian mailing lists (but apparently also on Ubuntu and the Linux Kernel mailing list) and uses a tons of fake users he keeps on setting up. Our listsmasters have a hard time blocking all his hate, sorry. Obviously, this is also the same troll that has been attacking Lennart Poettering. There is evidence that this troll used to go by the name "MikeeUSA", and has quite a reputation with anti-feminist hate for over 10 years now. Please, do not feed this troll. Here are some names he uses on YouTube: Gregory Smith, Matthew Bradshaw, Steve Stone. Blacklisting is the best measure we have, unfortunately. Even if you don't like the road systemd is taking or Lennart Poetting personall - the behaviour of that troll is unacceptable to say the least; and indicates some major psychological problems... also, I wouldn't be surprised if he is also involved in #GamerGate. See this example (LKML) if you have any doubts. We seriously must not tolerate such poisonous people. If you don't like systemd, the acceptable way of fighting it is to write good alternative software. End of story.
Catégories: Elsewhere

Pages

Subscribe to jfhovinne agrégateur