Russ Allbery: Review: A Man Called Ove
| Translator: | Henning Koch |
| Publisher: | Washington Square |
| Copyright: | 2012, 2014 |
| Printing: | May 2015 |
| ISBN: | 1-4767-3802-5 |
| Format: | Trade paperback |
| Pages: | 337 |
| Translator: | Henning Koch |
| Publisher: | Washington Square |
| Copyright: | 2012, 2014 |
| Printing: | May 2015 |
| ISBN: | 1-4767-3802-5 |
| Format: | Trade paperback |
| Pages: | 337 |
| Translator: | Henning Koch |
| Publisher: | Washington Square |
| Copyright: | 2012, 2014 |
| Printing: | May 2015 |
| ISBN: | 1-4767-3802-5 |
| Format: | Trade paperback |
| Pages: | 337 |
A brand new anytime package just arrived at CRAN. This is release number eight, evenly spread with over two per month, since the initial release in September. Needless to say I have been told off not to make this many releases. As they say, no good deed goes unpunished.
anytime is a very focused package aiming to do just one thing really well: to convert anything in integer, numeric, character, factor, ordered, ... format to either POSIXct or Date objects -- and to do so without requiring a format string. See the anytime page, or the GitHub README.md for a few examples.
This releases does a few things:
anydate() would somehow wrap around and return the previous day by accident. This has been addressed by moving the conversion to date directly into the C++ side of things.R> library(anytime)
R> p <- anytime("2010-01-02 03:04:05.123456")
R> p
[1] "2010-01-02 03:04:05.123456 CST"
R> iso8601(p)
[1] "2010-01-02 03:04:05"
R> rfc2822(p)
[1] "Sat, 02 Jan 2010 03:04:05.123456 -0600"
R> rfc3339(p)
[1] "2010-01-02T03:04:05.123456-0600"
R> R> jl <- anydate("July 04, 1789")
R> jl
[1] "1789-07-04"
R> iso8601(jl)
[1] "1789-07-04"
R> rfc2822(jl)
[1] "Sat, 04 Jul 1789"
R> rfc3339(jl)
[1] "1789-07-04"
R> Courtesy of CRANberries, there is a comparison to the previous release. More information is on the anytime page. For questions or comments use the issue tracker off the GitHub repo.Changes in anytime version 0.2.0 (2016-12-24)
- Added (exported) helper functions iso8601(), rfc2822() and rfc3339() to format date(time) objects according to standards
- Conversion to dates is now more robust thanks to improved internal processing (PR #39 closing #36)
- The ISO 8601 format is now recognised, however the timezone information is not parsed by Boost Date_Time (which is a known upstream limitation) (PR #38 closing #37)
- The 'allFormats.R' test script was significantly strengthened (#40)
- Test scripts like 'simpleTests.R' have as also been strengthened (#41); on Windows and in one file two tests need to be skipped.
- A new 'bulkTest.R' test script was added testing parsing against what R returns
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

% appstreamcli what-provides modalias \ usb:v1130p0202d0100dc00dsc00dp00ic03isc00ip00in00 Identifier: pymissile [generic] Name: pymissile Summary: Control original Striker USB Missile Launcher Package: pymissile % appstreamcli what-provides modalias usb:v0694p0002d0000 Identifier: libnxt [generic] Name: libnxt Summary: utility library for talking to the LEGO Mindstorms NXT brick Package: libnxt --- Identifier: t2n [generic] Name: t2n Summary: Simple command-line tool for Lego NXT Package: t2n --- Identifier: python-nxt [generic] Name: python-nxt Summary: Python driver/interface/wrapper for the Lego Mindstorms NXT robot Package: python-nxt --- Identifier: nbc [generic] Name: nbc Summary: C compiler for LEGO Mindstorms NXT bricks Package: nbc %A similar query can be done using the combined AppStream and Isenkram databases using the isenkram-lookup tool:
% isenkram-lookup usb:v1130p0202d0100dc00dsc00dp00ic03isc00ip00in00 pymissile % isenkram-lookup usb:v0694p0002d0000 libnxt nbc python-nxt t2n %You can find modalias values relevant for your machine using cat $(find /sys/devices/ -name modalias). If you want to make this system a success and help Debian users make the most of the hardware they have, please helpadd AppStream metadata for your package following the guidelines documented in the wiki. So far only 11 packages provide such information, among the several hundred hardware specific packages in Debian. The Isenkram database on the other hand contain 101 packages, mostly related to USB dongles. Most of the packages with hardware mapping in AppStream are LEGO Mindstorms related, because I have, as part of my involvement in the Debian LEGO team given priority to making sure LEGO users get proposed the complete set of packages in Debian for that particular hardware. The team also got a nice Christmas present today. The nxt-firmware package made it into Debian. With this package in place, it is now possible to use the LEGO Mindstorms NXT unit with only free software, as the nxt-firmware package contain the source and firmware binaries for the NXT brick. As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.
While I try to minimize Politics and Economics as much as I can on this blog, it sometimes surfaces. It is possible that some people may benefit or at least be aware.
A bit of background is necessary before I jump into the intricacies of the Maharashtra Real Estate Rules and Regulation Draft Rules 2016 (RERA) .
Since ever, but more prominently since 2007/8 potential homeowners from across the country have been suffering at the hands of the builder/promoter for number of years. While it would be wrong to paint all the Real Estate Developers and Builders as cheats (we as in all tenants and homeowners hope there are good ones out there) many Real Estate Builders and promoters have cheated homeowners of their hard-earned money. This has also lessened the secondary (resale) market and tenants like me have to fight over morsels as supply is tight.
There were two broad ways in which the cheating is/was done
a. Take deposits and run away i.e. fly by night operators Here the only option for a homeowner is to file an FIR (First Information Report) and hope the culprits are caught. 99% of the time the builder/promoter goes somewhere abroad and the potential home buyers/home-owners are left holding the can. This is usually done by small real estate promoters and builders.
b. The big boys would take all or most money of the project, may register or not register the flat in your name, either build a quarter or half-finished building and then make excuses. There are some who do not even build. The money given is used by the builder/developer either for his own needs or using that money in some high-profile project which is expensive and may have huge returns. They know that home-owners can t do anything, at the most go to the court which will take more than a decade or two during which time the developer would have interest-free income and do whatever he wants to do.
One of the bigger stories which came up this year was when the Indian Cricket Captain, M.S. Dhoni (cricket is a religion in India, and the cricketers gods for millions of Indians) had to end his brand engagement and ambassadorship from Amrapali Housing Group. Apparently, his wife Sakshi was on the Board of directors at Amrapali Housing and had to resign
The Government knew of such issues and had been working since last few years. Under the present Government, a Model Agreement and a Model Real Estate Rules and Regulation Bill was passed on 31st March and came into force on 1st May 2016.
India, similar to the U.S. and U.K. follows a federal structure. While I have shared this before, most of the laws in India fall in either of three lists, Central List, Concurrent Lists and State Lists. Housing for instance, is a state subject so any laws concerning housing has to be made by the state legislature.
Having a statutory requirement to put the bill in 6 months from 1st of May, the Government of Maharashtra chose to put the draft rules in public domain on 12th December 2016, about 10 days ago and there were efforts to let it remain low-key so people do not object as we are still in the throes of demonetisation. By law they should have given 30 days for people to raise objections and give suggestions.
The State Government too could have easily asked an extension and as both the State and the Centre are of the same Political Party they would have easily got it.
With that, below is the e-mail I sent to suggesstionsonrera@maharashtra.gov.in
Sub Some suggestions for RERA biggest suggestion, need to give more time study the implications for house-owners.
Respected Sir/Madame,
I will be publishing the below mail as a public letter on my blog as well.
I am writing as a citizen, a voter, a potential home owner, currently a tenant . If houses supply is not in time, it is us, the tenants who have the most to lose as we have to fight over whatever is in the market. I do also hope to be a home buyer at some point in time so these rules would affect me also somewhere in the hazy future.
I came to know through the media that Maharashtra Govt. recently introduced draft rules for RERA Real Estate (Regulation and Development) Act, 2016 . I hope to impress upon you that these proposed Rules and Regulations need to be thoroughly revised and new draft rules shared with the public at large with proper announcement in all newspapers and proper time ( more than a month ) to study and give replies on the said matter.
My suggestions and complaints are as under
a. The first complaint and suggestion is that the date between the draft regulations and suggestions being invited by members of public is and was too little 12 December 2016 23 December 2016 (only 11 days) for almost 90 pages of Government rules and regulations which needs multiple rounds of re-reading to understand the implications of the draft rules .
Add to that unlike the Central Building Legislation, Model Agreement which was prepared by Centre and also given wide publicity, the Maharashtra Govt. didn t do any such publicity to bring it to the
FOR the Wine Connoisseur
You can use credit / debit cards almost everywhere. Restaurant waiters also usually have wireless credit / debit terminals that they will bring to your table for you to settle your bill. How much your bank charges depends on your Canadian bank and the banking plan you are on. For instance, on my plan through the Bank Of Montreal, I get (I think) 20 free transactions a month and then after that I m charged $0.50CDN/piece. However, if I go to a Bank Of Montreal ATM and withdraw cash, there is no service fee for that. There is no service fee for using *credit* cards, only *debit* cards tend to have the fee. I live in a really rural area so I can t always get to a Bank Of Montreal machine for cash. So what I usually end up doing, is either pay by credit and then pay of the balance right away so I don t have to pay interest, or when I do use my bank card to pay for something, I ask if I can get cash back as well. Yes, Canada converted to plastic notes a few years ago. We ve also eliminated the penny. For cashless transactions, you pay the exact amount billed. If you re paying somebody in cash, it is rounded up or down to the nearest 5 cents. And for $1 or $2, instead of notes, we ve moved over to coins. I personally like the plastic notes. They re smoother and feel more durable than the paper notes. I ve had one go through a laundry load by accident and it came out the other side fine.Another gentleman responded with slightly more information which probably would interest travellers from around the world, not just Indians
Quebec has its own interbank system called Interac (https://interac.ca/en/about/our-company.html). Quebec is a very proud and independent region and for many historical reasons they want to stand on their own, which is why they support their local systems. Some vendors will support only Interac for debit card transactions (at least this was the case when I stayed there the beginning of this decade, it might have changed a bit). *Most* vendors (including supermarkets like Provigo, Metro, etc) will accept major credit and debit cards, although MasterCard isn t accepted as widely there as Visa is. So, if you have one of both, load up your Visa card instead of your MasterCard or get a prepaid Visa card from your bank. They support chip cards everywhere so don t worry about that. If you have a 5 digit pin on any of your cards and a vendor asks you for a 4 digit pin, it will work 90%+ of the times if you just enter the first 4 digits, but it s usually a good idea to go change your pin to a 4 digit just to be safe.From the Indian perspective all of the above fits pretty neat as we also have Pin and Chip cards (domestically though most ATMs still use the magnetic strip and is suspected that the POS terminals aren t any better.) That would be a whole different story so probably left for another day. I do like the bit about pocketing the change tip. As far as number of free transactions go, it was pretty limited in India for few years before the demonetization happening now. Few years before, I do remember doing as many transactions on the ATM as I please but then ATM s have seen a downward spiral in terms of technology upgradation, maintenance etc. There is no penalty to the bank if the ATM is out-of-order. If there was significant penalty then we probably would have seen banks taking more care of ATM s. It is a slightly more complex topic hence would take a stab at it some other day. Do hope though that the terms for ATM usage for bank customers become lenient similar to Canada otherwise it would be difficult for Indians to jump on the digital band-wagon as you cannot function without cheap, user-friendly technology.
The image has been taken from this fascinating article which appeared in Indian Express couple of days back.
Coming back to the cheese and wine in the evening. I think we started coming back from Eagle Encounters around 16:30/17:00 hrs Cape Town time. Somehow the ride back was much more faster and we played some Bollywood party music while coming back (all cool). Suddenly remembered that I had to buy some cheese as I hadn t bought any from India. There is quite a bit of a post where I m trying to know/understand if spices can be smuggled (which much later I learnt I didn t need to but that s a different story altogether), I also had off-list conversations with people about cheese as well but wasn t able to get any good recommendations. Then saw that KK bought Mysore Pak (apparently she took a chance not declaring it) which while not being exactly cheese fit right into things. In her own words a South Indian ghee sweet fondly nicknamed the blocks of cholesterol and reason #3 for bypass surgery . KK
So with Leonard s help we stopped at a place where it looked like a chain of stores. Each store was selling something. Seeing that, I was immediately transported to Connaught Place, Delhi
The image comes from http://planetden.com/food/roundabout-world-connaught-place-delhi which attempts to explain Connaught Place. While the article is okish, it lacks soul and not written like a Delhite would write or anybody who has spent a chunk having spent holidays at CP. Another day, another story, sorry.
What I found interesting about the stores while they were next to each other, I also eyed an alcohol shop as well as an Adult/Sex shop. I asked Leonard as to how far we were from UCT and he replied hardly 5 minutes by car and was shocked to see both alcohol and a sex shop. While an alcohol shop some distance away from a college is understandable, there are few and far around Colleges all over India, but adult shops are a rarity.
Unfortunately, none of us have any photos of the place as till that time everybody s phone was dead or just going to be dead and nobody had thought to bring a portable power pack to juice our mobile devices.
A part of me was curious to see what the sex shop would have and look from inside, but as was with younger people didn t think it was appropriate.
All of us except Jaminy and someone else (besides Leonard) decided to stay back, while the rest of us went inside to explore the stores. It took me sometime to make my way to the cheese corner and had no idea which was good and which wasn t. So with no idea of brands therein, the only way to figure out was the pricing. So bought two, one a larger 500 gm cheap piece and a smaller slightly more expensive one just to make sure that the Debian cheese team would be happy.
We did have a mini-adventure as for sometime Jaminy was missing, apparently she went goofing off or went to freshen up or something and we were unable to connect with her as all our phones were dead or dying.
Eventually we came back to UCT, barely freshened up when it was decided by our group to go and give our share of goodies to the cheese and wine party. When I went up to the room to share the cheese, came to know they needed a volunteer for cutting veggies etc.
Having spent years seeing Yan Can Cook
and having practised quite a bit tried to do some fancy decoration and some julian cutting but as we got dull knives and not much time, just did some plain old cutting
The Salads, partly done by me.

1.5 Litre Pressure Cooker with gasket and everything.

Best cooker for doing Basmati Biryanis and things like that.
Random selection of wine bottles from all over the world.
CHOCOLATES
. Who said gluttony is bad
Or this
French Bread, Wine and chaos
Juices for those who love their health

What we did at the Debian Edu / Skolelinux gathering in November 2016 in Oslo
From November 25 to 27 some people met in the hackerspace bitraf in downtown Oslo. On Saturday and Sunday we met in the morning and hacked and translated all day until we went for dinners in the evening. Despite the short time I think we managed to get a lot done and had good fun, so I'm hoping we'll have another gathering in 2017!
Debian Edu / Skolelinux is currently in better shape regarding the upcoming Debian release than we ever have been, which is pretty awesome. Today, on December 21st, all our changes are in Stretch, except for debian-edu-artwork.git, which awaits a desktop-base upload to unstable the only thing missing is being able to install Debian Edu using our profiles from official media releasing Debian Edu Stretch on the same day as Debian Stretch would be a huge success though!
These are the notes taken in a pad (thanks riseup!) during the meeting:
Phil Hands worked on


deb http://packages.arctica-project.org/ubuntu jessie,stretch,sid maindeb http://packages.arctica-project.org/ubuntu trusty,xenial main wget -qO - http://packages.arctica-project.org/archive.key sudo apt-key add -
The nx-libs software project brings to you the binary packages nxproxy (client-side component) and nxagent (nx-X11 server, server-side component).
Ubuntu developers, please note: we have added nightly builds for Ubuntu latest to our build server. This has been Ubuntu 16.10 so far, but we will soon drop 16.10 support in nightly builds and add 17.04 support.
References
Today marks the 10-year anniversary of my first contribution to Debian GNU/Linux.
I will not recount the full history here but my first experience with Debian was a happy accident. I had sent off for a 5-CD set of Red Hat from The Linux Emporium only to discover I lacked the required 12MB of RAM. Annoyed, I reached for the Debian "potato" CD that was included gratis in my order due to it being outdated at the time
Fast-forwarding a few years, whilst my first contribution was trivial, it was Thomas Bushnell's infectious enthusiasm that led me to contribute more, eventually becoming a Google Summer of Code student under Daniel Baumann, and finally becoming an official Debian Developer in September 2008 with Thomas Viehmann as my Application Manager. (Some things may never change, however I still struggle with the bug tracker's control@ interface.)
doc/conf.py) when a new version of a project is released.
python-setuptools just needs to be added to the setup.py to do its job, and in Bcolz the code goes like this:
setup(
name="bcolz",
use_scm_version=
'version_scheme': 'guess-next-dev',
'local_scheme': 'dirty-tag',
'write_to': 'bcolz/version.py'
The file the version number is written to is bcolz/version.py.
This file isn t in the upstream code revision nor in the tarball which was released by the upstream developers, it s always generated during build time.
In Debian there is an error if you try to build a package from a source tree which contains files which aren t to be found in the corresponding tarball, like cruft from a previous build, or if any files have changed therefore every new package should be test build also twice in a row in a non-chroot environment.
Generally there a two ways to solve this, either you add cruft to debian/clean, or you add the file resp. a matching file pattern to extend-diff-ignore in debian/source/options.
Which method is the better one could be discussed, I m generally using the clean option if something isn t in the upstream tarball, and the source/options solution if something is already in the upstream tarball, but gets changed during a build.
This is related to your preferred Git procedures, if you remove a file which is in the upstream tarball these removals have to be checked in separately, and that means everytime a new upstream tarball is released that is not very convenient.
Another option which is available is to strip certain files from the upstream tarball by putting them on the Files-Excluded in deb/copyright.
By the way, the same complex applies to egg-info/: that folder is shipped or is not shipped in the upstream tarball, and files in that folder get changed during build.
When the source code is put into a Git environment for Debian packaging, there could be problems with the version number setuptools-scm comes up with.
This setuptools extension gets the recent version from the latest Git tag when there is a version number to be found, and that s all right.
In Git environments for Debian packaging (like e.g. of the Debian Science group, the Python groups and the others) that is available, like the commonly used upstream tags have that1.
The problem is, sometimes the upstream version which Debian has2 doesn t match the original upstream version number which is wanted for version in bcolz/version.py.
For example, the suffix +ds is used if the upstream tarball has been stripped from prebuild files or embedded convenience shipments (like it s the case with the Bcolz package where c-blosc/ has been stripped because that s build for another package), of the suffix +dfsg shows that non-DFSG free software has been removed (which can t be distributed through the main archive section).
For example, the version string for Bcolz which is found after the build currently (1.1.0+ds1-1) is 1.1.0+ds1:
# coding: utf-8
# file generated by setuptools_scm
# don't change, don't track in version control
version = '1.1.0+ds1'
But that s not wanted because this version never has been released, but appears everywhere:
$ pip list grep bcolz
bcolz (1.1.0+ds1)
$ python3 -c 'import bcolz; bcolz.print_versions()'
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
bcolz version: 1.1.0+ds1
There are several different ways how to fix this.
The one with the crowbar (like said in German) is to patch use_scm_version out from setup.py, but if you don t provide any version in exchange the version number which is used by Setuptools then is 0.0.0.
The upstream version could be hard-coded into the patch, but then again it has not to be forgotten to update it manually by the maintainer, which is not very convenient.
Plus, setup.py could change and the patch then might need to be unfuzzed, thus more work.
Bad.
A patch could be spared by manipulating and exporting the SETUPTOOLS_SCM_PRETEND_VERSION environment variable for setuptools-scm in debian/rules, which is sometimes used when I see the returns for that string on Debian Code Search.
But how to prevent to hard code the version number, here?
The dpkg-dev package (pulled by build-essential) ships a Makefile snippet /usr/share/dpkg/pkg-info.mk which could be included into debian/rules.
It defines several variables which are useful for packaging, like DEB_SOURCE contains the source package name, they are extracted from debian/changelog.
But, DEB_VERSION_UPSTREAM which is available through that puts out the upstream version without epoch and Debian revision, but it s not getting any finer grained out of the box.
For a custom fix, a regular expression which removes the +... extensions (if present) from the bare upstream version string would be s/\+[^+]*//:
$ echo "1.1.0+ds1" sed -e 's/\+[^+]*//'
1.1.0
$ echo "1.1.0" sed -e 's/\+[^+]*//'
1.1.0
$ echo "1.1.0+dfsg12" sed -e 's/\+[^+]*//'
1.1.0
With that, a custom variable VERSION_UPSTREAM could be set on the top of DEB_VERSION_UPSTREAM (from pkg-info.mk) in debian/rules:
include /usr/share/dpkg/pkg-info.mk
VERSION_UPSTREAM = $(shell echo '$(DEB_VERSION_UPSTREAM)' sed -e 's/\+[^+]*//')
export SETUPTOOLS_SCM_PRETEND_VERSION = $(VERSION_UPSTREAM)
Bam, that works (see the commit here):
# coding: utf-8
# file generated by setuptools_scm
# don't change, don't track in version control
version = '1.1.0'
An addition, I ve seen that dh-python also takes care of SETUPTOOLS_SCM_PRETEND_VERSION since 2.20160609.
The environment variable is set by the Debhelper build system if python 3, -setuptools-scm is among the build-dependencies in debian/control.
The Perl code for that is in dh/pybuild.pm.
I think the version number string above comes from dh-python s pretended version, and not from any of the Git tags (which are currently debian/1.1.0+ds1-1 and upstream/1.1.0+ds1).
Earlier this week, Conrad released Armadillo 7.600.1. The corresponding RcppArmadillo release 0.7.600.1.0 is now on CRAN and in Debian. This follows several of rounds testing at our end with a full reverse-dependency of a pre-release version followed by another full reverse-depency check. Which was of course followed by CRAN testing for two more days.
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. RcppArmadillo integrates this library with the R environment and language--and is widely used by (currently) 298 other packages on CRAN -- an increase of 24 just since the last CRAN release of 0.7.500.0.0 in October!
Changes in this release relative to the previous CRAN release 0.7.500.0.0 are as follows:
Courtesy of CRANberries, there is a diffstat report. More detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.Changes in RcppArmadillo version 0.7.600.1.0 (2016-12-16)
- Upgraded to Armadillo release 7.600.1 (Coup d'Etat Deluxe)
- more accurate
eigs_sym()andeigs_gen()- expanded
floor(),ceil(),round(),trunc(),sign()to handle sparse matrices- added
arg(),atan2(),hypot()Changes in RcppArmadillo version 0.7.500.1.0 (2016-11-11)
- Upgraded to Armadillo release 7.500.1
- Small improvement to return value treatment
- The
sample.hextension was updated to the newer Armadillo interface. (Closes #111)
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
R has excellent tools for dates and times. The Date and POSIXct classes (as well as the 'wide' representation in POSIXlt) are versatile, and a lot of useful tooling has been built around them.
However, POSIXct is implemented as a double with fractional seconds since the epoch. Given the 53 bits accuracy, it leaves just a bit less than microsecond resolution. Which is good enough for most things.
But more and more performance measurements, latency statistics, ... are now measured more finely, and we need nanosecond resolution. For which commonly an integer64 is used to represent nanoseconds since the epoch.
And while R does not a native type for this, the bit64 package by Jens Oehlschl gel offers a performant one implemented as a lightweight S3 class. So this package uses this integer64 class, along with two helper functions for parsing and formatting, respectively, at nano-second resolution from the RcppCCTZ package which wraps the CCTZ library from Google. CCTZ is a modern C++11 library extending the (C++11-native) chrono type.
R> x <- nanotime("1970-01-01T00:00:00.000000001+00:00")
R> print(x)
integer64
[1] 1
R> format(x)
[1] "1970-01-01T00:00:00.000000001+00:00"
R> cat("x+1 is: ")
x+1 is: R> x <- x + 1
R> print(x)
integer64
[1] 2
R> format(x)
[1] "1970-01-01T00:00:00.000000002+00:00"
R>R> options("width"=60)
R> v <- nanotime(Sys.time()) + 1:5
R> v
integer64
[1] 1481505724483583001 1481505724483583002
[3] 1481505724483583003 1481505724483583004
[5] 1481505724483583005
R> format(v)
[1] "2016-12-12T01:22:04.483583001+00:00"
[2] "2016-12-12T01:22:04.483583002+00:00"
[3] "2016-12-12T01:22:04.483583003+00:00"
[4] "2016-12-12T01:22:04.483583004+00:00"
[5] "2016-12-12T01:22:04.483583005+00:00"
R> zoo
R> z <- zoo(cbind(A=1:5, B=5:1), v)
R> options("nanotimeFormat"="%d %b %H:%M:%E*S") ## override default
R> z
A B
12 Dec 01:47:55.812513001 1 5
12 Dec 01:47:55.812513002 2 4
12 Dec 01:47:55.812513003 3 3
12 Dec 01:47:55.812513004 4 2
12 Dec 01:47:55.812513005 5 1
R> integer64 type used to store the nanosecond resolution time as (positive or negative) offsets to the epoch of January 1, 1970. The RcppCCTZ package supplies the formatting and parsing routines based on the (modern C++) library CCTZ from Google.
install.packages("RcppCCTZ") # need 0.1.0 or later
remotes::install_github("eddelbuettel/nanotime") install.packages() (as I do), use the version from the ghrr drat:
install.packages("drat") # easier repo access + creation
drat:::add("ghrr") # make it known
install.packages("nanotime") # install itinstall.packages("nanotime")This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
Quite on the schedule, Weblate 2.10 is out today. This release brings Git exporter module, improves support for machine translation services and adds various CSV exports and API interfaces.
Full list of changes:
demo account using demo password or register your own user. Weblate is also being used on https://hosted.weblate.org/ as official translating service for phpMyAdmin, OsmAnd, Aptoide, FreedomBox, Weblate itself and many other projects.
Should you be looking for hosting of translations for your project, I'm happy to host them for you or help with setting it up on your infrastructure.
Further development of Weblate would not be possible without people providing donations, thanks to everybody who have helped so far! The roadmap for next release is just being prepared, you can influence this by expressing support for individual issues either by comments or by providing bounty for them.
Filed under: Debian English phpMyAdmin SUSE Weblate 0 comments
unattended-upgrades
package within the images.
The unattended-upgrades package contains a Python program that
automatically performs any pending upgrade and is designed to run
unattended. It is roughly the equivalent of doing
apt-get update; apt-get upgrade in a cron job, but has special code to
handle error conditions, warn about reboots, and selectively upgrade
packages. The package was originally written for Ubuntu by Michael Vogt,
a longtime Debian developer and Canonical employee.
Since there was a concern that Debian cloud images would be different
from normal Debian installs, McIntyre suggested installing
unattended-upgrades by default on all Debian installs, so that people
have a consistent experience inside and outside of the cloud. The
discussion that followed was interesting as it brought up key issues one
would have when deploying automated upgrade tools, outlining both the
benefits and downsides to such systems.
policy-rc.d
mechanism
to disable service restarts on certain packages out of the box.
unattended-upgrades also features a way to disable upgrades on
specific packages that administrators would consider too sensitive to
restart automatically and will want to schedule during maintenance
windows.
Reboots were another issue discussed: how and when to deploy kernel
upgrades? Automating kernel upgrades may mean data loss if the reboot
happens during a critical operation. On Debian systems, the kernel
upgrade mechanisms already provide a /var/run/reboot-required flag
file that tools can monitor to notify users of the required reboot. For
example, some desktop environments will popup a warning prompting users
to reboot when the file exists. Debian doesn't currently
feature an equivalent warning for command-line operation: Vogt
suggested
that the warning could be shown along with the usual /etc/motd
announcement.
The ideal solution here, of course, is reboot-less kernel upgrades,
which is also known as "live patching" the kernel. Unfortunately, this
area is still in development in the kernel (as was previously discussed
here). Canonical deployed the
feature for the Ubuntu 16.04 LTS release, but Debian doesn't yet have
such capability, since it requires extra infrastructure among other
issues.
Furthermore, system reboots are only one part of the problem. Currently,
upgrading packages only replaces the code and restarts the primary
service shipped with a given package. On library upgrades, however,
dependent services may not necessarily notice and will keep running with
older, possibly vulnerable, libraries. While libc6, in Debian, has
special code to restart dependent services, other libraries like
libssl do not notify dependent services that they need to restart to
benefit from potentially critical security fixes.
One solution to this is the needrestart
package which inspects all
running processes and restarts services as necessary. It also covers
interpreted code, specifically Ruby, Python, and Perl. In my experience,
however, it can take up to a minute to inspect all processes, which
degrades the interactivity of the usually satisfying apt-get install
process. Nevertheless, it seems like needrestart is a key component of
a properly deployed automated upgrade system.
The ecosystem-wide security benefits of having Debian systems keep up to date with security updates by default overweigh any inconvenience of having to tweak system configuration on hosts where the automatic updates are problematic.One could compare automated upgrades with backups: if they are not automated, they do not exist and you will run into trouble without them. (Wirzenius, coincidentally, also works on the Obnam backup software.) Another benefit that may be less obvious is the acceleration of the feedback loop between developers and users: developers like to know quickly when an update creates a regression. Automation does create the risk of a bad update affecting more users, but this issue is already present, to a lesser extent, with manual updates. And the same solution applies: have a staging area for security upgrades, the same way updates to Debian stable are first proposed before shipping a point release. This doesn't have to be limited to stable security updates either: more adventurous users could follow rolling distributions like Debian testing or unstable with unattended upgrades as well, with all the risks and benefits that implies.
sources.list then:
# apt-get update && apt-get dist-upgrade
But the actual upgrade process is really much more complex. If you run
into problems with the above commands, you will quickly learn that you
should have followed the release
notes, a
whopping 20,000-word, ten-section document that outlines all the gory
details of the release. This is a real issue for large deployments and
for users unfamiliar with the command line.
The solutions most administrators seem to use right now is to roll their
own automated upgrade process. For example, the Debian.org system
administrators have their own
process for the
"jessie" (8.0) upgrade. I have also written a
specification of how major
upgrades could be automated that attempts to take into account the wide
variety of corner cases that occur during major upgrades, but it is
currently at the design stage. Therefore, this problem space is
generally unaddressed in Debian: Ubuntu does have a do-release-upgrade
command
but it is Ubuntu-specific and would need significant
changes
in order to work in Debian.
unattended-upgrades or
Landscape, a proprietary
system-management service from Canonical. According to Vogt, the company
supports both projects equally as they differ in scope:
unattended-upgrades just upgrades packages while Landscape aims at
maintaining thousands of machines and handles user management, release
upgrades, statistics, and aggregation.
It appears that Debian will enable unattended-upgrades on the images
built for the cloud by default. For regular installs, the consensus
that has
emerged
points at the Debian installer prompting users to ask if they want to
disable the feature as well. One reason why this was not enabled
before is that unattended-upgrades had serious bugs in the past that
made it less attractive. For example, it would simply fail to follow
security
updates, a
major bug that was fortunately promptly fixed by the maintainer.
In any case, it is important to distribute security and major upgrades
on Debian machines in a timely manner. In my long experience in
professionally administering Unix server farms, I have found the upgrade
work to be a critical but time-consuming part of my work. During that
time, I successfully deployed an automated upgrade system all the way
back to Debian woody, using the simpler
cron-apt. This approach is,
unfortunately, a little brittle and non-standard; it doesn't address the
need of automating major upgrades, for which I had to revert to tools
like cluster-ssh or more
specialized configuration management tools like
Puppet. I therefore encourage any effort towards
improving that process for the whole community.
More information about the configuration of unattended-upgrades can be
found in the Ubuntu
documentation
or the Debian wiki.
Note: this article first appeared in the Linux Weekly News.
startproject,
startapp, runserver)aip flag which,
according to GA documentation, makes "the IP address of the sender
'anonymized'". It is not quite clear how that is done at Google and,
given that it is a proprietary platform, there is no way to verify
that claim. The proposal says it means that "we can't see, and Google
Analytics doesn't store, your actual IP". But that is not actually
what Google does: GA stores IP addresses, the documentation just says
they are anonymized, without explaining how.
GA is presented as a trade-off, since "Google's track record indicates
that they don't value privacy nearly as high" as the DSF does. The
alternative, deploying its own analytics software, was presented as
making sustainability problems worse. According to the proposal, Google
"can't track Django users. [...] The only thing Google could do would be
to lie about anonymizing IP addresses, and attempt to match users based
on their IPs".
The truth is that we don't actually know what Google means when it
"anonymizes" data: Jannis Leidel, a Django team member, commented
that "Google has previously been subjected to secret US court orders
and was required to collaborate in mass surveillance conducted by US
intelligence services" that limit even Google's capacity of ensuring
its users' anonymity. Leidel also argued that the legal framework of
the US may not apply elsewhere in the world: "for example the strict
German (and by extension EU) privacy laws would exclude the automatic
opt-in as a lawful option".
Furthermore, the proposal claims that "if we discovered Google was
lying about this, we'd obviously stop using them immediately", but it
is unclear exactly how this could be implemented if the software was
already deployed. There are also concerns that an
implementation could block normal operation, especially in countries
(like China) where Google itself may be blocked. Finally, some
expressed concerns that the information could constitute a
security problem, since it would unduly expose the version number of
Django that is running.
Software in Debian should not communicate over the network except: in order to, and as necessary to, perform their function[...]; or for other purposes with explicit permission from the user.In other words, opt-in only, period. Jackson explained that "when we originally wrote the core of the policy documents, the DFSG [Debian Free Software Guidelines], the SC [Social Contract], and so on, no-one would have considered this behaviour acceptable", which explains why no explicit formal policy has been adopted yet in the Debian project. One of the concerns with opt-out systems (or even prompts that default to opt-in) was well explained back then by Debian developer Bas Wijnen:
It very much resembles having to click through a license for every package you install. One of the nice things about Debian is that the user doesn't need to worry about such things: Debian makes sure things are fine.One could argue that Debian has its own tracking systems. For example, by default, Debian will "phone home" through the APT update system (though it only reports the packages requested). However, this is currently not automated by default, although there are plans to do so soon. Furthermore, Debian members do not consider APT as tracking, because it needs to connect to the network to accomplish its primary function. Since there are multiple distributed mirrors (which the user gets to choose when installing), the risk of surveillance and tracking is also greatly reduced. A better parallel could be drawn with Debian's popcon system, which actually tracks Debian installations, including package lists. But as Barry Warsaw pointed out in that discussion, "popcon is 'opt-in' and [...] the overwhelming majority in Debian is in favour of it in contrast to 'opt-out'". It should be noted that popcon, while opt-in,
I don't believe the increase we might get in the number of reports by making it harder to opt-out, can be worth the ill-will generated for people who might feel the reporting was "sneaked" upon them, or even those who feel they were nagged into participation rather than choosing to participate.Other options may also include gathering metrics in
pip or PyPI,
which was proposed by Donald Stufft. Leidel also proposed
that the system could ask to opt-in only after a few times the
commands are called.
It is encouraging to see that a community can discuss such issues
without heating up too much and shows great maturity for the Django
project. Every free-software project may be confronted with funding and
sustainability issues. Django seems to be trying to address this in a
transparent way. The project is willing to engage with the whole
spectrum of the community, from the top leaders to downstream
distributors, including individual developers. This practice should
serve as a model, if not of how to do funding or tracking, at least of
how to discuss those issues productively.
Everyone seems to agree the point is not to surveil users, but improve
the software. As Lars Wirzenius, a Debian developer,
commented: "it's a very sad situation if free
software projects have to compromise on privacy to get
funded". Hopefully, Django will be able to improve its funding without
compromising its principles.
Note: this article first appeared in the Linux Weekly News.
Another update, now at release 0.1.2, of anytime arrived at CRAN earlier today.
anytime is a very focused package aiming to do just one thing really well: to convert anything in integer, numeric, character, factor, ordered, ... format to either POSIXct or Date objects -- and to do so without requiring a format string.
See the anytime page, or the GitHub README.md for a few examples, or just consider the following illustration:
R> library(anytime)
R> anytime("20161107 202122") ## all digits
[1] "2016-11-07 20:21:22 CST"
R> utctime("2016Nov07 202122") ## UTC parse example
[1] "2016-11-07 14:21:22 CST"
R> %Y-%b-%d form, ie 2016-Dec-12 for today would fail on Windows as the contiguous string was apparently getting split by a routine looking for splits on spaces. Really strange.
Anyway, I switched to using more helper functions from the Boost String Algorithms library, and things are behaving now. An extra shoutout once more to G bor Cs rdi and the R Consortium for the most awesome R-Builder. I was able to test and fix on Windows during the weekend with no access to an actual windows environment.
The NEWS file summarises the release:
Courtesy of CRANberries, there is a comparison to the previous release. More information is on the anytime page. For questions or comments use the issue tracker off the GitHub repo.Changes in anytime version 0.1.2 (2016-12-13)
- The (internal) string processing and splitting now uses Boost algorithm functions which avoids a (bizarre) bug on Windows.
- Test coverage was increased.
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
(image courtesy of XKCD)
Last week I graduated with a Masters in Legal Science (now taught as an MLaw) from Queen s University Belfast. I m pleased to have achieved a Distinction, as well an award for Outstanding Achievement in the Dissertation (which was on the infringement of privacy by private organisations due to state mandated surveillance and retention laws - pretty topical given the unfortunate introduction of the Investigatory Powers Act 2016). However, as previously stated, I had made the decision that I was happier building things, and wanted to return to the world of technology. I talked to a bunch of interesting options, got to various stages in the hiring process with each of them, and happily accepted a role with Titan IC Systems which started at the beginning of September.
Titan have produced a hardware accelerated regular expression processor (hence the XKCD reference); the RXP in its FPGA variant (what I get to play with) can handle pattern matching against 40Gb/s of traffic. Which is kinda interesting, as it lends itself to a whole range of applications from network scanning to data mining to, well, anything where you want to sift through a large amount of data checking against a large number of rules. However it s brand new technology for me to get up to speed with (plus getting back into a regular working pattern rather than academentia), and the combination of that and spending most of the summer post DebConf wrapping up the dissertation has meant I haven t had as much time to devote other things as I d have liked. However I ve a few side projects at various stages of completion and will try to manage more regular updates.
Next.