Agreguesi i feed

I was assigned 15 hours of work by Freexian's Debian LTS initiative and carried over 8 hours from July. I worked only 5 hours and therefore carried over 18 hours to September.

I prepared and uploaded updates to the linux-4.9 (DLA 1466-1, DLA 1481-1) and linux-latest-4.9 packages.

Ben Hutchings https://www.decadent.org.uk/ben/blog Better living through software

It is now more than a year that I took over tlcontrib from Taco and provide it at the TeX Live contrib repository. It does now serve old TeX Live 2017 as well as the current TeX Live 2018, and since last year the number of packages has increased from 52 to 70.

Recent changes include pTeX support packages for non-free fonts and more packages from the AcroTeX bundle. In particular since the last post the following packages have been added: aeb-mobile, aeb-tilebg, aebenvelope, cjk-gs-integrate-macos, comicsans, datepicker-pro, digicap-pro, dps, eq-save, fetchbibpes, japanese-otf-nonfree, japanese-otf-uptex-nonfree, mkstmpdad, opacity-pro, ptex-fontmaps-macos, qrcstamps.

Here I want to thank Jürgen Gilg for reminding me consistently of updates I have missed, big thanks!

To recall what TLcontrib is for: It collects packages that not distributed inside TeX Live proper for one or another of the following reasons:

• because it is not free software according to the FSF guidelines;
• because it is an executable update;
• because it is not available on CTAN;
• because it is an intermediate release for testing.

In short, anything related to TeX that can not be on TeX Live but can still legally be distributed over the Internet can have a place on TLContrib. The full list of packages can be seen here.

Please see the main page for Quickstart, History, and details about how to contribute packages.

Last but not least, while this is a service to make access to non-free packages more easy for users of the TeX Live Manager, our aim is to have as many as possible packages made completely free and included into TeX Live proper!

Enjoy.

Norbert Preining https://www.preining.info/blog There and back again

This is the eleventh issue of The Lubuntu Development Newsletter. You can read the last issue here. Changes General This list is a bit short because we have been focusing on general, behind-the-scenes (and admittedly tedious) administration tasks, but we plan on ramping up development progress in time for the next newsletter. Desktop Experience We […]

digest version 0.6.17 arrived on CRAN earlier today after a day of gestation in the bowels of CRAN, and should get uploaded to Debian in due course.

digest creates hash digests of arbitrary R objects (using the md5, sha-1, sha-256, sha-512, crc32, xxhash32, xxhash64 and murmur32 algorithms) permitting easy comparison of R language objects.

This release brings another robustifications thanks to Radford Neal who noticed a segfault in 32 bit mode on Sparc running Solaris. Yay for esoteric setups. But thanks to his very nice pull request, this is taken care of, and it also squashed one UBSAN error under the standard gcc setup. But two files remain with UBSAN issues, help would be welcome!

CRANberries provides the usual summary of changes to the previous version.

For questions or comments use the issue tracker off the GitHub repo.

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

Dirk Eddelbuettel http://dirk.eddelbuettel.com/blog Thinking inside the box

Imagine my disappointment when I discovered that signs on Stanford’s campus pointing to their “Enchanted Broccoli Forest” and “Narnia”—both of which that I have been passing daily on my new commute—merely indicate the location of student living groups with whimsical names.

Benjamin Mako Hill https://mako.cc/copyrighteous copyrighteous

This week I had to deal with a setup in which I needed to distribute additional static network routes using DHCP.

The setup is easy but there are some caveats to take into account. Also, DHCP clients might not behave as one would expect.

The starting situation was a working DHCP clinet/server deployment. Some standard virtual machines would request for their network setup over the network. Nothing new. The DHCP server is dnsmasq, and the daemon is running under Openstack control, but this has nothing to do with the DHCP problem itself.

By default, it seems dnsmasq sends to clients the Routers (code 3) option, which usually contains the gateway for clients in the subnet to use. My situation required to distribute one additional static route for another subnet. My idea was for DHCP clients to end with this simple routing table:

user@dhcpclient:~$ ip r default via 10.0.0.1 dev eth0 10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.100 172.16.0.0/21 via 10.0.0.253 dev eth0 <--- extra static route

To distribute this extra static route, you only need to edit the dnsmasq config file and add a line like this:

dhcp-option=option:classless-static-route,172.16.0.0/21,10.0.0.253

For my initial tests of this config I was simply doing requesting to refresh the lease from the client DHCP. This got my new static route online, but if in the case of a reboot, the client DHCP would not get the default route. The different behaviour is documented in dhclient-script(8).

To try something similar to a reboot situation, I had to use this command:

user@dhcpclient:~$ sudo ifup --force eth0 Internet Systems Consortium DHCP Client 4.3.1 Copyright 2004-2014 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/eth0/xx:xx:xx:xx:xx:xx Sending on LPF/eth0/xx:xx:xx:xx:xx:xx Sending on Socket/fallback DHCPREQUEST on eth0 to 255.255.255.255 port 67 DHCPACK from 10.0.0.1 RTNETLINK answers: File exists bound to 10.0.0.100 -- renewal in 20284 seconds.

Anyway this was really surprissing at first, and led me to debug DHCP packets using dhcpdump:

TIME: 2018-09-11 18:06:03.496 IP: 10.0.0.1 (xx:xx:xx:xx:xx:xx) > 10.0.0.100 (xx:xx:xx:xx:xx:xx) OP: 2 (BOOTPREPLY) HTYPE: 1 (Ethernet) HLEN: 6 HOPS: 0 XID: xxxxxxxx SECS: 8 FLAGS: 0 CIADDR: 0.0.0.0 YIADDR: 10.0.0.100 SIADDR: xx.xx.xx.x GIADDR: 0.0.0.0 CHADDR: xx:xx:xx:xx:xx:xx:00:00:00:00:00:00:00:00:00:00 OPTION: 53 ( 1) DHCP message type 2 (DHCPOFFER) OPTION: 54 ( 4) Server identifier 10.0.0.1 OPTION: 51 ( 4) IP address leasetime 43200 (12h) OPTION: 58 ( 4) T1 21600 (6h) OPTION: 59 ( 4) T2 37800 (10h30m) OPTION: 1 ( 4) Subnet mask 255.255.255.0 OPTION: 28 ( 4) Broadcast address 10.0.0.255 OPTION: 15 ( 13) Domainname xxxxxxxx OPTION: 12 ( 21) Host name xxxxxxxx OPTION: 3 ( 4) Routers 10.0.0.1 OPTION: 121 ( 8) Classless Static Route xxxxxxxxxxxxxx .....D.. [...] ---------------------------------------------------------------------------

(you can use this handy command both in server and client side)

So, the DHCP server was sending both the Routers (code 3) and the Classless Static Route (code 121) options to the clients. So, why would fail the client to install both routes?

I obtained some help from folks on IRC and they pointed me towards RFC3442:

DHCP Client Behavior [...] If the DHCP server returns both a Classless Static Routes option and a Router option, the DHCP client MUST ignore the Router option.

So, clients are supposed to ignore the Routers (code 3) option if they get an additional static route. This is very counter-intuitive, but can be easily workarounded by just distributing the default gateway route as another classless static route:

dhcp-option=option:classless-static-route,0.0.0.0/0,10.0.0.1,172.16.0.0/21,10.0.0.253 # ^^ default route ^^ extra static route

