The sad state of sysadmin in the age of containers

System administration is in a sad state. It in a mess.
I'm not complaining about old-school sysadmins. They know how to keep systems running, manage update and upgrade paths.
This rant is about containers, prebuilt VMs, and the incredible mess they cause because their concept lacks notions of "trust" and "upgrades".
Consider for example Hadoop. Nobody seems to know how to build Hadoop from scratch. It's an incredible mess of dependencies, version requirements and build tools.
None of these "fancy" tools still builds by a traditional make command. Every tool has to come up with their own, incomptaible, and non-portable "method of the day" of building.
And since nobody is still able to compile things from scratch, everybody just downloads precompiled binaries from random websites. Often without any authentication or signature.
NSA and virus heaven. You don't need to exploit any security hole anymore. Just make an "app" or "VM" or "Docker" image, and have people load your malicious binary to their network.
The Hadoop Wiki Page of Debian is a typical example. Essentially, people have given up in 2010 to be able build Hadoop from source for Debian and offer nice packages.
To build Apache Bigtop, you apparently first have to install puppet3. Let it download magic data from the internet. Then it tries to run sudo puppet to enable the NSA backdoors (for example, it will download and install an outdated precompiled JDK, because it considers you too stupid to install Java.) And then hope the gradle build doesn't throw a 200 line useless backtrace.
I am not joking. It will try to execute commands such as e.g.
/bin/bash -c "wget ; dpkg -x ./scala-2.10.3.deb /"
Note that it doesn't even install the package properly, but extracts it to your root directory. The download does not check any signature, not even SSL certificates. (Source: Bigtop puppet manifests)
Even if your build would work, it will involve Maven downloading unsigned binary code from the internet, and use that for building.
Instead of writing clean, modular architecture, everything these days morphs into a huge mess of interlocked dependencies. Last I checked, the Hadoop classpath was already over 100 jars. I bet it is now 150, without even using any of the HBaseGiraphFlumeCrunchPigHiveMahoutSolrSparkElasticsearch (or any other of the Apache chaos) mess yet.
Stack is the new term for "I have no idea what I'm actually using".
Maven, ivy and sbt are the go-to tools for having your system download unsigned binary data from the internet and run it on your computer.
And with containers, this mess gets even worse.
Ever tried to security update a container?
Essentially, the Docker approach boils down to downloading an unsigned binary, running it, and hoping it doesn't contain any backdoor into your companies network.
Feels like downloading Windows shareware in the 90s to me.
When will the first docker image appear which contains the Ask toolbar? The first internet worm spreading via flawed docker images?

Back then, years ago, Linux distributions were trying to provide you with a safe operating system. With signed packages, built from a web of trust. Some even work on reproducible builds.
But then, everything got Windows-ized. "Apps" were the rage, which you download and run, without being concerned about security, or the ability to upgrade the application to the next version. Because "you only live once".
Update: it was pointed out that this started way before Docker: »Docker is the new 'curl | sudo bash'«. That's right, but it's now pretty much mainstream to download and run untrusted software in your "datacenter". That is bad, really bad. Before, admins would try hard to prevent security holes, now they call themselves "devops" and happily introduce them to the network themselves!
2015-03-12 14:04 — Categories: English Linux DebianPermaLink & Comments

Installing Debian with sysvinit

