The Linux Kernel Has Been Forcing Different Behavior For Processes Starting With "X"

[sinepgib]

Sorry for the delay xfcemint, it's been a busy week. I haven't read the other article yet.

Here's my response to this one. Parts I didn't quote I pretty much agree with and am comfortable with how they are phrased.

A translator service: a program providing an ABI, by converting the ABI into a mix of APIs and ABIs.

The use of APIs here would be to convey that you could rebuild the translator whenever the lower layer breaks? Otherwise I'm not sure why APIs are relevant in this context.

App developers write an application, but the application needs APIs. App developers prefer to ship executables, which require stable ABIs. There is an internal contradiction in app developers. Actors prefer to resolve their internal contradictions.

I'm not sure what the contradiction is.

Also note that shim libraries may exist that can convert an ABI into a shim API.

Would rephrase to translator library for consistency with the glossary.

Vendors' preferences: vendors are very diverse, and their goals are also diverse. Vendors generally prefer to provide an API to an ABI. Providing a stable API or a stable ABI usually inflicts extra cost and development time to them.

The current situation is the result of the following forces:
- Vendors provide APIs.
- Some APIs become quasi-stable. ABIs might be too low-level to be of practical use, or they might not be well documented, or they might be unstable.
- App developers will use APIs.
- This incentivizes the ecosystem of Linux distributions ("the ecosystem") to providing tools for managing the situation of unstable APIs. Those tools have grown sufficiently sophisticated to solve practically all the problems arising from of such a situation, except for the need of app developers to ship executables.
- Vendors have no good incentives for providing stable ABIs. Some incentives might exist for providing stable APIs.

I would add one item about the bazaar nature of open source incentivizing the rise of multiple incompatible solutions to the same problem. That doesn't help to stabilize an ABI in practice.

- point 3: I find it to be likely that the possibility of incentivizing creation of translator libraries based only on stable ABIs has not been sufficiently considered and discussed.

With "based only on stable ABIs" do we mean the ones they provide or the ones they sit on top? It'd make more sense to me for those to provide a stable ABI rather than require it, but I find how it's phrased ambiguous.

- point 4: I find it to be likely that the possibility of incentivizing the retention of old and superseded ABIs by Linux distributions has not been sufficiently considered and discussed.

This part is just discussing the point, but I agree we should consider it: I'd say point 3 is a much better approach, as it's a more "don't pay for what you don't use" way. I have this really old binary? Ok, I run my translator library/service. All my programs have been compiled from source? Ok, I can save a few kB of RAM.

- point 5: I find it to be likely that, when a smaller vendor is competing with a larger vendor, the smaller one is likely to push for standardization.

I agree, and I think it's actually why Azure and GCP seem to provide a better out-of-the-box experience for Kubernetes than AWS (or so I heard from devops). While all of them are giant companies, only one is the main player in cloud computing, and that one focuses on keeping their proprietary solutions on top and (presumably) actively tries to make migrating to standards a pain.

- point 6: I find it to be likely that, when a competition between two libraries or services of similar functionality exists, then a resulting force of a push for standardization is likely to be created.

I have mixed impressions about this one. First, I'm not sure which actors you suggest push for this. Then, while I think sometimes the library vendors do push for standardization, it doesn't happen all the time. The one thing I've seen causing such efforts are stuff revolving the X and Wayland protocols and their surrounding services. But in terms of library APIs (as opposed to bus protocols) I'm not sure there's been such a push.

- point 7: I find it to be likely that, the possibility of incentivizing (smaller) vendors to create competing services and libraries has not been sufficiently considered and discussed.

I think this merits discussion, but if the competition involves the API itself it may actually hinder the development of reliable, stable APIs and ABIs. If it concerns mostly the implementation of agreed-upon interfaces, it will probably be beneficial.

- point 8: I find it to be likely that the possibility of incentivizing creation of smaller services and smaller libraries that can be used by multiple vendors (to simplify development of services) has not been sufficiently considered and discussed.

