I have no idea why bitrig is not a uptream subproject in openbsd..
I am completely at a lost as to why openbsd have not moved to using clang/llvm instead of a completely outdated gcc version just support platforms like 286’s that seriously no one is really going to use for anything serious…. :<
This could explain your OpenBSD compiler questions
– gcc guys are too much closed to external patches comming from “non GPL” OS’s
– gcc guys take too much time to review patches, and when it’s done they drop a set of paches because 1 line of coding stile wrong, and you have to resend all the shit again, and wait on the queue
– OpenBSD devs created a lot of patches to make gcc work as expected on this OS
– Upstream patches to gcc now requre GPLv3, increasing the gap of differences between gcc and openbsd-gcc. Since their pathes would not be accepted with GPLv2, they managed the patches just on the GPLv2 version fork.
– OpenBSD have a set of almost 10 devs that knows all the limitations and strengths of their gcc so, they don’t want to risk to change the compiler without making tests and creating this knowledge with clang first.
I am completely incapable of telling what the point of this exercise is. Why?
It’s a fork of NetBSD that is supposed to contribute code back? It’s supposed to be experimental and implement new features aggressively, yet at the same time be ‘robust’ and ‘industrial-grade’? More so than NetBSD? How so, by implementing immature bleeding edge code? I thought that was the way to *not* do that.
Meanwhile their goals seem to consist of vague developer attraction.. and a graphical installer. Why?
This should be called WhyBSD.
NetBSD has always been a great platform and attracted a lot of cool research. However, even when some of this work was integrated intro NetBSD proper, it was not enabled by default (ASLR, SSP, signed packages, disk encryption…). To me such features are industry standard nowadays, but they end up being out of sync, and then bugged and dismissed. They are not immature, they are there, yet nobody can freely experiment with them openly and publicly (because of the current development workflow and tools of NetBSD).
Now that’s why we are opening this staging area: flexible tools, open development, stable and experimental branches to work on.
I hope that it will not turn into a “Distro Linuxism” or “another dead bsd project” like Bitrig
https://www.bitrig.org/index.php?title=Current_issues_page
I have no idea why bitrig is not a uptream subproject in openbsd..
I am completely at a lost as to why openbsd have not moved to using clang/llvm instead of a completely outdated gcc version just support platforms like 286’s that seriously no one is really going to use for anything serious…. :<
This could explain your OpenBSD compiler questions
http://marc.info/?l=openbsd-misc&m=137530560232232&w=2
Basically:
– gcc guys are too much closed to external patches comming from “non GPL” OS’s
– gcc guys take too much time to review patches, and when it’s done they drop a set of paches because 1 line of coding stile wrong, and you have to resend all the shit again, and wait on the queue
– OpenBSD devs created a lot of patches to make gcc work as expected on this OS
– Upstream patches to gcc now requre GPLv3, increasing the gap of differences between gcc and openbsd-gcc. Since their pathes would not be accepted with GPLv2, they managed the patches just on the GPLv2 version fork.
– OpenBSD have a set of almost 10 devs that knows all the limitations and strengths of their gcc so, they don’t want to risk to change the compiler without making tests and creating this knowledge with clang first.
I am completely incapable of telling what the point of this exercise is. Why?
It’s a fork of NetBSD that is supposed to contribute code back? It’s supposed to be experimental and implement new features aggressively, yet at the same time be ‘robust’ and ‘industrial-grade’? More so than NetBSD? How so, by implementing immature bleeding edge code? I thought that was the way to *not* do that.
Meanwhile their goals seem to consist of vague developer attraction.. and a graphical installer. Why?
This should be called WhyBSD.
NetBSD has always been a great platform and attracted a lot of cool research. However, even when some of this work was integrated intro NetBSD proper, it was not enabled by default (ASLR, SSP, signed packages, disk encryption…). To me such features are industry standard nowadays, but they end up being out of sync, and then bugged and dismissed. They are not immature, they are there, yet nobody can freely experiment with them openly and publicly (because of the current development workflow and tools of NetBSD).
Now that’s why we are opening this staging area: flexible tools, open development, stable and experimental branches to work on.
Hope this makes sense,
— khorben