nifoc

So it looks like they will be collecting PII (user_ipaddress) and they will also link these events to an account (account_uuid) and you just have to trust their "de-identification pipeline".

Will be interesting to see if they roll this out in the EU (especially with the "Share analytics" box being checked by default).

I used to have a (long) list of posts/comments that they refused to remove after I reported them. Most of these were (at least to me) _very_ obvious cases of being against the TOS (and the law).

I messaged this list to the admins. I emailed it to their support team. Never got a reply. Not even support answered my email.

I truly believe they just don't care.

Highlights blog: https://www.erlang.org/blog/otp-26-highlights/

I very strongly feel like this really should be opt-in instead of opt-out. They seem to want to do things the right way, but having opt-out telemetry in a password manager is something I really do not want.

And since Bing rasing prices affects their price so much, I'd argue that Kagi isn't investing enough into their own crawler/index, so that they can ultimately bring down the price of search.

Instead they're integrating yet another third-party (OpenAI), thereby rasing the price even more and tying their price to third-party API pricing even more.

They have updated the FAQ section of the announcement to directly address this (very, very valid) point:

Q. Didn’t you say in September that current subscibers will be grandfathered in?

A. Yes we did say that in September. We are sorry that we have to walk back on that promise and we should have done a better job at communicating the pricing change debate that has been going on for over three months with our community.

A lot of things changed in the meantime that we could not anticipate and predict, namely increase in search costs and popularization of generative AI which further increases the cost and making us lose even more money per user than before. That is not sustainable for a bootstrapped startup and we had to make the next best decision.

The decisions made (the price change and cancellation of grandfathering) is exactly the necessary step to keep us in the business of search, aligning incentives between us and users, and keeping the best interest of our users in mind.

We did the best we can, and we will still going to grandfather in everyone for up to a year on the old plan, and then on a special plan after that indefinitely (which still loses us money, just less). Discussion about this was long and hard and we made the best possible decision given our abilities and the circumstances.

This is so incredibly disappointing and basically confirms that we're (at least in part) paying for their AI experiments - something that I personally am not at all interested in.

Back in September they promised this[1]:

If such change to Individual plans is to occur, we plan to grandfather-in all early adopters (meaning all current and future paid customers, up until this change) allowing them to keep their existing subscription price as long as they don’t cancel it.

My guess is that they will focus on the "subscription _price_" wording. Technically the price didn't change, since you can still pay them $10. They "just" changed the terms.

[1] https://blog.kagi.com/status-update-first-three-months#futur...

I'm a happy Kagi customer, but going from $10/mo to $25/mo seems like a very steep increase. (I realize that much of it is probably driven by Bing more than doubling the price for their API results.)

One thing that feels kind of disingenuous to me is the number of searches that "a normal user" does in a month. The blog post mentions it several times, but they always reference numbers provided by Google or DDG. I have a feeling that the numbers for their "tech-savvy and heavy users of search" are _way_ higher than the averages of Google and DDG.

At my current usage, I would have to go with the $25/mo plan once my current subscription is up.

Highlights: https://www.erlang.org/blog/my-otp-25-highlights/

I don't know what's going on over at 1Password, but some of their decisions/statements are really questionable. A month ago they dropped this[1] in response to the 1PW 8 beta feedback:

I also wanted to respond to a specific part of @ShakataGaNai's original post about the multiple passwords. We've actually been recommending folks use the same password for each of their 1Password accounts. This might sound ironic given that the typical advice w.r.t. passwords is to use a unique password for everything. The difference is that your 1Password account password is intended to be the one password you remember, and so in theory, if you can only dedicate so much brain space to passwords, if you use only one password for all of your 1Password accounts, you'll be able to make that password stronger than if you have to remember multiple account passwords. So part of the new behavior encourages folks that direction.

More context can be found here[2].

[1] https://1password.community/discussion/comment/609753/#Comme...

[2] https://1password.community/discussion/122614/two-accounts-n...

Non-paywalled article: http://www.securityweek.com/cisco-acquire-opendns-635-millio...

SSH under OS X uses OSSLShim, which is wrapper around Secure Transport. I'm not exactly sure when they started using it for this, but it has been a while.

If you're seeing OpenSSL in the output, you have probably installed SSH via Homebrew.

Consider migrating to BSD, Plan 9 or something similar, if things get really out of hand.

I can understand suggesting to migrate to BSD, but Plan 9? Seriously?

And what's the purpose of the "Open Source Tea Party" picture? This surely is not the only picture of Lennart in existence.

The UI (and maybe other parts?) of AVM routers ("FritzBox") is written in Lua.

I'm under the impression that the Sprockets regression should not affect you in production, because your assets are precompiled.

Is that not the case?

How is this

> […] handing that task to Sprockets instead of resolving internally […]

even remotely related to performance issues because of random routing? You're mixing two issues that have nothing in common.

I think the important part is that the reverse-proxy should buffer the request, but I can't find anything about wether or not the Heroku router does this.

Since the Unicorn documentation explicitly states that you should not let it handle slow clients (everything outside your datacenter) directly, using Rainbows![1] might be a better solution.

[1] http://rainbows.rubyforge.org/

The "extend" to which the German PP wants to redistribute wealth includes a basic income guarantee (without any requirements). Everyone would get X € per month. Fun fact: They decided that they - as a party - want this, but have no idea how to finance it.

Yes, the Falcon patches work like a charm against p286.

Why don't you use PayEx? /s

I would like to try it out, but it looks like somebody has to invite me. Could you maybe do that? Thanks in advance! (daniel.kempkens[ät]gmail.com)