rigelbm

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.

Sincerely,

The Gatekeeper.

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.

> This is a solved problem.

Hosting a gigantic monorepo for 25K concurrent users is so far from a solved problem.

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.

Hopefully the omission is fixed soon.

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.

That sounds a lot like a "immortality project", as described by Becker in The Denial of Death [1].

[1] https://ernestbecker.org/about-becker/beckers-synthesis/#:~:....

> 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?

Edit: Wrong fixed interest rate.

Never thought I would see "overwhelmingly" and "60%" used as synonyms.

To whomever might be curious, the author probably is talking about MUTYH-Associated Polyposis. If you have 2 of the wrong genes, you are very likely to develop colorectal cancer at some point in your life. That's why it's indicated that you test every year.

Google uses neither k8s nor Docker internally. From my knowledge, a change like this can take anywhere from a couple of minutes to a few hours to roll globally, depending on how much support was already in place.

AOC Agon AG352UCG6, 35", Curved, VA, 1440p, 120Hz

https://www.techadvisor.com/review/aoc-agon-ag352ucg6-369041...

I went from 2 wide screens to a single ultra wide, and I'm never going back. It's like you have two screens (well, more like 1.5), but they are optimally positioned, and there's no bevel in the middle.

It's worth mentioning that I use i3, which helps a lot organising all that screen real state. I can see how obnoxious it could be to use it with other desktop environments.

Bonus: It's awesome for gaming. Most games support it nowadays, and it's very immersive.

Edit: The monitor -> https://www.techadvisor.com/review/aoc-agon-ag352ucg6-369041...

Edit 2: Got it at a Black Friday for £550, which was a pretty good deal. I would probably not buy it at full price.

To be fair, if implemented correctly (read "as an opt-in"), that would have been a pretty useful feature. The browser already allows you to setup credit/debit card as payment options. Having an option to setup other payment providers sounds like a natural extension of that. The main issue is how they did it: as a forced feature screaming at your face, instead of something you have to setup yourself. On the flip side, I can see how difficult it would be discoverability of the feature if they just stashed it in a menu somewhere. Neither extreme is perfect. I would have erred on the side of not annoying most users.

Not having to care about performance (because hardware is fast) allows us to build more software than ever before. Although optimized software saves on computing resources, it is wasteful on the most important resource of all: Software Engineers' Time. Not to say it's not important, but saying we are wasting computing resources for "no real reason" is not fair. There are a lot of delicate trade-offs involved.