WebKit on GitHub
webkit.org
webkit.org
Anyways, I distinctly remember one of the instructions for merging WebKit in our internal wiki being something like "now type `svk merge`, but hit ctrl-c immediately after! You don't want to use the built-in merge, it'll break everything, but this is the only way to get a magic number that you can find stored in [some file] after the merge has started. If it's not there, try `svk merge` again and let it go a little longer than last time." A few hires later (I think possibly a year after) someone set up a git mirror internally to avoid having to do this craziness, which if I remember correctly, was treated with some skepticism. This was 2007, so why would we try some new-fangled git thing when we had svk?
A few times in my career (including this one) I have thought, "We are sure going to a lot of effort to maintain a modified copy of that code while also preserving our changes atop it as we sync, and this is exactly the kind of workflow that Git was designed to enable." Like, the Linux kernel dev workflow is all about different maintainers maintaining different branches and merging between them, and that is where Git comes from.
So in a setting other than Chrome I have tried out using Git to try to manage these sorts of situation. I have found in practice many engineers aren't comfortable enough with Git to have it end up helping them out tooling-wise. This is disappointing but also not too unexpected given Git's UI.
So what's the best resource for learning more about using Git?
Other version control systems exist. Why learn Git if you’ve already got one that works?
In general, I agree with your point but I think there's a very pragmatic argument that the open source world heavily converging on Git means it's worth knowing even if it's not your primary tool. In the 2000s that was spread out more with CVS, SVN, Mercurial, etc. also being good candidates depending on what communities you worked in but it's been quite a while since I've seen even Mercurial being used in the wild.
It’s not like git invented version control or even distributed version control. Stuff predated git and git wasn’t even the only solution that was coded together when BitKeeper changed license terms (personally, I wish Mercurial had won because it has a much better interface, but what won won and I’m happy enough with git to not really care).
Putting all that aside, systems and codebases have their own workflows for a reason. I’m sure the reason WebKit was on SVN for so long wasn’t because the committers weren’t willing to use git (we’ve seen in this comment thread revelations by former Apple engineers who admit that they maintained a shadow git-based codebase internally), I’m sure almost everyone involved uses git. But for whatever reason, there were blockers to migrating (and some of those are explained in the WebKit blog).
Now, as an outsider, I might think that waiting this long to migrate to git, a solid decade after it made sense to do so, is odd. But I don’t have the context. I don’t know the reasons why, and for what it’s worth, the git-svn mirrors seemed to be working well for the people working on the project.
WordPress, a much more active open source project, at least in terms of outside contributors, is also still on SVN. Like WebKit, most contributors work on the git mirrors rather than using SVN. As an outsider, I can also think that it’s ridiculous for that project to still be on SVN, but again, I don’t know the context. I don’t know the blockers, I don’t know the workflow considerations.
But I do feel confident that none of these decisions (or lack of decisions) were made because developers weren’t willing to learn git.
I’d rather just have several independent file system snapshots of a particular folder + logs. I’d like to rewrite history easily. But that ship has long sailed.
I can effectively use, I don’t know, probably the about 5% of git that I need to do my job. It could maybe benefit me to learn 5% more? The rest feels like a trivia rabbit hole, I have shit to do, and I already have a lot of difficulty with cognitive load and far too many yaks to shave daily. With that said, I have no strong disagreement with you, but I do want to add a bit of nuance: “learn how to use git” is extraordinarily open-ended, and one of the most challenging parts is to know where to even start. Or continued learning has any practical benefit.
A little less nuanced: I encourage everyone who will listen, even experienced devs, to use a GUI frontend. Not just because GUIs do ~90% of what you’ll normally need in a daily workflow (which is especially good for noobs who learn which things are important to know first). Also because the GUIs generally have really obvious cues for how to unfuck a mistake, which is the most difficult thing for people who aren’t already well adjusted to git. I use a git GUI for almost all of my version control tasks, and I’m much more effective for it.
I’ve learned more how to use the git CLI for an art project than I’ve ever needed to know for normal work processes.
(Self nit: bullshit made up approximately educated guess percentages)
It's not really. It seems like it is because it has a baroque CLI with a ton of commands and those commands all have a ton of switches and the same commands can do lots of different things.
But under that atrocious CLI git is very elegant and simple conceptually. Once you understand the underlying concepts (blobs, trees, commits, refs, index/stage) the rest flows naturally.
Now I've been working with it since its earliest days including contributing to it here and there, but I never really found it very hard to grok.
"Git from the bottom up" is dated but git hasn't changed conceptually since then. "Git for computer scientists" is another good one. But any of the tutorials that start with git's low-level concepts and build from there are where I'd start.
Neither! I appreciate your perspective, and wish I’d emphasized that more than I did.
One way or another, I've wound up becoming the git guy at work, and think I'm on the more proficient side of average. But, for most anything outside of commands I use daily (or can easily find in shell history), I'm off to the git docs or a search engine. Just about always, I know what I need git to do, it's just a matter of finding an incantation to do it.
To me, there are two pieces to learning git. The lower level is about git itself: understanding that commits are snapshots and the diffs are calculated on-the-fly, that cherry-pick is an automated version of diff and patch, rebase is like a way to compose cherry-picks. The other layer is about how the organisation uses git - like how to fork a project on github, push some changes to a branch in your fork, make a PR to propose those changes to upstream, why committing directly to main is a bad idea.
I never understood why that gets mentioned as essential for understanding git. A version control system has to be able to produce both all versions of a given file and diffs between versions of a file, but how it does that is an implementation detail. There are many options there: full first version with diffs to newer versions, full last version with diffs to older versions, variants of those with full versions inserted every now and then, mixes of forward and backward diffs (as is done in some video formats, if you see each frame as a version of a file), etc.
Of course, there may be performance reasons for choosing an implementation. I could understand statements such as “Because of the existence of merge commits, it’s easier to store full files, rather than diffs, as a merge commit would have diffs with each of its parent that must be kept consistent”, but the “understanding that commits are snapshots” claim isn’t about implantation details, but claimed to be essential to understand git.
I think git sits in a sort of uncanny valley, where it's possible to go a long way treating the tool as a black box (and you're totally right - snapshots vs diffs is an implementation detail), but in practice, to really "get it" it's necessary to understand a bit about what is going on under the hood. The problem space that git addresses is inherently difficult, in contrast git internals are quite straightforward.
So, a person wanting to learn git has two options: they can keep the hood closed, study the manual, and fret over all the complicated looking knobs and switches. Or, they can have a look under the hood, realise that there really isn't much to it. Most of those controls just aren't relevant to do what they need to do at the moment, and when a problem arises they have a much better idea of where to look for solutions.
In my experience, being a well-rounded software engineer (for instance able to collaborate with a team at work, and make the occasional PR to random outside projects) requires a certain level of git proficiency. At that level of proficiency, the black-box approach seems to have a much steeper learning curve than the look-under-the-hood approach.
At a less philosophical level: git is a collaboration tool, and people get hopelessly confused about this stuff when they try to collaborate without sharing a common language. "How do I email a commit?" is the sort of question I get asked occasionally.
So it can be hard to learn the hard parts by doing, because by the time you need to do them again, you've forgotten what you learned last time
Even small stuff like not knowing to enable rerere means that rebases have incidental complexity compared to, for example, outright recreating commits in another spot.
I disagree with most people about mercurial being "better" (I love my staging area), but doing stuff with git in practice can be super duper fiddly. I've found it's much nicer to do the right thing with stuff like magit though. I bet there is a great UI that is yet to be built for most people that makes it easier to do stuff like "updating old commits" or other things that you end up having to do through rebases.
I'm looking forward to doing more modernizing of things over time, but for now most of our work is trying to map SVN semantics and structures onto Git, and dealing with weird tooling issues.
Case in point, the Git SCM branch source that the Jenkins multibranch plugin uses; all we need to filter on is branch name, which you can get from `git ls-remote <remote>`, but because of the way it's designed it actually clones the entire repository (between 4 and 12 GB) and then checks the branch list. Nightmareish.
Still, a lot of stuff works a lot better, and now we have more and more developers and teams testing out or using Gitlab's features, like merge requests, and more and more projects trying to modernize their approach with CI builds and the like. It's a very exciting time.
https://imag.malavida.com/mvimgbig/download-fs/rockmelt-8383...
I was our build/release engineer. One of my jobs was keeping our code rebased on-top of Chromium.
It wasn't terribly painful but I could always tell when a new engineer joined Chromium because they'd inevitably rewrite some major component and there'd go my day porting our code onto the rewrite. (I did more than just resolve merge conflicts. I also took a first pass at updating our code before handing it off to the rest of the team.)
We were using git from the beginning. Chromium was using svn then, but Google had an official git-svn mirror and I worked from that.
It's been a while, but I recall that I switched us from working off the tip-of-trunk to working off of release branches. That became feasible when Chromium switched to its more frequent release schedule (2 weeks I think?).
Funny how our perspective on a browser and social media changed.
[1] https://is4-ssl.mzstatic.com/image/thumb/Purple30/v4/9e/0c/3...
Then fiddle with the SVK config to set upstream to the real origin.
OR have admins do a local checkout on the server for people to rsync, then do other appropriate config fiddles.
I worked in the Cocoa group when we migrated from cvs to git. But it wasn't exactly cvs, it was ocvs, which was an ancient forked version of cvs that handled certain directories (nibs) as tar files.
There was no direct importer from cvs to git, so we had to go through Subversion as an intermediate. This was Cocoa so its history was very long, but the earliest history turned out to be mangled, so some poor fellow was tasked with learning how to repair CVS history, only so it could be migrated to git.
Once we got to git our lives were so much better. I'm glad we skipped svn.
ocvs man page for any masochists reading this:
https://opensource.apple.com/source/cvs_wrapped/cvs_wrapped-...
I look at my main project and I'm fairly happy to forget about 90% of the branches I have hanging around and half the lifetime of coding it, and it's just 100k LOC.
(except I haven't. Why haven't I?)
If curiosity is what you're wanting to allow, keep the current source control system on ice, and move everything to the superior one at its current state + a few releases back. Save a decade or two.
It seems to me a version (sic!) of technical debt otherwise.
In extreme, you could just distribute a tarball of the decentralised VCS, hence all you need is the ability to distribute a tarball, which is a lower bar than maintaining servers for it indefinitely.
Thank you - first for your contribution to the product; and secondly, thank you for opening up a window into the glass wall that is Apple.
What's the background there? Why do they need a natural ordering?
Git doesn't have a concept of one commit being before or after another once you've branched, or any native mechanism for enforcing global state across branches.
I used SVN like this in grad school: data files included the SVN $Id$ of the script that generated them. This let you work around bugs and experimental changes. For example, you might hardcode a delay, realize it should be longer, and then eventually decide to let the experimenter adjust it on the fly. This is easy with sequential ids:
if version < 11:
delay = 50
elif 11 <= version < 29:
delay = 100
else
delay = params.delay
For example, we tracked the orientation and direction of objects moving on a screen. One update redefined 0° to be up/north/12:00 instead of the +x direction used before. The code which loaded these files checked the $Id$ value and rotated the directional data so that the entire dataset used the same definition.
In my company we have the CI server that automatically creates a new tag (sequentially) each time one pushes on the master branch.
I'm guessing the tooling around this used subversion's increasing commit numbers and it was easier to add a shim to git, than to rewrite or rethink the tooling.
..unless it fixes some important security vulnerability, one hopes..
> If a patch lands that regresses performance according to our benchmarks, then the person responsible must either back the patch out of the tree or drop everything immediately and fix the regression.
I imagine that a security hotfix would lead almost immediately to the second situation (perhaps as soon as the implementor had gotten some sleep!)
Imagine bisecting builds with parallelism of two, when one of them completes, there is a 50% chance that the build on the other side of the range is now uninteresting. If you are lucky and it is interesting, you’ve only saved yourself half a step in the bisection, because when running in parallel you sliced the range in 3 rather than 2. Adding even more parallelism just makes this effect even worse.
Someone can probably work out the math better than me but you can quickly see that for 2x build power you instantly waste half the results for very marginal gain.
Just comparing the big O should also tell you this, parallelism only buys you O(N) while bisecting is O(log N).
That's complete BS. Just go search for all the perf regressions in the issue tracker.
Perhaps the regressions in the issue tracker are for things without benchmarks.
Sounds like one can push in a security bug or performance increase that is fast because it is frankly completely broken, but wouldn’t be allowed to reverse the decision at least not without finding some alternative unrelated performance increase. Features or fixes that may obviously be worth an associated dip in performance can generally not be implemented.
Under these conditions if I knew of ways to improve performance without adverse effect, as a developer I would sit on them instead of applying them because I would need a stockpile of reserves to apply in case of emergency to account for unrelated performance degrading changes that absolutely need to be made. I would also work to make sure the benchmarks were lousy and irrelevant.
Policies like this can’t be written by people with any semblance of sense. Singular mindedness on one metric and extreme policies like this can kill development and subvert goals just as lack of discipline can. Everything is a balance. Weigh performance metrics heavily by all means, but absolutism leads to the absurd.
I guess as long as Apple holds its monopoly on keeping iOS device browsers exclusively on Webkit, it will stick around though.
Sadly having had years of an inside perspective on the competence level or lack thereof of decision makers in the non-revenue generating parts of their software business, can’t say this policy surprises me.
https://git-scm.com/docs/git-describe
$ git describe 593a2a5d0639b4b4f91ff6e6ffb64e72020f8fd8
v2.34.1-83-g593a2a5d06
$ git log v2.34.1-83-g593a2a5d06
$ git show v2.34.1-83-g593a2a5d06:branch.c
It’s basically the same thing as rev-list that they do, except more readable, with tighter integration to tags and with the result usable as a commitish.
man 7 gitrevisions
[0] https://manpages.debian.org/bullseye/git-man/gitrevisions.7....
Turns out it ultimately doesn't matter, and after nearly 15 years using git, I have not once cared about ordering of commits.
Funnily enough I have the opposite desire - I've worked in a VC system with "natural ordering" and it once led to an incident, where I visually compared two version IDs and said "yep this release has the bug fix". Turns out this is hard to do accurately for big numbers and I was wrong. I put a big warning on our ops documentation saying "never compare version IDs visually" with a link to the postmortem!
A lot of the benefit of git to me has always been the local development model, but the git-svn bridge made that largely transparent which I think lowered the pressure to change.
I think that the difference makes the tradeoffs using anything other than git, more obvious. I even held out myself for a very long time with svn vs. git and once I switched... I kicked myself for not doing so earlier.
But, like they said in the post... they did need a feature, which is core to svn (incrementing changelog ids) and a workaround in git. Minor in the grand scheme of things.
This was during the 90s in a software development company in Mexico. Good times!
Version 1.0 of svn was released around 2004. According to wikipedia the project was started around 2000.
(Sidenote: there seems to be cognitive dissonance that svn was released much earlier than git ... but svn was released in 2004, and git in late 2005. There's a less than two years gap in between, yet so many projects had been "stuck" with svn...)
So, I think inertia may have been a huge part of why adoption of svn was so good compared to git that has a steep learning curve, even today.
1: Of course, Linus Torvalds believes you can never do CVS right https://www.youtube.com/watch?v=4XpnKHJAok8 and there's a transcript: https://gist.github.com/dukeofgaming/2150263
This is what git does right. What git lacks for me is smoothness in interaction with the user. To use git well you must think like git. Which is kinda annoying when I prefer my tools to think like me.
When I moved from svn to mercurial it was absolutely painless. On my next company git was terrible experience. I am sure that git tools and flexibility are amazing for linux kernel and other projects of the scale. But probably are overkill for smaller stuff when a more friendlier user flow will be nice.
who made this decision?
Is it tho? Why wouldn't they just install git on their server? Now there is not many mainstream successful social hosting for svn. They acknowledge the choice of github is to attract devs. So it's as much about the software as about the type of hosting and web presence.
That's easy, and it's about 5% of the functionality which GitHub provides. Even if you're working entirely in private, the tools you'd have to build yourself to do code review, CI/CD, package management, security updates, etc. are a significant amount of work and that's before you get to things like Codespaces.
Are you sure? I can’t even use “go to file” on GitHub and stay on a selected ref, I can’t bisect and gob help me if I need to rebase before closing a PR. I made a comment elsewhere in this conversation that I think I might use 5% of git functionality. I like GitHub, but if I can’t use even that on their site I’m having a hard time imagining they provide ~20x value over git as underlying functionality.
That’s a ton of features which cause people to use services like GitHub or GitLab, and it’s not like you’re giving up any of the CLI functionality to do so. My point wasn’t that these services are perfect but rather that there’s way more to it than setting up a Linux box you can push to.
In fact, if github disappeared from the internet today, all but the largest projects could just set up an ssh-accessible box somewhere and continue work (code review and issue interfaces notwithstanding, of course), probably with 24 hours.
[1] I work in github-cloned repositories almost full time. And sure, I remember a handful of times over the past 4-5 years where it's been down when I wanted to push something. I had no idea it was 50x/year! And that's because "working in a github-cloned repository" doesn't, in fact, require much contact with github itself.
Not that code reviews of diffs over email are all that great.
Are you suggesting that Microsoft should intentionally opt not to comply with OFAC sanctions?
Do you know of any non-OFAC sanctioned entities that have made that choice?
Are you aware of any OFAC sanctioned entities that maintain public accounts on any other code sharing sites?
I note that Matthew Green's mirror and GitHub account do not appear to have been blocked, which would fit with the idea that there's more to this than just committing code:
It's like git, but even more connected to a centralized server.
I'm a heavy user of github every day and maybe 1 or 2 of these caused me any disruption whatsoever. Most of the time I think they created productivity boosts as people just focused on what they were working on instead of reacting to Github notifications about issues or PRs or failing tests or whatever.
> a rocky history of recourselessly banning users from countries that are sanctioned by the United States
This is likely a feature for companies, projects, and organizations who have (or want) to adhere to the same strict regulations.
Not being on github also has costs.
It's all about the tradeoffs.
Subversion was so undeniably superior that everyone was super happy and instant. Git took much much longer as the complexity vs. the win was much more debatable to people, so it's interesting to see this finally happening - I will miss linearly increasing revision numbers though.
Glad to see they're keeping with bugzilla though - for whatever reason I find the GitHub issue tracker super annoying. Presumably at least part of that is familiarity and/or change resistance :D
p4 and then git were easy sells for large projects. while subversion was faster than cvs with its local hidden copy, many operations were still dog slow as they'd scan the whole repository (this was often worked around by creating lots of small repositories with associated wrapper scripts). p4 and git on the other hand were designed to handle large trees with ease. so for something on the scale of an operating system, browser, or both... the difference in productivity was significant. (tens of minutes vs single digit seconds for basic operations)
export CVS_RSH=ssh -z9
sourcesafe was trash. i migrated a pretty massive project off of it (browser, os, several bsps) and like 30% of the revisions were irretrievable.
I was fine with CVS, and I'm fine with Git now. But, for some reason, I could never wrap my head around Subversion. Something about revisions-as-a-directory-tree just messed with my neurons.
Do you mean tags and branches?
Looking back Subversion was a bit of a weird project. It didn't re-evaluate what was wrong with CVS. It was more a "Let's try that again, but fix a few obvious problems". Subversion didn't really contribute with that much overall. We could do branches more simply, but most of us just replaced the cvs command with svn and continued to work as before.
I've only used it for automating build numbers. The number of commits on the main branch behaves, in practice, close enough to a monotonically increasing counter that it works 99.9% of the time without anyone thinking about it.
This is not an unusual or bizarre configuration, it’s a very reasonable configuration.
git rev-list HEAD | measure
One of those things I ran into recently was trying to find an equivalent of the following thing I do a lot of in *nix programming: Finding files of a certain pattern in grep, only list them, and then pipe that through something like awk or perl to find/replace in each file for each of those found files in that given grep. That's super easy in *nix. Powershell still doesn't have such an equivalent. It came of age in a time when everything as text and etc from unix principles weren't considered.
sls '(ERROR|WARNING)' *.log | %{$_.Path} | %{ (gc $_) -replace '\b\w+ \d\d?, \d{4}\b',{
[datetime]$d = 0
[datetime]::TryParseExact($_.Value, 'MMMM d, yyyy', [cultureinfo]::InvariantCulture, 0, [ref]$d)
? $d.ToString('yyyy-mm-dd')
: $_
} | Out-File $_ }
The above has mostly top-level pipes like the Unix equivalent. You could also start with Get-ChildItem and skip the Select-String, instead having a conditional within a ForEach-Object, which certainly can masquerade as awk:
ls -file|%{gc $_|% -begin{"Counting in $_";$n=0}{if($_-match'\b\d{4}-\d{2}-\d{2}\b'){$n++}}-end{"$n lines"}}
But, as you've identified, the pain in pipelines with native commands is real. No subshells or named pipes, naturally. All command output is parsed and re-serialized—anything binary, or with linefeeds, or UTF-8 without BOM is, as expected, silently corrupted. At least that's being worked on (https://github.com/PowerShell/PowerShell/issues/1908) -- the hindsight shell manages to have an immense amount of WTF locked in, turned into wontfixes by Microsoft's backwards compatibility. Tour the footgun arsenal: https://github.com/PowerShell/PowerShell/issues/6745
Oh, and the dreadful slowness. But is it worth it, to no longer fear self-pwn by file naming?
perl -p -i -e 's/term/replacement/g' | $(grep -rl term)
perl -pi -e 's/term/replacement/g' $(grep -rl --include=\*.sh term)
perl -pi -e 'use Time::Piece; s/\b(\w+ \d\d?, \d{4})\b/
eval{Time::Piece->strptime($1, "%B %d, %Y")->strftime("%Y-%m-%d")} or $1/eg' \
$(grep -ilE '(ERROR|WARNING)' *.sh)
ls *.sh -r -File | %{($_|gc) -replace 'term','replacement' | Out-File $_}
Some of us are bound to stuff that doesn't exactly work under Linux, for platforms such as commercial video game consoles or business
Bonus is that almost every git command that takes a "commitish" descriptor (git switch -c, git log, etc) can work with a `git describe` output as "commitish" name for a branch state.
From what I hear from my colleagues on the Chrome team, one of the first things they were delighted to do after forking Blink was to finally go around and comment the various confusing parts of the codebase. (And, no longer get requests to remove comments when trying to land a PR.)
The long term plan is for Scalar to either go away completely, or possibly just be a simple front end for setting up a repository to use certain optional git features.
They actually have a version of scalar in official git's contrib folder, and they are very actively working with the core git team to convert the relevant features into core git features in whatever way the core git team is happy with.
But of course the present situation is certainly confusing, and does not seem to be well documented. I've only picked up on some of this from reading the git mailing lists, and have no idea how to actually use scalar.
[1]: https://github.com/HimbeersaftLP/ios-safari-remote-debug-kit...
Git is as "distributed" as Ethereum at this point. You have a central repo on github onto which you push changes. Just because you have a copy of the main branch when you're working on stuff, it's no different from SVN.
Yes it has the capability to be distributed, and individual contributors can certainly host their own git servers and you can have as many remotes as there are contributors, but we aren't doing things this way are we?
- merging and branch maintenance is more rigid with svn, so teams tend to have dedicated release teams to handles this, instead of offloading this onto devs - most devs now are expected to handle git merging and so on, not so with svn.
i worked about 10 years with svn, and 5 with git, and just my exp only of course.
2. No
I think the real problem is the gecko and spidermonkey seem to be falling significantly behind on real user experience. This is ignoring the Firefox application itself which I find super irksome.
But as their gross built in tracking+advertising shows they are at least somewhat hurting for cash which does not help, and encourages gross stuff like said spam+tracking.
It doesn't help that the google folk keep shoving out half-assed specs for whatever some google team has decided they want/need with specs but little thought of generally of how to make more universal solutions. That just means you've got constant pressure to implement ever increasing numbers of standards just to stay in place - if apple (and technically MS in the past) has difficulty keeping up with the constant "spec" spam it's hard to see Mozilla managing in the longer term.
I'd say that the issue with Google's control of web standards stem from their surveillance capitalism business model.
MS's anti-user was in the form of ensuring that necessary sites would not work in other browsers (including the Mac IE engine, whose name I have forgotten, and therefore IE mobile). They didn't block ad blockers, etc because they didn't support any kind of extensions :D
Google is still doing this today.
> Pop-ups were universally reviled
Just as universally reviled as auto-start video, audio, and ads that move around the screen as you scroll today.
Also IE didn’t support any extensions for MS to block (that was a big argument from Mozilla)
Of course, Firefox and later Chrome came around, so in the end the Web kicked Microsoft's ass anyway.
I think it was a bit more general: "We want to keep a stranglehold on the Apis used to write general software". The ability to write software once for the web and have it work on web browsers on any platform was viewed as an existential threat.
However, the observation that they only developed IE as long as they were worried about that threat and then left it to rot afterwards is spot on.
Their strategy was aimed against their competitors interests, not their users interests. Microsoft in the bad old days still saw their users as paying customers and not just a source of data to be exploited.
Yes, exactly. This is what I meant with 'before the Web kicks our ass'.
They each do the vast majority of the dev work in their respective engines, so it's "control" only because if they want a feature they'll just implement it. Similarly neither implements things that aren't of interest to them - I can't speak for blink but webkit isn't going to oppose people contributing support for new features unless the implementation is not good (I assume this is a universal across all projects), or it's considered harmful (features that are inherently insecure - a la SVG raw socket access - or inherently harmful - e.g. new tech to aid tracking).
And yes, it is absolutely bigger than Gecko. No question. But are you going to tell me with a straight face that WebKit has the same amount of traction with third-parties as Blink? Because sorry, that’s not the case. That was the case for about 5 years, when post iPhone, everyone and their brother decided to use WebKit to power their mobile browser for whatever mobile OS they were building for (Android, BlackBerry, Symbian/Maemo/Meego, webOS, Tizen) or for whatever embedded systems they were designing for in-car systems or whatever, but after the Google fork became demonstrably different, the surviving players in that arena switched to Blink because Google was faster at iterating and easier to work with for upstream commits (easier does not mean easy).
> bite the dust
If I were ceo of Mozilla I would have cut off Firefox development like 5 years ago. It doesn’t look pretty, but AOL and Yahoo changed assets, they don’t look as ugly. But I also hate a lot of what they currently stand for, and they don’t really have assets. They’re like some NPR for web standards documentation, and while it is the best, it’s not very valuable. Google seems to have a lot of leading control while Mozilla is angry outside, with a megaphone, and red-orange dyed hair.
They’ve always been open source, they’ll die of natural causes.
What exactly out of this this you hate so much? https://foundation.mozilla.org/en/advocacy/
I think an open source foundation has to stand on the shoulder of a valuable product to get noticed. GNU has all of its things, Mozilla is an acoustic guitar busker playing “bulls on parade by Ratm” outside of a Barnes and Nobles.
Also Mozilla: We need more than deplatforming [of those we disagree with and already attempted to deplatform]
None of Mozilla's virtue signalling serves to bring back the Firefox of yore. Firefox has instead followed Chrome's heels at every turn to the point I might as well just use the real deal rather than a third-rate knock off.
I want a lean, effective browser that I can tailor to my specific needs and desires, and Firefox has been not that for at least 20 years.
Mozilla is (supposed to be) a collective of computer programmers, not activists and lobbyists. So fuck their advocacy, more accurately virtue signalling. All of it. The specifics don't matter. Fuck all of that noise. If they go back to making some good software I might be more supportive and respectful of them again, but not a step before.
FWIW, Firefox was released just under 20 years ago
But on the whole, Blink is still more similar to WebKit than it is to Gecko.
And even if they did, I think Gecko has enough of a fan base that it would live on for a very long time. NetSurf and Dillo are still around after all.
Brendan Eich IIRC said they looked into building Brave on top of Webkit but it was so hard to compile and embed across all three platforms that they went with Chromium. Same story with Gecko.
So that's another reason why we now have a Blink monoculture: because the alternative engines didn't spend any effort in making them usable by third party applications.
But it's been stagnating for years and it's still not a viable replacement for Gecko and Chromium (broken scrolling on scaled screens, WebAuthn is unsupported so I can't login to my email account, etc.)
In any case, if I recall correctly Eich's comment, the biggest difficulty was building webkit for Windows. The documentation was very out of dated, and it's understandable given Apple's focus on its OS. Even this GitHub says it's a web engine for "macOS, iOS and Linux".
So in short, no. If Mozilla dies, then there will be trouble and would need someone to carry on their work as the last remaining 'freedom' blessed engine.
though git-svn brings back sweet, fuzzy memories...
Presumably they migrated from subversion to git. And then hosted their bare git repository Github to serve as their "central" repository.
So, where was their svn repository hosted before this?
Maybe I just can't find it but what's the license used for Webkit? It doesn't appear in the repo.
We did this. We chose the obvious host. We like ordering commits chronologically, we came up with something for that. Ok bye.
Also given that GitHub is a somewhat universally understood host that people seem to like, and it has all that UI/development integration that people like it kind of makes sense to just use that. It also seems that having GitHub accounts is increasingly widely spread so contributors would not necessarily have to create yet another account with yet another service.
Idk how investors, or any powerful external entities think, but switching to Git in 2022 isn't net positive news.
It may be a subtle announcement, but it made it's way onto the forum of a Startup generator / Investment fund.