On Tue, 2024-01-02 at 13:40 -0600, Craig A. Berry wrote:
> On 1/2/24 7:24 AM, Arne Vajhøj wrote:
> > On 1/2/2024 7:46 AM, Andy Burns wrote:
> > > Single Stage to Orbit wrote:
> > > > Arne Vajhøj wrote:
> > > > > You sort of get both with WSL.
> > > >
> > > > No, WSL is terrible! Use WSL2 instead.
> > >
> > > Performance-wise sure, but there is a certain technical elegance
> > > to
> > > the WSL1 mechanism.
> >
> > Was the problem with WSL1 performance?
> >
> > I always thought that the problem was compatibility
> > (that 99.9% compatibility was not god enough).
>
> The docs say that WSL2 performance is worse than WSL1 for operations
> involving file system integration.  Details here:
>
> https://github.com/microsoft/WSL/issues/4197#issuecomment-604592340

Eh? I thought it was WSL1 that had the performance issuses, not WSL2.
--
Tactical Nuclear Kittens

On 1/2/2024 9:12 AM, Arne Vajhøj wrote:
> On 1/2/2024 8:39 AM, Simon Clubley wrote:
>> On 2023-12-30, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> So I took:
>>> * what everybody knows about RMS
>>> * relative file and direct access fixed length file examples
>>>     I recently posted
>>> * the index-sequential file examples I have used numerous times before
>>> * some file read and file creation test code I did a few years ago
>>> and baked it into:
>>>
>>> https://www.vajhoej.dk/arne/articles/rms.html
>>
>> Some feedback:
>
> Thanks. Apperciated.

>> You may wish to make explicit what the maximum record size is with RMS.
>
> Yes. That is important. It may not have been a severe limitation
> in 1977, but it sure is today.
>
> And I would need to mention Fortran segmented files.

>> You may wish to make it clear that RMS is a part of VMS in that it is
>> within VMS itself and not just some user-mode library linked in to each
>> user program.
>
> I should probably mention EXEC mode
>
>> You may wish to make the byte ordering explicit by giving offsets to
>> each field. IOW, make it clear that the control data is at the start
>> of each record and that fields are in little-endian and not big-endian
>> format. This matters because different operating systems have both
>> different documentation and endian conventions.
>
> Yes.
>
> Not as big a problem today as 25 years ago. But still relevant.

Updated:
* add Groovy examples
* add examples using byte offset seek to mimic access by
record number to fixed length records
* add a lot about record size
* add note about RMS being exec mode and lengths being little endian

Still:

https://www.vajhoej.dk/arne/articles/rms.html

Arne

On Tue, 2 Jan 2024 23:21:23 -0000 (UTC), Dan Cross wrote:

> Take, for instance, the lack of internal kernel interfaces and gregkh's
> insistence that, not only are they unnecessary, they are _bad_: this can
> make things very hard to work with, with multiple generations of partial
> interfaces all coresident at the same time, and little incentive to
> clean up the resulting complexity or mess.

Could be worse. You could be required to carry all that baggage around
forever.

GregKH made this point some years back, about the state of respective USB
support in Windows versus Linux. At that point, Microsoft had rewritten
its USB stack three times, and so it was carrying around three different
driver APIs, and as long as there were third-party drivers using the
obsolete interfaces, would have to continue doing that essentially
forever.

At the same time, Linux had also rewritten its USB stack three times. But
it had the luxury of starting pretty much from scratch each time, without
having to carry around a lot of legacy baggage, because all the drivers
included in the Linux kernel source tree could be updated at the same
time.

Just one of many reasons why Linux is a much trimmer and more efficient OS
than Windows.

On Wed, 3 Jan 2024 00:03:36 -0000 (UTC), Dan Cross wrote:

> What I said is that it is a fraught proposition to try to keep up with
> the rate of change in the Linux kernel from outside of the Linux kernel.

And that “outside of the Linux kernel” includes the part of the Universe
containing Microsoft. It, too, has a struggle, even with its vast
resources, keeping up with the pace of Linux kernel development.

