After the success of our previous IRC meeting, we are having our second IRC meeting today. Monday 26th October, at 18:00 UTC:
#reproducible-builds channel on irc.oftc.net an agenda is available. As mentioned in our previous meeting announcement, due to the unprecedented events in 2020, there will be no in-person Reproducible Builds event this year, but we plan to run these IRC meetings every fortnight.
This article documents how to install FORT Validator (an RPKI relying party software which also implements the RPKI to Router protocol in a single daemon) on Debian 10 to provide RPKI validation to routers. If you are using testing or unstable then you can just skip the part about apt pinnings.
The packages in bullseye (Debian testing) can be installed as is on Debian stable with no need to rebuild them, by configuring an appropriate pinning for apt:
cat <<END > /etc/apt/sources.list.d/bullseye.list deb http://deb.debian.org/debian/ bullseye main END cat <<END > /etc/apt/preferences.d/pin-rpki # by default do not install anything from bullseye Package: * Pin: release bullseye Pin-Priority: 100 Package: fort-validator rpki-trust-anchors Pin: release bullseye Pin-Priority: 990 END apt updateBefore starting, make sure that curl (or wget) and the web PKI certificates are installed:
apt install curl ca-certificatesIf you already know about the legal issues related to the ARIN TAL then you may instruct the package to automatically install it. If you skip this step then you will be asked at installation time about it, either way is fine.
echo 'rpki-trust-anchors rpki-trust-anchors/get_arin_tal boolean true' \
debconf-set-selections
Install the package as usual:
apt install fort-validatorYou may also install rpki-client and gortr on Debian 10, or maybe cfrpki and gortr. I have also tried packaging Routinator 3000 for Debian, but this effort is currently on hold because the Rust ecosystem is broken and hostile to the good packaging practices of Linux distributions.
This article documents how to install rpki-client (an RPKI relying party software, the actual validator) and gortr (which implements the RPKI to Router protocol) on Debian 10 to provide RPKI validation to routers. If you are using testing or unstable then you can just skip the part about apt pinnings.
The packages in bullseye (Debian testing) can be installed as is on Debian stable with no need to rebuild them, by configuring an appropriate pinning for apt:
cat <<END > /etc/apt/sources.list.d/bullseye.list deb http://deb.debian.org/debian/ bullseye main END cat <<END > /etc/apt/preferences.d/pin-rpki # by default do not install anything from bullseye Package: * Pin: release bullseye Pin-Priority: 100 Package: gortr rpki-client rpki-trust-anchors Pin: release bullseye Pin-Priority: 990 END apt updateBefore starting, make sure that curl (or wget) and the web PKI certificates are installed:
apt install curl ca-certificatesIf you already know about the legal issues related to the ARIN TAL then you may instruct the package to automatically install it. If you skip this step then you will be asked at installation time about it, either way is fine.
echo 'rpki-trust-anchors rpki-trust-anchors/get_arin_tal boolean true' \
debconf-set-selections
Install the packages as usual:
apt install rpki-client gortrAnd then configure rpki-client to generate its output in the the JSON format needed by gortr:
echo 'OPTIONS=-j' > /etc/default/rpki-clientYou may manually start the service unit to immediately generate the data instead of waiting for the next timer run:
systemctl start rpki-client &gortr too needs to be configured to use the JSON data generated by rpki-client:
echo 'GORTR_ARGS=-bind :323 -verify=false -checktime=false -cache /var/lib/rpki-client/json' > /etc/default/gortrAnd then it needs to be restarted to use the new configuration:
systemctl restart gortrYou may also install FORT Validator on Debian 10, or maybe cfrpki with gortr. I have also tried packaging Routinator 3000 for Debian, but this effort is currently on hold because the Rust ecosystem is broken and hostile to the packaging practices of Linux distributions.
Exactly one week after the previous release 0.6.26 of digest, a minor cleanup release 0.6.27 just arrived on CRAN and will go to Debian shortly.
digest creates hash digests of arbitrary R objects (using the md5, sha-1, sha-256, sha-512, crc32, xxhash32, xxhash64, murmur32, spookyhash, and blake3 algorithms) permitting easy comparison of R language objects. It is a fairly widely-used package (currently listed at one million monthly downloads, 282 direct reverse dependencies and 8068 indirect reverse dependencies, or just under half of CRAN) as many tasks may involve caching of objects for which it provides convenient general-purpose hash key generation.
Release 0.6.26 brought support for the (nice, even cryptographic) blake3 hash algorithm. In the interest of broader buildability we had already (with a sad face) disabled a few very hardware-specific implementation aspects using intrinsic ops. But to our chagrin, we left one #error define that raised its head on everybody s favourite CRAN build platform. Darn. So 0.6.27 cleans that up and also removes the check and #error as all the actual code was already commented out. If you read this and tears start running down your cheeks, then by all means come and help us bring blake3 to its full (hardware-accelerated) potential. This (probably) only needs a little bit of patient work with the build options and configurations. You know where to find us
My CRANberries provides the usual summary of changes to the previous version.
For questions or comments use the issue tracker off the GitHub repo.
If you like this or other open-source work I do, you can now sponsor me at GitHub. For the first year, GitHub will match your contributions.
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
[user]
name = Sandro Tosi
email = <personal.address>@gmail.com
[includeIf "gitdir:~/deb/"]
path = ~/.gitconfig-deb
Every time the git path is in ~/deb/ (which is where i have all Debian repos) the file ~/.gitconfig-deb will be included; its content:[user]That results in my personal address being used on all repos not part of Debian, where i use my Debian email address. This approach can be extended to every other git configuration values.
email = morph@debian.org
A good month after the initial two releases, we are thrilled to announce relase 0.0.3 of RcppSpdlog. This brings us release 1.8.1 of spdlog as well as a few local changes (more below).
RcppSpdlog bundles spdlog, a wonderful header-only C++ logging library with all the bells and whistles you would want that was written by Gabi Melman, and also includes fmt by Victor Zverovic.
This version of RcppSpdlog brings a new top-level function setLogLevel to control what events get logged, updates the main example to show this and to also make the R-aware logger the default logger, and adds both an extended vignette showing several key features and a new (external) package documentation site.
The NEWS entry for this release follows.
Courtesy of my CRANberries, there is also a diffstat report. More detailed information is on the RcppSpdlog page. If you like this or other open-source work I do, you can now sponsor me at GitHub. For the first year, GitHub will match your contributions.Changes in RcppSpdlog version 0.0.3 (2020-10-23)
- New function
setLogLevelwith R accessor inexampleRsinkexample- Updated
exampleRsinkto use default logger instance- Upgraded to upstream release 1.8.1 which contains finalised upstream use to switch to REprintf() if R compilation detected
- Added new vignette with extensive usage examples, added compile-time logging switch example
- A package documentation website was added
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
hcloud-cli, currently only in testing and unstable:
apt install hcloud-cli
hcloud with the API key:
hcloud context create
#!/bin/sh # Create the server hcloud server create --name buildqt --ssh-key --start-after-create \ --type cpx51 --image debian-10 --datacenter # Query server IP IP="$(hcloud server describe buildqt -o json jq -r .public_net.ipv4.ip)" # Update ansible host file echo "buildqt ansible_user=root ansible_host=$IP" > hosts # Remove old host key ssh-keygen -f ~/.ssh/known_hosts -R "$IP" # Update login script echo "#!/bin/sh" > login echo "ssh root@$IP" >> login chmod 0755 login
.netrc credentials to ansible before provisioning:
#!/usr/bin/python3 import subprocess import netrc import tempfile import json login, account, password = netrc.netrc().authenticators(" ") with tempfile.NamedTemporaryFile(mode="wt", suffix=".json") as fd: json.dump( "repo_user": login, "repo_password": password, , fd) fd.flush() subprocess.run([ "ansible-playbook", "-i", "hosts", "-l", "buildqt", "--extra-vars", f"@ fd.name ", "provision.yml", ], check=True)
#!/usr/bin/env ansible-playbook - name: Install and configure buildqt hosts: all tasks: - name: Update apt cache apt: update_cache: yes cache_valid_time: 86400 - name: Create build user user: name: build comment: QT5 Build User shell: /bin/bash - name: Create sources directory become: yes become_user: build file: path: ~/sources state: directory mode: 0755 - name: Download sources become: yes become_user: build get_url: url: "https:// / item " dest: "~/sources/ item " mode: 0644 with_items: - "qt-everywhere-src-5.15.1.tar.xz" - "qt-creator-enterprise-src-4.13.2.tar.gz" - name: Populate home directory become: yes become_user: build copy: src: build dest: ~/ mode: preserve - name: Write .netrc become: yes become_user: build copy: dest: ~/.netrc mode: 0600 content: machine login repo_user password repo_password - name: Write .screenrc become: yes become_user: build copy: dest: ~/.screenrc mode: 0644 content: hardstatus alwayslastline hardstatus string '% = cw %-Lw% = KW %50>%n%f* %t% = cw %+Lw%< % = kK %-=%D %Y-%m-%d %c% - ' startup_message off defutf8 on defscrollback 10240 - name: Install base packages apt: name: git,mc,ncdu,neovim,eatmydata,devscripts,equivs,screen state: present - name: Clone git repo become: yes become_user: build git: repo: https:// @ / .git dest: ~/ - name: Copy Qt license become: yes become_user: build copy: src: qt-license.txt dest: ~/.qt-license mode: 0600
#!/bin/sh
hcloud server delete buildqt
amd64, in under 1
hour and 40 minutes.
n1-standard-1 instance,
providing a fresh set of one vCPU and 3.75GB of RAM for each and every build.
GCE supports several new instance types, featuring better and faster CPUs, including current AMD EPICs.
However, as it turns out, GCE does not support any single vCPU instances for any of those types.
So jobs in the future will use n2d-standard-2 for the time being,
provinding two vCPUs and 8GB of RAM..
Builds run with IPv6 enabled
All builds run with IPv6 enabled in the Docker environment.
This means the lo network device got the IPv6 loopback address ::1 assigned.
So tests that need minimal IPv6 support can succeed.
It however does not include any external IPv6 connectivity.
fit-arb fit:
QSoas> l michaelis.dat QSoas> fit-arb vm/(1+km/x)After running the fit, the window should look like this: Now, with the fit, we have reasonable values for \(v_m\) (
vm) and \(K_m\) (km). But, for publication, one would want to generate "smooth" curve going through the lines... Saving the curve from "Data.../Save all" doesn't help, since the data has as many points as the original data and looks very "jaggy" (like on the screenshot above)... So one needs a curve with more data points.
Maybe the most natural solution is simply to use generate-buffer together with apply-formula using the formula and the values of km and vm obtained from the fit, like:
QSoas> generate-buffer 0 20 QSoas> apply-formula y=3.51742/(1+3.69767/x)By default,
generate-buffer generate 1000 evenly spaced x values, but you can change their number using the /samples option. The two above commands can be combined to just one call to generate-buffer:
QSoas> generate-buffer 0 20 3.51742/(1+3.69767/x)This works, but it is quite cumbersome and it is not going to work well for complex formulas or the results of differential equations or kinetic systems... This is why to each
fit- command corresponds a sim- command that computes the result of the fit using a "saved parameters" file (here, michaelis.params, but you can also save it yourself) and buffers as "models" for X values:
QSoas> generate-buffer 0 20 QSoas> sim-arb vm/(1+km/x) michaelis.params 0This strategy works with every single fit ! As an added benefit, you even get the fit parameters as meta-data, which are displayed by the
show command:
QSoas> show 0 Dataset generated_fit_arb.dat: 2 cols, 1000 rows, 1 segments, #0 Flags: Meta-data: commands = sim-arb vm/(1+km/x) michaelis.params 0 fit = arb (formula: vm/(1+km/x)) km = 3.69767 vm = 3.5174They also get saved as comments if you save the data. Important note: the
sim-arb command will be available only in the 3.0 release, although you can already enjoy it if you use the github version.
About QSoasQSoas is a powerful open source data analysis program that focuses on flexibility and powerful fitting capacities. It is released under the GNU General Public License. It is described in Fourmond, Anal. Chem., 2016, 88 (10), pp 5050 5052. Current version is 2.2. You can download its source code and compile it yourself or buy precompiled versions for MacOS and Windows there.
A new release, now at version 0.1.6, of RcppZiggurat is now on the CRAN network for R.
The RcppZiggurat package updates the code for the Ziggurat generator by Marsaglia and other which provides very fast draws from a Normal distribution. The package provides a simple C++ wrapper class for the generator improving on the very basic macros, and permits comparison among several existing Ziggurat implementations. This can be seen in the figure where Ziggurat from this package dominates accessing the implementations from the GSL, QuantLib and Gretl all of which are still way faster than the default Normal generator in R (which is of course of higher code complexity).
This release brings a corrected seed setter and getter which now correctly take care of all four state variables, and not just one. It also corrects a few typos in the vignette. Both were fixed quite a while back, but we somehow managed to not ship this to CRAN for two years.
The NEWS file entry below lists all changes.
Courtesy of my CRANberries, there is a diffstat report for this release. More information is on the RcppZiggurat page. If you like this or other open-source work I do, you can now sponsor me at GitHub. For the first year, GitHub will match your contributions.Changes in version 0.1.6 (2020-10-18)
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
The Debian project is happy to announce a donation of 10,000 to help
Framasoft reach the fourth stretch-goal of its
Peertube v3 crowdfunding campaign -- Live Streaming.
This year's iteration of the Debian annual conference,
DebConf20, had to be held online,
and while being a resounding success, it made clear to the project our need
to have a permanent live streaming infrastructure for small events held by local Debian groups.
As such, Peertube, a FLOSS video hosting platform,
seems to be the perfect solution for us.
We hope this unconventional gesture from the Debian project will help us make
this year somewhat less terrible and give us, and thus humanity, better Free Software tooling
to approach the future.
Debian thanks the commitment of numerous Debian donors and DebConf sponsors,
particularly all those that contributed to DebConf20 online's success
(volunteers, speakers and sponsors).
Our project also thanks Framasoft and the PeerTube community for developing
PeerTube as a free and decentralized video platform.
The Framasoft association warmly thanks the Debian Project for
its contribution, from its own funds, towards making PeerTube happen.
This contribution has a twofold impact. Firstly, it's a strong sign of
recognition from an international project - one of the pillars of the Free
Software world - towards a small French association which offers tools to
liberate users from the clutches of the web's giant monopolies.
Secondly, it's a substantial amount of help in these difficult times,
supporting the development of a tool which equally belongs to and is useful to everyone.
The strength of Debian's gesture proves, once again, that
solidarity, mutual aid and collaboration are values which allow our communities
to create tools to help us strive towards Utopia.
The Reproducible Builds project depends on our many projects, supporters
and sponsors. We rely on their financial
support, but they are also valued ambassadors who spread the word about the
Reproducible Builds project and the work that we do.
This is the first installment in a series featuring the projects, companies and
individuals who support the Reproducible Builds project. If you are a supporter
of the Reproducible Builds project (of whatever size) and would like to be
featured here, please let get in touch with us at
contact@reproducible-builds.org.
However, we are kicking off this series by featuring Urs Gleim and Yoshi
Kobayashi of the Civil Infrastructure Platform
(CIP) project.
A: The CIP Project formed in 2016 as a project hosted by Linux Foundation. It
was launched out of necessity to establish an open source framework and
the subsequent software foundation delivers services for civil infrastructure
and economic development on a global scale. Some key milestones we have
achieved as a project include our collaboration with
Debian, where we are helping with the Debian Long Term
Support (LTS) initiative, which aims to extend
the lifetime of all Debian stable releases to at least 5 years. This is
critical because most control systems for transportation, power plants,
healthcare and telecommunications run on Debian-based embedded systems.
In addition, CIP is focused on IEC 62443,
a standards-based approach to counter security vulnerabilities in industrial
automation and control systems. Our belief is that this work will help mitigate
the risk of cyber attacks, but in order to deal with evolving attacks of this
kind, all of the layers that make up these complex systems (such as system
services and component functions, in addition to the countless operational
layers) must be kept secure. For this reason, the IEC 62443 series is
attracting attention as the de facto cyber-security standard.
Chris: If someone wanted to know more about the Civil Infrastructure Platform
(or even to get involved) where should they go to look?
A: We have many avenues to participate and learn more! We have a
website, a wiki
and you can even follow us on Twitter.
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) 786 other packages on CRAN.
A little while ago, Conrad released version 10.1.0 of Armadillo, a a new major release. As before, given his initial heads-up we ran two full reverse-depends checks, and as a consequence contacted four packages authors (two by email, two via PR) about a miniscule required change (as Armadillo now defaults to C++11, an old existing setting of avoiding C++11 lead to an error). Our thanks to those who promptly update their packages truly appreciated. As it turns out, Conrad also softened the error by the time the release ran around.
But despite our best efforts, the release was delayed considerably by CRAN. We had made several Windows test builds but luck had it that on the uploaded package CRAN got itself a (completely spurious segfault which can happen on a busy machine building machine things at once). Sadly it took three or four days for CRAN to reply our email. After which it took another number of days for them to ponder the behaviour of a few new deprecated messaged tickled by at the most ten or so (out of 786) packages. Oh well. So here we are, eleven days after I emailed the rcpp-devel list about the new package being on CRAN but possibly delayed (due to that seg.fault). But during all that time the package was of course available via the Rcpp drat.
The changes in this release are summarized below as usual and are mostly upstream along with an improved Travis CI setup due to the aforementioned use of the bspm package for binaries at Travis.
Courtesy of my CRANberries, there is a diffstat report relative to previous release. More detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page. If you like this or other open-source work I do, you can now sponsor me at GitHub. For the first year, GitHub will match your contributions.Changes in RcppArmadillo version 0.10.1.0.0 (2020-10-09)
- Upgraded to Armadillo release 10.1.0 (Orchid Ambush)
- C++11 is now the minimum required C++ standard
- faster handling of compound expressions by
trimatu()andtrimatl()- faster sparse matrix addition, subtraction and element-wise multiplication
- expanded sparse submatrix views to handle the non-contiguous form of
X.cols(vector_of_column_indices)- expanded
eigs_sym()andeigs_gen()with optional fine-grained parameters (subspace dimension, number of iterations, eigenvalues closest to specified value)- deprecated form of
reshape()removed from Cube and SpMat classes- ignore and warn on use of the
ARMA_DONT_USE_CXX11macro- Switch Travis CI testing to focal and BSPM
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
I am happy to report that we finally made it! Norwegian Bokm l
became the first translation published on paper of the new Buster
based edition of "The Debian
Administrator's Handbook". The print proof reading copy arrived
some days ago, and it looked good, so now the book is approved for
general distribution. This updated paperback edition is available from
lulu.com. The book is also available for download in electronic
form as PDF, EPUB and Mobipocket, and can also be
read online.
I am very happy to wrap up this Creative Common licensed project,
which concludes several months of work by several volunteers. The
number of Linux related books published in Norwegian are few, and I
really hope this one will gain many readers, as it is packed with deep
knowledge on Linux and the Debian ecosystem. The book will be
available for various Internet book stores like Amazon and Barnes &
Noble soon, but I recommend buying
"H ndbok
for Debian-administratoren" directly from the source at Lulu.
As usual, if you use Bitcoin and want to show your support of my
activities, please send Bitcoin donations to my address
15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.
For the past few years I've had a bunch of virtual machines hosting websites, services, and servers. Of course I want them to be available - especially since I charge people money to access at some of them (for example my dns-hosting service) - and that means I want to know when they're not.
The way I've gone about this is to have a bunch of machines running stuff, and then dedicate an entirely separate machine solely for monitoring and alerting. Sure you can run local monitoring, testing that services are available, the root-disk isn't full, and that kind of thing. But only by testing externally can you see if the machine is actually available to end-users, customers, or friends.
A local-agent might decide "I'm fine", but if the hosting-company goes dark due to a fibre cut you're screwed.I've been hosting my services with Hetzner (cloud) recently, and their service is generally pretty good. Unfortunately I've started to see an increasing number of false-alarms. I'd have a server in Germany, with the monitoring machine in Helsinki (coincidentally where I live!). For the past month I've started to get pinged with a failure every three/four days on average, "service down - dns failed", or "service down - timeout". When the notice would wake me up I'd go check and it would be fine, it was a very transient failure. To be honest the reason for this is my monitoring is just too damn aggressive, I like to be alerted immediately in case something is wrong. That means if a single test fails I get an alert, as rather than only if a test failed for something more reasonable like three+ consecutive failures. I'm experimenting with monitoring in a less aggressive fashion, from my home desktop. Since my monitoring tool is a single self-contained golang binary, and it is already packaged as a docker-based container deployment was trivial. I did a little work writing an agent to receive failure-notices, and ping me via telegram - instead of the previous approach where I had an online status-page which I could view via my mobile, and alerts via pushover. So far it looks good. I've tweaked the monitoring to setup a timeout of 15 seconds, instead of 5, and I've configured it to only alert me if there is an outage which lasts for >= 2 consecutive failures. I guess the TLDR is I now do offsite monitoring .. from my house, rather than from a different region. The only real reason to write this post was mostly to say that the process of writing a trivial "notify me" gateway to interface with telegram was nice and straightforward, and to remind myself that transient failures are way more common than we expect. I'll leave things alone for a moment, but it was a fun experiment. I'll keep the two systems in parallel for a while, but I guess I can already predict the outcome:
apt install libpam-google-authenticator
Then you need to add the module in your PAM stack somewhere. Since I
only use it for SSH, I added this line on top of /etc/pam.d/sshd:
auth required pam_google_authenticator.so nullok
I also used no_increment_hotp debug while debugging to avoid having
to renew the token all the time and have more information about
failures in the logs.
Then reload ssh (not sure that's actually necessary):
service ssh reload
google-authenticator -c
This will prompt you for a bunch of questions. To get them all right,
I prefer to just call the right ones on the commandline directly:
google-authenticator --counter-based --qr-mode=NONE --rate-limit=1 --rate-time=30 --emergency-codes=1 --window-size=3
Those are actually the defaults, if my memory serves me right, except
for the --qr-mode and --emergency-codes (which can't be disabled
so I only print one). I disable the QR code display because I won't be
using the codes on my phone, but you would obviously keep it if you
want to use the app.
google-authenticator command is not compatible with the token
expected by the ykpersonalize command used to configure the Yubikey
(base16 AKA "hexadecimal", with a fixed 20 bytes length). So you
need a way to convert between the two. I wrote a program called
oath-convert which basically does this:
read base32
add padding
convert to hex
print
Or, in Python:
def convert_b32_b16(data_b32):
remainder = len(data_b32) % 8
if remainder > 0:
# XXX: assume 6 chars are missing, the actual padding may vary:
# https://tools.ietf.org/html/rfc3548#section-5
data_b32 += "======"
data_b16 = base64.b32decode(data_b32)
if len(data_b16) < 20:
# pad to 20 bytes
data_b16 += b"\x00" * (20 - len(data_b16))
return binascii.hexlify(data_b16).decode("ascii")
head -1 .google_authenticator oath-convert
Then you paste the output in the prompt:
$ ykpersonalize -1 -o oath-hotp -o append-cr -a
Firmware version 3.4.3 Touch level 1541 Program sequence 2
HMAC key, 20 bytes (40 characters hex) : [SECRET GOES HERE]
Configuration data to be written to key configuration 1:
fixed: m:
uid: n/a
key: h:[SECRET REDACTED]
acc_code: h:000000000000
OATH IMF: h:0
ticket_flags: APPEND_CR OATH_HOTP
config_flags:
extended_flags:
Commit? (y/n) [n]: y
Note that you must NOT pass the -o oath-hotp8 parameter to the
ykpersonalize commandline, which we used to do in the Yubikey
howto. That is because Google Authenticator
tokens are shorter: it's less secure, but it's an acceptable tradeoff
considering the plugin is actually maintained. There's actually a
feature request to support 8-digit codes so that limitation might
eventually be fixed as well.
Thanks to the Google Authenticator people and Yubikey people
for their support in establishing this procedure.
| 2560*1440 works well | 3840*2160 goes slow | |
|---|---|---|
| System | Dell PowerEdge T320 | White Box PC from rubbish |
| CPU | 2.4GHz E5-2440 | 3.3GHz i5-2500 |
| Video Card | ATI Radeon HD 6570 | ATI Radeon R7 260X |
| PCIe Speed | PCIe 2.1 8GB/s | PCIe 3.0 downgraded to PCIe 2.1 8GB/s |
Although I still read a lot, during my college sophomore years my reading
habits shifted from novels to more academic works. Indeed, reading dry
textbooks and economic papers for classes often kept me from reading anything
else substantial. Nowadays, I tend to binge read novels: I won't touch a book
for months on end, and suddenly, I'll read 10 novels back to back1.
At the start of a novel binge, I always follow the same ritual: I take out my
e-reader from its storage box, marvel at the fact the battery is still pretty
full, turn on the WiFi and check if there are OS updates. And I have to admit,
Kobo Inc. (now Rakuten Kobo) has done a stellar job of keeping my e-reader up
to date. I've owned this model (a Kobo Aura 1st generation) for 7
years now and I'm still running the latest version of Kobo's Linux-based OS.
Having recently had trouble updating my Nexus 5 (also manufactured 7 years ago)
to Android 102, I asked myself:
Why is my e-reader still getting regular OS updates, while Google stopped issuing security patches for my smartphone four years ago?To try to answer this, let us turn to economic incentives theory. Although not the be-all and end-all some think it is3, incentives theory is not a bad tool to analyse this particular problem. Executives at Google most likely followed a very business-centric logic when they decided to drop support for the Nexus 5. Likewise, Rakuten Kobo's decision to continue updating older devices certainly had very little to do with ethics or loyalty to their user base. So, what are the incentives that keep Kobo updating devices and why are they different than smartphone manufacturers'? A portrait of the current long-term software support offerings for smartphones and e-readers Before delving deeper in economic theory, let's talk data. I'll be focusing on 2 brands of e-readers, Amazon's Kindle and Rakuten's Kobo. Although the e-reader market is highly segmented and differs a lot based on geography, Amazon was in 2015 the clear worldwide leader with 53% of the worldwide e-reader sales, followed by Rakuten Kobo at 13%4. On the smartphone side, I'll be differentiating between Apple's iPhones and Android devices, taking Google as the barometer for that ecosystem. As mentioned below, Google is sadly the leader in long-term Android software support. Rakuten Kobo According to their website and to this Wikipedia table, the only e-readers Kobo has deprecated are the original Kobo eReader and the Kobo WiFi N289, both released in 2010. This makes their oldest still supported device the Kobo Touch, released in 2011. In my book, that's a pretty good track record. Long-term software support does not seem to be advertised or to be a clear selling point in their marketing. Amazon According to their website, Amazon has dropped support for all 8 devices produced before the Kindle Paperwhite 2nd generation, first sold in 2013. To put things in perspective, the first Kindle came out in 2007, 3 years before Kobo started selling devices. Like Rakuten Kobo, Amazon does not make promises of long-term software support as part of their marketing. Apple Apple has a very clear software support policy for all their devices:
Owners of iPhone, iPad, iPod or Mac products may obtain a service and parts from Apple or Apple service providers for five years after the product is no longer sold or longer, where required by law.This means in the worst-case scenario of buying an iPhone model just as it is discontinued, one would get a minimum of 5 years of software support. Android Google's policy for their Android devices is to provide software support for 3 years after the launch date. If you buy a Pixel device just before the new one launches, you could theoretically only get 2 years of support. In 2018, Google decided OEMs would have to provide security updates for at least 2 years after launch, threatening not to license Google Apps and the Play Store if they didn't comply. A question of cost structure From the previous section, we can conclude that in general, e-readers seem to be supported longer than smartphones, and that Apple does a better job than Android OEMs, providing support for about twice as long. Even Fairphone, who's entire business is to build phones designed to last and to be repaired was not able to keep the Fairphone 1 (2013) updated for more than a couple years and seems to be struggling to keep the Fairphone 2 (2015) running an up to date version of Android. Anyone who has ever worked in IT will tell you: maintaining software over time is hard work and hard work by specialised workers is expensive. Most commercial electronic devices are sold and developed by for-profit enterprises and software support all comes down to a question of cost structure. If companies like Google or Fairphone are to be expected to provide long-term support for the devices they manufacture, they have to be able to fund their work somehow. In a perfect world, people would be paying for the cost of said long-term support, as it would likely be cheaper then buying new devices every few years and would certainly be better for the planet. Problem is, manufacturers aren't making them pay for it. Economists call this type of problem externalities: things that should be part of the cost of a good, but aren't for one a reason or another. A classic example of an externality is pollution. Clearly pollution is bad and leads to horrendous consequences, like climate change. Sane people agree we should drastically cut our greenhouse gas emissions, and yet, we aren't. Neo-classical economic theory argues the way to fix externalities like pollution is to internalise these costs, in other words, to make people pay for the "real price" of the goods they buy. In the case of climate change and pollution, neo-classical economic theory is plain wrong (spoiler alert: it often is), but this is where band-aids like the carbon tax comes from. Still, coming back to long-term software support, let's see what would happen if we were to try to internalise software maintenance costs. We can do this multiple ways. 1 - Include the price of software maintenance in the cost of the device This is the choice Fairphone makes. This might somewhat work out for them since they are a very small company, but it cannot scale for the following reasons:
.shenv (sourced by .bashrc):
export CDPATH=".:~:~/src:~/dist:~/wikis:~/go/src:~/src/tor"
This allows me to quickly jump into projects from my home dir, or the
"source code" (~/src), "work" (src/tor), or wiki checkouts
(~/wikis) directories. It works well from the shell, but
unfortunately it's very static: if I want a new directory, I need to
edit my config file, restart shells, etc. It also doesn't work from my
text editor.
cd.
Some of those may or may not have integration in Emacs.
find by default, so no notion of
frequency.Next.