|
eschaton posted:that doesn’t prevent him from being wrong of course; software that flouts API rules shouldn’t be expected to run forever nah, that is a terrible idea and it is good that linux has a solid principle in place for at least this interface
|
![]() |
|
![]()
|
# ? Feb 10, 2025 13:49 |
|
Cybernetic Vermin posted:nah, that is a terrible idea and it is good that linux has a solid principle in place for at least this interface I agree with this. The current interface should be kept intact as long as possible. Makes things easier for both userspace and the kernel. If an api is “wrong”, then it should be handled in userspace (via new glibc versions) as much as possible. Otherwise, it should be an entirely new system call.
|
![]() |
|
eschaton has finally came up with the solution to manage the complexity of backwards compatibility: add more code.
|
![]() |
|
I still think a lot of the widely-celebrated Linus burns are stupid and a result of him not understanding all the tiny bits of minutea of complex software. Three console I/O subsystem maintainers have quit row because the drat thing is such a beast with so much implicit undocumented behavior over 50 years of UNIX history, and when they accidentally broke it, Linus chastised them for trying to fix bugs, and when they asked for help trying to understand the userspace usecase so that they could investigate the bug, Linus swore at them with the same "we don't break userspace, you need to revert right now" rant... despite the patch actually fixing some other bug in some other userspace app. Software is difficult. Yelling at people for trying isn't the right way to go.
|
![]() |
|
well, let’s say you want to change the implementation of an API to enable some new feature when you make your changes, you discover a popular app, let’s call it PictureHut, was relying on some undocumented detail of the previous implementation (such as extending the lifetime of a passed in object to a certain degree) do you put in a workaround for all apps for all time, because apps are never wrong? do you put in a workaround for just PictureHut, but for all versions forever? it turns out that “anything that linked against the previous SDK gets the old behavior, anything linking against the new SDK gets the new behavior” is just about the right compromise: you keep running not just PictureHut but any other deployed app that was relying on the old behavior, but you make sure that newer versions of everything can’t rely on it, preserving your flexibility as a platform vendor
|
![]() |
|
what does this have to do with linux the kernel you don't link to linux, you link to glibc
|
![]() |
|
Tankakern posted:what does this have to do with linux the kernel Wish u would link back to GBS, hth?
|
![]() |
|
the kernel presents an API and ABI too, both to drivers and to userspace “the kernel can never break userspace” is a stupid rule; there are all sorts of subtle behaviors a userspace program could wind up relying upon that aren’t guaranteed by spec, and instead of trying to define this problem out of existence a more rational approach is to figure out a way to balance keeping existing software running against not limiting the future
|
![]() |
|
that sounds like a lot of work OP, it’d be easier to just refuse to run old working apps and gaslight the app developer over who is at fault
|
![]() |
|
Tankakern posted:what does this have to do with linux the kernel static link yourself back to gbs
|
![]() |
|
eschaton posted:the kernel presents an API and ABI too, both to drivers and to userspace yeah ok there's that on the other hand, linus says for what 27 years now NEVER EVER BREAK USERSPACE and still devs are constantly sending patches to him like "hmm what if we break userspace, that would be good actually". i can't or at least don't want to imagine what would happen if that stance weakened even a tiny bit i like the api version idea. or steal from wsl and support windows syscalls lol. although i guess that wouldn't work in practice cause the nt equivalent is partly in userspace
|
![]() |
|
why gbs though
|
![]() |
|
eschaton posted:the kernel presents an API and ABI too, both to drivers and to userspace the problem is that there is no spec and there will never be a spec “never break user space” is the fallback position. if a behavior was not previously documented, and user space apps depend on it, welp that’s now an unbreakable contract
|
![]() |
|
eschaton posted:that doesn’t prevent him from being wrong of course; software that flouts API rules shouldn’t be expected to run forever Linux backwards compat works better than you would expect via glibc shims. it’s not good, but it works more often than not
|
![]() |
|
Notorious b.s.d. posted:the problem is that there is no spec and there will never be a spec As we all know developers are well known for following specs and documentation
|
![]() |
|
just never release your kernel poo poo to the public for general purpose use
|
![]() |
|
Kevin Mitnick P.E. posted:i like the api version idea. or steal from wsl and support windows syscalls lol. although i guess that wouldn't work in practice cause the nt equivalent is partly in userspace Yeah, actual Windows syscall numbers change with each build, so actually it's entirely in userspace in eg kernel32.dll. What you want exists, it's just called Wine.
|
![]() |
|
Notorious b.s.d. posted:Linux backwards compat works better than you would expect via glibc shims. it’s not good, but it works more often than not In addition, there are many cases where the explicit API hides a lot of implicit behaviour regardless of Unix, just take this examination of read() for an example. It's never been up to any Unix to clear this kind of gap up much less expect linux to fix everything about kernel-userspace transitions.
|
![]() |
|
Kevin Mitnick P.E. posted:i like the api version idea. or steal from wsl and support windows syscalls lol. although i guess that wouldn't work in practice cause the nt equivalent is partly in userspace the api is already versioned via glibc — LD_ASSUME_KERNEL is the quick and dirty way to experiment
|
![]() |
|
holey FUCKIN poo poo firefox actually started up talking to Wayland on a hidpi display without violently making GBS threads everywhere only took them literally eight years and counting https://bugzilla.mozilla.org/show_bug.cgi?id=635134
|
![]() |
|
![]()
|
![]() |
|
welp, i guess 2018 wasn't the year of linux on the desktop after all, but i have a good feeling about 2019
|
![]() |
|
Soricidus posted:welp, i guess 2018 wasn't the year of linux on the desktop after all, but i have a good feeling about 2019 actually,
|
![]() |
|
2019 is the year of linux on the cooktop
|
![]() |
|
2019 will be it. I can feel it.
|
![]() |
|
Soricidus posted:welp, i guess 2018 wasn't the year of linux on the desktop after all, but i have a good feeling about 2019 i feel like we should skip directly to 2020 so we can get back into the spirit of feverish speculation talking about the current year as the year of linux on the desktop has never felt right
|
![]() |
|
year YYYY, dec 31: welp, this year I feel like Linux made some real headway on the desktop market, just got a few graphical problems to sort out and then
|
![]() |
|
next year, on the desktop
|
![]() |
|
can't wait for all the 2020 retrospectives that reference hindsight
|
![]() |
|
Soricidus posted:welp, i guess 2018 wasn't the year of linux on the desktop after all, but i have a good feeling about 2019 2018 was the year of linux on my desktop ![]()
|
![]() |
|
Poopernickel posted:year YYYY, dec 31:
|
![]() |
|
my bitter bi rival posted:2018 was the year of linux on my desktop you found an old slackware cd to use as a coaster?
|
![]() |
|
fritz posted:next year, on the desktop l'chaim
|
![]() |
|
Notorious b.s.d. posted:i feel like we should skip directly to 2020 so we can get back into the spirit of feverish speculation i can get behind this since microsoft will at least announce switching over to linux entirely by 2020
|
![]() |
|
Last Chance posted:i can get behind this since microsoft will at least announce switching over to linux entirely by 2020 idk if this is a joke or not but the windows client software stack is way too complicated to ever migrate to anything ever i can believe they would port more business software, though. sql server came first. what's next? axapta? great plains? sharepoint ?
|
![]() |
|
Last Chance posted:i can get behind this since microsoft will at least announce switching over to linux entirely by 2020 Personally, I doubt that will ever happen, particularly by 2020. If it happens, it will be 2025 or later. The sheer freedom of owning and developing your own OS and application environment that is free of steering committees and other external bureaucracy has probably helped Microsoft keep their market share. Having said that, I would not be surprised if they continued to integrate more open source components.
|
![]() |
|
Notorious b.s.d. posted:idk if this is a joke or not but the windows client software stack is way too complicated to ever migrate to anything ever This is much more believable. Develop it on Linux and deploy it using the compatibility shim and now you have (more or less) one codebase. Of course, you have to test it on a crap ton of environments but I guess they should have kickass testing suites for that software by now...
|
![]() |
|
I think if Microsoft threw a couple billion dollars at the WINE project you could end up with a pretty spectacular Linux Subsystem for Windows
|
![]() |
|
r u ready to WALK posted:I think if Microsoft threw a couple billion dollars at the WINE project you could end up with a pretty spectacular Linux Subsystem for Windows Microsoft has absolutely no inclination to make a windows subsystem for linux especially because of the sheer engineering effort required to maintain it, and the ridiculous amount of testing needed to make it enterprise ready it’s best to just let codeweavers try to make money out of that niche without suing the hell out of them and maybe make a slimmed down freeware win95/win98/win2k for software archivists
|
![]() |
|
![]()
|
# ? Feb 10, 2025 13:49 |
|
so how drunk are all of you right now to think this is even a possibility?
|
![]() |