> To which I replied that almost certainly the inverse is true; i.e., that
> the Linux kernel folks probably have access to several orders of
> magnitude more resources than Microsoft can put to Windows.

Given how much revenue Microsoft is supposedly earning from Windows, don’t
you think it should be putting a proportionate level of investment back
into it?

> In article <un26bd$2sllq$2@dont-email.me>,
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>>That "niche" is the reason why they have had to resort to WSL2, to bring
>>Linux-type APIs to Windows. And why do they need Linux-type APIs on
>>Windows, anyway? Because that's what the developers are increasingly
>>relying on. Why didn't WSL1 work? Because the Windows kernel wasn't up
>>to it.
>
> That seems like speculation on your part.

Microsoft’s own actions are all the evidence we need. Why abandon
something, after putting so much effort into it, if you could have got it
to work?

> They surely moved to WSL2 because the best, cheapest way to be "bug
> compatible" with Linux is to just run Linux.

After already putting all that investment into WSL1? That good old NT
kernel not versatile enough to emulate the little quirks as well as the
salient features?

As further evidence, consider how WINE is able to be bug-compatible with
Windows, on top of the Linux kernel. Why can’t Microsoft, with more
resources at its disposal than both the Linux kernel and WINE projects
*combined*, return the favour?

> Python is important; this has does not imply that
> Unix-style select/poll on a pipe under Windows in Python is important.

So how do you run that large installed base of Python code on Windows
without that compatibility?

> For more general types of asynchronous IO (storage, networking) it says
> nothing at all, and these are certainly more important than pipes which
> are just one kind of IPC mechanism (and not super relevant to Python
> specifically).

They’re a core feature of POSIX. They exist because they make for a very
convenient model for certain common kinds of IPC, as the original Unix
creators discovered in their experiments.

>>Remember why Microsoft needs WSL, clunky as it is: it's not something it
>>bestowed as a special favour on the Linux or open-source world or
>>anything like that: it created it because it had to, for sheer business
>>survival.
>
> I actually agree with this, but I think your argument here is poor.
> MSFT needs Linux compatability because the world is trending towards
> Linux and they can't keep up, yes. It does not follow that their
> engineers are bad, or even that their kernel is bad.

WSL1 would be evidence to the contrary.

And yes, engineers can be individually smart, yet due to a dysfunctional
and risk-averse corporate culture, they end up producing a mediocre net
product.

On Wed, 2024-01-03 at 02:46 +0000, Lawrence D'Oliveiro wrote:
> At the same time, Linux had also rewritten its USB stack three times.
> But it had the luxury of starting pretty much from scratch each time,
> without having to carry around a lot of legacy baggage, because all
> the drivers included in the Linux kernel source tree could be updated
> at the same time.

That's true but it is a source of considerable pain for commercial
products such as VMware, VirtualBox, ZFS and others. They all have to
devote substantial engineering resources to release updates for every
kernel release.
--
Tactical Nuclear Kittens

Arne Vajhøj wrote:

> Note that Cygwin and WSL does completely different things.

Sure, but they all fall into my "mixing windowsy things with unixy
things" slot ... also I forgot all about Interix/SFU

In article <un2icp$2vhkg$4@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Wed, 3 Jan 2024 00:03:36 -0000 (UTC), Dan Cross wrote:
>
>> What I said is that it is a fraught proposition to try to keep up with
>> the rate of change in the Linux kernel from outside of the Linux kernel.
>
>And that "outside of the Linux kernel" includes the part of the Universe
>containing Microsoft. It, too, has a struggle, even with its vast
>resources, keeping up with the pace of Linux kernel development.

A) you are clearly speculating about the "resources" you think
that Microsoft can apply to Windows. B) you have not
acknowledged that, whatever resources MSFT can bring to bear,
Linux can _bring more_.

>> To which I replied that almost certainly the inverse is true; i.e., that
>> the Linux kernel folks probably have access to several orders of
>> magnitude more resources than Microsoft can put to Windows.
>
>Given how much revenue Microsoft is supposedly earning from Windows, don't
>you think it should be putting a proportionate level of investment back
>into it?

A amateurish attempt to change the subject, but regardless,
that's a business, not a technical, decision at Microsoft. It
could be that they see the writing on the wall and don't feel
that it's a good investment.

>> In article <un26bd$2sllq$2@dont-email.me>,
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>>That "niche" is the reason why they have had to resort to WSL2, to bring
>>>Linux-type APIs to Windows. And why do they need Linux-type APIs on
>>>Windows, anyway? Because that's what the developers are increasingly
>>>relying on. Why didn't WSL1 work? Because the Windows kernel wasn't up
>>>to it.
>>
>> That seems like speculation on your part.
>
>Microsoft's own actions are all the evidence we need. Why abandon
>something, after putting so much effort into it, if you could have got it
>to work?

Your logical fallacy is assuming that because they _dont't_ do
something that that implies that they _can't_ do that thing.
There are many reasons that they may choose not to do something
that are totally independent from their ability to do that
thing.

>> They surely moved to WSL2 because the best, cheapest way to be "bug
>> compatible" with Linux is to just run Linux.
>
>After already putting all that investment into WSL1? That good old NT
>kernel not versatile enough to emulate the little quirks as well as the
>salient features?

Strawman. We've already discussed why they decided to move to
WSL2. Here, their inability to keep up with Linux is not about
technical ability, it's about resources, which (again) they have
fewer of than the rest of the world combined applies to Linux.

>As further evidence, consider how WINE is able to be bug-compatible with
>Windows, on top of the Linux kernel. Why can't Microsoft, with more
>resources at its disposal than both the Linux kernel and WINE projects
>*combined*, return the favour?

Again, you are assuming that Microsoft has "more resources at
its disposal" than Linux, but I see no evidence of that; in fact
I see significant evidence to the contrary.

Go ahead and browse the commit lots in the Linux kernel git
repo: how many author addresses end with meta.com, amazon.com,
google.com, ibm.com, intel.com, amd.com, redhat.com, nvidia.com,
adobe.come, etc? Or, for that matter, microsoft.com? And we're
not even talking about the smaller companies (altera, et al).

Even for those that don't, how many of the remaining offers work
for one of the FAANG companies? Do you really think that
Microsoft has more resources _combined_ working on Windows than
the rest of those companies are devoting to Linux?

As for WINE, it's compatibilty is not great.

>> Python is important; this has does not imply that
>> Unix-style select/poll on a pipe under Windows in Python is important.
>
>So how do you run that large installed base of Python code on Windows
>without that compatibility?

Since the vast bulk of Python code out there probably doesn't
try to mix pipes with select or poll, I'd imagine you just run
it.

>> For more general types of asynchronous IO (storage, networking) it says
>> nothing at all, and these are certainly more important than pipes which
>> are just one kind of IPC mechanism (and not super relevant to Python
>> specifically).
>
>They're a core feature of POSIX. They exist because they make for a very
>convenient model for certain common kinds of IPC, as the original Unix
>creators discovered in their experiments.

"...in their experiments." Um, sure. Doug proposed it and Ken
implemented it in a weekend. It was relevatory in the context
of Unix, but not necessarily in other systems.

But so what? We're talking about Python code here, which mostly
insulates the programmer from something as low-level as POSIX.
Again, it seems like the thing that the vast, vast majority of
the tiny fraction of Python programmers who deal with such
things are going to care about is asynchronous IO for networking
and storage, not pipes. Honing in on that one aspect of
incompatibility doesn't really go very far to prove a general
point.

>>>Remember why Microsoft needs WSL, clunky as it is: it's not something it
>>>bestowed as a special favour on the Linux or open-source world or
>>>anything like that: it created it because it had to, for sheer business
>>>survival.
>>
>> I actually agree with this, but I think your argument here is poor.
>> MSFT needs Linux compatability because the world is trending towards
>> Linux and they can't keep up, yes. It does not follow that their
>> engineers are bad, or even that their kernel is bad.
>
>WSL1 would be evidence to the contrary.

