From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Received: by 2002:a0c:b757:: with SMTP id q23mr4183586qve.213.1583245816430; Tue, 03 Mar 2020 06:30:16 -0800 (PST) X-Received: by 2002:a9d:7617:: with SMTP id k23mr3344097otl.329.1583245816032; Tue, 03 Mar 2020 06:30:16 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 3 Mar 2020 06:30:15 -0800 (PST) In-Reply-To: <7dfe88e3-d509-49d1-998c-ce494133890c@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=146.5.2.231; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 146.5.2.231 References: <7dfe88e3-d509-49d1-998c-ce494133890c@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <76465f52-3e93-4b31-9e51-bd56b1bafb11@googlegroups.com> Subject: Re: linux desktop in trouble From: Shark8 Injection-Date: Tue, 03 Mar 2020 14:30:16 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:58162 Date: 2020-03-03T06:30:15-08:00 List-Id: On Tuesday, March 3, 2020 at 2:45:40 AM UTC-7, Mehdi Saada wrote: > https://www.zdnet.com/article/the-linux-desktop-is-in-trouble/ > How easier would it be if they weren't using messed-up tools to begin wit= h, if they had the intelligence to let compilers do more of the work for th= em ? > How much less work hours in maintenance and errors correcting ? It seems to me that a lot of the problems in that article stem from design.= Take installation: the article says "but under the surface, there are half= -a-dozen different ways to install programs." =E2=80=94 The proper solution= here is to provide at least a proper interface for install/uninstall, like= Ada does for allocaters, or possibly a whole subsystem. In terms of programming languages, the problems cited in that article are s= imply the result of the C mentality: prioritizing simplicity over correctne= ss or completeness. =E2=80=94 This is opposed to the Ada mentality of doing= things foremost correctly which, arguably, could be the theme of several o= lder OSes like the Burroughs MCP, Multics, and perhaps OpenVMS. In order to really solve these problems, you would have to design the OS (f= rom the ground up) to address these issues; IIRC some of the above-mentione= d OSes did so, at least for various subsystems. (OpenVMS, for example, had = a very nice networking subsystem [based on the OSI model, IIRC] where clien= t-programs were unaware of the network-connection protocols.)