5 ms·

I don't know if I agree, but this is one shining example of what makes *bsd's great, not being afraid of change. Linux should take note. So much of Windows' hea

I don't know if I agree, but this is one shining example of what makes *bsd's great, not being afraid of change. Linux should take note. So much of Windows' headaches stem from not wanting to break things, and needing to support old client code.

justincormack 1y ago
There isn't really much of "Linux" here - this code is in libc, so glibc, but that was built from portability, it isn't very Linux specific. Linux doesn't have an all encpmpassing community for userspace.
- notepad0x90 1y ago
  I see. I thought OpenBSD maintained their own downstream fork of glibc or something since the title/link are for their site/lists. It may not be all encompassing,but I was referring to GNU/Linux. you can swap out bits and pieces, but what mainstream distros include by default, that's what I meant.
  - JdeBP 1y ago
    What you are looking at is not a GNU C library at all. It is a BSD C library.
  - wpollock 1y ago
    I think you are looking for the Linux Standard Base. It started out with a great idea, but the LSB grew so large most popular distros publicly stated they would no longer pursue compliance, so the effort kinda fizzled out.
sedatk 1y ago
> So much of Windows' headaches stem from not wanting to break things Quite acceptable for not having the headache for things breaking.
- notepad0x90 1y ago
  I am not disagreeing, but it is a design fault if you continually end up having to choose between breaking or improving things. When you have major platform updates like windows NT rewrite back in 2000, windows 8 and now windows 11, they're opportunities to shed legacy things. The choice should have been to keep supporting a long-term-stable version of windows for security fixes (like XP or Win7) and get rid of tech designed to support old software. Their problem now is they want everyone to be on win10 and then win11 and then whatever they come up with, or else. You can carry legacy dependencies with you to new major versions or you can support old versions for security fixes long-term.
  - sedatk 1y ago
    I empathize with the sentiment, but I think Microsoft isn't that conservative. Since XP, they have continuously dropped hundreds of features and components with varying significance. https://en.wikipedia.org/wiki/List_of_features_removed_in_Windows_Vista https://en.wikipedia.org/wiki/List_of_features_removed_in_Wi... That said, there isn't a one to one correlation between the gains of dropping a legacy component and the increased capability to innovate either. Windows is highly modular, and maintaining legacy compatibility rarely is a blocker for a line of innovation, nor is a high budget workload. I wonder though, what kind of innovation do you want to see but think that it's held back by legacy components?
cremno 1y ago
"Windows" did this 11 years ago: >FILE Encapsulation: In previous versions, the FILE type was completely defined in <stdio.h>, so it was possible for user code to reach into a FILE and muck with its internals. We have refactored the stdio library to improve encapsulation of the library implementation details. As part of this, FILE as defined in <stdio.h> is now an opaque type and its members are inaccessible from outside of the CRT itself. https://devblogs.microsoft.com/cppblog/c-runtime-crt-features-fixes-and-breaking-changes-in-visual-studio-14-ctp1/ https://devblogs.microsoft.com/cppblog/c-runtime-crt-feature...
rfl890 1y ago
Windows has kept FILE opaque for as long as I can remember. Granted, that's not very long, only 10 or so years.
badsectoracula 1y ago
> Linux should take note Ugh, no, it should not. As a user i prefer my existing programs to keep working whenever i update my OS and as a developer i prefer to work on new code than playing nanny with existing previously working code (working code here means the code did the task it was supposed to do) because some dependency broke itself.
- notepad0x90 1y ago
  it's already not working that way in Linux, it's just that there is no rhyme or reason to it. Even on stable Debian I have to have pipx/pyenv/venv for python and juggle multiple versions of rust and go because of mismatches between software and distro versions.
  - alchemio 1y ago
    Python, rust and Go aren’t beacons of software stability though.
  - badsectoracula 1y ago
    This is a Python, Rust and Go issue, not a Linux issue. With "Linux" i meant the Linux kernel which does not break backwards compatibility. Sadly, the userland does not have the same mindset as very few libraries and languages care about backwards compatibility. However at least on Linux it is possible to do that if you care by choosing languages and libraries that do not break compatibility without worrying that the OS will break things. On OpenBSD you may write your program in C (which has strong backwards compatibility as a language) and use only libraries such as curl, cairo, opengl, openal and x11 that in general do not break backwards compatibility and yet have the OS throw all that effort out of the window.
    - notepad0x90 1y ago
      Even on windows, it isn't usually the NT kernel that's the issue, it's the user space api's. For example, why hasn't ripgrep (and similar tools) replaced grep as a default? they're much better for performance right? (i mean on stable/mainstream distros). i get supporting old stuff, that's why there are LTS releases. But I think it is the fear of not being able to shed enough old things in new releases to displace the maintenance burden of LTS type releases that's the big issue. Features shouldn't be ridden of just because either, there needs to be a good reason, like a better alternative.

