Hacker Newsnew | past | comments | ask | show | jobs | submit | stateoff's commentslogin

A consumers tale about enshitification. Look to the sky and enjoy your ESPP everyone :)


"Raspberry Pi CM0 is a yet-to-be-officially-announced castellated Compute Module based on the Raspberry Pi RP3A0 SiP (System-in-Package) found in the Raspberry Pi Zero 2 W and Raspberry Pi Compute Module 3E (CM3E)."



Absolutely agree. The blog post is claiming the opposite to what their ToS is granting - but one is fluff (that will be forgotten soon) while the other is legally binding. I cannot imagine applications like browsers that would require such an unrestricted license for user input just to do its service. That clearly indicates some "other" future motive that is underlined by the notion to remove the FAQ entry and other past actions towards an advertising future at Mozilla.

Am looking forward to explore some of the alternatives. And no, I don't want a just a correcting/updating/informing follow-up blog post of how we the users got it all wrong. In fact, the current UPDATE makes it worse:

"UPDATE: We’ve seen a little confusion about the language regarding licenses, so we want to clear that up. We need a license to allow us to make some of the basic functionality of Firefox possible. Without it, we couldn’t use information typed into Firefox, for example. It does NOT give us ownership of your data or a right to use it for anything other than what is described in the Privacy Notice."

vs. the ToS:

"You give Mozilla all rights necessary to operate Firefox, including processing data as we describe in the Firefox Privacy Notice, as well as acting on your behalf to help you navigate the internet. When you upload or input information through Firefox, you hereby grant us a nonexclusive, royalty-free, worldwide license to use that information to help you navigate, experience, and interact with online content as you indicate with your use of Firefox."

No - you don't need a license for my input. Just pass the butter, it's not your job to "use that information" in any way, form or shape. How did you survive 26 years without any license to our input? What did legally change that would require that license? No one asked you to: "We use data to make Firefox functional and sustainable, improve your experience, and keep you safe." (from the blog). What does that even mean? If you have specific use-cases in mind state them clearly, instead of this overreaching general license, that may or may not be misused now or in future. As of this ToS you may very sell my data to AI companies to "help me navigate the internet" which is not even part of the Privacy Notice protection.

Reinstatement your privacy guarantees in the ToS and be transparent about explicit use-cases.

Meanwhile, so long, and thanks for all the fish.


The blog does come from company officials and so you can show it to a judge and state "this is how you should interpret their ToS". It will be harder than if the ToS was clear, but the judge on seeing the ToS and blog differ is likely to come down hard to Mozilla for creating this situation. But you also need a good (expensive) lawyer to pull this off.


Even with a lawyer it's still a gamble if you will win - and in either case, the damage will have been done by then and no monetary compensation will undo it.


I haven't read the article. All I know is, Firefox changed their TOS.

> That clearly indicates some "other" future motive

It's training data, isn't it?

(It's always training data).


I was referring to Mozilla's past investment into advertising: https://blog.mozilla.org/en/mozilla/mozilla-anonym-raising-t...

To me that and the new ToS add up, why else would they remove the FAQ entry.


Totally fair, tbh. Stealing data for that purpose has already been normalized, so it's a much easier sell.


> How did you survive 26 years without any license to our input?

Might be a case of covering their asses in the context of services they provide for search suggestions etc. Those are not mere programs users run on their own devices, and they rather make use of services run by Mozilla, which probably leads to their lawyers seeing the need for legally covering Mozilla ass.

A less charitable interpretation is that they actually want to introduce terms for using the software itself, in a way that conflicts with the no-nonsense "no restrictions on use" approach of open source, and thus ignoring open source principles in preference for covering their asses against hypothetical risks, while somehow still trying to look like open source.

In any case I agree the blog post or the update don't make anything better. I don't think the post says anything substantial about the terms of use or their introduction. It doesn't, in concrete terms, clarify anything about the seeming conflict between the introduction of terms of use and the commonly accepted definition of open source (which includes no restrictions on use). The post rather seems like a classic case of trying to make things better with nice-sounding words rather than owning up and actually clarifying any ambiguity.


> Might be a case of covering their asses in the context of services they provide for search suggestions etc.

But they already have a separate policy for the services. Why do they also need a policy for the browser itself?


Maybe, but SEGA seems to muddy their own case as their official support FAQ section [1] states: "Will I still be able to play the SEGA Classics games? Absolutely! All SEGA Classics games and bundles you own will remain in your library, ready to be downloaded and played at any time."

Note the "you own" here that is in dispute with the Steam user agreement.

[1] https://support.sega.com/hc/en-gb/articles/29776767664145-SE...


xetdata is retired and recently became part of hugging face. I wonder if nfsserve will be still supported.

Are there other recommended NFS server codebases?


Examples will be based on this repo, I believe: https://github.com/TheSpydog/SDL_gpu_examples


This article from the main author of the API describes how the buffer cycling works: https://moonside.games/posts/sdl-gpu-concepts-cycling/


This rubs me the wrong way. Resource renaming is a high level concept, which was one of the features of OpenGL that all the modern APIs have successfully dropped. A modern low level GPU API should not do that.


It’s so convenient to have buffer renaming as an user of a graphics API. What’s not to like about it?


If it came in a yellow and not a blue bag, we should have known.


After some searching it appears that the joke here is that yellow bags are meant to stay in IKEA stores, while one can buy blue ones. So a yellow bag must be stolen.


Gamma should not have any effect on the alpha channel, which is linear by definition. The alpha channel represents the average coverage of (infinite) subpixels within the pixel. The color encoding of an object should not have any impact on the coverage within that pixel.

I recommend reading the technical memo "Alpha and the History of Digital Compositing" by Alvy Ray Smith [1] to get a better intuition on the matter.

[1] http://alvyray.com/Memos/CG/Microsoft/7_alpha.pdf


Gamma does however have an effect on blurring. And I suspect that because of gamma correction, applying a blur filter to a premultiplied image is (very subtly) incorrect.


Yes, I think the possibilities, in practice, for bad interactions between gamma-related and alpha-related operations are real.

"PS3 does sRGB conversion before alpha-blending, so the blending is done in gamma space, which is not quite right."

https://tomforsyth1000.github.io/blog.wiki.html


Applying a blur filter to a premultiplied image is (very subtly) _correct_, at least if the goal is to emulate what happens if you used a physical lens to blur the same image. Not only does postmultiplied alpha mess up the correct pixel values (as the original post shows), but even without alpha, you get a “halo” that is weird and unphysical.


I think corysama had the right of it, you need to do all the operations in linear colors, i.e.

original image -> convert to linear color space -> multiply alpha -> blur -> composite -> possibly convert back to sRGB if needed

The wrong way I meant was

original image -> multiply alpha -> gamma-correct-blur -> composite

where gamma-correct-blur = convert to linear color space -> blur filter -> convert to sRGB


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: