The examples in TFA are terrible and I don't get why it was necessary to jump the gun by submitting that article instead of actually waiting for the release and the official release page with more carefully designed examples.
> The examples in TFA are terrible and I don't get why it was necessary to jump the gun by submitting that article instead of actually waiting for the release and the official release page with more carefully designed examples.
Google Container Registry provides a pull-through mirror, though, just prefix `mirror.gcr.io` and use `library` as the user for the Docker Official Images. For example `mirror.gcr.io/library/redis` for https://hub.docker.com/_/redis.
Indeed. It might even result in out of range values due to implicit rounding (`3.5 + (4.5 - 3.5) * (the largest float smaller than 1)` results in 4.5, which is unexpected).
I'm a contributor to the PHP programming language and a maintainer of the randomness functionality and did some research into this topic to provide a floating point generation method that is as good as possible and came across the "Drawing Random Floating-point Numbers from an Interval" paper by Frédéric Goualard.
PHP 8.3 ships with a method generating random floats from arbitrary intervals based on the γ-section algorithm described in that paper. The PHP documentation goes into additional detail:
As part of the implementation I also reached out to Prof. Goualard with some questions for clarification regarding the behavior for extreme values, which resulted in an Corrigendum being published, since the algorithm was buggy in those cases (https://frederic.goualard.net/publications/corrigendum.pdf). The entire exchange with Prof. Goualard was really pleasant.
For PHP 8.3, we upgraded production during the RC phase, but were prepared to revert back to an older one by not relying on the new functionality. Docker makes this easy.
As long as you do not use the new functionality, I'd claim that a new PHP version is no less stable than an older one. And on a contrary you would be missing out on some bugfixes that were deemed too risky to apply to an existing version.
Disclosure: I've got a commit-bit for PHP, so we had in-house expertise to diagnose issues ourselves.
> It seems to be better to err on the side of 'people dont know if they want a PRNG or a CSPRNG' and switch the default to the latter with an explicit choice for the former for people that know what they need :)
That’s exactly what we did in PHP 8.2 [1] with the new object-oriented randomness API: If you as the developer don’t make an explicit choice for the random engine to use, you’ll get the CSPRNG.
Now unfortunately the hard part is convincing folks to migrate to the new API - or even from the global Mt19937 instance using mt_rand() to the CSPRNG using random_int() which is already available since 7.0.
OpenBSD had a similar problem with people calling arc4random and getting RC4 randomness, but they just changed it to use ChaCha20 anyway and backronymed it to "a replacement call for random".
Zoner is a Finnish web hosting company, which has a history of providing hosting for Finnish open source projects, and the original maintainer (and most of the original crew) is Finnish as well. Nothing weird here.
FYI: Serving static files is easier and more flexible in modern versions of HAProxy via the `http-request return` action [1]. No need to abuse error pages and no need to embed the header within the error file any longer :-) You even have some dynamic generation capabilities via the `lf-file` option, allowing you to embed e.g. the client IP address or request ID in responses.
Nice, I will have to play around with that. I admit I sometimes get stuck in outdated patterns due to old habits and being lazy.
I'm a community contributor to HAProxy.
I think I recall chatting with you on here or email, I can't remember which. I have mostly interacted with Willy in the past. He is also on here. Every interaction with HAProxy developers have been educational and thought provoking not to mention pleasant.
> I think I recall chatting with you on here or email, I can't remember which.
Could possibly also have been in the issue tracker, which I did help bootstrapping and doing maintenance for quite a while after initially setting it up. Luckily the core team has took over, since I had much less time for HAProxy contributions lately.
The DSL supports comparison operators, '&&', '||' and nested expressions, while preventing mixing of '&&' and '||' without making precedence clear using parentheses. This DSL should fit 'non-trivial', but it still should be simple enough to easily understand it.
I don't believe this is necessarily true. Unless I'm misunderstand you, each of the possible variants of spelling out 32 hexadecimal characters could theoretically SHA-256 into the spelled-out hash + 1 (looping around at ff…ff).
Given that the cat effectively is out of the bag, does the example on the release page (sneak preview) make more sense to you: https://www.php.net/releases/8.5/en.php#closures-in-const-ex...?
> As a side note, even PHP's official wiki cannot highlight correctly the multiline attributes behind a "#"
Yes, unfortunately the off-the-shelf software of the Wiki uses a custom-built highlighter instead of the `highlight_string()` function that is bundled with PHP: https://www.php.net/manual/en/function.highlight-string.php
reply