Obviously this was my first time in my career dealing with this setup and situation. My conclussion is that even old-enough protocols like DHCP can sometimes behave in a counter-intuitive way. Reading RFCs is not always funny, but can help understand what’s going on.

You can read the original issue in Wikimedia Foundation’s Phabricator ticket T202636, including all the back-and-forth work I did. Yes, is open to the public ;-)

Arturo Borrero González http://ral-arturo.org/ ral-arturo.org

My first race redo at the same distance/ascent meters. Let’s see how it went… 45.2km, 1’773m altitude gain (officially: 45km, 1’800m). This was the Halbmarathon distance, compared to the full Marathon one, which is 86km/3’000m.

Pre-race

I registered for this race right after my previous one, and despite it having much more altitude meters, I was looking forward to it.

That is, until the week of the race. The entire week was just off. Work life, personal life, everything seemed out of sync. Including a half-sleepless night on Wednesday, which ruined my sleep schedule for the rest of the week and also my plans for the light maintenance rides before the event. And which also made me feel half-sick due to lack of sleep.

I prepared for my ride on Saturday (bike check, tyre pressure check, load bike on car), and I went to bed—late, again difficult to fall asleep—not being sure I’ll actually go to the race. I had a difficult night sleep, but actually I managed to wake up on the alarm. OK, chances looking somewhat better for getting to the race. Total sleep: 5 hours. Ouch!

So I get in the car—about 15 minutes later than planned—and start, only to find a road closure on the most direct route to the highway, and police people directing the traffic—at around 07:10—on the “new” route, resulting in yet another detour, and me getting stressed enough on which way to go and not paying attention to exact speed on a downhill that I got a flashed by a speed camera. Sigh…

The rest of the drive was uneventful, I reach Alpnach, I park, I get to the start/finish location, get my number, and finally get to the start line with two minutes (!!) to spare. The most “just-in-time” I ever was at a race, as I’m usually way early. By this time I was even in a later starting block since mine was already setup and would have been difficult to reach.

Oh, and because I was so late, and because this is smaller race (number of participants, setup, etc.), I didn’t find a place to fill my water bottle. And this, for the one time I didn’t fill it in advance. Fun!

The race

So given all this, I set low expectations for the race, and decided to consider it a simple Sunday ride. Will take it easy on the initial 12.5km, 1’150m climb, and then will see how it goes. There was a food station two thirds in the climb, so I said I’ll hopefully not get too dehydrated until then.

The climb starts relaxed-I was among the last people starting—and 15 minutes in, my friend the lower back says “ah, you’re climbing again, remember I’m here too”, which was way too early. So, I said to myself, nothing to lose, let’s just switch to standing every time my back gets tired, and stand until my legs get tired, then switch again.

The climb here was on pavement, so standing was pretty easy. And, to my surprise, this worked quite well: while standing I also went much faster (by much, I mean probably ~2-3km/h) than sitting so I was advancing in the long stretch of people going up the mountain, and my back was very relieved every time I switched.

So, up and down and up and down in the saddle, and up and up and up on the mountain, until I get to the food station. Water! I quickly drink an entire bottle (750ml!!), refill, and go on.

After the food station, the route changed to gravel, and this made pedalling while standing more difficult, due to less grip and slipping if you’re not careful. I tried the sit/stand/sit routine, but it was getting more difficult, so I went, slower, until a point I had to stop. I was by now in the sun, hot, and tired. And annoyed at the low volume out of the water bottle, so I opened it, and drank just like from a glass, and emptied it quickly - yet again! I felt much better, and restarted pedalling, eager to get to the top.

The last part of the climb is quite steep and more or less on a trail, so here I was pushing the bike, but since I didn’t have any goals did not feel guilty about it. Up and up, and finally I reach the top (altitude: 1’633m, elevation gained: 1’148m out of ~1’800m), and I can breathe easier knowing that the most difficult part is over.

From here, it was finally a good race. The o-tour route is much more beautiful than I remembered, but also more technically difficult, to the point of being quite annoying: it runs for long stretches on very uneven artificial paths, like if someone built a paved road, but the goal was to have the most uneven surface, all rocks being at an angle, instead of aiming for an even surface. For hikers this is excellent, especially in wet conditions, but for trying to move a bike forward, or even more, forward uphill, is annoying. There were stretches of ~5% grade that I was pushing the bike, due to how annoying biking on that surface was.

The route also has nice single track sections, some easily navigable, some not, at least for me, and some that I had to carry the bike. Or even carry the bike on my shoulder while I was climbing over roots. A very nice thing, and sadly uncommon in this series of races.

One other fun aspect of the race was the mud. Especially in the forests, there was enough water left on tracks that one got splashed quite often, and outside (where the soil doesn’t have the support of the rood), less water but quite deep mud. Deep enough that at one point, I misjudged how deep the around 3 meters long mud-alike section was, and I had enough speed so that my front wheel got stuck in mud, and slowly (and I imagine gracefully as well :P, of course) I went over the handlebars in the softest mud I ever landed in. Landed, as halfway up my elbows (!), hands full of mud, gloves muddy as hell, legs down to the ankle in mud so shoes also muddy, and me finding the situation the funniest moment of the race. The guy behind me asked if everything is alright, and I almost couldn’t answer due to laughing out-loud.

Back to serious stuff now. The rest of the “meters of climbing left”, about 600+ meters, were supposed to be distributed in about 4 sections, all about the same profile except the first one which was supposed to be a bit longer and flatter. At least, that’s what the official map was showing, in a somewhat stylised way. And that’s what I based my effort dosage on.

Of course, real life is not stylised, and there 2 small climbs (as expected), and then a long and slow climb (definitely unexpected). I managed to stay on the bike, but the unexpected long climb—two kilometres—exhausted my reserves, despite being a relatively small grade (~5%, gained ~100m). I really was not planning for it, and I paid for that. Then a bit of downhill, then another short climb, another downhill—on road, 60km/h!—and then another medium-sized climb: 1km long, gaining 60m. Then a slow and long descent, a 700m/50m climb, a descent, and another climb, short but more difficult: 900m/80m (~9%). By this time, I was spent, and was really looking forward to the final descent, which I remembered was half pavement, half very nice single-track. And indeed it was superb, after all that climbing. Yay!

And then, reaching basically the end of the race (a few kilometres left), I remembered something else: this race has a climb at the end! This is where the missing climbing meters were hiding!

So, after eight kilometres of fun, 1.5km of easy climbing to gain 80m of ascent. Really trivial, a regular commute almost, but for me at this stage, it was painful and the most annoying thing ever…

And then, reaching the final two kilometres of light descent on paved road, and finishing the race. Yay!

Overall, given the way the week went, this race was much easier than I hoped, and quite enjoyable. Why? No idea. I’ll just take the bonus points and not complain ☺

Real champions

After about two minutes of me finishing, I hear the speaker saying that the second placed woman in the long distance was nearing, and that it was Esther Süss! I’ve never seen her in person as far as I know, nor any of the other leaders in these races, since usually the end times are much apart. In this case, I apparently finished between the first and second places in the women’s race (there was 3m05s difference between them). This also explained what all those photographers with telephotos at the finish line were waiting for, and why they didn’t take my picture :)))))) In any case, I was very happy to see her in person, since I’m very impressed that at 44 years old, she’s still competing and most of the time winning against other women, 10 or even 20 years younger than her. Gives a bit of hope for older people like me. Of course minus being on the thinner side (unlike me), and actually liking long climbs (unlike me), and winning (definitely unlike me). Not even bringing up the world championships gold medals, OK?

