The new FAI version 5.9.4 adds support for the new Ubuntu LTS version 20.04 (focal). New FAI installation images (including a Ubuntu only ISO) are available from https://fai-project.org/fai-cd I've added support for the Debian testing release (currently bullseye) to the FAIme service for building customized installation and cloud images. This service still supports the oldstable and stable release including variants with a backports kernel. The FAI.me build service is also using the newest FAI version and the customized ISO images can be booted in an UEFI or legacy BIOS environment. https://fai-project.org/FAIme

Folks who acutely dig into this website might know that I have been taking more pictures recently, as I got a new camera since January 2018: a beautiful Fujifilm X-T2 that I really like. Recently, I went out on a photo shoot in the rain. It was intermittent, light rain when I left so I figured the "weather proofing" (dpreview.com calls this "environmentally sealed") would keep the camera secure. After an hour of walking outside, however, rain intensified and I was just quickly becoming more and more soaked. Still trusting the camera would function, I carried on. But after about 90 minutes of dutiful work, the camera just turned off and wouldn't power back on. It had drowned. I couldn't believe it; "but this is supposed to be waterproof! This can't be happening!", I thought. I tried swapping out the battery for a fresh one, which was probably a bad idea (even if I was smart enough to do this under cover): still no luck, yet I could still not believe it was dead, so I figured I would look at it later when I was home. I still eventually removed the battery after a while, remembering that it mattered. Turns out the camera was really dead. Even at home, it wouldn't power up, even with fresh batteries. After closer inspection, the camera was as soaked as I was...

...even the SD cards were wet!

I was filled with despair! My precious camera! I had been waiting for litterally decades to find the right digital camera that was as close to the good old film cameras I was used to. I was even working on black and white "film" to get back to basics, which turned into a project to witness the impact of the coronavirus on city life! All that was lost, or at least stopped: amazingly, the SD cards were just absolutely fine and survived the flooding without problem.

The last photo my camera took before it died

A good photographer friend told me that this was actually fairly common: "if you shoot outside, get used to this, it will happen". So I tried "the rice trick": plunge your camera in a pile of rice and let it rest there for a long time. It didn't work so well: I didn't have a big enough container to hold the camera and the rice. I was also worried about rice particles inserting themselves into the camera holes, as I had opened all the ports to let it dry. I could also not keep myself from inserting a battery and trying it out again: amazingly, it powered up, only once, and died again. After shopping in desperation for dessicators (who would have thought you should keep those little bags from the stuff you order online!), I ended up buying silica gel dehumidifier from Lee Valley (13$, the small one!) which comes in a neat little metal box. But that never arrived in time so I had to find another solution. My partner threw the idea out in jest, but the actual solution worked, and it was surprisingly simple!

Tada! Turns out you can dehydrate hardware too!

We have a food dehydrator at home (a Sedna Express if you really want to know) since we do a lot of backpacking and canot-camping, but I never thought I would put electronics in there. Turns out a food dehydrator is perfect: it has a per degree temperature control that can go very low and a timer. I set it to 30 C for 24 hours. (I originally set it to 40 C but it smelled like plastic after a while so my partner turned it off thinking it was melting the camera.) And now the camera is back! I was so happy! There is probably some permanent damage to the delicate circuitry in the camera. And I will probably not go back out in heavy rain again with the camera, or at least not without a rainjacket (35$USD at B&H) on the camera. And I am now in a position to tell other people what to do if they suffer the same fate...

Tips for dealing with electronic liquid damage So, lessons learned...

1. when you have a liquid spill over your electronics: IMMEDIATELY REMOVE ALL ELECTRIC POWER, including the battery! (this is another reason why all batteries should be removable)
2. if the spill is "sticky" (e.g. coffee, beer, maple syrup, etc) or "salty", do try to wash it with water, yet without flooding it any further (delicate balance, I know) some devices are especially well adapted to this: I have washed a keyboard with a shower head and drowned the thing completely, it worked fine after drying.
3. do NOT power it back on until you are certain the equipment is dry
4. let the electronics device dry for 24 to 48 hours with all ports open in a humidity-absorbing environment: a bag of rice works, but a food dehydrator is best. make sure the rice doesn't get stuck inside the machine: use a small mesh bag if necessary
5. once you are confident the device has dried, fiddle with the controls and see if water comes out: it might not have dried because it was stuck inside a button or dial. if dry, try powering it back on and watch the symptoms. if it's still weird, try drying it for another day.
6. if you get tired of waiting and the machine doesn't come back up, you will have to send it to the repair shop or open it up yourself to see if there is soldering damage you can fix.

I hope it might help careless people who dropped their coffee or ran out in the rain, believing the hype of waterproof cameras. Amateur tip: waterproof cameras are not waterproof...

Armadillo is a powerful and expressive C++ template library for linear algebra aiming towards a good balance between speed and ease of use with a syntax deliberately close to a Matlab. RcppArmadillo integrates this library with the R environment and language and is widely used by (currently) 705 other packages on CRAN. A new upstream release 9.870.2 of Armadillo was released a few days ago. We had tested two release candidates, and this caught one bug. The release was held up at CRAN for a few days as one package had an overly sensitive test depending on random input data; eventually we all convinced ourselves that there was no (Rcpp)Armadillo issue here. So morale: friends don t let friends have tests depend on random behavior. Changes in the new release are noted below.

Changes in RcppArmadillo version 0.9.870.2.0 (2020-04-24)

• Upgraded to Armadillo release 9.870.2 (Roasted Mocha Retox)
  • faster handling of matrix multiplication expressions by diagvec() and diagmat()
  • added trimatu_ind() and trimatl_ind()
  • more consistent detection of sparse vector expressions

Courtesy of CRANberries, there is a diffstat report relative to previous release. More detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page. If you like this or other open-source work I do, you can now sponsor me at GitHub. For the first year, GitHub will match your contributions.

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

Artemisia Gentileschi - Wikipedia