First let me note that I am using systemd, so these things here are untested by me. See e.g. Petter's and Simon's blog entries on the same overall topic.
According to the Debian installer maintainers, the only accepted way to install Debian with sysvinit is to use preseeding. This can either be done at the installer boot prompt by manually typing the magic spell:
preseed/late_command="in-target apt-get install -y sysvinit-core"
or by using a preseeding file (which is a really nice feature I used for installing my Hadoop nodes) to do the same:
d-i preseed/late_command string in-target apt-get install -y sysvinit-core
If you are a sysadmin, using preseeding can save you a lot of typing. Put all your desired configuration into preseeding files, put them on a webserver (best with a short name resolvable by local DNS). Let's assume you have set up the DNS name, and your DHCP is configured such that is on the DNS search list. You can also add a vendor extension to DHCP to serve a full URL. Manually enabling preseeding then means adding
auto url=d-i
to the installer boot command line (d-i is the hostname I suggested to set up in your DNS before, and the full URL would then be Preseeding is well documented in Appendix B of the installer manual, but nevertheless will require a number of iterations to get everything work as desired for a fully automatic install like I used for my Hadoop nodes.

There might be an easier option.
I have filed a wishlist bug suggesting to use the tasksel mechanism to allow the user to choose sysvinit at installation time. However, it got turned down by the Debian installer maintainers quire rudely in a "No." - essentially this is a "shut the f... up and go away", which is in my opinion an inappropriate to discard a reasonable user wishlist request.
Since I don't intend to use sysvinit anymore, I will not be pursuing this option further. It is, as far as I can tell, still untested. If it works, it might be the least-effort, least-invasive option to allow the installation of sysvinit Jessie (except for above command line magic).
If you have interest in sysvinit, you (because I don't use sysvinit) should now test if this approach works.
  1. Get the patch proposed to add a task-sysvinit package.
  2. Build an installer CD with this tasksel (maybe this documentation is helpful for this step).
  3. Test whether the patch works. Report results to above bug report, so that others interested in sysvinit can find them easily.
  4. Find and fix bugs if it didn't work. Repeat.
  5. Publish the modified ("forked") installer, and get user feedback.
If you are then still up for a fight, you can try to convince the maintainers (or go the nasty way, and ask the CTTE for their opinion, to start another flamewar and make more maintainers give up) that this option should be added to the mainline installer. And hurry up, or you may at best get this into Jessie reloaded, 8.1. - chance are that the release manager will not accept such patches this late anymore. The sysvinit supporters should have investigated this option much, much earlier instead of losing time on the GR.
Again, I won't be doing this job for you. I'm happy with systemd. But patches and proof-of-concept is what makes open source work, not GRs and MikeeUSA's crap videos spammed to the LKML...
(And yes, I am quite annoyed by the way the Debian installer maintainers handled the bug report. This is not how open-source collaboration is supposed to work. I tried to file a proper wishlist bug reporting, suggesting a solution that I could not find discussed anywhere before and got back just this "No. Shut up." answer. I'm not sure if I will be reporting a bug in debian-installer ever again, if this is the way they handle bug reports ...)
I do care about our users, though. If you look at popcon "vote" results, we have 4179 votes for sysvinit-core and 16918 votes for systemd-sysv (graph) indicating that of those already testing jessie and beyond - neglecting 65 upstart votes, and assuming that there is no bias to not-upgrade if you prefer sysvinit - about 20% appear to prefer sysvinit (in fact, they may even have manually switched back to sysvinit after being upgraded to systemd unintentionally?). These are users that we should listen to, and that we should consider adding an installer option for, too.
2014-11-25 09:24 — Categories: English Linux DebianPermaLink & Comments

What the GR outcome means for the users

The GR outcome is: no GR necessary
This is good news.
Because it says: Debian will remain Debian, as it was the last 20 years.
For 20 years, we have tried hard to build the "universal operating system", and give users a choice. We've often had alternative software in the archive. Debian has come up with various tool to manage alternatives over time, and for example allows you to switch the system-wide Java.
You can still run Debian with sysvinit. There are plenty of Debian Developers which will fight for this to be possible in the future.
The outcome of this resolution says:
  • Using a GR to force others is the wrong approach of getting compatibility.
  • We've offered choice before, and we trust our fellow developers to continue to work towards choice.
  • Write patches, not useless GRs. We're coders, not bureocrats.
  • We believe we can do this, without making it a formal MUST requirement. Or even a SHOULD requirement. Just do it.
The sysvinit proponents may perceive this decision as having "lost". But they just don't realize they won, too. Because the GR may easily have backfired on them. The GR was not "every package must support sysvinit". It was also "every sysvinit package must support systemd". Here is an example: eudev, a non-systemd fork of udev. It is not yet in Debian, but I'm fairly confident that someone will make a package of it after the release, for the next Debian. Given the text of the GR, this package might have been inappropriate for Debian, unless it also supports systemd. But systemd has it's own udev - there is no reason to force eudev to work with systemd, is there?
Debian is about choice. This includes the choice to support different init systems as appropriate. Not accepting a proper patch that adds support for a different init would be perceived as a major bug, I'm assured.
A GR doesn't ensure choice. It only is a hammer to annoy others. But it doesn't write the necessary code to actually ensure compatibility.
If GNOME at some point decides that systemd as pid 1 is a must, the GR only would have left us three options: A) fork the previous version, B) remove GNOME altogether, C) remove all other init systems (so that GNOME is compliant). Does this add choice? No.
Now, we can preserve choice: if GNOME decides to go systemd-pid1-only, we can both include a forked GNOME, and the new GNOME (depending on systemd, which is allowed without the GR). Or any other solution that someone codes and packages...
Don't fear that systemd will magically become a must. Trust that the Debian Developers will continue what they have been doing the last 20 years. Trust that there are enough Debian Developers that don't run systemd. Because they do exist, and they'll file bugs where appropriate. Bugs and patches, that are the appropriate tools, not GRs (or trolling).
2014-11-19 20:58 — Categories: English Linux DebianPermaLink & Comments

Generate iptables rules via pyroman

Vincent Bernat blogged on using Netfilter rulesets, pointing out that inserting the rules one-by-one using iptables calls may leave your firewall temporarily incomplete, eventually half-working, and that this approach can be slow.
He's right with that, but there are tools that do this properly. ;-)
Some years ago, for a multi-homed firewall, I wrote a tool called Pyroman. Using rules specified either in Python or XML syntax, it generates a firewall ruleset for you.
But it also adresses the points Vincent raised:
  • It uses iptables-restore to load the firewall more efficiently than by calling iptables a hundred times
  • It will backup the previous firewall, and roll-back on errors (or lack of confirmation, if you are remote and use --safe)
It also has a nice feature for the use in staging: it can generate firewall rule sets offline, to allow you reviewing them before use, or transfer them to a different host. Not all functionality is supported though (e.g. the Firewall.hostname constant usable in python conditionals will still be the name of the host you generate the rules on - you may want to add a --hostname parameter to pyroman)
pyroman --print-verbose will generate a script readable by iptables-restore except for one problem: it contains both the rules for IPv4 and for IPv6, separated by #### IPv6 rules. It will also annotate the origin of the rule, for example:
# /etc/pyroman/
-A rfc4890f -p icmpv6 --icmpv6-type 255 -j DROP
indicates that this particular line was produced due to line 82 in file /etc/pyroman/ This makes debugging easier. In particular it allows pyroman to produce a meaningful error message if the rules are rejected by the kernel: it will tell you which line caused the rule that was rejected.
For the next version, I will probably add --output-ipv4 and --output-ipv6 options to make this more convenient to use. So far, pyroman is meant to be used on the firewall itself.
Note: if you have configured a firewall that you are happy with, you can always use iptables-save to dump the current firewall. But it will not preserve comments, obviously.
2014-11-18 09:46 — Categories: English Debian SecurityPermaLink & Comments

GR vote on init coupling

