Palm Treo/Pre and BlackBerry users! And probably Clicks users too. It's not a matter of "Does Russian language use the Latin script?" (it doesn't), but rather "What is the least annoying method to input Cyrillic on a BB-style keyboard, which doesn't have enough buttons for the йцукен layout?". Phonetic layouts such as яверты or яшерты were very popular for such devices back in the day.
Pebble watches can use Bluetooth LE and Bluetooth Classic connection profiles simultaneously. It's possible to pair two phones this way, but that's considered an undocumented hack. Also there's no ready-made desktop OS support, I'd look into forwarding your laptop notifications to a phone via KDE Connect or something like that instead.
Nikolai Durov lives in Saint Petersburg and works for the Russian Academy of Sciences. Pavel Durov had visited Russia multiple time since his "exile".
The public-facing story around Telegram is performative PR, which could be explained by the exact reasons listed in the parent comments: association with the Russian state had hindered VK growth besides the CIS region.
Phone UI paradigm isn't as easy as "Let's just scale down the Desktop/Tablet applications". In case of Sailfish OS development history, migration from clunky, but closer to Desktop, Hildon framework of Maemo 5 to purpose-built Qt applications of Maemo/MeeGo Harmattan was obvious quality boost. Same with webOS and UBports: app ecosystem starting from scratch within their corresponding "DE"s. If convergence-style cross-device applications were somewhat easily achievable, that would've happened in the early 2010s (Windows Phone / Windows RT? Ubuntu Touch getting more attention from investors?). It's the same story why Android Tablets suck and iPadOS doesn't, but in other direction.
And/or, it's a simple matter of time/money being spent on streamlining the experience. It's not like Sailfish OS is perfect (Qt6 migration is way overdue), but Jolla has already figured out lots of integration details which will become teething problems for Droidian and such. Including, but not limited to VoLTE support.
I'm not convinced that convergent UI works either. The needs of desktop and mobile just differ too greatly.
That doesn't mean that the two can't be served by the same UI framework, but at minimum you need two sets of widgets and separate desktop/mobile layouts in order to not either make the desktop experience dumbed down or end up with a mobile experience that's awkward to use with touch.
The padding and control size in GNOME feels completely goofy on a desktop machine for example and reduces the usability of 12"-13" laptops with how much space is eaten up by blank space.
> I'm not convinced that convergent UI works either. The needs of desktop and mobile just differ too greatly.
For the record, I agree. But I've been playing with Apple's new Liquid Glass UI on macOS / iOS and I think they've done a pretty good job of defining platform-agnostic UI primitives and layouts with some platform-specific rules when needed.
It's a big redesign that covers desktop / mobile / tablet / TV. They did a pretty clever job of it, though the desktop experience suffers slightly (of course).
I've been seeing this myself since I use several Apple products, and while parts are done well…
> though the desktop experience suffers slightly (of course).
This is the part that makes it not work. The Liquid Glass transition isn't the only thing that's negatively impacted desktop UI in macOS, but also the several revisions of iOS-7-like flat designs since 10.10 Yosemite with a slow but constant march of papercuts. So even in the prior version (Sequoia), a great deal of damage had already been done. Tahoe's Liquid Glass compares less favorably against the much more "desktoppy" 10.9 Mavericks.
Trust me, I'm with you 100%. I weep for the Mac OS X we used to have.
I'm just trying to look at it from Apple's eyes. From their perspective, I think, they're trying to design a UI framework that exists beyond any particular device form factor. UI design in the abstract, where specific platforms are particular manifestations of their Platonic UI ideal.
So you have something of a broad convergence of macOS / iOS / iPadOS / visionOS / etc. design elements, like rounded application windows, UI widgets (button/toolbar/...), ecosystem stuff (app widgets, live activities), and Apple technologies (Control Center, Spotlight, Siri, notifications).
Layout is (mostly) grouped relative to display size, not interaction method (like touch v. mouse). Similar display sizes have similar application layouts. Large = (macOS, visionOS, tvOS, iPadOS), medium = (iOS, iPadOS [small devices], CarPlay), small = (Apple Watch). Large display layouts tend to have the menu bar, toolbars, and side bars.
I could go on but it's getting late. This might be a half-baked idea, but I'm pretty sure this is more-or-less how Apple is approaching their platforms now with the Liquid Glass redesign.
> Phone UI paradigm isn't as easy as "Let's just scale down the Desktop/Tablet applications".
Have you tried modern Gnome/GTK+ 4 applications? You can resize the window to a tiny size and it seamlessly "scales down" to a phone layout. Very handy even on a desktop. Yes, there are real differences besides size (phone UI needs a lot of inactive padding around tap areas because finger taps are imprecise; it greatly prefers swipes to taps, while a pointer-based UI prefers clicks to drag'n'drop; phone UI needs long taps as a secondary action, etc.) but they're minor in the grand scheme of things.
You mean modern in the sense that is no designer any longer, one has to code everything manually, and the designer that was going to be done, was based on Web technologies?
I somehow agree with this statement too. Although I don't dislike current GNOME, I think Mer Linux (SailfishOS and Nemo) as well as its predecesors (MeeGo and Maemo) are much more pleasant to use on a small screen. The others don't look very optimized for that usecase. Actually, MeeGo, as shipped in a Nokia N9, was in many aspects the most elegant mobile UI I've ever seen.
Containers with systemd as an init process are considered first-class citizen by the Podman ecosystem (the base images are named accordingly: e.g, ubi10-init vs ubi10)
My current production systems are running Ubuntu 22.04, and there is no official images with systemd for them in Podman. So it does feel like second class citizen.
On another hand, if ubi’s work fine — that means there should be no technical limitation to keep Ubuntu working.
I’ll keep playing with Podman for now, but will switch to Incus if that will fail
Chromium choice is easy to explain due to PWA-shortcuts integration. That's less clunky than shipping Firefox with an extension or adding an external GUI PWA-manager.