I could see some resistance from application developers here. There's already a bit of trouble with having myriads of tiny deps in the high level development world, specially now that supply chain is in the agenda. I think most developers will want a bigger layer to rely on. Unless you mean using those interchangeably to build such a layer in each vendor (e.g. for a distro).

[oiaohm]

Yes, that is the same as my interpretation. I reasoned: there already exists a huge toolset for dealing with unstable APIs in Linux distributions, so I don't see a reason why not to use it for "services" (the term "services" is a weird catagory in the current situation, noone except the microkernel "loonies" can have such a perspective).

Service is a term you have to be very careful with.

https://en.wikipedia.org/wiki/Windows_NT#/media/File:Windows_2000_architecture.svg

It not just micro-kernels that point of view that its core. This is windows NT forwards architecture with executive services basically Windows NT equal to Linux kernel subsystems.

Historic term daemon fell out of favor and use to be used for user space services that are not driver related. Microkernel design never formally declared what the name was for subsystem/executive services vs daemons/ user space services that are not driver/core kernel related that sit on top the the ABI/API provided by the kernel and subsystem/executive services.

The app developers are using one thing (API), but want another (stable ABI). They can't solve this problem themselves, they are stuck in the current situation. I'm sure that there is a contradiction there, but perhaps it isn't really "internal". Anyway, they would certainly prefer the issue to be resolved, which is important for "point 10".

Application developers are not this good. Application developers have multi different issues.
1) they want to show good performance.

Yes that number 1 leads to many issues. Like depending on quirks in particular implementations that are bugs because it will give them higher performance even when they know it is a bug that should be fixed. So not all application developers want stable ABI/API some of them want the latest and greatest API/ABI so they get the best performance.

This is a issue you have you are thinking the will of application developers are unified. Valve work on the steam runtime is interesting as they are trying to come up with solutions that solve for all different application developers groups.

I'm against rephrasing it. "Shim" in this context means something simple and small. On the other hand, "translator libraties" are named such to be consistent with "translator services". The only strange thing is that "translator libraies" are no different than any other libraries.

Shim is a windows term and when you would look it up its most likely not what you attend at all. Shim modified the dynamic loader under windows.

https://techcommunity.microsoft.com/t5/ask-the-performance-team/demystifying-shims-or-using-the-app-compat-toolkit-to-make-your/ba-p/374947

This on the Linux side the closest thing is libcapsule.

https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/tree/706c7d4b95a1c949f4e6c783d0edee037d55ea72/subprojects/libcapsule

Neither is what I think you are going for.

Closest defined terms I can think of is a Wrapper library and Compatibility layer.

I think that there must be a bazaar, it is unavoidable. You can't get a stable solution immediately, it has to go through the bazaar phase.

This is something you miss the its partly covered in the book the "The Cathedral and the Bazaar". Lets look at the khronos group or Wayland protocols or Linux kernel users space stable ABIs, WIndows stable ABIs... Every case you find that there is a Cathedral.

There are examples where there was no bazaar phase before stable ABI in different areas have appeared on Linux. The one part that must be there is a Cathedral to uniform ratify what is valid and correct.

Remember each Linux distributions is basically its own Cathedral. Linux world has the same problem as the Christianity with all the competing churches/Cathedrals.

Linux world has a Bazaar filled with Cathedrals with Bazaars inside those Cathedrals that at times has another bazaar inside then Cathedral inside .... Basically the old saying turtles all the way down.

My thought was: Incentivizing creation of new translator libraries that provide an API (stable or unstable), but translate (make calls, i.e. sit on top) only to stable ABIs. Translator libraries can't provide an ABI, because libraries can provide APIs only.

Translation libraries are normally wanted by parties like Valve to run old applications or application developers who are not updating any more. Performance cost is never liked.

