You are here

Agreguesi i feed

Steinar H. Gunderson: Futatabi: Multi-camera instant replay with slow motion

Planet Debian - Sht, 02/02/2019 - 11:14md

I've launched Futatabi, my slow motion software! Actually, the source code has been out as part of Nageru for a few weeks, so it's in Debian buster and all, but there's been a dash the last few days to get all the documentation and such in place.

The FOSDEM talk went well—the turnout wasn't huge (about fifty people in person; I don't know the stream numbers), but I guess it's a fairly narrow topic. Feedback was overall good, and the questions were well thought-out. Thanks to everyone who came, and especially those who asked questions! I had planned for 20 minutes (with demo, but without questions) and ended up in 18, so that's fairly good. I forgot only minor details, and reached my goal of zero bullet points. The recording will be out as soon as I can get my hands on it, although I do suspect it's been downconverted from 60 to 50 and then further to 25 fps, which will naturally kill the smoothness of the interpolated video.

Relevant stuff:

Jonathan Dowland: glitched Amiga video

Planet Debian - Sht, 02/02/2019 - 8:30md

This is the fifth part in a series of blog posts. The previous post was Amiga/Gotek boot test.

Glitchy component-video out

As I was planning out my next Gotek-floppy-adaptor experiment, disaster struck: the video out from my Amiga had become terribly distorted, in a delightfully Rob Sheridan fashion, sufficiently so that it was impossible to operate the machine.

Reading around, the most likely explanation seemed to be a blown capacitor. These devices are nearly 30 years old, and blown capacitors are a common problem. If it were in the Amiga, then the advice is to replace all the capacitors on the mainboard. This is something that can be done by an amateur enthusiast with some soldering skills. I'm too much of a beginner with soldering to attempt something like this. I was recommended a company in Aberystwyth called Mutant Caterpillar who do a full recap and repair service for £60 which seems very reasonable.

Philips CRT

Luckily, the blown capacitor (if that's what it was) wasn't in the Amiga, but in the A520 video adaptor. I dug my old Philips CRT monitor out of the loft and connected it directly to the Amiga and the picture was perfect. I had been hoping to avoid fetching it down, as I don't have enough space on my desk to leave it in situ, and instead must lug it over whenever I've found a spare minute to play with the Amiga. But it's probably not worth repairing the A520 (or sourcing a replacement) and the upshot is the picture via the RGB out is much clearer.

As I write this, I'm in a hotel room recovering after my first day at FOSDEM 2019, my first FOSDEM conference. There was a Retrocomputing devroom this year that looked really interesting but I was fully booked into the Java room all day today. (And I don't see mention of Amigas in any of the abstracts)

Bits from Debian: Help test initial support for Secure Boot

Planet Debian - Sht, 02/02/2019 - 11:00pd

The Debian Installer team is happy to report that the Buster Alpha 5 release of the installer includes some initial support for UEFI Secure Boot (SB) in Debian's installation media.

This support is not yet complete, and we would like to request some help! Please read on for more context and instructions to help us get better coverage and support.

On amd64 machines, by default the Debian installer will now boot (and install) a signed version of the shim package as the first stage boot loader. Shim is the core package in a signed Linux boot chain on Intel-compatible PCs. It is responsible for validating signatures on further pieces of the boot process (Grub and the Linux kernel), allowing for verification of those pieces. Each of those pieces will be signed by a Debian production signing key that is baked into the shim binary itself.

However, for safety during the development phase of Debian's SB support, we have only been using a temporary test key to sign our Grub and Linux packages. If we made a mistake with key management or trust path verification during this development, this would save us from having to revoke the production key. We plan on switching to the production key soon.

Due to the use of the test key so far, out of the box Debian will not yet install or run with SB enabled; Shim will not validate signatures with the test key and will stop, reporting the problem. This is correct and useful behaviour!

Thus far, Debian users have needed to disable SB before installation to make things work. From now on, with SB disabled, installation and use should work just the same as previously. Shim simply chain-loads grub and continues through the boot chain without checking signatures.

It is possible to enrol more keys on a SB system so that shim will recognise and allow other signatures, and this is how we have been able to test the rest of the boot chain. We now invite more users to give us valuable test coverage on a wider variety of hardware by enrolling our Debian test key and running with SB enabled.

If you want to help us test our Secure Boot support, please follow the instructions in the Debian wiki and provide feedback.

With help from users, we expect to be able to ship fully-working and tested UEFI Secure Boot in an upcoming Debian Installer release and in the main Buster release itself.

Dirk Eddelbuettel: The Incomplete Book of Running: A Short Review

Planet Debian - Sht, 02/02/2019 - 6:48pd

Peter Sagal’s The Incomplete Book of Running has been my enigma for several weeks now. As a connection, Peter and I have at most one degree of separation: a common fellow runner friend and neighbor who, sadly, long departed to Colorodo (hi Russ!). So we’re quasi-neighbors. But he is famous, I am not, but I follow him on social media.

So as “just another runner”, I had been treated to a constant trickling of content about the book. And I had (in vain) hoped my family would get me the book for Xmas, but no such luck. Hence I ordered a copy. And then Amazon, mankind’s paragon of inventory management and shipment, was seemingly out of it for weeks – so that my copy finally came today all the way from England (!!) even though Sagal and I live a few miles apart, and he and I run similar neighborhoud routes, run (or ran) the same track for Tuesday morning speedwork – and as I noticed while devouring the book, share the same obsession for FIRST I tried to install onto my running pals a decade ago. We also ran the same initial Boston Marathon in 2007, ran many similar marathons (Boston, NY, Philly) even at the same time. But bastard that he his not only owns both my PRs at a half (by about two minutes) and full (by about four minutes) marathon – but he also knows how to write!

This is a great book about running, life, and living around Oak Park. As its focus, the reflections about running are good, sometimes even profound, often funny, and show a writer’s genuine talent in putting words around something that is otherwise hard to describe. Particularly for caustic people such as long-distance runners.

The book was a great pleasure to read—and possibly only the second book in a decade or longer that I “inhaled” cover to cover in one sitting this evening as it was just the right content on a Friday night after a long work week. This was a fun and entertaining yet profound read. I really enjoyed his meditation on the process and journey that got him to his PR – when it was time for mine by now over ten years ago it came after a (now surreal seeming) sequence of running Boston, Chicago, New York in one year and London and Berlin the next. And somehow by the time I got to Berlin I was both well trained, and in a good and relaxed mental shape so that things came together for me that day. (I also got lucky as circumstances were favourable: that was one of the many recent years in which a marathon record was broken in Berlin.) And as Sagal describes really well throughout the book, running is a process and a practical philosophy and an out and occassional meditation. But there is much more in the book so go and read it.

One minor correction: It is Pfeiffer with a P before the f for Michelle’s family name as every viewer of the Baker Boys should know.

Great book. Recommended to runners and non-runners alike.

Ted Gould: Knot Boards

Planet Ubuntu - Sht, 02/02/2019 - 1:00pd