Race analysis Hydration, hydration…

As I mentioned above, I drank a lot at the beginning of the race. I continued to drink, and by 2 hours I was 3 full bottles in, at 2:40 I finished the fourth bottle.

Four bottles is 3 litres of liquid, which is way more than my usual consumption since I stopped carrying my hydration pack. In the Eiger bike challenge, done in much hotter temperatures and for longer, I think I drank about the same or only slightly more (not sure exactly). Then temperature: 19° average, 33° max, 6½ hours, this time: 16.2° average, 20° max, ~4 hours. And this time, with 4L in 4 hours, I didn’t need to run to the bathroom as I finished (at all).

The only conclusion I can make is that I sweat much more than I think, and that I must more actively drink water. I don’t want to go back to hydration pack in a race (definitely yes for more relaxed rides), so I need to use all the food stops to drink and refill.

General fitness vs. leg muscles

I know my core is weak, but it’s getting hilarious that 15 minutes into the climbing, I start getting signals. This is not happening on flat nor indoor for at least 2-2½ hours, so the conclusion is that I need to get fitter (core) and also do more outdoors real climbing training—just long (slower) climbs.

The sit-stand-sit routine was very useful, but it did result in even my hands getting tired from having to move and stabilise the bike. So again, need to get fitter overall and do more cross-training.

That is, as if I didn’t know it already ☹

Numbers

This is now beyond subjective, let’s see how the numbers look like:

• 2016:
  • time: overall 3h49m34.4s, start-Langis 2h44m31s, Langis-finish: 1h05m02s.
  • age category: overall 70/77, start-Langis ranking: 70, Langis-finish: 72.
  • overall gender ranking: overall 251/282, start-Langis: 250, Langis-finish: 255.
• 2018:
  • time: 3h53m43.4s, start-Langis: 2h50m11s, Langis-finish: 1h03m31s.
  • age category 70/84, start-Langis: 71, Langis-finish: 70.
  • overall gender ranking: overall 191/220, start-Langis: 191, Langis-finish: 189.

The first conclusion is that I’ve done infinitesimally better in the overall rankings: 252/282=0.893, 191/220=0.868, so better but only trivially so, especially given the large decline in participants on the short distance (the long one had the same). I cannot compare age category, because ☺

The second interesting titbit is that in 2016, I was relatively faster on the climb plus first part of the high-altitude route, and relatively slower on the second half plus descent, both in the age category and the overall category. In 2018, this reversed, and I gained places on the descent. Time comparison, ~6 minutes slower in the first half, 1m30s faster on the second one.

But I find my numbers so close that I’m surprised I neither significantly improved nor slowed down in two years. Yes, I’m not consistently training, but still… I kind of expect some larger difference, one way or another. Strava also says that I beat my 2016 numbers on 7 segments, but only got second place to that on 14 others, so again a wash.

So, weight gain aside, it seems nothing much has changed. I need to improve my consistency in training 10× probably to see a real difference. On the other hand, maybe this result is quite good, given my much less consistent training than in 2016 — ¯\_(ツ)_/¯.

Equiment-wise, I had a different bike now (full suspension vs. hardtail), and—compared to previous race two weeks ago, at least—I had the tyre pressure quite well dialled in for this event. So I was able to go fast, and indeed overtake a couple of people on the flat/light descents, and more importantly, was not overtaken by other people on the long descent. My brakes were much better as well, so I was a bit more confident, but the front brake started squeaking again when it got hot, so I need to improve this even more. But again, not even the changed equipment made much of a difference ☺

I’ll finish here with an image of my “heroic efforts”:

Not very proud of this…

I’m very surprised that they put a photographer at the top of a climb, except maybe to motivate people to pedal up the next year… I’ll try to remember this ☺

Iustin Pop https://k1024.org iustin - all posts

I have been struggling with getting TensorFlow running on Debian/sid for quite some time. The main problem is that the CUDA libraries installed by Debian are CUDA 9.1 based, and the precompiled pip installable TensorFlow packages require CUDA 9.0 which resulted in an unusable installation. But finally I got around and found all the pieces.

Step 1: Install CUDA 9.0

The best way I found was going to the CUDA download page, select Linux, then x86_64, then Ubuntu, then 17.04, and finally deb (network>. In the text appearing click on the download button to obtain currently cuda-repo-ubuntu1704_9.0.176-1_amd64.deb.

After installing this package as root with

dpkg -i cuda-repo-ubuntu1704_9.0.176-1_amd64.deb

the nvidia repository signing key needs to be added

apt-key adv --fetch-keys https://developer.download.nvidia.com/compute/cuda/repos/ubuntu1704/x86_64/7fa2af80.pub

and finally install the CUDA 9.0 libraries (not all of cuda-9-0 because this would create problems with the normally installed nvidia libraries):

apt-get update apt-get install cuda-libraries-9-0

This will install lots of libs into /usr/local/cuda-9.0 and add the respective directory to the ld.so path by creating a file /etc/ld.so.conf.d/cuda-9-0.conf.

Step 2: Install CUDA 9.0 CuDNN

One difficult to satisfy dependency are the CuDNN libraries. In our case we need the version 7 library for CUDA 9.0. To download these files one needs to have a NVIDIA developer account, which is quick and painless. After that go to the CuDNN page where one needs to select Download for CUDA 9.0 and then cuDNN v7.2.1 Runtime Library for Ubuntu 16.04 (Deb).

This will download a file libcudnn7_7.2.1.38-1+cuda9.0_amd64.deb which needs to be installed with dpkg -i libcudnn7_7.2.1.38-1+cuda9.0_amd64.deb.

Step 3: Install Tensorflow for GPU

This is the easiest one and can be done as explained on the TensorFlow installation page using

pip3 install --upgrade tensorflow-gpu

This will install several other dependencies, too.

Step 4: Check that everything works

Last but not least, make sure that TensorFlow can be loaded and find your GPU. This can be done with the following one-liner, and in my case gives the following output:

$ python3 -c "import tensorflow as tf; sess = tf.Session() ; print(tf.__version__)" 2018-09-11 16:30:27.075339: I tensorflow/core/platform/cpu_feature_guard.cc:141] Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX2 FMA 2018-09-11 16:30:27.143265: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:897] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero 2018-09-11 16:30:27.143671: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1405] Found device 0 with properties: name: GeForce GTX 1050 Ti major: 6 minor: 1 memoryClockRate(GHz): 1.4175 pciBusID: 0000:01:00.0 totalMemory: 3.94GiB freeMemory: 3.85GiB 2018-09-11 16:30:27.143702: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1484] Adding visible gpu devices: 0 2018-09-11 16:30:27.316389: I tensorflow/core/common_runtime/gpu/gpu_device.cc:965] Device interconnect StreamExecutor with strength 1 edge matrix: 2018-09-11 16:30:27.316432: I tensorflow/core/common_runtime/gpu/gpu_device.cc:971] 0 2018-09-11 16:30:27.316439: I tensorflow/core/common_runtime/gpu/gpu_device.cc:984] 0: N 2018-09-11 16:30:27.316595: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1097] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 3578 MB memory) -> physical GPU (device: 0, name: GeForce GTX 1050 Ti, pci bus id: 0000:01:00.0, compute capability: 6.1) 1.10.1 $ Addendum: Keras and R

