I think it could be because Google may offer them quite a bit longer hardware support. They had to go with some industrial SoC for the FP5 to get Qualcomm to offer even a half decent hardware support cycle.
Note that I didn't say that you should never squash commits. You should do that but with the intention of producing a clearer history, not as a general rule eliminating any possibly useful history.
Whether this is bad depends on your threat model. Additionally, you must also consider that other search engines are able to easily identify you without you explicitly identifying yourself. If you can't fool https://abrahamjuliot.github.io/creepjs/, you certainly can't fool Google for instance. And that's even ignoring the immense identifying potential of user behaviour.
Billing supports OpenNode AFAICT which I guess you could funnel your Moneros through but meh.
All the LLM-generated "top 10" listicles are grouped into one large block I can safely ignore. (I could hide them entirely but the visual grouping allows for easy mental filtering, so I haven't bothered.) Your weird top10 fake site does not show up.
But yes, as the linked article says, Kagi is primarily a proxy for Google with some extra on top. This is, unfortunately, a feature as Google's index still reigns supreme for general purpose search. It absolutely is bad and getting worse but sadly still the best you can get. Using only non-Google indices would just result in bad search results.
The Google-ness is somewhat mitigated by Kagi-exclusive features such as the LLM garbage grouping.
What Google also cannot do is highlighted in my screenshot: You can customise filtering and ranking.
The first search result is a Reddit thread with some decent discussion because I configured Kagi to prefer Reddit search results. In the case of household appliances, this doesn't do a whole lot as I have not researched trusted/untrusted sources in this field yet but it's very noticeable in fields like programming where I have manually ranked sites.
Kagi is not "all about" privacy. It's a factor, sure but ultimately you still have to trust a U.S. company. Better than "trusting" a known abuser (Google, M$) but without an external audit, I wouldn't put too much wight into this.
The index ain't it either as it's mostly Google though sometimes a bit better.
What really sets it apart is the features. Customised ranking aswell as blocking some sites outright (bye bye pinterest and userbenchmark) are immensely useful. So are filtering garbage results that Google still likes to return.
That whole situation was such an overblown idiotic mess. Kagi has always used indices from companies that do far more unethical things than committing the extreme crime of having a CEO who has stupid opinions on human rights.
I 100% agree with Vlad's response to this whole thing and anyone who thinks otherwise should question what exactly it is they're criticising.
I don't like Brave (super shady IMHO) and certainly not their CEO but I didn't sign up for a 100% ethically correct search engine, I signed up for a search engine with innovative features and good search results. The only viable alternatives are to use 100% not ethically correct search indices with meh (Google) to bad (Bing, DDG) search results. If you're going to tell me how Google and M$ are somehow ethical, I'm going to have to laugh at you.
The whole argument amounts to whining about the status quo and bashing the one company that tries anything to change it. The only way to get away from the Google monopoly is alternative indices. Yes those alternatives may not be much more ethical than friggin Google. So what.
you also lose the merge-commits, which convey no valuable information of their own.
In a feature branch workflow, I do not agree. The merge commit denotes the end of a feature branch. Without it, you lose all notion of what was and wasn't part of the same feature branch.
The only difference between a rebase-merge and a rebase is whether main is reset to it or not. If you kept the main branch label on D and added a feature branch label on G', that would be what @andrew@lemmy.stuart.fun meant.
You should IMO always do this when putting your work on a shared branch
No. You should never squash as a rule unless your entire team can't be bothered to use git correctly and in that case it's a workaround for that problem, not a generally good policy.
Automatic squashes make it impossible to split commit into logical units of work. It reduces every feature branch into a single commit which is quite stupid.
If you ever needed to look at a list of feature branch changes with one feature branch per line for some reason, the correct tool to use is a first-parent log. In a proper git history, that will show you all the merge commits on the main branch; one per feature branch; as if you had squashed.
Rebase "merges" are similarly stupid: You lose the entire notion of what happened together as a unit of work; what was part of the same feature branch and what wasn't. Merge commits denote the end of a feature branch and together with the merge base you can always determine what was committed as part of which feature branch.
Because when debugging, you typically don't care about the details of wip, some more stuff, Merge remote-tracking branch 'origin/master', almost working, Merge remote-tracking branch 'origin/master', fix some tests etc. and would rather follow logical steps being taken in order with descriptive messages such as component: refactor xyz in preparation for feature, component: add do_foo(), component: implement feature using do_foo() etc.
For merge you end up with this nonsense of mixed commits and merge commits like A->D->B->B’->E->F->C->C’ where the ones with the apostrophe are merge commits.
Your notation does not make sense. You're representing a multi-dimensional thing in one dimension. Of course it's a mess if you do that.
Your example is also missing a crucial fact required when reasoning about merges: The merge base.
Typically a branch is "branched off" from some commit M. D's and A's parent would be M (though there could be any amount of commits between A and M). Since A is "on the main branch", you can conclude that D is part of a "patch branch". It's quite clear if you don't omit this fact.
I also don't understand why your example would have multiple merges.
Here's my example of a main branch with a patch branch; in 2D because merges can't properly be represented in one dimension:
M - A - B - C - C'
\ /
D - E - F
The final code ought to look the same, but now if you’re debugging you can’t separate the feature patch from the main path code to see which part was at fault.
If you use a feature branch workflow and your main branch is merged into, you typically want to use first-parent bisects. They're much faster too.
That's the hard part: Who has claims to how much of the license fees. That's an extremely tough question to answer because it necessitates quantification of code contributions which is far from a solved problem.
By the fact that none of the apps I use day-to-day on my Android phone have viable alternatives on non-Android Linux.
I'd have to run Android inside a container on the mobile Linux which isn't the best experience and if I need to have Android running anyways, might aswell use regular android.
While it'd be cool to have, I don't really need a proper freedesktop userspace on my phone if I'm honest.
Android is also simply leagues ahead in mobile UI things.
I consider those measures to be included in "lockdown" but it's besides the point: The paper contains no evidence that those measures made it disappear, just that it disappeared.
Atemu @ Atemu @lemmy.ml Posts 63Comments 1,439Joined 5 yr. ago
I think it could be because Google may offer them quite a bit longer hardware support. They had to go with some industrial SoC for the FP5 to get Qualcomm to offer even a half decent hardware support cycle.