On 24/08/2023 20:33, Carlos E. R. wrote:
> On 2023-08-24 09:39, The Natural Philosopher wrote:
>> On 24/08/2023 13:44, Carlos E. R. wrote:
>>> On 2023-08-24 01:02, 51b.1055 wrote:
>>>> On 8/23/23 2:49 AM, The Natural Philosopher wrote:
>>>>> On 23/08/2023 06:17, 51b.1055 wrote:
>>>>>> On 8/22/23 9:41 AM, Carlos E. R. wrote:
>>>
>>>>>>    Yep, drive shares for early DOS !!! Coax cable.
>>>>>>
>>>>> FTP software's TCP/IP
>>>>> Suns PC-NFS. And there was one other - a geek who wrote an amazing
>>>>> TCP/IP stack in about 16K IIRC. Cannot remember the product name.
>>>>>
>>>>> Then microsoft staggered into the arena and that was the end of one
>>>>> business model and market.
>>>>>
>>>>> They always had 'lan manager' and netbeui...that became  netbios
>>>>> and then the ghastly file sharing over windows TCP/IP
>>>>
>>>>    DOS/Win file sharing was/is always a bit clunky - but
>>>>    at least they've got it to work pretty OK at this point.
>>>
>>> Dos share had features that Linux today doesn't have, AFAIK.
>>
>> Id call those bugs, actually
>
> Absolutely not.
>
> The implementation may have bugs or not. The technical description and
> features are sound.
>
>>
>>>
>>> Dos could lock for write or read an area of a file, for instance. And
>>> those are mandatory locks. This feature is needed for databases that
>>> run without a centralized daemon, but sharing the database file
>>> itself instead.
>>>
>>
>> And what a nightmare those actually were.
>> SAMBA does better file locking than winders ever did on Lan Manager
>>
>> But if you want proper locking uses a database.
>
> Different thing. Peas to nuts.
>
>
Not really. You can build an app around text files or you can build an
app using a centralised database to store those files.

--
I would rather have questions that cannot be answered...
....than to have answers that cannot be questioned

Richard Feynman

On 25/08/2023 02:44, 51b.1055 wrote:
> On 8/24/23 3:36 AM, The Natural Philosopher wrote:
>> On 24/08/2023 05:40, 51b.1055 wrote:
>>> On 8/22/23 3:00 AM, The Natural Philosopher wrote:
>>>> On 22/08/2023 06:09, 51b.1055 wrote:
>>>>> Does a Gb-sized -ix, esp CL, do THAT much more
>>>>>    vital stuff than the ones that ran on a PC-XT ???
>>>>>    We want MU/MT, a file system, a certain amount of
>>>>>    device abstraction, a couple good compilers. Guess
>>>>>    it's all what you have in mind, but sometimes that
>>>>>    vision is "simple", "compact", "low-resource".
>>>>
>>>> You cant have a thousand users all on MSDOS. You can on linux.
>>>> Linux is ground up multi-user multitasking.
>>>
>>>    Quite true. As said, it's all what you want/need. For
>>>    many devices, single-user/task IS just fine. Oh, there
>>>    ARE ways to kinda fake MU/MT on DOS and CP/M. The old
>>>    TI-9900 was fascinating in that the CPU instruction set
>>>    was designed to facilitate MU/MT (albeit in mostly 64k
>>>    universes). BLWP - Branch and Load Workspace Pointer -
>>>    would create a new 64k universe.
>>>
>>>    What I'm aiming at here is the "intermediate niche" ...
>>>    the zone between the microcontroller universe and full
>>>    complete modern "computers". This is an expanding segment,
>>>    now mostly the domain of the IOT, but also a variety of
>>>    industrial/device needs. Think machines with maybe a tenth
>>>    the memory/cpu/power-req as something like a PI that
>>>    you'd expect to run perfectly for a decade or more.
>>>
>>>> Its a miniature mini computer operating system, and getting it on a
>>>> miniature card for less than $20 is still a bloody miracle.
>>>
>>>    Indeed !
>>>
>>>    But what about $9.95 ?  :-)
>>>
>>>> If it takes 60MB RAM so what. We HAVE 60MB RAM.
>>>> MSDOS ran on one archgtecture only. Linux runs on many.
>>>
>>>    But 60mb still COSTS, still USES POWER. Think "solar
>>>    cells" ............
>>>
>>>    Did an environmental multi-monitor a few years back that
>>>    had to run on a 5w solar panel. I managed that using an
>>>    Arduino Mega - it has instructions/options that let you
>>>    bring the thing down to near zero power between device/
>>>    timer interrupts. However this was a micro-controller
>>>    and didn't REALLY have an "OS" in the conventional sense.
>>>    There were 'C' libraries, but it was messy. The kinds of
>>>    things an OS would do were kinda ad-hoc, special functions
>>>    unto themselves rather than integrated into a whole even
>>>    as simple as DOS-CP/M.
>>>
>>>    I can see more uses for such "intermediate" applications,
>>>    esp with special power needs. I'd like one step beyond
>>>    the micro-controller universe without giving up most of
>>>    the fine control. Unix DID run on those old 8088 boxes
>>>    and I'm wondering if it, or Linux, can fit into the
>>>    same power/resource/complexity paradigm. Even a PI-Zero
>>>    uses a LOT of power and can NOT really be brought down
>>>    to a micro/nano-power state.
>>>
>>>    At PRESENT - Linux CANNOT. Even the 'minimal' distros
>>>    have become just TOO large and hungry. You wind up with
>>>    the ugly option of using a u-controller to start/stop
>>>    the "modern" board.
>>
>> Seriously mate, my Pi Zero W is  cheap as chips, uses bugger all
>> power, has 512M of RAM and runs a full blown copy of Linux!
>>
>> I think that *is* the intermediate.
>
>
>   Look it up - the power used by something like an Ard
>   with the low-power library and a Zero. The diff is
>   horrific. Well, just TRY to run that Zero on a 5w
>   panel with a little LiPo charger ... or even just
>   a few 'AA' batteries.
>

The Pi zero is around 80mA. with the Wifi on ot its around 140mA
depending on whether its chattering or not. So total power is around a
watt worst case.

The point here is that you cannot have wifi capability without consuming
power.

>   Zero's/Pico's and such ARE good and useful, but within
>   a certain sphere. i9's with $1500 NVidia cards are
>   good within their sphere. PIC-12's within theirs
>   (love those things !). All I'm saying is that there
>   IS a niche in-between "microntroller" and "computer"
>   worth some effort, and that can generate some $$$.
>   I'm just not seeing as many options there as
>   I think there ought to be.
>
>   And it'd be REALLY REALLY nice if there was a Linux/Unix
>   that'd run on them.
>
Linux uses up a lot of code space to generate a user level model that is
consistent across hardware platforms.