With the above settled, the installation of Keras can be done via

apt-get install python3-keras

and this should pick up the TensorFlow backend automatically.

For R there is a Keras library that can be installed without

install.packages('keras')

on the R command line (as root).

After that running a simple MNIST code example should use your GPU from R (taken from Deep Learning with R from Manning Publications):

library(keras) mnist <- dataset_mnist() train_images <- mnist$train$x train_labels <- mnist$train$y test_images <- mnist$test$x test_labels <- mnist$test$y network <- keras_model_sequential() %>% layer_dense(units = 512, activation = "relu", input_shape = c(28 * 28)) %>% layer_dense(units = 10, activation = "softmax") network %>% compile( optimizer = "rmsprop", loss = "categorical_crossentropy", metrics = c("accuracy") ) train_images <- array_reshape(train_images, c(60000, 28 * 28)) train_images <- train_images / 255 test_images <- array_reshape(test_images, c(10000, 28 * 28)) test_images <- test_images / 255 train_labels <- to_categorical(train_labels) test_labels <- to_categorical(test_labels) network %>% fit(train_images, train_labels, epochs = 5, batch_size = 128) metrics <- network %>% evaluate(test_images, test_labels) metrics Norbert Preining https://www.preining.info/blog There and back again

This is a public service announcement that the.earth.li (the machine that hosts this blog) will cease service as a Debian mirror on 1st February 2019 at the latest.

It has already been removed from the official list of Debian mirrors. Please update your sources.list to point to an alternative sooner rather than later.

The removal has been driven by a number of factors:

• This mirror was originally setup when I was running Black Cat Networks, and a local mirror was generally useful to us. It’s 11+ years since Black Cat was sold, and 7+ since it moved away from that network.
• the.earth.li currently lives with Bytemark, who already have an official secondary mirror. It does not add any useful resilience to the mirror network.
• For a long time I’ve been unable to mirror all release architectures due to disk space limitations; I think such mirrors are of limited usefulness unless located in locations with dubious connectivity to alternative full mirrors.
• Bytemark have been acquired by IOMart and I’m uncertain as to whether my machine will remain there long term - the acquisition announcement focuses on their cloud service rather than mentioning physical server provision. Disk space requirements are one of my major costs and the Debian mirror makes up ⅔ of my current disk usage. Dropping it will make moving host easier for me, should it prove necessary.

I can’t find an exact record of when I started running a mirror, but it was certainly before April 2005. 13 years doesn’t seem like a bad length of time to have been providing the service. Personally I’ve moved to deb.debian.org but if the network location of the is the reason you chose it then mirror.bytemark.co.uk should be a good option.

Jonathan McDowell https://www.earth.li/~noodles/blog/ Noodles' Emptiness

In February I reviewed a Thinkpad X1 Carbon Gen 1 [1] that I bought on Ebay.

I have just been supplied the 6th Generation of the Thinkpad X1 Carbon for work, which would have cost about $1500 more than I want to pay for my own gear. ;)

The first thing to note is that it has USB-C for charging. The charger continues the trend towards smaller and lighter chargers and also allows me to charge my phone from the same charger so it’s one less charger to carry. The X1 Carbon comes with a 65W charger, but when I got a second charger it was only 45W but was also smaller and lighter.

The laptop itself is also slightly smaller in every dimension than my Gen 1 version as well as being noticeably lighter.

One thing I noticed is that the KDE power applet disappears when battery is full – maybe due to my history of buying refurbished laptops I haven’t had a battery report itself as full before.

Disabling the touch pad in the BIOS doesn’t work. This is annoying, there are 2 devices for mouse type input so I need to configure Xorg to only read from the Trackpoint.

The labels on the lid are upside down from the perspective of the person using it (but right way up for people sitting opposite them). This looks nice for observers, but means that you tend to put your laptop the wrong way around on your desk a lot before you get used to it. It is also fancier than the older model, the red LED on the cover for the dot in the I in Thinkpad is one of the minor fancy features.

As the new case is thinner than the old one (which was thin compared to most other laptops) it’s difficult to open. You can’t easily get your fingers under the lid to lift it up.

One really annoying design choice was to have a proprietary Ethernet socket with a special dongle. If the dongle is lost or damaged it will probably be expensive to replace. An extra USB socket and a USB Ethernet device would be much more useful.

The next deficiency is that it has one USB-C/DisplayPort/Thunderbolt port and 2 USB 3.1 ports. USB-C is going to be used for everything in the near future and a laptop with only a single USB-C port will be as annoying then as one with a single USB 2/3 port would be right now. Making a small laptop requires some engineering trade-offs and I can understand them limiting the number of USB 3.1 ports to save space. But having two or more USB-C ports wouldn’t have taken much space – it would take no extra space to have a USB-C port in place of the proprietary Ethernet port. It also has only a HDMI port for display, the USB-C/Thunderbolt/DisplayPort port is likely to be used for some USB-C device when you want an external display. The Lenovo advertising says “So you get Thunderbolt, USB-C, and DisplayPort all rolled into one”, but really you get “a choice of one of Thunderbolt, USB-C, or DisplayPort at any time”. How annoying would it be to disconnect your monitor because you want to read a USB-C storage device?

As an aside this might work out OK if you can have a DisplayPort monitor that also acts as a USB-C hub on the same cable. But if so requiring a monitor that isn’t even on sale now to make my laptop work properly isn’t a good strategy.

One problem I have is that resume from suspend requires holding down power button. I’m not sure if it’s hardware or software issue. But suspend on lid close works correctly and also suspend on inactivity when running on battery power. The X1 Carbon Gen 1 that I own doesn’t suspend on lid close or inactivity (due to a Linux configuration issue). So I have one laptop that won’t suspend correctly and one that won’t resume correctly.

The CPU is an i5-8250U which rates 7,678 according to cpubenchmark.net [2]. That’s 92% faster than the i7 in my personal Thinkpad and more importantly I’m likely to actually get that performance without having the CPU overheat and slow down, that said I got a thermal warning during the Debian install process which is a bad sign. It’s also only 114% faster than the CPU in the Thinkpad T420 I bought in 2013. The model I got doesn’t have the fastest possible CPU, but I think that the T420 didn’t either. A 114% increase in CPU speed over 5 years is a long way from the factor of 4 or more that Moore’s law would have predicted.

The keyboard has the stupid positions for the PgUp and PgDn keys I noted on my last review. It’s still annoying and slows me down, but I am starting to get used to it.

The display is FullHD, it’s nice to have a laptop with the same resolution as my phone. It also has a slider to cover the built in camera which MIGHT also cause the microphone to be disconnected. It’s nice that hardware manufacturers are noticing that some customers care about privacy.

The storage is NVMe. That’s a nice feature, although being only 240G may be a problem for some uses.

Conclusion

Definitely a nice laptop if someone else is paying.

The fact that it had cooling issues from the first install is a concern. Laptops have always had problems with cooling and when a laptop has cooling problems before getting any dust inside it’s probably going to perform poorly in a few years.

Lenovo has gone too far trying to make it thin and light. I’d rather have the same laptop but slightly thicker, with a built-in Ethernet port, more USB ports, and a larger battery.

