Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Features vs ungoogled? #1

Open
dm17 opened this issue Jun 11, 2021 · 3 comments
Open

Features vs ungoogled? #1

dm17 opened this issue Jun 11, 2021 · 3 comments

Comments

@dm17
Copy link

dm17 commented Jun 11, 2021

I'm curious about what this achieves feature-wise versus ungoogled-chromium. If it achieves more, then I wonder if the ungoogled-chromium projects would be interested in your patches. Here's a brainstorm on the effort to merge a bunch of ungoogled chromium stuff: ungoogled-software/ungoogled-chromium#1395

P.S. I'm a fan of what you recently stood up for on the kernel mailing list ;)

@metux
Copy link
Owner

metux commented Jun 14, 2021

Hi,

I'm curious about what this achieves feature-wise versus ungoogled-chromium.

My intent was dropping everything that's not really needed and risky for privacy.
Unfortunately, even building, let alone maintaining, chrome is a monster task and I just haven't had the spare time to finish up anything actually useful.

If it achieves more, then I wonder if the ungoogled-chromium projects would be interested in your patches. Here's a brainstorm on the effort to merge a bunch of ungoogled chromium stuff: Eloston/ungoogled-chromium#1395

IMHO we should bring all those similar projects together. And the fist major step should be clear and robust import path from upstream (so we can easily rebase our patches ontop of upstream head) and robust build build process. Once that's done, it's much easier to do custom patching and building installable patches for various distros.

P.S. I'm a fan of what you recently stood up for on the kernel mailing list ;)

Thanks. I actually didn't expect the impact of these few lines. Linus exposed himself and now is compared with Gates in many chat groups around the world. Smells like he didn't do himself a favour with that. We'll see how this plays out for him.
I just wonder why he's in such a panic.

@dm17
Copy link
Author

dm17 commented Jun 16, 2021

Hi,

I'm curious about what this achieves feature-wise versus ungoogled-chromium.

My intent was dropping everything that's not really needed and risky for privacy.
Unfortunately, even building, let alone maintaining, chrome is a monster task and I just haven't had the spare time to finish up anything actually useful.

Yes, understandable.

If it achieves more, then I wonder if the ungoogled-chromium projects would be interested in your patches. Here's a brainstorm on the effort to merge a bunch of ungoogled chromium stuff: Eloston/ungoogled-chromium#1395

IMHO we should bring all those similar projects together. And the fist major step should be clear and robust import path from upstream (so we can easily rebase our patches ontop of upstream head) and robust build build process. Once that's done, it's much easier to do custom patching and building installable patches for various distros.

Well please do help promote the idea and your improvements to it in the above thread. Some are resistant because they'll think it'll cost rather than save them time in the long run. Those two possibilities aren't comparable because if they all merged their bases together, then perhaps each could achieve things they wouldn't otherwise.

P.S. I'm a fan of what you recently stood up for on the kernel mailing list ;)

Thanks. I actually didn't expect the impact of these few lines. Linus exposed himself and now is compared with Gates in many chat groups around the world. Smells like he didn't do himself a favour with that. We'll see how this plays out for him.
I just wonder why he's in such a panic.

Seemingly very rare for engineers not to be totally brainwashed on the same set of issues across the board that they perceive as being "known by science" in the same way engineers know how software/computers they built themselves work. I suppose those who can see it also notice their associated logical fallacies :)

@metux
Copy link
Owner

metux commented Jun 16, 2021

Hi,

Well please do help promote the idea and your improvements to it in the above thread. Some are resistant because they'll
think it'll cost rather than save them time in the long run. Those two possibilities aren't comparable because if they all merged
their bases together, then perhaps each could achieve things they wouldn't otherwise.

Will be happy to do so.

I believe the first thing we should do is set up an clear SCM process (eg. automatic imports from upstream, so that we're able to rebase our patches anytime) and fully automatic build process. For start, I could live with everything in a docker container, packaging for distros can come later.

Seemingly very rare for engineers not to be totally brainwashed on the same set of issues across the board that they perceive as being "known by science" in the same way engineers know how software/computers they built themselves work. I suppose those who can see it also notice their associated logical fallacies :)

Post-humanist mindset. These folks tend to be believe that living organisms (life forms as well as societies) are just big machines that can be engineered. Quite the same mindset as in the Third Reich. OTOH, that's good for us, as their hybris will bring their ideology to downfall. Nature just doesn't work that way, so they're ideology is deemed to fail.

It's them, not us, who'll have a hard crash landing, when this all falls apart. There's even chance that once they're all fully discredited, we might become the new leaders. Two years ago, I would have rigorously rejected that kind of responsibility, but now, after 1.5 years of organizing weekly rallies, dozens of public speeches, etc, I'm ready to take it now.

wwg1wga

--mtx

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants