That's why for almost a year now #CEPH users have a problem, because Rust parts of Cryptography are clashing with Rust parts of BCrypt. But it's great!
And the best thing is Cryptography authors' attitude — #PyO3 has to deal with it, let's close the bug and lock comments. We really should have more critical packages like that.
That's why for almost a year now #CEPH users have a problem, because Rust parts of Cryptography are clashing with Rust parts of BCrypt. But it's great!
And the best thing is Cryptography authors' attitude — #PyO3 has to deal with it, let's close the bug and lock comments. We really should have more critical packages like that.
Idea: instead of trying to fix #y2k38 problem, let's just roll the calendar back to 1970. The XXI century sucks anyway, everything is going downhill. Really no point in keeping it.
How about one of the many alternative #Python#AsyncIO implementations that keeps causing trouble, yet people use it because it claims to be "ultra fast". Except that the claim is based on benchmarks… from 2018. Done on Python 3.5. Against other implementations whose versions weren't given. And last year, someone already reported they can't reproduce the numbers.
• add an artificial pkg-config file for bzip2, as bzip2-sys requires it, yet vanilla bzip2 distribution doesn't supply one (https://github.com/alexcrichton/bzip2-rs/issues/104)
• set an environment variable for zstd-sys
• pass appropriate "feature" to activate system lib in blosc2-sys
• patch lz4-sys to support system lib, using a patch that's being ignored by the author for months now (https://github.com/10XGenomics/lz4-rs/pull/39)
• patch libcramjam to allow system library in libdeflate-sys and liblzma-sys (via passing appropriate features)
• patch libcramjam not to force linking to static blosc2 in blosc2-sys
• patch blosc2-sys and libdeflate-sys not to force an exact version of the system library (in the case of blosc2-sys, a broken version, I must add)
So, well, #RustLang and #Cargo are going great. I recall that somebody posted a matching variant of the Scooby Doo meme. Except that I'd modify it a bit, to show that underneath your average`*-sys` crate, there's actually a vendored, old and broken version of a C library. And even if system libraries are actually supported, you have to put a lot of effort to make them work. And on top of that, if they don't, nobody even bothers printing a message and telling you why. It's all guesswork and reading the code.
Now we just have to check and patch all the remaining Rust packages in Gentoo…
Two hours later, and we have an unbundled #CramJam in #Gentoo.
• add an artificial pkg-config file for bzip2, as bzip2-sys requires it, yet vanilla bzip2 distribution doesn't supply one (https://github.com/alexcrichton/bzip2-rs/issues/104)
• set an environment variable for zstd-sys
• pass appropriate "feature" to activate system lib in blosc2-sys
• patch lz4-sys to support system lib,...
I'm slowly working on a new blog post. In the meantime, I've looked closer at the #y2k38 problem, and I'd like to share some observations with you.
It seems that the problem is mostly considered from the "overflow" in 32-bit programs angle — i.e. that we're suddenly going to move back in time from 2038 to 1901, and there will be some "funny" effects of that. However, in reality we're probably going to see different kinds of problems.
Firstly, `stat()` stops working on files whose timestamps can't be expressed in 32-bit `time_t` (the files can still be opened, though). It is quite counterintuitive; we usually assume that opening files is more restrictive. In the most absurd case, a program would be able to use a file only once. Once used, timestamps will get updated and `stat()` will start failing.
Secondly, `time()` returns an error. Many developers (myself included) doesn't even consider that `time()` can fail. Yet after 2038, every single call is going to return `-1`. What does that mean? A "well-written" software will just fail with an error. Other programs will just be "stuck" 1 second prior to midnight of December 31, 1969. And I believe that could be worse than returning an "overflowed" time counter, as every call will return the same value.
What could the consequences be? Clocks showing the same date and time all the time. Waiting loops based on wall clock time hanging immediately. Events never getting triggered. Clock-seeded pseudorandom number generators (`srand(time(NULL))`) always returning the same sequence of numbers.
This will affect all proprietary software on 32-bit platforms. If we wanted to play an old game, we're going to have quite a fight ahead of us. What's even worse, even faketime doesn't suffice here — it will adjust the time returned by `time()` calls, but not file timestamps.
I'm slowly working on a new blog post. In the meantime, I've looked closer at the #y2k38 problem, and I'd like to share some observations with you.
It seems that the problem is mostly considered from the "overflow" in 32-bit programs angle — i.e. that we're suddenly going to move back in time from 2038 to 1901, and there will be some "funny" effects of that. However, in reality we're probably going to see different kinds of problems.
On the eastern shore of #Kórnik Lake, there's a promenade dedicated to Wisława #Szymborska, the poet born in these parts. There, you can find some of her poems pinned to a fence, but also a bench dedicated to her. It includes a part of her poem, illustrated with a #cat figure.
"""
(…)
Here someone was and was,
then suddenly disappeared
and now is stubbornly absent.
All the closets were peered into.
The shelves were walked through.
The rug was lifted and examined.
Even the rule about not scattering
papers was violated.
What more is to be done?
Sleep and wait.
On the eastern shore of #Kórnik Lake, there's a promenade dedicated to Wisława #Szymborska, the poet born in these parts. There, you can find some of her poems pinned to a fence, but also a bench dedicated to her. It includes a part of her poem, illustrated with a #cat figure.
"""
(…)
Here someone was and was,
then suddenly disappeared
and now is stubbornly absent.
All the closets were peered into.
The shelves were walked through.
The rug was lifted and examined.
Even the rule about not scattering
I can't bump #uv in #Gentoo again, because it — once again — switched to requiring the very newest #RustLang compiler, released not even a week ago. Of course, the new release of the compiler breaks some crates. Of course, since everything is pinned in Rust, we now have to go through tremendous effort patching stuff before we'll be able to get the new version in.
But no, Rust is going great. Also, don't forget that it's Python breaking backwards compatibility all the time.
Also, this is why gccrs will never work. What's the advantage of having an alternative compiler when it will need to catch up with the reference implementation within days of release?
I can't bump #uv in #Gentoo again, because it — once again — switched to requiring the very newest #RustLang compiler, released not even a week ago. Of course, the new release of the compiler breaks some crates. Of course, since everything is pinned in Rust, we now have to go through tremendous effort patching stuff before we'll be able to get the new version in.
@mgorny Are they always using the newest features or are the requiring the newest compiler just because? If the later, maybe they can be persuaded to give it a bit of time?
@mgorny Crates tracking the latest toolchain is a major annoyance - also for Rust devs that don't develop for PC and are stuck with whatever rustc version the SDK for their target offers. One of my projects is probably still stuck with Rust 1.52...
Gregory's Server