Each year Cub Scouts has a birthday party for Scouting in February, which is called the Blue & Gold banquet. We have a tradition that at the banquet were we thank all of our volunteers who help make the Cub Scout Pack run. For the Den Leaders, who are so critical to the program, I like to do something special that helps them to run a better program for the scouts. For 2018 (notice I'm a little behind) I decided to make all of the Den Leaders for our Pack knot boards.

When I was a Scout I remember my mom making knot boards. Back then we had a piece of paper with the various knots that was varnished onto a piece of plywood, which had a rope attached to it. High technology for the time, but today I'm a member of TheLab.ms makerspace and have access to a laser cutter. While these knot boards are the same in spirt, we can do some very cool things with big toys.

First step is to pull out Inkscape and design the graphics. I grabbed a rope border from Open Clipart and grabbed some knot graphics from a Scouting PDF (which I can't find a link to). I put those together to create the basic design along with labes for the knots. I also added a place for each Scout to sign their name as a Thank you to the Den Leader. I then make some small circles for the laser cutter to cut out holes for the ropes. I made a long oblong region on the right so the board would have a handle and a post to tie the hitches around. Then lastly I added the outline to cut out the board.

To get the design into the laser cutter I exported it from Inkscape in two graphics. I exported the cut lines as a DXF and I exported the etching as a 300 DPI PNG. The cut lines were simpler and the laser cutter software was able to handle those and create simple controls for the cutter. The knots on the other hand were more complex vector objects and the laser cutter software couldn't handle them. Inkscape could, so I had it do the rendering to a bitmap. The laser cutter can then setup scans that use the bitmap data which worked very well.

For the boards I used ¼th" Lauan Plywood which I was able to get in 2'x2' sheets at Lowe's. Those sheets have a nice grain on both sides. I also liked being able to get sheets that were exactly the size I needed to fit into the laser cutter. Saved me a step. I'm certain the knot boards would be great in many other woods and other materials.


After cutting out the knot boards I needed short lengths of rope to be able to insert into the holes. I couldn't find anywhere that would sell me short pieces of rope. I felt like I needed a Monty Python sketch. To make short lengths of the paracord I looped it in a circle with the circumference as the length I needed. Then I took a blowtorch and cut the circle. This also sealed the ends of the paracord.

Petter Reinholdtsen: Websocket from Kraken in Valutakrambod

Planet Debian - Pre, 01/02/2019 - 10:25md

Yesterday, the Kraken virtual currency exchange announced their Websocket service, providing a stream of exchange updates to its clients. Getting updated rates quickly is a good idea, so I used their API documentation and added Websocket support to the Kraken service in Valutakrambod today. The python library can now get updates from Kraken several times per second, instead of every time the information is polled from the REST API.

If this sound interesting to you, the code for valutakrambod is available from github. Here is example output from the example client displaying rates in a curses view:

Name Pair Bid Ask Spr Ftcd Age BitcoinsNorway BTCEUR 2959.2800 3021.0500 2.0% 36 nan nan Bitfinex BTCEUR 3087.9000 3088.0000 0.0% 36 37 nan Bitmynt BTCEUR 3001.8700 3135.4600 4.3% 36 52 nan Bitpay BTCEUR 3003.8659 nan nan% 35 nan nan Bitstamp BTCEUR 3008.0000 3010.2300 0.1% 0 1 1 Bl3p BTCEUR 3000.6700 3010.9300 0.3% 1 nan nan Coinbase BTCEUR 2992.1800 3023.2500 1.0% 34 nan nan Kraken+BTCEUR 3005.7000 3006.6000 0.0% 0 1 0 Paymium BTCEUR 2940.0100 2993.4400 1.8% 0 2688 nan BitcoinsNorway BTCNOK 29000.0000 29360.7400 1.2% 36 nan nan Bitmynt BTCNOK 29115.6400 29720.7500 2.0% 36 52 nan Bitpay BTCNOK 29029.2512 nan nan% 36 nan nan Coinbase BTCNOK 28927.6000 29218.5900 1.0% 35 nan nan MiraiEx BTCNOK 29097.7000 29741.4200 2.2% 36 nan nan BitcoinsNorway BTCUSD 3385.4200 3456.0900 2.0% 36 nan nan Bitfinex BTCUSD 3538.5000 3538.6000 0.0% 36 45 nan Bitpay BTCUSD 3443.4600 nan nan% 34 nan nan Bitstamp BTCUSD 3443.0100 3445.0500 0.1% 0 2 1 Coinbase BTCUSD 3428.1600 3462.6300 1.0% 33 nan nan Gemini BTCUSD 3445.8800 3445.8900 0.0% 36 326 nan Hitbtc BTCUSD 3473.4700 3473.0700 -0.0% 0 0 0 Kraken+BTCUSD 3444.4000 3445.6000 0.0% 0 1 0 Exchangerates EURNOK 9.6685 9.6685 0.0% 36 22226 nan Norgesbank EURNOK 9.6685 9.6685 0.0% 36 22226 nan Bitstamp EURUSD 1.1440 1.1462 0.2% 0 1 2 Exchangerates EURUSD 1.1471 1.1471 0.0% 36 22226 nan BitcoinsNorway LTCEUR 1.0009 22.6538 95.6% 35 nan nan BitcoinsNorway LTCNOK 259.0900 264.9300 2.2% 35 nan nan BitcoinsNorway LTCUSD 0.0000 29.0000 100.0% 35 nan nan Norgesbank USDNOK 8.4286 8.4286 0.0% 36 22226 nan

Yes, I notice the strange negative spread on Hitbtc. I've seen the same on Kraken. Another strange observation is that Kraken some times announce trade orders a fraction of a second in the future. I really wonder what is going on there.

As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

Wouter Verhelst: Visum!

Planet Debian - Pre, 01/02/2019 - 10:22md

A year and a half ago, we made a decision: I was going to move.

About a year ago, I decided that getting this done without professional help was not a very good idea and would take forever, so I got set up with a lawyer and had her guide me through the process.

After lots of juggling with bureaucracies, some unfortunate delays, and some repeats of things I had already done before, I dropped off a 1 cm thick file of paperwork at the consulate a few weeks ago

Today, I went back there to fetch my passport, containing the visum.

Tomorrow, FOSDEM starts. After that, I will be moving to a different continent!

Jamie Strandboge: Monitoring your snaps for security updates

Planet Ubuntu - Pre, 01/02/2019 - 9:53md

Some time ago we started alerting publishers when their stage-packages received a security update since the last time they built a snap. We wanted to create the right balance for the alerts and so the service currently will only alert you when there are new security updates against your stage-packages. In this manner, you can choose not to rebuild your snap (eg, since it doesn’t use the affected functionality of the vulnerable package) and not be nagged every day that you are out of date.

As nice as that is, sometimes you want to check these things yourself or perhaps hook the alerts into some form of automation or tool. While the review-tools had all of the pieces so you could do this, it wasn’t as straightforward as it could be. Now with the latest stable revision of the review-tools, this is easy:

$ sudo snap install review-tools $ review-tools.check-notices \ ~/snap/review-tools/common/review-tools_656.snap {'review-tools': {'656': {'libapt-inst2.0': ['3863-1'], 'libapt-pkg5.0': ['3863-1'], 'libssl1.0.0': ['3840-1'], 'openssl': ['3840-1'], 'python3-lxml': ['3841-1']}}}

The review-tools are a strict mode snap and while it plugs the home interface, that is only for convenience, so I typically disconnect the interface and put things in its SNAP_USER_COMMON directory, like I did above.

Since now it is super easy to check a snap on disk, with a little scripting and a cron job, you can generate a machine readable report whenever you want. Eg, can do something like the following:

$ cat ~/bin/check-snaps #!/bin/sh set -e snaps="review-tools/stable rsync-jdstrand/edge" tmpdir=$(mktemp -d -p "$HOME/snap/review-tools/common") cleanup() { rm -fr "$tmpdir" } trap cleanup EXIT HUP INT QUIT TERM cd "$tmpdir" || exit 1 for i in $snaps ; do snap=$(echo "$i" | cut -d '/' -f 1) channel=$(echo "$i" | cut -d '/' -f 2) snap download "$snap" "--$channel" >/dev/null done cd - >/dev/null || exit 1 /snap/bin/review-tools.check-notices "$tmpdir"/*.snap

or if  you already have the snaps on disk somewhere, just do:

$ /snap/bin/review-tools.check-notices /path/to/snaps/*.snap

Now can add the above to cron or some automation tool as a reminder of what needs updates. Enjoy!

Paul Wise: FLOSS Activities January 2019

Planet Debian - Pre, 01/02/2019 - 6:23pd
Changes Issues Review Administration
  • Debian: merge patch, install dependencies, fix LDAP server, answer keys question, check build hardware differences, remove references to dead systems
  • Debian wiki: re-enable old account unblacklist IP addresses, whitelist email addresses, ping accounts with bouncing email, investigate password reset issue
  • Debian derivatives census: rerun patch generation to fix broken files
Communication
  • Initiate discussion about the status of hLinux
  • Respond to queries from the Debian derivatives census Outreachy project intern
  • Respond to queries from Debian users and developers on the mailing lists and IRC
Sponsors

The purple-discord work was sponsored by my employer. All other work was done on a volunteer basis.

Louis-Philippe Véronneau: DebConf Videoteam sprint @ FOSDEM report

Planet Debian - Pre, 01/02/2019 - 6:00pd

For the past week, the DebConf Videoteam has been hard at work, sprinting in Diegem, Belgium. We've had a lot of fun, but were also able to improve a lot of things.

Raspberry Pi Hacking

Jonathan and Andy eventually want to set up Raspberry Pi 3B+ with screens on the top of our cameras to act as tally lights and enable the video directors to send messages to the camera operators that way. No more sleeping on the switch! To make this possible, Jonathan has been working on adding a custom drop-down menu near the camera preview in voctogui.

Since we don't want to have to jump through hoops to image those boards, Jonathan worked on booting a pure Debian image on the Pi 3B+. He's been able to load an Initramfs and a full mainline kernel on it, but ran into trouble getting the network up because of USB driver problems.

The program Jonathan has been writing to display messages on the Raspberry Pi screens is called toetally. It's still in pre-alpha, but check it out nonetheless!

Opsis

Tzafrir worked on getting his Opsis board up to date with the latest version of HDMI2USB, the firmware we are using on those boards to capture HDMI inputs.

He's been mostly successful in getting it to work, but has been having hardware problems with his Minnowboard Turbot, the SBC we are using to control the Opsis.

Documenting our streaming setup

Nicolas completely rebuilt our streaming setup for DebConf17, migrating from icecast2 to something based on libnginx-mod-rtmp, as icecast2 kept crashing.

It has been working very well since then, but sadly Nicolas hadn't had time to document how it works properly.

This is not the case anymore! You can now check out our streaming documentation.

Nicolas also included our ansible role documentation to the main ansible documentation generated in sphinx.

Hardware Hacking

We recently bought a new audio kit to replace the one we had. It was getting pretty old and was basically crumbling away. At the last mini-DebConf we did in Hamburg, we even had to borrow a kit from the CCC VOC.

Before the sprint, Andy and Kyle worked on listing what hardware we needed to buy and Nicolas had the gear shipped to Paris. Sadly, we only got one of the four wireless receivers we bought, as the other ones were backorder.

During the sprint, Nicolas and Andy worked hard on racking the gear in our new front of stage rack and Andy did a soldering job in our Opsis case to be able to power the Opsis, the turbot and the network switch all at once.

You can find more in depths details about our new audio system and the racking process on Andy's blog.

Thanks to HSBXL for lending us tools to hack sheet metal!

Git LFS

With the phasing out of Alioth, our old git-annex repository was not accessible anymore (Salsa doesn't support git-annex). Judit, Tzafir & Stefano thus worked on migrating it to git LFS.

The plan is to use this new DebConf share repository to host pictures taken by attendees.

As we are trying to migrate away from DebConf hardware, Stefano also wrote a scraper for DebConf Gallery and plans to move the pictures hosted there to DebConf share.

He still plans to modify Wafer to make it easy for speakers to publish their slides on the DebConf website, but if it comes to it, we'll also be able to use that git LFS repository to host slides too.

Playing with the Fomu

Giovanni Mascellani came-by during the week to learn more about the way our setup works. He helped with a bunch of small fixes left and right and we had a very good time!

By pure chance, Stefano came back from LCA with a bunch of Fomu boards (tiny open hardware, open toolchain FPGA boards that fits in your USB port) to give out for FOSDEM and Giovanni managed to flash one of them with a Raspberry Pi. Very neat!

USB installer for our ansible playbooks

Although we mainly install new machines using PXE boot from our network gateway, we sometime need to bootstrap other machines without it. We normally did that by installing Debian manually on a machine and then running ansible on it.

We now have an easy to use USB installer! You can run a simple script that builds a preseeded Debian image and flashes it on a USB key. Once Debian is installed, the machine reboots and runs ansible automatically.

We previously had something similar, but Carl Karsten rebuilt the whole thing and made it easier to use. Louis-Philippe updated the documentation.

Soldering USB ports

When we packed one of our Opsis boards after DebConf18 in Taiwan, one of the USB ports got mangled. Nicolas spent a whole day trying to resolder it back, but finally ended up cutting it from the board and replaced it by a cable attached to a USB header.

systemd in Docker in Gitlab CI

Louis-Philippe worked a large part of the week trying to get systemd to run in Docker in Gitlab CI. We need that to test our ansible modules properly.

Having worked on this previously, this week he tried to build a docker container that ran both systemd as PID 1 and an OpenSSH Server and tried to run this image as a service.

The idea behind this is that since there is no way to run systemd as PID 1 in Gitlab CI, maybe it could be achieved in a service. Ansible roles could then be tested by connecting via ssh.

Sadly, this also proved impossible. Even when using a privileged runner, docker containers need to have volumes like /sys/fs/cgroup explicitly mounted for systemd to run and there is no way to achieve this with a service.

To better test our ansible roles, he added more unit tests that skip the systemd handlers.

DebConf19 preparations

Paulo and Adriana flew in from Brazil to attend the video sprint. With the help of other DebConf people present, they ironed out a few problems and worked some more on planning for DebConf19.

Fixing our example inventory in ansible

Stefano fixed the default ansible inventory that ships with our playbooks. We don't use that inventory very often, as we have a more complete one for our production setup.

It is used by people that want to test our setup though, so that means others will be able to replicate our work more easily.

Thank you!

This sprint would not have been possible without the support of the amazing Jasper Nuyens of Linux Belgium, who very graciously lent us a place to hack and sleep for the week. Jasper also bought us delicious pizza on Thursday night, a gesture everyone highly appreciated.

We also extend our thanks to the Debian Project for giving us a budget for the sprint.

Thank you!

Jonathan McDowell: IoT Security, DRM and user freedom

Planet Debian - Enj, 31/01/2019 - 7:39md

IoT security is a hot topic these days, and rightly so. Matthew Garrett has spent a lot of time reverse engineering various IoT light bulbs to determine how secure they are, with depressing results. So when I saw Bruce Schneier’s recent post Security Analysis of the LIFX Smart Light Bulb which started with “it’s terrible” I thought this was more of the same. Except it’s not. The original article is Pwn the LIFX Mini white (and the author has at least a couple of other device teardowns in the same vein).

What these articles are concerned with is not the usual protocol level security which Matthew investigates. Instead they’re about physical device security. In particular the points raised are:

  • Wi-Fi details are stored in the clear on the device
  • The device does not have secure boot or flash encryption enabled
  • The private key for the device can be retrieved easily

All of these boil down to the same root cause; without effective DRM there is no way to protect devices from physical attacks. That can be as simple as having only internal flash and being able to blow a set of EFUSEs to prevent readout/debug interfaces functioning, or it can be a full built in boot ROM with cryptographic verification of an image pulled in from external flash (potentially encrypted) and the building up of a chain of trust. I see 2 main problems with this.

Firstly, getting security like this right is hard. Games console manufacturers are constantly trying to protect their devices against unauthorised code running, and while they seem to be getting better it’s taken quite a number of mistakes to get there. They have a much bigger financial imperative to get this right, as console DRM attacks are frequently used for piracy. An IoT vendor could end up adding significant cost to their BoM if they have to buy a more advanced chip to be able to do the appropriate end-to-end flash encryption required. (The LIFX is using the ESP32, which does have some of these features that are not present in the more basic (and cheaper) ESP8266. I’ve no idea if anyone has done a full analysis of the ESP32 security.)

Secondly, locking devices down in this way has a big impact on user freedom. It should come as no surprise that this is my primary concern, as I believe it is detrimental to the end user in multiple ways.

  • There’s a lot of poor security in the IoT protocol arena. If it’s not possible for anyone other than the manufacturer to update a device, or retrieve the firmware image to examine how a device operates, security will suffer.
  • Updates being locked down to the manufacturer leaves the user open to the prospect of forced obsolescence when the manufacturer decides they will no longer support the device, or goes out of business (assuming a device that has some sort of cloud component).
  • Part of the appeal of a lot of the current IoT devices is the fact they can be repurposed for uses beyond what the manufacturer imagined. Just look at the Sonoff-Tasmota project - this excellent 3rd party support is one of the main reasons I purchased several Sonoff devices. If I hadn’t been able to replace the firmware they wouldn’t have been of interest to me or countless other people who’ve purchased them.

There are ways to enable user freedom while still having a locked down setup by default, but they’re hard to do in the embedded IoT space (generally no hardware infrastructure that allows plugging in a USB stick with a new root certificate on it and enrolling it like EFI Secure Boot), and add significant cost and complexity to devices that are meant to be cheap and ubiquitous. I see the validity in raising concerns about discarded devices leaking Wi-Fi credentials, but it’s something any device you connect to your Wi-Fi is potentially going to do. That means your laptop, your phone and all the random other devices you allow to connect to your Wi-Fi. It’s something we need to be aware of generally, rather than singling some cheap IoT light bulbs out.

The lack of physical security for the firmware image or device credentials is not so worrying to me. A surveillance device in a light bulb is not a new concept; in fact the added complexity of an IoT bulb makes it easier to justify the complex circuitry being present. If it requires physical access to be able to subvert the device like this that’s significantly less worrying than being able to do so remotely.

Don’t get me wrong, I love a good device teardown, and I think there’s an interesting discussion that’s already underway about how to improve physical device security without restricting user freedom. I just don’t think this is the major failure that some commenters are suggesting.

Ubuntu Podcast from the UK LoCo: S11E99 – Listener Get Together

Planet Ubuntu - Enj, 31/01/2019 - 4:00md

We’re having a Get Together in Reading, UK on Saturday March 16th 2019. The exact venue is not decided yet, but will be in Reading town centre.

We’d like to gauge how many people might come, so please sign in and mark yourself as wanting to come.

It’s Season 11 Episode 99 of the Ubuntu Podcast! Mark Johnson is connected and speaking to your brain.

Back in November 2018 we conducted a poll on Twitter to see what kind of social event our listeners were interested in. Overwhelmingly (and perhaps unsurprisingly) you chose a Pub/Restaurant meet, so that’s what we’re doing.

It’ll be a relaxed social event with the presenters having a beer or fruit-based drink, and maybe some food to be decided later.

Do let us know if you’d like to come by marking yourself attending here.

That’s all for this week! You can listen to the Ubuntu Podcast back catalogue on YouTube. If there’s a topic you’d like us to discuss, or you have any feedback on previous shows, please send your comments and suggestions to show@ubuntupodcast.org or Tweet us or Comment on our Facebook page or comment on our Google+ page or comment on our sub-Reddit.

Andy Simpkins: Debconf Video Team Sprint – Day 3

Planet Debian - Enj, 31/01/2019 - 2:31md

Today has mostly been spent in conversation.

Jonathan has started to scratch an itch that I share, we need a better tally light solution.  When we were using DV switch we had a simple tally light system using (iirc DTR on a) serial port to turn on or off an LED.  This was fine because there was always a PC available at each camera running DVCapture.

Since the move to Voctomix, each camera no longer has it’s own dedicated PC.  Instead we have long 50R co-ax cables (remember the days of cheaper-net 10 base-2?) going directly to a PC running VoctoCore….  Yes we still use a serial port to drive a tally light (all be it these days from a USB to serial converter) but we could do so much better.

Whilst an LED is good to indicate to a presenter which camera(s) are currently active, but wouldn’t it be good to be able to interact with the camera operator some way as well?

Sure we can dedicate an LED or two for this task, but given how cheep SPI displays are these days why not go for a small display instead?

Now the director can send camera operators canned messages (or free text if they have the time to type one).  The camera operator can easily see what the director would like them to do – and they can acknowledge the instruction.  of cause they can also prod the director as well  – two way comms and all :-)

Our tally light / display can be mounted to our cameras using either a flash shoe (shame we can’t grab power this way) or from a tripod screw, both are available on our cameras.

We could choose to hang all this behind a really cheep SBC (think Arduino) but given the cost and that we only need a few something like a RaspberryPi is perhaps a better option.  We could even add USB headsets and mumble if we later want to have full talk-back…

We spent some time fleshing out the requirements for and the road map of the ToeTally project.

I have ordered myself a little SPI display and a case from ebay (Jonathan already has something similar – there are many such things on Ebay and other sites).  This should be plenty to get the project up and running.

/me has found another rabbit hole to spend my time – I may even make some software commits!

 

Debian Java Packaging Team: Help the Java Team distribute your project!

Planet Debian - Enj, 31/01/2019 - 2:00md

There is a vast array of great free software projects written in Java. All sorts of large systems that we all rely on every day are built upon the Apache Foundation libraries. Large companies like Google and IBM put out standard libraries that so many other projects use. Unfortunately, the standard practice for distributing Java code makes it a lot of work to integrate them into Debian.

The Debian Java Team's work is generally under-appreciated, so we are getting the word out here. The Java Team has to consistently fight the Java standard practice of bundling all deps into a single JAR. This means there is no shared security updates, each dev has to update every dependency themselves in that model. That works great for large companies with staff devoted to doing that.

For the majority of Debian use cases, that works poorly. Debian delivers on the promise that people can just apt install foo and have it work, and receive security updates. The user does not even need to know what language the program is written in, it just works.

The Java developer community need to embrace the value of these use cases, and help Debian by making it easier to package Java projects in the standard distro method, with shared dependencies that are independently updated.

Python and Ruby provide great examples of more flexible standard practice for shipping software. Both have methods of describing the dependencies needed, and then automatically fetching them. They are designed in a way that is quite easy to hook into the native build system and make Debian packages. That is sadly not the case with Gradle and Maven, the most popular build systems for Java. For those, the Java Team usually has to extensively patch the build system to make it work for the Debian package.

Steve Kemp: I decided it was time to write a compiler

Planet Debian - Enj, 31/01/2019 - 1:46md

I've spent some time in the recent past working with interpreters, and writing a BASIC interpreter, but one thing I'd not done is write a compiler.

Once upon a time I worked for a compiler-company, but I wasn't involved with the actual coding at that time. Instead I worked on other projects, and did a minor amount of system-administration.

There are enough toy-languages that it didn't seem worthwhile to write a compiler for yet another one. At the same time writing a compiler for a full-language would get bogged down in a lot of noise.

So I decided to simplify things: I would write a compiler for "maths". Something that would take an expression and output assembly-language, which could then be compiled.

The end result is this simple compiler:

Initially I wrote something that would parse expressions such as 3 + 4 * 5 and output an abstract-syntax-tree. I walked the tree and started writing logic to pick registers, and similar. It all seemed like more of a grind than a useful exercise - and considering how ludicrous compiling simple expressions to assembly language already was it seemed particularly silly.

So once again I simplified, deciding to accept only a simple "reverse-polish-like" expression, and outputing the assembly for that almost directly.

Assume you want to calculate "((3 * 5) +2)" you'd feed my compiler:

3 5 * 2 +

To compile that we first load the initial state 3, then we walk the rest of the program always applying an operation with an operand:

  • Store 3
  • 5 * -> multiply by 5.
  • 2 + -> add 2.
  • ..

This approach is trivial to parse, and trivial to output the assembly-language for: Pick a register and load your starting value, then just make sure all your operations apply to that particular register. (In the case of Intel assembly it made sense to store the starting value in EAX, and work with that).

A simple program would then produce a correspondingly simple output. Given 1 1 + we'd expect this output:

.intel_syntax noprefix .global main .data result: .asciz "Result %d\n" main: mov rax, 1 add rax, 1 lea rdi,result mov rsi, rax xor rax, rax call printf xor rax, rax ret

With that output you can assemble the program, and run it:

$ gcc -static -o program program.s $ ./program Result 2

I wrote some logic to allow calculating powers too, so you can output 2 ^ 8, etc. That's just implemented the naive-way, where you have a small loop and multiply the contents of EAX by itself the appropriate number of times. Modulus is similarly simple to calculate.

Adding support for named variables, and other things, wouldn't be too hard. But it would involve register-allocation and similar complexity. Perhaps that's something I need to flirt with, to make the learning process complete, but to be honest I can't be bothered.

Anyway check it out, if you like super-fast maths. My benchmark?

$ time perl -e 'print 2 ** 8 . "\n"' 256 real 0m0.006s user 0m0.005s sys 0m0.000s

vs.

$ math-compiler -compile '2 8 ^' $ time ./a.out Result 256 real 0m0.001s user 0m0.001s sys 0m0.000s

Wow. Many wow. Much speed. All your base-two are belong to us.

Jonathan Carter: Free Software Activities (2019-01)

Planet Debian - Enj, 31/01/2019 - 1:15md

I used to think monthly logs are too much effort, but I decided to give it a go and it ended up being easy and very non-intrusive to my workflow. Above picture taken at Rhodes memorial while riding bike around Cape Town.

2019-01-01 Published Debian Package of the Day #59: bastet (highvoltage.tv / YouTube)

2019-01 01: Start working on updating Planet Debian policy

2019-01-02: Read 191/349 pages of Python Interviews – Discussions with Python experts

2019-01-03: Update Planet Debian policy, make it live and announce it

2019-01-03: Continued discussion of xfce-screensaver‘s future in Debian (ITP: #911115)

2019-01-03: Sponsor package: camlimages (4.2.6-1) (mentors.debian.net), grant dm upload rights for uploader

2019-01-03: Various discussions regarding DebConf20 bids, following Lisbon recon team live updates

2019-01-04: Finish reading Python Interviews – Discussions with Python experts

2019-01-04: Adopt aalib package, upload new package with vcs now on salsa.debian.org

2019-01-04: Upload new upstream version of toot (0.20.0-1) to debian unstable

2019-01-04: Upload new upstream version of bundlewrap (3.5.3-1) to debian unstable

2019-01-04: Upload new upstream version of flask-restful (0.3.7-1) to debian unstable

2019-01-04: Upload new upstream version of gnome-shell-extension-dash-to-panel (17-1) to debian unstable

2019-01-04: Sponsor package: pass-otp (1.2.0-1) (e-mail request)

2019-01-04: Troubleshoot pythonqt, give up in frustration and take a break for the weekend instead

2019-01-07: Backport firmware-nonfree (20180825+dfsg-2~aimsppa1) for AIMS Desktop (mostly for RTL8237AU support)

2019-01-07: Upload new package xfce4-screensaver (0.1.3-1) to debian experimental

2019-01-08: Update calamares-settings-debian (10.0.15) with preliminary buster artwork and work around stale fstab file left behind by live-build and upload to debian unstable (10.0.15-1). Fix description typo that will be released with next upload (Closes: #918222)

2019-01-09: Fix a whole bunch of AIMS Desktop build related problems and build updated stretch/buster images for testing.

2019-01-10: Upload new upstream version of calamares (3.2.3-1) to debian unstable

2019-01-10: Upload new upstream version of python aniso8601 (4.1.0-1) to debian unstable

2019-01-10: Work on initial announcement for Buster artwork selection

2019-01-13: Upload xfce4-screensaver (0.13-2) (Closes: #919151) (Whoops, accidental upload to unstable, file #919348 to prevent it migrating to testing)

2019-01-11: Initial upload of fonts-quicksand (0.2016.1) to debian unstable (Closes: #918995)

Calamares on Debian Live using new buster artwork

2019-01-15: Test new calamares with buster artwork on debian-live weekly builds

2019-01-16: Upload new upstream version of dash-to-panel gnome shell extention (18-1) to debian unstable

2019-01-16: Release new calamares-settings-debian that fixes setups that contain swap partitions + full disk encryption (10.0.16), upload to debian unstable (10.0.16-1) which also fixes a typo (Closes: #918222)

2019-01-17: Upload new live-installer (57) to remove calamares-settings-debian after live install from d-i

2019-01-17: DebConf meeting with DC20 bid teams to ask questions from DebConf Committee and improve bid pages

2019-01-18: Prepare artwork upload for debian-installer, upload rootskel-gtk (1.41) to debian unstable

2019-01-18: Spent lots of time going through debian-installer code, started working on some skeleton concepts for some ideas that I have that I’ll publicly publish some other time

2019-01-19: Started working on some proof-of-concept system installer code in python3, worked mostly on structure and module importing. More on this much later

2019-01-20: Worked on keyboard, localisation and partitioning modules for a concept distro-installer

2019-01-21: Uploaded fonts-quicksand (0.2016-2) with some minor fixes to correct lintian warnings

2019-01-21: Upload calamares (3.2.3-2), add libpwquality-dev and remove patch to use sudo instead of pkexec (not that pkexec seems to work everywhere)

2019-01-22: Sign gpg key of local Debianite who should soon apply for DD

2019-01-22: Adopt and upload preload (0.6.4-3) (Closes: #646216)

2019-01-22: Reviewed mentors.debian.net package siconos (4.2.0+git20181026.0ee5349+dfsg-1) (needs a little more work)

2019-01-22: Review mentors.debian.net package libcxx-serial (1.2.1-1) (needs a little more work)

2019-01-22: Sponsor package budgie-extras (0.7.0-1) (mentors.debian.net request) (Closes: #917724)

2019-01-23: Sponsor package osmose-emulator (1.4-1) (mentors.debian.net request) (Closes: #918507)

2019-01-23: Sponsor package dhcpcd5 (7.0.8-1) (mentors.debian.net request) (Closes: #914070)

2019-01-23: Review mentors.debian.net package pcapy (0.11.4-1) (needs some more work)

2019-01-23: Sponsor package blastem (0.6.1-1) (mentors.debian.net request) (Closes: #919541)

2019-01-23: Review mentors.debian.net package owlr (5.2.0-1) (needs some more work)

2019-01-23: Upload preload (0.6.4-4) to debian experimental (Closes: #920197, #861937, #893374, #697071)

2019-01-23: Fix some bootloader related stuff when using d-i on AIMS Desktop, add README entry in GRUB.

2019-01-24: Sponsor package dhcpcd5 (7.0.8-2) (e-mail request)

2019-01-24: Upload preload (0.6.4-5~exp1) to debian experimental (attempt to fix some niggles)

2019-01-25: Start traveling from Cape Town to Brussels for Debconf video sprint and FOSDEM (thanks to Debian for covering travelling expenses)

2019-01-29: Sponsor packages for DD with expired: key git-review (1.27.0-1), q-text-as-data (1.7.4+2018.12.21+git+28f776ed46-1), swift (2.19.0-4)

Thanks to Linuxbe for providing the hackspace, drinks and kind hospitality for the DebConf video sprint!

2019-01-28: Day 1 of DebConf video sprint. Work on tillytally (now ToeTally), start to unhardcode test cards, implement planned cards and initial discussion with integrating with voctomix-core.

ToeTally is a tally display system that will be mounted above DebConf video cameras, replacing existing tally lights that work over serial, it should make it easier for the director to co-ordinate the stream. It’s also very early work in progress.


2019-01-29: Learn about raspberry pi netbooting, figure, tweak and build debian(ish) images using rpi23-gen-image (for later use on video tally system)

2019-01-30: Spent some time with Andy from video team properly speccing out Tally project, renamed from TillyTally to ToeTally.

2019-01-31: Started working on cross-building scripts for building tally system (arm64) boot environment on x86 that will eventually be deployed using existing video team Ansible setup.

James Bromberger: 20 Years of Linux.conf.au [Memoirs]

Planet Debian - Enj, 31/01/2019 - 1:02md

On the first night I arrived in Christchurch, New Zealand for Linux.conf.au 2019, a group of around a dozen attendees went to dinner. Amongst them were Steve Hanley and Hugh Blemmings, whom I have known since the early 2000’s at various LCAs around the region. They asked for some memoirs of LCA – something small; what follows was my throughts, far longer than expected

Dateline: Just after the Year 2000. The Y2K bug. The first billion seconds of the Unix epoch (Sept 9 2001)…

In the summer of 2001, some friends from Perth and I made a trip to a new conference we had heard about called Linux.conf.au. I was a new Debian Linux developer, my friends were similarly developers, sysadmins, etc. What met us was one of the best interactions of like minded individuals we had seen; deeply technical discussions and presentations by key individuals who not only knew their subject matter, but wrote the code, created the community, or otherwise steered a section of the Open Source software movement from around the world.

Linux.conf.au 2001 – day 1

Living on the opposite side of Australia in Perth meant we were intellectually starved of being able to talk face-to-face to key people from this new world of Open Source and Free Software. The distance across the county is almost the same as East to West coast United States, and not many visitors to Melbourne or Sydney make the long trek over the Great Australian Bight to reach Western Australia’s capital.

We found ourselves asking the LCA 2011 organisers if it would be possible in future to run Linux.Conf.Au in Perth one day.

Having had the initial conference (then called the Conference of Australian Linux Users, or CALU) in 1999 in Melbourne, and then Linux.conf.au 2001 in Sydney, it seemed a natural progression to having LCA roam around different cities year; it felt almost unfair to those who could not afford to travel to Melbourne or Sydney.

The result from 2001 was that in 2002 it would run in Brisbane, but that we should make a proposal and get organised

MiniConfs at LCA

In 1999 I went to AusWeb in Ballina, NSW, and ApacheCon 2K in London.

Closing of ApacheCon 2000 in London – developers on stage Q&A

I also went to DebConf 1 in Bordeaux, France. DebConf was run as an adjunct to the larger French Libre Software Meeting (LSM), as Debian felt that its gathering of developers was too small to warrant the organisational overhead for its own conference at that time.

Debian Developers at DebConf1, Bordeaux 2001

I liked the idea of a pre-conference gathering for Debian for Linux.conf.au 2002 in Brisbane – a Mini Conference.

So in parallel to talking about running LCA in Perth for 2003, I asked Raymond Smith, LCA 2002 lead organiser, and the rest of the Brisbane organising team if I could turn up a few days early to Brisbane for the 2002 conference, use one of the rooms for a small pre-event.

The principle was simple: minimal organisation overhead; don’t get in the way of those setting up for LCA.

LCA2003 Bid Preparation Puffin/Penguin suit

In December 2001 we found what was probably closer to a full-size puffin costume at a fancy dress shop – close enough that it could pass for a penguin.

We started to plan a video as a welcome video – to show some of Perth, and what could be expected in coming to the West.

With a logo I designed from a classic Australian yellow road sign, we had a theme of the Road Trip to Perth.

So with the Puffin/Penguin suit in hand, and a few phone calls, we found ourselves with camera kit on New Years’ Day 2002 at the arrivals hall of Perth airport to film segments for a video to play at the close of LCA2002: the story of tux arriving and making his/her/their way to the conference venue at UWA. Much of the costume performance was Nick Bannon, but also Mark Tearle, and others. I filmed and rough scripted, Tony Breeds edited video, and sought licensing for the music, generously donated by the band credited.

LCA 2002

The MiniConf at LCA ran smoothly. People arrived from around the world, including then DPL Bdale Garbee.

James Bromberger (c) and Bdale Garbee (r) at the Dbeian Mini-Conf, 2002

The main conference was awesome, as always.

Rusty Russell speaking at Linux.conf.au 2002 Jeremy Allison (l) and Andrew Tridgell (r) tlaking Samba at Linux.conf.au 2002 Raymond Smith, lead organiser LCA 2002 Ted T’so talking filesystems at LCA 2002. “In Ted we trust”. LCA2003 closing James Bromberger (l) and Tony Breeds (r) – co-chairs of LCA 2003 LCA2003 invite video being played at LCA2002 Closing Post 2002 prep for 2003

We ran monthly, then weekly face to face meetings, we split into teams – web site, papers committee, travel & accommodation, swag, catering, venue, AV and more. Bernard Blackham made significant changes to get us able to process the crypto to talk to the CommSecure payment gateway so we could process registrations (and send signed receipts).

We thought that not many people would come to Perth, a worry that drove us to innovate. Sun Microsystems agreed to sponsor a program we devised called the Sun Regional Delegate Programme, funding a sizable amount of money to fly people from across the state down to Perth to attend

I left my full time job in November 2002 to work full time on the conference, having planned to start travelling in Europe sometime after LCA in 2003. Hugh Blemmings (then at IBM) sponsored Linus Torvalds to attend, which we kept under wraps.

A small group worked on making a much better, full size Penguin costume, which days before the opening we proposed to put Linus in as part of the opening welcome.

I sourced some white label wine, designed and had printed some custom labels, naming this the Holy Penguin Pee, which was to be our conference dinner wine (amongst other beverages). While at the time this was a nice little drop; the bottles I now hold some 16 years later are a little less palatable.

Perth 2003

Miniconfs had blown out to several sessions. Attendance was projected to exceed 500 attendees (excluding speakers and organisers).

As the audience gathered for the welcome in the Octagon Theatre at UWA, we had amongst us Tove Torvalds, and their three small girls: Patricia (6), Daniella (4), and Celeste (2).

James Bromberger (l), Rusty Russel (c), Linus Torvalds (r

As the conference opened, I took to the stage, and the Penguin waddled on. I commented that we have a mascot, and he’s here; Rusty then joined me, and removed the head of the Penguin to reveal Linus within.

Along with Linus, we also had Tove Torvalds, and their three small girls: Patricia (6), Daniella (4), and Celeste (2). During the earlier rehearsal, the girls were so amused to see their Daddy in a penguin suit; there were some lovely photos of them inspecting the suit, and looking at their Dad change the world while having fun.

On that opening welcome – the morning in the Penguin suit – the temperature was over 40°C.

For a non-profit event, we had too much money left over that it was decided to reduce the profit by ordering pizza for lunch on the last day. Days ahead, we drove to a local pizza hut branch, and asked what would be required to order some 300 pizzas, and could they deliver them effectively. We cut a cheque (remember those) two days in advance, and on the day, two minivans stuffed to the roof turned up.

LCA spelt with Pizza Boxes, a slang name for a common form factor of servers around this time, and one of the LCA yellow banners.

Prior to recycling, I suggested we spell out the name of this even in Pizza boxes as a fun tribute to the amount of pizza we all consumed as we cut code, and changed the world. This photo embodies LCA (and appears on the Wikipedia page). I think I took the image from the library balcony, but I may be wrong.

LCA2003 was the first time we had full audio recordings of all main conference sessions. Ogg Speex was the best codec at the time, and video was just beyond us. A CD was produced containing all recordings, plus a source copy of the Speex codec.

LCA2003 closed on 25 January 2003.

Then on the 26th (Australia Day) my then girlfriend and I grabbed our bags, and moved to the UK for 1 year (PS: it was 8).

Roaming around the northern hemisphere

My time in Europe got me to FOSDEM and DebConf many times. I was at UKUUG, tripping through Cambridge occasionally, seeing people whom I had previously met from the Debian community at the LSM in Bordeaux. I met new people as well, some of whom have since made the trip to Australia in order to present at LCA.

James Bromberger (far l), Barry White (l), Pierre Denis (c), Simon Wardley (far r), at the Fotango Christmas party (skiiing) in Chamonix in 2004.

I spent time at Fotango (part of Canon Europe) working with some awesome Perl developers, and running the data centres and infrastructure.

Returning Home

Upon my return to Perth in 2010, I went back to PLUG, to find a new generation of people who were going to LCA 2011 in Brisbane.

I started a cunning plan with the PLUG crew; we put forward a proposal to the Lottery commission for $10,000 to get equipment for us to set up a single stream for video recording using DVSwitch in order to record the regular PLUG meetings.

Euan (l) and Jason (r) playing with DVSwitch at Perth Artifactory in 2011

It worked; a crew came together, and PLUG had some practice at what running a Video Team required (at the time).  I managed to convince Luke John to put forward a proposal to run LCA – it had been nearly 10 years since it had been in Perth – and thus it came to pass.

I, however, was not going to be front and centre in 2014 (though I did give a presentation on Debian and AWS at the 2014 conference).

But I found a new role I could play. With the additional video kit, and a bit of organising, we grabbed a couch and for one year, created LCA TV – an opportunity to grab on video some of the amazing people who come to Linux.conf.au. While we now have great video of presentations, it’s nice to have a few minutes for chat with those amongst us, captured for posterity.

LCA TV 2014

I want to thank LA Council who have had the courage to have LCA wander the region year to year. I want to thank the LCA crews I have worked with in 2003 and 2014, but I want to thank the crew from every year, the speakers who have stood up and spoken, the video teams, and the volunteers.

Looking forward; I want to thank people who haven’t done what they are going to do yet: those who will run LCA in future, and those who will give their time to share their knowledge with others, across countries, languages, companies and more.

Linux.Conf.Au has been central to the success of technical talent in the Linux and Open Source space in this region.

Arriving at CHC Airport, LCA 2019 was present for conference registrations in the terminal.

I have one more person to thank. My then-girlfriend in 2003, now my wife of many years who has put up with me spending so much time attending, planning and running a technical conference over the years. Thanks Andrea.

Michal Čihař: wlc 1.0

Planet Debian - Enj, 31/01/2019 - 12:30md

wlc 1.0, a command line utility for Weblate, has been just released. The most important change is marking this stable and releasing actual 1.0. It has been around long enough to indicate it's stability.

Full list of changes:

  • Marked as stable release.
  • Added support for more parameters on file upload.

wlc is built on top of Weblate API, you can use it on Weblate 2.10 or newer, though some features might require more recent version. Of course you use it on our hosting offering. Usage examples can be found in the wlc documentation.

Filed under: Debian English SUSE Weblate

Andy Simpkins: Debconf Video Team Sprint – Day 2

Planet Debian - Enj, 31/01/2019 - 12:04md

Two things to concentrate on today, getting the stage box rack populated and following conversation with starting to Jonathan last night, to look at Raspberry Pi boot.

So task 1 Racking up the stage box equipment

It is a shame that we do not have all of the radio receivers for the stage box yet, never mind; I can leave a 1U space in the case for 2 of the missing receivers and I can fit the the one receiver I have with the log side ear that comes with the kit so that it can still be fitted into the rack…  Note to self DO NOT lose the little mounting plate to bind two receivers together – I will need 2 of them, and each receiver comes with just 1…

OK so the box assembled quite well:

Front of rack. Missing 3 of the Radio Mic Receivers

The two (tiny) aerials on the front are connected to the antenna distribution amplifier.  This acts as a buffer amplifier splitting each antenna signal 5 ways;  providing a pair of antenna signals for each of the radio mic receivers and an additional output to ‘daisy chain’ into further distribution amplifiers (we will not need this).

But why have 2 independent antenna systems?  Well this is all about signal path.  When the system is in use the receivers don’t move about, however the radio mic transmitters do (as presenters move around, mics get handed to different people etc).   Each aerial is separated by a significant fraction of the wavelength of the carrier frequency used by the system; this means that if  (when) the signal path between the transmitter and the receiver antennas is poor, due to the line of sight being blocked, weaker signals reflected off the walls ceiling and floor should still reach the antennas, however these reflected signals are the product of multiple signal paths (reflections of many different surfaces).  This multi-path signal is a combination of all the received reflected signals and because the received signals will have taken paths of different lengths when combined they will be slightly out of phase meaning. By having multiple antennas a receiver is offered several observations of the same signal. Each antenna will experience a different interference environment. Thus, if one antenna is experiencing deep fade, it is likely that another has a sufficient signal. Collectively such a system can provide a much more robust link.

The Antenna distribution unit comes with a power supply large enough to power itself and 4 receivers, so it also provides 4 DC power outputs and cables to power the receivers, meaning I only have the one mains power supply for all of the radio mic system.

Below the antenna distribution amplifier there will be 4 radio mic receivers (right now there is only the one – the remaining three are on back order).  Each radio mic receiver comes with enough hardware that it can be installed on its own in a rack; one small ear, and one large ear.  It also comes with a link plate to join to another receiver.  To fit two receivers side by side the large ear is left off and both small ears are used (one from each receiver), the two receivers are linked together with the link plates – located one on the top of the receivers and the other on the bottom (again only one is supplied with each receiver).  Because I have only been sent one receiver so far I have installed this as you can see in the photo.  I MUST NOT LOSE the link plate – It will be needed when I want to fit one of the 3 recivers on back order by the side of the one already in the rack.  A space of 1U has been left for the other 2.

Below the radio mic receivers we have installed our OPSIS / Turbot HDMI capture system.

Finally below that Nicolas has fitted a 2U high draw.  The draw has machined cut-outs so we can store and transport the 2 hand held radio mics and the 2 ‘head set’ mics and their body pack transmitters.  There is even enough space to store some batteries!

Storage for the hand held and headset mic transmitters

Now to the back of the rack…

back of the rack

At the top we have fitted a 2U ventilation plate, behind the distribution amplifier and the top pair of receivers.  A solid 2U blanking plate is at the bottom of the rack behind the draw.

Behind the bottom pair of radio mic receivers (the currently empty space in the picture) I have fitted a 1U short depth shelf.  This proved a but of a faff because I have fitted it BEHIND the face rail so that we can still fit a 2 blanking plate to cover the remaining ‘gap’.

Onto this shelf I planed to mount the power power supply for the radio system, a small packet switch and a 4 way mains power block (to distribute power to the OPSIS, radio receivers and the ‘Wall wart’ power brick for the packet switch)

The 2U blanking plate will be cut out to house all of the plugs and sockets that need to be connected to the rack that is:

1x IEC switched & Fused power inlet
4x XLR mic sockets
1x HDMI in (from presenter laptop)
2x HDMI out (to projector and confidence screen)
4x Ethernet sockets

Each of the above will be cabled to the appropriate locations inside the rack.  The HDMI input cable will also have the ‘MAGIC’ Reamere signal conditioning chip that cleans and reforms the HDMI signal enough that cheep ‘out of spec’ HDMI cables can still be used…    Who would have thaught that those cheep thin HDMI cables you buy from eBay and the likes wouldn’t be HDMI spec compliant?

Anyway the reason for going to all the trouble of fitting a cable between the equipment and a connector mounted on a backplate is two fold:

Firstly it means that we can leave connected all the buts that stay together in the rack.  Nobody is going to disconnect them by mistake when unplugging the cables that go to the outside of the rack.  There is a minimum number of connections presented on the back of the rack to plug into – making this much simpler to use and harder to plug into the wrong socket.

Secondly (in most importantly) it reduces damage to the kit.  Someone will trip over a cable at some point, they will bend a pin, or force the wrong connector into a socket or the right connector upside down…  Cables are cheep and easily replaced, so to are the connectors on the back plate, but a surface mount HDMI connector on the OPSIS or an XLR fitted to the equipment?  Having “Sacrificial” connectors on the back of the unit will hopefully save us a lot of money in the long term.

Ahh that reminds me – the Power supplies on the OPSIS / Turbot in the cases we have a switch for 240 and 110 VAC so we should change them to a wide input version (as is the case for the radio receivers and the packet switch)

Something like this should be fine (we don’t need a full PC power supply – we don’t need the 3V3 rail) 1866-3987-ND.

And then a “Eurica” moment happed…

IF I put the packet switch inside the OPSIS / Turbot rack then I can also power the packet switch from the same 12V rail we power the OPSIS from.  That gets rid of the nasty ‘Wall Wart’ PSU which I hadn’t yet worked out how to mount.  It also means that I don’t need the 1U shelf any more.  I can cable tie the Radio PSU to the ventalation pannel, and I only need to run 2 IEC power cables – one to the radio PSU and the other to the PSU in the OPSIS / Turbot case – AC power distribution is now just 2 wires sharing a ‘Spade’ connection to the Power Inlet Socket / Switch / Fuse Module.

Great problem solved – and much much cleaner / simpler than before.

And then the next problem shows up…

When we put HDMI cables on the back of the OPSIS they protrude too far out the back that they foul the back plate.  So as well as needing to move the Turbot to make way for the packet switch we also need to step back the OPSIS.

First lets move the Turbot.  There are a pair of disk trays in the case that are not being used in this installation.  We will probably install a small SSD to replace the uSD card we are currently using for the Turbot in one, and the Turbot itself can be installed in the other.  Nicolas reached for the Dremal to make some holes in one of the cages… Dremals are really not the right tool here and one broken drill bit and and hour later we decide that no they really are not the right tool here (we still don’t have the correct sized hole for the stand-offs to mount the Turbot)

There has to be a local make space round here?

Indeed there is… and they have an open meeting this evening which we are invited to attend (a talk on OpenLDAP)  after which we can use the workshop.  Many thanks to betz & askarel at the hsbxl Hackerspace Brussels for letting us use the your facility.

The modified OPSIS / Turbot case now looks like this:

Updated chassis

The PSU still needs to be replaced (see above) but as you can see the OPSIS now sits further inside the case, we have a packet switch where the Turbot used to be and the Turbot has been moved to one of the drive bays.  I have also simplified the cabling pruned back the unused wires.

Still to do (not during this sprint):

– Replace the PSU in the OPSIS / Turbot case
– Add a small SSD to the Turbot
– Source connectors for the back plate of the rack and fit
– Cable between the case and the back plate
– Add a FET to power cycle the OPSIS under GPIO control from the Turbot (Hard reset of the FPGA after reprogramming / Remote reset if things go TU during a talk)

Mike Gabriel: FOSDEM 2019

Planet Debian - Enj, 31/01/2019 - 10:46pd

All family members (including myself) are healthy and well, so I am sitting on my yearly train to Belgium. Looking forward to meeting many of you there.

light+love
Mike

Faqet

Subscribe to AlbLinux agreguesi