justincormack 1y ago

There isn't really much of "Linux" here - this code is in libc, so glibc, but that was built from portability, it isn't very Linux specific. Linux doesn't have an all encpmpassing community for userspace.

notepad0x90 1y ago
I see. I thought OpenBSD maintained their own downstream fork of glibc or something since the title/link are for their site/lists. It may not be all encompassing,but I was referring to GNU/Linux. you can swap out bits and pieces, but what mainstream distros include by default, that's what I meant.
- JdeBP 1y ago
  What you are looking at is not a GNU C library at all. It is a BSD C library.
- wpollock 1y ago
  I think you are looking for the Linux Standard Base. It started out with a great idea, but the LSB grew so large most popular distros publicly stated they would no longer pursue compliance, so the effort kinda fizzled out.

sedatk 1y ago

> So much of Windows' headaches stem from not wanting to break things Quite acceptable for not having the headache for things breaking.

notepad0x90 1y ago
I am not disagreeing, but it is a design fault if you continually end up having to choose between breaking or improving things. When you have major platform updates like windows NT rewrite back in 2000, windows 8 and now windows 11, they're opportunities to shed legacy things. The choice should have been to keep supporting a long-term-stable version of windows for security fixes (like XP or Win7) and get rid of tech designed to support old software. Their problem now is they want everyone to be on win10 and then win11 and then whatever they come up with, or else. You can carry legacy dependencies with you to new major versions or you can support old versions for security fixes long-term.
- sedatk 1y ago
  I empathize with the sentiment, but I think Microsoft isn't that conservative. Since XP, they have continuously dropped hundreds of features and components with varying significance. https://en.wikipedia.org/wiki/List_of_features_removed_in_Windows_Vista https://en.wikipedia.org/wiki/List_of_features_removed_in_Wi... That said, there isn't a one to one correlation between the gains of dropping a legacy component and the increased capability to innovate either. Windows is highly modular, and maintaining legacy compatibility rarely is a blocker for a line of innovation, nor is a high budget workload. I wonder though, what kind of innovation do you want to see but think that it's held back by legacy components?

cremno 1y ago

"Windows" did this 11 years ago: >FILE Encapsulation: In previous versions, the FILE type was completely defined in <stdio.h>, so it was possible for user code to reach into a FILE and muck with its internals. We have refactored the stdio library to improve encapsulation of the library implementation details. As part of this, FILE as defined in <stdio.h> is now an opaque type and its members are inaccessible from outside of the CRT itself. https://devblogs.microsoft.com/cppblog/c-runtime-crt-features-fixes-and-breaking-changes-in-visual-studio-14-ctp1/ https://devblogs.microsoft.com/cppblog/c-runtime-crt-feature...

rfl890 1y ago

Windows has kept FILE opaque for as long as I can remember. Granted, that's not very long, only 10 or so years.

badsectoracula 1y ago

> Linux should take note Ugh, no, it should not. As a user i prefer my existing programs to keep working whenever i update my OS and as a developer i prefer to work on new code than playing nanny with existing previously working code (working code here means the code did the task it was supposed to do) because some dependency broke itself.

notepad0x90 1y ago
it's already not working that way in Linux, it's just that there is no rhyme or reason to it. Even on stable Debian I have to have pipx/pyenv/venv for python and juggle multiple versions of rust and go because of mismatches between software and distro versions.
- alchemio 1y ago
  Python, rust and Go aren’t beacons of software stability though.
- badsectoracula 1y ago
  This is a Python, Rust and Go issue, not a Linux issue. With "Linux" i meant the Linux kernel which does not break backwards compatibility. Sadly, the userland does not have the same mindset as very few libraries and languages care about backwards compatibility. However at least on Linux it is possible to do that if you care by choosing languages and libraries that do not break compatibility without worrying that the OS will break things. On OpenBSD you may write your program in C (which has strong backwards compatibility as a language) and use only libraries such as curl, cairo, opengl, openal and x11 that in general do not break backwards compatibility and yet have the OS throw all that effort out of the window.
  - notepad0x90 1y ago
    Even on windows, it isn't usually the NT kernel that's the issue, it's the user space api's. For example, why hasn't ripgrep (and similar tools) replaced grep as a default? they're much better for performance right? (i mean on stable/mainstream distros). i get supporting old stuff, that's why there are LTS releases. But I think it is the fear of not being able to shed enough old things in new releases to displace the maintenance burden of LTS type releases that's the big issue. Features shouldn't be ridden of just because either, there needs to be a good reason, like a better alternative.