Well, that's related to my idea that, in order to get a stable ABI, you first have to go through a bazaar phase. In the beginning, it looks like all competing libraries and services are creating a mess caused by mutual incompatibility, but in the end, the situation should actually stabilize. In order for the situation to stabilize, it must first mature. So, all the services and libraries must resolve the initial issues that exist because, at first, services and libraries get rushed out to cover some gaping holes (lack of required functionality) in ABIs/APIs.

No this is your wishful thinking we are 2+ decades in and the reality ABI don't naturally stabilize. Remember gnome with GTK formally agreed to have a cycle of intentionally breaking backwards compatibility. Same appears from Qt and many other core like libraries.

ABI only stabilize if some form of Cathedral body(yes central body) exists to make it happen with testsuites and so on to test conformance and detect when conformance is broken. This rule applies to Linux kernel for user space ABI, Microsoft, Khronos group ... basically any group that makes stable ABI/API that application developers can depend on.

This is not about becoming mature. Qt selling new versions of their libraries is in the company behind them interest and a large selling feature is performance not backwards binary compatibility.

Remember party like EPIC does not what to have to depend on Valve for a solution. This is another factor when you have two companies in tooth and nail competition with each other they can feel that they cannot trust the other party so they would prefer to use a solution from a different party who is not the competition this is another factor in API/ABI fragmentation under Linux.

Linus Torvalds defines this problem as attempting to Herding cats. Yes application developers will say they will want a stable ABI but when you get closer they turn out to be insanely picky on what they want that to be.

Microsoft and Apple has advantage here they have a single Cathedral each and they can decide to make all application developers working on their platforms slightly unhappy to get ABI stability. Yes successfully herding cats by having only one way door to drive them though. Linux world is not this..

[oiaohm]

Here is the corrected text of the analysis:

App developers write applications, but they have to use APIs to make an application functional. App developers are expected to ship executables, which require stable ABIs. The app developers cannot express where their problem is, because the situation is too complex and proper terminology is lacking. The app developers are in a situation known as double-bind (see description on Wikipedia of double bind).

[ I.e however "looney" it might sound, whoever wants to be an efficient regulator of this situation needs to first contact a psychologist that has expertise in double bind situations (and, the psychologist should know something about Linux, to make it easier for him to understand the situation). ]

This is not really the current location.

https://abi-laboratory.pro/index.php?view=timeline&l=glibc

Lets take glibc under Linux has almost 100% perfect backwards compatibility. Symbols are versioned so this can happen. Now application build with glibc does not have forwards compatibility. Forward compatibility this is where you take application build with newer glibc and try to use on older glibc only to find out it throws error due to missing symbol. Yes this is exactly like the Windows driver ABI.

Lets do a C application under windows using visual studio you are going to build up a Microsoft maintained runtime with your application or user will hit symbol does not work and install the runtime themselves. Yes one of the features of the SXS system under windows is to prevent these libraries from overwriting each other. This allows forward compatibility.

The like or not the proper terminology exists and the functional problem is not that complex. But it requires effort to understand the problem.

https://www.baeldung.com/linux/multiple-glibc

NixOS and others uses the technology above to have a form SXS under Linux.

Ok, so here is, in simple words, what has been going on:

There is another, hidden actor or actors. This hidden actor is the result of the sum of the most important people and organizations dealing with Linux. This hidden actor is the one who can actually "pull the strings". He is a regulator. But, an efficient regulator (the concept of an "efficient regulator" is a part of cybernetics, so read about it there) needs to have a complete model of the system he is controlling. However, the current regulator (the hidden actor) doesn't know about the double bind, so he is an inefficient regulator. In order for this hidden actor to become an efficient regulator, the hidden actor must consult a psychologist. Together, the hidden actor, the psychologist, and the app developers can find efficient solutions to the problem of a usefull userspace ABI. The cybernetical analysis that I have provided should be a starting point for the discussion between the affected actors.

Wrong presume. We don't have hidden actor on Linux with userspace ABI and that is the problem.

Here’s the story, titled “Whose Job Is It, Anyway?”

