Same here. I'd feel a tad more comfortable if I could set an upper limit for the extra Chat credits that are used, but I guess it's hard to rack up 100s of $ when using it manually without noticing, so I'm not super concerned.
Overall I really enjoy the new functionality, and I've cancelled all the other GPT integrations I used so far in PyCharm.
There is Daniel Schmachtenbergers 'Metacrisis', which comes with its own little spin, but is probably close, and seems to gain traction. Could not find anything about him or the term on Wikipedia though, which I find a bit curious. Maybe just me being stupid and not looking right though
This is just for my personal taxes, no accounting involved. I just get all the relevant stuff together once a year. Of course it's not 10s of 100s of documents, but still enough so it would take me some time to get everything together manually.
Also it was just meant as an example, paperless is generally useful (to me) in situations where I need to access somehow related documents, like traveling and such, or searching my documents for some information. As I said, there are other systems and ways to do this, but for me this is the one that stuck.
You can just use your digital documents directly, and augment it with the few paper receipts that you might (or might not) still have to deal with. The main selling point is really document management (to me, anyway), the 'branding focus' on physical documents is probably a little misleading.
Can't speak for physical documents in general, but personally I really appreciate paperless-ngx for it's general document indexing/storage. Being able to scan and ocr physical documents (usually using the camera on my mobile phone) is very nice, but I mainly use it with pdfs that paperless automatically fetches, ocrs (if necessary), and tags from my email inbox, or which I copy into a specific local folder which gets synced with paperless.
Getting all my invoices from last year to prepare taxes is now just a simple query in the paperless UI, the result would be about 95% digital and 5% physical documents, probably. Of course I could do all that old-school using filesystem folders, but having all my documents indexed and searchable in a single place was definitely worth the (small) effort of setting it all up and keep it running.
Edit: also, looks like you have to be in the 'Team' plan for access. But who knows, if there is demand I'm sure they'd open this up, so maybe just ping them.
Yay! :) Thanks heaps! It's funny, 'rattler' is exactly what I need at the moment. I was about to write a rust app that downloads 'micromamba' and runs it as a subprocess. But this is so much better for what I try to do, being able to include everything in a single binary and calling rust code directly...
Thanks for sharing, very cool! There doesn't seem to be a whole lot of documentation on how to use it as a library, but looking at the code all seems to be nice and tidy, and it doesn't look too difficult to adapt to a use-case or two I have in mind.
Any plans to publish a release version to crates.io, or is it mainly intended as an internal tool for prefix.dev?
I don't consider myself a kagi fan, nor do I think their use of discord is 'impressive'. That would be quite silly. So you are wrong if you assume that is where my positive judgement comes from. I just make different value judgements than you -- ones I feel align well with my own, personal priorities and specific context. That doesn't mean I don't care about money, I hope you can see and accept that.
I just stumbled upon their discussion about pricing, and found it interesting how such a problem could be approached, and seeing their point of view and reasonings, and pros and cons for several options, and how its a really difficult problem for a young company like them. Compared to that, the discussion here feels a bit one-dimensional and flat, tbh. Anyway, just wanted to give a different, bit more emphathetic perspective to most of the sentiments in the rest of the comments.
Basically, I can understand why they felt the need to make the decisions they made, but I acknowledge that I'm in the minority with this. Doesn't mean I don't think I'm right and you're all wrong :)
I have to admit, I'm a bit disappointed by the mostly negative responses here, I wouldn't have thought this would be received as badly as it apparently is, by this here crowd.
I haven't followed along that closely, but I dropped by their discord every once in a while, and from the discussions I saw I felt Kagi was as open as they could be, trying to communicate the upcoming change(s), why they are necessary, getting user input, changing their plans accordingly, etc.
So, maybe my expectations where already 'anchored', but I find those changes very reasonable, and only if you compare it with 'free' is it expensive. But as we all know, 'free' doesn't necessarily mean no money is involved, just who pays directly and who pays indirectly. I'd guess the 'actual' cost is close to the same in both cases, minus some scaling that Google can do and Kagi can't. I'm willing to pay for 'unscaled', personally.
I've been using Kagi for about a year now, averaging between 700 and 1200 searches per month, so none of the proposed plans would break the bank, compared to what I've been paying so far. Tempting to choose the legacy plan for a year, but I'll probably just go for the 'ultimate' one, the yearly plan, to support a service I really really don't want to go away.
During the time I've been using Kagi, I hardly noticed it. Which I think is brilliant. There was no annoyance, in probably 90% of my searches I don't even have to scroll and one of the first 5 results is what I'm looking for. No ads, at all. In my calculations, that are at least 700 interactions with software that are fast and to the point, with very little chance to annoy me, reliably, every month. And those interactions are very important for me to do my job. I value the time and piece of mind that are connected to those 700-1200 interactions.
So -- as a professional -- to me this is worth $25 a month, easily. I dislike subscriptions as much as the next person, but to me it seems obvious that the context matters here: if it's for a software, then I really want the option to pay for a permanent license, and I think it's fair to pay for (major) upgrades if I want them. Companies that lock you into their product and you can't use the data you created with it anymore -- unless you keep paying -- are acting morally reprehensible in my view.
But on the other hand, if the service that is provided has a considerable cost for every user-interaction, then, well, 'pay-per-view' is justified. If I use it more, then I have to pay more. I don't want companies to make a loss because I'm using their service, esp. if I like their service. And I even want them to make a healthy surplus. A business model where heavy users pay more and are not subsidized by low-volume users seems like a good thing to me.
If a search costs them, say, $0.02, then I'm happy to pay $0.04 for it, it is what it is. Of course I'd want them to be efficient, and save as much cost as one can reasonably expect (maybe some of my searches could be answered from my personal cache?), but from what I see, kagi hasn't been buying villas and yachts from my money so far, and I don't think they'll be able to in the near future with their new pricing structure.
What kagi was doing here ticks all of my boxes, I don't think they have been 'baiting & switching' me, and I trust their reasoning and calculations unless someone has good evidence that shows I shouldn't.
I'm doing the same. It's also quite nice for de-duplication, a lot of operations on our data happen on a column basis, and we need to assemble tables that are basically the same, except for one or two computed columns. I usually store all columns in a separate file, and assemble tables on the fly, also memory-mapped. Quite happy with being able to do that. Not sure how easy that would be with parquet.
I think this got shared on hackernews too early for this to be ready, the author says somewhere else that packaging and publishing to app store is in the pipeline if I recall right.
I think there is always a danger, for every language, when you install a 3rd party dependency from a package repoitory. But usually this is restricted to the runtime of the application that uses the 3rd party library (and maybe, depending on the language, the code-paths that are executed).
That's a difficult enough problem to deal with already, but with Python, it's possible to execute code at install time of such a 3rd party library (basically, when you do a 'pip install stuff'). So, you might never have run the application you installed, but you'd still have executed whatever malware was hiding. This is not the case for a lot of other languages. Also, Python allows the execution of code when you have an `import stuff` statement, which is also not the case in other languages, often. But this is not directly related to this, just another 'Python-specific' attack vector.
Not sure what you are saying, have you read the article further? It also says that what you call 'established media' uses the same strategy. Either way, i think Scott renders a good argument overall, as usual, and I don't really see how your point invalidates any of it.