Oracle Switching Solaris To A Continuous Delivery Model

[aht0]

"redirfs" for example. It was file system filtering driver. AFAIK it's development ceased around 2014 and it's sudden lack in kernels caused problems for Linux's antivirus software. Suddenly your AV stopped working after you upgraded and it was that. Take an program using that module and it won't work. Such examples are probably plentiful. Since Linux kernel has stuff added to it and removed from it all the time.

[ldo17]

"redirfs" for example. It was file system filtering driver.

What exactly does a file system driver have to do with userland APIs? Especially one that it seems was created to bypass them.

[aht0]

What exactly does a file system driver have to do with userland APIs? Especially one that it seems was created to bypass them.

You thought up "userland APIs" on particular, not me.

Many of the AV's were commercial software, which all-of-a-sudden became incompatible. It's exactly along the lines of what I claimed initially. Shit worked, until it stopped working.

System Z is still capable of running programs written for System/360 and the latter came out back in 1964. If support for some particual program versions has it's support cut off, you'd get nearly decade of advance warning and you may end up with a ~20 years of time in your hands to change (CICS, OS/VS COBOL particular versions etc).

[TheBlackCat]

"redirfs" for example. It was file system filtering driver. AFAIK it's development ceased around 2014 and it's sudden lack in kernels caused problems for Linux's antivirus software. Suddenly your AV stopped working after you upgraded and it was that. Take an program using that module and it won't work. Such examples are probably plentiful. Since Linux kernel has stuff added to it and removed from it all the time.

Is this a third-party driver, not part of the mainline kernel? That is what it looks like from what I can tell. Nothing was "removed from the kernel", it was never in the kernel to begin with.

[ldo17]

You thought up "userland APIs" on particular, not me.

Because that is what I was asking about. That is what Linus is notoriously strict about preserving.

[aht0]

And userland API stability is relevant how in the context of an example I brought? Or even if the redirfs module was official or 3rd party?

Important function of a program was using a driver which in turn was dependent upon an internal API. Internal API was changed (which happens daily in Linux) -> driver broke -> program stopped working.

So, you are screwed from the moment you are trying to use some older binary which in turn is trying to use some driver, which has since then internally changed/driver has not been periodically updated. Which in fact is pretty fucking standard issue in Linux daily.

QUOTE=TheBlackCat;n939659]

Is this a third-party driver, not part of the mainline kernel? That is what it looks like from what I can tell. Nothing was "removed from the kernel", it was never in the kernel to begin with.[/QUOTE]

Sarcasm mode ON.
If nothing was removed (or changed) then I would have to assume that driver simply did not like the version numbers of newer releases.

Can't see what the fuck you are trying to prove arguing me.

[ldo17]

And userland API stability is relevant how in the context of an example I brought?

Wrong way round: it is your example that is irrelevant to the point I made, about userland API compatibility. That is the thing Linus is famous for guaranteeing.

[aht0]

point of start for this particular argument.

Linux does AFAIK not guarantee backward compatibility to business software written 20-30 years a go. It has in fact trouble being backward compatible to itself.

Your response to it:

It certainly guarantees backward compatibility with old code written for Linux. Linus has famously chewed out people who wanted to break userland compatibility, on more than one occasion.

Your response claims 100% backward compatibility. At least I parse out the sentence thus.

I proved, you do not need more than change to an Internal API to break userland program. Because that program may use some driver that in turn depends on Internal API. Got it? Butterfly effect. As a conclusion - there is no "guaranteed backwards compatibility" if you have to apply "if's" and "but's" to it. Logically. Get it?

Whatever else you are trying to "prove" 'between your initial quote and now' is just a side show and I am trying to more or less ignore it. I am keeping initial start of argument in mental focus. Or the whole thing would branch out into endless back and forth. Maybe it's exactly what you want.

How other OSes solve the particular issue. Compatibility layers (yeah, even to itself).
FreeBSD 11-Release-p8, portion of default kernel config. FreeBSD 3.2 was released 18 years a go.

file: /usr/src/sys/amd64/conf
...
options         MSDOSFS                 # MSDOS Filesystem
options         CD9660                  # ISO 9660 Filesystem
options         PROCFS                  # Process filesystem (requires PSEUDOFS)
options         PSEUDOFS                # Pseudo-filesystem framework
options         GEOM_PART_GPT           # GUID Partition Tables.
options         GEOM_RAID               # Soft RAID functionality.
options         GEOM_LABEL              # Provides labelization
[B]options         COMPAT_FREEBSD32        # Compatible with i386 binaries
options         COMPAT_FREEBSD4         # Compatible with FreeBSD4
options         COMPAT_FREEBSD5         # Compatible with FreeBSD5
options         COMPAT_FREEBSD6         # Compatible with FreeBSD6
options         COMPAT_FREEBSD7         # Compatible with FreeBSD7
options         COMPAT_FREEBSD9         # Compatible with FreeBSD9
options         COMPAT_FREEBSD10        # Compatible with FreeBSD10[/B]
options         SCSI_DELAY=5000         # Delay (in ms) before probing SCSI
options         KTRACE                  # ktrace(1) support
options         STACK                   # stack(9) support
options         SYSVSHM                 # SYSV-style shared memory
options         SYSVMSG                 # SYSV-style message queues
options         SYSVSEM                 # SYSV-style semaphores
options         _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions
options         PRINTF_BUFR_SIZE=128    # Prevent printf output being interspersed.
options         KBD_INSTALL_CDEV        # install a CDEV entry in /dev
..

On Windows, it's more or less the same. You can run pretty old binaries just fine. In fact, when using 32bit Windows, you can theoretically run even ancient 16-bit applications (Win3.x)

[ldo17]

Your response claims 100% backward compatibility. At least I parse out the sentence thus.

I did make it clear I was talking about userland APIs, did I not? You even quoted that bit before trying to bring up your example, so I assumed you understood it.

Do I have to teach you how to make a coherent argument?

[aht0]

I did make it clear I was talking about userland APIs, did I not? You even quoted that bit before trying to bring up your example, so I assumed you understood it.

Do I have to teach you how to make a coherent argument?

"Know-it-all", shortly, I do not consider your "userland API stability" relevant aspect at all. Not for backward compatibility. You seem to have difficulty grasping the concept. Thus I've been and I am still going to completely ignore it.

It's not even meant for providing backward compatibility but to offer reasonable expectation of "present compatibility". Think for a second what would happen with userland stuff when userland APIs changed as often and much as kernel's internal API's. It'd be utter blighted mess and fast-track method for majority of userland dev's to give up in disgust, go and seek another platform to develop on and for - where they would not be having to constantly "correct" and adjust their code.

Further, we haven't even talked yet about another ballpark of issues that crop up when you are trying to run older binaries on Linux. Libraries. Try using a old binary compiled on different version of Glibc (for example but libraries are not limited to just glibc) and you are instantly going to be running into issues. Further back you go in time (older the binary - just to be sure you understand) - bigger the differences become.

You'd have to patch the binary by hand first OR you are going to run into bunch of relocation errors and "undefined symbol" errors and get nowhere at all. You won't be successfully running it "as is". Which also proves, there is no "backward compatibility".

I do not have to hexedit "fix" old Windows XP binaries for running those on Win10. Get the conceptual difference?