This is a story about four people named Everybody, Somebody, Anybody and Nobody. There was an important job to be done and Everybody was sure that Somebody would do it. Anybody could have done it, but Nobody did it. Somebody got angry about that, because it was Everybody’s job. Everybody thought Anybody could do it, but Nobody realized that Everybody wouldn’t do it. It ended up that Everybody blamed Somebody when Nobody did what Anybody could have.

The story may be confusing but the message is clear: no one took responsibility so nothing got accomplished.

https://www.lollydaskal.com/leadership/story-everybody-somebody-anybody-nobody/

We have a story of everybody, somebody, anybody and nobody here when it comes to stable userspace ABI for application developers that the way they want.

Distribution job its to make their collection of applications work with latest versions of libraries for the best performance and security. So its not their job to do the effort to make a stable ABI for third party applications. Of course application developers want to blame Distribution for this at the same time failing to see that Distributions cannot fix their problem when they want to run on older so need forward compatibility. Forwards compatibility=requirement for application developer to ship with runtime or user to be able to install runtime..

Library makes in the linux world majority do make backwards compatible libraries and that is a confirmed fact by abi-laboratory. But applications developers want to release new application using new library features and expect it to work on old distributions with only old version of libraries and it breaks of course because they did not include runtime. Yes application developers under windows are use to paying Microsoft Windows and visual studio to make these runtime for them. Microsoft is the hidden actor here making it work.

Where is the Linux hidden actor to make it work. That right Nobody. Are the application developers or end users willing to put up money to pay party to do this role this is mostly not.

xfcemint way simpler problem right you never asked who is responsible to notice the current party is nobody. You also started off with the presume that Stable ABI does not exist on Linux. Issue user-space Stable ABI absolutely exists on Linux distributions themselves would not be able to function if it did not.

Valve runtime for running old Linux native binaries catches a lot out it always end up using versions of glibc way newer than the application binary and this only works because there is a stable ABI. Yes libcapsule is also used to shim the old library usages to new libraries. Also steam runtime for developers is restricted set of libraries that all the libraries have a track record of long term ABI stability for backwards compatibility and the steam application installs newer runtime on older distributions so newer games can work. Valve here took up the nobody was doing it role.

xfcemint the fact valve with steam gets it to work shows clearly its been a nobody or application developer problem. Of course valve wants to recover there costs so some of how it works is bound to steam.

Yes some of the problem lets pick the most popular distribution users are using and build with that logic that application developer take at times and get very badly burnt. Lets say they had built for NixOS instead. NixOS can be installed as a full baremental distribution or on top of almost all other Linux distributions. NixOS is built to have SXS functionality build in. Of course then you have Linux users upset that having the extra libraries and so on are going to cause higher memory and disc usage yes Windows users are use to this.

Then you have flatpak and snap that are even more solutions to the same problem. So we have the many cathedrals problem. Application developers with Linux are in a city of Cathedrals but only a handful in fact suite their faith and they are upset because they are going into Cathedrals that don't use their doctrine. Yes you could say Valve, NixOS, flatpak, snap.... are Cathedrals that give there members guided tours with instructions how to interact with other faiths in other Cathedrals without doing anything too offensive and this is what applications developers need to be looking for.

[oiaohm]

I sound like a whacko to myself. This is completely whacko.

On the other hand, it is not a problem to give it a shot. I mean, it is simple. Then we can evaluate does it work or not. It would be an attempt to put a theory into practice.

The analysis, actually, suggests exactly that same thing in the very beginning (good further discussion). The only difference is that this time the "experts in solving similar problems" are more precisely identified as psychologists who must take double-bind into account when discussion is in progress.

No the issue is pure double bind.

Also, one more point: apparently, the vendors (i.e. the representatives of vendors) should not participate in the good further discussion, if the best results are to be obtained. The discussion should be between the hidden actor (or representatives), psychologists and app developers' representatives.

The reality is there are not hidden actors that much in the Linux world.

What you wrote here is a Herding cats problem.