You need to have that code space available. On smaller boards it simply
isn't.
Likewise while I might get a Pico to run a fairly basic multitasker, to
actually equip it with enough storage to compile it on itself, is out of
the question.

As far as I am concerned the Pi Zero W is a beautiful little halfway
house. Small, cheap, has networking, has linux, consumes bugger all, and
is easy to set up and program.

Its not the answer to everything. But now I have nearly finished my
server side code, I'll be moving on to the PICO, which I am rather
dreading. Documentation for the C interface is really poor. But nothing
good comes without a struggle.

>
>> The pi PICO or an Arduino is even less, one thinks if a single tasking
>> OS is good enough for you.
>
>   Single CAN serve for many applications ... hey, DOS and CP/M
>   got by that way for many years and we got word processors
>   and spreadsheets and photo-shop pgms and databases and all
>   those good things. Single can be tweaked to kinda fake multi
>   also without TOO much trouble.
>
>> And ther are multitasking kernels you can use with those too.
>
>   Somewhere I mentioned OS/9 ... and it can do exactly that -
>   MU/MT/RTOS but AIMED at that lower/intermediate range of devices.
>   It has a considerable look/feel of Unix - hell, one of their
>   old ad campaigns said they were Unix, but a whole lot better.
>
>   OS/9 is still around, still sold, still developed. NOT 'free'
>   however. It has also kind-of abandoned its 6809 roots, now
>   primarily ported to modern, 'bigger', chips. Might still BE
>   8 & 8/16-bit versions to be had however, they just don't
>   advertise it straight-up. They do support the 68k/Coldfire
>   16/32-bit chips that run at a whopping 100Mhz ... which
>   is kind of the zone I'm looking for.
>
You could probably get a chip to emulate a z809 and run concurrent CP/M
on it...

I mean really, if you want that stuff that bad, write it. I could
probably write an OS at that level in under a year - certainly when I
was younger I could - although dealing with undocumented hardware
features is a bit shit.

What I always baulked at was writing a TCP/IP stack. But LWIP exists in
source form, I suppose.

>   https://www.microsys.de/en/products/software/os-9/
>   https://www.nxp.com/docs/en/fact-sheet/COLDFIREIPLCFS.pdf

--
I would rather have questions that cannot be answered...
....than to have answers that cannot be questioned

Richard Feynman

On 2023-08-25 03:10, Richard Kettlewell wrote:
> "Carlos E. R." <robin_listas@es.invalid> writes:
>> On 2023-08-24 14:14, Richard Kettlewell wrote:
>>> "Carlos E. R." <robin_listas@es.invalid> writes:
>>>> Dos share had features that Linux today doesn't have, AFAIK.
>>>>
>>>> Dos could lock for write or read an area of a file, for instance. And
>>>> those are mandatory locks. This feature is needed for databases that
>>>> run without a centralized daemon, but sharing the database file itself
>>>> instead.
>>> Obviously not true, you can have a shared-file database with advisory
>>> locks. SQLite is an example.
>> No, you can not. It is a different thing.
>
> In what way?

a) It is kernel based mandatory locks.

b) It is not a daemon. A database engine residing in a daemon doesn't
need to apply zonal locks. All accesses are requested on the single
daemon, nothing else has to access the database file.

c) Windows/msdos can have several applications competing to access the
same file. One application can, at least theoretically, lock access to a
portion of the database file (say, a single database record), and modify
it, while another application has a different lock on another database
record in the same file.

d) Windows can also have a single daemon database engine "Linux style".

You may not like this concept, you may hate it, you may say it is
stupid. I'm not saying it is better nor worse. I am only saying that it
is different and it exists.

And I'm aware that Linux only programmers have a difficult time
understanding this different lock concept.

--
Cheers,
Carlos E.R.

"Carlos E. R." <robin_listas@es.invalid> writes:
> On 2023-08-25 03:10, Richard Kettlewell wrote:
>> "Carlos E. R." <robin_listas@es.invalid> writes:
>>> On 2023-08-24 14:14, Richard Kettlewell wrote:
>>>> "Carlos E. R." <robin_listas@es.invalid> writes:
>>>>> Dos share had features that Linux today doesn't have, AFAIK.
>>>>>
>>>>> Dos could lock for write or read an area of a file, for instance. And
>>>>> those are mandatory locks. This feature is needed for databases that
>>>>> run without a centralized daemon, but sharing the database file itself
>>>>> instead.
>>>> Obviously not true, you can have a shared-file database with advisory
>>>> locks. SQLite is an example.
>>> No, you can not. It is a different thing.
>> In what way?
>
> a) It is kernel based mandatory locks.
>
> b) It is not a daemon. A database engine residing in a daemon doesn't
> need to apply zonal locks. All accesses are requested on the single
> daemon, nothing else has to access the database file.
>
> c) Windows/msdos can have several applications competing to access the
> same file. One application can, at least theoretically, lock access to
> a portion of the database file (say, a single database record), and
> modify it, while another application has a different lock on another
> database record in the same file.
>
> d) Windows can also have a single daemon database engine "Linux style".

I understand all that. Your claim was that you cannot have a shared-file
database without mandatory locks. That’s simply not true, and SQLite is
the constructive proof that it’s not true.

> You may not like this concept, you may hate it, you may say it is
> stupid. I'm not saying it is better nor worse. I am only saying that
> it is different and it exists.
>
> And I'm aware that Linux only programmers have a difficult time
> understanding this different lock concept.

I understand the difference between mandatory and advisory locks.

--
https://www.greenend.org.uk/rjk/

The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 25/08/2023 02:44, 51b.1055 wrote:
>>
>> Look it up - the power used by something like an Ard
>> with the low-power library and a Zero. The diff is
>> horrific. Well, just TRY to run that Zero on a 5w
>> panel with a little LiPo charger ... or even just
>> a few 'AA' batteries.
>>
>
> The Pi zero is around 80mA. with the Wifi on ot its around 140mA
> depending on whether its chattering or not. So total power is around a
> watt worst case.

It does vary a lot under load. With a Pi Zero (non-W) I measured
90mA at idle, but a peak of 190mA while booting Linux. But what's
really missing is a low power state that microcontrollers like the
modern PICs have. Even if the Pi Zero had convenient ways to wake
up from its powered-off state, in the powered-off state it still
draws 50mA!

> The point here is that you cannot have wifi capability without
> consuming power.

