In my opinion, that's because X11 lacks proper abstract for many things like screenshot, screencast, color managerment and etc, so the applications have to use many X11 implementation details to implement these features. It leads to high-coupling code with X11 so move their code to wayland and ensuring it works correctly and is consistent with the old behavior is difficult.
Coelacanthus
joined 1 year ago
That may be because the hostname can't be resolved.
https://forum.suse.org.cn/t/topic/12280 (Chinese)
https://bugzilla.mozilla.org/show_bug.cgi?id=1296836 (upstream report)
They doesn't use normal beta channel, and publish a new application named Bitwarden Beta.
https://play.google.com/store/apps/details?id=com.x8bit.bitwarden.beta
Yeah. Bitwarden developed a new android client written by Kotlin to replace old C# client. This new client is in beta testing currently. The old client supports both PascalCase and camelCase but the new client only supports camelCase. And Vaultwarden use PascalCase now, so it's incompatible with new Android client.
Hope this Pull Request could be merged soon so I can use it with new Bitwarden native Android client.
More common word in Chinese is 自制 zì zhì. 土法 focuses on "easy to implement with simple tool and material" but 自制 focuses on "do it by yourself".
I use Yubikey 5 NFC and Canokey Pigeon, both works out of box on Linux.
I don't think Sidebery is a great implementation unless the developers fix this bug. It can be reproduced stably and is important for users who opened many tabs and keep them between session.
It's better to integrate Tree Style Tab addon instead. It's not a good idea to re-implement a function which already has a great implementation...
Maybe you can do both: physical USIM card, but with eSIM functions. So you can move your profile from one phone to another just by plug out and plug in, and install many profiles on one phone and switch between them. There are some products can do it, such as eSIM.me, esim.5ber.com or https://github.com/estkme-group .
view more: next ›
The problem is not caused by mono kernel. Just because AMDGPU driver was developed in mono style. i.e. they include the code of all generations in one driver. In monolithic kernel, the developer can develop drivers with "micro" style. e.g. Intel's GPU driver doesn't use mono style, they created a new driver when they changed GPU hardware architecture.
Monolithic kernel is a concept about address space. If all parts of a kernel are running in the same address space, this is a monolithic kernel, otherwise it's a micro kernel.
This problem is about how to split parts, but not how to place parts in memory.