Live data from Hacker News

We are the "thin blue line" that is trying to keep the code high quality

lore.kernel.org

91–100 of 186 posts

Re: We are the "thin blue line" that is trying to keep the code high quality

#91
post #68

Earlier quoted context omitted.

I'm not a left winger, and I generally respect the police, but everybody I've met with a "thin blue line" American flag decal or sticker has been a total asshole. It's not just hatred of the police. Connotations change over time, and the general connotation of "the thin blue line" in the US at the moment is unabashed support of far-right authoritarianism.

[flagged]

[flagged]

Re: We are the "thin blue line" that is trying to keep the code high quality

#92
post #27

> One of the things which gets very frustrating from the maintainer's perspective is development teams that are only interested in their pet feature, and we know , through very bitter experience, that 95+% of the time, once the code is accepted, the engineers which contribute the code will disappear, never to be seen again. This was painful for me to read as someone who has seen how corporations think about “Open Sou…

That doesn't exactly strike me as a bad thing? Isn't that sort of the point of open source? Lots of people working on the things that interest them and through a diversity of interests arriving at a useful project?

Re: We are the "thin blue line" that is trying to keep the code high quality

#93
post #86
post #61

Earlier quoted context omitted.

There are already kernels written in Rust. Telling them to go write new kernels in Rust is like telling people working on a new audio workstation that they should write a package manager instead. A new kernel that they cannot practically use does not suit their needs. The point is to use Rust where it can suit their needs.

Why are they entitled to the existing kernel? By what right?

They were invited to by Linus and Greg KH...

Re: We are the "thin blue line" that is trying to keep the code high quality

#95
post #75
post #62

Earlier quoted context omitted.

Yes but the parent has addressed this and you're just talking past them like they didn't comment. If the maintainers don't want it to happen then they need to come to an agreement that it won't happen. If they do want it to happen then they need to stop blocking it for non-technical reasons. If they can't actually decide then that's "no" or up to the project lead to enforce the decision at the risk of losing maintain…

Wow, the entitlement here is absolutely amazing. You are not entitled to any work, or explanation, or "agreement". Show me where it says maintainers owe you any of this at all.

I think that being open to working with others is implicit in deciding to maintain a widely used project like Linux. There's tons of open source tools which are explicit "this is something you are free to use but I created it for my own purposes and don't intend to support it"; however, that isn't how Linux presents itself.

That is to say, if you are building an tool as a collaborative open source project, then that implies that you intend to collaborate.

Re: We are the "thin blue line" that is trying to keep the code high quality

#96
post #65
post #16

Earlier quoted context omitted.

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, compare…

The Rust community does seem to be more focused on non-copyleft licenses, do you have any ideas why that is?

nope, but I encounter it a lot. For example, the default cargo template or whatever just gives you a non-copyleft license https://github.com/cargo-generate/cargo-generate . There are a lot of questionable defaults in this space, like the ecosystem encouraging people to use a centralized repository like crates.io which requires github (now owned by microsoft).

I figure it's because the companies and orgs that started working with and investing in the rust ecosystem start by contributing to the compiler, which is non-copyleft and just try to extend that because it works to their advantage. You see this with a lot of languages/ecosystems with corporate sponsors, but also just because it gives you a unique selling point in an area where copyleft software dominates. Like, there will always be some company (like imagine a defense company) that absolutely refuses to publish all of their changes, so that represents a niche that can sustain smaller permissive projects.

I think that for an individual corporation, permissive is better and they won't make a decision to go copyleft unless forced. But for the ecosystem as a whole, GPL is better for business (especially when it comes to something like a kernel) because it forces companies to publicly fork over their drivers and collaborate, and reduces the competitive advantage vs companies that would otherwise not publish their changes if it was permissive.

That was probably too many words. Anyways, it would be nice to see some of this improved, i think it's a great language and will probably replace C++.

Re: We are the "thin blue line" that is trying to keep the code high quality

#97
post #28

Earlier quoted context omitted.

Also, if you're not from the USA, you're more likely to associate it with the beloved Rowan Atkinson sitcom.

Or the non-politically-loaded phrase that the sitcom is named for.

> the non-politically-loaded phrase

You mean its popularisation and heavy use by William Henry Parker III, Chief of the Los Angeles Police Department (from 1950 to 1966)?

He very much used it in a loaded manner to portray police as bastions of good and the last defence against "the criminal element".

From his wikipedia page:

   Parker himself was known for his "unambiguous racism".
https://en.wikipedia.org/wiki/William_H._Parker_(police_offi...

Re: We are the "thin blue line" that is trying to keep the code high quality

#98
post #65
post #16

Earlier quoted context omitted.

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, compare…

The Rust community does seem to be more focused on non-copyleft licenses, do you have any ideas why that is?

They are too young to have lived through SCO and Halloween documents.

Re: We are the "thin blue line" that is trying to keep the code high quality

#99
post #65
post #16

Earlier quoted context omitted.

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, compare…

The Rust community does seem to be more focused on non-copyleft licenses, do you have any ideas why that is?

Speaking for myself, I want my code to be usable by everyone, including corporations, for free, with no limits. I even like to drop the attribution clause that things like MIT have.

Both copyleft and copyright (to a lesser extent) are in opposition to my beliefs and goals.

Re: We are the "thin blue line" that is trying to keep the code high quality

#100

The 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…

>Bring solutions. Tech debt is just OpEx to everyone else.

What if there was a rust compiler to C, that produced like readable, compliant C code for the kernel. And then developers that want to work in rust can publish their original rust code to some third party location, so the reviewers have no idea if the C code they receive it was originally written in rust or not.

Post reply on HN