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

  • freemedia
  • Guest

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 Reply by zapper

  • zapper
  • zapper
  • Hyper Cyber
  • Offline
  • Registered: 2017-10-18
  • Posts: 1,075

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...

HyperbolaBSD: The Future of Secure Libre Lightweight Operating Systems!

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

  • freemedia
  • Guest

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

4 Reply by schilling.klaus

  • schilling.klaus
  • Hyper User
  • Offline
  • Registered: 2022-11-27
  • Posts: 55

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

In the case of Mozilla, add the move of launching Rust as the new platform, given that this step also influenced Torvalds into making the kernel starting to rot away from the inside.

Maybe also add selinux etc. as assaults on privacy; further, all those distro-agnostic binary repositories (Snap, Flatpac, AppImage) are a thread to freedom.

5 Reply by zapper

  • zapper
  • zapper
  • Hyper Cyber
  • Offline
  • Registered: 2017-10-18
  • Posts: 1,075

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

schilling.klaus wrote:

In the case of Mozilla, add the move of launching Rust as the new platform, given that this step also influenced Torvalds into making the kernel starting to rot away from the inside.

Maybe also add selinux etc. as assaults on privacy; further, all those distro-agnostic binary repositories (Snap, Flatpac, AppImage) are a thread to freedom.

Since this topic has come back up after a while, I should add 2+ years later I realized its less EEE and more EEATC
Embrace
Extend
Absorb Then Control

The difference being to me, one causes the idea to die, one is basically stealing and making use of someone else's hard work for their own purposes.

Mostly the same motives,
But more cunning and way more cheeky.

HyperbolaBSD: The Future of Secure Libre Lightweight Operating Systems!

6 Reply by Other_Cody (edited by Other_Cody 2024-02-02 16:08:09)

  • Other_Cody
  • Guest

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

There is a question at https://trisquel.info/en/forum/reverse- … boot-legal

about the binary blobs in Libreboot and Coreboot. So like the Linux kernel has blobs, these boot programs also may be a problem for those "downstream" as those "downstream" the Linux kernel also need time to just de-blob the kernel.

I do not know if Libreboot and Coreboot have licenses that forbid reverse engineering or just have binary blobs in them, though that could still be a problem for freedom as Libreboot may be under GNU General Public License, version 3.

And if it is under GNU General Public License, version 3, maybe also later versions, than till the blobs are removed it could not be "legal" to distribute it with the blobs still in it.

That is why GNU Boot and Canoeboot were made, I think, to have fully "free as in freedom" boot software/firmware instead of firmware with binary blobs in it.

https://www.gnu.org/software/gnuboot/web/

https://canoeboot.org/

Though if the blobs in Libreboot and Coreboot could be "legally" reverse engineered than Libreboot and Coreboot may also be "legal" to distribute when the blobs have source code that is not obscured, but till than those may be not be distributed without copyright infringement, I think. As Coreboot is under is under GNU General Public License, version 2, maybe also later versions.

Unless exceptions are made in both Libreboot and Coreboot licenses, to link non-free licensed things with the GNU General Public Licenses, somehow, thus making the blobs things that may not be "legal" to reverse engineer or even distribute, unless you get permission from whoever holds the copyright to the code.