danogentili

The current trend in govt regulation is actually going in the opposite direction, with telecom lobbies in Europe pushing for "fair share" (pretty much an implementation through law of what Deutsche Telekom and Vodafone Germany are doing right now) through the Digital Networks Act.

South Korea pioneered "fair share" govt regulations in 2016 (which caused Twitch to exit the market in 2024 due the exorbitant "fair share" fees).

Seems pretty much a private equivalent of "fair share" govt regulation currently being pushed by ISPs in Europe through lobbying with the Digital Networks Act (https://www.namex.it/toward-the-digital-networks-act-the-fut..., https://stopdna.eu/).

South Korea pioneered fair share govt regulations in 2016 (which caused Twitch to exit the market in 2024 due the exorbitant "fair share" fees).

Async functions based on PHP fibers are explicitly uncolored, they do not require any special keywords to be invoked, and are explicitly swappable with any regular functions.

Fibers are incredibly powerful, as they can be used to implement seamless go-like concurrency with async, colorless functions.

They were added to PHP by the maintainers of amphp (https://amphp.org), which is the best library for async PHP out there, providing a clean, object-oriented and async API for files, databases and everything that can make use of async I/O.

Kia is also using a Linux Wayland system on an x86-64 Intel machine (with an iGPU) with an (excellent) QT5 UI for their infontainment system

Not really, the auth_key_id really is simply equivalent to a TLS session ticket, used to avoid repeating the handshake every time a new connection is established: there's nothing "unencryted" about it, it's just an identifier of a previously established encrypted channel, like session tickets in TLS (and on top of that, the MTProto auth key ID is also rotated every 24 hours).

Note that the article employs unwarranted FUD in regards to the auth_key_id, which is fully equivalent to a TLS session ticket, used, like in TLS, to avoid repeating the handshake each time a new connection is established (and on top of that, the MTProto auth key ID is also rotated every 24 hours).

Apparently they're using a simple 4g/3g/2g modem with Russian SIM, which is the reason why all russian ISPs completely turn off mobile internet (& voice) when drone launches are detected (clearly hasn't helped here as the drones were launched from trucks super close to the targets).

These launches specifically seem to have also used on-board AI targeting models trained on photos of the plane models to hit, I assume as a fallback in case mobile connection isn't available inside the bases (and photos on some Telegram channels seem to show usage of the FOSS autopilot system ArduPilot (https://ardupilot.org))

You listed around 4 competing stores in your example, but Apple explicitly does not allow anyone to compete with their own store (except for in the EU, thanks to the DMA, and even then they take their cut, see below).

Another issue with the analogy is that when you buy a PC in a physical store, that store does not continue taking a cut of all software bought on that PC using i.e. unrelated digital stores (but that's precisely what Apple is asking from competing stores in the EU).

It's even more of a waste.

Grishka wrote very low quality code (an extremely buggy and segfaulty mess of C and C++), combined with little testing in not-so-edge case network conditions.

I managed to improve the situation after weeks of refactoring and testing for my library, and thankfully now it was completely replaced by webrtc.

This dude has absolutely no right to say anything about the quality of the source code of the android app, because:

1) His libtgvoip code, previously used for audio calls, is the worst code I have ever had the displesaure of touching, it caused all kinds of issues ranging from instability to segfaults, and thankfully it was completely replaced by webrtc.

2) The android app is literally the smoothest and most responsive android app I've ever used.

Grishka, please stop being so salty. VoIP is hard to do right, but not impossibly so. VoIP being hard is still not an excuse for writing garbage C/C++ code (and I don't mean to offend personally here, but the code was really a mess, please stick to Java development on your own personal projects).

And you call that a success story? :D

If a 2FA password is configured, it is still required in order to login with a future auth token; however, even if it isn't set up, the fact that you have a future auth token means you have already logged in and then logged out on this specific device, so it's not a real issue (i.e. it's as if when logging out, you didn't actually log out but rather just hid the account in the UI, the future auth token is stored safely, in the same place as normal auth keys are + re-entering the 2FA password is still required).

This is also supported by Telegram, as well as sending codes via email (in select countries), see https://core.telegram.org/api/auth#code-types for the full list of authentication methods (which are chosen by the server, depending on the country of the user and some other heuristics).

I believe it's quite the opposite, cloud has normalized absurdly high traffic fees, and that is what should be raising alarm bells.

I manage my own ASN, I've been thinking of branching out, experimenting by creating my own eSIM.

Given the huge number of virtual ISPs offering eSIMs at various prices, I mistakenly assumed it would be relatively easy to find documentation on how to do that (perhaps via some ISP selling traffic bundles to virtual ISPs); maybe someone can recommend any resources?

Yes, I certainly do: if Apple can't behave, there's no reason their unrepairable, overpriced garbage should stay on the EU market.

The last one actually made me snoff

> Can we start expanding this argumentation to Microsoft, Sony and Nintendo too?

Absolutely.

> Sony has no right to decide what I do with my hardware, right?

That is correct.

If EU app stores fill up with pornography and terrorism apps, that will be a problem of the companies running the stores, not Apple's problem.

Apple has no right to decide what users do with the hardware they sell.

You could make the same (unconvincing) argument for apps on third-party stores, teaching the same dangerous things or doing even worse things like (gasp) allowing pornography :P

Now this leaves me wondering, should I agree because I have had similar experiences when trying to improve some frankly unintelligible proofs in certain sections of CS wikipedia, or should I carefully disagree because of the suspicious second part of your comment? :=)

The rk3588 and rk3588s (i.e. orange pi 5) both support hardware H264/HEVC encoding @ 8k30fps, as well as hardware HEVC/VP9 decoding @ 8k60fps, H264 decoding @ 8k30fps, AV1 decoding @ 4k60fps.

The rk3588 and rk3588s both support hardware H264/HEVC encoding @ 8k30fps, as well as hardware HEVC/VP9 decoding @ 8k60fps, H264 decoding @ 8k30fps, AV1 decoding @ 4k60fps.

Yes.

That would be awesome!

Yes, I'm planning to support my fork of ext-php-rs, given that it will be heavily used by our mongodb driver.

I've actually sent an email to David Cole, asking him to make a maintainer of the original repo, but he hasn't replied yet, feel free to send your MRs to our fork in the meantime!

I used the same delay because this way when running via CLI it's clearer that the requests are made asynchronously, because the "Got response" lines are printed at the same time after 5 seconds, not 5 seconds apart each; using varying delays removes this neat simultaneous effect.

The PHP <-> Rust bindings are provided by https://github.com/Nicelocal/ext-php-rs/ (our fork of https://github.com/davidcole1340/ext-php-rs with a bunch of UX improvements :).

php-tokio's integrates the https://revolt.run event loop with the https://tokio.rs event loop; async functionality is provided by the two event loops, in combination with PHP fibers through revolt's suspension API (I could've directly used the PHP Fiber API to provide coroutine suspension, but it was a tad easier with revolt's suspension API (https://revolt.run/fibers), since it also handles the base case of suspension in the main fiber).

https://revolt.run / https://amphp.org does basically what you did, except with also a bunch of nicely designed async libraries for HTTP/MySQL/Postgres/etc, stackful coroutines (like goroutines) with fibers and integration not only with libuv, but also with libev, or with plain stream_select.

php-tokio plugs into revolt, which in turn allows it to coexist with any async library based on or compatible with revolt (i.e. the entire amp ecosystem, PSL, reactphp, etc...).