Overregulation is bad, and the project is suffering from the recent Anti-Systemd hate campaigning.
There is nothing balanced about the original GR proposal. It is bullshit from a policy point of view (it means we must remove software from Debian that would not work with other inits, such as gnome-journal, by policy).At the same time, it uses manipulative language like "freedom to select a different init system" (as if this would otherwise be impossible) and "accidentally locked in". It is exactly this type of language and behavior which has made Debian quite poisonous the last months.
In fact, the GR pretty much says "I don't trust my fellow maintainers to do the right thing, therefore I want a new hammer to force my opinion on them". This is unacceptable in my opinion, and the GR will only demotivate contributors. Every Debian developer (I'm not talking about systemd upstream, but about Debian developers!) I've met would accept a patch that adds support for sysvinit to a package that currently doesn't. The proposed GR will not improve sysvinit support. It is a hammer to kick out software where upstream doesn't want to support sysvinit, but it won't magically add sysvinit support anywhere.
What some supporters of the GR may not have realized - it may as well backfire on them. Some packages that don't yet work with systemd would violate policy then, too... - in my opinion, it is much better to make the support on a "as good as possible, given available upstream support and patches" basis, instead of a "must" basis. The lock-in may come even faster if we make init system support mandatory: it may be more viable to drop software to satisfy the GR than to add support for other inits - and since systemd is the current default, software that doesn't support systemd are good candidates to be dropped, aren't they? (Note that I do prefer to keep them, and have a policy that allows keeping them ...)
For these reasons I voted:
  1. Choice 4: GR not required
  2. Choice 3: Let maintainers do their work
  3. Choice 2: Recommended, but not mandatory
  4. Choice 5: No decision
  5. Choice 1: Ban packages that don't work with every init system
Fact is that Debian maintainers have always been trying hard to allow people to choose their favorite software. Until you give me an example where the Debian maintainer (not upstream) has refused to include sysvinit support, I will continue to trust my fellow DDs. I've been considering to place Choice 2 below "further discussion", but essentially this is a no-op GR anyway - in my opinion "should support other init systems" is present in default Debian policy already anyway...
Say no to the haters.
And no, I'm not being unfair. One of the most verbose haters going by various pseudonyms such as Gregory Smith (on Linux Kernel Mailing list), Brad Townshend (LKML) and John Garret (LKML) has come forward with his original alias - it is indeed MikeeUSA, a notorious anti-feminist troll (see his various youtube "songs", some of them include this pseudonym). It's easy to verify yourself.
He has not contributed anything to the open source community. His songs and "games" are not worth looking at, and I'm not aware of any project that has accepted any of his "contributions". Yet, he uses several sock puppets to spread his hate.
The anti-systemd "crowd" (if it acually is more than a few notorious trolls) has lost all its credibility in my opinion. They spread false information, use false names, and focus on hate instead of improving source code. And worse, they tolerate such trolling in their ranks.
2014-11-09 15:38 — Categories: English Linux DebianPermaLink & Comments

Avoiding systemd isn't hard

The former contents of this blog post have been removed.
Systemd-haters pissed me off so much, that I'm no longer willing to provide information helpful for avoiding systemd.
Here is my message to all the anti-systemd-trolls: Go jump in a lake, we do not need haters in the open source community.
Hint: if you want people to care about you, stop insulting them. If you keep on pissing off people, you will not achieve anything!
2014-10-21 13:17 — Categories: English DebianPermaLink & Comments

Beware of trolls - do not feed

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 listmasters 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 (and you should be able to continue using SysV init or openRC, unless there is a bug, in Debian - in this case, provide a bug fix). End of story.
2014-10-18 18:41 — Categories: English DebianPermaLink & Comments

Google Earth on Linux

Google Earth for Linux appears to be largely abandoned by Google, unfortunately. The packages available for download cannot be installed on a modern amd64 Debian or Ubuntu system due to dependency issues.
In fact, the adm64 version is a 32 bit build, too. The packages are really low quality, the dependencies are outdated, locales support is busted etc.
So here are hacky instructions how to install nevertheless. But beware, these instructions are a really bad hack.
  1. These instructions are appropriate for version Do not use them for any other version. Things will have changed.
  2. Make sure your system has i386 architecture enabled. Follow the instructions in section "Configuring architectures" on the Debian MultiArch Wiki page to do so
  3. Install lsb-core, and try to install the i386 versions of these packages, too!
  4. Download the i386 version of the Google Earth package
  5. Install the package by forcing dependencies, via
    sudo dpkg --force-depends -i google-earth-stable_current_i386.deb
  6. As of now, your package manager will complain, and suggest to remove the package again. To make it happy, we have to hack the installed packages list. This is ugly, and you should make a backup. You can totally bust your system this way... Fortunately, the change we're doing is rather simple. As admin, edit the file /var/lib/dpkg/status. Locate the section Package: google-earth-stable. In this section, delete the line starting with Depends:. Don't add in extra newlines or change anything else!
  7. Now the package manager should believe the dependencies of Google Earth are fulfilled, and no longer suggest removal. But essentially this means you have to take care of them yourself!
Some notes on using Google Earth:
  • Locales are busted. Use LC_NUMERIC=en_US.UTF-8 google-earth to start it. Otherwise, it will fail parsing coordinates, if you are in a locale that uses a different number format.
  • You may need to install the i386 versions of some libraries, in particular of your OpenGL drivers! I cannot provide you with a complete list.
  • Search doesn't work sometimes for me.
  • Occassionally, it reports "unknown" network errors.
  • If you upgrade Nvidia graphics drivers, you will usually have to reboot, or you will see graphics errors.
  • Some people have removed/replaced the bundled libQt* and libfreeimage* libraries, but that did not work for me.
2014-10-17 15:59 — Categories: English Web DebianPermaLink & Comments

Debian chooses systemd as default init

It has been all over the place. The Debian CTTE has chosen systemd over upstart as default init system by chairman call. This decision was overdue, as it was pretty clear that the tie will not change, and thus it will be up to chairman. There were no new positions presented, and nobody was being convinced of a different preference. The whole discussion had been escalating, and had started to harm Debian.

Some people may not want to hear this, but another 10 ballots and options would not have changed this outcome. Repating essentially the same decision (systemd, upstart, or "other things nobody prefers") will do no good, but turn out the same result, a tie. Every vote counting I saw happen would turn out this tie. Half of the CTTE members prefer systemd, the other half upstart.

The main problems, however, are these:

  • People are not realizing this is about the default init for jessie, not about the only init to support. Debian was and is about choice, but even then you need to make something default... If you prefer SysV init or openRC, you will still be able to use it (it will be just fewer people debugging these startup scripts).
  • Some people (not part of the CTTE) are just social inept trolls, and have rightfully been banned from the list.
  • The discussion has been so heated up, a number of imporant secondary decisions have not yet been discussed in a civil manner. For example, we will have some packages (for example, Gnome Logs), which are specific to a particular init system, but not part of the init system. A policy needs to be written with these cases in mind that states when and how a package may depend on a particular init system. IMHO, a package that cannot support other init systems without major changes should be allowed to depend on that system, but then meta-packages such as the Gnome meta packages must not require this application.

So please, everybody get back to work now. If there ever is enough reason to overturn this decision, there are formal ways to do this, and there are people in the CTTE (half of the CTTE, actually) that will take care of this.

Until then, live with the result of a 0.1 votes lead for systemd. Instead of pursuing a destructive hate campaign, why not improve your favorite init system instead.

Oh, and don't forget about the need to spell out a policy for init system support requirements of packages.

2014-02-11 22:07 — Categories: English Linux DebianPermaLink & Comments

Minimizing usage of debian-multimedia packages

How to reduce your usage of debian-multimedia packages:

As you might be aware, the "deb-multimedia" packages have seen their share of chaos.

Originally, they were named "debian-multimedia", but it was then decided that they should better be called "deb-multimedia" as they are not an official part of Debian. The old domain was then grabbed by cybersquatters when it expired.

While a number of packages remain indistributable for Debian due to legal issues - such as decrypting DVDs - and thus "DMO" remains useful to many desktop users, please note that for many of the packages, a reasonable version exists within Debian "main".

So here is a way to prevent automatically upgrading to DMO versions of packages that also exist in Debian main:

We will use a configuration option known as apt pinning. We will modify the priority of DMO package to below 100, which means they will not be automatically upgraded to; but they can be installed when e.g. no version of this package exists within Debian main. I.e. the packages can be easily installed, but it will prefer using the official versions.

For this we need to create a file I named /etc/apt/preferences.d/unprefer-dmo with the contents:

Package: *
Pin: release o=Unofficial Multimedia Packages
Pin-Priority: 123

As long as the DMO archive doesn't rename itself, this pin will work; it will continue to work if you use a mirror of the archive, as it is not tied to the URL.

It will not downgrade packages for you. If you want to downgrade, this will be a trickier process. You can use aptitude for this, and start with a filter (l key, as in "limit") of ?narrow(~i,~Vdmo). This will only show packages installed where the version number contains dmo. You can now patrol this list, enter the detail view of each package, and check the version list at the end for a non-dmo version.

I cannot claim this will be an easy process. You'll probably have a lot of conflicts to clear up, due to different libavcodec* API versions. If I recall correctly, I opted to uninstall some dmo packages such as ffmpeg that I do not really need. In other cases, the naming is slightly different: Debian main has handbrake, while dmo has handbrake-gtk.

A simple approach is to consider uninstalling all of these packages. Then reinstall as needed; since installing Debian packages is trivial, it does not hurt to deinstall something, does it? When reinstalling, Debian packages will be preferred over DMO packages.

I prefer to use DFSG-free software wherever possible. And as long as I can watch my favorite series (Tatort, started in 1970 and airing episode 900 this month) and the occasional DVD movie, I have all I need.

An even more powerful aptitude filter to review installed non-Debian software is ?narrow(~i,!~ODebian), or equivalently ?narrow(?installed,?not(?origin(Debian))). This will list all package versions, which cannot be installed from Debian sources. In particular, this includes versions that are no longer available (they may have been removed because of security issues!), software that has been installed manually from .deb files, or any other non-Debian source such as Google or DMO. (You should check the output of aptitude policy that no source claims to be o=Debian that isn't Debian though).

This filter is a good health check for your system. Debian packages receive a good amount of attention with respect to packaging quality, maintainability, security and all of these aspects. Third party packages usually failed the Debian quality check in at least one respect. For example, Sage isn't in Debian yet; mostly because it has so many dependencies, that making a reliable and upgradeable installation is a pain. Similarly, there is no Hadoop in Debian yet. If you look at Hadoop packaging efforts such as Apache Bigtop, they do not live up to Debian quality yet. In particular, the packages have high redundancy, and re-include various .jar copies instead of sharing access to an independently packaged dependency. If a security issue arises with any of these jars, all the Hadoop packages will need to be rebuilt.

As you can see, it is usually not because of Debian being too strict or too conservative about free software when software is not packaged. More often than not, it's because the software in question itself currently does not live up to Debian packaging quality requirements. And of course sometimes because there is too little community backing the software in question, that would improve the packaging. If you want your software to be included in Debian, try to make it packaging friendly. Don't force-include copies of other software, for example. Allow the use of system-installed libraries where possible, and provide upgrade paths and backwards compatibility. Make dependencies optional, so that your software can be pacakged even if a dependency is not yet available - and does not have to be removed if the dependency becomes a security risk. Maybe learn how to package yourself, too. This will make it easier for you to push new features and bug fixes to your userbase: instead of requiring your users to manually upgrade, make your software packaging friendly. Then your users will be auto-upgraded by their operating system to the latest version.

Update: If you are using APT::Default-Release or other pins, these may override above pin. You may need to use apt-cache policy to find out if the pins are in effect, and rewrite your default-release pin into e.g.

Package: *
Pin: release a=testing,o=Debian
Pin-Priority: 912
for debugging, use a different priority for each pin, so you can see which one is in effect. Notice the o=Debian in this pin, which makes it apply only to Debian repositories.

2014-02-09 12:35 — Categories: English Linux DebianPermaLink & Comments

The init wars

The init wars have recently caught a lot of media attention (e.g. heise, prolinux, phoronix). However, one detail that is often overlooked: Debian is debating over the default, while all of them are already supported to a large extend, actually. Most likely, at least two of them will be made mandatory to support IMHO.
The discussion seems to be quite heated, with lots of people trying to evangelize for their preferred system. This actually only highlights that we need to support more than one, as Debian has always been about choice. This may mean some extra work for the debian-installer developers, because choosing the init system at install time (instead of switching later) will be much easier. More often than not, when switching from one init system to another you will have to perform a hard reset.
If you want to learn about the options, please go to the formal discussion page, which does a good job at presenting the positions in a neutral way.
Here is my subjective view of the init systems:
  • SysV init is the current default, and thus deserves to be mentioned first. It is slow, because it is based on a huge series of shell scripts. It can often be fragile, but at the same time it is very transparent. For a UNIX system administrator, SysV init is probably the preferred choice. You only reboot your servers every year anyway.
  • upstart seems to be a typical Canonical project. It solves a great deal of problems, but apparently isn't good enough at it for everybody, and they fail at including anyone in their efforts. Other examples of these fails include Unity and Mir, where they also announced the project as-is, instead of trying to get other supporters on board early (AFAICT). The key problem to widespread upstart acceptance seems to be the Canonical Contributor License Agreement that many would-be contributors are unwilling to accept. The only alternative would be to fork upstart completely, to make it independent of Canonical. (Note that upstart nevertheless is GPL, which is why it can be used by Debian just fine. The CLA only makes getting patches and enhancements included in the official version hard.)
  • systemd is the rising star in the init world. It probably has the best set of features, and it has started to incorporate/replace a number of existing projects such as ConsoleKit. I.e. it not only manages services, but also user sessions. It can be loosely tied to the GNOME project which has started to rely on it more and more (much to the unhappyness of Canonical, who used to be a key player for GNOME; note that officially, GNOME chose to not depend on systemd, yet I see this as the only reliable combination to get a complete GNOME system running, and since "systemd can eventually replace gnome-session" I foresee this tie to become closer). As the main drawback, systemd as is will (apparently) only work with the Linux kernel, whereas Debian has to also support kFreeBSD, NetBSD, Hurd and the OpenSolaris kernels (some aren't officially supported by Debian, but by separate projects).
So my take: I believe the only reasonable default is systemd. It has the most active development community and widest set of features. But as it cannot support all architectures, we need mandatory support for an alternative init system, probably SysV. Getting both working reliably will be a pain, in particular since more and more projects (e.g. GNOME) tie themselves closely to systemd, and would then become Linux-only or require major patches.
I have tried only systemd on a number of machines, and unfortunately I cannot report it as "prime time ready" yet. You do have the occasional upgrade problems and incompatibilities, as it is quite invasive. From screensavers activating during movies to double suspends, to being unable to shutdown my system when logged in (systemd would treat the login manager as separate session, and not being the sole user it would not allow me to shut down), I have seen quite a lot of annoyances happen. This is an obvious consequence of the active development on systemd. This means that we should make the decision early, because we will need a lot of time to resolve all these bugs for the release.
There are more disruptions coming on the way. Nobody seems to have talked about kDBUS yet, the integration of an IPC mechanism like DBUS into the Linux kernel. It IMHO has a good chance of making it into the Linux kernel rather soon, and I wouldn't be surprised if it became mandatory for systemd soon after. Which then implies that only a recent kernel (say, mid-2014) version might be fully supported by systemd soon.
I would also like to see less GNOME influence in systemd. I have pretty much given up on the GNOME community, which is moving into a UI direction that I hate: they seem to only care about tablet and mobile phones for dumb users, and slowly turn GNOME into an android UI; selling black background as major UI improvements. I feel that the key GNOME development community does not care about developers and desktop users like me anymore (but dream of being the next Android), and therefore I have abandoned GNOME and switched to XFCE.
I don't give upstart much of a chance. Of course there are some Debian developers already involved in its development (employed by Canonical), so this will cause some frustration. But so far, upstart is largely an Ubuntu-only solution. And just like Mir, I don't see much future in it; instead I foresee Ubuntu going systemd within a few years, because it will want to get all the latest GNOME features. Ubuntu relies on GNOME, and apparently GNOME already has chosen systemd over upstart (even though this is "officially" denied).
Sticking with SysV is obviously the easiest choice, but it does not make a lot of sense to me technically. It's okay for servers, but more and more desktop applications will start to rely on systemd. For legacy reasons, I would however like to retain good SysV support for at least 5-10 more years.

But what is the real problem? After all, this is a long overdue decision.
  • There is too much advocacy and evangelism, from either side. The CTTE isn't really left alone to do a technical decision, but instead the main factors have become of political nature, unfortunately. You have all kinds of companies (such as Spotify) weigh in on the debate, too.
  • The tone has become quite aggressive and emotional, unfortunately. I can already foresee some comments on this blog post "you are a liar, because GNOME is now spelled Gnome!!1!".
  • Media attention. This upcoming decision has been picked up by various Linux media already, increasing the pressure on everybody.
  • Last but not least, the impact will be major. Debian is one of the largest distributions, last but not least used by Ubuntu and Steam, amongst others. Debian preferring one over the other will be a slap in somebodys face, unfortunately.
So how to solve it? Let the CTTE do their discussions, and stop flooding them with mails trying to influence them. There has been so much influencing going on, it may even backfire. I'm confident they will find a reasonable decision, or they'll decide to poll all the DDs. If you want to influence the outcome provide patches to anything that doesn't yet fully support your init system of choice! I'm sure there are hundreds of packages which do neither have upstart nor systemd support yet (as is, I currently have 27 init.d scripts launched by systemd, for example). IMHO, nothing is more convincing than have things just work, and of course, contributing code. We are in open source development, and the one thing that gets you sympathy in the community is to contribute code to someone elses project. For example, contribute full integrated power-management support into XFCE, if you include power management functionality.
As is, I have apparently 7 packages installed with upstart support, and 25 with systemd support. So either, everybody is crazy about systemd, or they have the better record of getting their scripts accepted upstream. (Note that this straw poll is biased - with systemd, the benefits of not using "legacy" init.d script may just be larger).
2014-01-22 16:39 — Categories: English Linux DebianPermaLink & Comments

ELKI data mining in 2013

ELKI, the data mining framework I use for all my research, is coming along nicely, and will see continued progress in 2013. The next release is scheduled for SIGMOD 2013, where we will be presenting the novel 3D parallel coordinates visualization we recently developed. This release will bear the version number 0.6.0.
Version 0.5.5 of ELKI is in Debian unstable since december (Version 0.5.0 will be in the next stable release) and Ubuntu raring. The packaged installation can share the dependencies with other Debian packages, so they are smaller than the download from the ELKI web site.
If you are developing cluster analysis or outlier detection algorithm, I would love to see them contributed to ELKI. If I get a clean and well-integrated code by mid june, your algorithm could be included in the next release, too. Publishing your algorithms in source code in a larger framework such as ELKI will often give you more citations. Because it is easier to compare with your algorithm then and to try it on new problems. And, well, citations counts are a measure that administration loves to judge researchers ...
So what else is happening with ELKI:
  • The new book "Outlier Analysis" by C. C. Aggarwal mentions ELKI for visual evaluation of outlier results as well as in the "Resources for the Practioner" section and cites around 10 publications closely related to ELKI.
  • Some classes for color feature extraction of ELKI have been contributed to jFeatureLib, a Java library for feature detection in image data.
  • I'd love to participate in the Google Summer of Code, but I need a contact at Google to "vouch" for the project, otherwise it is hard to get in. I've been sending a couple of emails, but so far have not heard back much yet.
  • As the performance of SVG/Batik is not too good, I'd like to see more OpenGL based visualizations. This could also lead to an Android based version for use on tablets.
  • As I'm not an UI guy, I would love to have someone make a fancier UI that still exposes all the rich functions we have. The current UI is essentially an automatically generated command line builder - which is nice, as new functionality shows up without the need to modify UI code. It's good for experienced users like me, but hard for beginners to get started.
  • I'd love to see integration of ELKI with e.g. OpenRefine / Google Refine to make it easier to do appropriate data cleaning and preprocessing
  • There is work underway for a distributed version running on Hadoop/YARN.
2013-02-28 10:55 — Categories: English Coding Debian ResearchPermaLink & Comments

Pyroman IPv6 support

I've added IPv6 support to my firewall tool Pyroman, and uploaded a package to experimental. But of course you can just checkout the source code from Subversion and call it as bin/pyroman without installation.
Pyroman will try to produce a consistent set of rules for IPv4 and IPv6. Originally it was designed for complex firewalls with multiple interfaces, various rules and NAT. I have so far only tested this version on my single-host setup at home, in particular NAT might break.
Pyroman has extensive debug functions. You can try --print-verbose to see why it produced which rules. By invoking pyroman safe you will tell it to revert any changes unless you type OK at the prompt.
And if it fails to compute firewall rules, or there is some iptables error, it will also restore the previous state.
So you have plenty of options to give it a try without risking to produce a mess. Just start with configuring it to the point where you like the "--print" output. Then give the "safe" mode a try next.
Check the Pyroman homepage for the features. There is more. Pyroman is a lot faster than most other firewall tools, because it does not perform hundreds of iptables invocations but uses iptables-restore to bulk load them. This is the fastest way to bring the firewall from one configured state into another. For the 0.6 version of pyroman I plan to offer precomputing the firewall rules, and use a single iptables-restore call at bootup to setup your firewall, with dependency tracking to see if the precomputed file is still up to date.
2011-08-17 20:54 — Categories: Linux Debian CodingPermaLink & Comments

AMD64 broken on Debian unstable - avoid libc6 2.13-3

Beware from upgrading on AMD64. Make sure to avoid version 2.1.3-3, as this will render your system unbootable and unusable. As simple as the reason is (a missing link) as severe.
Bug report with instructions on how to recover. If you are lucky you have a root shell open to restore the missing link. Otherwise, you need to reboot with parameters break=init rw, recover the link with cd root; ln -s lib lib64, sync, unmount, reboot. It's not really hard to do when you know how. But it is a lot easier to avoid upgrading to this version. My i386 mirror already has the fixed upload (but i386 is not affected anyway). So by tomorrow, it should be safe again (depening on your mirrors delay).
2011-05-12 20:39 — Categories: English Linux DebianPermaLink & Comments

Finding packages for deinstallation

On my netbook, I try to keep the amount of installed software limited. Aptitudes "automatically installed" markers are very helpful here, since they allow you to differentiate between packages that were deliberately installed and packages that were manually marked for installation. I quite often browse through the list of installed packages and recheck those that are not marked as "A".
However, packages that are "suggested" by some other package (but not "required") will be kept even when marked as automatically. This is quite sensible: when you deinstall the package that "suggested" them, they will be removed. So this is nice for having optional software also automatically removed.
However sometimes you need the core package but not this optional functionality. Aptitude can help you there, too. Here's an aptitude filter I used to find some packages for removal:
!?reverse-depends(~i) ~M !?essential
It will display only packages with no direct dependency from another installed package and that are marked as automatically installed (so they must be kept installed because of a weaker dependency.
Some examples of "suggested but not required" packages:
  • Accessibility extensions of Gnome
  • Spelling dictionaries
  • Optional functionality / extensions
Depending on your requirements, you might want to keep some of these and remove others.

Here is also a filter to find packages that you can put on "automatically installed":
~i !~M ?reverse-depends(~i) !?essential
This will catch "installed but not automatically installed packages, that another installed package depends on". Note that you should not blindly put all of these to "automatic" mode. For example "logrotate" depends on "cron | anacron | fcron". If you have both cron and anacron installed, aptitude will consider anacron to be unnecessary (it is - on a system with 24h uptime). So review this list, and see what happens when you set packages to "A", and reconsider your intentions. If it is a software you want for sure, leave it on manual.
2011-03-15 14:04 — Categories: English Debian LinuxPermaLink & Comments

GNOME3 in Debian experimental - python and dconf

As GNOME3 slowly enters Debian experimental, things become a bit ... experimental.
The file manager can be set to still draw icons on the desktop, but that doesn't entirely work yet (it will also open folders as desktop then...)
One machine had lost the keyboard settings. I could not set the fonts I wanted...
There is a tool called dconf-editor that will allow you to manually tweak some settings such as the fonts. But it doesn't seem to have support for value lists yet - and the keyboard mappings setting is a string list.
So here's sample python code to modify such a value:
from gi.repository import Gio
s ="org.gnome.libgnomekbd.keyboard")
s.set_strv("layouts", ["de"])
Update: you could also install the optional libglib2.0-bin and use the gsettings command.
2011-03-15 00:41 — Categories: English Linux Debian GnomePermaLink & Comments

Debian Squeeze released!

Debian GNU/Linux 6.0 "squeeze" has been released today.
Congratulations to everyone involved in ironing the last few bugs out.
(My own involvement had been a bit limited recently, but I at least kept my few remaining packages in a ready-to-release state and helped with the occasional bug report and patch.)
Some people think that Ubuntu is the better Debian - I do NOT. Debian is a fun place, has great people working on it and is true to its aims at creating a truly free and high-quality distribution. The long release cycles of Debian are a feature, not a bug. Stable is for production systems, not toy projects.
The proper way of attributing Debian stable is conservative and sustainable, but not outdated. It actually can do everything you need - and will do so in 10 years.
If you have been using Open Source for as long as me (say 15+ years) you will probably have seen software hypes come and go. The one thing that has been always the same was Debian: dead reliable. There was a time when everyone was crazy about enlightement for it's shiny pretty UI. Almost like Compiz-Beryl just two years ago. It came, as a matter of fact Debian also had it, but it also went.
I also remember how people complained that Debian didn't ship Xgl back in 2006 when this was the latest hype (there was no Debian release in 2006). Well, Xgl died in 2008. The features remained, but done in a much nicer way, and also found their way into Debian. In fact, I also ran Xgl at least once, on Debian, but just not on "stable". One could say that Xgl never was quite "stable", was it?
Debian stable is good the way it is: an administrators choice. Of course, developers might have different needs, but there also is testing, unstable and experimental. Just make sure to align your choice with your needs. And sometimes, also rethink your needs: there is no "latest beta versions" and "stable platform" at the same time.
2011-02-06 11:10 — Categories: English Debian LinuxPermaLink & Comments

New netbook - ASUS EeePC 1016P

I have a new netbook, from work. This model wasn't my choice, but it is a really good choice by our system administrator. The design is plain, dark but nice (brushed aluminium), the size is a true netbook. I also like the keyboard, despite the small size.
Installing Debian squeeze worked like a charm. Essentially, I needed to build an installer USB stick with the netinstall image, then I could use the switched LAN connection to a local Debian mirror at the university network. However you should know that the WLAN connection requires a non-free firmware, so if you plan to install with WLAN only, you need to get the package on your install thumbdrive.
The rest worked out of the box, and I directly went to unstable + some stuff from experimental. The only thing not working I've found so far are some special buttons (presentation mode, but also toggle wireless!) - but they are already reported by the kernel als "unknown key", so this will eventually be added.
As for battery life, GNOME currently says I'll get around 8 hours of use with wireless, medium (but good) brightness and "blog" use. Charts indicate I'm at around 6 Watt. (Unless using some OpenGL screensaver, which seems to cost more than 1 Watt extra!)
So here's my current summary:
  • + well supported by Linux
  • + 2 GB of RAM
  • + battery life, low power consumption
  • + wireless much better than on my old laptop
  • + good display (gloss free, good brightness, 1024x600)
  • - the webcam is dead weight, it's completely useless (crappy quality)
  • - there is no UMTS, which many business people will complain about
  • - screen resolution could be higher; I really like high resolutions!
  • - Intel IGP can't do FullHD, but I have a FullHD external monitor
The one thing I really don't get about this laptop is why they added this ridiciulously bad webcam.
15.12.2010 22:34 — Categories: Deutsch Linux DebianPermaLink & Comments

Beware of the "startpar" bug!

UPDATE: the bug is already fixed after a few hours, and only affected a minority of users (of a now deprecated, experimental option in the 'unstable' distribution, and only users that rebooted with the affected version).

The sysvinit version that hit unstable today has a grave bug if you have been running "startpar" or maybe "shell" style parallel booting. Read this bug report, if you have been using these (they were not enabled by default, so unless you've been giving parallel boot a try before, you should be ok.)

How to check if you are affected:

grep CONCURRENCY /etc/default/rcS

If this command says "startpar", then you ARE affected. If it says "shell" you MIGHT be affected. If you have not set CONCURRENCY or if it's "none" or "makefile", then you should be ok (according to the bug).

The workaround is as simple: just put either "none" or "makefile" in there, these are the only two values that are still distinct.

How to recover a broken system:

  1. Boot recovery mode aka "single-user". At some point you should be asked for the root password. Login.
  2. Run mount -o remount,rw / to enable write mode on your disk.
  3. $EDITOR /etc/default/rcS and change the value of "CUNCURRENCY"
  4. reboot

You should have a working system again.

I can only confirm that changing "startpar" to "none" helped me. I havn't tried "makefile" yet, and "none" seemed more likely to fix things.

2010-05-15 22:40 — Categories: English Linux DebianPermaLink & Comments

Removing modlogan

Unless someone drops in as new maintainer, I'll file for removal of ModLogAn from Debian soon.

The software has been abandoned upstream for, well, a couple of years. It still works okayish (just the patterns need refreshing), and in fact I'm still running it. But there is plenty of software to replace it, and it seems as if many people go the Google Analytics way today.

Please speak up quickly if you care about ModLogAn, otherwise it's gone from Debian soon.

2010-04-12 02:11 — Categories: English Linux DebianPermaLink & Comments

Enigma in Debian


is a great game, with a unique mixture of puzzles with mouse skills and action. If you know the discontinued game Oxyd originally on the Atari ST in the 90s (also on Amiga and one version on DOS), then you know the principle of Enigma. Except that it has tons of more levels and is Open Source.

Some weeks ago, I uploaded a 1.10 pre-release (approximately milestone 5) to Debian experimental. This is the soon-to-be-released new version, using a new level file format (with a much extended API to make level development even easier, ~50% less code per level now), new levels (of course), updated graphics (including support for new graphics modes), ...

Unstable still contains version 1.01; the reason is simple that I knew there would be another 1.01 maintainance release coming. However I believe it doesn't offer much against the current unstable version; it largely marks an upstream release containing patches already in the Debian package (since communication with upstream is really good).

So I have now two choices: refreshing the Debian unstable package to the "probably last" 1.01 release upstream, or going straight for the 1.10 milestones to give enigma some extra testing.

2009-12-28 16:54 — Categories: English Linux DebianPermaLink & Comments

Google Summer of Code 2009

Just a short reminder that the application phase for the Google Summer of Code 2009 is running.

GSoC 2009 logo

So far, we have quite few applications. Deadline is April 3rd, 19:00 UTC. Usually applications arrive rather late, but still I have the impression that we have much less than the previous years. But less copy & paste, too.

If you are interested in doing a GSoC project at Debian:

  • Check the Debian Wiki which has all kind of relevant information.
  • Talk to Debian people
  • Make sure it's related to Debian (and not just "runs on Linux")
  • Talk to Debian people
  • Make sure your application shows your genuine interest and has some original ideas, copy & paste will not be sufficient
  • Talk to Debian people

I hope to see more applications - and good luck that we get enough slots for all of you!

P.S. as far as I can tell, current Debian Developers can be eligible as well, although it has also always been a goal of the project to get new contributors involved.

2009-03-30 14:43 — Categories: English Linux DebianPermaLink & Comments

Congratulations, Debian

Debian Lenny Banner

Congratulations to all developers (DDs or not, we have sponsored uploads, Debian contributors and such, too!) who contributed to the release of Debian GNU/Linux "lenny" 5.0. I must admit that I've been largely inactive recently, I just managed to keep the bugs on my remaining packages low. Funnily, just the day lenny was released I learned about a bug in Enigma on AMD64 that is probably worth fixing through proposed updates ...

2009-02-16 18:33 — Categories: English Linux DebianPermaLink & Comments

Xorg hotplugging

From Roderich Schupp I received the following instructions:

cp /usr/share/doc/hal/examples/10-x11-input.fdi /etc/hal/fdi/policy/

And in order to set a default keymap:

<deviceinfo version="0.2">
    <match key="input.xkb.rules" contains="base">
      <merge key="input.xkb.layout" type="string">de</merge>
      <merge key="input.xkb.variant" type="string">nodeadkeys</merge>

Into yet another custom file in this directory.

Thank you, I'm going to try that on my next reboot (which may take a week).

2008-08-30 01:18 — Categories: English Linux DebianPermaLink & Comments

Xorg evdev hotplugging anyone?

Xorg 1.4 in experimental is supposed to have input device hotplugging.

Does anyone have a Howto for Debian? I tried it, but I couldn't get it to hot-plug my USB mouse, so I'm back to using the regular mouse driver for it again, using the /dev/input/mice in-kernel-hack for hotplugging.

P.S. on a recent kernel, you might want to add

blacklist snd_pcsp

to a custom file in /etc/modutils/, in order to avoid your PC speaker showing up as regular audio device. You don't want your regular apps to consider your legacy PC speaker as audio device usually.

P.S. No, my blog doesn't have comments. Just send me an email (you know, 'legacy' email) via erich AT debian org.

2008-08-28 17:44 — Categories: English Linux DebianPermaLink & Comments

Google impressively quick index updates

Today, I uploaded a new version of my firewall configuration tool, pyroman, to Debian unstable.

About 4 hours later I googled for "Pyroman Debian" and was surprised to find the upload notification in the top results. The first hour of this was probably spent with me doing some package function tests (I don't want to upload broken packages, after all), then the announcement was distributed to the -changes mailing list at Debian, which in turn was picked up by Google Groups.

However that might be due to getting special treatment, though. For this resource, Google can actually trigger an update instead of having to have a spider frequently re-crawl all the contents.

Still I find it pretty impressive to have such new data already in their main index. I was used to this e.g. for blog and news search, but not for regular web search.

2008-08-01 19:23 — Categories: English Linux DebianPermaLink & Comments

Debian in the Google Summer of Code 2008

The Summer of Code wiki page in the Debian Wiki has been updated with an overview of the projects that made the race for the 13 slots we have.

A separate press release (containing a short paragraph on what each project is about) is in preparation and will be out soonish.

2008-04-22 01:48 — Categories: English Linux DebianPermaLink & Comments

Debian in the Google Summer of Code 2008

We've received another of the last minute slots (thanks to those organizations which returned some of their assigned slots) to a total of 13 this year.

We have received some very good application, and we'll be able to fill these 13 slots easily with very good applications working on a variety of topics.

The results will be published on Monday, since there may still be minor changes in which students are accepted or who didn't make it to the top slots.

Google Summer of Code 2008

2008-04-19 16:36 — Categories: English Linux DebianPermaLink & Comments

Ubuntu to rename top level directories

[Yes, this post was written on April 1st and is not to be taken serious.]

The usability experts of Ubuntu have finally started to handle the single most mentioned usability issue with Linux: the top level directory names.

Quoting Finn C. Tional from the Ubuntu Usability Group:

It's one of the mysteries of Unix that the directory named "usr" is not for user data, and the directory named "etc" while looking like random stuff thrown together stores all the important config files. [...] This is probably the single most confusing hurdle for new Unix users. [...] We need to finally tackle this, before people are too used to these odd directory names.

Therefore, they propose the following renaming scheme:

/bin      /system/executables
/boot     /system/boot
/dev      /system/devices
/etc      /system/config
/lib      /system/libraries
/home     /users
/media    /storage
/mnt      /storage
/proc     /system/processes
/root     /users/Administrator
/sbin     /system/executables/admin
/tmp      /system/temporary
/usr      /system/applications

They'll include a patch for the GNU C library as well as for AppArmor to redirect the old path names to the new ones. Given the existing filename matching already done by AppArmor the overhead is expected to be neglible at least for AppArmor enabled systems. SELinux enabled systems will remain unchanged, since the user won't be allowed to see anything potentially irritating in the root directory anyway, but will be confined to his user directory.

Since there are a dozen applications that will need changes to accomodate the new naming scheme, expect these changes only to be included with Ubuntu 10.4 (also lovingly named Ubuntu X) scheduled for April 2010.

Other distributions are expected to follow up with these changes in 2011.

P.S. Yeah, the Ubuntu folks really need to think this throuh some more. Russel pointed out that "My System" is even easier to understand; after all this is not about someone elses system or some systematic error or whatever. I figure he's right. How about "My Computer" than this lowercase (pessimistic?) "system" directory they're proposing there!

2008-04-01 17:12 — Categories: English Linux DebianPermaLink & Comments

Google Summer Of Code 2008

As blogged before, Debian is in the Google Summer of Code 2008


So far, we have rather few applications - much less than last year. This doesn't seem specific to Debian, other organizations have also been reporting fewer applications, and Google is considering a deadline extension. Maybe the low number is related to Easter holidays. Also at least at my university the summer term will start only on April 1st, just past the deadline. So many students probably are still away in holiday.

Anyway: if you are interested in participating in the Google Summer of Code, chances are still pretty good. We don't have too many applications yet; not even all of the projects on the Wiki Ideas page have received a submission yet, only a few have received more than one; and even with those a well-written submission standas a good chance. Also some new ideas have been added in the meantime.

In particular missing from our submissions list are:

  • MergeMaster port
  • debexpo
  • CDD webtools
  • security policy

(see the Wiki page for details on these projects).

Especially the lack of a submission for the MergeMaster port is surprising. Many people would love to see a good configuration file merging tool in Debian. I can only guess that people are thinking "awh, everybody is going to submit an application for this one, I don't have a chance here". You currenlty DO have a chance, because there is no single proposal in for this one yet!

If you have any questions, IRC channel #debian-soc in OFTC is pretty useful.

2008-03-29 20:00 — Categories: English Linux DebianPermaLink & Comments
This website uses cookies to personalise content and ads, to provide social media features and to analyse our traffic. We also share information about your use of our site with our social media, advertising and analytics partners. See details