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

They should classify the ICANN and the RIRs as gatekeepers too, they are the biggest ones.


I've been a FOSS contributor since the early 2000s, I've stopped contributing and stopped maintaining projects completely in recent years, except for when I am paid, or where there is a problem that affects me directly that I can't workaround easily. I don't feel the FOSS community values that formed part of my identity are represented in the community much these days, and AI has made that situation worse.


They are likely pretty busy with their lawsuit against Vizio, which is going to trial in August and would set a very interesting precedent if won.

https://sfconservancy.org/copyleft-compliance/vizio.html


I think the Vizio lawsuit will set a more narrow precedent than the SFC wants. The tentative ruling the judge in that case made in December (not binding, but represents the judge's current understanding of the case going into the trial) is that Vizio has a contractual obligation to provide the GPL source code for the TV the SFC bought because the TV has an offer to provide source code upon request buried in one of the menus. The tentative ruling doesn't cover what happens if a company doesn't offer to provide source code. In the future, a company that uses GPL code without a source code offer could argue that third-party GPL beneficiaries have no grounds to sue because there's no contract being violated, and this would take another lawsuit to resolve.


That was my impression, as well, but I recently met SFC people and they assured me that the judge is taking the third party beneficiary doctrine very seriously, it‘s not off the table. Funnily, because Vizio objected to the tentative ruling, it has little meaning now.

The trial in August will handle the TPB stuff, as well. It will be streamed, btw.


Nice, I'm glad to hear that.


The OpenMoko Freerunner only had 128MB RAM, it was able to run a Linux desktop of the time, Englightenment/E16. There were lots of apps for it too. IIRC the cut down QtMoko distro ran best though.

https://wiki.openmoko.org/wiki/Neo_Freerunner https://wiki.openmoko.org/wiki/Applications https://wiki.openmoko.org/wiki/QtMoko

Before that Linux ran on the Zaurus too:

https://en.wikipedia.org/wiki/Sharp_Zaurus https://en.wikipedia.org/wiki/OpenZaurus


Indeed, the Reproducible Builds community is working on fixing non-deterministic build output https://reproducible-builds.org/


Build reproducibility checks usually use bitwise comparison, not hash comparison.

The Reproducible Builds project also wrote diffoscope, which goes quite far with helping identify where differences occur and how to fix them.

https://reproducible-builds.org/ https://diffoscope.org/ https://try.diffoscope.org/


Let’s say, for the positive case, hash comparison is significantly faster.


I feel like that is quite unlikely. Both the hash and bitwise comparisons read both files in both cases. In the not-equal case the hash reads the entirety of both files, so its slower than a start-to-end bitwise comparison, which exits at the first not-equal bit. In the equal case, both read the entirety of both files. Various other bitwise strategies can be faster than start-to-end, rdfind for example checks the start of the file first, then the end, then the rest of the file.


I think we’re not talking about the same scenario. I’m talking about the case where at least one hash has already been calculated.




There is a copy of it on Software Heritage:

https://archive.softwareheritage.org/browse/origin/directory...



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

Search: