Agreed. I LOVE Kagi as a search engine - so long as it answers queries in under 2s with no ads, I'm a very happy customer. I don't mind if they flirt with LLMs, but if the LLM work detracts from the search work they will lose me as a paying customer. If the LLM work slows down search results I also lose the only thing I pay for - search result response time and correctness.
I've been a paying customer since 04/2022, and have the early adopter badge. I was easily doing 600-800 searches/month, and now I do 400-300 searches. I think that's the reality. More and more people are asking ChatGPT or whatever for search.
The best approach would be to treat "High Performance" as a system-controlled attribute like "Can Read Location Data"; the app can make a request for a performance profile it's designed against, the user gets final say-so, the OS records the user's decision and re-uses it for future launches.
This gives best of both worlds; users who need performance pick it, users who don't need/don't understand get to be kept safe by Apple's scheduler. Apps get back the state, so they can render a different icon or something to indicate "Hey we'll do our best but your hardware may not max out because scheduling wasn't built for this task"
It's not about safety but battery life. I don't think bombarding non-technical users with all kinds of tradeoffs is the best option, but this seems to be a niche app case. Maybe an attribute could work, but it's difficult to say if that guarantees anything. Phones can overheat too...
I love the idea! It combines social-network capabilities with in-person hangouts.
Let me know if you need a C++/Rust/Zig developer for backend work. The required infrastructure sounds simple to build if you outsource payment processing. The most complex component will be a reputation system.
Guarantees about those things are impossible to add after a language/community abandons them, and you can Arc::<RWLock<T>> your way to writing Java pretty fast. I hold that keeping the strongest-possible abstractions is the best decision, even if that means your average developer needs to learn borrow checking. I've started a career writing Java, spent a year with Rust, and when I came back to Java my data structures were 5x as useful. I could spit out features _WITHOUT_NULLPOINTER_ISSUES_ in hours where previously it would have taken a week.
Yes there is a skill gradient, but everyone who doesn't climb that hill is a fool and a weaker team member for it in my opinion.
6 months if you're a college-sophmore-level student doing it part-time (my own experience + numbers), I'd estimate 3-4 weeks if you were spending more than 3hrs/day on it and knew 2 other languages.
That would be my estimate as well. I've seem some porting between Go and Rust (both ways) where either way an experienced developer with some multi-language knowledge got up and running in a day, writing useful code in a week and being proficient enough to do normal sprint work in about another week.
It mostly depends on what you have in you brain, what you see when you look at code, and if you understand why you do what you do rather than repeating a trick and hoping it works, and I suppose that is a combination of theory and experience.
Hasn't the solution to this problem always been easy? Just encrypt before you type it into imessages; this applies to _all_ untrusted communication channels. Don't tell me base64-encoding/decoding is what's stopping you from having perfect security?
Exactly, if you're dealing with truly sensitive information where any leak is unacceptable, make your own encrypted blob. Don't trust any communication software to do it for you.
The concern typically isn't backdoors, it's bugs. I've had plenty of terrible experiences with Enigmail.
Brent is the engineer building all the real tech that a company in the Phoenix Project is building, and when the MC (a manager, Bill I believe) realizes this he re-directs resources so Brent can do his job without interruptions, ultimately saving the company. Excellent read, it's the first book managers are told to read when they use SCRUM/AGILE incorrectly.
