Calling yourself the “thin blue line” like a reference to police really doesn’t seem like a way to have an enduring community. Police don’t serve the community; I guess they think in the same way then.
[flagged]
We are the "thin blue line" that is trying to keep the code high quality
11–20 of 186 posts
Re: We are the "thin blue line" that is trying to keep the code high quality
#12The problem is aging code sours like milk. I empathize but we need to have people take over these initiatives and refactor them into something easier the maintain. Not saying introduce a new language or anything but change how we fundamentally look at “The Kernel”. I think reducing scope and making it so hardware providers must maintain their drivers is a good start. If your toolchain doesn’t suffice, create a new to…
There is redox os
Re: We are the "thin blue line" that is trying to keep the code high quality
#13Pre-supposes existing high quality, a fact not in evidence.
Re: We are the "thin blue line" that is trying to keep the code high quality
#14> the engineers which contribute the code will disappear
From the other side, as a very occasional contributor, I'd actually want to deal with fixes or reviews around the code I contribute.
But it's usually edge cases on otherwise stable and mature libraries, so hopefully it probably won't happen more than say once in a decade. If I got a mention on a PR I'd reappear, but that doesn't sound like the standard way, I never got involved again on anything submitted.
I feel like either the maintainers are doing an incredibly good job at vetting the PRs, or got used to deal with the aftermath another way and just don't need the original code submitter to reappear most of the time ?
Am I missing some bigger part of it ?
Re: We are the "thin blue line" that is trying to keep the code high quality
#15Calling yourself the “thin blue line” like a reference to police really doesn’t seem like a way to have an enduring community. Police don’t serve the community; I guess they think in the same way then.
[flagged]
Re: We are the "thin blue line" that is trying to keep the code high quality
#16The problem is aging code sours like milk. I empathize but we need to have people take over these initiatives and refactor them into something easier the maintain. Not saying introduce a new language or anything but change how we fundamentally look at “The Kernel”. I think reducing scope and making it so hardware providers must maintain their drivers is a good start. If your toolchain doesn’t suffice, create a new to…
There is redox os
It's a cool idea but it's licensed MIT instead of GPL or something copyleft so I won't contribute to it.
Rust-only ecosystem would be pretty cool though. It may be worth just forking linux for the sake of compatibility, and keeping the license going. I don't see a future otherwise.
I'd also like to see better compiler diversity. Maybe once gccrs rolls around we will see different attitudes around rust emerge, compared to C/C++ which have more distributed development.
Re: We are the "thin blue line" that is trying to keep the code high quality
#17Calling yourself the “thin blue line” like a reference to police really doesn’t seem like a way to have an enduring community. Police don’t serve the community; I guess they think in the same way then.
I agree with you, and the reference _is_ politically loaded (https://en.wikipedia.org/wiki/Thin_blue_line):
>The thin blue line U.S. flag has been banned by some police departments in the United States for its associations with ideologies described as "undemocratic, racist, and bigoted."
>According to a 2018 law review article, "thin blue line" also refers to an unwritten code of silence used to cover up police misconduct, also known as the blue wall of silence, a term dating back to 1978
Re: We are the "thin blue line" that is trying to keep the code high quality
#18Calling yourself the “thin blue line” like a reference to police really doesn’t seem like a way to have an enduring community. Police don’t serve the community; I guess they think in the same way then.
Police in your area maybe?
Look into the history and meaning of “thin blue line.” It’s an endorsement of the us vs. them mindset prevalent in American policing that is the source of many (most? all?) police scandals.
Re: We are the "thin blue line" that is trying to keep the code high quality
#19The factors at play are all obvious. The old-school guys want to keep things old-school. The new-school guys want to make things better in a new way. Has there been any new rewrite without a BFDL who himself is of the new school? The vim/neovim schism happened and perhaps that's how it ends. I personally like Neovim and I'm glad to be in backers.md and it's a tremendously larger amount of work than to have just changed vim. But c'est la vie.
Egcs vs. gcc was a big deal back in the day and in the end we ended up with gcc by the egcs guys and that was it. When you win, everyone forgets the 'drama' existed. When you lose, everyone remembers you as just the drama guy. RMS had the drama label for decades. Things are not even different. They're the same again. It's like when you'd buy those Chinese NES dupes and they'd have 999 levels of Mario but half the levels would be the same but with different colour bricks. Isomorphic to original but distinct. That's this story.
Re: We are the "thin blue line" that is trying to keep the code high quality
#20why cannot more people learn about git and branching you want your merges in? patch it in your own branch the real crux of the issue is the quality of " the offical version", the real issue, then, is about official branding. I remember back in the day there were multiple kernel versions by different mantainers.... then again I'm probably missing the forest for the trees or something
Because forked kernels is how we ended up with all those SBCs which could only run some ancient version of linux. If you can't mainline it, you are committing to maintaining a fork forever, and the more changes you require, the more maintenance that fork will be.
The Linux kernel quite intentionally makes maintaining a fork a pain in the ass to pressure vendors to mainline their drives. But now mainline maintainers are refusing to accept those drivers. So it's unlikely we will ever see Macbooks properly supported on Linux.