1 |
David Seifert wrote: |
2 |
> > Maybe because it is so well-known that monoculture is harmful per se, |
3 |
> > which is why the commitment to choice in Gentoo is very valuable. |
4 |
> > |
5 |
> > Further, LibreSSL comes out of the OpenBSD project, which has a good |
6 |
> > reputation on code quality. |
7 |
> |
8 |
> Like strong-arming 99% of the users of OpenSSH because they were |
9 |
> unwilling to port to the OpenSSL 1.1 API, fully well knowing that most |
10 |
> of the OpenSSH consuming world doesn't actually use libressl? How is |
11 |
> explicitly tying OpenSSH to libressl not a form of monoculture? |
12 |
|
13 |
Now we're properly off-topic :) but considering that OpenSSH is developed |
14 |
for OpenBSD and that openssh-portable is merely provided as a service to |
15 |
other systems it's easy to understand why OpenSSH (remember, part of OpenBSD) |
16 |
uses the libressl API for crypto, and why the -portable team is not so keen |
17 |
on maintaining patches for other crypto providers. Another example is systemd |
18 |
binding tightly to Linux. In both cases it's understandable, but also quite |
19 |
unfortunate; better portability would be better. |
20 |
|
21 |
|
22 |
> Case in point: Have you tried using the official libjpeg package instead |
23 |
> of libjpeg-turbo? Go ahead, give it a try. |
24 |
|
25 |
I'll take a look. I chose libjpeg-turbo for a project because it |
26 |
cross-compiled better. |
27 |
|
28 |
|
29 |
> "Monoculture"s are mostly a coincidence, not some sinister conspiracy. |
30 |
|
31 |
I don't claim conspiracy, I just say that it's healthy to avoid them. |
32 |
|
33 |
|
34 |
> Implementation-diversity-but-API-compatibility is mostly a |
35 |
> pipe dream, as libav, imagemagick, libjpeg have shown. |
36 |
|
37 |
I've been fortunate to have a different experience with other codebases. |
38 |
|
39 |
It's completely possible, but takes (extra!) effort, meaning you have |
40 |
to really want it. If there is some rivalry then it's also quite easy |
41 |
to sabotage your colleagues. |
42 |
|
43 |
|
44 |
//Peter |