The reality here is Linux Distributions have different ideas on what is correct they are not going to sit down with each other can come to a 100 percent uniform agreement. Linux Distributions have true case of Irreconcilable Differences.

The problem here is like how different christian religions interpret the bible differently and totally refuse to agree. This aligns up with Linux Distribution behavior.

Then you have different application developer groups that have Irreconcilable differences between them so will not sit down with each other to come up with a common agreement..

https://discuss.python.org/t/lets-get-rid-of-the-stable-abi-but-keep-the-limited-api/18458

Then you have this that stable ABI causes it own fair share of issues. So a developer of a application or library to fix security issues, performance issues and so on is motivated by one of these reasons to break stable ABI. Of course Sod law applies "if something can go wrong, it will" so Stable ABI breakage is always going to be natural happening.

xfcemint the biggest problem here is that people need to accept the reality. Linux world is never going to have a 100 percent uniform stable ABI that application developers ask for this is never going to happen while people can create their own new distributions customized for what they need. Windows and Mac OS and android can kind of offer this because each of these are single cathedrals. Yes each Linux distribution is own cathedral and worse nightmare is every release of a distribution can be its own cathedral.

The reality you make a deb package for debian/ubuntu.... you are basically agreeing to update that when the distribution does update and that you will not have backwards compatibility all the time. Same applies to RPM... There are a long list of distributions in this camp. This is their nature.

Freedesktop runtimes(what flatpak uses), Steam runtime(valve), NixOS are all different forms of Cathedrals that focus on long term running of applications. There are security and memory usage downsides to this.

Stable ABI is not a free it has costs. Yes application developers and end users have to agree to pay the cost here.
Application developers need to stop expecting parties like Debian/Ubuntu.. to behave like windows or macOS with stable ABI. Notice Ubuntu snap you end up bound to their store.

For end users I would say there is a lack of a good front end with tooling to make resolving ABI issues simpler. Yes people forget that its really possible to override any dynamic linked Linux applications loader this can be combined with .desktop files. So Linux distributions could have a compatibility mode like Windows does even provide by a third party of someone was willing to put in the effort the technology exists to-do it. Another interesting point the 80000 packages in nixOS don't need to be installed in /usr NixOS works by altering the dynamic loader. Dynamic loader fixing ABI issues and allowing alternative libraries is a tested and functional solution under Linux but this does not come default with distributions like debian/ubuntu/Redhat/Suse.... instead you need to add like NixOS or Guix to have it.

The horrible reality right the solutions exist 99% of the LInux user-space ABI mess to have applications work across multi distributions and multi generations of Linux distributions. This now comes the classic statement "you can lead a horse to water but you cannot make them drink" you run into this a lot with distributions and application developers.

xfcemint driver issue is another problem of it own.

Userspace ABI issue for applications is purely failure to accept what Linux world is and work in the problem space with what is in fact provided. Yes the Linux world does punish those who look for a quick fix solution without first accepting and understanding the Linux world very harshly due to being able make something like a deb package for debian without understandably this is agreeing to be on a treadmill of updates then run into nightmares of repeated breaking. Yes for this debian case if you had read the Debian packaging policies they warn you of this problem.

I would say this is a very steep learning curve because the Linux world is truly different to Windows and Mac OS world and developers come in attempting to interact with it like it Android Windows and Mac OS.

Yes Android, Windows and Mac OS you can presume that you will naturally get forwards and backwards compatibility as application developer all of the time. But this has never been true for all operating systems. Most BSD based solutions you don't even have the stable ABI from kernel space.

The top one is "Assume= make ASS out of U and ME". Biggest problem for those starting attempting to make application for Linux is they assume Linux will behave like Windows or MacOS or Android so they don't need to learn anything about the nature of what they are using. There is a very large diversity and natures between Linux distributions.

[oiaohm]

I find it likely that the hidden actor is Linus Torvalds,

Linus Torvalds is not that hidden. Linux Torvalds power does not extend into user-space ABI other than the syscalls the Linux kernel provides.

There are different userspace parties who will not sit down with Linus Torvalds even if he asked. He tried and stated it was a herding cats problem and pointed out that there are a lot of Irreconcilable differences between gtk/qt and so on in libraries then irreconcilable differences between distributions ideas of what is right and wrong.

[oiaohm]

I find it amazing that both of the forum's biggest whackos agree on this one.

Note I wrote "pure double bind". Pure being keyword. A pure double bind is a double bind locked in place by "Irreconcilable differences".

a psychological predicament in which a person receives from a single source conflicting messages that allow no appropriate response to be made.

That is a double bind. A pure double bind there is no way to by discussion to solve the conflicting messages and the conflicting messages are in fact all true the problem is the double bind is coming from real "irreconcilable differences".

Solution to "pure double bind" is not more debate but acceptance. ""experts in solving similar problems" go talk to expert and ask them about the "pure double bind" case.

The normal double bind case you can find some flawed statement so breaking the double bind.

Pure double bind cannot be resolved by Therapy or anything else. They are catch-22 that are like the force of gravity that you just have to accept.

Pure double bind are items Therapist and Psychologist cannot alter or resolve or change no matter how much they attempt to assist.

Pure double binds normally are points that you have to agree to disagree and accept that one party is going to go one route and another party is going to go another and never cooperate on this point.

Some ways xfcemint it would be useful to have a list of all the "pure double binds". The points we cannot expect agreement so just have to work around.

When it comes to Psychology double bind comes in two forms. Psychological constructs double binds these are cases that people believe they are in a double bind but after closer inspection their is falsehoods in the ideas behind the double bind so these can be undone. The other is Pure/Real double bind these cannot be undone and are true no win only thing Therapist can do with pure/real double bind is get the party to acceptance. If there is pure/real double bind between two or more individual parties this is Irreconcilable Differences.

Yes solution to Irreconcilable difference is accepting that agreement is not possible and possible going own way.

xfcemint I most likely should have explained the importance of pure. You wrote that getting expert in these field involved could help problem here Linus Torvalds using the Linux foundation already tried that.

The problem here is Stable ABI is a catch-22/pure double bind yes this is why it is a source of Irreconcilable differences between the different parties.

These catch-22 points attempting to get mass agreement mostly end up wasting time.

[oiaohm]

I find it likely that you are not sufficiently qualified to put forward such a statement. To get a correct answer, an expert in double bind situations (i.e. a psychiatrist) should be consulted.

I find it likely that you are not sufficiently qualified to put forward such a statement. To get a correct answer, an expert in double bind situations (i.e. a psychiatrist) should be consulted.

I used the word Therapist and Psychologist for reasons. Psychologist study human behavior. Therapist treat human behavior. There is a big difference between the two.

I would also make a recommendation for application developers, that they should also consult a psychiatrist in order to help them in solving the double bind from their side.

This would be Therapist.

Psychologist would be used to study the group behavior. Yes may over look Therapist collected information to confirm if the case is truly pure double blind.

Linus Torvalds with Linux foundation assistance got psychologist involved to study the behavior to work out what was going on. There is a Linux foundation published white paper on this stuff.

Here is another reccommendation:

When the problem of a useful userspace ABI is being discussed, the psychiatrist from both sides should be present, i.e. a regulator's psychiatrist and application developers' psychiatrist should be present. This is to avoid a possible issue of psychiatrists being biased towards one side (the side that approached and hired the psychiatrist).

This is just were you keep on getting terms wrong. These would be Therapists not psychiatrist. Therapists are trained in managing meetings of people to avoid stuff going really wrong. Pure psychiatrists are not. There are reasons why psychiatrist to perform their experiments need ethic boards.

Psychology you learn about motivations. A Pure double bind. Therapist is going to look at the problem Stable ABI and say this is case of "Irreconcilable differences" and not put both sides together instead have both sides enter acceptance to the case.