• [1] https://etbe.coker.com.au/2018/02/08/thinkpad-x1-carbon/
• [2] https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i5-8250U+%40+1.60GHz&id=3042

Related posts:

1. More About the Thinkpad X301 Last month I blogged about the Thinkpad X301 I got...
2. Thinkpad T420 I’ve owned a Thinkpad T61 since February 2010 [1]. In...
3. Thinkpad X1 Carbon I just bought a Thinkpad X1 Carbon to replace my...

etbe https://etbe.coker.com.au etbe – Russell Coker

A first update to the AsioHeaders package arrived on CRAN today. Asio provides a cross-platform C++ library for network and low-level I/O programming. It is also included in Boost – but requires linking when used as part of Boost. This standalone version of Asio is a header-only C++ library which can be used without linking (just like our BH package with parts of Boost).

This release is the first following the initial upload of version 1.11.0-1 in 2015. I had noticed the updated 1.12.1 version a few days ago, and then Joe Cheng surprised me with a squeaky clean PR as he needed it to get RStudio’s websocket package working with OpenSSL 1.1.0.

I actually bumbled up the release a little bit this morning, uploading 1.12.1 first and then 1.12.1-1 as we like having a packaging revision. Old habits die hard. So technically CRAN, but we may clean that up and remove the 1.12.1 release from the archive as 1.12.1-1 is identical but for two bytes in DESCRIPTION.

The NEWS entry follow, it really is just the header update done by Joe plus some Travis maintenance.

Changes in version 1.12.1-1 (2018-09-10)

• Upgraded to Asio 1.12.1 (Joe Cheng in #2)

• Updated Travis CI support via newer run.sh

Via CRANberries, there is a diffstat report relative to the previous release, as well as this time also one between the version-corrected upload and the main one.

Comments and suggestions about AsioHeaders are welcome via the issue tracker at the GitHub GitHub repo.

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

Dirk Eddelbuettel http://dirk.eddelbuettel.com/blog Thinking inside the box

The Commons Clause was announced recently, along with several projects moving portions of their codebase under it. It's an additional restriction intended to be applied to existing open source licenses with the effect of preventing the work from being sold[1], where the definition of being sold includes being used as a component of an online pay-for service. As described in the FAQ, this changes the effective license of the work from an open source license to a source-available license. However, the site doesn't go into a great deal of detail as to why you'd want to do that.

Fortunately one of the VCs behind this move wrote an opinion article that goes into more detail. The central argument is that Amazon make use of a great deal of open source software and integrate it into commercial products that are incredibly lucrative, but give little back to the community in return. By adopting the commons clause, Amazon will be forced to negotiate with the projects before being able to use covered versions of the software. This will, apparently, prevent behaviour that is not conducive to sustainable open-source communities.

But this is where things get somewhat confusing. The author continues:

Our view is that open-source software was never intended for cloud infrastructure companies to take and sell. That is not the original ethos of open source.

which is a pretty astonishingly unsupported argument. Open source code has been incorporated into proprietary applications without giving back to the originating community since before the term open source even existed. MIT-licensed X11 became part of not only multiple Unixes, but also a variety of proprietary commercial products for non-Unix platforms. Large portions of BSD ended up in a whole range of proprietary operating systems (including older versions of Windows). The only argument in favour of this assertion is that cloud infrastructure companies didn't exist at that point in time, so they weren't taken into consideration[2] - but no argument is made as to why cloud infrastructure companies are fundamentally different to proprietary operating system companies in this respect. Both took open source code, incorporated it into other products and sold them on without (in most cases) giving anything back.

There's one counter-argument. When companies sold products based on open source code, they distributed it. Copyleft licenses like the GPL trigger on distribution, and as a result selling products based on copyleft code meant that the community would gain access to any modifications the vendor had made - improvements could be incorporated back into the original work, and everyone benefited. Incorporating open source code into a cloud product generally doesn't count as distribution, and so the source code disclosure requirements don't trigger. So perhaps that's the distinction being made?

Well, no. The GNU Affero GPL has a clause that covers this case - if you provide a network service based on AGPLed code then you must provide the source code in a similar way to if you distributed it under a more traditional copyleft license. But the article's author goes on to say:

AGPL makes it inconvenient but does not prevent cloud infrastructure providers from engaging in the abusive behavior described above. It simply says that they must release any modifications they make while engaging in such behavior.

IE, the problem isn't that cloud providers aren't giving back code, it's that they're using the code without contributing financially. There's no difference between what cloud providers are doing now and what proprietary operating system vendors were doing 30 years ago. The argument that "open source" was never intended to permit this sort of behaviour is simply untrue. The use of permissive licenses has always allowed large companies to benefit disproportionately when compared to the authors of said code. There's nothing new to see here.

But that doesn't mean that the status quo is good - the argument for why the commons clause is required may be specious, but that doesn't mean it's bad. We've seen multiple cases of open source projects struggling to obtain the resources required to make a project sustainable, even as many large companies make significant amounts of money off that work. Does the commons clause help us here?

As hinted at in the title, the answer's no. The commons clause attempts to change the power dynamic of the author/user role, but it does so in a way that's fundamentally tied to a business model and in a way that prevents many of the things that make open source software interesting to begin with. Let's talk about some problems.

The power dynamic still doesn't favour contributors

The commons clause only really works if there's a single copyright holder - if not, selling the code requires you to get permission from multiple people. But the clause does nothing to guarantee that the people who actually write the code benefit, merely that whoever holds the copyright does. If I rewrite a large part of a covered work and that code is merged (presumably after I've signed a CLA that assigns a copyright grant to the project owners), I have no power in any negotiations with any cloud providers. There's no guarantee that the project stewards will choose to reward me in any way. I contribute to them but get nothing back in return - instead, my improved code allows the project owners to charge more and provide stronger returns for the VCs. The inequity has shifted, but individual contributors still lose out.

It discourages use of covered projects

One of the benefits of being able to use open source software is that you don't need to fill out purchase orders or start commercial negotiations before you're able to deploy. Turns out the project doesn't actually fill your needs? Revert it, and all you've lost is some development time. Adding additional barriers is going to reduce uptake of covered projects, and that does nothing to benefit the contributors.

You can no longer meaningfully fork a project

One of the strengths of open source projects is that if the original project stewards turn out to violate the trust of their community, someone can fork it and provide a reasonable alternative. But if the project is released with the commons clause, it's impossible to sell any forked versions - anyone who wishes to do so would still need the permission of the original copyright holder, and they can refuse that in order to prevent a fork from gaining any significant uptake.

It doesn't inherently benefit the commons

The entire argument here is that the cloud providers are exploiting the commons, and by forcing them to pay for a license that allows them to make use of that software the commons will benefit. But there's no obvious link between these things. Maybe extra money will result in more development work being done and the commons benefiting, but maybe extra money will instead just result in greater payout to shareholders. Forcing cloud providers to release their modifications to the wider world would be of benefit to the commons, but this is explicitly ruled out as a goal. The clause isn't inherently incompatible with this - the negotiations between a vendor and a project to obtain a license to be permitted to sell the code could include a commitment to provide patches rather money, for instance, but the focus on money makes it clear that this wasn't the authors' priority.

