Note as well like many people have pointed out - the GPL was never intended to protect us from corporate interests. It was written under the assumption that capitalism will "just do the right thing" as long as it's forced to release source code. and, that's just not true.

Show thread

On top of licenses like the GPL **barely** being able to provide the protection of keeping open source open, it's also unable to provide for requirements that software not be used for the purpose of war, and they won't provide any kind of protection against a hostile corporate takeover/takedown/etc. of projects.
FOSS needs to be treated as a public service that everyone has a right to, one that needs real tangible protections against hostile corporate interests.

Show thread

The future of open source cannot rely on corporations. As long as it does, we will be contributed to up until the point it is no longer convenient and profitable. The GPL already proved that you need actual restrictions on how software can be distributed in order for companies to even consider keeping their work with open source, and it doesn't provide any kind of protections for companies just up and dropping open source projects because they didn't feel like contributing anymore

Show thread

The longer I do open source, the more I worry about the entirely real possibility of large corporate sponsors of the projects that I work on suddenly dropping those projects because they reached a point where it's no longer convenient for The Company to contribute to this upstream, so they just go to make their own upstream.

I worry about this with companies like Google especially, where they've repeatedly shown they will take more control wherever they possibly can over digital ecosystems

Google makes another valuable contribution to open source, by making it so that the majority of the emails regarding the X.org foundation that we try to send out to people just get marked by gmail's spam. I'm going to try to get in contact with someone about this again, but I'm not expecting anything to change and god fucking damnit google can you maybe fuck off please and stop trying to shit on open source? thanks

@devurandom @WritNelson\@twitter.com@twitter.com it better only have those like three offspring sounds as the sound track

Gotta be honest: it is next to impossible to push myself to work on something with a looming deadline when everyone involved already has confirmed we can still go without this thing being done, when I'm also the only one who is actually pushing for this thing to get done on time and me getting this thing done on time is entirely dependent on a hardware partner that is clearly also not motivated to give a shit about getting this thing done.

@rrika I meant more in terms of "what GPU/GPU driver", but yeah feel free to poke me on mastodon. I probably can't fix your issue here but I can point you in the right direction to get it fixed

@rrika my guess is it's something going wrong with mesa (flickering might be a result of page flipping combined with some framebuffer being pointed at the wrong location, or some other rendering error). do you have a screenshot and what kind of system is this running on?

*hires a plane pilot to fly with a large banner on the back of their plane that says "Hi this is Lyude, can someone please review my patches thanks"*

@emersion if you optimize your config first you might disable a module that would have been loaded otherwise

And if you REALLY want to optimize your kernel config, even though I promise you will not get any marginal speed increase just from turning off a bunch of modules, my advice is to start with your distro's config, compile the whole thing and boot that kernel, then run `make localmodconfig`, recompile and reinstall the kernel, and bam - you've saved a bunch of space and are dramatically less likely to have disabled something.
That's still potentially painful though

Show thread

But in my opinion? If you're just compiling a kernel for arch or something, the extra space an unoptimized kernel takes (which really isn't much - fedora's kernel + modules only amounts to around a few hundred megabytes total) is probably well worth the amount of potential pain you're saving yourself.

Show thread

If you feel comfortable changing both of these things, go nuts. I won't stop you.
But if it means anything: as a full time kernel developer I genuinely avoid changing them outside of my dev setups or when I need a driver fedora doesn't enable because even among experts it's REALLY easy to turn something off you didn't realize you actually needed. You might be hitting some bug right now because you turned something off.
So I guess, think about whether you really need to change them or not

Show thread

This /partly/ goes same for kernel cmdline options, however, there are a bunch of kernel cmdline options we do actually expect users to need to change every now and then (hence why some of them are actually documented in Documentation/admin-guide/parameters.rst). But, a lot of the time we don't really expect users to change those either outside of us asking them to so we can troubleshoot an issue, or the kernel itself telling you to change them in dmesg

Show thread

This is just kind of an observation that I've noticed for a while now and not pointed at anyone in particular, but I think it's worth mentioning:
Linux compile-time kernel config options are typically intended for either:
- Making the kernel small because you are developing on it and you need to recompile a bajillion times
- Making the kernel small for an embedded developer
- Distro maintainers
We uh, genuinely do not add config options with the intent of end users actually changing them

If corporations are people then they can be kinkshamed

Show older
Queer Party!

A silly instance of Mastodon for queer folk and non-queer folk alike. Let's be friends!