mbStavola

Cancer isn't one disease, any cell could potentially become cancerous and they can potentially become cancerous in different ways. A universal cancer vaccine will probably never happen, but hopefully we'll be able to have enough coverage of the more common ones such that cancer is effectively eliminated.

One of the main selling points of Kagi is privacy. It's featured on the main landing page, they have a page dedicated to it, and it's mentioned in pretty much every sales pitch they will make. Kagi's audience is also comprised of people who have that value as paying for a search engine means divesting from adtech surveillance.

So, it does not matter that "all search engines are problematic in terms of privacy"-- this one is marketed to not be. That's why people have concerns about how serious they're taking that committment and why people would hold them to a higher standard. It's also why a sale to a company which does not respect privacy is potentially a major issue, especially if current customer data isn't being handled in the manner they had expected.

You are right... up until maybe the second reply.

Vlad saw something critical of his hard work and wanted to put in the effort to clarify his stances and mend a relationship. I can absolutely understand that, your work is a reflection of yourself and nobody wants to be judged on misunderstanding. He might've even felt like he let someone who cared about Kagi down and wanted to make it right. Again, all understandable!

However, twice, the blog post author said they did not want to engage. At this point, regardless of how you feel about what was said, you should probably move on; they said their piece, you tried to engage, they rebuffed, oh well, do something else! To continue on is both incredibly annoying and a bit unhinged.

If Vlad absolutely felt like he needed to respond to this, he should've digested the main points of the original blogpost, reflected on them, and written his own blog post to a more general audience. Not necessarily in _response_ to the author, but understanding that more people probably feel this way as well and want to hear clear answers. Perfect examples of this would be an "Our stance on privacy" or "How we're ensuring Kagi's future," again factoring in the criticism from the author.

I write all of this as someone who pays for and likes Kagi. I think it's a good product, if a bit scattered at times. But the blog post does hit on some concerns that I have (privacy being the biggest) and seeing the follow up leaves a bad taste in my mouth.

Because "going down" doesn't necessarily mean _shutting_ down-- it could be a sale as well. Considering the stated attitude towards privacy, that should worry you if privacy is your concern.

This is actually really good information, thanks for pointing it out!

Just to be clear, this was one of the arguments of the Helix maintainers. I (sort of) agree and do think it's the _overall_ better approach in terms of general learnability and ease-of-use (bar WASM+WASI components, though that has it's own complexities).

However, my complaint was a bit more selfish-- for me personally, I'm a bit let down because I had gotten the idea in my head that I'd be able to use Rust from top to bottom. Following the discussion for the plugin system for a good while, many different options were on the table and I had gotten my hopes up for the ones which didn't pan out. Woe is me, but I'll live and I trust the maintainers to do what is ultimately right for the editor.

While I understood the maintainer's arguments for wanting to adopt a Scheme-like for plugins, I can't help but be a bit disappointed.

Helix being written in Rust meant that I felt very comfortable looking at the source code which gave me the confidence that if I wanted to implement something, I could reasonably do so. Furthermore, the idea that plugins could've been in Rust or Rust through WASM meant that I'd have an editor which was completely hackable in the least annoying way possible. Every time I have to learn one of these tool-specific languages I end up breathing a heavy sigh, spending a lot of time relearning things or working around weird quirks, and then ultimately giving up after writing the most basic version of what I want to do.

Ultimately, this is just a me problem and I really can't complain about something I haven't paid for or substantially contributed to. Maybe it'll actually be awesome and I'll change my mind completely, maybe they'll reconsider and add Rust-based plugins. Helix as an editor is awesome and I'm just going to have to trust the developers.

Rust is considering this under the name of "pattern types" [0][1]. If the full idea is realized, you should be able to handle strings and enums as well.

There is also a PR for a minimal implementation using a macro and targeting integers specifically[2]. It's experimental and there is a chance this doesn't get stabilized, but here's hoping it makes it through!

[0]: https://github.com/rust-lang/rust/pull/107606 [1]: https://cohost.org/oli-obk/post/165584-ranged-integers-via [2]: https://github.com/rust-lang/rust/pull/120131

The first response to the original post is quite possibly one of the most tone-deaf and unempathetic things I've ever read.

These stories always really get me-- to essentially raise an animal from newborn to adulthood, share years of beautiful memories and deep love for them, only to abruptly be reminded that at the end of the day, it's an animal. And, unfortunately, sometimes animals do things that can alter your life permanently, or cut it short, with seemingly little to no reason or warning. They can't explain why, and you can't reason with them. No matter how much you love them, they're just animals.

I can't imagine feeling that level of betrayal; he described his relationship with the warthog as basically father and son. The profound sadness he experienced, mixed in with all that raw fear... even just reading it is unbearable.

I'm really sorry this guy had to go through this. I wish his memories of Waylan didn't have to be tainted with the violence of the incident or the unfortunate, but understandable execution.

I think there is a lot of value in exploring this idea, even though it's a "big idea." Rust already has a history of taking PLT ideas system programmers don't care about and making it practical and appealing. This could be another one of those things where the effort pays off many fold and we all wonder why other languages don't do this. It could be as important as generics, traits, or even lifetimes, who knows!