Chips like some of the ESP32s can consume much less power in WiFi
applications though. They also have various low power states. This
article describes a Light-Sleep mode where "the WiFi baseband is
disabled but the WiFi connection itself remains active" and graphs
current measurements for various ESP32 boards dropping from around
50mA at idle to mostly under 10mA in Light-Sleep mode:
https://diyi0t.com/reduce-the-esp32-power-consumption/

Plus the developer support for the Pis is terrible. The _community_
support is great, but it's a crowd of people constantly banging on
Broadcom's door and then eagerly lapping up the occasional scrap of
poorly-written official documentation that they throw out. You
don't even get timing specs for the I/O, and the vague electrical
specifications for the SoCs weren't even published until the
Compute boards came out. There's only a sub-set of register
documentation, plus bits of difficult-to-find code that the Pi
engineers have put in the Linux kernel based on all the secret
Broadcom docs that they quote occasionally on their forum. Modern
microcontroller datasheets can be pretty bad too, but at least they
exist whereas on the Pi you have to test everything yourself, or
find someone on the web who'se already done so (and believe that
they know what they're doing).

(There is a bit of fun to working out all Broadcom's secrets for
yourself if you're not in a hurry, but it's only fun when you
_can_ work them out in the end)

Hell there could be a low-power WiFi mode supported in the
closed-source binary firmware that runs on the Pi Zero W's WiFi
chip. But you wouldn't know unless you disassembled it or got a
peek at the commercial SDK. In fact if I remember correctly people
suspect that the firmware actually runs proprietary mini-OS on the
WiFi chip (maybe even a second one on the separate Bluetooth
processor in the same chip). That in fact is the sort of OS
application being discussed.

> You could probably get a chip to emulate a z809 and run concurrent CP/M
> on it...
>
> I mean really, if you want that stuff that bad, write it. I could
> probably write an OS at that level in under a year - certainly when I
> was younger I could - although dealing with undocumented hardware
> features is a bit shit.
>
> What I always baulked at was writing a TCP/IP stack. But LWIP exists in
> source form, I suppose.

There's also USB and all the drivers for things you might want to
support, plus similar things for Bluetooth. The list of things that
an embedded OS might need to do yet you just don't want to write
yourself has been growing, and I agree that it would be ideal if
you could just use Linux with all its proven code on slightly lower
spec hardware.

On the other hand it's also kind-of silly to develop a UNIX system
to run on something like that given that UNIX was designed for a
completely different application and therefore Linux needs
complicated add-on functionality for things like realtime I/O,
while at the same time you disable core functionality like
multi-user support.

--
__ __
#_ < |\| |< _#

On 26/08/2023 02:50, Computer Nerd Kev wrote:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> On 25/08/2023 02:44, 51b.1055 wrote:
>>>
>>> Look it up - the power used by something like an Ard
>>> with the low-power library and a Zero. The diff is
>>> horrific. Well, just TRY to run that Zero on a 5w
>>> panel with a little LiPo charger ... or even just
>>> a few 'AA' batteries.
>>>
>>
>> The Pi zero is around 80mA. with the Wifi on ot its around 140mA
>> depending on whether its chattering or not. So total power is around a
>> watt worst case.
>
> It does vary a lot under load. With a Pi Zero (non-W) I measured
> 90mA at idle, but a peak of 190mA while booting Linux. But what's
> really missing is a low power state that microcontrollers like the
> modern PICs have. Even if the Pi Zero had convenient ways to wake
> up from its powered-off state, in the powered-off state it still
> draws 50mA!
>
No, Pi Pico W can go down to a very low state of a mA or less.

>> The point here is that you cannot have wifi capability without
>> consuming power.
>
> Chips like some of the ESP32s can consume much less power in WiFi
> applications though. They also have various low power states. This
> article describes a Light-Sleep mode where "the WiFi baseband is
> disabled but the WiFi connection itself remains active" and graphs
> current measurements for various ESP32 boards dropping from around
> 50mA at idle to mostly under 10mA in Light-Sleep mode:
> https://diyi0t.com/reduce-the-esp32-power-consumption/
>
Same for a Pco allegedly

> Plus the developer support for the Pis is terrible. The _community_
> support is great, but it's a crowd of people constantly banging on
> Broadcom's door and then eagerly lapping up the occasional scrap of
> poorly-written official documentation that they throw out. You
> don't even get timing specs for the I/O, and the vague electrical
> specifications for the SoCs weren't even published until the
> Compute boards came out. There's only a sub-set of register
> documentation, plus bits of difficult-to-find code that the Pi
> engineers have put in the Linux kernel based on all the secret
> Broadcom docs that they quote occasionally on their forum. Modern
> microcontroller datasheets can be pretty bad too, but at least they
> exist whereas on the Pi you have to test everything yourself, or
> find someone on the web who'se already done so (and believe that
> they know what they're doing).
>
> (There is a bit of fun to working out all Broadcom's secrets for
> yourself if you're not in a hurry, but it's only fun when you
> _can_ work them out in the end)
>
> Hell there could be a low-power WiFi mode supported in the
> closed-source binary firmware that runs on the Pi Zero W's WiFi
> chip. But you wouldn't know unless you disassembled it or got a
> peek at the commercial SDK. In fact if I remember correctly people
> suspect that the firmware actually runs proprietary mini-OS on the
> WiFi chip (maybe even a second one on the separate Bluetooth
> processor in the same chip). That in fact is the sort of OS
> application being discussed.
>
>> You could probably get a chip to emulate a z809 and run concurrent CP/M
>> on it...
>>
>> I mean really, if you want that stuff that bad, write it. I could
>> probably write an OS at that level in under a year - certainly when I
>> was younger I could - although dealing with undocumented hardware
>> features is a bit shit.
>>
>> What I always baulked at was writing a TCP/IP stack. But LWIP exists in
>> source form, I suppose.
>
> There's also USB and all the drivers for things you might want to
> support, plus similar things for Bluetooth. The list of things that
> an embedded OS might need to do yet you just don't want to write
> yourself has been growing, and I agree that it would be ideal if
> you could just use Linux with all its proven code on slightly lower
> spec hardware.
>
> On the other hand it's also kind-of silly to develop a UNIX system
> to run on something like that given that UNIX was designed for a
> completely different application and therefore Linux needs
> complicated add-on functionality for things like realtime I/O,
> while at the same time you disable core functionality like
> multi-user support.
>

--
Gun Control: The law that ensures that only criminals have guns.

