1 (edited by freemedia 2018-10-08 21:51:23)

Topic: projects that might be designed as part of anti-freedom eee strategy

i think the title is pretty reasonable, if its too controversial i welcome the admins/mods to change the title but it says what i meant.

years ago, a large corporations plans to fight free software were leaked into the public. they are available via wikipedia.

one of the most prominent strategies is known as "eee" and it is a way that some companies fight competition (also freedom) and the halloween documents were specifically about how to fight free software itself. so perhaps today, people might think free software is immune to eee. either way, there was a detailed strategy to fight free software as a threat to non-free models.

while for the past few years, i believe symptomd has proven to be a setback for free software (it has certainly divided software authors, which isnt always a bad thing in the long run-- but in the short run, it can cause difficulty.)

whether or not you think that this division is the fault of the software or the people who left is not a debate that will be won either way-- its a theory, but it really only lends itself to peripheral theories and less a conclusion.

im only going to list events and software and design decisions that i think have caused the most problems for free software in the past few years. feel free to include your own candidates.

hopefully this community (more than others) will find this thread useful, and not mistake it for simple trolling or a simple misunderstanding.

1. systemd (one of the big reasons we are here)
2. github purchase
3. mozilla dropping support for old plugins

now you can make "good" arguments for each of these. to me thats beside the point. it isnt possible to prove or disprove that a company is in any way responsible for having a hand in any of these things as part of an anti-free-software strategy.

however, i think it is at best optimistic and at worst naive to think that monopolies have stopped treating free software as a threat.

not only do they (a select number of them) always have a plan to fight competition, but there is public access to older versions of those plans, and we can find that some of those practices bear similarity to what has happened over the past few years.

the goal is not to prove this has happened, the goal is to ask what projects have hit free software development the hardest-- if at all.

1. systemd (one of the big reasons we are here)
2. github purchase
3. mozilla dropping support for old plugins

i think its a good start. im not married to this list, though i doubt i will ever consider symptomd a "good thing."

above all, please avoid (if possible) making this thread about any single example. this is about a list. of course we can talk about the individual items, thats the point-- but not (preferably) to focus exclusively on one or two of the items. i mean we could just have one or two threads about those (and probably do already.) the real question here is: "are there others?"

i dont personally believe there is only one item on it-- even if 3 doesnt ultimately belong on the list. i threw it on only to say "aww, that stinks." please try not to explain that mozilla shouldnt be "on the hook" for maintaining their old plugin infrastructure-- i agree, but there are more responsible ways to retire the old versions.

any mozilla-like organisation who have laid some claim to care about freedom or public good in the past (mozilla is a 501(c)(3) are they not?) should be zipping all of this up to be on the internet archive.

there are plenty of archivists happy to help with this sort of thing. by doing it this way, mozilla is not simply retiring from old plugins-- they are extinguishing them and sending people into a scramble to preserve them.

i do not applaud mozillas actions. ive complained for a long time that they clearly dont care about the public good anymore.

that said, ive proposed the list. feel free to pull the third item first.

i suspect most of us will agree on the first item-- are there others worth mentioning?

what is the real purpose of this list? to think about the consequences for software freedom of certain events and software and design decisions, and to either work around or at least be careful around those list items.

this is not a blacklist. although it pleases me to notice that lib32-systemd is on your own blacklist as:

lib32-systemd::::[nonsecurity] is a scope creep project that leads to vulnerabilities, contains absurd bugs and conceptional problems [nonprivacy] contains hard coded Google DNS, [technical] breaks portability, ignores backwards compatibility, replaces existing services forcing into adoption...

that is superbly well-said and bravo to whomever wrote that!

this is not a blacklist but if you feel it is more appropriate, please feel free to move this from philosophy to the blacklist subforum. cheers.

2

Re: projects that might be designed as part of anti-freedom eee strategy

freemedia wrote:

i think the title is pretty reasonable, if its too controversial i welcome the admins/mods to change the title but it says what i meant.

years ago, a large corporations plans to fight free software were leaked into the public. they are available via wikipedia.

one of the most prominent strategies is known as "eee" and it is a way that some companies fight competition (also freedom) and the halloween documents were specifically about how to fight free software itself. so perhaps today, people might think free software is immune to eee. either way, there was a detailed strategy to fight free software as a threat to non-free models.

while for the past few years, i believe symptomd has proven to be a setback for free software (it has certainly divided software authors, which isnt always a bad thing in the long run-- but in the short run, it can cause difficulty.)

whether or not you think that this division is the fault of the software or the people who left is not a debate that will be won either way-- its a theory, but it really only lends itself to peripheral theories and less a conclusion.

im only going to list events and software and design decisions that i think have caused the most problems for free software in the past few years. feel free to include your own candidates.

hopefully this community (more than others) will find this thread useful, and not mistake it for simple trolling or a simple misunderstanding.

1. systemd (one of the big reasons we are here)
2. github purchase
3. mozilla dropping support for old plugins

now you can make "good" arguments for each of these. to me thats beside the point. it isnt possible to prove or disprove that a company is in any way responsible for having a hand in any of these things as part of an anti-free-software strategy.

however, i think it is at best optimistic and at worst naive to think that monopolies have stopped treating free software as a threat.

not only do they (a select number of them) always have a plan to fight competition, but there is public access to older versions of those plans, and we can find that some of those practices bear similarity to what has happened over the past few years.

the goal is not to prove this has happened, the goal is to ask what projects have hit free software development the hardest-- if at all.

1. systemd (one of the big reasons we are here)
2. github purchase
3. mozilla dropping support for old plugins