Not really; see above.

>And yes, engineers can be individually smart, yet due to a dysfunctional
>and risk-averse corporate culture, they end up producing a mediocre net
>product.

Maybe, but that's a different matter. I think the probability
that you know someone who's worked on both Linux and Windows at
the kernel level is approximately 0, as evidenced by your lack
of understanding of the technical and business issues involved.

- Dan C.

In article <7b209da2cb6d3666421c56fefbd470ceba999f36.camel@munted.eu>,
Single Stage to Orbit <alex.buell@munted.eu> wrote:
>On Tue, 2024-01-02 at 13:40 -0600, Craig A. Berry wrote:
>> On 1/2/24 7:24 AM, Arne Vajhøj wrote:
>> > On 1/2/2024 7:46 AM, Andy Burns wrote:
>> > > Single Stage to Orbit wrote:
>> > > > Arne Vajhøj wrote:
>> > > > > You sort of get both with WSL.
>> > > >
>> > > > No, WSL is terrible! Use WSL2 instead.
>> > >
>> > > Performance-wise sure, but there is a certain technical elegance
>> > > to
>> > > the WSL1 mechanism.
>> >
>> > Was the problem with WSL1 performance?
>> >
>> > I always thought that the problem was compatibility
>> > (that 99.9% compatibility was not god enough).
>>
>> The docs say that WSL2 performance is worse than WSL1 for operations
>> involving file system integration.  Details here:
>>
>> https://github.com/microsoft/WSL/issues/4197#issuecomment-604592340
>
>Eh? I thought it was WSL1 that had the performance issuses, not WSL2.

Got a citation? I'd believe it's the other way around; a world
switch into Linux from Windows is going to be more expensive
than a system call, and accessing a filesystem remotely (surely
how they implement access to NTFS from WSL2) will mean
ping-ponging between Windows and Linux several times to satisfy
an IO request.

- Dan C.

In article <un293n$2tfib$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 1/2/2024 2:25 PM, Andy Burns wrote:
>> Lawrence D'Oliveiro wrote:
>>> And, in spite of the fact that it was supposed to be implementing a well-
>>> documented API, with plenty of example source code to refer to, they
>>> still
>>> couldn’t get WSL1 to work right. So they had to chuck it away and
>>> bring in
>>> a proper Linux kernel instead.
>>
>> I didn't do anything other than "play" with WSL1, but I thought
>> performance was the issue.
>>
>> I think I did more with MKS Toolkit and Cygwin than WSL.
>
>Note that Cygwin and WSL does completely different things.
>
>Cygwin:
>
>*nix and/or Windows source--Cygwin toolchain-->Windows executable
>
>WSL:
>
>*nix source--Linux toolchain-->Linux executable

More like: "cygwin executes Windows executables that are built
from Unix-y sources using compatibility libraries, while WSL1
executes Linux-branded ELF binaries using a compatibility layer
in the Windows kernel." Toolchains are only tangentially
relevant.

- Dan C.

In article <un2hq1$2vhkg$3@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Tue, 2 Jan 2024 23:21:23 -0000 (UTC), Dan Cross wrote:
>
>> Take, for instance, the lack of internal kernel interfaces and gregkh's
>> insistence that, not only are they unnecessary, they are _bad_: this can
>> make things very hard to work with, with multiple generations of partial
>> interfaces all coresident at the same time, and little incentive to
>> clean up the resulting complexity or mess.
>
>Could be worse. You could be required to carry all that baggage around
>forever.
>
>GregKH made this point some years back, about the state of respective USB
>support in Windows versus Linux. At that point, Microsoft had rewritten
>its USB stack three times, and so it was carrying around three different
>driver APIs, and as long as there were third-party drivers using the
>obsolete interfaces, would have to continue doing that essentially
>forever.
>
>At the same time, Linux had also rewritten its USB stack three times. But
>it had the luxury of starting pretty much from scratch each time, without
>having to carry around a lot of legacy baggage, because all the drivers
>included in the Linux kernel source tree could be updated at the same
>time.
>
>Just one of many reasons why Linux is a much trimmer and more efficient OS
>than Windows.