Artemisia Lomi or Artemisia Gentileschi (US: / d nt l ski, -ti -/, Italian: [arte mi zja d enti leski]; July 8, 1593 c. 1656) was an Italian Baroque painter, now considered one of the most accomplished seventeenth-century artists working in the dramatic style of Caravaggio. In an era when women had few opportunities to pursue artistic training or work as professional artists, Artemisia was the first woman to become a member of the Accademia di Arte del Disegno in Florence and had an international clientele.

Maria Pellegrina Amoretti (1756 1787), was an Italian lawyer. She is referred to as the first woman to graduate in law in Italy, and the third woman to earn a degree.

Laura Maria Caterina Bassi (October 1711 20 February 1778) was an Italian physicist and academic. She received a doctoral degree in Philosophy from the University of Bologna in May 1732. She was the first woman to earn a professorship in physics at a university. She is recognized as the first woman in the world to be appointed a university chair in a scientific field of studies. Bassi contributed immensely to the field of science while also helping to spread the study of Newtonian mechanics through Italy.

Maria Gaetana Agnesi (UK: / n je zi/ an-YAY-zee,[1] US: / n -/ ahn-,[2][3] Italian: [ma ri a ae ta na a zi, - e z-];[4] 16 May 1718 9 January 1799) was an Italian mathematician, philosopher, theologian, and humanitarian. She was the first woman to write a mathematics handbook and the first woman appointed as a mathematics professor at a university.[5]

Elena Lucrezia Cornaro Piscopia (US: /k r n ro p sko pi /,[4] Italian: [ lena lu kr ttsja kor na ro pi sk pja]) or Elena Lucrezia Corner (Italian: [kor n r]; 5 June 1646 26 July 1684), also known in English as Helen Cornaro, was a Venetian philosopher of noble descent who in 1678 became one of the first women to receive an academic degree from a university, and the first to receive a Doctor of Philosophy degree.

Maria Tecla Artemisia Montessori (/ m nt s ri/ MON-tiss-OR-ee, Italian: [ma ri a montes s ri]; August 31, 1870 May 6, 1952) was an Italian physician and educator best known for the philosophy of education that bears her name, and her writing on scientific pedagogy. At an early age, Montessori broke gender barriers and expectations when she enrolled in classes at an all-boys technical school, with hopes of becoming an engineer. She soon had a change of heart and began medical school at the Sapienza University of Rome, where she graduated with honors in 1896. Her educational method is still in use today in many public and private schools throughout the world.

Rita Levi-Montalcini OMRI OMCA (US: / le vi mo nt l t i ni, l v-, li vi m nt l -/, Italian: [ ri ta l vi montal t i ni]; 22 April 1909 30 December 2012) was an Italian Nobel laureate, honored for her work in neurobiology. She was awarded the 1986 Nobel Prize in Physiology or Medicine jointly with colleague Stanley Cohen for the discovery of nerve growth factor (NGF). From 2001 until her death, she also served in the Italian Senate as a Senator for Life. This honor was given due to her significant scientific contributions. On 22 April 2009, she became the first Nobel laureate ever to reach the age of 100, and the event was feted with a party at Rome's City Hall. At the time of her death, she was the oldest living Nobel laureate.

Margherita Hack Knight Grand Cross OMRI (Italian: [mar e ri ta (h)ak]; 12 June 1922 29 June 2013) was an Italian astrophysicist and scientific disseminator. The asteroid 8558 Hack, discovered in 1995, was named in her honour.

Samantha Cristoforetti (Italian pronunciation: [sa manta kristofo retti]; born 26 April 1977, in Milan) is an Italian European Space Agency astronaut, former Italian Air Force pilot and engineer. She holds the record for the longest uninterrupted spaceflight by a European astronaut (199 days, 16 hours), and until June 2017 held the record for the longest single space flight by a woman until this was broken by Peggy Whitson and later by Christina Koch. She is also the first Italian woman in space. Samantha Cristoforetti is also known as the first person who brewed an espresso in space.

Ubuntu Focal Fossa 20.04 was released two days ago, so I took the opportunity yesterday and this morning to upgrade my VPS from Ubuntu 18.04 to 20.04. The VPS provides:

• SMTP via Postfix
• Spam filtering via rspamd
• HTTP(S) via nginx and letsencrypt (certbot)
• Weechat relay
• OpenVPN server
• Shadowsocks proxy
• Unbound recursive DNS resolver, for the spam filtering

I rebooted one more time than necessary, though, as my cloud provider Hetzner recently started offering 2nd generation EPYC instances which I upgraded to from my Skylake Xeon based instance. I switched from the CX21 for 5.83 /mo to the CPX11 for 4.15 /mo. This involved a RAM downgrade - from 4GB to 2GB, but that s fine, the maximum usage I saw was about 1.3 GB when running dose-distcheck (running hourly); and it s good for everyone that AMD is giving Intel some good competition, I think. Anyway, to get back to the distribution upgrade - it was fairly boring. I started yesterday by taking a copy of the server and launching it locally in a lxd container, and then tested the upgrade in there; to make sure I m prepared for the real thing :) I got a confusing prompt from postfix as to which site I m operating (which is a normal prompt, but I don t know why I see it on an upgrade); and a few config files I had changed locally. As the server is managed by ansible, I just installed the distribution config files and dropped my changes (setting DPkg::Options "--force-confnew"; ;" in apt.conf), and then after the upgrade, ran ansible to redeploy the changes (after checking what changes it would do and adjusting a few things). There are two remaining flaws:

1. I run rspamd from the upstream repository, and that s not built for focal yet. So I m still using the bionic binary, and have to keep bionic s icu 60 and libhyperscan4 around for it. This is still preventing CI of the ansible config from passing for focal, because it won t have the needed bionic packages around.
2. I run weechat from the upstream repository, and apt can t tell the versions apart. Well, it can for the repositories, because they have Size fields - but status does not. Hence, it merges the installed version with the first repository it sees. What happens is that it installs from weechat.org, but then it believes the installed version is from archive.ubuntu.com and replaces it each dist-upgrade. I worked around it by moving the weechat.org repo to the front of sources.list, so that the it gets merged with that instead of the archive.ubuntu.com one, as it should be, but that s a bit ugly.

I also should start the migration to EC certificates for TLS, and 0-RTT handshakes, so that the initial visit experience is faster. I guess I ll have to move away from certbot for that, but I have not investigated this recently.

Since many years I am a big big fan of Unison. It is a two-way synchronization tool, meaning that changes on both sides are carried over as long as there is no conflict. Unison is the bread and butter for keeping my computers (main desktop, laptop, server) in sync. There is only one problem with Unison it is extremely picky about with what kind of Unison on the other side it speaks: Even the very same version, compiled with a slightly different OCaml compiler version, already produces incompatibilities. And with me having to sync between Debian/Buster (my server) and Debian/sid (my other machines), this always ended in tears. But heyhoh! the pain is over! My solution up to now was to keep a Unison binary from Buster on my Sid system, and used that binary when syncing to Buster server, but the normal Unison binary when syncing between two sid computers. This created lots of pain, because, when using a incompatible Unison binary, already a simple connect without a sync trial messed up the state files and required a complete resync. And so it happened often that I used the wrong binary, and had to resync a few gigabyte, what a pain. The Debian maintainer is working with upstream to improve this rather unfortunate situation, so maybe this will change in the future, but I need a solution now. BTW, thanks a lot to the excellent work of the current maintainers, setting up the new package was a blaze and only needed a bit of adjustments for the changed layout of recent sources. Big kudos to the maintainers of unison!!! So I have ventured out to create my own Unison package for Debian. And what I mean for Debian/Buster and Debian/sid, so that they are compatible, by using the very same compiler and the very same source and the very same dependencies to build the binaries. Fortunately, the lessons learned from my KDE/Plasma updates for Debian helped, and with a bit of magic and the nice service from the openSUSE build service, I now have packages for Unison ready for Debian/Buster and Debian/sid that are compatible, and in addition also the latest version, not the 5 year old package that is currently Debian. So here it is, the Debian Unison repository, binaries of (currently) Unison 2.51.2 are available for both i386 and amd64: For Debian/Buster For Debian/sid: To use this repository, you need to import my OBS key obs-npreining.asc, best put it as is into /etc/apt/trusted.gpg.d/obs-npreining.asc. The sources are available at the OBS project debian-unison. For those interested, I had to backport a few package to Buster to ensure that the builds agree: debhelper (because dh_dwz is buggy in Buster), dh-ocaml, findlib, lablgl, lablgtk2, labltk, and ocaml. These packages are available in the OBS debian-ocaml-backports repository, and are also apt accessible if necessary. I guess you can conjure up the correct line ;-). That s it. I can now forget about all the differences between versions and happily sync between Buster and sid. Enjoy.

The Linux kernel lockdown patches were merged into the 5.4 kernel last year, which means they're now part of multiple distributions. For me this was a 7-year journey, which means it's easy to forget that others aren't as invested in the code as I am. Here's what these patches are intended to achieve, why they're implemented in the current form and what people should take into account when deploying the feature.

Root is a user - a privileged user, but nevertheless a user. Root is not identical to the kernel. Processes running as root still can't dereference addresses that belong to the kernel, are still subject to the whims of the scheduler and so on. But historically that boundary has been very porous. Various interfaces make it straightforward for root to modify kernel code (such as loading modules or using /dev/mem), while others make it less straightforward (being able to load new ACPI tables that can cause the ACPI interpreter to overwrite the kernel, for instance). In the past that wasn't seen as a significant issue, since there were no widely deployed mechanisms for verifying the integrity of the kernel in the first place. But once UEFI secure boot became widely deployed, this was a problem. If you verify your boot chain but allow root to modify that kernel, the benefits of the verified boot chain are significantly reduced. Even if root can't modify the on-disk kernel, root can just hot-patch the kernel and then make this persistent by dropping a binary that repeats the process on system boot.

Lockdown is intended as a mechanism to avoid that, by providing an optional policy that closes off interfaces that allow root to modify the kernel. This was the sole purpose of the original implementation, which maps to the "integrity" mode that's present in the current implementation. Kernels that boot in lockdown integrity mode prevent even root from using these interfaces, increasing assurances that the running kernel corresponds to the booted kernel. But lockdown's functionality has been extended since then. There are some use cases where preventing root from being able to modify the kernel isn't enough - the kernel may hold secret information that even root shouldn't be permitted to see (such as the EVM signing key that can be used to prevent offline file modification), and the integrity mode doesn't prevent that. This is where lockdown's confidentiality mode comes in. Confidentiality mode is a superset of integrity mode, with additional restrictions on root's ability to use features that would allow the inspection of any kernel memory that could contain secrets.

Unfortunately right now we don't have strong mechanisms for marking which bits of kernel memory contain secrets, so in order to achieve that we end up blocking access to all kernel memory. Unsurprisingly, this compromises people's ability to inspect the kernel for entirely legitimate reasons, such as using the various mechanisms that allow tracing and probing of the kernel.

How can we solve this? There's a few ways:

1. Introduce a mechanism to tag memory containing secrets, and only restrict accesses to this. I've tried to do something similar for userland and it turns out to be hard, but this is probably the best long-term solution.
   
2. Add support for privileged applications with an appropriate signature that implement policy on the userland side. This is actually possible already, though not straightforward. Lockdown is implemented in the LSM layer, which means the policy can be imposed using any other existing LSM. As an example, we could use SELinux to impose the confidentiality restrictions on most processes but permit processes with a specific SELinux context to use them, and then use EVM to ensure that any process running in that context has a legitimate signature. This is quite a few hoops for a general purpose distribution to jump through.
   
3. Don't use confidentiality mode in general purpose distributions. The attacks it protects against are mostly against special-purpose use cases, and they can enable it themselves.

My recommendation is for (3), and I'd encourage general purpose distributions that enable lockdown to do so only in integrity mode rather than confidentiality mode. The cost of confidentiality mode is just too high compared to the benefits it provides. People who need confidentiality mode probably already know that they do, and should be in a position to enable it themselves and handle the consequences.

