On 1/12/20 9:38 AM, Luya Tshimbalanga wrote:
The challenge about upstream is when they lack activity for years and
contributions are very difficult when users lack knowledge of coding
without proper guidance. For example, attempting to improve say
CellWriter (sorely missing due to the lack of port to Wayland
compositor) and howdy, a Windows Hello facial recognition like for
convertible laptops turned out too much as a graphic designer and
trying to get someone knowing to code turned out complex than
anticipated.
Only options is to actively test and give input so far.
Deepin Linux seems to have a face recognition login (or at least support
for this), but still searching for the implementation. The two PAM based
authentications (Howdy and PAM-facial-auth):
https://github.com/devinaconley/pam-facial-auth
https://github.com/boltgolt/howdy
seem to suggest they are not intended when high security is required.
Tests on manufacturer developed authentication also seem to suggest not
so secure:
https://www.blackhat.com/presentations/bh-dc-09/Nguyen/BlackHat-DC-09-Ngu...
However, a number of banks and KFC do use this in China, so maybe a good
open source implementation is missing (something other than a trial
version). Most of these rely on machine learning algorithms, maybe
something machine learning SIG might be interested in.
Perhaps collaboration across distributions on upstream projects may be
good, for example as done for 389 directory server by openSuse and
Redhat. In cases with no direct funding, Apache foundation is helpful
for large projects, but it seems unlikely that all projects are suitable
for it.
On 2020-01-07 6:08 a.m., Colin Walters wrote:
>
> On Tue, Jan 7, 2020, at 6:41 AM, Tom Hughes wrote:
>> I'd love to find a way to directly integrate the likes of gem, npm
>> etc directly into our packaging rather than us having to repackage
>> everything by hand but I just don't see any way of doing it without
>> compromising what we do to the extent that we're not really doing
>> anything useful at all and are just shoveling out whatever nonsense
>> upstreams perpetrate without question.
> Implicit in this is the idea that value should be captured at a
> secondary distribution layer. Implicit in this is the idea that
> distribution forks *need* to happen. But they don't.
>
> In fact, everyone here can work upstream too! If e.g. someone
> upstream messes up licensing, the mindset shouldn't be "oh man those
> upstream developers are incompetent, let's patch it downstream".
>
> Join upstream. Review *code* not spec files. Fix *code* not spec
> files. That's the most valuable thing for FOSS - not spec files.
The spec
files are useful in ensuring a repeatable build procedure and
checks on licenses. It is already quite a task to get those done. Code
review for large software projects can be quite challenging (so much so
that people would pay for this when they really need it). It would
however be good to encourage code review. What guidelines would be
proposed for this? Would such software have special recognition in the
repositories? What would one do for code review of dependencies?
>>
>> If there's an upstream that isn't doing the right thing
>> (consistently) - fork the upstream, don't fork it at the package
>> level. That way, work can be shared across multiple distributions.
>>
>> Even ignoring others, the Red Hat ecosystem today has 3 distributions
>> - it's simply better to work upstream as much as possible, and avoid
>> duplicating work across those 3 downstreams.
>> _______________________________________________
>> devel mailing list -- devel(a)lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>> Fedora Code of Conduct:
>>
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>>
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>