i think its a good start. im not married to this list, though i doubt i will ever consider symptomd a "good thing."

above all, please avoid (if possible) making this thread about any single example. this is about a list. of course we can talk about the individual items, thats the point-- but not (preferably) to focus exclusively on one or two of the items. i mean we could just have one or two threads about those (and probably do already.) the real question here is: "are there others?"

i dont personally believe there is only one item on it-- even if 3 doesnt ultimately belong on the list. i threw it on only to say "aww, that stinks." please try not to explain that mozilla shouldnt be "on the hook" for maintaining their old plugin infrastructure-- i agree, but there are more responsible ways to retire the old versions.

any mozilla-like organisation who have laid some claim to care about freedom or public good in the past (mozilla is a 501(c)(3) are they not?) should be zipping all of this up to be on the internet archive.

there are plenty of archivists happy to help with this sort of thing. by doing it this way, mozilla is not simply retiring from old plugins-- they are extinguishing them and sending people into a scramble to preserve them.

i do not applaud mozillas actions. ive complained for a long time that they clearly dont care about the public good anymore.

that said, ive proposed the list. feel free to pull the third item first.

i suspect most of us will agree on the first item-- are there others worth mentioning?

what is the real purpose of this list? to think about the consequences for software freedom of certain events and software and design decisions, and to either work around or at least be careful around those list items.

this is not a blacklist. although it pleases me to notice that lib32-systemd is on your own blacklist as:

lib32-systemd::::[nonsecurity] is a scope creep project that leads to vulnerabilities, contains absurd bugs and conceptional problems [nonprivacy] contains hard coded Google DNS, [technical] breaks portability, ignores backwards compatibility, replaces existing services forcing into adoption...

that is superbly well-said and bravo to whomever wrote that!

this is not a blacklist but if you feel it is more appropriate, please feel free to move this from philosophy to the blacklist subforum. cheers.

Yep, and also pulseaudio is rumored to be similiar to systemd to some extent, although, I dunno if its a huge problem yet...

But, it does have some leaks which are still bad. Give the systemd team time, they will make something else bad... or we can just fix the entire problem by convincing people to fight the good fight. How we would do that, I have no idea...

Hyperbola:

The Stable Secure Libre Arch!

3 (edited by freemedia 2018-10-09 02:06:48)

Re: projects that might be designed as part of anti-freedom eee strategy

zapper wrote:

and also pulseaudio

of course. actually, whenever ive had a problem with sound (or someone else has had a problem with sound) disabling pa seemed to help or fix it entirely. i always hear thats what it used to be like.

just to illustrate, most recently-- ive hidden this post so i will paste it in here:

Jun 23 2018, 11:56 PM

so im running alsamixer, and something is definitely broken here. im familiar with the auto-mute feature, and i should probably be able to turn it off.

when i start clipping the wires to the speakers, you might ask me why im breaking this laptop. well, it was working fine for years, someone broke it, but im restoring it to the default i want-- which is i dont use the built-in speakers, i want them to be reliably turned off.

the difference is, the software controlling them was until recently, reliable. when i plug in the headphones, the speakers are muted-- whoopty-doo, thats whats supposed to happen when you plug headphones into a laptop.

but when i turn the speakers all the way down in the mixer, then plug in headphones and unplug them again, hey, guess what-- it turns the speaker volume up to 100%. i turn them down all the way with the controls, it turns them up again when i do this. theres no simple way to stop it from doing that.

now thats just stupid. i plug in headphones, i remove them, my speaker volume goes up to 100%. real good in the middle of a uni course or quiet middle of the night coding session. now i have to turn off auto-mute in the mixer.

nope! good job guys, that doesnt do anything.

so no matter what, unplugging the headphones turns the speakers up to 100%. you know whats more useful than that functionality? clipping the speaker wires. so literally yeah, here are the scissors.

now if i delete the offending typically useless layer of sound-level/sound-functionality sabotaging software from lennart and company, it does fix the problem, it stops changing the speaker levels for me. no surprise that it was one of the usual suspects.

and i can still alsactl init without it, but thats not going to give me audio from my web browser right, so time to reinstall this bullsh** software, be happy that ive clipped the wires to the speakers, and really despise the people responsible for destroying gnu/linux.

theres a reason im doing it this way, its fast and it works 100%. but it only works on machines that i can physically modify, so for everyone else that wants to be absolutely certain their machine isnt going to randomly start belting out meghan trainor tunes, sudo rm /usr/bin/pulseaudio ; kill -9 $(pgrep pulseaudio)

how would you get sound working in your web browser after that? go back to 2013 and use a real browser on a real operating system, as there isnt one anymore.

no thanks to mozilla as usual-- bunch of punks and...

wow, i wasnt having a nice day. im using that machine right now-- it was worth it to pull the speaker wires, because now i have sound but it stops coming over the speakers in the middle of the night.

im sure that theres an option hidden away in some config file. ive already got plenty of those without lennart and co adding yet one more, thanks.

definitely!

1. systemd
2. github purchase
3. pulseaudio
4. mozilla dropping support for old plugins

of course if this were any other forum, there would immediately be jeers from someone about why i didnt just go and find the umpteenth new config option, how im exaggerating and didnt rtfm--

all sidestepping how completely and utterly stupid it is to have a default where:

1. i mute the speakers
2. then i plug in headphones
3. then when i unplug the headphones, it unmutes the speakers automatically

if i disable pa, this doesnt happen. and also the browser stops playing sound then, because its the only application i use that requires pa.

so i wont say its a bigger deal than the github purchase but:

1. systemd
2. github purchase
3. pulseaudio
4. mozilla dropping support for old plugins