What we're left with is a license condition that does nothing to benefit individual contributors or other users, and costs us the opportunity to fork projects in response to disagreements over design decisions or governance. What it does is ensure that a range of VC-backed projects are in a better position to improve their returns, without any guarantee that the commons will be left better off. It's an attempt to solve a problem that's existed since before the term "open source" was even coined, by simply layering on a business model that's also existed since before the term "open source" was even coined[3]. It's not anything new, and open source derives from an explicit rejection of this sort of business model.

That's not to say we're in a good place at the moment. It's clear that there is a giant level of power disparity between many projects and the consumers of those projects. But we're not going to fix that by simply discarding many of the benefits of open source and going back to an older way of doing things. Companies like Tidelift[4] are trying to identify ways of making this sustainable without losing the things that make open source a better way of doing software development in the first place, and that's what we should be focusing on rather than just admitting defeat to satisfy a small number of VC-backed firms that have otherwise failed to develop a sustainable business model.

[1] It is unclear how this interacts with licenses that include clauses that assert you can remove any additional restrictions that have been applied
[2] Although companies like Hotmail were making money from running open source software before the open source definition existed, so this still seems like a reach
[3] "Source available" predates my existence, let alone any existing open source licenses
[4] Disclosure: I know several people involved in Tidelift, but have no financial involvement in the company

comments Matthew Garrett https://mjg59.dreamwidth.org/ Matthew Garrett

Here’s what happened in the Reproducible Builds effort between Sunday September 2 and Saturday September 8 2018:

• The trydiffoscope command-line client for try.diffoscope.org was uploaded to Debian unstable by Chris Lamb. It included contributions already covered in previous weeks as well as adding a add missing Build-Depends on dh-python.

• There were further updates for our website including Arnout Engelen fixing some presentation titles and URLs and making some initial changes to use the logo and colours from our style guide which were subsequently adjusted by Chris Lamb to avoid breaking the navigation and ensuring images were visible on all pages on the site.

• Our Jenkins-based testing framework that powers tests.reproducible-builds.org was updated this month, including Holger Levsen explaining how to cleanup systemctl’s state and to drop a “work-in-progress” disclaimer and Hans-Christoph Steiner added new packages to the FDroid dependency list.

• 11 Debian package reviews were added, 9 were updated and 11 were removed in this week, adding to our knowledge about identified issues. A new randomness_in_frozenset_representations_in_sphinx toolchain issue was identified and added by Chris Lamb.

Patches filed

• Bernhard M. Wiedemann:

  • fs-uae (zip order, date)
  • varnish (merged, replace randomness with digest + fixup)
  • pesign-obs-integration (merged bugfix + more bugs)
  • kdoctools (parallelism-race bug)
  • openmpi (user+host)
  • openmpi3 (date+hostname)
  • tog-pegasus (drop timestamp)
  • build-compare (merged, bugfix, ignored diffs)
  • OBS (issues with unreproducible noarch packages)
  • graphviz (merged, sort glob(3) / readdir(2))
  • python-pymol (merged, sort python glob / readdir(2))
  • graphviz/sfio (benchmarking)
  • stressapptest (date+user+host)

• Chris Lamb:

  • #907793 filed against libgit2-glib.
  • #907929 filed against taopm.
  • #908040 filed against sphinxcontrib-restbuilder.
  • #908219 filed against libhinawa.
  • #908222 filed against octavia.
  • #908309 filed against gdk-pixbuf.
  • sphinx (merged, sort frozenset)
  • sphinx-gallery (merged, drop build duration from output)

Misc.

This week’s edition was written by Bernhard M. Wiedemann, Chris Lamb & reviewed by a bunch of Reproducible Builds folks on IRC & the mailing lists.

Reproducible builds folks https://reproducible-builds.org/blog/ reproducible-builds.org

After almost 6 months, a new release of the GStreamer Rust bindings and the GStreamer plugin writing infrastructure for Rust is out. As usual this was coinciding with the release of all the gtk-rs crates to make use of all the new features they contain.

Thanks to all the contributors of both gtk-rs and the GStreamer bindings for all the nice changes that happened over the last 6 months!

And as usual, if you find any bugs please report them and if you have any questions let me know.

GStreamer Bindings

For the full changelog check here.

Most changes this time were internally, especially because many user-facing changes (like Debug impls for various types) were already backported to the minor releases in the 0.11 release series.

WebRTC

The biggest change this time is probably the inclusion of bindings for the GStreamer WebRTC library.

This allows using building all kinds of WebRTC applications outside the browser (or providing a WebRTC implementation for a browser), and while not as full-featured as Google’s own implementation, this interoperates well with the various browsers and generally works much better on embedded devices.

A small example application in Rust is available here.

Serde

Optionally, serde trait implementations for the Serialize and Deserialize trait can be enabled for various fundamental GStreamer types, including caps, buffers, events, messages and tag lists. This allows serializing them into any format that can be handled by serde (which are many!), and deserializing them back to normal Rust structs.

Generic Tag API

Previously only a strongly-typed tag API was exposed that made it impossible to use the wrong data type for a specific tag, e.g. code that tries to store a string for the track number or an integer for the title would simply not compile:

let mut tags = gst::TagList::new(); { let tags = tags.get_mut().unwrap(); tags.add::<Title>(&"some title", gst::TagMergeMode::Append); tags.add::<TrackNumber>(&12, gst::TagMergeMode::Append); }

While this is convenient, it made it rather complicated to work with tag lists if you only wanted to handle them in a generic way. For example by iterating over the tag list and simply checking what kind of tags are available. To solve that, a new generic API was added in addition. This works on glib::Values, which can store any kind of type, and using the wrong type for a specific tag would simply cause an error at runtime instead of compile-time.

let mut tags = gst::TagList::new(); { let tags = tags.get_mut().unwrap(); tags.add_generic(&gst::tags::TAG_TITLE, &"some title", gst::TagMergeMode::Append) .expect("wrong type for title tag"); tags.add_generic(&gst::tags::TAG_TRACK_NUMBER, &12, gst::TagMergeMode::Append) .expect("wrong type for track number tag"); }

This also greatly simplified the serde serialization/deserialization for tag lists.

GStreamer Plugins

For the full changelog check here.

gobject-subclass

The main change this time is that all the generic GObject subclassing infrastructure was moved out of the gst-plugin crate and moved to its own gobject-subclass crate as part of the gtk-rs organization.

As part of this, some major refactoring has happened that allows subclassing more different types but also makes it simpler to add new types. There are also experimental crates for adding some subclassing support to gio and gtk, and a PR for autogenerating part of the code via the gir code generator.

More classes!

The other big addition this time is that it’s now possible to subclass GStreamer Pads and GhostPads, to implement the ChildProxy interface and to subclass the Aggregator and AggregatorPad class.

This now allows to write custom mixer/muxer-style elements (or generally elements that have multiple sink pads) in Rust via the Aggregator base class, and to have custom pad types for elements to allow for setting custom properties on the pads (e.g. to control the opacity of a single video mixer input).

There is currently no example for such an element, but I’ll add a very simple video mixer to the repository some time in the next weeks and will also write a blog post about it for explaining all the steps.

A week later than expected, it’s the September development update! The theme for August (and early September) has been visual improvements, with a few bug fixes tossed in for good measure. Check it out! 

Xubuntu Bionic Beaver (18.04)

Bionic was pretty stable in August, with only one of our packages making it through the SRU process and into the hands of our users.

