"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
[...]
> 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.

I think you mean "package manager".

[...]

> 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.

I happen to be typing this on a Windows laptop (via ssh to another
system). The system drive is called "C:", and I don't know of any other
name by which I can refer to it. If I examine its properties in Windows
Explorer, it appears to have the label "Acer", but that's not the "messy
string with lots of backslashes" you referred to.

It strikes me that "C:" is the drive's "official" name in any reasonable
sense of the word.

What API are you referring to, what can I expect it to give me as the
"official" name of my C: drive, and what could I do with that name?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> On 2024-08-19 10:45, Lawrence D'Oliveiro wrote:
>> On Mon, 19 Aug 2024 09:37:39 +0200, Dmitry A. Kazakov wrote:
[...]
>>>> And single drive letters?
>>>
>>> They are dozens characters long actually, if you mean the device names.
>> Drive names are only single letters. You’re not talking about
>> reserved
>> file names, are you?
>
> No, I am talking about proper file paths under Windows. Letters is a
> DOS layer on top of it. E.g. see QueryDosDeviceW call.

OK, I tried a test program that invokes QueryDosDeviceW() on L"C:".
The result was "\Device\HarddiskVolume4". (That's not a C string
literal. It contains two single backslash characters.)

What can I do with that string? In what sense is it more "official"
than "C:", or "Acer": (the volume's label), or "B64F-C8F7" (the
volume's serial number)?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

On Mon, 19 Aug 2024 13:14:00 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> I happen to be typing this on a Windows laptop (via ssh to another
> system). The system drive is called "C:", and I don't know of any
> other name by which I can refer to it. If I examine its properties
> in Windows Explorer, it appears to have the label "Acer", but that's
> not the "messy string with lots of backslashes" you referred to.
>
> It strikes me that "C:" is the drive's "official" name in any
> reasonable sense of the word.
>
> What API are you referring to, what can I expect it to give me as the
> "official" name of my C: drive, and what could I do with that name?

NT has its own low-level scheme for identifying devices/representing
file paths. If you're curious, someone at the Google compound did a
write-up on it some years back:
https://googleprojectzero.blogspot.com/2016/02/the-definitive-guide-on-win32-to-nt.html

For most practical purposes, users and user-level application software
pretty much never see this or have to think about it - but it *is*
there, and it does cause strange corner-case behavior sometimes. (I'm
pretty sure the underlying reason why cmd.exe sometimes cannot access
network shares mapped to a conventional drive letter has to do with
this, f'rinstance.)

On 2024-08-19 22:28, Keith Thompson wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> On 2024-08-19 10:45, Lawrence D'Oliveiro wrote:
>>> On Mon, 19 Aug 2024 09:37:39 +0200, Dmitry A. Kazakov wrote:
> [...]
>>>>> And single drive letters?
>>>>
>>>> They are dozens characters long actually, if you mean the device names.
>>> Drive names are only single letters. You’re not talking about
>>> reserved
>>> file names, are you?
>>
>> No, I am talking about proper file paths under Windows. Letters is a
>> DOS layer on top of it. E.g. see QueryDosDeviceW call.
>
> OK, I tried a test program that invokes QueryDosDeviceW() on L"C:".
> The result was "\Device\HarddiskVolume4". (That's not a C string
> literal. It contains two single backslash characters.)
>
> What can I do with that string?

You can use it in CreateFile. In fact there are cases when you should. I
remotely remember a problem determining if the file is same and opening
it. It failed miserably on letters created by the SUBST command.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On Mon, 19 Aug 2024 13:03:23 +0200, Dmitry A. Kazakov wrote:

> Well, handheld gaming to gaming is like masturbation to love. Sorry...
>
>> Microsoft has been talking about bringing out a
>> Windows “Handheld Mode” for about two years now, but still has nothing
>> to ship.

So what do you think Microsoft has been doing with its hands all that
time? ;)

> On 2024-08-19 10:45, Lawrence D'Oliveiro wrote:
>>
>> On Mon, 19 Aug 2024 09:37:39 +0200, Dmitry A. Kazakov wrote:
>>
>>> On 2024-08-19 01:14, Lawrence D'Oliveiro wrote:
>>>
>>>> On Sun, 18 Aug 2024 10:10:09 +0200, Dmitry A. Kazakov wrote:
>>>>
>>>>> Windows has a pipe object named and anonymous. No problem.
>>>>
>>>> One problem: you can’t use them with poll/select calls.
>>>
>>> You can. See overlapped I/O.
>>
>> I said “poll/select calls”. Do you not know what those are? On Windows,
>> they work with sockets, but not with pipes. Or even ordinary files. So
>> unlike *nix systems, you have to keep in mind the different kinds of
>> files you might be working with.
>
> Again. It is called overlapped I/O. You can start multiple
> *asynchronous* I/O operations from a thread.

I’m not talking about using threads. I’m talking about avoiding threads,
and all their potential for difficult-to-fix race-condition-type bugs.

I’m talking about situations where the bottleneck is the I/O, not the CPU,
so multithreading gets you nothing.

On 2024-08-19 21:09, David Brown wrote:

> 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.

It is no complain, merely stating an elementary economic fact. If the
price does not reflect the costs, there is no market. No market, no
competition. No competition, no quality.

One could argue that there cannot be software market at all for
costs-intensive stuff like OS and compilers similarly to the communal
infrastructure like roads etc. That might be but it is another question.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 2024-08-20 01:03, Lawrence D'Oliveiro wrote:
> On Mon, 19 Aug 2024 13:03:23 +0200, Dmitry A. Kazakov wrote:
>
>> Again. It is called overlapped I/O. You can start multiple
>> *asynchronous* I/O operations from a thread.
>
> I’m not talking about using threads. I’m talking about avoiding threads,
> and all their potential for difficult-to-fix race-condition-type bugs.
>
> I’m talking about situations where the bottleneck is the I/O, not the CPU,
> so multithreading gets you nothing.

It seems you suffer some form of dyslexia. I clearly stated that all
instances of overlapped I/O is started from the same/single/one thread.
Better now?

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On Tue, 20 Aug 2024 08:52:27 +0200, Dmitry A. Kazakov wrote:

> It is no complain, merely stating an elementary economic fact. If the
> price does not reflect the costs, there is no market. No market, no
> competition. No competition, no quality.

Elementary economic fact: in a competitive market, the unit price of the
product tends to converge towards the marginal cost of producing that
product.

What’s the marginal cost of producing a copy of a piece of software?
Essentially, zero.

On Tue, 20 Aug 2024 08:57:07 +0200, Dmitry A. Kazakov wrote:

> On 2024-08-20 01:03, Lawrence D'Oliveiro wrote:
>
>> On Mon, 19 Aug 2024 13:03:23 +0200, Dmitry A. Kazakov wrote:
>>
>>> Again. It is called overlapped I/O. You can start multiple
>>> *asynchronous* I/O operations from a thread.
>>
>> I’m not talking about using threads. I’m talking about avoiding
>> threads, and all their potential for difficult-to-fix race-condition
>> -type bugs.
>>
>> I’m talking about situations where the bottleneck is the I/O, not the
>> CPU, so multithreading gets you nothing.
>
> It seems you suffer some form of dyslexia. I clearly stated that all
> instances of overlapped I/O is started from the same/single/one thread.
> Better now?

Do I need to repeat that this has nothing to do with threading?

On Mon, 19 Aug 2024 13:30:05 -0700
John Ames <commodorejohn@gmail.com> boringly babbled:
>NT has its own low-level scheme for identifying devices/representing
>file paths. If you're curious, someone at the Google compound did a
>write-up on it some years back:
>https://googleprojectzero.blogspot.com/2016/02/the-definitive-guide-on-win32-to
>-nt.html
>
>For most practical purposes, users and user-level application software
>pretty much never see this or have to think about it - but it *is*
>there, and it does cause strange corner-case behavior sometimes. (I'm
>pretty sure the underlying reason why cmd.exe sometimes cannot access
>network shares mapped to a conventional drive letter has to do with
>this, f'rinstance.)

To sum up, Microsoft have made a complete dogs dinner of something as simple
and basic as file paths. You couldn't make it up.

Can Windows do non-root level filesystem mounting yet? Ie unix can mount a
new filesystem anywhere in the current filesystem hierarchy.

On 20/08/2024 08:52, Dmitry A. Kazakov wrote:
> On 2024-08-19 21:09, David Brown wrote:
>
>> 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.
>
> It is no complain, merely stating an elementary economic fact. If the
> price does not reflect the costs, there is no market. No market, no
> competition. No competition, no quality.

That's an easy claim to make - saying something that sounds obvious and
calling it a "fact". But that does not make it true in general.

There are endless numbers of situations where price and cost are highly
out of sync. And there are endless different ways in which price and
cost can be measured for different things.

Most "elementary economics" is based on the idea of physical production
- to make each whotsit, a company buys in parts for a cost $A, uses
employee time for a cost $B, and sells it for a price $C. Profit is
then $C - ($A + $B). You make more money by reducing A or B, or
increasing C. Production scaling is just multiplication. Competition
comes from others making whotsits for lower prices, or with higher worth.

Software development, licensing and sale is /totally/ different. The
cost models are completely different. Base cost is high, but unit cost
is near zero. Some software (like computer games) is, roughly speaking,
make once then sell lots - for other kinds of software, it's a
continuous process. Some is sold, some is effectively rented out. Some
is given away free in order to sell other products (like support deals,
or hardware). The same license can be sold in one situation for 100
times the price of a different situation.

>
> One could argue that there cannot be software market at all for
> costs-intensive stuff like OS and compilers similarly to the communal
> infrastructure like roads etc. That might be but it is another question.
>

That might be a slightly less bad model than the traditional cost/price
market model, but it's not good either. Software is in a very different
category from "real" things - and indeed there are many different
categories of software with very different economic models. Any attempt
to compare it to traditional economic market theory is doomed to be of
little relevance.

The success or failure of software companies or products is mostly a
combination of skill, hard work, diplomacy, ruthlessness and luck - with
luck being perhaps the biggest part.

On 2024-08-20 09:21, Lawrence D'Oliveiro wrote:
> On Tue, 20 Aug 2024 08:52:27 +0200, Dmitry A. Kazakov wrote:
>
>> It is no complain, merely stating an elementary economic fact. If the
>> price does not reflect the costs, there is no market. No market, no
>> competition. No competition, no quality.
>
> Elementary economic fact: in a competitive market, the unit price of the
> product tends to converge towards the marginal cost of producing that
> product.
>
> What’s the marginal cost of producing a copy of a piece of software?
> Essentially, zero.

No different from books, music records, reproductions. In these cases
the unit is more than just a copy. This is how concepts of intellectual
property get invented etc.

Again, I do not say what is right and what is wrong. Just stating facts.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On Tue, 20 Aug 2024, Dmitry A. Kazakov wrote:

> On 2024-08-20 01:03, Lawrence D'Oliveiro wrote:
>> On Mon, 19 Aug 2024 13:03:23 +0200, Dmitry A. Kazakov wrote:
>>
>>> Again. It is called overlapped I/O. You can start multiple
>>> *asynchronous* I/O operations from a thread.
>>
>> I’m not talking about using threads. I’m talking about avoiding threads,
>> and all their potential for difficult-to-fix race-condition-type bugs.
>>
>> I’m talking about situations where the bottleneck is the I/O, not the CPU,
>> so multithreading gets you nothing.
>
> It seems you suffer some form of dyslexia. I clearly stated that all
> instances of overlapped I/O is started from the same/single/one thread.
> Better now?
>

Don't you worry Dmitry, Lawrence is a first class troll and thrives on the
resistance you're giving him. My bet is, he'll just continues with his
tricks. Don't let him drive you crazy. =)

On 2024-08-20 09:44, David Brown wrote:

> That's an easy claim to make - saying something that sounds obvious and
> calling it a "fact".  But that does not make it true in general.

But sometimes it does.

> There are endless numbers of situations where price and cost are highly
> out of sync.  And there are endless different ways in which price and
> cost can be measured for different things.

Yes

> Software development, licensing and sale is /totally/ different.  The
> cost models are completely different.  Base cost is high, but unit cost
> is near zero.

Yes, and that is the problem. Not really a unique problem, e.g. books,
music records etc.

>> One could argue that there cannot be software market at all for
>> costs-intensive stuff like OS and compilers similarly to the communal
>> infrastructure like roads etc. That might be but it is another question.
>
> That might be a slightly less bad model than the traditional cost/price
> market model, but it's not good either.

.... counting the potholes ...

> Software is in a very different
> category from "real" things - and indeed there are many different
> categories of software with very different economic models.  Any attempt
> to compare it to traditional economic market theory is doomed to be of
> little relevance.

Maybe, but then we have what we have.

> The success or failure of software companies or products is mostly a
> combination of skill, hard work, diplomacy, ruthlessness and luck - with
> luck being perhaps the biggest part.

The question is sustainability in long term.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 20/08/2024 10:27, Dmitry A. Kazakov wrote:
> On 2024-08-20 09:44, David Brown wrote:
>
>> That's an easy claim to make - saying something that sounds obvious
>> and calling it a "fact".  But that does not make it true in general.
>
> But sometimes it does.

You are snipping a bit too much context - as it stands, it looks like
some things are true simply because they are easy to say, which is of
course nonsense.

I think your line of reasoning was too simplistic to be realistic. It
is simply not the case that you have to have price reflecting cost to
make a market, or that you have to have a market to have competition, or
that you have to have competition to have quality. None of these is
true in general (even taking into account that the term "market" could
be defined in many ways). Each of them is true in some cases, but even
that does not mean they follow as logical consequences.

>
>> There are endless numbers of situations where price and cost are
>> highly out of sync.  And there are endless different ways in which
>> price and cost can be measured for different things.
>
> Yes
>
>> Software development, licensing and sale is /totally/ different.  The
>> cost models are completely different.  Base cost is high, but unit
>> cost is near zero.
>
> Yes, and that is the problem. Not really a unique problem, e.g. books,
> music records etc.
>

Those are different situations again, but certainly closer than the
production of "wotsits". Traditionally, books and records have relevant
unit costs as well as base "development" costs, and then much of their
later income comes from sources invisible to end users (like film rights
or royalties).

I don't think any of this is a "problem", it is simply that you can't
wildly mix simplified (or invented) "economic facts" in totally
different situations.

>>> One could argue that there cannot be software market at all for
>>> costs-intensive stuff like OS and compilers similarly to the communal
>>> infrastructure like roads etc. That might be but it is another question.
>>
>> That might be a slightly less bad model than the traditional
>> cost/price market model, but it's not good either.
>
> ... counting the potholes ...
>
>> Software is in a very different category from "real" things - and
>> indeed there are many different categories of software with very
>> different economic models.  Any attempt to compare it to traditional
>> economic market theory is doomed to be of little relevance.
>
> Maybe, but then we have what we have.

It often surprises me that economic theories give any usable results at
all. Most are based on total gibberish with no relation to real life,
such as linear towns, totally rational customers, and such
simplifications that they are close to meaningless. They basically work
by the central limit theorem - with enough variables, results are fairly
near an average for much of the time.

>
>> The success or failure of software companies or products is mostly a
>> combination of skill, hard work, diplomacy, ruthlessness and luck -
>> with luck being perhaps the biggest part.
>
> The question is sustainability in long term.
>

Then luck is even more the biggest part. Predictions are hard,
especially about the future.

In comp.unix.programmer David Brown <david.brown@hesbynett.no> wrote:
> On 16/08/2024 17:02, Kalevi Kolttonen wrote:
>> In comp.unix.programmer Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>>> On 2024-08-15, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>> On Thu, 15 Aug 2024 19:48:36 -0000 (UTC), Kalevi Kolttonen wrote:
>>>>
>>>>> The last I checked, the O'Reilly Python book is just absolutely
>>>>> *MASSIVE*. The language has a huge number of features now ...
>>>>
>>>> No, it hasn’t. The core language reference spec is only a small fraction
>>>> of, say, the Java language spec.
>>>>
>>>> It’s just that you can do so many things with Python. And that is down to
>>>> the huge variety of off-the-shelf addon libraries that build on that core
>>>> language spec. It has to be a strong, very solidly founded core in order
>>>> to be such a versatile basis for these addons, and it is.
>>>
>>> That's idiotic; you're saying that the standard library packages of
>>> Python are not part of Python, and do not contribute to its size.
>>
>> You seem to have a point. The core of C language is also small. I
>> guess they even said in the original K & R book that C is a small
>> language best described by a small book.
>>
>> But in order to do anything with C, you need to know the standard
>> libraries. They have grown bigger and bigger during all these
>> years. One could also well argue that to program on UNIX, you also
>> need to know all the POSIX libraries.
>>
>
> Absolute nonsense.
>
> In order to use a programming language for a given task, you need to
> know the basics of the language and libraries appropriate for the task.
> You most certainly do not need to know all about the language, or all
> about all the libraries provided as standard for the language or the
> host OS.

I would not label it as "absolute nonsense". In order to program on UNIX,
you need to be familiar with the facilities that are available. I
know of a very smart man who ended up as a professor of physics who
programmed on Amiga back in the 1980s. Even though his PhD thesis
was something like 100-150 pages of strange-looking formulas, he said
he had problems with C on the Amiga. For some reason, he was unable
to remember what functions where provided as standard libraries, so
he always ended up writing his own functions instead of using libraries.

To know Linux, you need Michal Kerrisk's book the Linux Programming
Interface. I have this book, but admittedly you are kind of right:
It is large and I do not know every single part of it, but I have
studied it a lot and I am familiar with the most important features.

br,
KK

On Tue, 20 Aug 2024 14:21:38 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) boringly babbled:
>To know Linux, you need Michal Kerrisk's book the Linux Programming
>Interface. I have this book, but admittedly you are kind of right:
>It is large and I do not know every single part of it, but I have
>studied it a lot and I am familiar with the most important features.

Luckily not much has changed in core unix systems programming over the decades
(seems they got it mostly right first time) so Advanced Programming in the
Unix Enviroment by W. Richard Stevens is still a very relevant book to anyone
who wants to develop on unix.

On Tue, 20 Aug 2024 14:35:33 +0000, Muttley wrote:

> On Tue, 20 Aug 2024 14:21:38 -0000 (UTC)
> kalevi@kolttonen.fi (Kalevi Kolttonen) boringly babbled:
>>To know Linux, you need Michal Kerrisk's book the Linux Programming
>>Interface. I have this book, but admittedly you are kind of right:
>>It is large and I do not know every single part of it, but I have
>>studied it a lot and I am familiar with the most important features.
>
> Luckily not much has changed in core unix systems programming over the decades
> (seems they got it mostly right first time) so Advanced Programming in the
> Unix Enviroment by W. Richard Stevens is still a very relevant book to anyone
> who wants to develop on unix.

Agreed. APUE is one of my go-to books.

Note that Addison-Wesley released a new edition of APUE a decade or so ago
co-authored by WRS and Stephen Rago. That edition covered SUS version 4, and
(among others) Linux (up to kernel 3.2).

--
Lew Pitcher
"In Skills We Trust"

On 2024-08-20 15:09, David Brown wrote:
> On 20/08/2024 10:27, Dmitry A. Kazakov wrote:
>> On 2024-08-20 09:44, David Brown wrote:
>>
> I think your line of reasoning was too simplistic to be realistic.  It
> is simply not the case that you have to have price reflecting cost to
> make a market, or that you have to have a market to have competition, or
> that you have to have competition to have quality.  None of these is
> true in general (even taking into account that the term "market" could
> be defined in many ways).  Each of them is true in some cases, but even
> that does not mean they follow as logical consequences.

There are plenty historic examples illustrating the point.

>> Yes, and that is the problem. Not really a unique problem, e.g. books,
>> music records etc.
>
> Those are different situations again, but certainly closer than the
> production of "wotsits".  Traditionally, books and records have relevant
> unit costs as well as base "development" costs, and then much of their
> later income comes from sources invisible to end users (like film rights
> or royalties).
>
> I don't think any of this is a "problem", it is simply that you can't
> wildly mix simplified (or invented) "economic facts" in totally
> different situations.

It is a problem of rewarding the authors.

There is a whole spectrum of economic systems which redistribute costs
this or that way. Beginning with slavery. Free market is the best so far.

> It often surprises me that economic theories give any usable results at
> all.

Economy is not a science, it need not to produce any results. But it can
explain things. I think that lack of market force explains the state of
software developing quite well. But of course there could other
explanations.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

John Ames <commodorejohn@gmail.com> wrote or quoted:
>NT has its own low-level scheme for identifying devices/representing
>file paths.

We need to break down a few terms when we're chatting about Windows:

- the physical hard disk,

- volumes: partitions of that physical disk, and

- drive letters: labels slapped on a volume (not on a hard disk!).

(You can totally have volumes without a drive letter.)

In comp.unix.programmer Muttley@dastardlyhq.com wrote:
> On Tue, 20 Aug 2024 14:21:38 -0000 (UTC)
> kalevi@kolttonen.fi (Kalevi Kolttonen) boringly babbled:
>>To know Linux, you need Michal Kerrisk's book the Linux Programming
>>Interface. I have this book, but admittedly you are kind of right:
>>It is large and I do not know every single part of it, but I have
>>studied it a lot and I am familiar with the most important features.
>
> Luckily not much has changed in core unix systems programming over the decades
> (seems they got it mostly right first time) so Advanced Programming in the
> Unix Enviroment by W. Richard Stevens is still a very relevant book to anyone
> who wants to develop on unix.

That is pretty much true, yes.

br,
KK

On 20/08/2024 16:21, Kalevi Kolttonen wrote:
> In comp.unix.programmer David Brown <david.brown@hesbynett.no> wrote:
>> On 16/08/2024 17:02, Kalevi Kolttonen wrote:
>>> In comp.unix.programmer Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>>>> On 2024-08-15, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>>> On Thu, 15 Aug 2024 19:48:36 -0000 (UTC), Kalevi Kolttonen wrote:
>>>>>
>>>>>> The last I checked, the O'Reilly Python book is just absolutely
>>>>>> *MASSIVE*. The language has a huge number of features now ...
>>>>>
>>>>> No, it hasn’t. The core language reference spec is only a small fraction
>>>>> of, say, the Java language spec.
>>>>>
>>>>> It’s just that you can do so many things with Python. And that is down to
>>>>> the huge variety of off-the-shelf addon libraries that build on that core
>>>>> language spec. It has to be a strong, very solidly founded core in order
>>>>> to be such a versatile basis for these addons, and it is.
>>>>
>>>> That's idiotic; you're saying that the standard library packages of
>>>> Python are not part of Python, and do not contribute to its size.
>>>
>>> You seem to have a point. The core of C language is also small. I
>>> guess they even said in the original K & R book that C is a small
>>> language best described by a small book.
>>>
>>> But in order to do anything with C, you need to know the standard
>>> libraries. They have grown bigger and bigger during all these
>>> years. One could also well argue that to program on UNIX, you also
>>> need to know all the POSIX libraries.
>>>
>>
>> Absolute nonsense.
>>
>> In order to use a programming language for a given task, you need to
>> know the basics of the language and libraries appropriate for the task.
>> You most certainly do not need to know all about the language, or all
>> about all the libraries provided as standard for the language or the
>> host OS.
>
> I would not label it as "absolute nonsense".

OK, let's say "pretty much nonsense" instead.

> In order to program on UNIX,
> you need to be familiar with the facilities that are available. I
> know of a very smart man who ended up as a professor of physics who
> programmed on Amiga back in the 1980s. Even though his PhD thesis
> was something like 100-150 pages of strange-looking formulas, he said
> he had problems with C on the Amiga. For some reason, he was unable
> to remember what functions where provided as standard libraries, so
> he always ended up writing his own functions instead of using libraries.
>
> To know Linux, you need Michal Kerrisk's book the Linux Programming
> Interface. I have this book, but admittedly you are kind of right:
> It is large and I do not know every single part of it, but I have
> studied it a lot and I am familiar with the most important features.
>

You need to know what you need to know in order to handle the task in hand.

If you are writing a program to convert json files to xml files, you
need to know enough about the interface to open, read and write files,
and to manipulate strings and other data structures in the language of
your choice. If that is C, for example, you need to know about 5% of
the standard library, at most. You need to know a /tiny/ fraction of
POSIX. The same goes for any other language you choose to use, and any
other program you choose to write.

Unless you are working with huge pieces of software with connections to
large parts of the system - say, a Windowing system - you don't need to
know about more than a very small part of the OS interfaces. Unless you
are writing a compiler, standard library, or other big development tool,
you rarely need to know more than the basics of a programming language
along with parts specific to your tasks.

And for most modern software written to run on general-purpose OS's,
people use languages where you haven't a hope in hell of understanding
the entire language and its standard libraries, never mind the common
frameworks and libraries that are often used. You have /zero/ chance of
knowing all of the system APIs and common library interfaces of your OS
- there are not nearly enough hours in the day for that. But you don't
need any of that - you learn and use the language features and libraries
that are appropriate for getting the job done. (And often that is all
cross-platform - little or no POSIX-specific stuff in sight, even if you
only run your code on Linux.)

No, you do not need your particular favourite out of the thousand and
one Linux programming books in order to program for Linux. You do not
need /any/ book in order to write useful and successful code for Linux.
Of course you need /some/ reference - and in the days before the
internet was so easily available and so full of information, I went
through a lot of programming books. Some were good, some less so, and
some have become famous. But none of them were /necessary/ in any way.

In comp.unix.programmer David Brown <david.brown@hesbynett.no> wrote:
> No, you do not need your particular favourite out of the thousand and
> one Linux programming books in order to program for Linux. You do not
> need /any/ book in order to write useful and successful code for Linux.
> Of course you need /some/ reference - and in the days before the
> internet was so easily available and so full of information, I went
> through a lot of programming books. Some were good, some less so, and
> some have become famous. But none of them were /necessary/ in any way.

Well, I am a quite bad programmer but I am interested enough in the
Linux/UNIX workings so that reading the newest APUE and The Linux
Programming Interface did not feel painful or unnecessary at all. On
the contrary, it was a great pleasure to examine what kind of
programming facilities my favourite OS offers.

Having these two books, or just one of them, is a great way to educate
oneself about Linux/UNIX. I see that The Linux Programming Interface
is available online as a free PDF, but I am not sure whether it is
a pirated version.

There is no better way to learn Linux/UNIX workings than these two
books. Period.

br,
KK

On Tue, 20 Aug 2024 10:27:01 +0200, Dmitry A. Kazakov wrote:

> The question is sustainability in long term.

In the long term, proprietary software is in retreat, while Free software
is on the rise. So it’s quite clear which one is more “sustainable”.

On Tue, 20 Aug 2024 10:15:53 +0200, Dmitry A. Kazakov wrote:

> On 2024-08-20 09:21, Lawrence D'Oliveiro wrote:
>
>> On Tue, 20 Aug 2024 08:52:27 +0200, Dmitry A. Kazakov wrote:
>>
>>> It is no complain, merely stating an elementary economic fact. If the
>>> price does not reflect the costs, there is no market. No market, no
>>> competition. No competition, no quality.
>>
>> Elementary economic fact: in a competitive market, the unit price of
>> the product tends to converge towards the marginal cost of producing
>> that product.
>>
>> What’s the marginal cost of producing a copy of a piece of software?
>> Essentially, zero.
>
> Again, I do not say what is right and what is wrong.

Neither do I. The fact is, Free software is on the rise, and proprietary
software is fighting a rearguard action against it.