Re: [arch-general] IBus Qt

[Jiachen YANG via arch-general]

On 2018年05月10日 10:30, Grady Martin via arch-general wrote:
> From :
>
>> Additionally, to enable IBus for Qt applications, install the ibus-qt
>> library.
>
> Since 2012, I have used IBus with Qt applications and have yet to
> encounter a single problem, yet I have never installed ibus-qt.  Can
> anyone clarify this statement from the wiki?

Hi, I am only using Fcitx in recent years but I think the need for IM
Modules is the same for both fcitx and ibus, so I will try answer this
with my experience.

ibus-qt package provides IM Module shared objects (dynamic libraries)
for qt applications. IM modules are small instrusive loadable libraries
that are initiated by the application, and are talking to the IME server
(ibus/fcitx/etc.) on a native IPC protocol (usually dbus these days).
Without IM Modules (when not installed or non-qt/gtk applications), the
application usually fallback to an old protocol called XIM. The
existence of XIM is why you can type without ibus-qt installed.

XIM is an old protocol which did not consider async communications by
design, so it is inherently buggy. For simple IME engine and application
scenario, modern day PC specs may hide XIM's buggy behavior. But as soon
as you start to use really advanced IME engines (those developped with
predictions and machine learning algorithms, large databases, often used
by Chinese/Japanese users) in modern applications (with multiple threads
handling rendering and inputs), characters you typed start to go all
over the place, with a reasonable typing speed. High speed CPU/IO will
not hide this because IME engines for East Asian languages are designed
to fully utilize the CPU time between user input intervals, to provide
better predictions with larger database.

IM modules are designed to fix XIM's buggy behavior, and they can
provide far more context information than XIM protocol. Also I believe
wayland sessions cannot use XIM for native wayland applications, and
wayland's native IM protocol is far from ready.

So while you may still type in Qt applications with ibus without ibus-qt
installed, I think this should still be a general recommandation for
most users.




signature.asc
Description: OpenPGP digital signature

[arch-general] IBus Qt

[Grady Martin via arch-general]

From :



Additionally, to enable IBus for Qt applications, install the ibus-qt library.


Since 2012, I have used IBus with Qt applications and have yet to encounter a 
single problem, yet I have never installed ibus-qt.  Can anyone clarify this 
statement from the wiki?

Re: [arch-general] Stronger Hashes for PKGBUILDs

[Leonid Isaev via arch-general]

On Wed, May 09, 2018 at 09:30:51PM +0200, Neven Sajko wrote:
> I would just like to note that SHA-2 hashes are inferior to Keccak and
> to BLAKE2. So better not to spend effort migrating to SHA-2.

Strength of various SHA hashes is a different topic. My only point was that
relying on md5 these days is like having no hashes at all or using the source
filename as a hash...

And there should be no migration -- when a new version of a package is released
or a rebuild happens, just update the *sums array.

Cheers,
-- 
Leonid Isaev

Re: [arch-general] Stronger Hashes for PKGBUILDs

[David C. Rankin]

On 05/08/2018 10:38 PM, Eli Schwartz via arch-general wrote:
> This is honestly a much better use of everyone's time.

It is indeed a rare occurrence to see the uncommon common sense rear its
lonely head from time to time... but comforting.

-- 
David C. Rankin, J.D.,P.E.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Stronger Hashes for PKGBUILDs

[Neven Sajko via arch-general]

I would just like to note that SHA-2 hashes are inferior to Keccak and
to BLAKE2. So better not to spend effort migrating to SHA-2.

Re: [arch-general] Missing rc-local.service

[Jelle van der Waa]

On 05/09/18 at 02:17am, Marek Howard via arch-general wrote:
> Hello,
> 
> I'd like to use /etc/rc.local and noticed, that there's something
> called systemd-rc-local-generator which should somehow pull in
> rc-local.service on boot, according to its man page. But on my
> ArchLinux, the service file isn't there, and neither does /etc/rc.local
> run on boot.

When we migrated to systemd we basically stopped promoting (or even
supporting) rc.local. The alternative is to write a systemd unit which
have a lot of benefits. (finer grained control, etc.) 

> Is the systemd in ArchLinux packaged correctly?

Well it might be an upstream bug, since the man page is installed but
the binary.

-- 
Jelle van der Waa


signature.asc
Description: PGP signature