I fully agree concerning an engineering background.
However, any good practitioner (with, like Heaviside, credentials
equivalent to both academic intellectual education and practical field
experience, irrespective of formal diplomata -- today, the diploma seems
the most important and a Heaviside probably would be impossible) should
have the requisite software engineering techniques and skills. My
concerns are two-fold -- lack of such techniques and skills, and lack of
sufficient work-fraction to do the work (e.g., for which the work is not
gainful employment). For some things, such as say, Calibre or
TexStudio, it is less of a concern that these applications
professionally are constructed or maintained (these actually are);
however, systems software are of such a concern, including both
reliability as well as "hardening" against compromise.
On 12/31/20 8:02 AM, Lamar Owen wrote:
> On 12/31/20 12:05 AM, Yasha Karant wrote:
>> ... It is difficult, but not impossible, to have a distro that does
>> not have computer science and engineering professionals ... doing the
>> implementation that is suitable for "hardened" production use,
>> including converting a distribution source into a functioning
>> alternately badged but otherwise identical "executable" distribution.
>
> In my opinion and for software that I will approve for use at $dayjob,
> developers doing "professional" release engineering and management for
> any software really should have solid software engineering backgrounds,
> not just computer science backgrounds. Since I do this sort of
> evaluation on a professional basis, I am using the ACM's definitions of
> those fields as defined in "Computing Curricula 2005: The Overview
> Report" as well as the individual, updated, curricula as found on the
> ACM's page at
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.acm.org_education_curricula-2Drecommendations&d=DwIFAw&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=J_y_RQ_m1wBDNa6puHIKs0qD-PVYaEuxw9yvER0cVXo&s=9h8AR-p_2yNK1ZunKeU1c78tSEzoHsVXrIyUejk4EVc&e=
> . I do this sort of research for any high-value software, whether
> commercial or not, especially if there is a budget line item associated
> with it or if it is core infrastructure such as the primary server OS to
> run.
>
> One reason I was so very comfortable with CentOS is that I've done my
> homework on the developers' professional backgrounds, which passed
> muster for my purposes; I was equally comfortable with Scientific Linux
> even before it was called that, but the larger base behind CentOS made
> the decision for me between those two, which I annually reviewed. It
> helps a great deal that I've been acquainted with many of these folks
> (both CentOS and SL) for over 20 years, and have seen their track
> records. And track records trump degrees and titles for my purposes.
>
> Track records makes it all the more difficult for me to choose a CentOS
> Linux replacement today; even just counting the RHEL rebuilds, there is
> quite a bit of choice, between Oracle, Springdale, CloudLinux Project
> Lenix, Rocky, and even CentOS Stream. The evaluation rubric is much
> larger now than it was when PUIAS, WhiteBox, and CentOS started.
>
> In my over fifteen years experience here, primarily with CS interns, I
> have found that much of the time a computer science background alone is
> not enough; proper release engineering and management requires
> sub-disciplines that aren't necessarily found in the typical CS
> curriculum (learning such out-of-major disciplines is one goal of a good
> internship, in my opinion; the discipline of effectively and
> consistently using things like source code revision control, for
> instance). Now, information systems or information technology
> backgrounds (again, using the ACM's definitions) can be highly useful
> toa project, mostly for process management and business alignment (on
> the IS side) or infrastructure management (on the IT side), but the core
> discipline needed for release management is SE.
>
>> My observation about the paywall was simply that public archived
>> discussions are needed to trace back both proper attribution (even if
>> not for-fee property) as well as to verify the current state of any
>> particular implementation.
> In my opinion, requiring a login of any kind to access archives means
> the discussion isn't public by definition, even if anyone can join; many
> mailing lists even have a 'members-only' archive policy. I too have a
> bit of a problem with certain communications channels that seem to be
> very popular these days, but at the same time, in open source projects
> at least, the people who do the work should be able to choose the tools
> they use to do that work. But, one of the side effects of this
> Instagram/SnapChat/Discord/Tiktok world is that the value of archives
> seems to not be fully appreciated (I won't elaborate here on how well I
> know this in terms of astronomy in general and radio astronomy in
> particular).
> --
> They say hindsight is 20/20;
> I'm looking forward to 2020 becoming hindsight.
|
