The Y2038 problem is similar to the Y2K problem. We’re exactly in between both about now. Both are 18 years away, in either direction. While Y2K is over and was obvious to everyone, Y2038 is not.
The issue here relates to a representation of date and time in Unix systems, and is therefore sometimes referred to as Unix Y2K. The root is the convention to store date and time information as 32bit unsigned integer in such systems. This means, possible values are limited. Time-differences in seconds, starting from 01.Jan 1970 cannot span beyond 03:14:07 UTC on 19 January 2038.
The Y2038 problem will make all calculations beyond this date impossible, until migrated to another representation. At the time being, this seems far away. However, the problem casts its shadows already. Industries, in particular financial markets, often rely on long term forecasts.
Governance issued treasury bonds come with with the longest maturity. Often twenty years, sometimes thirty years. Calculations for complex, long running financing models easily try to estimate returns 20 years and beyond into the future. This is already beyond the problematic date that Y2038 brings. The code to run these calculations is typically complex and stable. Sometimes, it is as old as from 1970. Back then, this date-representation Unix engineers introduced this approach. 32bit covered a long period. John Femellia has a thread, over at Twitter, telling a story about the upcoming issues today.
British Royal Mail issues computer games stamps writes BoingBoing:
The article features pictures of these stamps. Those who remember the times will find these adorable. The stamps are apparently available as first or second class stamps, at £1.60 or £1.55, and also in collectors sets.
Do I know enough people in the UK to send me postcards with stamps from:
Micro Machines (1991)
Sensible Soccer (1992)
each? Germany, meanwhile, is still debating whether computer games are hazardous and the people involved in the scene should be observed.
Part of the compelling nature of SaaS Products is the possibility to understand the user and improve on the go. Any Product Manager will literally have to understand what are the use-cases for customers and how to focus on the important areas. Just recently our team led the debate which metrics would be the right ones to focus on.
Nancy Wang, Head of Product Management at Amazon Web Services, highlights six product metrics enterprise SaaS companies should track.
In this Article, Nancy Wang, head of Product Management at the most successful cloud service providers, shares her insights on important metrics to keep an eye on. The possibility to understand often goes overboard and requires focus.
The case under discussion in the article revolves around paid products. Derived metrics are a foundation that serves as a blueprint to other products in the SaaS space. Goals differ, but ultimately, to make a product successful, it requires an understanding of how successful customers were, using the product. Following the established funnel pattern, users are being segmented into funnel. Along that funnel, the metrics acquired need to reflect the stage of the journey the user is on.
At the top of the funnel, most often the interaction is anonymous and requires profiling to understand the audience coming in. Further down in the funnel, metrics capture engagement and transaction. Towards the end of the funnel, the metric needs to relate to retention.
Specification of DNS over Dedicated QUIC Connections
While a lot of people debate DNS-over-https (and it’s dependencies), IETF has a specification for DNS-over-QUIC on it’s standards track.
This document describes the use of QUIC to provide transport privacy for DNS. The encryption provided by QUIC has similar properties to that provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient error corrections than UDP. DNS over QUIC (DNS/QUIC) has privacy properties similar to DNS over TLS specified in RFC7858, and performance similar to classic DNS over UDP.
Heute hat der Europäische Gerichtshof in einem Fall von FashionID, des Onlineshop des Modehändlers Peek & Cloppenburg, ein Urteil gesprochen. Es geht darin darum, wie mit der Weitergabe von Benutzerdaten bei der Verwendung von 3rd Party Content umgegangen werden muss. Dass der Einsatz von beispielsweise Facebook Like Buttons
Unter anderem versucht die Tagesschau aufzuklären. Weil das Urteil durch den EuGH ergangen ist und daher Konsequenzen über Deutschland hinaus haben wird, berichten auch internationale News wie Techcrunch und Yahoo(Reuters).
Simon Assion von #twobirds, Twitter-aktiver Rechtsanwalt, fasst eben dort einige Stichpunkte zu dem Urteil in einem Thread zusammen.
The other day wrote this in their post on LinkedIn. Following the link takes one to the newly announced Github Package Registry, that allows developers to host releases for distribution. It’s currently in beta and supports npm, docker images, maven packages, NuGet and Ruby Gems. The corresponding blog article has a few more insights:
With GitHub Package Registry your packages are at home with their code—sign up for the limited beta to try it out.
From the blogpost
While I appreciate the thought and easiness of integration, the announcement doesn’t leave me with a cosy feeling. It’s a bit like GitHub is trying to become the Facebook of code. The Internet is made to work decentralised and the interesting part always has been the freedom of choice. With functionality merging together in one platform, choice gets lost and there is opportunity of misuse.
In particular, it seems almost forgotten that Github, just like Linkedin, have been acquired by Microsoft in 2016 and 2018. This perspective throws another light on the added functionality and developers may want to evaluate remaining alternatives.