On 25/08/2023 17:05, Carlos E. R. wrote:
> On 2023-08-25 03:10, Richard Kettlewell wrote:
>> "Carlos E. R." <robin_listas@es.invalid> writes:
>>> On 2023-08-24 14:14, Richard Kettlewell wrote:
>>>> "Carlos E. R." <robin_listas@es.invalid> writes:
>>>>> Dos share had features that Linux today doesn't have, AFAIK.
>>>>>
>>>>> Dos could lock for write or read an area of a file, for instance. And
>>>>> those are mandatory locks. This feature is needed for databases that
>>>>> run without a centralized daemon, but sharing the database file itself
>>>>> instead.
>>>> Obviously not true, you can have a shared-file database with advisory
>>>> locks. SQLite is an example.
>>> No, you can not. It is a different thing.
>>
>> In what way?
>
> a) It is kernel based mandatory locks.
>
> b) It is not a daemon. A database engine residing in a daemon doesn't
> need to apply zonal locks. All accesses are requested on the single
> daemon, nothing else has to access the database file.
>
> c) Windows/msdos can have several applications competing to access the
> same file. One application can, at least theoretically, lock access to a
> portion of the database file (say, a single database record), and modify
> it, while another application has a different lock on another database
> record in the same file.
>
> d) Windows can also have a single daemon database engine "Linux style".
>
>
> You may not like this concept, you may hate it, you may say it is
> stupid. I'm not saying it is better nor worse. I am only saying that it
> is different and it exists.
>
> And I'm aware that Linux only programmers have a difficult time
> understanding this different lock concept.
>

I think Richard's point is that once you have advisory locks an exe/api
is enough to synchronise file access, it doesn't need to be a daemon.

The bit I can't get my head around is why it is practical to implement
advisory locks, but not mandatory locks. It seems to me once you have
the advisory lock, most of the hard work is done. I need to read up on it.

Pancho <Pancho.Jones@proton.me> writes:
> The bit I can't get my head around is why it is practical to implement
> advisory locks, but not mandatory locks. It seems to me once you have
> the advisory lock, most of the hard work is done. I need to read up on it.

I don’t know how hard it is in practice but the old Linux
implementation[1] documented a number of bugs, plus some inconsistencies
between Unix implementations.

[1] https://www.kernel.org/doc/Documentation/filesystems/mandatory-locking.txt

My suspicion is that the combination of these issues and practical
issues (e.g. an application hangs holding a lock means your backup
process hangs too when it reaches that file) and I suspect they’re
basically not worth the effort.

--
https://www.greenend.org.uk/rjk/

On 26/08/2023 14:21, Richard Kettlewell wrote:
> Pancho <Pancho.Jones@proton.me> writes:
>> The bit I can't get my head around is why it is practical to implement
>> advisory locks, but not mandatory locks. It seems to me once you have
>> the advisory lock, most of the hard work is done. I need to read up on it.
>
> I don’t know how hard it is in practice but the old Linux
> implementation[1] documented a number of bugs, plus some inconsistencies
> between Unix implementations.
>
> [1] https://www.kernel.org/doc/Documentation/filesystems/mandatory-locking.txt
>
> My suspicion is that the combination of these issues and practical
> issues (e.g. an application hangs holding a lock means your backup
> process hangs too when it reaches that file) and I suspect they’re
> basically not worth the effort.
>
Also as networking speeds have increased the tendency towards cloud
services - even internal to an organization - rather than shared file
ones has reduced the need for locking anyway.

--
The biggest threat to humanity comes from socialism, which has utterly
diverted our attention away from what really matters to our existential
survival, to indulging in navel gazing and faux moral investigations
into what the world ought to be, whilst we fail utterly to deal with
what it actually is.

On Sat, 26 Aug 2023 06:50:45 -0400, Pancho <Pancho.Jones@proton.me> wrote:
> The bit I can't get my head around is why it is practical to implement
> advisory locks, but not mandatory locks. It seems to me once you have
> the advisory lock, most of the hard work is done. I need to read up on it.

Using advisory locks is simpler to implement and works well as long as all
of the software involved can be trusted to respect those locks.

Mandatory locks are only needed if the software components may not respect
advisory locks in a proper manner.

Regards, Dave Hodgins

The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 26/08/2023 02:50, Computer Nerd Kev wrote:
>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>> On 25/08/2023 02:44, 51b.1055 wrote:
>>>>
>>>> Look it up - the power used by something like an Ard
>>>> with the low-power library and a Zero. The diff is
>>>> horrific. Well, just TRY to run that Zero on a 5w
>>>> panel with a little LiPo charger ... or even just
>>>> a few 'AA' batteries.
>>>>
>>>
>>> The Pi zero is around 80mA. with the Wifi on ot its around 140mA
>>> depending on whether its chattering or not. So total power is around a
>>> watt worst case.
>>
>> It does vary a lot under load. With a Pi Zero (non-W) I measured
>> 90mA at idle, but a peak of 190mA while booting Linux. But what's
>> really missing is a low power state that microcontrollers like the
>> modern PICs have. Even if the Pi Zero had convenient ways to wake
>> up from its powered-off state, in the powered-off state it still
>> draws 50mA!
>>
> No, Pi Pico W can go down to a very low state of a mA or less.
>
>>> The point here is that you cannot have wifi capability without
>>> consuming power.
>>
>> Chips like some of the ESP32s can consume much less power in WiFi
>> applications though. They also have various low power states. This
>> article describes a Light-Sleep mode where "the WiFi baseband is
>> disabled but the WiFi connection itself remains active" and graphs
>> current measurements for various ESP32 boards dropping from around
>> 50mA at idle to mostly under 10mA in Light-Sleep mode:
>> https://diyi0t.com/reduce-the-esp32-power-consumption/
>>
> Same for a Pco allegedly

So all the more reason that someone might like to run Linux on
boards like that, rather than the Raspberry Pi Zero W which is
currently the mimimum in the Pi range with advertised Linux
support.

I don't see how you meant to make a point "that you cannot have
wifi capability without consuming power" by quoting power figures
for the Pi Zero W unless you wrongly assumed that WiFi-supporting
boards without Linux support have similar power consumption to the
Pi Zero W.

--
__ __
#_ < |\| |< _#

On 2023-08-21 07:06, The Natural Philosopher wrote:
> And once I throw Firefox on top of that you can kiss goodbye to at least
> 3 GB of RAM.
>
> In short, its not Linux that is bloated, it is the graphical
> applications and the X windows shite.

I can use Mageia 9 Xfce, with Firefox, on my Dell Inspiron 5100, even
though it only has 2GB of RAM.

OK, so that 21-year-old P4 runs slow enough that I can fix myself a
sandwich while a complex page loads - it still does the job, eventually.

TJ

