Re: Python (was Re: I did not inhale)

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 with the API is an SEP.