5 ms·

> It looks like golang is going to have to deal with — again — OpenBSD treating libc as the interface with the kernel instead of syscalls being the interface wi

> It looks like golang is going to have to deal with — again — OpenBSD treating libc as the interface with the kernel instead of syscalls being the interface with the kernel. Something they wouldn't have to do if they'd heeded the warnings they got since they first started going raw syscalls on non linux systems. But as usual, go is uniquely american, only doing the right thing after it has tried everything else.

PrimeMcFly 3y ago
> go is uniquely american, doing the right thing after it has tried everything else. That doesn't seem like anything common to an American way of doing things. What an odd statement.
- kstrauser 3y ago
  It's a play on a quote often attributed to Winston Churchill: https://quoteinvestigator.com/2012/11/11/exhaust-alternatives/ https://quoteinvestigator.com/2012/11/11/exhaust-alternative...
  - arp242 3y ago
    Bizarre nationalistic "they're doing it because they're Americans" rantings are still not okay even if they're a "play on a quote". I can "play" with all sorts of quotes to say all sorts of idiotic things.
    - kstrauser 3y ago
      I guess. I'm proudly American and I thought it was funny, but everyone has different tolerances.
tadfisher 3y ago
You could also describe it as doing the sane thing (avoiding hardcoding against the libc ABI through FFI) until the only sane option is removed. Did you know many libc APIs are preprocessor macros?
- masklinn 3y ago
  > You could also describe it as doing the sane thing (avoiding hardcoding against the libc ABI through FFI) No, you could not. On pretty much every system but linux the libc (or equivalent) is the officially supported API to the kernel. Bypassing it is not supported and thus definitionally can not be sane, that's like declaring that doing the sane thing is avoiding hardcoding against the front door and entering your home through the roof instead. The front door is what you're supposed to use, do hardcode against it. Same with libc. And Go has been going "ouch" then putting its fingers straight back in the socket from the start, as it keeps trying to work around libcs on all the platform where it is not supported.
  - dfox 3y ago
    On linux the stable API and ABI that you are supposed to use is also just libc. But due to various reasons people think that the libc ABI is less stable than how stable it really is. Edit: NT with its split OS API dll and separate libc is its own can of worms. You can have multiple instances of libc in the same address space, which among other things implies that you cannot safely malloc() in one module and free() in another, and don't even think about passing FILE* around.
    - GrumpySloth 3y ago
      Linux doesn’t have an official libc. Raw syscalls are its only official API.
  - tadfisher 3y ago
    My point is that libc as the only system API is not a sane choice, and appeals to tradition don't make it less insane.
    - masklinn 3y ago
      > My point is that libc as the only system API is not a sane choice That might be your new point after having yeeted the goalposts out, but it's definitely not your original statement. > and appeals to tradition don't make it less insane. This is not an appeal to tradition, it's how things work. If the authors and maintainers of the system tell you something is the supported API, wilfully bypassing that supported API is not "the sane thing", especially when you complain that your bypass blows your face off down the line, then you're an asshole too.
FullyFunctional 3y ago
I don't use Go, but I had the exact same reaction; C is the source of most of the problems and this is just codifies the use of C. The whole thing has a security by obscurity smell.
- MrRolleyes 3y ago
  Your comment seems to conflate a language with an ABI. To what end? What is inherently insecure about the C ABI? Why is using a syscall interface any more secure?
  - FullyFunctional 3y ago
    I'm not conflating anything. Why do you need to burden a language with a C ABI when you can just invoke the language independent mechanism directly?
    - MrRolleyes 3y ago
      [dead]
    - samus 3y ago
      The C ABI is influenced by C's type model, but so is OpenBSD itself. There is no truly language independent mechanism. If a programming language implementation can't interface with a C ABI, how can it interface with the language independent mechanism?