On 27/08/2023 00:19, Computer Nerd Kev wrote:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> On 26/08/2023 02:50, Computer Nerd Kev wrote:
>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>> On 25/08/2023 02:44, 51b.1055 wrote:
>>>>>
>>>>> Look it up - the power used by something like an Ard
>>>>> with the low-power library and a Zero. The diff is
>>>>> horrific. Well, just TRY to run that Zero on a 5w
>>>>> panel with a little LiPo charger ... or even just
>>>>> a few 'AA' batteries.
>>>>>
>>>>
>>>> The Pi zero is around 80mA. with the Wifi on ot its around 140mA
>>>> depending on whether its chattering or not. So total power is around a
>>>> watt worst case.
>>>
>>> It does vary a lot under load. With a Pi Zero (non-W) I measured
>>> 90mA at idle, but a peak of 190mA while booting Linux. But what's
>>> really missing is a low power state that microcontrollers like the
>>> modern PICs have. Even if the Pi Zero had convenient ways to wake
>>> up from its powered-off state, in the powered-off state it still
>>> draws 50mA!
>>>
>> No, Pi Pico W can go down to a very low state of a mA or less.
>>
>>>> The point here is that you cannot have wifi capability without
>>>> consuming power.
>>>
>>> Chips like some of the ESP32s can consume much less power in WiFi
>>> applications though. They also have various low power states. This
>>> article describes a Light-Sleep mode where "the WiFi baseband is
>>> disabled but the WiFi connection itself remains active" and graphs
>>> current measurements for various ESP32 boards dropping from around
>>> 50mA at idle to mostly under 10mA in Light-Sleep mode:
>>> https://diyi0t.com/reduce-the-esp32-power-consumption/
>>>
>> Same for a Pco allegedly
>
> So all the more reason that someone might like to run Linux on
> boards like that, rather than the Raspberry Pi Zero W which is
> currently the mimimum in the Pi range with advertised Linux
> support.
>
> I don't see how you meant to make a point "that you cannot have
> wifi capability without consuming power" by quoting power figures
> for the Pi Zero W unless you wrongly assumed that WiFi-supporting
> boards without Linux support have similar power consumption to the
> Pi Zero W.
>

Really, how do you think radio actually works?

--
It’s easier to fool people than to convince them that they have been fooled.
Mark Twain

On 27/08/2023 01:18, TJ wrote:
> On 2023-08-21 07:06, The Natural Philosopher wrote:
>> And once I throw Firefox on top of that you can kiss goodbye to at
>> least 3 GB of RAM.
>>
>> In short, its not Linux that is bloated, it is the graphical
>> applications and the X windows shite.
>
> I can use Mageia 9 Xfce, with Firefox, on my Dell Inspiron 5100, even
> though it only has 2GB of RAM.
> ]

Try it on 512M ....:-

> OK, so that 21-year-old P4 runs slow enough that I can fix myself a
> sandwich while a complex page loads - it still does the job, eventually.
>
> TJ

--
It’s easier to fool people than to convince them that they have been fooled.
Mark Twain

The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 27/08/2023 00:19, Computer Nerd Kev wrote:
>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>> On 26/08/2023 02:50, Computer Nerd Kev wrote:
>>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>>> The Pi zero is around 80mA. with the Wifi on ot its around 140mA
>>>>> depending on whether its chattering or not. So total power is around a
>>>>> watt worst case.
>>>>
>>>> It does vary a lot under load. With a Pi Zero (non-W) I measured
>>>> 90mA at idle, but a peak of 190mA while booting Linux. But what's
>>>> really missing is a low power state that microcontrollers like the
>>>> modern PICs have. Even if the Pi Zero had convenient ways to wake
>>>> up from its powered-off state, in the powered-off state it still
>>>> draws 50mA!
>>>>
>>> No, Pi Pico W can go down to a very low state of a mA or less.
>>>
>>>>> The point here is that you cannot have wifi capability without
>>>>> consuming power.
>>>>
>>>> Chips like some of the ESP32s can consume much less power in WiFi
>>>> applications though. They also have various low power states. This
>>>> article describes a Light-Sleep mode where "the WiFi baseband is
>>>> disabled but the WiFi connection itself remains active" and graphs
>>>> current measurements for various ESP32 boards dropping from around
>>>> 50mA at idle to mostly under 10mA in Light-Sleep mode:
>>>> https://diyi0t.com/reduce-the-esp32-power-consumption/
>>>>
>>> Same for a Pco allegedly
>>
>> So all the more reason that someone might like to run Linux on
>> boards like that, rather than the Raspberry Pi Zero W which is
>> currently the mimimum in the Pi range with advertised Linux
>> support.
>>
>> I don't see how you meant to make a point "that you cannot have
>> wifi capability without consuming power" by quoting power figures
>> for the Pi Zero W unless you wrongly assumed that WiFi-supporting
>> boards without Linux support have similar power consumption to the
>> Pi Zero W.
>>
>
> Really, how do you think radio actually works?

In the case of WiFi, obviously not by continuously transmitting at
full power. Hence the possibility of low-power modes, but the best
such low-power modes are on boards without Linux support, so your
quoting of power figures for the Pi Zero W contradicts the point
you claimed to be making, so far as I can see.

I did assume that you meant "by consuming that much power", or more
specifically "by consuming power figures similar to those I quoted
above for the Pi Zero W", figuring that you wouldn't be pointlessly
stating the obvious fact that WiFi works using electricity. Maybe I
was wrong there.

--
__ __
#_ < |\| |< _#