comments

My fellow Debianites, It's been one month, one week and one day since I decided to run for this DPL term. The Debian community has been through a variety of interesting times during the last decade, and instead of focusing on grand, sweeping changes for Debian, core to my DPL campaign was to establish a sense of normality and stability so that we can work on community building, continue to focus on technical excellence and serve our users the best we can. Thing don't always work out as we plan, and for many of us, Debian recently had to take a back seat to personal priorities. Back when I posted my intention to run, there were 125 260 confirmed cases of COVID-19 globally. Today, that number is 20 times higher, with the actual infected number likely to be significantly higher. A large number of us are under lock-down, where we not only fear the disease and its effect on local hospitals and how it will affect our loved ones, but also our very livelihoods and the future of our local businesses and industry. I don't mean to be gloomy with the statement above, I am after all, an optimist - but unfortunately it does get even worse. Governments and corporations around the world have started to take advantage of COVID-19 in negative ways and are making large sweeping changes that undermine the privacy and rights of individuals everywhere. For many reasons, including those above, I believe that the Debian project is more important and relevant now than it's ever been before. The world needs a free, general purpose operating system, unburdened by the needs of profit, which puts the needs of its users first, providing a safe and secure platform for the computing needs of the masses. While we can't control or fix all the problems in the world, we can control our response to it, and be part of the solutions that bring the change we want to see. During my term as DPL, I will be available to help with problems in our community to the maximum extent that my time permits. If we help ourselves, we will be in a better position to help others. If you (or your team) get stuck and are in need of help, then please do not hessitate to e-mail me. A few thank-yous As incoming DPL, I'd like to thank Sam Hartman on behalf of the project for the work that he's done over the last year as DPL. It's a tremendous time commitment that requires constant attention to detail. On Sunday, Sam and I had a handover meeting where we discussed various DPL responsibilities including finances, delegations (including specifics of some delegations), legal matters, outreach and other questions I had. I'd also like to thank Sam for taking the time to do this. Thank you to Sruthi Chadran and Brian Gupta who took the time to also run for DPL this year. Both candidates brought important issues to the forefront and I hope to work with both of them on those in the near future. DPL Blog Today, I've started a new blog for the Debian Project Leader to help facilitate more frequent communication, and to reach a wider audience via Planet Debian. This will contain supplemental information to what I send to the debian-devel-announce mailing list. Want to help? In my platform, I listed some key areas that I'd like to work on. My work won't be limited to those, but it should give you some idea of the type of DPL that I'll be. If you'd like to get involved, feel free to join the #debian-dpl channel on the oftc IRC network, and please introduce yourself along with any areas of interest that you'd like to contribute to.

My fellow Debianites, It's been one month, one week and one day since I decided to run for this DPL term. The Debian community has been through a variety of interesting times during the last decade, and instead of focusing on grand, sweeping changes for Debian, core to my DPL campaign was to establish a sense of normality and stability so that we can work on community building, continue to focus on technical excellence and serve our users the best we can. Thing don't always work out as we plan, and for many of us, Debian recently had to take a back seat to personal priorities. Back when I posted my intention to run, there were 125 260 confirmed cases of COVID-19 globally. Today, that number is 20 times higher, with the actual infected number likely to be significantly higher. A large number of us are under lock-down, where we not only fear the disease and its effect on local hospitals and how it will affect our loved ones, but also our very livelihoods and the future of our local businesses and industry. I don't mean to be gloomy with the statement above, I am after all, an optimist - but unfortunately it does get even worse. Governments and corporations around the world have started to take advantage of COVID-19 in negative ways and are making large sweeping changes that undermine the privacy and rights of individuals everywhere. For many reasons, including those above, I believe that the Debian project is more important and relevant now than it's ever been before. The world needs a free, general purpose operating system, unburdened by the needs of profit, which puts the needs of its users first, providing a safe and secure platform for the computing needs of the masses. While we can't control or fix all the problems in the world, we can control our response to it, and be part of the solutions that bring the change we want to see. During my term as DPL, I will be available to help with problems in our community to the maximum extent that my time permits. If we help ourselves, we will be in a better position to help others. If you (or your team) get stuck and are in need of help, then please do not hessitate to e-mail me. A few thank-yous As incoming DPL, I'd like to thank Sam Hartman on behalf of the project for the work that he's done over the last year as DPL. It's a tremendous time commitment that requires constant attention to detail. On Sunday, Sam and I had a handover meeting where we discussed various DPL responsibilities including finances, delegations (including specifics of some delegations), legal matters, outreach and other questions I had. I'd also like to thank Sam for taking the time to do this. Thank you to Sruthi Chadran and Brian Gupta who took the time to also run for DPL this year. Both candidates brought important issues to the forefront and I hope to work with both of them on those in the near future. DPL Blog Today, I've started a new blog for the Debian Project Leader to help facilitate more frequent communication, and to reach a wider audience via Planet Debian. This will contain supplemental information to what I send to the debian-devel-announce mailing list. Want to help? In my platform, I listed some key areas that I'd like to work on. My work won't be limited to those, but it should give you some idea of the type of DPL that I'll be. If you'd like to get involved, feel free to join the #debian-dpl channel on the oftc IRC network, and please introduce yourself along with any areas of interest that you'd like to contribute to.

It's dead, that's what's wrong with it! It's passed on! This Python is no more! It has ceased to be! It's expired and gone to meet its maker! It's a stiff! Bereft of life, it rests in peace! If you hadn't nailed it to the perch it'd be pushing up the daisies! Its metabolic processes are now 'istory! It's off the twig! It's kicked the bucket, it's shuffled off its mortal coil, run down the curtain and joined the bleedin' choir invisible!! THIS IS AN EX-PYTHON!!

So, after I took over or at least, said to take over maintainership of the Raspberry Pi build images originally produced by Michael Stapelberg in mid-2018, I pushed very few updates. Yes, there was some good and visible work, migrated the image-spec repository from GitHub to Salsa, ironed out several outstanding issues, and most important for me managed to get an image built and running for all Raspberry models below the Raspberry Pi 4 Today, I am happy to announce a very good step in the right direction, so I am now