akira2501 3y ago
> go is uniquely american, only doing the right thing after it has tried everything else. Perhaps this is why most innovations are American. We don't automatically fall for the bully pulpit of the gnostic class. > Something they wouldn't have to do Yea, but they'll get it done anyways, and the language will continue to be excellent. I'm sure Google can absorb the engineering challenge without subtracting anything from us or other languages.

PrimeMcFly 3y ago

> go is uniquely american, doing the right thing after it has tried everything else. That doesn't seem like anything common to an American way of doing things. What an odd statement.

kstrauser 3y ago
It's a play on a quote often attributed to Winston Churchill: https://quoteinvestigator.com/2012/11/11/exhaust-alternatives/ https://quoteinvestigator.com/2012/11/11/exhaust-alternative...
- arp242 3y ago
  Bizarre nationalistic "they're doing it because they're Americans" rantings are still not okay even if they're a "play on a quote". I can "play" with all sorts of quotes to say all sorts of idiotic things.
  - kstrauser 3y ago
    I guess. I'm proudly American and I thought it was funny, but everyone has different tolerances.

tadfisher 3y ago

You could also describe it as doing the sane thing (avoiding hardcoding against the libc ABI through FFI) until the only sane option is removed. Did you know many libc APIs are preprocessor macros?

masklinn 3y ago
> You could also describe it as doing the sane thing (avoiding hardcoding against the libc ABI through FFI) No, you could not. On pretty much every system but linux the libc (or equivalent) is the officially supported API to the kernel. Bypassing it is not supported and thus definitionally can not be sane, that's like declaring that doing the sane thing is avoiding hardcoding against the front door and entering your home through the roof instead. The front door is what you're supposed to use, do hardcode against it. Same with libc. And Go has been going "ouch" then putting its fingers straight back in the socket from the start, as it keeps trying to work around libcs on all the platform where it is not supported.
- dfox 3y ago
  On linux the stable API and ABI that you are supposed to use is also just libc. But due to various reasons people think that the libc ABI is less stable than how stable it really is. Edit: NT with its split OS API dll and separate libc is its own can of worms. You can have multiple instances of libc in the same address space, which among other things implies that you cannot safely malloc() in one module and free() in another, and don't even think about passing FILE* around.
  - GrumpySloth 3y ago
    Linux doesn’t have an official libc. Raw syscalls are its only official API.
- tadfisher 3y ago
  My point is that libc as the only system API is not a sane choice, and appeals to tradition don't make it less insane.
  - masklinn 3y ago
    > My point is that libc as the only system API is not a sane choice That might be your new point after having yeeted the goalposts out, but it's definitely not your original statement. > and appeals to tradition don't make it less insane. This is not an appeal to tradition, it's how things work. If the authors and maintainers of the system tell you something is the supported API, wilfully bypassing that supported API is not "the sane thing", especially when you complain that your bypass blows your face off down the line, then you're an asshole too.

FullyFunctional 3y ago

I don't use Go, but I had the exact same reaction; C is the source of most of the problems and this is just codifies the use of C. The whole thing has a security by obscurity smell.

MrRolleyes 3y ago
Your comment seems to conflate a language with an ABI. To what end? What is inherently insecure about the C ABI? Why is using a syscall interface any more secure?
- FullyFunctional 3y ago
  I'm not conflating anything. Why do you need to burden a language with a C ABI when you can just invoke the language independent mechanism directly?
  - MrRolleyes 3y ago
    [dead]
  - samus 3y ago
    The C ABI is influenced by C's type model, but so is OpenBSD itself. There is no truly language independent mechanism. If a programming language implementation can't interface with a C ABI, how can it interface with the language independent mechanism?

akira2501 3y ago

> go is uniquely american, only doing the right thing after it has tried everything else. Perhaps this is why most innovations are American. We don't automatically fall for the bully pulpit of the gnostic class. > Something they wouldn't have to do Yea, but they'll get it done anyways, and the language will continue to be excellent. I'm sure Google can absorb the engineering challenge without subtracting anything from us or other languages.