On 27/08/2023 13:07, Computer Nerd Kev wrote:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> On 27/08/2023 00:19, Computer Nerd Kev wrote:
>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>> On 26/08/2023 02:50, Computer Nerd Kev wrote:
>>>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>>>> The Pi zero is around 80mA. with the Wifi on ot its around 140mA
>>>>>> depending on whether its chattering or not. So total power is around a
>>>>>> watt worst case.
>>>>>
>>>>> It does vary a lot under load. With a Pi Zero (non-W) I measured
>>>>> 90mA at idle, but a peak of 190mA while booting Linux. But what's
>>>>> really missing is a low power state that microcontrollers like the
>>>>> modern PICs have. Even if the Pi Zero had convenient ways to wake
>>>>> up from its powered-off state, in the powered-off state it still
>>>>> draws 50mA!
>>>>>
>>>> No, Pi Pico W can go down to a very low state of a mA or less.
>>>>
>>>>>> The point here is that you cannot have wifi capability without
>>>>>> consuming power.
>>>>>
>>>>> Chips like some of the ESP32s can consume much less power in WiFi
>>>>> applications though. They also have various low power states. This
>>>>> article describes a Light-Sleep mode where "the WiFi baseband is
>>>>> disabled but the WiFi connection itself remains active" and graphs
>>>>> current measurements for various ESP32 boards dropping from around
>>>>> 50mA at idle to mostly under 10mA in Light-Sleep mode:
>>>>> https://diyi0t.com/reduce-the-esp32-power-consumption/
>>>>>
>>>> Same for a Pco allegedly
>>>
>>> So all the more reason that someone might like to run Linux on
>>> boards like that, rather than the Raspberry Pi Zero W which is
>>> currently the mimimum in the Pi range with advertised Linux
>>> support.
>>>
>>> I don't see how you meant to make a point "that you cannot have
>>> wifi capability without consuming power" by quoting power figures
>>> for the Pi Zero W unless you wrongly assumed that WiFi-supporting
>>> boards without Linux support have similar power consumption to the
>>> Pi Zero W.
>>>
>>
>> Really, how do you think radio actually works?
>
> In the case of WiFi, obviously not by continuously transmitting at
> full power. Hence the possibility of low-power modes, but the best
> such low-power modes are on boards without Linux support, so your
> quoting of power figures for the Pi Zero W contradicts the point
> you claimed to be making, so far as I can see.
>
Oh dear.
Look at the online data. When connecting a wifi uses a lot of power to
transmit various handshakes,. Then it uses power to transmit data. How
could it not?

The point being that you cannot power down a wifi receiver completely
*if you want to be able to receive incoming packets*.

Which militates against having remote sensors that can be polled by a
central server for example. In such cases the optimal methodology is to
simply power the whole board down and then after a suitable period wake
it up, take a measurement, connect and send it, and shut down again.

You cannot go into 'deep sleep' nanoamp consumption and still get 'woken
up' by incoming data packets.

> the obvious fact that WiFi works using electricity. Maybe I
> was wrong there.
>

Well that was in fact the part you seemed to have missed. Once its
transmitting, if you want the signal to get to the receiver, it needs
quite a LOT of power.

And even in receive mode, you need to be running a chip that can at
least understand wifi packets that are *not* aimed at it, but at other
devices on that wifi node.

In short sitting there listening takes a lot more power than sitting
there doing the square root of Sweet Fanny Adams, waiting for e.g. a
hardware timer interrupt....

--
“Progress is precisely that which rules and regulations did not foresee,”

– Ludwig von Mises

On 28/08/2023 10:56, The Natural Philosopher wrote:

>
> In short sitting there listening takes a lot more power than sitting
> there doing the square root of Sweet Fanny Adams, waiting for e.g. a
> hardware timer interrupt....
>

I'm not really following, but I do remember hearing about Bluetooth Low
Energy, more specifically how it achieved low energy. AIUI, one of the
ways, was, indeed, shifting WiFi polling from the LE server device to a
higher energy client device. Particularly relevant for sensors (the
server) powered by 2032 batteries, and a smartphone (the client).

I think a lot of work was done on this with BlueTooth LE, it might be to
look at that.

The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 27/08/2023 13:07, Computer Nerd Kev wrote:
>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>> On 27/08/2023 00:19, Computer Nerd Kev wrote:
>>>> I don't see how you meant to make a point "that you cannot have
>>>> wifi capability without consuming power" by quoting power figures
>>>> for the Pi Zero W unless you wrongly assumed that WiFi-supporting
>>>> boards without Linux support have similar power consumption to the
>>>> Pi Zero W.
>>>
>>> Really, how do you think radio actually works?
>>
>> In the case of WiFi, obviously not by continuously transmitting at
>> full power. Hence the possibility of low-power modes, but the best
>> such low-power modes are on boards without Linux support, so your
>> quoting of power figures for the Pi Zero W contradicts the point
>> you claimed to be making, so far as I can see.
>>
> Oh dear.
> Look at the online data. When connecting a wifi uses a lot of power to
> transmit various handshakes,. Then it uses power to transmit data. How
> could it not?
>
> The point being that you cannot power down a wifi receiver completely
> *if you want to be able to receive incoming packets*.
>
> Which militates against having remote sensors that can be polled by a
> central server for example. In such cases the optimal methodology is to
> simply power the whole board down and then after a suitable period wake
> it up, take a measurement, connect and send it, and shut down again.
>
> You cannot go into 'deep sleep' nanoamp consumption and still get 'woken
> up' by incoming data packets.

You're the one who needs waking up: _This_ discussion wasn't about
your central heating rig. You may have designed that with sensors
getting polled by a central server, and that may mean that low-power
WiFi modes won't halp as much in your application (frankly I
haven't paid enough attention to your descriptions of the scheme
to know). That has nothing to do with the discussion about whether
Linux should target lower power boards such as ones with those
WiFi sleep modes ("deep sleep" and others).

>> the obvious fact that WiFi works using electricity. Maybe I
>> was wrong there.
>
> Well that was in fact the part you seemed to have missed. Once its
> transmitting, if you want the signal to get to the receiver, it needs
> quite a LOT of power.
>
> And even in receive mode, you need to be running a chip that can at
> least understand wifi packets that are *not* aimed at it, but at other
> devices on that wifi node.
>
> In short sitting there listening takes a lot more power than sitting
> there doing the square root of Sweet Fanny Adams, waiting for e.g. a
> hardware timer interrupt....

Yeah but electronics is a larger field than central heating control
systems (as you should know given you often describe your own
history in the field). Believe it or not, sometimes you might not
need a device listening continuously on the WiFi. Maybe it only
actually needs to use the WiFi after a user has walked over and
pressed a button that starts a function requiring WiFi? Or a few
sceduled times each day.

Don't you agree that these WiFi sleep modes were implemented for a
reason after all?

--
__ __
#_ < |\| |< _#

On 2023-08-25 12:13, Richard Kettlewell wrote:
> "Carlos E. R." <robin_listas@es.invalid> writes:
>> On 2023-08-25 03:10, Richard Kettlewell wrote:
>>> "Carlos E. R." <robin_listas@es.invalid> writes:
>>>> On 2023-08-24 14:14, Richard Kettlewell wrote:
>>>>> "Carlos E. R." <robin_listas@es.invalid> writes:
>>>>>> Dos share had features that Linux today doesn't have, AFAIK.
>>>>>>
>>>>>> Dos could lock for write or read an area of a file, for instance. And
>>>>>> those are mandatory locks. This feature is needed for databases that
>>>>>> run without a centralized daemon, but sharing the database file itself
>>>>>> instead.
>>>>> Obviously not true, you can have a shared-file database with advisory
>>>>> locks. SQLite is an example.
>>>> No, you can not. It is a different thing.
>>> In what way?
>>
>> a) It is kernel based mandatory locks.
>>
>> b) It is not a daemon. A database engine residing in a daemon doesn't
>> need to apply zonal locks. All accesses are requested on the single
>> daemon, nothing else has to access the database file.
>>
>> c) Windows/msdos can have several applications competing to access the
>> same file. One application can, at least theoretically, lock access to
>> a portion of the database file (say, a single database record), and
>> modify it, while another application has a different lock on another
>> database record in the same file.
>>
>> d) Windows can also have a single daemon database engine "Linux style".
>
> I understand all that. Your claim was that you cannot have a shared-file
> database without mandatory locks. That’s simply not true, and SQLite is
> the constructive proof that it’s not true.

