> (4). Once any maintainer of the community responds to the email, indicating “looks good”, we immediately point out the introduced bug and request them to not go ahead to apply the patch. At the same time, we point out the correct fixing of the bug and provide our proper patch. In all the three cases, maintainers explicitly acknowledged and confirmed to not move forward with the incorrect patches. This way, we ensure that the incorrect patches will not be adopted or committed into the Git tree of Linux.
> We send the emails to the Linux communityand seek their feedback. The experiment is not to blame any maintainers but to reveal issues in the process. The IRB of University of Minnesota reviewed the procedures of the experiment and determined that this is not human research. We obtained a formal IRB-exempt letter. The experiment will not collect any personal data, individual behaviors, or personal opinions. It is limited to studying the patching process OSS communities follow, instead of individuals.
I would say that the concept and implementation in C is inherently insecure. Switching to something less reviewed because there is a sudo vulnerability is not a guarantee that you are now "safer" especially if those ports are not reviewed.
As far as I can say, never ever use slicer69/doas, I've found 3 critical security vulnerabilities in it, the author does not understand C or how it should work in general.
Here are 3 examples if issues I found and the author used misleading commit titles to hide the issues and made excuses saying a clear buffer overflow very similar to the one found in sudo is just "potential":
1. Void Linux doesn't claim its BSD inspired, BSD inspired could mean 100 different things.
2. runit is not a "sysv-style" init, its the complete opposite.
runit is a supervisor and inspired by daemontools. A "rc init" is more closely related to "sysv-style" than runit is.
3. > I like OpenBSD's init system: super simple and best of all, no bs runlevels!
Runit has no runlevels, can actually automatically restart services when they die, can signal services without relying on pid files (which are prone to race conditions) and can create a pipe between a service and a log service that will never lose any logs.
The size for `sockaddr_storage` is not defined by POSIX, but `sockaddr_un` is defined, and you can't just change the `sun_path` to a pointer, so to increase `sun_path` you would have to increase the `sockaddr_storage` struct size.
This comes with other downsides, first is incompatibility with other OSes, most OSes seem to be around 104-109 bytes.
Second new problem would be that with any larger value each socket call would have to copy more data, even if they are not unix sockets. If you change it to something that looks sensible like `PATH_MAX` you end up increasing memory requirements for any application that works with sockets.
> Knoppix' Startvorgang läuft nach wie vor per Sys-V-Init mit wenigen Bash-Skripten, welche die Systemdienste effizient sequenziell oder parallel starten.
> Knoppix' boot sequence still uses Sys-V-Ini, with some bash scripts which start the system services efficiently sequential or in parallel.
So it has still all the downsides of sysvinit, except that might start sevices in a more efficient order or some in parallel.
If production is servers, then alpine is the better choice as it provides stable releases.
Void Linux is a nice desktop system and you can run it on single servers you personally take care of.
But I would rather not use it at scale for servers as updating rolling release can always lead to issues and not updating will leave security issues unfixed.
The one benefit would probably providing a glibc version if you require it.
Most websites don't have redundant servers but its still there and used by a lot of big sites.
The whole point of it is to connect to multiple A and AAAA records with a very short delay (250ms in chrome).
The browsers use poll to get notified about the first established connection and then use it.
So if one A/AAAA records IP is unreachable or slow it will use a another one.
There will be no fallout (except maybe for clients that don't use something like happy eyeballs, but any browser does that) if you have multiple A/AAAA records and one of them is down.
> Well Arch Linux Arm has optimized packages for soft-float ARMv5te, hard-float ARMv6 and ARMv7, and ARMv8 AArch64 instruction sets [1], which is even more.
Right, Void does not provide pre-built packages for armv5, there are a few other architectures void works with but doesn't provide pre-build packages.
this includes armv5, different mips targets and there are currently contributors working on getting powerpc and powerpc64 merged.
powerpc64 will most likely become another architecture with pre-build packages.
> Does it really matter if it is not under the same project?
Yes, different projects apply different patches, have potentially different packages or provide different package versions.
With Void every package has the same patches applied, maintainers are "forced" to write portable patches that can be easily upstreamed.
Package versions are usually the same (some exceptions), no delay.
I bet its easier for void to maintain all architectures at once than the man power required to maintain separate repositories and patches for the arch "forks".
Then you have the review overhead with forks, on void maintainers review commits to one repository, with the arch forks you have a fraction of the arch maintainers review commits to forks, while all others only review commits to the main repository.
Void makes it easier to maintain packages for different architectures, it provides xbps-src which cross compile to different architectures, it uses Travis-CI to build each pull request for different architectures.
You think, but you have no clue about the differences, which are so substantial that it wouldn't be possible to convince arch to change things like this, may it be for legacy reasons because some things are breaking changes or may it be just something the Arch team doesn't care about.
- Arch Linux supports only x86_64 in the main project
- Void supports i686, x86_64, armv6, armv7 and aarch64 with both musl and glibc under one project, one source repository.
- Arch linux does not allow partial updates
- Void linux allows partial updates because the package manager tracks shared libraries and big issues can be avoided by aborting the transaction if a conflict exists
- Arch puts everything into one big package
- Void splits packages, not as much as debian, but at least the development stuff is in a `-devel` subpackage. This reduces the installation size by alot (especially useful for embedded systems, arm...).
- Arch has no repository with debugging symbols
- Void has a repository with -dbg packages containing the debug symbols.
- Arch only maintains two kernels, mainline and lts.
- Void maintains kernels in packages with the a version suffix, `linuxX.XX`. Users can choose which series for how long they want to use. (also great for embedded systems)
- Arch kernel updates remove the old kernel version
- Void keeps the old kernels, the administrators can boot the previous kernel until they decides to purge old kernels with the `vkpurge` script if new kernels work fine.
This are the differences on top of my head, there are plenty more.
I'm sorry to hear about your experience with this, but this is simply not the case here.
There is a big blog post about it, no one is trying to boot anyone out.
Yes the article does not mention names, but its easy to find out and verify commit histories and social media accounts.
And just to be sure, I think most if not all of the contributors would be happy to hear back and know if everything is alright. The lead was a very central and active part of the community until over a year ago.
Forking the project would kill the original, all servers are payed for and maintained by currently active contributors.
We can not simply pull the plug and ask users to switch, if we do this this has to happen over a long time period until we know there are not many users left and there is no significant amount of traffic on the repository mirrors.
> Furthermore, we’re in contact with a non profit organisation that helps open source projects to manage donations and other resources. We hope that we can announce further details in a few weeks.