Mit Temtem liefert das spanische Entwicklerstudio Crema Games den ersten Überraschungserfolg im PC-Spielejahr 2020 auf. Und das, obwohl es auf Kickstarter nur mäßig viel Geld sammeln konnte – und obwohl sich sogar die Community schon früh Sorgen wegen der Ähnlichkeit mit Pokémon machte. (Pokémon, MMORPG)
Quelle: Golem
Boeings neues Flugzeug 777X ist erstmals geflogen. Es ist aktuell die größte Passagiermaschine mit zwei Treibwerken und zeichnet sich durch ein besonderes Design bei den Tragflächen aus. Für Boeing war das eine dringend notwendige Erfolgsmeldung. (Boeing, Technologie)
Quelle: Golem
One of the most productive meetings I had KubeCon in San Diego last November was a meeting with Docker, Amazon and Microsoft to plan a collaboration around a new version of the CNCF project Notary. We held the Notary v2 kickoff meeting a few weeks later in Seattle in the Amazon offices.
Emphasising that this is a cross-industry collaboration, we had eighteen people in the room (with more dialed in) from Amazon, Microsoft, Docker, IBM, Google, Red Hat, Sylabs and JFrog. This represented all the container registry providers and developers, other than the VMware Harbor developers who could unfortunately not make it in person. Unfortunately, we forgot to take a picture of everyone!
@awscloud, @GCPcloud, @Azure, @Docker, @RedHat, @jfrog collaborating on @CloudNativeFdn Notary v2 – touring the amazon spheres. Who would have thought… https://t.co/6VL3OucX0c pic.twitter.com/rNglQIO5ZM— Steve Lasker (@SteveLasker) December 15, 2019
The consensus and community are important because of the aims of Notary v2. But let’s go back a bit as some of you may not know what Notary is and what it is for.
The Notary project was originally started at Docker back in 2015 to provide a general signing infrastructure for containers based on The Update Framework (TUF), a model for package management security developed by Justin Cappos and his team at New York University. This is what supports the “docker trust” set of commands that allow signing containers, and the DOCKER_CONTENT_TRUST settings for validating signatures.
In 2017, Notary was donated to the CNCF, along with the TUF specification, to make it a cross-industry standard. It began to be shipped in other places as well as Docker Hub, including the Docker Trusted Registry (now a Mirantis product), IBM’s container registry, the Azure Container Registry, and with the Harbor project, another CNCF project. TUF also expanded its use cases, in the package management community, and in projects such as Uptane, a framework for updating firmware on automobiles.
So why a version 2 now? Part of the answer is that we learnt a lot of things about the usage of containers since 2015. Are container years like dog years? I am not sure, but a lot has happened since then, and the usage of containers has expanded enormously. I covered a lot of the reasons in-depth in my KubeCon talk:
Supply chain security – making sure that you ship what you intended to ship into production – has become increasingly important, as attacks on software supply chains have increased in recent years. Signatures are an important part of the validation needed in container supply chains.
Integrating Signatures in the Registry
The first big change that we want to make is because at present not every registry supports Notary. This means that if you use a mixture of registries, some may support signatures while others do. In addition, you cannot move signatures between registries. Both of these are related to the design of Notary as in effect a registry sidecar. While Notary shares the same authentication as a registry, it is built as a separate service, with its own database and API.
Back when Notary was designed this did not seem so important. But now many people use, or want to use, complex registry configurations with local registries close to a production cluster, or at the cloud provider code is running on, or in an edge location which may be disconnected. The solution that we are working on is that rather than being a standalone sidecar service, signatures will be integrated into the OCI image specification and supported by all registries. The details of this are still being worked out, but this will make portability much easier, as signatures will be able to be pushed and pulled with images.
Improving Usability
The second big set of changes is around usability. The current way of signing containers and checking signatures is complex, as is the key management. One of the aims of Notary v2 is to have signatures and checking on by default where possible. There have been many issues stopping this with the current Notary, many of which are detailed in the KubeCon talk, including the large number of keys involved due to lack of hierarchy and delegation, and lack of standard interfaces for signature checking on different platforms such as Kubernetes.
If you want to learn more, there are weekly meetings on Mondays at 10 a.m. Pacific Time – see the CNCF community calendar for details. The Slack channel is #notary-v2 in the CNCF Slack. There will be two sessions at KubeCon Amsterdam, one introductory overview and state of where we are, and another deep dive working session on current issues. Hope to see you there!
The post Community Collaboration on Notary v2 appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/
Die Bundesregierung hat den geplanten Umweltbonus für Elektroautos immer noch nicht bei der EU-Kommission notifizieren lassen. Doch es soll Fortschritte in dem Verfahren geben. (Elektroauto, Internet)
Quelle: Golem
The Cluster Overview dashboard we introduced in Red Hat OpenShift 4.2 was a significant and well-received addition to the Web Console, and our team has greatly enjoyed seeing how OpenShift users (and even our own developers) have been using it to identify and resolve issues they otherwise may not have noticed.
We’ve made a number of changes both big and small to the dashboard based on our user research findings and the feedback we’ve collected from readers like you. This post covers some of the key improvements and introduces a new member of the dashboard family that we think developers in particular are going to love.
If you’d like to help us make these dashboards even better in the future, consider filling out our survey to provide feedback and sign up for future research opportunities.
Let’s dive in.
Visual polish
With the help of visual designers on our User Experience Design team and a closer adherence to the open source PatternFly design system, the 4.3 dashboard provides a much cleaner first impression. The new Red Hat font, adjusted spacing, fewer separators, and more clearly-defined charts make this the cleanest window into OpenShift clusters yet.
More signal, less noise
Dashboards have a tendency to become disorganized smörgåsbords of cards and information that compete for attention as they gain more functionality. When that kind of noise starts to creep in, figuring out what’s important and what actions need to be taken at a glance can become difficult.
Our team made a conscious effort in 4.3 to reduce the amount of visual noise from the previous iteration and boost the important signals that make managing and fixing clusters easier. Along with a variety of smaller iconography and behavioral tweaks, we were able to combine three cards into one without losing any functionality and integrate links to other areas of the Console (like alert details pages) when they become contextually relevant.
These changes make the dashboard a more effective launching point than ever, requiring less guesswork and fewer clicks to find and fix issues.
Card-by-card refinements
There are a ton of little details I could dig into, but for the sake of your eyes and my fingers I’ll cover the highlights and let the rest be nice little surprises. If you prefer to spoil nice little surprises, take a peek at our detailed design documentation in the OpenShift Design GitHub repository.
The Details card now includes the cluster’s API address, a link to the OpenShift Cluster Manager, the current upgrade channel, and a handy link to the cluster’s settings page. You’ll also see a version upgrade notice here when one is available.
Resources in the Inventory card can now be clicked to view the full list page of each type, and the card now includes the cluster’s Storage Classes as well.
The Status card regains the same subsystem statuses that were available in the Cluster Status page of 4.0, with the response rates of each control plane component included in a popover. The alerts that appear in this card also now include links to view additional information about each one.
When the Red Hat Quay operator is installed an additional Quay Image Security status appears that flags any container vulnerabilities that are found, with links to the Quay console for additional information. Learn more about the Console’s Quay integration in this post.
The revised Activity card condenses all events into denser, easily-scannable rows and highlights certain long-running operations (like cluster updates) in a new Ongoing section so they can’t easily be missed.
Finally, the Utilization card now incorporates the best pieces of 4.2’s Capacity and Top Consumers cards to show the current resource usage and remaining capacity in one place. Clicking any measurement reveals the top consumers of each resource by either project, node, or pod, and the card’s charts can be adjusted to show the last 1, 6, or 24 hours of resource consumption.
The new Project Dashboard
Forgive me for saving the biggest news for last, but the new Project dashboard (which is also available in the Developer perspective, of course) provides the same familiar dashboard experience but scoped to project-level resources and metrics.
The Inventory card includes the quantity and statuses of deployments, pods, PVCs, services, routes, config maps, and secrets, and the Utilization card includes the network utilization and historical pod count of the current project. Any resource quotas applied to the project are also included, and an additional Launcher card with relevant external links can be added via the new ConsoleLink CRD.
What’s next
New features, refinements, and surprises, of course!
Check out the OpenShift Console and OpenShift Design GitHub repositories if you’d like a sneak peek, but until then, we would really love to hear your ideas and feedback! Please fill out our brief survey to get in touch, or sign up to participate in future OpenShift research opportunities.
The post OpenShift 4.3: Dashboard refinements and the new Project dashboard appeared first on Red Hat OpenShift Blog.
Quelle: OpenShift
Zwischen Assassin’s Creed und künftigen Großprojekten für Google Stadia war noch Zeit für etwas Kleineres: Das Entwicklerstudio Typhoon hat mit Journey to the Savage Planet ein gelungenes Actionspiel produziert, das vage an No Man’s Sky erinnert – aber wesentlich kompakter daherkommt. Von Peter Steinlechner (Spieletest, Games)
Quelle: Golem
Der Autohersteller Audi kämpft mit der Produktion seiner Elektroautos im Werk Brüssel. Derzeit wird über Kurzarbeit beim Bau des E-Tron und E-Tron Sportback verhandelt. (Elektroauto, Technologie)
Quelle: Golem
Nicht für eine Beschränkung, sondern für ein Verbot von 5G in der Schweiz treten die Gegner ein. Andere wollen erst eine Studie des Bundesamtes für Umwelt (Bafu) abwarten. (5G, GreenIT)
Quelle: Golem
Bei der Geforce RTX 2060 setzt EVGA keinen TU106-Chip ein, sondern den TU104. Dadurch ist die KO-Edition in einigen Benchmarks deutlich flotter, als zu erwarten wäre. Grund dafür sind offenbar die Raster-Engines. (Nvidia Turing, Grafikhardware)
Quelle: Golem
Anfangs hieß es, dass bei dem Schadsoftware-Befall des Berliner Kammergerichts keine Daten abgegriffen wurden. Doch ein unveröffentlichtes Gutachten kommt nun zu einem anderen Schluss. Neben einem Datenabfluss wirft es kein gutes Licht auf die IT-Infrastruktur des Gerichts. (Malware, Virus)
Quelle: Golem
