Friday, 14 January 2022
06:40 PM
Insight [Futility Closet] 06:40 PM, Friday, 14 January 2022 07:00 PM, Friday, 14 January 2022
Conducting a workshop on paper folding and geometry for a group of gifted 10-year-olds in 1977, Santa Clara University mathematician Jean Pedersen passed around a collection of polyhedra and asked the students which shapes they’d classify as “regular.” To her surprise, the only one who chose the five platonic solids was Peter Wilson, a blind student.
The others immediately responded, “That’s not fair, Peter’s blind!” So Pedersen agreed to let them try again, this time feeling the models with their eyes closed. Now every student chose the five platonic solids.
“I’m not sure what all the ramifications of these events are,” Pedersen wrote in a letter to the Mathematical Intelligencer, “but begin with this: we can perceive things with just our hands that we miss when we use both our eyes and our hands. Sometimes less really is more.”
(Jean Pedersen, “Seeing the Idea,” Mathematical Intelligencer 20:4 [Fall 1998], 6.)
06:01 PM
Debian Social Team: Some site updates [Planet Debian] 06:01 PM, Friday, 14 January 2022 06:40 PM, Friday, 14 January 2022
- Pleroma has been updated to version 2.4.1. We also suffered some downtime during the 11th of January. Upgrading to the latest version fixed our issues.
- Peertube has been upgraded to version 4.0.0.
- Jitsi Meet has been upgraded to version 2.0.6726.
- Mjolnr has been upgraded to 1.2.1.
- Our upgrade to bullseye is complete, we haven’t encountered any problems upgrading to bullseye \o/.
04:52 PM
[$] Struct slab comes to 5.17 [LWN.net] 04:52 PM, Friday, 14 January 2022 05:20 PM, Friday, 14 January 2022
The ongoing memory folio work has caused ripples through much of the kernel and inspired a few side projects, one of which was the removal of slab-specific fields from struct page. That work has been pulled into the mainline for the 5.17 kernel release; it is thus a good time to catch up with the status of struct slab and why this work is important.
03:55 PM
Rust 1.58.0 released [LWN.net] 03:55 PM, Friday, 14 January 2022 04:00 PM, Friday, 14 January 2022
Version 1.58.0 of the Rust programming language is available.
Rust 1.58 brings captured identifiers in format strings, a change to the Command search path on Windows, more #[must_use] annotations in the standard library, and some new library stabilizations.
More information on "captured identifiers" (the ability to use in-scope variables directly in format strings) can be found on this page.
03:55 PM
Streamlining Inkscape for the masses (Libre Arts) [LWN.net] 03:55 PM, Friday, 14 January 2022 04:00 PM, Friday, 14 January 2022
Libre Arts has posted an interview with four Inkscape developers.
From what I understand, what helped was finally porting the user interface from GTK2 to GTK3. It was just a huge task and brought many regressions, some of them are still in even after 2 years. Just to compare, 1.0 was in alpha state for 1.5 years; but for 1.1, it was just 3 months. So if you want a faster release, don’t port your app. Too late for us though! And we probably need to port again to GTK4 now if we want to fix performance regressions.
03:10 PM
Security updates for Friday [LWN.net] 03:10 PM, Friday, 14 January 2022 03:20 PM, Friday, 14 January 2022
Security updates have been issued by Debian (firefox-esr), Fedora (cockpit, python-cvxopt, and vim), openSUSE (libmspack), Oracle (webkitgtk4), Scientific Linux (firefox and thunderbird), SUSE (kernel and libmspack), and Ubuntu (firefox and pillow).
02:28 PM
A History of Modern Computer Crashing [] 02:28 PM, Friday, 14 January 2022 07:20 PM, Friday, 14 January 2022
Steven Sinofsky wrote a good (and long) essay about why and how computers crash less often than they used to. Sinofsky says in part:
… In the early days of PCs before Windows, crashes froze the computer—nothing worked, not even banging on the keyboard. The only recourse was to turn the computer off and start over, losing unsaved work and causing a potentially extreme emotional moment. In the earliest days of automobiles, drivers had to be mechanics for fear of getting stranded by flaky engines—PCs were sort of like that….
The situation improved dramatically, Sinofosky explains, after software developers became able to — and set up ways to — gather crash info rapidly, and somewhat reliably, using the internet.
We began to see that while there were many different crashes, the majority of them could be attributed to a small number of buckets. In other words, if we fixed a few bugs we eliminated a huge number of crashes, dramatically improving the reliability of the product for everyone….
People used to ask if clicking on that “Send Error Report” button did any good. It absolutely did.
06:37 AM
For Short (local copy) [Futility Closet] 06:37 AM, Friday, 14 January 2022 07:00 AM, Sunday, 16 January 2022
Henri Gatien Bertrand, Napoleon’s companion during his exile on Saint Helena, kept an impenetrable diary. The entry for January 20, 1821, reads:
N. so. le mat. en cal: il. déj. bi. se. trv. un peu fat; le so. il est f.g.
It’s not code, just extremely abbreviated French. Interpreter Paul Fleuriot de Langle referred to his work as “translating from French into French — the singular sport and strange pastime.” He rendered the passage above as:
Napoléon sort le matin en calèche. Il déjeune bien, se trouve un peu fatigué; le soir, il est fort gai
Or “Napoleon goes out in the morning in a carriage. He lunches well, finds himself a little tired; in the evening, he is very gay.” Not very incriminating — perhaps Bertrand was just trying to save paper.
(From David Kahn’s The Codebreakers, 1967.)
06:00 AM
iDIRECT – disentangling direct from indirect relationships in association networks [RNA-Seq Blog] 06:00 AM, Friday, 14 January 2022 01:20 PM, Friday, 14 January 2022
Networks are vital tools for understanding and modeling interactions in complex systems in science and engineering, and direct and indirect interactions are pervasive in all types of networks. However, quantitatively disentangling direct and indirect relationships in networks remains a formidable task. A team led by researchers at the University of Oklahoma has developed a framework, called iDIRECT (Inference of Direct and Indirect Relationships with Effective Copula-based Transitivity), for quantitatively inferring direct dependencies in association networks. Using copula-based transitivity, iDIRECT eliminates/ameliorates several challenging mathematical problems, including ill-conditioning, self-looping, and interaction strength overflow. With simulation data as benchmark examples, iDIRECT showed high prediction accuracies. Application of iDIRECT to reconstruct gene regulatory networks in Escherichia coli also revealed considerably higher prediction power than the best-performing approaches in the DREAM5 (Dialogue on Reverse Engineering Assessment and Methods project, #5) Network Inference Challenge. In addition, applying iDIRECT to highly diverse grassland soil microbial communities in response to climate warming showed that the iDIRECT-processed networks were significantly different from the original networks, with considerably fewer nodes, links, and connectivity, but higher relative modularity. Further analysis revealed that the iDIRECT-processed network was more complex under warming than the control and more robust to both random and target species removal (P < 0.001). As a general approach, iDIRECT has great advantages for network inference, and it should be widely applicable to infer direct relationships in association networks across diverse disciplines in science and engineering.
Overview of iDIRECT
(A) An association network contains both direct (blue) and indirect (red) associations. Indirect associations include spurious links (solid lines) and overestimated direct links (dotted lines). (B) iDIRECT uses a copula-based addition ⊕ to combine association between two nodes through different paths, ensuring the interaction strengths to be within the range [0,1]. (C) iDIRECT introduces a transitivity matrix Ti,kj (association between k and j excluding paths passing i) and uses SikTi,kj to calculate indirect association strength between i and j, eliminating spurious self-looping paths like i–k–i–j. (D) iDIRECT uses nonlinear solvers to obtain direct association strengths of each link, without inverting the ill-conditioned association matrix. (E) Overall workflow for iDIRECT.
05:00 AM
small RNA sequencing suggests BPA exposure of the placenta could affect fetal brain development [RNA-Seq Blog] 05:00 AM, Friday, 14 January 2022 01:20 PM, Friday, 14 January 2022
In a new study, scientists at the University of Missouri demonstrate the direct transmission of bisphenol A (BPA) from a mother to her developing child via the placenta could negatively impact fetal brain development. Cheryl Rosenfeld, a professor of biomedical sciences in the College of Veterinary Medicine, and colleagues propose more attention should be placed on how this temporary organ affects fetal brain development.
“The placenta is only a temporary organ that aids in the exchange of nutrients and waste between mother and child during pregnancy, but how the placenta responds to toxicants like BPA during pregnancy can lead to long-term health consequences,” Rosenfeld said. “We focused on the role of microRNAs within the placenta, which are known to be key mediators in regulating cellular functions, including neural development, and the identification of certain markers for cancer.”
Rosenfeld suspects the microRNAs are playing a role in how the effects of BPA exposure can lead to neurological disorders later in life.
“These microRNAs can be packaged inside extracellular vesicles and can be transported to distant organs within the body,” Rosenfeld said. “We’re assuming that by changing the pattern of microRNAs in the placenta, these small molecules can then reach the brain, resulting in harmful effects. Even before the brain’s neurons are developed, these microRNA packages may already be guiding fetal brain development. These changes may even be different in female versus male fetuses.”
BPA is used in many household items such as plastic water bottles and food containers, and the epoxy coating of metal food cans. Exposure can occur during the simple act of microwaving food inside polycarbonate plastic food containers. While recent efforts have begun toward making products “BPA free,” the more than decade-long debate surrounding what’s considered safe levels of BPA exposure continues. Numerous studies have looked into possible related health consequences, including neurobehavioral disorders, diabetes, obesity and various reproductive deficiencies.
Rosenfeld believes microRNAs’ changes in the placenta could also be used as an early diagnostic biomarker for BPA exposure.
“By identifying the relationship between these microRNAs and fetal brain development through BPA exposure, targeted therapies could eventually be developed to help prevent or reverse some of the harmful effects of BPA exposure that occur due to these microRNAs,” Rosenfeld said.
Future plans for this work include examining the relationship between the placenta and the brain outside of the body through using cell culture systems.
This latest discovery continues a more than decade-long interest by Rosenfeld on the effects of BPA exposure. Her most recent focus on the relationship between the placenta and the brain could help scientists with developing a foundation for an early step in translational medicine, or research that aims to improve human health by determining the relevance of animal science discoveries to people.
Source – University of Missouri
02:17 AM
Norbert Preining: Future of “my” packages in Debian [Planet Debian] 02:17 AM, Friday, 14 January 2022 02:40 AM, Friday, 14 January 2022
After having been (again) demoted (timed perfectly to my round birthday!) based on flimsy arguments, I have been forced to rethink the level of contribution I want to do for Debian. Considering in particular that I have switched my main desktop to dual-boot into Arch Linux (all on the same btrfs fs with subvolumes, great!) and have run Arch now for several days exclusively, I think it is time to review the packages I am somehow responsible for (full list of packages).
After about 20 years in Debian, time to send off quite some stuff that has accumulated over time.
KDE/Plasma, frameworks, Gears, and related packages
All these packages are group maintained, so there is not much to worry about. Furthermore, a few new faces have joined the team and are actively working on the packages, although mostly on Qt6. I guess that with me not taking action, frameworks, gears, and plasma will fall back over time (frameworks: Debian 5.88 versus current 5.90, gears: Debian 21.08 versus current 21.12, plasma uptodate at the moment).
With respect to my packages on OBS, they will probably also go stale over time. Using Arch nowadays I lack the development tools necessary to build Debian packages, and above all, the motivation.
I am sorry for all those who have learned to rely on my OBS packages over the last years, bringing modern and uptodate KDE/Plasma to Debian/stable, please direct your complaints at the responsible entities in Debian.
Cinnamon
As I have written already here, I have reduced my involvement quite a lot, and nowadays Fabio and Joshua are doing the work. But both are not even DM (AFAIR) and I am the only one doing uploads (I got DM upload permissions for it). But I am not sure how long I will continue doing this. This also means that in the near future, Cinnamon will also go stale.
TeX related packages
Hilmar has DM upload permissions and is very actively caring for the packages, so I don’t see any source of concern here. New packages will need to find a new uploader, though. With myself also being part of upstream, I can surely help out in the future with difficult problems.
Calibre and related packages
Yokota-san (another DM I have sponsored) has DM upload permissions and is very actively caring for the packages, so also here there is not much of concern.
Onedrive
This is already badly outdated, and I recommend using the OBS builds which are current and provide binaries for Ubuntu and Debian for various versions.
ROCm
Here fortunately a new generation of developers has taken over maintenance and everything is going smoothly, much better than I could have done, yeah to that!
Qalculate related packages
These are group maintained, but unfortunately nobody else but me has touched the repos for quite some time. I fear that the packages will go stale rather soon.
isync/mbsync
I have recently salvaged this package, and use it daily, but I guess it needs to be orphaned sooner or later.
CafeOBJ
While I am also part of upstream here, I guess it will be orphaned.
Julia
Julia is group maintained, but unfortunately nobody else but me has touched the repo for quite some time, and we are already far behind the normal releases (and julia got removed from testing). While go stale/orphaned. I recommend installing upstream binaries.
python-mechanize
Another package that is group maintained in the Python team, but with only me as uploader I guess it will go stale and effectively be orphaned soon.
xxhash
Has already by orphaned.
qpdfview
No upstream development, so not much to do, but will be orphaned, too.
01:03 AM
Dirk Eddelbuettel: Rcpp 1.0.8: Updated, Strict Headers [Planet Debian] 01:03 AM, Friday, 14 January 2022 02:40 AM, Friday, 14 January 2022
The Rcpp team is thrilled to share the news of the newest release 1.0.8 of Rcpp which hit CRAN today, and has already been uploaded to Debian as well. Windows and macOS builds should appear at CRAN in the next few days. This release continues with the six-months cycle started with release 1.0.5 in July 2020. As a reminder, interim ‘dev’ or ‘rc’ releases will alwasys be available in the Rcpp drat repo; this cycle there were once again seven (!!) – times two as we also tested the modified header (more below). These rolling release tend to work just as well, and are also fully tested against all reverse-dependencies.
Rcpp has become the most popular way of enhancing R with C or C++ code. Right now, around 2478 packages on CRAN depend on Rcpp for making analytical code go faster and further, along with 242 in BioConductor.
This release finally brings a change we have worked on quite a
bit over the last few months. The idea of enforcing the
setting of STRICT_R_HEADERS was prososed years ago
in 2016
and again in
2018. But making such a chance against a widely-deployed code
base has repurcussions, and we were not ready then. Last April,
this was revisited in issue
#1158. Over the course of numerous lengthy runs of tests of a
changed Rcpp package
against (essentially) all reverse-dependencies (i.e.
packages which use Rcpp) we
identified ninetyfour packages in total which needed a change. We
provided either a patch we emailed, or a GitHub pull request, to
all ninetyfour. And we are happy to say that eighty cases were
resolved via a new CRAN upload, with a seven more having merged the
pull request but not yet uploaded.
Hence, we could make the case to CRAN (who were always CC’ed on the monthly ‘nag’ emails we sent to maintainers of packages needing a change) that an upload was warranted. And after a brief period for their checks and inspection, our January 11 release of Rcpp 1.0.8 arrived on CRAN on January 13.
So with that, a big and heartfelt Thank You! to all eighty maintainers for updating their packages to permit this change at the Rcpp end, to CRAN for the extra checking, and to everybody else who I bugged with the numerous emails and updated to the seemingly never-ending issue #1158. We all got this done, and that is a Good Thing (TM).
Other than the aforementioned change which will not
automatically set STRICT_R_HEADERS (unless opted out
which one can), a number of nice pull request by a number of
contributors are included in this release:
- Iñaki generalized use of finalizers for external pointers in #1180
- Kevin ensured include paths are always quoted in #1189
- Dirk added new headers to allow a more fine-grained choice of Rcpp feature for faster builds in #1191
- Travers Ching extended the function signature generator to allow for a default R argument in #1184 and #1187
- Dirk extended documentation, removed old example code, updated references and refreshed CI setup in several PRs (see below)
The full list of details follows.
Changes in Rcpp release version 1.0.8 (2022-01-11)
Changes in Rcpp API:
STRICT_R_HEADERSis now enabled by default, see extensive discussion in #1158 closing #898.A new
#defineallows default setting of finalizer calls for external pointers (Iñaki in #1180 closing #1108).
Rcpp:::CxxFlags()now quotes the include path generated, (Kevin in #1189 closing #1188).New header files
Rcpp/Light,Rcpp/Lighter,Rcpp/Lightestand defaultRcpp/Rcppfor fine-grained access to features (and compilation time) (Dirk #1191 addressing #1168).Changes in Rcpp Attributes:
Changes in Rcpp Documentation:
Changes in Rcpp Deployment:
Thanks to my CRANberries, you
can also look at a diff
to the previous release. Questions, comments etc should go to
the
rcpp-devel mailing list off the R-Forge page.
Bugs reports are welcome at the GitHub issue tracker as
well (where one can also search among open or closed issues);
questions are also welcome under rcpp
tag at StackOverflow which also allows searching among the
(currently) 2822 previous questions.
If you like this or other open-source work I do, you can sponsor me at GitHub.
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
12:00 AM
Reproducible Builds (diffoscope): diffoscope 200 released [Planet Debian] 12:00 AM, Friday, 14 January 2022 10:00 AM, Friday, 14 January 2022
The diffoscope maintainers are pleased to announce the release
of diffoscope version 200. This version
includes the following changes:
* Even if a Sphinx .inv inventory file is labelled "The remainder of this
file is compressed using zlib", it might not actually be. In this case,
don't traceback, and simply return the original content.
(Closes: reproducible-builds/diffoscope#299)
* Update "X has been modified after NT_GNU_BUILD_ID has been applied" message
to, for instance, not duplicating the full filename in the primary
diffoscope's output.
You find out more by visiting the project homepage.