Announcing raspi.debian.net! I have registered and set up an (unofficial!) site, raspi.debian.net, that should serve as a go-grab-it destination for regularly autobuilt images for the Raspberry Pi family. Of course, today you will get an early view of the site. I plan to fix the lack of https due to a mistake on my part WRT the processes at my hosting provider, do some testing in the hardware I have handy (and bless + gpg-sign some images as tested), migrate and update the information in the Debian Wiki, etc. Oh! And I hope to get good news on the Raspberry 4 front, as I know work is actively underway to achieve it.

Gibbsdavidl/CatterPlots

Did you ever wish you could make scatter plots with cat shaped points? Now you can! - Gibbsdavidl/CatterPlots

What is the best tool to use for drawing vector pictures? For me and probably for many others, the answer is pretty obvious: Illustrator, or, maybe, Inkscape.

A coloring book to help folks understand how SELinux works. - mairin/selinux-coloring-book

The EURion constellation (also known as Omron rings[1] or doughnuts[2]) is a pattern of symbols incorporated into a number of banknote designs worldwide since about 1996. It is added to help imaging software detect the presence of a banknote in a digital image. Such software can then block the user from reproducing banknotes to prevent counterfeiting using colour photocopiers. According to research from 2004, the EURion constellation is used for colour photocopiers but probably not used in computer software.[3] It has been reported that Adobe Photoshop will not allow editing of an image of a banknote, but in some versions this is believed to be due to a different, unknown digital watermark rather than the EURion constellation.[4][3]

This huge collection of non-scary optical illusions and fascinating visual phenomena emphasizes interactive exploration, beauty, and scientific explanation.

Generated photos are created from scratch by AI systems. All images can be used for any purpose without worrying about copyrights, distribution rights, infringement claims, or royalties.

Dokumentarfilm ber die Rangierer im Bahnhof Dresden-Friedrichstadt in der DDR aus dem Jahr 1984.

Il termine sardo femina accabadora, femina agabbad ra o, pi comunemente, agabbadora o accabadora (s'agabbad ra, lett. "colei che finisce", deriva dal sardo s'acabbu, "la fine" o dallo spagnolo acabar, "terminare") denota la figura storicamente incerta di una donna che si incaricava di portare la morte a persone di qualunque et , nel caso in cui queste fossero in condizioni di malattia tali da portare i familiari o la stessa vittima a richiederla. In realt non ci sono prove di tale pratica, che avrebbe riguardato alcune regioni sarde come Marghine, Planargia e Gallura[1]. La pratica non doveva essere retribuita dai parenti del malato poich il pagare per dare la morte era contrario ai dettami religiosi e della superstizione.

Alright the people have spoken and they want more cat genetics. So, I present to you all "Cat Coat Genetics 101: A Tweetorial", feat. pics of many real life cats (for science, of course...this baby is Caterpillar).

Review: Beyond the Galaxy, by Ethan Siegel

Publisher:	World Scientific
Copyright:	2016
ISBN:	981-4667-16-1
Format:	Kindle
Pages:	370

In the preface of this book, Ethan Siegel recounts his experience as a new college professor in 2009, thrilled to learn that he would be teaching the college's introductory astronomy class. The only disappointment was that he could not find a textbook that described astronomy the way that he wanted to teach it. Siegel did not want to simply describe the current astronomical understanding. He wanted to start at the beginning and tell a story. What questions did we start with? How did we answer them? What new questions did those answers provoke? I enjoyed Sabine Hossenfelder's Lost in Math, but I'm even happier that she included in it a recommendation of Beyond the Galaxy as a good introduction to modern astronomy. I am completely in agreement with Siegel: Astronomy is interesting however it is described, but the best presentation for the interested lay person who does not intend to become a professional astronomy is chronological. (I feel the same way about physics and mathematics.) The narrative structure of scientific discovery draws me in every time. It's so satisfying to see our knowledge growing, breakthrough by breakthrough, only to meet the next puzzling inconsistency. It also is a natural fit for bringing someone up to speed on a field, since the history of the field starts with simpler questions and problems, and the complications of later discoveries build on the gaps left by earlier theories. Siegel tells that story well. Beyond the Galaxy starts with observations of seasonal changes in the path of the Sun through the sky and phases of the moon, quickly moves on to Eratosthenes's calculation of the circumference of the Earth, and continues at pace through early astronomy. The first chapter brings the reader up to the start of the 20th century, after which Siegel slows down and spends the remaining 10 chapters on the last 100 years: special and general relativity, the expansion of the universe, the Big Bang, dark matter, dark energy, the inflationary period, and more. For me, this was perfect. The story of early astronomy and the fight over the heliocentric model of the universe is worth telling, but it's been told many times before and features prominently in history books outside of science classes. The weight of material in this book matched my interest: What new developments have there been after general relativity and the Big Bang theory? What inconsistencies are dark matter and dark energy explaining? What is the inflationary period and how did it modify the Big Bang theory? (My half-formed impression of this part of astronomy from news articles turned out to be almost entirely wrong.) And how do we know all of this? The question of how we know as much as we do about the early origins of the universe turned out to be far more interesting than I had realized. It's one of those pieces of science where, when given only the conclusions, it's hard to imagine how our theories could be as complete as they are. Siegel is a bit repetitive in how he talks about theory development and occasionally skims over the details to avoid getting too deep into techniques and math, but he does a great job explaining the predictions of a theory, the design of experiments to prove or disprove those predictions, and the implications for the boundaries of what we know. This is the first time someone has explained the theorized origin of matter-antimatter asymmetry in sufficient detail that I was able to understand and internalize it. Dark matter and dark energy are the current topics of astronomy that get the most press, and the coverage of both is very good here. I was particularly fascinated by the link between dark matter and the superstructures of the universe that we've discovered. Astronomy does scale in a way that no other science can manage, and the scale of structure we've discovered and been able to map has gone up considerably since the last time I refreshed my astronomical knowledge. If you're looking for a math-light, comprehensive introduction to modern astronomy, I can wholeheartedly recommend this book. That goes double if you, like me, prefer a chronological view of scientific discovery so that you can understand what questions people were trying to answer and how our understanding changed over time. One note on format: Astronomy being what it is, this book is very heavy on pictures. It is not at all suitable for a dedicated ebook reader. The Kindle tries, but the combination of a small screen and black and white e-ink fail miserably. I switched to reading on a tablet, and that was a far better experience. The Kindle app still struggles to put the figures next to the text that discusses them, but that's a typesetting problem that I often have with physical books as well. If you don't have a tablet and you aren't willing to read on a computer screen, you probably want a physical copy of this one (which, sadly, means academic textbook pricing). Rating: 8 out of 10

