Path: ...!weretis.net!feeder9.news.weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Python (was Re: I did not inhale)
Date: Mon, 19 Aug 2024 21:09:57 +0200
Organization: A noiseless patient Spider
Lines: 171
Message-ID: <va05a6$2vsf9$1@dont-email.me>
References: <uu54la$3su5b$6@dont-email.me> <20240408075547.000061e8@gmail.com>
 <g52cnWOOwoz_son7nZ2dnZfqnPWdnZ2d@brightview.co.uk>
 <uvbe3m$2cun7$1@dont-email.me> <uvbfii$3mom0$1@news.xmission.com>
 <20240412094809.811@kylheku.com> <87il0mm94y.fsf@tudado.org>
 <way-20240413091747@ram.dialup.fu-berlin.de> <87il0lldf8.fsf@tudado.org>
 <choices-20240413123957@ram.dialup.fu-berlin.de>
 <v9lm2k$12qhv$1@dont-email.me> <v9m4gd$14scu$1@dont-email.me>
 <20240815182717.189@kylheku.com> <v9npls$1fjus$1@dont-email.me>
 <v9posc$1rpdj$1@dont-email.me> <v9pvoo$1sn55$1@dont-email.me>
 <v9r60h$2289h$2@dont-email.me> <v9sa91$2afht$1@dont-email.me>
 <v9tv8o$2iahp$1@dont-email.me> <v9uso3$2pdrg$2@dont-email.me>
 <v9v0e0$2q822$1@dont-email.me> <v9v7d4$2r6q2$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 19 Aug 2024 21:09:58 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f833deded671d14d9dc64f84d09e50d3";
	logging-data="3142121"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+oqaBcIJQqs1DHKzpUXj0c6hBhCwyawiY="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:/RUUV+03DXDapuvdVXskX5cnQns=
Content-Language: en-GB
In-Reply-To: <v9v7d4$2r6q2$1@dont-email.me>
Bytes: 10517

On 19/08/2024 12:39, Dmitry A. Kazakov wrote:
> On 2024-08-19 10:40, David Brown wrote:
>> On 19/08/2024 09:37, Dmitry A. Kazakov wrote:
> 
>>> Both OSes contributed to the Dark Ages of computing. The reasons are 
>>> not technical, because both were worst on the market. 
>>
>> What sort of time-frame are you thinking of here, what were the 
>> alternatives that you think were "better", what markets or uses are 
>> you considering, and in what way were other OS's "better" ?
>>
>> There's no doubt that non-technical issues have had a big influence on 
>> which OS's or types of OS have succeeded, but you seem to have 
>> something specific in mind.
> 
> I think the main reason is that we do not pay the actual costs of 
> software developing. OS, compiler require huge investments. Vendors 
> never passed these to the end users funding developing from other 
> sources. That effectively killed the market. Free software only 
> aggravated the situation. In effect it is akin to the socialist 
> production method which always kills quality.

Experience shows that commercial software vendors rarely passed the real 
costs on to the users - they often pass vastly higher charges on to the 
user for software than it cost to develop the software.  Other times, 
they might charge very little or nothing because they have other sources 
of income, such as giving away the main software and charging 
subscription fees for add-on features.  There are all sorts of models - 
free and open source software provides different models.  At my company, 
the software we write is closed source, but we never charge for licenses 
for it.  Customers either pay for the time used in development, or they 
pay for it as part of the cost of the electronics boards we make for them.

If you use, for example, gcc or Linux, you don't pay the costs directly. 
  But you /do/ pay them indirectly.  The solid majority of development 
for major free and open source projects is paid work.  Intel and ARM pay 
developers to work on gcc - every time you buy a device with an Intel or 
ARM processor in it, you are paying a little towards gcc.  Google pays 
for Linux development - every time you buy a new pair of shoes, some of 
what you pay goes to the manufacturer's advertising budget, some of 
which goes to Google, some of which goes to Linux development, so that 
Google's servers can use a steadily better quality OS to serve up those 
adverts.

It all goes around - there's always money there, somewhere.

Just like any other kind of competition, free and open source has been 
disruptive in many software markets where some companies were used to 
spending some money on development, then living off that software for 
years as nearly pure profit.  It has forced other companies to change 
models - making their software better, or providing better support.  But 
it hasn't killed the good quality, imaginative and flexible software 
companies.  In the embedded development world, there are large numbers 
of compilers available at a range of prices because they offer something 
that pure gcc does not - support, certification, additional tools, 
training, libraries, specialised extra features, or whatever.  Other 
companies exist by taking gcc (or clang) and adding more and charging 
for it.  These markets were not /killed/ by free and open source 
compilers - they were /created/ by them.