That said, it is incredibly complex and a lot to grok. It's a completely alien concept to most programmers and there is still some confusion over what this feature even entails. As many people have said, it's questionable if you could truly unify some of these "effects" in a way that is useful or even coherent; you might have a sync and async version of a function that ostensibly does the same thing, but the implementation details could diverge a lot to the point where you might as well have just written two different functions. This sort of feature really needs an exploration of what it would look like in practice for existing, popular APIs, and not just toy examples.

I really am looking forward to the full RFC with the hopes that they nail the sweet spot here and we end up getting a nice effect system that helps me write beautiful, correct, and performant APIs (more so than I can already do today). At the same time, I also want one of the "correct" outcomes of the RFC to be "let's not do this at all." I worry with the amount of excitement and promotion this initiative has that this may end up being adopted by default. I really have no basis for thinking that, but I do keep seeing this pop up and a lot of people have valid questions and concerns that just go unanswered.

I'm not a Zig programmer, but this framework seems pretty nice! Honestly, a lot nicer than I would've expected from a language that explicitly targets lower-level dev[1].

[1]: Rust also has a focus on low-level programming, but has many higher level constructs / a more complicated type system so I'm not too surprised when I see nice web frameworks in that ecosystem

This is why I spent so much effort trying to procure a Brother printer that for my needs a while back; most printing brands are selling you subscriptions, overpriced resources, and/or some form of lock-in. Every year it gets worse too, so this headline comes as no surprise.

I'm incredibly happy with my MFC-L3770CDW and I'm so glad I spent the effort tracking it down.

Absolutely devastating-- Tachiyomi has been my go-to manga reading app for years. It's also one of the most polished open source projects out there and I frequently recommended it, even to those who don't even know what open source is. Thank you to every contributor who put their blood, sweat, and tears into each release of the years. I wish it didn't have to end like this!

As for Kakao, going after the maintainers like this was absolutely disgusting especially after they purged the extensions. I don't even think the music industry went after torrent clients, so they're somehow even worse. A part of me wishes they were able/willing to fight this with support from the EFF or some other org with a dog in this fight.

This is one of those functions I end up implementing in pretty much every single non-trivial JS project I work on. Glad to see some movement here.

You might be referring to Marina del Rey which has had much development in the past decade.

In the post they say they pay Google "multiple millions" of dollars already. Depending on their needs, the TCO of Oxide racks may end up being less than what they pay GCP.

This would require a live or weakened virus vaccine, it wouldn't be possible with mRNA-based ones.

If those are your complaints, I think they're probably doing okay.

Fun fact, Rust's human readable errors were inspired by elm[1].

[1]: https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-com...

Considering that Ferrocene has been open sourced (or at least, will be) and Adacore announced the (seemingly) closed source GNAT Pro for Rust, it looks to me that maybe the two organizations couldn't agree on a path forward regarding source availability and parted ways. Even this post mentions that the current version of Ferrocene needs to have some "proprietary partner work" scrubbed before a proper open source release can occur.

I wonder if it's possible to buy any extra stock DVDs/BDs that Netflix may have left over.

I think this is it, I'm just going to start the de-googling process. I'm sick of having to change apps because this company can't agree on a direction.

Awesome to see that the git history is preserved! Thanks for doing this-- I've seen a few of these kinds of merges where the easier route of squash-and-forget was taken and it's always a bit disappointing.

As for external contributions, well, you have at least one (incredibly minor) external contribution that I'm aware of. I'm sure that person is happy to see their commit survived the repo transition!

With the merge of iox into the main InfluxDB repo, are you preserving git history / external contributions at all?

As a recent adopter of Svelte, these changes are intriguing but I don't really have a grasp of how I feel about it quite yet.

One thing that I am definitely happy to see is the removal of $: as it should help Typescript users. Personally, I was quite sick of writing:

  let input = 'Hello';
  // ...
  let loudInput: string;
  $: loudInput = `${input)!`;

Instead of:

  let input = 'Hello';
  // ...
  $: loudInput: string = `${input)!`;

It's an incredibly minor thing, but when you do it 1000 times it becomes very frustrating. Having reactivity be rune-based should help TS avoid the syntactic confusion, bringing us to:

  let input = $state('hello');
  // ...
  let loudInput: string = `${input)!`;

Ignoring whether or not this would decimate legitimate site usage, I'm not even sure that requiring payment for access will solve the bot issue; those who are pushing a lot of the terrible bot spam and scams are also in the same group as those who would use stolen credit cards.

Wipeout was great, but I always preferred playing Extreme-G on the N64. I know the source for the third game in the series was leaked, but I'm still waiting for the original!

This is incredibly depressing news. Kris Nova will be missed dearly and remembered fondly.

Unfortunately assuming this doesn't mean that we start producing more CO2 since we'd have an effective method of curtailing runaway CO2 production. Instead of reversing, we may just end up slowing down the rate of increase.