In Haskell (and many other functional languages) it's quite common for the implementation of a function to reference one less argument than the type signature declares:

g :: foo -> bar
g = length . reverse

Known as point-free style by proponents (and pointless style by opponents), the function definition is a list of other functions which are composed together to produce a composite requiring a single argument: the missing one. Sometimes I come across the opposite: a function with a type signature and a definition beginning in a way similar to this

f :: foo -> bar
f a b =  

That is, the type signature declares that the function accepts a single argument of type foo, but the definition is in terms of two arguments. Huh? What's going on is that bar is really a type synonym for another function. In other words

type bar = baz -> qux

So we can consider f to actually be

f :: foo -> baz -> qux

With this definition of bar, in the definition of f above, the second parameter b maps to the type baz. When I've encountered this, I strongly suspect what has happened is the function was originally written with the longer type signature, and later on the type synonym was declared and function signatures updated to use it. I'm not aware of anyone advocating for this style.

I m working on trying to get a Qualcomm IPQ8064 device working properly. I d got as far as an extremely hacked up chain of networking booting and the serial console working, so the next stage was to try and get a basic userland in place to try and make poking things a bit easier. While I have a cross-compiling environment all setup (that s how I m building my kernels) I didn t really want to get into something complicated just to be able to poke around sysfs etc. I figured I could use a static BusyBox in an initramfs. I was right, but there were a couple of hiccups along the way so I m writing it up so I remember next time. First, I cheated and downloaded a prebuilt static binary from https://busybox.net/downloads/binaries/ (very convenient, thanks) - the IPQ8064 is a dual core ARMv7 so I used busybox-armv7l. There were various sites with init scripts to go along with this; I ended up with a variation of Star Brilliant s gist:

Minimal init script

#!/bin/busybox sh
busybox mkdir -p /dev /etc /proc /root /sbin /sys /usr/bin /usr/sbin
busybox mount -t proc proc /proc
busybox mount -t sysfs sys /sys
busybox mount -t devtmpfs dev /dev
echo Starting up...
echo ttyMSM0::respawn:/sbin/getty -L ttyMSM0 115200 vt100 >> /etc/inittab
echo Login with root and no password. > /etc/issue
echo >> /etc/issue
echo root::0:0:root:/root:/bin/sh > /etc/passwd
busybox mdev -s
busybox --install
hostname localhost
ip link set lo up
echo 5 > /proc/sys/kernel/printk
exec /linuxrc

busybox and the init script aren t sufficient. If you have any problems then you re going to want a console device. Otherwise you ll do what I did, forget to change one of the tty references in the script to the right device, and spend too long trying to figure out why you re not getting any output as soon as you start running userspace. It turns out that CONFIG_DEVTMPFS_MOUNT isn t sufficient for the initramfs (the Kconfig help even tells you that). So I need to create a /dev/console device file inside the initramfs too. And I don t build as root (and you shouldn t either) which makes creating a device node hard. It s ok though, because the Linux kernel doesn t need you to be root to build it, and it has a default initramfs with a console device in it. This is helpfully generated using usr/gen_init_cpio, which takes a file defining what you want to put in the cpio file that becomes your initramfs. I used the following:

Minimal initramfs creation file

# Simple busybox based initramfs
dir /dev 0755 0 0
nod /dev/console 0600 0 0 c 5 1
dir /root 0700 0 0
dir /bin 0755 0 0
dir /sbin 0755 0 0
file /init basic-init 0755 0 0
file /bin/busybox busybox-armv7l 0755 0 0

All that then needs to be done is linux/usr/gen_init_cpio initramfs.list > initramfs.cpio and the resulting initramfs.cpio is suitable for inclusion in your kernel. The precompiled binaries have a lot of stuff enabled, which makes for a pretty useful debugging environment with fairly minimal work.