• xfce4-terminal 0.8.7.4-0ubuntu0.18.04.1
  • This is a new upstream release with a number of improvements (LP: #1782327).

We’re currently looking to get these new releases and fixes into Bionic.

• Catfish 1.4.6
  • This is a new release with numerous bug fixes and a much-improved thumbnailer.
• Xfce Settings: Mouse acceleration not configurable in Xubuntu 18.04 (LP: #1758023)
  • This issue is related to libinput taking over mouse configuration, and will be resolved by building xfce4-settings with libinput support.

Cosmic Cuttlefish (18.10)

The following source package updates landed in Cosmic in August.

• elementary-xfce 0.12-1ubuntu1
  • The elementary-xfce icon theme is now available on Debian! Previously, this theme was part of the xubuntu-icon-theme package.
• ristretto 0.8.3-1 (Debian sync)
• thunar-archive-plugin 0.4.0-1 (Debian sync)
• thunar-media-tags-plugin 0.3.0-1 (Debian sync)
• xfce4-taskmanager 1.2.1-1 (Debian sync)
• xubuntu-artwork 18.10
  • The development wallpaper is set on boot and the desktop.
  • The xubuntu-icon-theme is now a branding package, that upgrades the elementary-xfce icon theme with the Xubuntu distributor logo.
• xubuntu-default-settings 18.10
  • “Square icons” were enabled in all supported plugins, improving size and shape consistency on the panel.
  • Orage configuration was updated to use the “paplay” command for sounds by default (LP: #1054396)
  • The panel was updated to be 80% transparent at all times. This is a settings migration to support the new GTK+ 3 panel.
  • The Xubuntu session was updated to correctly set XDG_CURRENT_DESKTOP (LP: #1590089)
• xubuntu-meta 2.227
  • This package release replaces the fwupdate dependency with the newly minted fwupd.

Xfce New Releases

Xfce had 3 new releases in August, featuring a variety of bug fixes and usability improvements.

• Xfce Session 4.13.1
• Xfce Screenshooter 1.9.3
• Xfce Appfinder 4.13.1

Xfce Display Profiles (Preview)

Simon has been hard at work implementing a nifty new feature for the Xfce Display Settings, display profiles! This feature allows you to save and switch between various display setups, useful for users on the go or presenters. This hasn’t been merged into master yet, so designs are not final.

Spacing Improvements

I’ve spent the last week submitting patches to the Xfce core applications, panel plugins, and Thunar plugins. My goal is to improve the overall look and feel of Xfce by improving the consistency of it’s preference dialogs. A few before and after screenshots are below.

I’ve based my work on the excellent GNOME 2 HIG Window Layout documentation. Xfce has long borrowed the design philosophies from this document (to varying degrees) and is once again benefiting from the well-written work.

Shimmer Project Elementary Xfce Icon Theme

Xubuntu’s beloved icon theme has had a few significant updates in recent weeks. From build optimizations to new upstream icons, there’s a lot to unpack.

The theme has added a Makefile and build tool to convert the theme’s SVG sources to PNG. Xubuntu has included the PNG-building functionality for some time, and now it’s available for everyone. PNG-based themes are faster to load and generally crisper at various sizes. Included in the new build options are PNG optimization. Optipng is now used to optimize each of the generated files, reducing the overall file size.

Updated icons coming from upstream this month include dialog-password, selection icons, graphics icons, and manila-colored folders. The manila folders are a sharp contrast from the longtime blue, but after using them for a few days, they’re actually pretty nice.

Other Updates Mugshot 0.4.1

I released Mugshot 0.4.1 early last month with a number of bug fixes and code quality improvements. You can check out the release notes and find downloads here.

Contributing

Ready to start giving back to your favorite open source projects? Remember that there’s something for everyone, and you can get started quickly with the Xubuntu and Xfce contributor docs. If you don’t know where to start, join us at #xubuntu-devel on Freenode… we’ll point you in the right direction.

I meant to write this post much closer to the end of Hacker Summer Camp, but to be honest, I’ve been completely swamped with getting back into the thick of things. However, I kept feeling like things were “unfinished”, so I thought I’d throw together at least a few thoughts from this year.

BSides Las Vegas

I can’t say much about BSides as a whole this year, as I spent the entire time Gold Teaming for Pros vs Joes CTF. (Gold Team is responsible for running the game infrastructure, scoreboard, etc.) It was a great experience to be on Gold Team, but I do miss having a team to support and educate. Overall, the CTF went fairly well, but there were a few bumps that I hope we can avoid next year.

BSides also announced that they are ending their free badges. In some ways, I’m disappointed, but I also understand the reasons they are doing this. Even though I’ve had a badge included with my participation in the PvJ CTF for years, I’ve also been a personal sponsor of BSidesLV for those years as well. I’m lucky enough to be well-employed in the industry that BSidesLV supports, and I want to support their mission. I hope others will do so as well, but I also want to try to find a way to support those who aren’t able to shell out for a badge. Once details are announced for badges next year, I’ll look for an opportunity to support passionate students in our community.

DEF CON 26

DEF CON 26 was an incredible event. I know there were some bumps and warts to it, but I had a great con. (Also, I think it’s the only conference I attend that I refer to simply as “con”.) The villages are my favorite part of DEF CON, and the villages were in rare form this year with the expansion.

This year was my first year speaking at DEF CON (as a village speaker) and I am incredibly humbled by the experience. To think that something I had done was seen as interesting enough for 150 or so attendees to choose to spend 45 minutes of their time listening to me really makes me feel like I’m making an impact. The audience was great, and thanks to the IoT village for having me. (Maybe one day I’ll get a DEF CON speaker badge to place on my wall of badges.)

I have hopes that next year, villages will have some way to divide their rooms or reduce noise for the presentations in their space. So many run another activity (a CTF, hands on activities, etc.) and the noise from that can be problematic when it comes to speakers in the same space. (I experienced this both as a speaker and as an attendee for the talks.)

I also hope that next year, DEF CON will have helped to work through the issues we had with Caesar’s security this year. A good friend of mine landed in hot water over a misunderstood tweet, and there were the obvious reports of “room checks” that were not going according to the established policy. (I’m not even a fan of the room checks, but rifling through guests belongings is completely unacceptable.)

Splitting across Las Vegas Boulevard was also not the best situation. I look forward to moving back to Paris/Bally’s and having Planet Hollywood join the con. (Plus, breakfast crepes!) Getting over to Flamingo was such an ordeal that I only went over there once, and it was a brief visit at that. The ICS village over there was really impressive, and I missed out on a chance to get a Car Hacking Village badge. Some of this was poor planning on my part, but also the sheer distance between the two conference areas made it anything but convenient.

Conclusion

I can’t wait until next year. I’ll begin my planning guide around the beginning of 2019 to try to provide support to those looking for travel information, and I have a feeling that DEF CON 27 will be an even stronger showing. Here’s to all the contributions of the hacker family!

As you may know, Ubuntu Membership is a recognition of significant and sustained contribution to Ubuntu and the Ubuntu community. To this end, the Community Council recruits from our current member community for the valuable role of reviewing and evaluating the contributions of potential members to bring them on board or assist with having them achieve this goal.

We have five members of our boards expiring from their terms, which means we need to do some restaffing of this Membership Board.

We have the following requirements for nominees:

• be an Ubuntu Member (preferably for some time)
• be confident that you can evaluate contributions to various parts of our community
• be committed to attending the membership meetings broad insight into the Ubuntu community at large is a plus

Additionally, those sitting on membership boards should have a proven track record of activity in the community. They have shown themselves over time to be able to work well with others and display the positive aspects of the Ubuntu Code of Conduct. They should be people who can discern character and evaluate contribution quality without emotion while engaging in an interview/discussion that communicates interest, a welcoming atmosphere, and which is marked by humanity, gentleness, and kindness. Even when they must deny applications, they should do so in such a way that applicants walk away with a sense of hopefulness and a desire to return with a more complete application rather than feeling discouraged or hurt.

To nominate yourself or somebody else (please confirm they wish to accept the nomination and state you have done so), please send a mail to the membership boards mailing list (ubuntu-membership-boards at lists.ubuntu.com). You will want to include some information about the nominee, a Launchpad profile link, and which time slot (20:00 or 22:00) the nominee will be able to participate in.

We will be accepting nominations through Monday, September 10th at 13:00 UTC. At that time all nominations will be forwarded to the Community Council who will make the final decision and announcement.

Thanks in advance to you and to the dedication everybody has put into their roles as board members.

Every year we take a group photo at Akademy and then me or one of the Kennies manually marks up the faces so people can tag them and we can know who we all are and build community.  This is quite old school effort so this year I followed a mangazine tutorial and made Akademy Group Photo Automator to do it.  This uses an AI library called face_recognition to do the hard work and Docker to manage the hard work and spits out the necessary HTML.  It was a quick attempt and I’m not sure it did much good in the end alas.  The group photos tend to be quite disorganised and whoever takes it upon themselves to direct it each year makes basic mistakes like putting everyone on a flat stage or making everyone wave their hands about which means many of the faces are half covered and not recognised.  And it seems like the library is not a fan of glasses.  It also outputs rect coordinates rather than circle ones which ment Kenny had to do many adjustments.  Still it’s an interesting quick dive into a new area for me and maybe next year I’ll get it smoother.

Faces recognisedby

Like each month, here comes a report about the work of paid contributors to Debian LTS.

Individual reports

In July, about 224 work hours have been dispatched among 14 paid contributors. Their reports are available:

• Abhijith PA did 12 hours (out of 10 hours allocated + 2 extra hours).
• Antoine Beaupré did 15 hours.
• Ben Hutchings did 10 hours (out of 15 hours allocated + 3 extra hours, thus keeping 8 extra hours for August).
• Brian May did 10 hours.
• Chris Lamb did 18 hours.
• Emilio Pozuelo Monfort did 17.25 hours (out of 30 hours allocated + 6.75 extra hours, thus keeping 19.5 extra hours for August).
• Holger Levsen did nothing (out of 8 hours allocated + 8 extra hours, thus keeping 16 extra hours for August).
• Hugo Lefeuvre did 7.75 hours (out of 15 hours allocated + 9.5 extra hours, but gave back the 16.75 remaining hours).
• Markus Koschany did 30 hours.
• Mike Gabriel did 8 hours.
• Ola Lundqvist did 4 hours (out of 8 hours allocated + 4 remaining hours, thus keeping 8 extra hours for August).
• Roberto C. Sanchez did 18 hours.
• Santiago Ruano Rincón did 17.5 hours (out of 8 hours allocated + 9.5 extra hours).
• Thorsten Alteholz did 30 hours.

Evolution of the situation

The number of sponsored hours did not change.

The security tracker currently lists 51 packages with a known CVE and the dla-needed.txt file has 43 packages needing an update.

Thanks to our sponsors

New sponsors are in bold.

• Platinum sponsors:
• TOSHIBA (for 34 months)
• GitHub (for 25 months)
• Civil Infrastructure Platform (CIP)
• Gold sponsors:
• The Positive Internet (for 51 months)
• Blablacar (for 49 months)
• Linode (for 39 months)
• Babiel GmbH (for 29 months)
• Plat’Home (for 28 months)
• Silver sponsors:
• Domeneshop AS (for 50 months)
• Trollweb Solutions (for 47 months)
• Nantes Métropole (for 44 months)
• Dalenys (for 40 months)
• Université Jean Monnet de St Etienne (for 36 months)
• Univention GmbH (for 35 months)
• Ribbon Communications, Inc. (for 29 months)
• maxcluster GmbH (for 23 months)
• Exonet B.V. (for 19 months)
• Leibniz Rechenzentrum (for 13 months)
• Vente-privee.com (for 10 months)
• CINECA (for 3 months)
• Bronze sponsors:
• David Ayers – IntarS Austria (for 51 months)
• Evolix (for 50 months)
• Seznam.cz, a.s. (for 50 months)
• Freeside Internet Service (for 49 months)
• MyTux (for 49 months)
• Intevation GmbH (for 47 months)
• Linuxhotel GmbH (for 47 months)
• Daevel SARL (for 46 months)
• Bitfolk LTD (for 45 months)
• Megaspace Internet Services GmbH (for 45 months)
• Greenbone Networks GmbH (for 44 months)
• NUMLOG (for 44 months)
• WinGo AG (for 43 months)
• Ecole Centrale de Nantes – LHEEA (for 39 months)
• Sig-I/O (for 37 months)
• Entr’ouvert (for 34 months)
• Adfinis SyGroup AG (for 32 months)
• GNI MEDIA (for 26 months)
• Laboratoire LEGI – UMR 5519 / CNRS (for 26 months)
• Quarantainenet BV (for 26 months)
• RHX Srl (for 23 months)
• Bearstech (for 18 months)
• LiHAS (for 18 months)
• People Doc (for 14 months)
• Catalyst IT Ltd (for 12 months)
• Supagro (for 8 months)
• Demarcq SAS (for 6 months)
• TrapX Security (for 3 months)

No comment | Liked this article? Click here. | My blog is Flattr-enabled.

On September 4th, I’ll be starting a fellowship at the Center for Advanced Studies in the Behavioral Sciences (CASBS), a wonderful social science research institute at Stanford that’s perched on a hill overlooking Palo Alto and the San Francisco Bay. The fellowship is a one-year gig and I’ll be back in Seattle next June.

A CASBS fellowship is an incredible gift in several senses. In the most basic sense, it will mean time to focus on research and writing. I’ll be using my time there to continuing my research on the social scientific study of peer production and cooperation. More importantly though, the fellowship will give me access to a community of truly incredible social social scientists who be my “fellow fellows” next year.

Finally, being invited for a CASBS fellowship is a huge honor. I’ve been preparing by reading a list of Wikipedia articles I built about the previous occupants of the study that I’ll be working out of next year (the third fellow to work out of my study was Claude Shannon!). It’s rare for junior faculty like myself to be invited and I’m truly humbled.

The only real downside of the fellowship is that it means that I’ll be spending the academic year away from Seattle. I’m going to miss working out of UW, my department, and the Community Data Science Collective lab here enormously.

In a personal sense, it means I’ll be leaving a wonderful community in Seattle in and around my home at Extraordinary Least Squares. I’m going to miss folks deeply and I look forward to returning.

Of course, I’m also pretty excited about moving to Palo Alto. It will be the first time either Mika or I have lived in California and we hope to take advantage of the opportunity.

Please help us do so!  If you’re at Stanford, in Silicon Valley, or are anywhere in the Bay Area and want to meet up, please don’t hesitate to get in contact! We’ll be arriving with very little community and I’m really interested in meeting and making friends  and taking advantage of my nine-months in the area to make connections!