No, I did not say that. If that is what you understood, then it
reinforces what I said about Linux programmers not understanding this
"mechanism".

>
>> You may not like this concept, you may hate it, you may say it is
>> stupid. I'm not saying it is better nor worse. I am only saying that
>> it is different and it exists.
>>
>> And I'm aware that Linux only programmers have a difficult time
>> understanding this different lock concept.
>
> I understand the difference between mandatory and advisory locks.

That's not it.

--
Cheers,
Carlos E.R.

"Carlos E. R." <robin_listas@es.invalid> writes:
> On 2023-08-25 12:13, Richard Kettlewell wrote:
>> "Carlos E. R." <robin_listas@es.invalid> writes:
>>> On 2023-08-25 03:10, Richard Kettlewell wrote:
>>>> "Carlos E. R." <robin_listas@es.invalid> writes:
>>>>> On 2023-08-24 14:14, Richard Kettlewell wrote:
>>>>>> "Carlos E. R." <robin_listas@es.invalid> writes:
>>>>>>> Dos share had features that Linux today doesn't have, AFAIK.
>>>>>>>
>>>>>>> Dos could lock for write or read an area of a file, for instance. And
>>>>>>> those are mandatory locks. This feature is needed for databases that
>>>>>>> run without a centralized daemon, but sharing the database file itself
>>>>>>> instead.
>>>>>> Obviously not true, you can have a shared-file database with
>>>>>> advisory locks. SQLite is an example.
>>>>> No, you can not. It is a different thing.
>>>> In what way?
>>>
>>> a) It is kernel based mandatory locks.
>>>
>>> b) It is not a daemon. A database engine residing in a daemon doesn't
>>> need to apply zonal locks. All accesses are requested on the single
>>> daemon, nothing else has to access the database file.

Just returning to this point, SQLite is alsoq not a daemon, so this one
is wrong. Perhaps you could give an accurate description of how the
whatever is is you think you’re describing differs from SQLite?

>>> c) Windows/msdos can have several applications competing to access the
>>> same file. One application can, at least theoretically, lock access to
>>> a portion of the database file (say, a single database record), and
>>> modify it, while another application has a different lock on another
>>> database record in the same file.
>>>
>>> d) Windows can also have a single daemon database engine "Linux style".
>>
>> I understand all that. Your claim was that you cannot have a
>> shared-file database without mandatory locks. That’s simply not true,
>> and SQLite is the constructive proof that it’s not true.
>
> No, I did not say that. If that is what you understood, then it
> reinforces what I said about Linux programmers not understanding this
> "mechanism".

Well, yes you did, “This feature is needed for databases that run
without a centralized daemon, but sharing the database file itself
instead.” In other words, a shared-file database.

>>> And I'm aware that Linux only programmers have a difficult time
>>> understanding this different lock concept.
>> I understand the difference between mandatory and advisory locks.
>
> That's not it.

According to the Windows API documentation:

Locking a portion of a file for exclusive access denies all other
processes both read and write access to the specified region of the
file. Locking a region that goes beyond the current end-of-file
position is not an error.

Locking a portion of a file for shared access denies all processes
write access to the specified region of the file, including the
process that first locks the region. All processes can read the
locked region.

That matches my understanding exactly. How does your understanding
differ?

--
https://www.greenend.org.uk/rjk/

On 26/08/2023 15:35, David W. Hodgins wrote:
> On Sat, 26 Aug 2023 06:50:45 -0400, Pancho <Pancho.Jones@proton.me> wrote:
>> The bit I can't get my head around is why it is practical to implement
>> advisory locks, but not mandatory locks. It seems to me once you have
>> the advisory lock, most of the hard work is done. I need to read up on
>> it.
>
> Using advisory locks is simpler to implement and works well as long as all
> of the software involved can be trusted to respect those locks.
>

In what way are advisory locks simpler to implement? Apart from a
trivial wrapper to an IO API, i.e. a thin wrapper making mandatory IO
operations obey the advisory locks, I can't see the difference.

The only significant difference I can see is the pragmatic one Richard
mentions, mandatory lock errors cause practical problems, backups etc,
in a way advisory lock errors do not.

This hunch is supported by Richard's mandatory lock counter example,
SQLite. A quick Google finds advice that the SQLite shared database file
should not be situated on a network drive, a common cause of lock
issues. Supporting a suspicion that advisory locks are also problematic,
but that the issues are more manageable. While I have no real experience
of Unix locks, it is common in my programming experience that the use of
many tools, techniques like advisory locks must be nuanced.

On 2023-09-01 03:26, Richard Kettlewell wrote:
> "Carlos E. R." <robin_listas@es.invalid> writes:
>> On 2023-08-25 12:13, Richard Kettlewell wrote:
>>> "Carlos E. R." <robin_listas@es.invalid> writes:
>>>> On 2023-08-25 03:10, Richard Kettlewell wrote:
>>>>> "Carlos E. R." <robin_listas@es.invalid> writes:
>>>>>> On 2023-08-24 14:14, Richard Kettlewell wrote:
>>>>>>> "Carlos E. R." <robin_listas@es.invalid> writes:
>>>>>>>> Dos share had features that Linux today doesn't have, AFAIK.
>>>>>>>>
>>>>>>>> Dos could lock for write or read an area of a file, for instance. And
>>>>>>>> those are mandatory locks. This feature is needed for databases that
>>>>>>>> run without a centralized daemon, but sharing the database file itself
>>>>>>>> instead.
>>>>>>> Obviously not true, you can have a shared-file database with
>>>>>>> advisory locks. SQLite is an example.
>>>>>> No, you can not. It is a different thing.
>>>>> In what way?
>>>>
>>>> a) It is kernel based mandatory locks.
>>>>
>>>> b) It is not a daemon. A database engine residing in a daemon doesn't
>>>> need to apply zonal locks. All accesses are requested on the single
>>>> daemon, nothing else has to access the database file.
>
> Just returning to this point, SQLite is alsoq not a daemon, so this one
> is wrong. Perhaps you could give an accurate description of how the
> whatever is is you think you’re describing differs from SQLite?