You are conflating _internal_ interfaces and _external_
interfaces. Linux has none of the former; it has strong
backwards compatibility guarantees for the latter ("thou shalt
not break userspace").

The lack of internal interfaces mean that it's difficult to
evolve kernel internals without significant churn. E.g.,
filesystems are deeply entwined with the virtual memory
subsystem, as is networking; everything speaks directly to
the process code, etc.

Linux is extraordinarily bloated.

- Dan C.

On Wed, 2024-01-03 at 13:29 +0000, Dan Cross wrote:
> > >
> > > https://github.com/microsoft/WSL/issues/4197#issuecomment-604592340
> >
> > Eh? I thought it was WSL1 that had the performance issuses, not
> > WSL2.
>
> Got a citation?  I'd believe it's the other way around; a world
> switch into Linux from Windows is going to be more expensive
> than a system call, and accessing a filesystem remotely (surely
> how they implement access to NTFS from WSL2) will mean
> ping-ponging between Windows and Linux several times to satisfy
> an IO request.

With WSL2, both the Windows NT kernel and the Linux kernel run on top
of a hypervisor. It's a nice solution and performance differences
between the two WSL systems should be night and day.

https://thecodeblogger.com/2020/08/22/understanding-differences-between-wsl-1-and-wsl-2/
--
Tactical Nuclear Kittens

In article <58a152d7482131319b40481943ad2ff6ce71c166.camel@munted.eu>,
Single Stage to Orbit <alex.buell@munted.eu> wrote:
>On Wed, 2024-01-03 at 13:29 +0000, Dan Cross wrote:
>> > >
>> > > https://github.com/microsoft/WSL/issues/4197#issuecomment-604592340
>> >
>> > Eh? I thought it was WSL1 that had the performance issuses, not
>> > WSL2.
>>
>> Got a citation?  I'd believe it's the other way around; a world
>> switch into Linux from Windows is going to be more expensive
>> than a system call, and accessing a filesystem remotely (surely
>> how they implement access to NTFS from WSL2) will mean
>> ping-ponging between Windows and Linux several times to satisfy
>> an IO request.
>
>With WSL2, both the Windows NT kernel and the Linux kernel run on top
>of a hypervisor. It's a nice solution and performance differences
>between the two WSL systems should be night and day.
>
>https://thecodeblogger.com/2020/08/22/understanding-differences-between-wsl-1-and-wsl-2/

That doesn't really explain why you'd think that WSL1 would be
appreciably slower (or slower at all) than WSL2. Consider that
Windows is still responsible for running IO devices and
providing access to e.g. the filesystem for Linux in the latter;
this will necessarily require lots of context switching between
the two (where in this context "context" means running in either
a Linux or Windows guest under a shared hypervisor) as Linux
accesses services provided by Windows. In WSL1 there would be
no such overhead.

- Dan C.

Arne Vajhøj schrieb am 02.01.2024 um 15:12:
> [...]
>
> <quote>
> Nobody seems to see a purpose with VFC record format. But DCL create
> files in VFC record format, so it is used.
> ...
>  Fortran carriage control use the first column in file for control. A
> space ' ' in first column means ordinary new line. A one '1' in first
> column means new page. This is a very old Fortran convention. And
> usually it is only files generated by Fortran programs that use Fortran
> carriage control, but VMS and RMS support sit.
> [...]

In addition, '+' means no line feed (overprint) and '0' means two new lines.

(from my Fortran programming days back in the early 80s...)

Hans.

On Wed, 03 Jan 2024 08:54:23 +0000, Single Stage to Orbit wrote:

> On Wed, 2024-01-03 at 02:46 +0000, Lawrence D'Oliveiro wrote:
>
>> At the same time, Linux had also rewritten its USB stack three times.
>> But it had the luxury of starting pretty much from scratch each time,
>> without having to carry around a lot of legacy baggage, because all the
>> drivers included in the Linux kernel source tree could be updated at
>> the same time.
>
> That's true but it is a source of considerable pain for commercial
> products such as VMware, VirtualBox, ZFS and others. They all have to
> devote substantial engineering resources to release updates for every
> kernel release.

The usual recommendation is that they should contribute the necessary
drivers to the mainline Linux kernel--along with a commitment to keep
maintaining them.

Microsoft discovered this the hard way, when it got some Hyper-V drivers
accepted into the kernel, and then forgot about the part that every piece
of code in the kernel has to have a responsive maintainer. It took the
threat of the code being dropped from the kernel to make them sit up and
take notice.

On Wed, 3 Jan 2024 09:03:17 +0000, Andy Burns wrote:

> ... also I forgot all about Interix/SFU

Apparently Interix/SFU was the result of a temporary lapse on the part of
Microsoft. In those days, it was possible to get documentation from them
for how to write your own “personality” on top of the NT kernel, which
Interix did.

Then Microsoft decided it didn’t want this knowledge becoming publicly
known. So they acquired Interix to stop it spreading further.

On 1/3/2024 12:21 PM, Hans Bachner wrote:
> Arne Vajhøj schrieb am 02.01.2024 um 15:12:
>> <quote>
>> Nobody seems to see a purpose with VFC record format. But DCL create
>> files in VFC record format, so it is used.
>> ...
>>   Fortran carriage control use the first column in file for control. A
>> space ' ' in first column means ordinary new line. A one '1' in first
>> column means new page. This is a very old Fortran convention. And
>> usually it is only files generated by Fortran programs that use
>> Fortran carriage control, but VMS and RMS support sit.
>> [...]
>
> In addition, '+' means no line feed (overprint) and '0' means two new
> lines.
>
> (from my Fortran programming days back in the early 80s...)

Yes. I guess I was lazy and just noted those that I use.

+ and 0 still works fine.

$ type z.txt
AAA
+B
0CC
$ set file/attr=rat=ftn z.txt
$ type z.txt
BAA

CC

I will update.

Arne

On Wed, 3 Jan 2024 21:52 +0000 (GMT Standard Time), John Dallman wrote:

> In article <umv3ll$2adef$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
> wrote:
>
>> If MS want to continue the big presence in the consumer segment,
>> then they need to address it. Somehow they need to get into the phone
>> and tablet market. This is why the MS CEO recently said that he
>> regretted killing Windows Phone.
>
> Then he still hasn't faced up to the reason for its failure.As far as I
> can tell, that was because it was too much like desktop/laptop Windows.

There you have in a nutshell, this conflation between the core OS and the
GUI that should be a separate layer on top of the OS. Remember, the whole
“tiles” interface was developed as part of the emphasis on mobile, and
then Windows 8 tried to retrofit it onto the desktop, which people hated.

Imagine saying that Android is “too much like desktop/laptop/server/
embedded/supercomputer Linux”, because it is: they share essentially the
same kernel. Yet that didn’t stop Android from taking over the mobile
world: in fact, it probably helped.

On Wed, 2024-01-03 at 15:16 +0000, Dan Cross wrote:
> >
> > With WSL2, both the Windows NT kernel and the Linux kernel run on
> > top
> > of a hypervisor. It's a nice solution and performance differences
> > between the two WSL systems should be night and day.
> >
> > https://thecodeblogger.com/2020/08/22/understanding-differences-between-wsl-1-and-wsl-2/
>
> That doesn't really explain why you'd think that WSL1 would be
> appreciably slower (or slower at all) than WSL2.  Consider that
> Windows is still responsible for running IO devices and
> providing access to e.g. the filesystem for Linux in the latter;
> this will necessarily require lots of context switching between
> the two (where in this context "context" means running in either
> a Linux or Windows guest under a shared hypervisor) as Linux
> accesses services provided by Windows.  In WSL1 there would be
> no such overhead.

You've tickled my curiousity now. When I've time I'll spin up a couple
Windows VMs, one with WSL1, and one with WSL2, and do some benchmarks.
See who's right.
--
Tactical Nuclear Kittens

On Wed, 2024-01-03 at 19:01 +0000, Lawrence D'Oliveiro wrote:
> > That's true but it is a source of considerable pain for commercial
> > products such as VMware, VirtualBox, ZFS and others. They all have
> > to devote substantial engineering resources to release updates for
> > every kernel release.
>
> The usual recommendation is that they should contribute the necessary
> drivers to the mainline Linux kernel--along with a commitment to keep
> maintaining them.
>
> Microsoft discovered this the hard way, when it got some Hyper-V
> drivers accepted into the kernel, and then forgot about the part that
> every piece of code in the kernel has to have a responsive
> maintainer. It took the threat of the code being dropped from the
> kernel to make them sit up and take notice.

It's the same old story, costs != profit and beancounters are not
always right.
--
Tactical Nuclear Kittens

On 2024-01-03, John Dallman <jgd@cix.co.uk> wrote:
>
> Me, I regarded Windows 2000 as the peak of their GUI design, and it's
> been getting worse, on average, ever since.
>

Unfortunately, that seems to be the case with modern GUI designs in
general.

For example, compare the disaster that is GTK4 with the much cleaner GTK2,
including how there is no regard to backwards compatibility or fully
duplicating existing functionality. Also, just how arrogant and out of
touch modern GUI designers are.

How to move from GTK3 to GTK4 (basically, rewrite your code):

https://docs.gtk.org/gtk4/migrating-3to4.html

One very arrogant GUI designer example from a couple of years ago:

https://gitlab.gnome.org/GNOME/gtk/-/issues/3787

Basically, more blurry and hard to read text in GTK4 wasn't considered
a problem by the current GTK developers and users were initally told
outright it was not going to be fixed. :-(

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2024-01-03, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
> Imagine saying that Android is ?too much like desktop/laptop/server/
> embedded/supercomputer Linux?, because it is: they share essentially the
> same kernel. Yet that didn?t stop Android from taking over the mobile
> world: in fact, it probably helped.

Yes. I have the Alpine Linux userland running just fine on my Android
phone for some basic stuff (with the help of PRoot). Unfortunately,
I have to use vi on my phone because emacs requires a proper keyboard... :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Thu, 04 Jan 2024 09:30:20 +0000, Single Stage to Orbit wrote:

> On Wed, 2024-01-03 at 19:01 +0000, Lawrence D'Oliveiro wrote:
>>
>> On Wed, 03 Jan 2024 08:54:23 +0000, Single Stage to Orbit wrote:
>>>
>>> That's true but it is a source of considerable pain for commercial
>>> products such as VMware, VirtualBox, ZFS and others. They all have to
>>> devote substantial engineering resources to release updates for every
>>> kernel release.
>>
>> The usual recommendation is that they should contribute the necessary
>> drivers to the mainline Linux kernel--along with a commitment to keep
>> maintaining them.
>>
>> Microsoft discovered this the hard way, when it got some Hyper-V
>> drivers accepted into the kernel, and then forgot about the part that
>> every piece of code in the kernel has to have a responsive maintainer.
>> It took the threat of the code being dropped from the kernel to make
>> them sit up and take notice.
>
> It's the same old story, costs != profit and beancounters are not always
> right.

And yet you’d think those beancounters would notice the very opportunity
to save money mentioned above, and stop having to “devote substantial
engineering resources to release updates for every kernel release”.

On Thu, 4 Jan 2024 13:35:14 -0000 (UTC), Simon Clubley wrote:

> On 2024-01-03, John Dallman <jgd@cix.co.uk> wrote:
>>
>> Me, I regarded Windows 2000 as the peak of their GUI design, and it's
>> been getting worse, on average, ever since.
>>
> Unfortunately, that seems to be the case with modern GUI designs in
> general.
>
> For example, compare the disaster that is GTK4 with the much cleaner
> GTK2 ...

Notice what you are comparing here: on the one hand, two different OS
versions, on the other hand, two different versions of a GUI toolkit that
lives entirely in userland.

In the first case, you can only change the GUI by entirely replacing the
OS. In the latter case, it’s just a matter of choosing different packages
to install. In fact, the common Linux distros continue to offer GUI
packages based on all three versions of GTK from GTK2 onwards, so
switching between them is a simple matter of logging out of one and
logging back into another.

On 1/3/2024 8:31 AM, Dan Cross wrote:
> In article <un293n$2tfib$1@dont-email.me>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 1/2/2024 2:25 PM, Andy Burns wrote:
>>> Lawrence D'Oliveiro wrote:
>>>> And, in spite of the fact that it was supposed to be implementing a well-
>>>> documented API, with plenty of example source code to refer to, they
>>>> still
>>>> couldn’t get WSL1 to work right. So they had to chuck it away and
>>>> bring in
>>>> a proper Linux kernel instead.
>>>
>>> I didn't do anything other than "play" with WSL1, but I thought
>>> performance was the issue.
>>>
>>> I think I did more with MKS Toolkit and Cygwin than WSL.
>>
>> Note that Cygwin and WSL does completely different things.
>>
>> Cygwin:
>>
>> *nix and/or Windows source--Cygwin toolchain-->Windows executable
>>
>> WSL:
>>
>> *nix source--Linux toolchain-->Linux executable
>
> More like:

Less like that.

> "cygwin executes Windows executables that are built
> from Unix-y sources using compatibility libraries,

Cygwin does not execute executables. Cygwin produces regular
Windows executables that are executed by Windows line any other
Windows executable.

And as I described above then Cygwin can build both *nix source and
Windows source (and hybrids of those) not just *nix sources.

> while WSL1
> executes Linux-branded ELF binaries using a compatibility layer
> in the Windows kernel."

WSL execute standard Linux binaries - not something just Linux branded.
And being ELF binaries is not sufficient - it has to be Linux binaries.

> Toolchains are only tangentially
> relevant.

Toolschains are really the only thing that matters.

WSL exist to allow developers to run Linux toolchains.

Arne

On 1/3/2024 4:52 PM, John Dallman wrote:
> In article <umv3ll$2adef$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
> wrote:
>
>> If MS want to continue the big presence in the consumer segment,
>> then they need to address it. Somehow they need to get into
>> the phone and tablet market. This is why the MS CEO recently
>> said that he regretted killing Windows Phone.
>
> Then he still hasn't faced up to the reason for its failure. As far as I
> can tell, that was because it was too much like desktop/laptop Windows.
>
> iOS and Android both have pretty gentle learning curves. You don't need
> to know much to start using them, and fairly small steps in learning open
> up more activities quite quickly.
>
> Windows Phone's GUI was ... kind of complicated. It makes sense to
> someone who's been closely following the evolution of desktop Windows
> since about the year 2000, and always sticking to the Microsoft defaults.
> Like, say, Microsoft's UI designers and marketing people.
>
> But it has been a pretty twisty path, and there's a lot of accumulated
> strangeness. The result is not friendly to someone who has never used
> Windows, and that's quite hard for someone who is very pro-Windows to
> understand.

I don't know hos much he was thinking about "the Windows Phone 8
code base" versus just "a MS OS for phones".

But what I heard from most WP users back then was that they
actually liked the UI.

(they hated the Windows 8 attempt to look like WP8 though)

What made many of them drop WP was the lack of apps. The WP
apps eco-system could not compete with the gazillion
iOS and Android apps.

Companies only developed apps for iOS and Android, because there were
too few WP users. And there were too few WP users because companies
only developed apps for iOS and Android.

That problem still exist for anyone trying to get into the
phone market without being hooked into Apple App Store or
Google Play.

Arne