And customer companies - successful, well-run ones at least - are still 
quite happy to pay a lot of money for software if it does a better job 
than equivalent free software, saving them money in the end.  At my 
company we have bought compilers when they were better tools for the job 
than free tools.  But they have to be /better/ - not just more 
expensive, and they have to be better enough to justify the price. 
Usually, they are not.

So no, free and open source development does not "kill quality" or "kill 
markets".  It is often /better/ quality than commercial alternatives, at 
least in some ways, and it forces commercial alternatives to improve 
their quality and cost-effectiveness.  It does not /kill/ markets - it 
/changes/ them.  It spells the end for some suppliers, and opens up 
opportunities for new ones, just like progress always does.

People who complain about how free and open source software has killed 
their businesses are like saddle-makers sitting about complaining about 
how the car killed their markets, while their competitors have switched 
from making saddles to opening car repair shops.

> 
>> Windows has locks on files, which are a different thing.  While I can 
>> understand the point of them, they can be a real inconvenience (try 
>> deleting a directory tree when a file from that tree is in use).
> 
> Oh, yes! I understand why I should not remove a locked file, but I still 
> enjoy Linux's ability to remove anything an be it all damned!
> 
> The usual case is when Windows locks some file on the Linux Samba server 
> share for some mysterious reason. It is a sheer fun to log into the 
> server do "rm -rf" on the file and then go back to Windows: "eat that!"
> 
>>> Under Linux you must log in as the root and remove the stray file 
>>> lock manually. It happens in UNIX administration all the time.
>>
>> As someone who has administrated Linux servers for decades, and used 
>> it as my desktop OS on many machines, I am not sure I can ever 
>> remember removing a stray lock file.  Certainly needing to do so "all 
>> the time" is a very wild exaggeration.  Linux, like all systems, 
>> undoubtedly has its flaws and weaknesses, but this is not one of them 
>> IME.
> 
> In main case it is packet manager. I am too lazy to find how to turn off 
> automatic update checks. So when I try to run apt or dnf I have to kill 
> the lock.

Right... so your big complaint against Linux is actually due to your own 
laziness and weird way of updating your system.  (Like many Linux users, 
I have automatic update checks enabled /and/ I use "apt" or other 
package managers when I want to - without problems with lock files.)

> 
>> Times change.  Needs and uses change.  Hardware changes.
>>
>> Keeping things separate and modular has advantages in scalability, 
>> security and stability.  Keeping things monolithic has advantages in 
>> efficiency (speed and memory) and consistency.  There is no "right" 
>> answer.
> 
> Yes. E.g. in automotive you still need the system booted right after you 
> turned the key.
> 
> Initially an ability to trim the system and sometimes to patch a driver 
> was a huge advantage Linux had over Windows NT.
> 

It still is, for those with such niche needs that it is worth the effort.

>>> On the other hand you still cannot have decent gaming under Linux.
>>
>> I do almost all my gaming under Linux.  Some games do work better 
>> under Windows, but that is primarily because most games developers 
>> target Windows as their main platform.  It may also be because Linux 
>> systems are more varied.
> 
> "You are in an open field on the west side of a white house with a 
> boarded front door." That sort of games? (:-))
> 

No, RTS, FPS, that sort of thing.  I don't do a lot of fast-action 
gaming these days - my reactions are not those of a kid any more!  And 
my PC is not optimised for very demanding games.  But most (80%+) Steam 
games run as well on Linux as on Windows, on the same hardware.  I see 
some games have trouble on Linux, and some run better (especially older 
ones that find modern Windows confusing).

Overall, if someone wanted a pure gaming PC, I'd recommend Windows over 
Linux - but it's absolutely fine for casual gaming.

>>>> And single drive letters?
>>>
>>> They are dozens characters long actually, if you mean the device names.
>>
>> I thought by "drive letters", he meant "drive letters" - "c:", "d:", etc.
> 
> The official file name of "C:" would be some messy string with lots of 
> backslashes. C: is a "DOS name." There are API to convert DOS names into 
> proper names. It is a mess. All Windows API is a mess.
> 

The file path the user sees regularly starts with a driver letter. 
Users don't see API's.

It is a /long/ time since I have had to deal much with Windows APIs 
directly.  I remember such joys as a "CreateFile" call that you needed 
to do things like open a comms port or handles to many other types of 
devices or interfaces, but which was not useable for creating files. 
These days my Windows programming is almost all in Python - so dealing 
========== REMAINDER OF ARTICLE TRUNCATED ==========