Rich Felker
Seeing the Base Browser Project https://codeberg.org/basebrowserproject/organization/ patches to remove even the smallest shit is mind blowing.
The clowns at Mozilla somehow managed to make functionality that should be a few tens or at worst hundreds of kB of js code into >18 MB of source code (size of the patch to remove it).
This is a project where literally everything is 2+ orders of magnitude larger than it should be, for no reason other than management incompetence.
John Breen
@dalias Long ago, I saw the pattern. There's Moore's Law, but then there's "Software Developer Law", which is :
"Software expands to consume twice the available resources, no matter how vast"
And developers always have the latest, fastest platforms.
For a while, it was encouraged because it sold new HW every year or two.
Now we can make a quantum leap forward by deleting the past 15 years of cruft from the stack.
Chris
@dalias at the rate this is going Sarah will have to ask codeberg for increased storage limits very soon 😅
Sarah Jamie Lewis
No joke this is something I am already concerned about.
Rich Felker
@sarahjamielewis @chrisvest I suspect the removals should be represented with commands that generate them from the source tree rather than raw diff files. This will make forward-porting/maintenance a lot easier too.
If not that, they probably call for some kind of out-of-band content-addressed-storage with just hashes in the git history. A git repo with multiple versions of files that are each tens or hundreds of MB is not viable to actually use as a git repo.
Rich Felker
@sarahjamielewis @chrisvest Using --irreversible-delete defeats the whole purpose of having version control. Referencing out-of-band content-addressed storage would be a much better approach because the history is kept and available as long as someone is hosting the files.
Sarah Jamie Lewis
I think `--irreversible-delete` can likely get us most of they way to something reasonable. It's not ideal in a few ways, but better than accumulating megabytes (I would have done this in the first place had I realized that singular features were going to total up hundreds of thousands of lines of changes)
I'm also on the lookout for any other patch management tooling that might exist, as we are already in a place where we have suggested additions to existing sets.
Rich Felker
@sarahjamielewis @chrisvest Oh, I think I misunderstood a bunch of this. So are you saying the patch files stored in the git repo would just contain file deletion actions without the contents of those files, so that re-expending to a full traditional diff would require access to the files, but they could be applied without that? I think that's correct and would be fine, and would make forward-porting the patches a lot easier too.
Sarah Jamie Lewis
> Using --irreversible-delete defeats the whole purpose of having version control.
I don't think this is true in this case? As we'd be using it on patch files targeting a secondary repository where there is defined history and so it should always be possible to reconstruct the full patch from a collection of patch files that omit the content of fully deleted files.
Unless I'm missing something?
G. Wozniak
@jab01701mid @dalias I don't work in web stuff at all, but I rail against this mentality all the time. Yes, I have a fast machine. No, I don't think it's a baseline.
I swear it's a mentality thing, where there are those like me who want to make products that allow people to enhance their lives, even if it's not groundbreaking. Then there are other who just want to make products in the belief there is great virtue in that product simply existing.
The latter never care about performance or resource usage.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.