Yes acceptance that they cannot expect the other party they are in a pure double bind to work with them in particular areas because other parties interests and need don't align and never will. The python developer case keeping the stable ABI end up preventing upgrading the cpython core so hinding performance improvement this is a real world issue. There are many cases with stable ABI where this comes up.

Valve starting the steam runtime came out of acceptance. Flatpak freedesktop runtime comes out of acceptance. NixOS way of doing things come out of acceptance.

Stable ABI for userspace applications on Linux is likely always to be competing solutions. Application developers need to pick what one they think will service their userbase the best and suite the way they want to do development.

Yes there was a study into why Linux Standard Base failed as well. The old Linux Standard Base was like you ignored the existence of the pure double binds and though that getting people to talk enough and comprise enough solution could be found. Yes the Psychology report into why that fail mentions pure double binds.

Linux foundation is quite well funded. When ever Linux foundation believe there was a chance for Therapist to solve these problem they have provided them.

xfcemint; everything you think is a new idea was started being tried 2 decades ago and was attempted for 15 years.

https://en.wikipedia.org/wiki/Linux_Standard_Base

[oiaohm]

I'm not an expert in this subject, but in my opinion the word "therapist" is too ambiguous. "Therapist" can also mean a phisiotherapist (Wikipedia: physical therapy).

