Since I've created the phpMyAdmin container for Docker I've always felt strange about using PHP's built in web server there. It really made it poor choice for any production setup and probably was causing lot of problems users saw with this container. During the weekend, I've changed it to use more complex setup with Supervisor, nginx and PHP FPM.
As building this container is one of my first experiences with Docker (together with Weblate container), it was not as straightforward as I'd hope for, but in the end is seems to be working just fine. While touching the code, I've also improved testing of the Docker container to tests all supported setups and to better report in case of test fails.
The nice side effect of this is that the PHP code is no longer being executed under root in the container, so that should make it more sane for production use as well (honestly I never liked this approach that almost everything is executed as root in Docker containers).
It has been a while that I have been contacted by a recruiter, and the last few ones were fairly decent conversations, where they made an effort to research me first, and even if they did not get everything right, they still listened, and we had a productive talk. But four days ago, I had another recruiter reach out to me, from a company I know oh so well: one I ranted about before: Google. Apparently, their recruiters still do carpet-bombing style outreach. My first thought was "what took them so long?" - it has been five years since my last contact with a Google recruiter. I almost started missing them. Almost. To think that Google is now powerful enough to read my mind, is scary. Yet, I believe, this is not the case; rather, it's just another embarrassing mistake.
To make my case, let me quote the full e-mail I was sent, with the name of the sender redacted, and my comments - which I'm also sending to the recruiter:
How are you? Hope you're well.
Thank you, I'm fine, just back from vacation, and I was thrilled to read your e-mail. Although, I did find it surprising too, and considering past events, I thought it to be spam first.
My name is XXX and I am recruiting for the Google Engineering team. I have just found your details on Github...
I'm happy that you found me through GitHub, but I'm curious why you mailed me at my debian.org address then? That address is not on my GitHub profile, and even though I have some code signed with that address, that's not what I use normally. My GitHub profile also links to a page I created especially for recruiters, which I don't think you have read - but more on that below.
...and your experience with software development combined with your open source contributions is particularly relevant to Google
Which part of my recent contributions are relevant to Google? For the past few months, the vast majority (over 90%) of my open source work has been on keyboard firmware. If Google is developing a keyboard, then this may be relevant, otherwise, I find it doubtful.
Some of my past OSS contributions may be more relevant, but that's in the past, and it would take some digging to see those from GitHub. And if you did that kind of digging, you would have found the page on my site for recruiters, and would not have e-mailed me at my Debian address, either.
We are always interested in talking to top engineers with your mix of skills and I was wondering if you are at all open to exploring roles with Google in EMEA.
To make things short, my stance is the same as it was five years ago, when I wrote - and I quote - "So, here's a public request: do not email me ever again about job opportunities within Google. I do not wish to work for Google. Not now, not tomorrow, not ever."
This still stands. Please do not ever e-mail me about job opportunities within Google. I do not wish to work for Google, not now, not tomorrow, not five years from now, not ever. This will not change. Many things may change, this however, will not.
But even if I ignore this, let me ask you mix of skills are you exactly interested in? Keyboard firmware hacking, mixed with Emacs Lisp, some Clojure, and hacking on Hy (which, if you have explored my GitHub profile, will surely know) from time to time? Or is it my Debian Developer hat that got your interest? If so, why didn't you say so? Not that it would change anything, but I'm curious.
Is it my participation in 24pullrequests? Or my participation in GSoC in years past?
Nevertheless, my list of conditions I mentioned above, apply. Is Google able to fulfill all my requirements, and the preferences too? Last time I heard, working for Google required one to relocate, which I clearly said on that page, I'm not willing to do.
The teams I recruit for are responsible for Google's planet-scale systems. Just to give you more of an idea, some of the projects we work on that might be of interest to you would include:
- App Engine
And how would these be interesting to me, considering my recent OSS work? (Hint: none of them interest me, not a bit. Ok perhaps MapReduce, a little.)
I think you could be a great fit here, where you can develop a great career and at the same time you will be part of the most mission critical team, designing and developing systems which run Google Search, Gmail, YouTube, Google+ and many more as you can imagine.
My career is already developing fine, thank you, I do not need Google to do that. I am already working on things I consider important and interesting, if I wanted to change, I would. But I certainly would not consider a company which I had asked numerous times NOT to contact me about opportunities. If you can't respect this wish, and forget about this in mere five years, why would I trust you to keep any other promises you make now?
Thank you so much for your time and I look forward to hearing from you.
I wish you had spent as much time researching me - or even half that - as I have spent replying to you. I suppose this is not the reply you were expecting, or looking for, but this is the only one I'll ever give to anyone from Google.
And here, at the end, if you read this far, I'm asking you, and everyone at Google to never contact me about job opportunities. I will not work for Google. Not now, not tomorrow, not five years from now, not ever. Please do not e-mail me again, and do not reply to this e-mail either. I'm not interested in neither apologies, nor promises that you won't contact me - just simply don't do it.
I was recently asked to get data from a computer that controlled security cameras after a crime had been committed. Due to the potential issues I refused to collect the computer and insisted on performing the work at the office of the company in question. Hard drives are vulnerable to damage from vibration and there is always a risk involved in moving hard drives or systems containing them. A hard drive with evidence of a crime provides additional potential complications. So I wanted to stay within view of the man who commissioned the work just so there could be no misunderstanding.
The system had a single IDE disk. The fact that it had an IDE disk is an indication of the age of the system. One of the benefits of SATA over IDE is that swapping disks is much easier, SATA is designed for hot-swap and even systems that don’t support hot-swap will have less risk of mechanical damage when changing disks if SATA is used instead of IDE. For an appliance type system where a disk might be expected to be changed by someone who’s not a sysadmin SATA provides more benefits over IDE than for some other use cases.
I connected the IDE disk to a USB-IDE device so I could read it from my laptop. But the disk just made repeated buzzing sounds while failing to spin up. This is an indication that the drive was probably experiencing “stiction” which is where the heads stick to the platters and the drive motor isn’t strong enough to pull them off. In some cases hitting a drive will get it working again, but I’m certainly not going to hit a drive that might be subject to legal action! I recommended referring the drive to a data recovery company.
The probability of getting useful data from the disk in question seems very low. It could be that the drive had stiction for months or years. If the drive is recovered it might turn out to have data from years ago and not the recent data that is desired. It is possible that the drive only got stiction after being turned off, but I’ll probably never know.Doing it Properly
Ever since RAID was introduced there was never an excuse for having a single disk on it’s own with important data. Linux Software RAID didn’t support online rebuild when 10G was a large disk. But since the late 90’s it has worked well and there’s no reason not to use it. The probability of a single IDE disk surviving long enough on it’s own to capture useful security data is not particularly good.
Even with 2 disks in a RAID-1 configuration there is a chance of data loss. Many years ago I ran a server at my parents’ house with 2 disks in a RAID-1 and both disks had errors on one hot summer. I wrote a program that’s like ddrescue but which would read from the second disk if the first gave a read error and ended up not losing any important data AFAIK. BTRFS has some potential benefits for recovering from such situations but I don’t recommend deploying BTRFS in embedded systems any time soon.
Monitoring is a requirement for reliable operation. For desktop systems you can get by without specific monitoring, but that is because you are effectively relying on the user monitoring it themself. Since I started using mon (which is very easy to setup) I’ve had it notify me of some problems with my laptop that I wouldn’t have otherwise noticed. I think that ideally for desktop systems you should have monitoring of disk space, temperature, and certain critical daemons that need to be running but which the user wouldn’t immediately notice if they crashed (such as cron and syslogd).
There are some companies that provide 3G SIMs for embedded/IoT applications with rates that are significantly cheaper than any of the usual phone/tablet plans if you use small amounts of data or SMS. For a reliable CCTV system the best thing to do would be to have a monitoring contract and have the monitoring system trigger an event if there’s a problem with the hard drive etc and also if the system fails to send a “I’m OK” message for a certain period of time.
I don’t know if people are selling CCTV systems without monitoring to compete on price or if companies are cancelling monitoring contracts to save money. But whichever is happening it’s significantly reducing the value derived from monitoring.
- Health and Status Monitoring via Smart Phone Health Monitoring Eric Topol gave an interesting TED talk about...
- Planning Servers for Failure Sometimes computers fail. If you run enough computers then you...
- Shelf-life of Hardware Recently I’ve been having some problems with hardware dying. Having...
Three moments from earlier this week..
Sprawled under a tree after three hours of hiking with a heavy, water-filled pack, I look past my feet at six ranges of mountains behind mountains behind flowers.
From my campsite, I can see the rest of the path of the Appalachian Trail across the Roan balds, to Big Hump mountain. It seems close enough to touch, but not this trip. Good to have a goal.
Near sunset, land and sky merge as the mist moves in.
What happened in the Reproducible Builds effort between Sunday August 21 and Saturday August 27 2016:GSoC and Outreachy updates
- #834976 filed against auto-apt-proxy by Chris Lamb.
- #835637 filed against myghty by Chris Lamb.
- #835061 filed against varnish by Chris Lamb.
- #835633 filed against pleiades by Chris Lamb.
- #835625 filed against nikwi by Chris Lamb.
- #835263 filed against binutils-m68hc1x by Chris Lamb.
- #835448 filed against eekboek by Chris Lamb.
- #835143 filed against ttf-tiresias by Chris Lamb.
- #835637 filed against myghty by Chris Lamb.
- #835495 filed against broccoli by Chris Lamb.
- #835129 filed against dateutils by Chris Lamb.
- #835051 filed against sheepdog by Chris Lamb.
- #835145 filed against udpcast by Chris Lamb.
- #834983 filed against eyed3 by Chris Lamb.
- #835617 filed against congress by Chris Lamb.
- #835376 filed against lilyterm by Chris Lamb.
- #835130 filed against ircd-ircu by Chris Lamb.
- #835262 filed against radare2 by Chris Lamb.
- #835193 filed against phpdox by Chris Lamb.
- #835265 filed against argyll by Chris Lamb.
- #835259 filed against quvi by Chris Lamb.
- #835371 filed against dispcalgui by Chris Lamb.
- #835147 filed against javatools by Chris Lamb.
- #834988 filed against twitter-bootstrap3 by Chris Lamb.
- #835463 filed against fdroidserver by Chris Lamb.
- #835646 filed against dh-lua by Chris Lamb.
- #835447 filed against libmodule-build-withxspp-perl by Chris Lamb.
- #835418 filed against libfm by Chris Lamb.
- #835143 filed against ttf-tiresias by Chris Lamb.
- #834993 filed against oss4 by Reiner Herrmann.
10 package reviews have been added and 6 have been updated this week, adding to our knowledge about identified issues.
A large number of issue types have been updated:
- Add captures_build_path issue and some packages affected by it
- Add golang_compiler_captures_build_path_in_binary and move obfs4proxy to it
- Move 7 golang packages from captures_build_path to golang_compiler_captures_build_path_in_binary
- Add new:
- Fixes for issues created:
- Patch for zope_random_field_order_in_dzproduct uploaded.
- Fix the link for the golang issue, previous link is for random_build_path_by_golang_compiler a different issue
- Add a tip regarding how to call ./configure for rust
- Add offending source line for gcc-defaults.
29 FTBFS bugs have been reported by:
- Chris Lamb (27)
- Daniel Stender (1)
- Santiago Vila (1)
- Chris Lamb:
- Add tests for skip_unless_tool_exists helper.
- comparators/elf.py: Specify string format arguments as logging function parameters, not using interpolation.
- Tidy imports in Debian comparator and tests.
- Skip Haskell tests if GHC version does not match. (Closes: #835055)
- Use pytest.xfail over assert False.
- Use the debian_fallback.X as the fallback for debian.DotBuildinfoFile (not debian.X).
- Rename skip_unless_tool_exists -> skip_unless_tools_exist and fix logic.
- Avoid ugly DRY violations in diffoscope.comparators.__init__ by dynamically importing classes via a single list.
- Satyam Zode:
- Mattia Rizzolo:
- Be even more verbose about failing tests
- d/control: alternate build-dependency on default-jdk-headless|default-jdk, to ease backporting to older debian releases
- add default-jdk to the alternate packages for javap for Debian; default-jdk-headless is not available in older Debian releases
- in the tests only, normalize xxd's output so that we can compare jessie's xxd with stretch's
- Jérémy Bobbio:
- Ximin Luo:
strip-nondeterminism 0.023-1 was uploaded by Chris Lamb:
* Support Android .apk files with the JAR normalizer. * handlers/png.pm: Drop unused Archive::Zip import * Remove hyphen from non-determinism and non-deterministic. * javaproperties.pm: Match more styles of .properties and loosen filename matching. * Improve tests: - Make fixture runner generic to all normalizer types. - Replace (single) pearregistry test with a fixture. - Set a canonical time for fixture tests. - Add gzip testcase fixture. - Replace t/javadoc.t with fixture - Replace t/ar.t with a fixture. - t/javaproperties: move pom.properties and version.properties tests to fixtures - t/fixtures.t: move to using subtests - t/fixtures.t: Explicitly test that we can find a normalizer - t/fixtures.t: Don't run normalizer if we didn't find one.
strip-nondeterminism 0.023-2 uploaded by Mattia Rizzolo to allow stderr in autopkgtest.disorderfs development
- Chris Lamb:
- Link to jenkins documentation in every page (h01ger)
- In the "pre build" check, whether a node is up, now also detects if a node has a read-only filesystem, which sometimes happens on some broken armhf nodes. (h01ger)
- Collapse whitespace to avoid ugly "trailing underlines" in hyperlinks for diffoscope results and pkg sets (Chris Lamb)
- Give details HTML elements "cursor: pointer" CSS property to highlight they are clickable. (Chris Lamb)
This week's edition was written by Chris Lamb and reviewed by a bunch of Reproducible Builds folks on IRC.
Many people reading this have already suffered me talking to them about Prometheus. In personal conversation, or in the talks I gave at DebConf15 in Heidelberg, the Debian SunCamp in Lloret de Mar, BRMlab in Prague, and even at a talk on a different topic at the RABS in Cluj-Napoca.
Since their public announcement, I have been trying to support the project in the ways I could: by packaging it for Debian, and by spreading the word.
Last week the first ever Prometheus conference took place, so this time I did the opposite thing and I spoke about Debian to Prometheus people: I gave a 5 minutes lightning talk on Debian support for Prometheus.
What blew me away was the response I've got: from this tiny non-talk I prepared in 30 minutes, many people stopped me later to thank me for packaging Prometheus, and for Debian in general. They told me they were using my packages, gave me feedback, and even some RFPs!
At the post-conference beers, I had quite a few interesting discussions about Debian, release processes, library versioning, and culture clashes with upstream. I was expecting some Debian-bashing (we are old-fashioned, slow, etc.), instead I had intelligent and enriching conversations.
To me, this enforces once again my support and commitment to community conferences, where nobody is a VIP and everybody has something to share. It also taught me the value of intersecting different groups, even when there seems to be little in common.
FOAAS upstream came out with release 1.1.0 earlier last week. Tyler Hunt was kind enough to provide an almost immediate pull request adding support for the extended capabilties. Following yesterday's upload we now have version 1.1.0 of rfoaas on CRAN.
It brings six more accessors: maybe(), blackadder(), horse(), deraadt(), problem(), cocksplat() and too().
As usual, CRANberries provides a diff to the previous CRAN release. Questions, comments etc should go to the GitHub issue tracker. More background information is on the project page as well as on the github repo
I wrote my first Mojolicious web app yesterday, a cloud-init meta-data server to enable running pre-built VM images (e.g. as provided by debian, ubuntu, etc) without having to install and manage a complete, full-featured cloud environment like openstack.
I hacked up something similar several years ago when I was regularly building VM images at home for openstack at work, with just plain-text files served by apache, but that had pretty-much everything hard-coded. fakecloud does a lot more and allows per-VM customisation of user-data (using the IP address of the requesting host). Not bad for a day’s hacking with a new web framework.
There has been some discussion  around my decision to drop sysvinit support in the conntrackd package in Debian  (version 1:1.4.4-2).
The rationale I used for such a movement was sent to the debian-devel  mailing list, and here it is:
- the default init system in debian is systemd
- I don't have any sysvinit system to keep sysvinit files under any kind of maintenance
- sysvinit conntrackd script is really poor, to reliably use conntrackd as a system daemon you should use systemd
- conntrackd & systemd are very good integrated (using libsystemd)
- systemd is starting to drop support for some sysvinit mechanisms 
- it's time to let sysvinit die
Lots of people have talked to me with both support and disagreement with the change.
Before reading the rest of this blogpost, please note that I'm not interested in the 'systemd vs sysvinit' war, and starting now I will focus mainly on the subject of building a firewall cluster with netfilter technology and the reasons why I think sysvinit here is irrelevant.
I started working with firewall clusters by the time of Debian Squeeze. By then, I used only sysvinit, because it was the Debian default init system and because I did not dive so much in the internals of the firewall cluster itself.
By then, the conntrackd debian package included support for sysvinit by means of two files (the two files that I dropped in 1:1.4.4-2) :
Using both files, you could start/stop conntrackd, and nothing more (for example, a proper status check was not implemented).
The conntrackd daemon is used in HA firewall clusters to replicate connection states between nodes of the cluster, so flow states are known in all nodes and they can properly perform stateful firewalling.
When you build HA clusters, there are 2 basic states of the cluster you may check and adjust: failover and failback.
With conntrackd, the failover situation is straight forward: the other node has the state information already from the dying node.
The failback situation is different: depending on the configuration of both the cluster and conntrackd, the new node may ask for a complete synchronisation to the other node when it become alive again (at boot time, for example) . This is the case if you are building a multi-master firewall cluster (i.e: both nodes are seeing traffic and filtering at the same time).
Asking for a complete synchronisation is done by means of a new instance of conntrackd, which communicates using a UNIX socket to the main conntrackd daemon (the one which is actually communicating with the other node). A failback boot procedure may look like this:
- system boots
- firewall ruleset loading
- networking up
- conntrackd up (main sync daemon: using 'conntrackd -d'; UNIX socket is opened)
- request sync with other node (using `conntrackd -n' which uses the UNIX socket opened in step 4)
In both sysvinit and systemd cases, the step 5 may be implemented using another dummy service which performs the required operations and that depends on the main service representing the step 4.
The point here is that steps 4 and 5 suffer a very bad race condition: the conntrackd daemon may open the UNIX socket (step 4) *after* the we try to use it (step 5).
As you could probably imagine, this is the worst possible scenario: as one of the nodes of the cluster is missing important flow state information the stateful firewall will drop packets and all the network monitoring alarms will start to ring... Ironically, just after a failback operation, when all of our cluster is supposed to be up an running.
To avoid the race conditions, some typical hacks could be implemented:
- a wait loop for the socket
- manual delay (sleep time) between step 4 and step 5
- some kind of poll mechanism
- conntrackd somehow notifies of UNIX socket being opened
After a bit of research, I found that the last point could be implemented very easily using libsystemd, so the daemon inform of its internal state to systemd .
The solution is elegant, simple and offers more direct benefits:
- systemd watchdog support
- no guess games with the PID of the daemon
- shutdown detection by systemd (so if the daemon was killed with 'conntrackd -k', systemd detects it)
- we get the service 'status' check (missing in sysvinit)
It's obvious to me that systemd is a better technology than sysvinit. The sysvinit approach has been OK for a while, and for me it was fascinating when I started developing init scripts and learning how things worked.But now we have systemd. It's the default in Debian. It's far better.
Conclusions: yes, I will probably reintroduce sysvinit files just to avoid any flamewar.
This release just updates a few package internals such as the vignette, the DESCRIPTION and the README.md file as well as under Travis script used for continuous integration.Changes in version 0.2.5 (2016-08-26)
Synchronized code with the cnpy repository
NOAA decommissioning weather.noaa.gov led to breakage which reveals just how much duplication of code and effort there is for fetching and parsing weather data.
During this year’s ESSLLI (European Summer School in Logic, Language and Information) I was teaching a course on Algebraic Specification and Verification with CafeOBJ. Now that the course is over I can relax a bit and enjoy the beauty of the surrounding North Tyrol.
For those who couldn’t attend the ESSLLI or the course, here are the course materials:
- Day 1 – Introduction, with two short programming challenges: esslli-cafeobj-day1.pdf
- Day 2 – Advanced topics: esslli-cafeobj-day2.pdf
- Day 3 – Advanced topics II and CloudSync: esslli-cafeobj-day3.pdf
- Day 4 – Exploiting AC and Hidden Algebras: esslli-cafeobj-day4.pdf
- Day 5 – Proving with CafeOBJ – CITP: esslli-cafeobj-day5.pdf
- Code for all the lectures and exercises: cafe.zip
Thanks to the participants for the interesting questions and participation.
What follows is the original description of the course.Abstract
Ensuring correctness of complex systems like computer programs or communication protocols is gaining ever increasing importance. For correctness it does not suffice to consider the finished system, but correctness already on the level of specification is necessary, that is, before the actual implementation starts. To this aim, algebraic specification and verification languages have been conceived. They are aiming at a mathematically correct description of the properties and behavior of the systems under discussion, and in addition often allow to prove (verify) correctness within the same system.
This course will give an introduction to algebraic specification, its history, logic roots, and actuality with respect to current developments. Paired with the theoretical background we give an introduction to CafeOBJ, a programming language that allows both specification and verification to be carried out together. The course should enable students to understand the theoretical background of algebraic specification, as well as enable them to read and write basic specifications in CafeOBJ.Description
CafeOBJ is a specification language based on three-way extensions to many-sorted equational logic: the underlying logic is order-sorted, not just many-sorted; it admits unidirectional transitions, as well as equations; it also accommodates hidden sorts, on top of ordinary, visible sorts. A subset of CafeOBJ is executable, where the operational semantics is given by a conditional order-sorted term rewriting system.
The language system CafeOBJ has been under constant development at the institute of the lecturers since the late 80ies. It is closely related to other algebraic specification languages in the OBJ family, including Maude. The CafeOBJ language and the range of verification methods and tools it supports – including its support for inductive theorem proving, verification of behavioral specifications, deductive invariant proof, and reachability analysis of concurrent systems – has played a key role in both extending and bringing algebraic specification techniques into contact with many software engineering applications.
The following topics will be discussed:
- algebraic foundations: many-sorted algebras, order-sorted algebras, behavioral specification
- computational foundations: rewriting
- programming with CafeOBJ: language elements, modules, simple programs
- CloudSync: presentation of an example cloud synchronization protocol and its verification
To make the lectures not too `heavy’, we will structure each lecture into two parts: A first part providing an introduction of some theoretical concept, or framework, and a second part dealing with actual programming and implementation. Especially for the second part of each lecture students are encouraged to use their laptops to try out code and experiment.
Once I got CI working on multiple platforms the obvious next step was to be able to aggregate coverage reports across them. This should not be that hard, right? Well I've spent couple of hours on that during last few days.
On Linux and OSX it was pretty much straightforward. Both GCC and Clang do support coverage, so it's just matter of configuring them properly and collect the coverage reports. I've used own solution for that in past and that was really far from working well (somehow I never managed to get coverage fully uploaded to Codecov). Fortunately there exists CMake script called CMake-codecov which does all needed work and works out of the box on GCC and Clang (even on OSX). Well it works on Travis only once you update the compilers and install llvm-cov tool.
The Windows part on AppVeyor was much harder for me. This can be heavily accounted to lack of my experience with Windows and especially development on Windows in past ten years (probably even more). First challenge was to find something what can generate code coverage there.
After lot of googling I've settled down on OpenCppCoverage what seems to be the only free solution I was able to find. The good thing is that it can generate coverage in Cobertura format that Codecov undestands. There are also bad things that I've learned. First of all it's quite hard to integrate this with CTest. There is no support for wrapping test calls in custom commands, so I've misused the memory checks for that purpose. I've written small python script which pretends the valgrind interface and does call OpenCppCoverage in the background.
Now I had around 800 coverage files (one for each test case) and we need to deal with them somehow. The Codeconv command line client doesn't deal wit this out of the box so the obvious choice was to merge them before upload. There even seems to be script doing that, but unfortunately trying that on our coverage data make it nowhere near completion within hour, so that's not really good choice. Second thing I've tried was merging binary coverage in OpenCppCoverage and then exporting to Cobertura format. Obviously Gammu is special project as all I got from this attempt was crashing OpenCppCoverage (it did merge some of the coverages, but it failed in the end without indicating any error).
In the end I've settled down to uploading files in chunks to Codecov. This seems to work quite okay, though is a bit slow, mostly due to way how Codecov bash uploader prepares data to upload (but this will be hopefully fixed soon).
Anyway the goal has been reached, both Windows and Linux code shows in coverage reports.
Another Armadillo 7.* release -- now at 7.400. We skipped the 7.300.* serie release as it came too soon after our most recent CRAN release. Releasing RcppArmadillo 0.7.400.2.0 now keeps us at the (roughly monthly) cadence which works as a good compromise between getting updates out at Conrad's sometimes frantic pace, while keeping CRAN (and Debian) uploads to about once per month.
So we may continue the pattern of helping Conrad with thorough regression tests by building against all (by now 253 (!!)) CRAN dependencies, but keeping release at the GitHub repo and only uploading to CRAN at most once a month.
Armadillo is a powerful and expressive C++ template library for linear algebra aiming towards a good balance between speed and ease of use with a syntax deliberately close to a Matlab.
The new upstream release adds new more helper functions. Detailed changes in this release relative to the previous CRAN release are as follows:Changes in RcppArmadillo version 0.7.400.2.0 (2016-08-24)
Upgraded to Armadillo release 7.400.2 (Feral Winter Deluxe)
added expmat_sym(), logmat_sympd(), sqrtmat_sympd()
Upgraded to Armadillo release 7.300.1
added index_min() and index_max() standalone functions
expanded .subvec() to accept size() arguments
more robust handling of non-square matrices by lu()
to me, an inclusive security community would focus as much (or at all) on surveillance of women by abusive partners as it does the state— kelsey ᕕ( ᐛ )ᕗ (@_K_E_L_S_E_Y) August 2, 2016
and it got me thinking. Security research is often derided as unnecessary stunt hacking, proving insecurity in things that are sufficiently niche or in ways that involve sufficient effort that the realistic probability of any individual being targeted is near zero. Fixing these issues is basically defending you against nation states (who (a) probably don't care, and (b) will probably just find some other way) and, uh, security researchers (who (a) probably don't care, and (b) see (a)).
Unfortunately, this may be insufficient. As basically anyone who's spent any time anywhere near the security industry will testify, many security researchers are not the nicest people. Some of them will end up as abusive partners, and they'll have both the ability and desire to keep track of their partners and ex-partners. As designers and implementers, we owe it to these people to make software as secure as we can rather than assuming that a certain level of adversary is unstoppable. "Can a state-level actor break this" may be something we can legitimately write off. "Can a security expert continue reading their ex-partner's email" shouldn't be.
For centuries man has hunted, he brought the animals to pasture, cultivated fields and sailed the seas without any kind of tool to measure time. Back then, the time was not measured, but only estimated with vague approximation and its pace was enough to dictate the steps of the day and the life of man. Subsequently, for many centuries, hourglasses accompanied the civilization with the slow flow of their sand grains. About hourglasses, Ernst Junger writes in “Das Sanduhrbuch – 1954” (no English translation): “This small mountain, formed by all the moments lost that fell on each other, it could be understood as a comforting sign that the time disappears but does not fade. It grows in depth”.
For the philosophers of ancient Greece, the time was just a way to measure how things move in everyday life and in any case there was a clear distinction between “quantitative” time (Kronos) and “qualitative” time (Kairòs). According to Parmenides, time is guise, because its existence…Tweet
In case you just upgraded to the latest gnupg-agent and used gnupg-agent as your ssh-agent you may find that ssh refuses to work with a simple but not helpful
sign_and_send_pubkey: signing failed: agent refused operation
This seems to come from systemd starting the agent, no longer a script at the start of the X session. And so it ends up with either no or an unusable tty. A simple
gpg-connect-agent updatestartuptty /bye
updates that and voila, ssh agent functionality is back in.
Note: This assumes you have “enable-ssh-support” in your ~/.gnupg/gpg-agent.conf
Long flights and lazy afternoons relaxing from teaching, I tried out another game on my Android device, Deus Ex Go. It is a turn based game in the style of the Deus Ex series (long years ago I was beta tester for the Deus Ex version of LGP). A turn based game where you have to pass through a series of levels, each one consisting of an hexagonal grid with an entry and exit point, and some nasty villains or machines trying to kill you.
Without any explanations given you are thrown into the game and it takes a few iterations until you understand what kind of attacks you are facing, but once you have figured that out, it is a more or less simple game of combination how to manage to get to the exit. I played through the around 50 levels of the story mode and I think it was only in the last five that I once or twice had to actually try and think hard to find a solution.
I found the game quite amusing at the beginning, but soon it became repetitive. But since you can play through the whole story mode in probably one long afternoon, that is not so much of a problem. More a problem is the apparently incredible battery usage of this game. Playing without checking for some time leaves you soon with a near empty battery.
Graphically well done, with more or less interesting gameplay, it still does not stand up to Monument Valley.
After upgrading an Ubuntu 14.04 ("trusty") machine to the latest 16.04 Hardware Enablement packages, I ran into login problems. I could log into my user account and see the GNOME desktop for a split second before getting thrown back into the LightDM login manager.
The solution I found was to install this missing package:
apt install libwayland-egl1-mesa-lts-xenialLooking for clues in the logs
The first place I looked was the log file for the login manager (/var/log/lightdm/lightdm.log) where I found the following:
DEBUG: Session pid=12743: Running command /usr/sbin/lightdm-session gnome-session --session=gnome DEBUG: Creating shared data directory /var/lib/lightdm-data/username DEBUG: Session pid=12743: Logging to .xsession-errors
This told me that the login manager runs the gnome-session command and gets it to create a session of type gnome. That command line is defined in /usr/share/xsessions/gnome.desktop (look for Exec=):
[Desktop Entry] Name=GNOME Comment=This session logs you into GNOME Exec=gnome-session --session=gnome TryExec=gnome-shell X-LightDM-DesktopName=GNOME
I couldn't see anything unexpected there, but it did point to another log file (~/.xsession-errors) which contained the following:
Script for ibus started at run_im. Script for auto started at run_im. Script for default started at run_im. init: Le processus gnome-session (GNOME) main (11946) s'est achevé avec l'état 1 init: Déconnecté du bus D-Bus notifié init: Le processus logrotate main (11831) a été tué par le signal TERM init: Le processus update-notifier-crash (/var/crash/_usr_bin_unattended-upgrade.0.crash) main (11908) a été tué par le signal TERM
Seaching for French error messages isn't as useful as searching for English ones, so I took a look at /var/log/syslog and found this:
gnome-session: WARNING: App 'gnome-shell.desktop' exited with code 127 gnome-session: WARNING: App 'gnome-shell.desktop' exited with code 127 gnome-session: WARNING: App 'gnome-shell.desktop' respawning too quickly gnome-session: CRITICAL: We failed, but the fail whale is dead. Sorry....
It looks like gnome-session is executing gnome-shell and that this last command is terminating prematurely. This would explain why gnome-session exits immediately after login.Increasing the amount of logging
In order to get more verbose debugging information out of gnome-session, I created a new type of session (GNOME debug) by copying the regular GNOME session:
cp /usr/share/xsessions/gnome.desktop /usr/share/xsessions/gnome-debug.desktop
and then adding --debug to the command line inside gnome-debug.desktop:
[Desktop Entry] Name=GNOME debug Comment=This session logs you into GNOME debug Exec=gnome-session --debug --session=gnome TryExec=gnome-shell X-LightDM-DesktopName=GNOME debug
After restarting LightDM (service lightdm restart), I clicked the GNOME logo next to the password field and chose GNOME debug before trying to login again.
This time, I had a lot more information in ~/.xsession-errors:
gnome-session: DEBUG(+): GsmAutostartApp: starting gnome-shell.desktop: command=/usr/bin/gnome-shell startup-id=10d41f1f5c81914ec61471971137183000000128780000 gnome-session: DEBUG(+): GsmAutostartApp: started pid:13121 ... /usr/bin/gnome-shell: error while loading shared libraries: libwayland-egl.so.1: cannot open shared object file: No such file or directory gnome-session: DEBUG(+): GsmAutostartApp: (pid:13121) done (status:127) gnome-session: WARNING: App 'gnome-shell.desktop' exited with code 127
which suggests that gnome-shell won't start because of a missing library.Finding the missing library
To find the missing library, I used the apt-file command:
apt-file update apt-file search libwayland-egl.so.1
and found that this file is provided by the following packages:
Since I installed the LTS Enablement stack, the package I needed to install to fix this was libwayland-egl1-mesa-lts-xenial.
I filed a bug for this on Launchpad.