Readit Newsjustinmayer commented on Google's shortened goo.gl links will stop working next month theverge.com/news/713125/... · Posted by u/mobilio
About 60k academic citations about to die - https://scholar.google.com/scholar?start=90&q=%22https://goo...
Countless books with irrevocably broken references - https://www.google.com/search?q=%22://goo.gl%22&sca_upv=1&sc...
And for what? The cost of keeping a few TB online and a little bit of CPU power?
An absolute act of cultural vandalism.
In the first segment of the very first episode of the Abstractions podcast, we talked about Google killing its goo.gl URL obfuscation service and why it is such a craven abdication of responsibility. Have a listen, if you’re curious:
Overcast link to relevant chapter: https://overcast.fm/+BOOFexNLJ8/02:33
Original episode link: https://shows.arrowloop.com/@abstractions/episodes/001-the-r...
justinmayer commented on Llama.cpp supports Vulkan. why doesn't Ollama? github.com/ollama/ollama/... · Posted by u/buyucu
Ollama needs competition. I’m not sure what drives the people that maintain it but some of their actions imply that there are ulterior motives at play that do not have the benefit of their users in mind.
However such projects require a lot of time and effort and it’s not clear if this project can be forked and kept alive.
Benefiting users is definitely not Ollama’s first priority, as seen when this pull request was summarily closed: https://github.com/jmorganca/ollama/pull/395
Those README changes only served to provide greater transparency to would-be users.
Ulterior motives, indeed.
I’m one of the maintainers of Ollama.
It’s amazing to see others build on top of open-source projects. Forks like RamaLama are exactly what open source is all about. Developers with different design philosophies can still collaborate in the open for everyone’s benefit.
Some folks on the Ollama team have contributed directly to the OCI spec, so naturally we started with tools we know best. But we made a conscious decision to deviate because AI models are massive in size - on the order of gigabytes - and we needed performance optimizations that the existing approaches didn’t offer.
We have not forked llama.cpp, We are a project written in Go, so naturally we’ve made our own server side serving in server.go. Now, we are beginning to hit performance, reliability and model support problems. This is why we have begun transition to Ollama’s new engine that will utilize multiple engine designs. Ollama is now naturally responsible for the portability between different engines.
I did see the complaint about Ollama not using Jinja templates. Ollama is written in Go. I’m listening but it seems to me that it makes perfect sense to support Go templates.
We are only a couple of people, and building in the open. If this sounds like vendor lock-in, I'm not sure what vendor lock-in is?
You can check the source code: https://github.com/ollama/ollama
These comments would carry more merit if they weren’t coming from the very person who closed this pull request: https://github.com/jmorganca/ollama/pull/395
Those rejected README changes only served to provide greater transparency to would-be users, and here we are a year and a half later with woefully inadequate movement on that front.
I am very glad folks are working on alternatives.
Integrating ripgrep-all with fzf makes for a powerful combination when you want to recursively search the contents of a given directory.
I have been using a shell function to do this, and it works wonderfully well: https://github.com/phiresky/ripgrep-all/wiki/fzf-Integration
The built-in rga-fzf command appeared in v0.10 and ostensibly obviates the need for the above shell function, but the built-in command produces errors for me on MacOS: https://github.com/phiresky/ripgrep-all/issues/240
justinmayer commented on State of S3 – Your Laptop is no Laptop anymore – a personal Rant blog.jeujeus.de/blog/hard... · Posted by u/tosh
Having owned countless Mac notebooks over the last 30 years — starting from the PowerBook 140 up through the M1 MacBook Pro — I can tell you with confidence that Apple has made the same sleep change shenanigans mentioned in OP’s article.
It used to be that you could count on a sleeping Mac to stay asleep until you explicitly woke it up by opening the lid, pressing a key on the keyboard, or pressing the trackpad (or separate trackpad buttons — yes, those used to exist). Perhaps more importantly, you could count on the sleep function to have barely any effect on the Mac battery.
I don’t recall when, but at some point over the aforementioned three decades, Apple started changing the terms of this sleep contract.
It seems Apple decided that some functions should still be available when the Mac is “sleeping”, with no way to restore the previous behavior. As a result, random wake-ups are the new normal, replete with unexpected battery drainage.
I have seen modern MacBooks go to “sleep” with an 80% charge at night, only to be rendered dead with a 0% battery level by morning. Does something this extreme happen often? No. But it never happened before. And moderate battery loss while sleeping? That happens very often on today’s MacBooks.
Your mileage may very. And Apple probably continues to implement better computer sleep behavior than competing vendors. But I would argue that people who think MacBook sleep behavior is excellent… have never experienced how it behaved in the past. That behavior was superb.
But sadly, I imagine most people have never experienced that excellence.
As the maintainer of the Python-based Pelican static site generator for over a decade, I can say with confidence that my experience has been nothing like what is described in this article.
Most of Pelican’s code was written by other people, and yet I have spent almost zero time debugging that code, much less my own. After taking advantage of Pelican’s rich plugin ecosystem and adding a handful of useful plugins, I continue to be amazed by how much time this publishing system saves me, and how little time I must spend to keep everything running smoothly.
What it would take to accomplish this by writing HTML by hand instead… I simply can’t fathom it. But once again, that’s just one person’s experience, and YMMV.
Hi!
Thank you for helping me learn Japanese! :)
Can you please explain what do you mean by actively supporting JMDict? I hope I didn't make an attribution mistake, or misunderstood something. My understanding is that I can use those files in my project as long as I follow the license guidelines.
It makes me really happy that so many people are interested in it. :)
Sorry for the confusing language choice on my part. I just meant that I think it's great that your project supports JMdict. I think how you are using JMdict is indeed totally okay! :^)
Hey guys. I wrote LinguaCafe. I didn't know it was posted here, I've just read it now.
I didn't think this many people would be interested. I'll write a guide for Jellyfin, then add Italian, French and Dutch languages tomorrow.
As a credited contributor to the EDICT[1] Japanese/English dictionary, I am very pleased to see its successor JMdict[2] actively supported by this project. Bravo!
And as someone who now also speaks Italian, I am even more pleased to see that Italian support will be added tomorrow.
It is wonderful to see such a useful tool released as an open-source, self-hosted project. (^_^)
[1] EDICT: http://edrdg.org/jmdict/edict_doc_2009.html
[2] JMdict: https://en.wikipedia.org/wiki/JMdict
I have not yet tried either one, but here is the other project for those who want to compare and contrast them:
https://github.com/manaflow-ai/cmux