vlowrian

I can see how this would have helped in this case.

As I see it, the distributions are mostly relying on the upstream provisioning of the openJDK project. So if they fix this issue, it shouldn't take long until we see updated packages in all major distributions. This might be a problem specific to the openJDK build process, so a different package source would help in that case.

But as mentioned above, Azul usually doesn't provide out-of-cycle critical fixes without a paid plan. And most people will still use whatever the distribution provides - so this is still an issue regardless of alternative package sources.

And since I assume that many or most running JDK instances actually are coming from the distributions repository rather than an alternative source, and there is literally no outcry regarding the missing packages whatsoever - I fear that there are a lot of vulnerable software systems of people not knowing about it right now.

Thanks for the info! That's very interesting since they usually only provide out-of-cycle critical fixes for their paid tiers. On the other hand - this only proves that it's actually possible to provide a hot-fixed OpenJDK in time.

Unfortunately, I assume that a very common case is just using the distribution provided openjdk-package and configuring the system for auto updates. So the main issue here is that a serious number of systems is relying on the patch process of the distribution to fix issues like this and they are still vulnerable at this moment.

What puzzles me most is that two days after the announcement of the vulnerability and the release of the patched Oracle JDK, there is still no patched version of OpenJDK for most distributions.

We're running some production services on OpenJDK and CentOS and until now there are only two options to be safe: shutdown the services or change the crypto provider to BouncyCastle or something else.

The official OpenJDK project lists the planned release date of 17.0.3 as April 19th, still the latest available GA release is 17.0.2 (https://wiki.openjdk.java.net/display/JDKUpdates/JDK+17u).

Adoptium have a large banner on their website and until now there is not a single patched release of OpenJDK available from them (https://github.com/adoptium/adoptium/issues/140).

There are no patched packages for CentOS, Debian or openSUSE.

The only available version of OpenJDK 17.0.3 I've seen until now seems to be the Archlinux package (https://archlinux.org/packages/extra/x86_64/jdk17-openjdk/). They obviously have their own build.

How can it be that this is not more of an issue? I honestly don't get how the release process of something as widely used as OpenJDK can take more than 2 days to provide binary packages for something already fixed in the code.

This shouldn't be much more effort than letting the CI do its job.

Edit: Typo.

The interesting thing about the German covid app is that it is actually pretty good considering the solution space available to its creators. It features a decentralized "privacy first" architecture and utilizes the platform APIs which _should_ be the best implementation for handling the actual contact tracing.

Since it is open source and uses a very common tech stack, it is easy to check and understand for as many people as possible that it is well-crafted and does not contain any obvious security vulnerabilities or backdoors. This makes it very trustworthy from an IT-persons point of view, and should in minimize the number of unsettled people who don't install the application on their handsets since they mistrust the government.

Well-known public instances like the CCC (German IT-Security NGO) did a review on the app and gave it a good testimonial - even on mass media like public television. The government and the involved third-parties like Deutsche Telekom and SAP did a lot to emphasize that there is no harm to be expected from the app and the worst thing that could happen is that it doesn't work - which would be the exact same outcome as if you just didn't use it.

Still, Germans' are hard to convince, once they made up their mind about something. The public image of the government, as well as Deutsche Telekom and SAP is often disconnected from their actual performance. The same people often disregard these instances' and companies' ideas, products and services with the same persistence they welcome or defend equaly debatable innovations and decisions from actors they look favorably upon, like Apple.

It's sad to see that the good work of many smart people is so easily disregarded. The government and the involved companies actually listened to privacy and security experts and made a lot of right choices. That's something I'd like to see more of in the future. A little bit of appreciation could go a long way for shaping such decisions for the years to come.

This depends in the broadest sense on what data you want to have and which data source you trust. The OWID data is a good data source for our use case because it collects many data characteristics from all over the world and is very trustworthy at the same time. On the other hand, you can't break down this data further than on a country level.

Other data sources differentiate more in terms of geographical characteristics, but include a smaller amount of other information, e.g. the New York Times data used by Google (https://www.google.com/search?q=covid+data+usa+county+state).

Hi HN, this is a little pet project we created over the last couple of weeks. We created "Software EKG" a while back as an internal tool to analyze large amounts of time series data collected on production systems. This was before things like Prometheus and Grafana existed and it proved to be a valuable tool in our belt when we had to hunt down performance issues and relate different metrics like harddisk I/O and request latency in our application.

This adjusted version automatically downloads COVID-19 data from OWID. Feedback welcome.

> Das Gericht will mit dem Verkaufsstopp beide Unternehmen an einen Tisch zwingen, damit sie ein Lizenzabkommen aushandeln.

This roughly translates to: With this sales ban, the court wants to bring both parties back to the table so they negotiate a license agreement.

This doesn't make sense to me. Doesn't the sales ban only force Lenovo into accepting an unreasonably high license fee so they can minimize the damage?

I find it quite fascinating that there seems to be no recognized English source on the actual sales block, while there are plenty credible sources in German.

> If the higher court overturns the injunction, the enforcing company has to compensate the other side for any lost sales, which can be substantial.

Based on this, I'd expect some dent in Lenovo's stock value. I thought information like that would take minutes to hit major news portals rather than hours or days.

Anyone interested in that matter might enjoy these two blog posts by a colleague of mine:

1. https://medium.com/@armin.heller/using-parser-combinators-in... 2. https://medium.com/@armin.heller/parser-combinator-gotchas-2...

They highlight the typical pitfalls of implementing your own parser combinators and I found them very helpful for my understanding of parser combinators.

There are two main drivers for this decision: first, as you already mentioned, systemd-nspawn requires root privileges when creating a container instance. With schroot this is something I don't really have to care about.

The other important reason is that I try to keep the slingring codebase as small as possible. At the moment, I maintain this project alone and I want to keep it manageable in the long term. I actually started Slingring using nspawn containers, but I found that handling things like providing the user/group nss databases inside the container had to be done by myself, while schroot includes that functionality.

On the other hand, I simply do not need the greater flexibility that is provided by nspawn-containers at the moment. This could change in the future. Therefore, the coupling with schroot inside slingring is kept to a minimum and I might switch to nspawn whenever it might suite my requirements better.

Hi everyone, I am the author of Slingring. It is in a very early stage and I am interested in your opinion on the basic concept as well as my approach. Please ask anything you want to know :)