New around here? Register your SA Forums Account here!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Cybernetic Vermin
Apr 18, 2005

eschaton posted:

that doesn’t prevent him from being wrong of course; software that flouts API rules shouldn’t be expected to run forever

of course if Linux had a concept of API/ABI epochs, binaries built against an earlier SDK could be kept running while the same code built against a newer SDK could break appropriately (so its developers fix it)

nah, that is a terrible idea and it is good that linux has a solid principle in place for at least this interface

Adbot
ADBOT LOVES YOU

sb hermit
Dec 13, 2016





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.

Suspicious Dish
Sep 24, 2011

2020 is the year of linux on the desktop, bro
Fun Shoe
eschaton has finally came up with the solution to manage the complexity of backwards compatibility: add more code.

Suspicious Dish
Sep 24, 2011

2020 is the year of linux on the desktop, bro
Fun Shoe
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.

eschaton
Mar 7, 2007

the knowledge knower. a wisdom imparter. irritatingly self-assertive. odorous.
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

Tankakern
Jul 25, 2007

what does this have to do with linux the kernel

you don't link to linux, you link to glibc

Schadenboner
Aug 15, 2011

by Shine

Tankakern posted:

what does this have to do with linux the kernel

you don't link to linux, you link to glibc

Wish u would link back to GBS, hth?

eschaton
Mar 7, 2007

the knowledge knower. a wisdom imparter. irritatingly self-assertive. odorous.
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

pseudorandom name
May 6, 2007

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

Malcolm XML
Aug 8, 2009

I always knew it would end like this.

Tankakern posted:

what does this have to do with linux the kernel

you don't link to linux, you link to glibc

static link yourself back to gbs

Nomnom Cookie
Aug 30, 2009



eschaton posted:

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

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

Tankakern
Jul 25, 2007

why gbs though

Notorious b.s.d.
Jan 25, 2003

by Reene

eschaton posted:

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

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

Notorious b.s.d.
Jan 25, 2003

by Reene

eschaton posted:

that doesn’t prevent him from being wrong of course; software that flouts API rules shouldn’t be expected to run forever

of course if Linux had a concept of API/ABI epochs, binaries built against an earlier SDK could be kept running while the same code built against a newer SDK could break appropriately (so its developers fix it)

Linux backwards compat works better than you would expect via glibc shims. it’s not good, but it works more often than not

Sapozhnik
Jan 2, 2005

Nap Ghost

Notorious b.s.d. posted:

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

As we all know developers are well known for following specs and documentation

Cocoa Crispies
Jul 20, 2001

Vehicular Manslaughter!

Pillbug
just never release your kernel poo poo to the public for general purpose use

feedmegin
Jul 30, 2008

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.

ewe2
Jul 1, 2009

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.

Notorious b.s.d.
Jan 25, 2003

by Reene

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

Sapozhnik
Jan 2, 2005

Nap Ghost
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

Tankakern
Jul 25, 2007

:toot:

Soricidus
Oct 20, 2010
freedom-hating statist shill
welp, i guess 2018 wasn't the year of linux on the desktop after all, but i have a good feeling about 2019

akadajet
Sep 14, 2003

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,

r u ready to WALK
Sep 29, 2001

2019 is the year of linux on the cooktop

mike12345
Jul 14, 2008

"Whether the Earth was created in 7 days, or 7 actual eras, I'm not sure we'll ever be able to answer that. It's one of the great mysteries."





2019 will be it. I can feel it.

Notorious b.s.d.
Jan 25, 2003

by Reene

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

Poopernickel
Oct 28, 2005

electricity bad
Fun Shoe
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

fritz
Jul 26, 2003

next year, on the desktop

Toady
Jan 12, 2009

can't wait for all the 2020 retrospectives that reference hindsight

post hole digger
Mar 21, 2011

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 :peanut:

Captain Foo
May 11, 2004

we vibin'
we slidin'
we breathin'
we dyin'

Poopernickel posted:

year YYYY, dec 31:

welp, this year I feel like Linux made some real headway on the desktop market, just got a few audio problems to sort out and then

Soricidus
Oct 20, 2010
freedom-hating statist shill

my bitter bi rival posted:

2018 was the year of linux on my desktop :peanut:

you found an old slackware cd to use as a coaster?

Notorious b.s.d.
Jan 25, 2003

by Reene

fritz posted:

next year, on the desktop

l'chaim

Last Chance
Dec 31, 2004

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

talking about the current year as the year of linux on the desktop has never felt right

i can get behind this since microsoft will at least announce switching over to linux entirely by 2020

Notorious b.s.d.
Jan 25, 2003

by Reene

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 ?

sb hermit
Dec 13, 2016





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.

sb hermit
Dec 13, 2016





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

i can believe they would port more business software, though. sql server came first. what's next? axapta? great plains? sharepoint ?

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...

r u ready to WALK
Sep 29, 2001

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

sb hermit
Dec 13, 2016





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

Adbot
ADBOT LOVES YOU

pseudorandom name
May 6, 2007

so how drunk are all of you right now to think this is even a possibility?

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply