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-Nguyen-Face-not-your-password-slides.pdf
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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
