As a Kagi long time user, and a Linux die-hard, I don't get the obsession with having everything being open source.
This will sound overly critic (sorry before hand), but what do you want the source code for?
Do you read the source code of every open source applications you use? Do you compile all of them to make sure there are no shenanigans? If you do, congratulations, you are a member of a very niche group of people, that I'm not sure companies will be targeting.
I pay Kagi because I don't want to be the product (via no-privacy ad businesses). Not because I hate ads per-se (although I really dislike them), but because ads-funding incentives are contrary to make their products better. I like to know that Kagi's only incentive is to make their products better, so that I will keep paying for them.
I more than welcome that now expanding to browsers. I would get absolutely 0 value from it being open source, and so would most users I would guess, including probably you, even if you are fundamentally against closed source software, which you have the right to be of course.
Meanwhile Europe still doesn't have a cloud hyperscaler, so most of these €200B will end up in the coffers of Amazon, Google and Microsoft, the real winners.
Error handling is really not an issue that needs fixing in Golang. That being said, I wish Golang had an assert key word as a shortcut to "if cond { panic }". A lot of those "if err != nil" in the wild should really just be assertions.
You answered your own question. I don't want my great-grand-children to be the first to have a great Linux Desktop. Ideally, I would like to have it now. Unfortunately, as things go in capitalism, the easiest way to accelerate development of something is with money.
Imagine you did have an idea, put a lot of effort building it, just so that some random person takes a dump on your work. It wouldn't be nice, would it?
Unnecessarily harsh and misses the point that this is a new VCS that brings valid new ideas to table. As with any new thing, if it's not for you, it's not for you.
SBArbeit, ignore this kind of comment. Not because it's not valid feedback, but because it isn't worth it.
The proposed ToC looks amazing, and I can't wait to get my hands in this book. One thing that seems omitted though, which can have significant impact in performance, is I/O. That would have been a nice add-on.
Critically missing from the text are the definitions of "external" vs "internal" bootstrapping. The author left us all guessing, and by the look of the comments here, no one has figured it out yet, me included.
Nice product. It's always good to see more choices in the authz space.
I think Ory (Kratos) is a critical omission in the comparissons page, given the Ory suite seems to be one of the top alternatives currently for OSS authz/authn.
I stopped at "Good Programmers". Seriously though, it would have been perfectly fine to phrase it as "Exploring the correlation between Code Style and Competitive Programming Performance". Everyone knows that competitive programming has constraints (e.g. small time limit, throwaway one-off deliverable, no collaboration) that favours a style of coding that you wouldn't normally find, for example, on a business setting.
It's not clear whether this paper was accepted at the conference, but if it was, it is a testament to the low bar of the examining board. I like to follow the "if you don't have anything nice to say, don't say anything" mantra, but this paper deserves an exception.
Not A Lawyer. The Court of Appeals decided to take this case to trial because it is novel and will probably serve as precedent for future cases. There has been no decision on liability and what not. Author is a bit overreacting. Sure, it's annoying and all to have to defend yourself. But seems unplausible that a decision would be made to ignore license for liability given all the repercussions, not just to this case, but to the software industry as a whole.
That means 1y6m per job? I know it might not mean anything relevant, but it might look like job hopping for the hiring companies. Also, market is pretty tough right now, and flooded with experienced people from big tech. Good luck on your job search!
Isn't there a wide ecosystem of options between "I have to physically go to DC to configure new server" and "Storing everything in EvilCorp Public Cloud"? There are several hosting providers out there that offer anything from bare metal servers, to VPS, to OpenStack, to Kubernetes and beyond. Going into a DC physically to configure a new server sounds like the hardest option possible short of them managing the DC themselves.
I don't feel like the author gives enough rationale for the choices made. Making the decision so binary (Hard Way vs EvilCorp), it becomes easier to justify "Hard Way". I think if author accepts that there could be other options, maybe that will help with the problem stated.
Actually, I thought about it twice and I retract what I said about this specification being pointless for building tools compatible with protobuf. Reasons:
* The language itself is unlikely to change much given it's been public for so long. A non-official spec that captures the current implementation is probably going to survive for some time.
* There's no official spec (which I would prefer) for me to base my tool on. This spec is about my only choice. The more tools targeting this spec, the hardest would be for Google to break compatibility with it, reinforcing my previous point.
I will keep the parent comment for context, and I don't retract the fact that I think the title is misleading. Otherwise, great work!!
Echoing some of the sentiment here: although this was certainly a great effort and the result is awesome, that is NOT The Protobuf Language Specification, for as long as the maintainers of the Protobuf (protoc) project don't agree to follow it.
This is certainly The Buf Language Specification, which is useful in itself. Specs are like contracts. If I were to build a tool to be compatible with Buf, I would definitely aim it to work with this spec.
The problem is that the Protobuf project simply didn't sign this contract. Whatever it says is, sorry for the choice of word, a bit pointless if I'm trying to build a tool compatible with Protobuf, specially around forward compatibility.
The industry does need better tooling around protobuf/efficient RPC, and being dependent on a single company (i.e. Google) is definitely not healthy. I hope you guys succeed in what your are trying to doing.
Note about the title: I really clicked the link to learn about how to use cloud metrics to fuel my monitoring needs. Imagine the surprise with what I found.
> As a developer I prefer Jira over every alternative I've tried (Clubhouse, Trello, GitHub Issues, and Monday.com).
I also prefer JIRA, but that doesn't mean I love it. It just so happens to be the only available product with most of the features I need.
That being said, its UX is beyond terrible. The moment something else appears that covers some significant portion of its feature set, I can see a lot of people making the switch.
I think one of the biggest problems of competitors is to think that JIRA is bad because it's complex. Therefore they position their offerings as a simpler slim down version of JIRA.
Big news: it is complex to manage complex projects. JIRA has, I think, the right level of complexity and flexibility to tackle that.
If any competitor reads this message: please, go complex!
In London it's common for people to take 25y~30y loans that are fixed for only 2y~5y. 5 years ago interest rates were 2.5%. If rates go above 10% this year, does that mean a sudden influx of houses in the market because people can't pay their houses anymore?
This will sound overly critic (sorry before hand), but what do you want the source code for?
Do you read the source code of every open source applications you use? Do you compile all of them to make sure there are no shenanigans? If you do, congratulations, you are a member of a very niche group of people, that I'm not sure companies will be targeting.
I pay Kagi because I don't want to be the product (via no-privacy ad businesses). Not because I hate ads per-se (although I really dislike them), but because ads-funding incentives are contrary to make their products better. I like to know that Kagi's only incentive is to make their products better, so that I will keep paying for them.
I more than welcome that now expanding to browsers. I would get absolutely 0 value from it being open source, and so would most users I would guess, including probably you, even if you are fundamentally against closed source software, which you have the right to be of course.