Ah, sqlite, ok. AFAIK, SQLite, as used for example by rpm, does not
allow concurrent access. Only one app can access the database.

The lock (mandatory or not) applies to the entire database file.

>
>>>> c) Windows/msdos can have several applications competing to access the
>>>> same file. One application can, at least theoretically, lock access to
>>>> a portion of the database file (say, a single database record), and
>>>> modify it, while another application has a different lock on another
>>>> database record in the same file.
>>>>
>>>> d) Windows can also have a single daemon database engine "Linux style".
>>>
>>> I understand all that. Your claim was that you cannot have a
>>> shared-file database without mandatory locks. That’s simply not true,
>>> and SQLite is the constructive proof that it’s not true.
>>
>> No, I did not say that. If that is what you understood, then it
>> reinforces what I said about Linux programmers not understanding this
>> "mechanism".
>
> Well, yes you did, “This feature is needed for databases that run
> without a centralized daemon, but sharing the database file itself
> instead.” In other words, a shared-file database.

But I'm not talking about full file mandatory (or advisory) locks. I am
talking about locks on a part of the file. That's a crucial difference
that tools like MSAccess do use and need.

>
>>>> And I'm aware that Linux only programmers have a difficult time
>>>> understanding this different lock concept.
>>> I understand the difference between mandatory and advisory locks.
>>
>> That's not it.
>
> According to the Windows API documentation:
>
> Locking a portion of a file for exclusive access denies all other
> processes both read and write access to the specified region of the
> file. Locking a region that goes beyond the current end-of-file
> position is not an error.
>
> Locking a portion of a file for shared access denies all processes
> write access to the specified region of the file, including the
> process that first locks the region. All processes can read the
> locked region.
>
> That matches my understanding exactly. How does your understanding
> differ?

Now it matches.

--
Cheers,
Carlos E.R.

"Carlos E. R." <robin_listas@es.invalid> writes:
> On 2023-09-01 03:26, Richard Kettlewell wrote:
>> Just returning to this point, SQLite is also not a daemon, so this
>> one is wrong. Perhaps you could give an accurate description of how
>> the whatever is is you think you’re describing differs from SQLite?
>
> Ah, sqlite, ok.

I’ve only mentioned it three times...

> AFAIK, SQLite, as used for example by rpm, does not
> allow concurrent access. Only one app can access the database.
>
> The lock (mandatory or not) applies to the entire database file.

Default behavior (AFAICS) for SQLite is many readers but at most one
writer, with an option for multiple writers. From the documentation it
looks like it does use per-page locks in some cases.

At any rate, no mandatory locks involved.

>> Well, yes you did, “This feature is needed for databases that run
>> without a centralized daemon, but sharing the database file itself
>> instead.” In other words, a shared-file database.
>
> But I'm not talking about full file mandatory (or advisory) locks.

Nor am I.

> I am talking about locks on a part of the file. That's a crucial
> difference that tools like MSAccess do use and need.

Linux’s file locking APIs cover individual regions of the file as well,
so no, there is no ‘crucial difference’ here.

I really don’t think the issue here is a lack of understanding by ‘Linux
programmers’.

--
https://www.greenend.org.uk/rjk/

Pancho <Pancho.Jones@proton.me> writes:
> On 26/08/2023 15:35, David W. Hodgins wrote:
>> On Sat, 26 Aug 2023 06:50:45 -0400, Pancho <Pancho.Jones@proton.me> wrote:
>>> The bit I can't get my head around is why it is practical to implement
>>> advisory locks, but not mandatory locks. It seems to me once you have
>>> the advisory lock, most of the hard work is done. I need to read up
>>> on it.
>> Using advisory locks is simpler to implement and works well as long
>> as all of the software involved can be trusted to respect those
>> locks.
>
> In what way are advisory locks simpler to implement? Apart from a
> trivial wrapper to an IO API, i.e. a thin wrapper making mandatory IO
> operations obey the advisory locks, I can't see the difference.

Some possible issues..

IO operations aren’t instantaneous. A conflicting IO operation might
already be underway at the point a lock is acquired. The implementation
must detect this and respond to it somehow.

Memory-mapped files must be handled somehow. The practical, but not very
useful, answer is “You can’t mix locks and mmap”. If you want to try to
make it work then:

- You have to update page tables in other processes (perhaps running on
other cores) every time a lock is acquired or released.

- You have to do something with processes when their memory accesses
conflict with a lock. (Suspend them until the lock is released? Send a
signal?)

- You have to deal with accesses to unlocked addresses in pages that
overlap locked regions. (Emulate the instruction?)

With advisory locks, on the other hand, the only things that need
synchronizing are the acquire and release operations.

--
https://www.greenend.org.uk/rjk/

On Fri, 01 Sep 2023 07:22:01 -0400, Pancho <Pancho.Jones@proton.me> wrote:

> On 26/08/2023 15:35, David W. Hodgins wrote:
>> On Sat, 26 Aug 2023 06:50:45 -0400, Pancho <Pancho.Jones@proton.me> wrote:
>>> The bit I can't get my head around is why it is practical to implement
>>> advisory locks, but not mandatory locks. It seems to me once you have
>>> the advisory lock, most of the hard work is done. I need to read up on
>>> it.
>>
>> Using advisory locks is simpler to implement and works well as long as all
>> of the software involved can be trusted to respect those locks.
>>
>
> In what way are advisory locks simpler to implement? Apart from a
> trivial wrapper to an IO API, i.e. a thin wrapper making mandatory IO
> operations obey the advisory locks, I can't see the difference.
>
> The only significant difference I can see is the pragmatic one Richard
> mentions, mandatory lock errors cause practical problems, backups etc,
> in a way advisory lock errors do not.
>
> This hunch is supported by Richard's mandatory lock counter example,
> SQLite. A quick Google finds advice that the SQLite shared database file
> should not be situated on a network drive, a common cause of lock
> issues. Supporting a suspicion that advisory locks are also problematic,
> but that the issues are more manageable. While I have no real experience
> of Unix locks, it is common in my programming experience that the use of
> many tools, techniques like advisory locks must be nuanced.

With mandatory locks atomic operations are required to avoid time of check,
time of use problems. That's has to be implemented at the i/o level for the
locks.

With advisory locks, the various parts work using communications between
the different parts to ensure one part doesn't clobber what's done by
another part.

There are various ways to implement either, each with pros and cons.

Regards, Dave Hodgins