Today at the ACLU, we released a whitepaper discussing how to evaluate some novel cryptographic schemes that are being considered to provide technology-assisted contact-tracing in the face of the COVID-19 pandemic. The document offers guidelines for thinking about potential schemes like this, and what kinds of safeguards we need to expect and demand from these systems so that we might try to address the (hopefully temporary) crisis of the pandemic without also creating a permanent crisis for civil liberties. The proposals that we're seeing (including PACT, DP^3T, TCN, and the Apple/Google proposal) work in pretty similar ways, and the challenges and tradeoffs there are remarkably similar to Internet protocol design decisions. Only now in addition to bytes and packets and questions of efficiency, privacy, and control, we're also dealing directly with risk of physical harm (who gets sick?), society-wide allocation of scarce and critical resources (who gets tested? who gets treatment?), and potentially serious means of exercising powerful social control (who gets forced into quarantine?). My ACLU colleague Jon Callas and i will be doing a Reddit AMA in r/Coronavirus tomorrow starting at 2020-04-17T19:00:00Z (that's 3pm Friday in TZ=America/New_York) about this very topic, if that's the kind of thing you're into.

Like each month, here comes a report about the work of paid contributors to Debian LTS. Individual reports In March, 252 work hours have been dispatched among 14 paid contributors. Their reports are available:

• Abhijith PA did 16.0h (out of 14h assigned and 2h from February).
• Ben Hutchings did 12.25h (out of 20h assigned and 0.75h from February), thus carrying over 8.5h to April.
• Brian May did 10h (out of 10h assigned).
• Chris Lamb did 18h (out of 18h assigned).
• Dylan A ssi did 6h (out of 6h assigned).
• Emilio Pozuelo Monfort did 19.5h (out of 30h assigned and 6.75h from February), thus carrying over 17.25h to April.
• Hugo Lefeuvre gave back the 12h he got assigned.
• Markus Koschany did 10h (out of 30h assigned and 18.75h from February), thus carrying over 38.75h to April.
• Mike Gabriel did 10.25h (out of 8h assigned and 2.25h from February).
• Ola Lundqvist did 6h (out of 12h assigned and 2.5h from February), thus carrying over 8.5h to April.
• Roberto C. S nchez did 6.25h (out of 8h assigned), and gave back the remaining 1.75h.
• Sylvain Beucler did 30h (out of 30h assigned).
• Thorsten Alteholz did 30h (out of 30h assigned).
• Utkarsh Gupta did 24h (out of 24h assigned).

Evolution of the situation March was a strange month for many people all over the globe. Here we ll just express our hopes that you are and will be well! LTS gained a new contributor in March, Anton Gladky, however he then decided to become active later this year. Similarly Hugo Lefeuvre notified us that he ll be inactive in April. In case you missed it (or missed to act), please read this post about keeping Debian 8 Jessie alive for longer than 5 years. If you expect to have Debian 8 servers/devices running after June 30th 2020, and would like to have security updates for them, please get in touch with Freexian. Hurry up: the end of Jessie LTS is coming in less than three months! The security tracker currently lists 25 packages with a known CVE and the dla-needed.txt file has 23 packages needing an update. Thanks to our sponsors New sponsors are in bold.

• Platinum sponsors:
• TOSHIBA (for 55 months)
• GitHub (for 45 months)
• Civil Infrastructure Platform (CIP) (for 22 months)
• Gold sponsors:
• Blablacar (for 70 months)
• Roche Diagnostics International AG (for 65 months)
• Linode (for 59 months)
• Babiel GmbH (for 49 months)
• Plat Home (for 48 months)
• University of Oxford (for 4 months)
• Silver sponsors:
• The Positive Internet Company (for 71 months)
• Domeneshop AS (for 70 months)
• Nantes M tropole (for 64 months)
• Univention GmbH (for 56 months)
• Universit Jean Monnet de St Etienne (for 56 months)
• Ribbon Communications, Inc. (for 49 months)
• Exonet B.V. (for 39 months)
• Leibniz Rechenzentrum (for 33 months)
• CINECA (for 23 months)
• Minist re de l Europe et des Affaires trang res (for 17 months)
• Cloudways Ltd (for 6 months)
• Dinahosting SL (for 4 months)
• Bronze sponsors:
• Seznam.cz, a.s. (for 71 months)
• Evolix (for 70 months)
• MyTux (for 70 months)
• Intevation GmbH (for 67 months)
• Linuxhotel GmbH (for 67 months)
• Daevel SARL (for 66 months)
• Bitfolk LTD (for 65 months)
• Megaspace Internet Services GmbH (for 65 months)
• Greenbone Networks GmbH (for 64 months)
• NUMLOG (for 64 months)
• WinGo AG (for 63 months)
• Ecole Centrale de Nantes LHEEA (for 59 months)
• Sig-I/O (for 57 months)
• Entr ouvert (for 54 months)
• Adfinis SyGroup AG (for 52 months)
• GNI MEDIA (for 46 months)
• Laboratoire LEGI UMR 5519 / CNRS (for 46 months)
• Tesorion (for 46 months)
• Bearstech (for 38 months)
• LiHAS (for 38 months)
• People Doc (for 34 months)
• Catalyst IT Ltd (for 32 months)
• Supagro (for 28 months)
• Demarcq SAS (for 26 months)
• TrapX Security (for 23 months)
• Universit Grenoble Alpes (for 12 months)
• TouchWeb SAS (for 4 months)
• SPiN AG

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

Debian.org added support for DKIM in 2020. To configure this on my side, I had to do the following, on top of my email configuration.

1. add this line to /etc/opendkim/signing.table:

   *@debian.org marcos-debian.anarcat.user
   

2. add this line to /etc/opendkim/key.table:

   marcos-debian.anarcat.user debian.org:marcos-debian.anarcat.user:/etc/opendkim/keys/marcos-debian.anarcat.user.private
   

   Yes, that's quite a mouthful! That magic selector is long in that way because it needs a special syntax (specifically the .anarcat.user suffix) for Debian to be happy. The -debian string is to tell me where the key is published. The marcos prefix is to remind me where the private is used.
3. generate the key with:

   opendkim-genkey --directory=/etc/opendkim/keys/ --selector=marcos-debian.anarcat.user --domain=debian.org --verbose
   

   This creates the DNS record in /etc/opendkim/keys/marcos-debian.anarcat.user.txt (alongside the private key in .key).
4. restart OpenDKIM:

   service opendkim restart
   

   The DNS record will look something like this:

   marcos-debian.anarcat.user._domainkey   IN  TXT ( "v=DKIM1; h=sha256; k=rsa; "
   "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtKzBK2f8vg5yV307WAOatOhypQt3ANQ95iDaewkVehmx42lZ6b4PzA1k5DkIarxjkk+7m6oSpx5H3egrUSLMirUiMGsIb5XVGBPFmKZhDVmC7F5G1SV7SRqqKZYrXTufRRSne1eEtA31xpMP0B32f6v6lkoIZwS07yQ7DDbwA9MHfyb6MkgAvDwNJ45H4cOcdlCt0AnTSVndcl"
   "pci5/2o/oKD05J9hxFTtlEblrhDXWRQR7pmthN8qg4WaNI4WszbB3Or4eBCxhUdvAt2NF9c9eYLQGf0jfRsbOcjSfeus0e2fpsKW7JMvFzX8+O5pWfSpRpdPatOt80yy0eqpm1uQIDAQAB" )  ; ----- DKIM key marcos-debian.anarcat.user for debian.org
   

5. The "p=MIIB..." string needs to be joined together, without the quotes and the p=, and sent in a signed email to changes@db.debian.org:

   -----BEGIN PGP SIGNED MESSAGE-----
   dkimPubKey: marcos.anarcat.user MIIB[...]
   -----BEGIN PGP SIGNATURE-----
   [...]
   

6. Wait a few minutes for DNS to propagate. You can check if they have with:

   host -t TXT marcos-debian.anarcat.user._domainkey.debian.org nsp.dnsnode.net
   

   (nsp.dnsnode.net being one of the NS records of the debian.org zone.)

If all goes well, the tests should pass when sending from your server as anarcat@debian.org.

Testing Test messages can be sent to dkimvalidator, mail-tester.com or check-auth@verifier.port25.com. Those tools will run Spamassassin on the received emails and report the results. What you are looking for is:

• -0.1 DKIM_VALID: Message has at least one valid DKIM or DK signature
• -0.1 DKIM_VALID_AU: Message has a valid DKIM or DK signature from author's domain
• -0.1 DKIM_VALID_EF: Message has a valid DKIM or DK signature from envelope-from domain

If one of those is missing, then you are doing something wrong and your "spamminess" score will be worse. The latter is especially tricky as it validates the "Envelope From", which is the MAIL FROM: header as sent by the originating MTA, which you see as from=<> in the postfix lost. The following will happen anyways, as soon as you have a signature, that's normal:

• 0.1 DKIM_SIGNED: Message has a DKIM or DK signature, not necessarily valid

And this might happen if you have a ADSP record but do not correctly sign the message with a domain field that matches the record:

• 1.1 DKIM_ADSP_ALL No valid author signature, domain signs all mail

That's bad and will affect your spam core badly. I fixed that issue by using a wildcard key in the key table:

--- a/opendkim/key.table
+++ b/opendkim/key.table
@@ -1 +1 @@
-marcos anarc.at:marcos:/etc/opendkim/keys/marcos.private
+marcos %:marcos:/etc/opendkim/keys/marcos.private

References

• Ubuntu documentation
• Debian wiki
• linode tutorial, also recommends rotating keys every 6 months
• jak-linux: uses rspamd instead of opendkim, and PostSRSd
• Gio's tutorial

This is a copy of a subset of my more complete email configuration.

Welcome to gambaru.de. Here is my monthly report (+ the first week in April) that covers what I have been doing for Debian. If you re interested in Java, Games and LTS topics, this might be interesting for you. I am sure I am not the only one who will remember March 2020 in the future as a month nobody was really fond of. I was mostly occupied with non-Debian work and managed to get ill in the same week I wanted to celebrate my birthday but it didn t matter anyway because of ehm quarantine and social distancing. Maybe next year March will be great again.
Debian Games

• I was notified by Minetest upstream that Debian did not build the game with CMAKE_BUILD_TYPE=Release or that we simply missed the -DNDEBUG compiler flag which in turn could cause some unexepected runtime errors. I quickly fixed the problem and backported the change to buster-backports. There is another pending merge request about build-depending on libspatialindex-dev. I was told it will speed up some processes on the server side, so I wanted to give it a try.
• I fixed RC bug #954722 in spring, the RTS game engine. A change in GCC caused yet another FTBFS but was rather easy to fix.
• I sponsored jag and runescape for Carlos Donizete Froes. Despite being such a trivial helper script for downloading the runescape launcher, the latter caused some controversy. Now it looks like all problems can be resolved and I expect another upload with bug fixes in April.
• Last but not least I packaged a new upstream release of extremetuxracer, the racing game with Tux for all the family.

Debian Java

• I worked on new releases of wildfly-common, undertow, jboss-threads, jboss-xnio, libsmali-java and apktool.
• I uploaded a security update of checkstyle to Stretch and Buster and prepared another point update for Buster to fix a bug in el-api, websocket-api and jsp-api when libservlet3.1-java was upgraded from Stretch to Buster.
• A missing jar file on the CLASSPATH in commons-configuration2 made mediathekview and other packages FTBFS (#955755) but it also motivated me to remove the unnecessary update check in MediathekView on every startup because it may take a while until I can upgrade this program again.
• I also applied a patch by Bas Couwenberg for OpenJFX to fix a FTBFS bug due to the -Werror=deprecated-declarations flag.

Misc

• While I am still waiting for ublock-origin being processed in the NEW queue, I packaged the latest version of another browser addon, https-everywhere.

Debian LTS This was my 49. month as a paid contributor and I have been paid to work 10 hours on Debian LTS, a project started by Rapha l Hertzog. In that time I did the following:

• I worked on Tomcat 8 in Jessie and prepared patches for CVE-2020-1938, CVE-2020-1935 and CVE-2019-17563. I am working together with Abhihith PA who is currently reviewing them. Especially CVE-2020-1938 requires careful attention because of new options to secure the AJP port and protocol. In contrast to Wheezy, Tomcat in Jessie will be supported at least for another year, so it makes sense to apply the upstream changes for hardening the setup.
• I prepared another Tomcat 8 update for Stretch which will be released this month.

ELTS Extended Long Term Support (ELTS) is a project led by Freexian to further extend the lifetime of Debian releases. It is not an official Debian project but all Debian users benefit from it without cost. The current ELTS release is Debian 7 Wheezy . This was my 22. month and I have been paid to work 9 hours on ELTS.

• I investigated all identified source packages from last month. They are supported but embed external software, sometimes affected by unfixed security vulnerabilities. After a closer inspection I discovered that most packages were either affected only by minor issues, which did not warrant an extra update, or they were not even affected at all because they linked against system libraries. However zlib, apache2 and php5 contained embedded and unfixed code copies of expat and file and zlib s miniunzip program was still prone to a directory traversal attack. I fixed the latter in ELA-222-1. The apache2 update will follow shortly and there is ongoing work for PHP5 anyway which allows us to fix the latest reported vulnerabilites and address the embedded code copy issues together in one update.

Thanks for reading and see you next time.