The most precise and appropriate term to descibe the specialist (that I'm thinking of) is "psychiatrist". The source of the problem is in the minds of affected actors, in their thought processes. A psychiatrist is a qualification required to solve those kind of problems (in this situation, the source of the problem is a repetitious pattern of irrational thinking).

psychotherapist is the global term.

It goes like this: Some application developers consult a psychiatrist. The psychatrist then explains the situation and provides some remarks on appropriate language and actions in similar situations. In this specific case, if the regulator refuses to consult a psychiartist and organize discussions, then the application developers can attack the regulator in public by ridiculing him.

Having a psychiatrist sit down and go though the group mental problems and lay the finding of his research what they are in front of the application developers would be helpful. The problem you just wrote attack the regulator. If the regulator happens to be in a catch-22 and has to pick a side between like stable ABI and performance or stable ABI and security and the regulator has a userbase they have to support happens to value security or performance more they are not in the wrong for their user base and should not be attacked.

Application developers are really good at asking for a stable ABI and complaining when stuff does not without accepting that the party not keeping it stable majority of cases are in catch-22. Valve developers maintaining the stable ABI for the steam runtimes learnt this. Do note I said runtimes valve attempted to make a single runtime then found out this caused horrible performance problems as the catch-22 of keeping ABI stable hit. Even Windows if you look closely is multi stable ABI in user space. This is fully not 1 size fits all.

I don't claim to be all-knowing. You might be mostly right, but I think that you are not completely right, and that at least some small part of the stuff that I have been rambling about is actually novel and useful.

Remember the LSB mailing list was at this for 15 years. Sorry you have not come up with anything novel that was not already covered in that mailing list. The hard reality is what was worked out in the LSB mailing list never really got out there.

xfcemint you do demo exactly the problem we are up against with application developers vs distributions. Lack of acceptance that double bind/Irreconcilable Differences exist. At times the distribution stated objectives are counter to-doing stable ABI and for their end users those objectives can be important.

Same problem exists between monolithic kernel design and microkernel designs there are Irreconcilable Differences in places if you stick to pure microkernel or pure monolithic design. The best all rounder is likely to be something developed middle ground taking advantage of monolithic design and microkernel design where it suites and possible managed OS design and maybe a few others.

Managed OS design also promises things that microkernel and monolithic designs don't that is single driver file working cross CPU types without needing the user to have a development suite set up.

Not being willing to accept Irreconcilable Differences is why people do many things wrong.

Xfcemint think you have still been stuck that we have to be able sit down and talk this out. Think of a person in a failed marriage they can throw away decades of their life not really living their life because they have not accepted that they have Irreconcilable Differences. Yes if they had gone their own ways they would be happier and in fact made progress instead of being stuck at stand still.

How to get the application developers wanting to release on Linux to be aware that particular Linux distributions are Irreconcilably Difference to their objectives and the end users of these distributions at times need these differences and other Linux distributions like nixOS or other solutions like flatpak are not as Irreconcilably Difference and this might result in them having to ask their users to jump though a few extra hoops to use their application.

Xfcemint this is the case the stable user space ABI problem with Linux solutions are sitting there. So its not unsolved problem. The problem is acceptance of the solutions and what that mandates how things have to be done. Yes this acceptance includes accepting that different groups will never maintain stable user space ABI because it does not suite their use case and users.

[hotaru]

I'm not an expert in this subject, but in my opinion the word "therapist" is too ambiguous. "Therapist" can also mean a phisiotherapist (Wikipedia: physical therapy).

The most precise and appropriate term to descibe the specialist (that I'm thinking of) is "psychiatrist". The source of the problem is in the minds of affected actors, in their thought processes. A psychiatrist is a qualification required to solve those kind of problems (in this situation, the source of the problem is a repetitious pattern of irrational thinking).

no, a psychiatrist is a doctor who specializes in prescribing medication as an alternative to actually solving mental health problems. "therapist" is the correct word to use here.

[oiaohm]

I find it likely that the regulator has plenty of actions on his disposal, he is just too stubborn to consider them seriously. One source of the problem is irrational thinking in his head. The regulator needs to consult a psychotherapist and attempt to explain to him why is he keeping application developers in a double bind, while simultaneously not wanting to keep the application developers in a double bind.

No false logic. https://www.kernel.org/doc/Documenta...i-nonsense.rst This is the most known example. Here the developer in charge who is the regulator take the problem of stable kernel driver ABI very serous-ally. Problem here it is a true catch-22/ pure double bind.

The fundamental problems problems that happen with stable ABI keep on turning up. Psychotherapist cannot change a fundamental problem.

Yes having all the core Linux kernel developers sitting down with psychotherapist is not going to be able to change anything.

Yes the stable ABI nonsense is that people want a stable in kernel driver ABI without understand the major downsides. Of course third party driver developers want to keep their driver code out of the kernel tree. This has lead to decades of repeated issues with Nvidia binary drivers and other third parties because they would not accept this are fundamental limitations.

You can find other examples with python changes and so on. Where the comes a point where only way to fix issues is break Stable ABI.

Basic thing you keep on missing is that a regulator may have plenty of actions at his disposal but the problem is mutual exclusivity. You choose stable ABI this equals you now have limitations on what internal structures you can change. You cannot have freedom to change internal structures and Stable ABI that depends on those internal structures as they are.

Yes the base to most pure double bind/Irreconcilable Differences are choices that have mutual exclusivity. Lot of what you have been writing is like saying "you can have your cake and eat it as well" this is a physical impossibility because by the rules of nature is mutual exclusive. Software design and development does have fixed set of rules that does force mutual exclusive choices.

Can you show me where the term "double bind" is mentioned in that mailing list? After that, you have to prove that all 10 points from my analysis have already been seriously considered.

Irreconcilable Differences is what is commonly mentioned not the term pure double bind. Also take a close look at your 10 points does any of them work at all once you have true Irreconcilable Differences. No where in your 10 points is acceptance of that.

Yes the first part you stated your fundamental problem no point digging out the references across the LSB mailing list. Thinking the other side is just being stubborn means you don't consider their point of view.

Sometimes when you do consider the other point of view bugger they have had to make a call between X and Y. I would have liked Y but X and Y are mutual exclusive so they can only choose one. This is exactly what happen in the stable ABI nonsense. Now comes acceptance and working out how to live with that choice.

xfcemint you need to lose the idea that regulators have absolutely choice freedom the real world do does not work that way. Any solution to these problems has to have something in the solution to deal with the mutual exclusivity/Irreconcilable Differences/pure double bind. This also means any solution will have to be imperfect. Even windows so call stable ABI is imperfect that why Microsoft has shims to attempt to mask over the imperfections.