Sorry, meant say that Blacksky is much more important than the metrics you point to, with more detail on that wiki.
They're the first alternative full stack, the first alternative AppView, and that is something that the author should have mentioned. However, it weakens the argument so they left it out.
"Number of contributors" has never meant impact. You wouldn't dismiss openssl or curl, ya know?
I've been mostly using emacs past 30 years ie. about the time when system memory wasn't any more constraint which while single user was about 8MB at least. But I did earn my living before that about 7 years mostly using vi as most usable editor in the system and that 8MB was luxury most of that time.
But even emacs IMHO was and is vastly superior, vi still had it niche fast small edits and especially before log based transactional filesystems. After power outage or bad brownout event system crash there was great chance you got to fixing filesystem with fsck (which did often take lot of time) and worst cases finally debugfs trying to fiddle bits that you get fsck fixing rest.
Bringing system up with old system could be tedious. Before you get system enough up single user mode and just root fs mounted you had to resort you way forward using those modest tools you had there. It was really great if vi did work, but it too required sometimes more memory than you had before swap was active. If not, then ed was your friend, ex is just vi without visual mode.
For a long time vi was also able to edit very large files. It did not require reading whole file in memory before it allowed editing as for example emacs did (or mmap's it memory later).
These days I use vi for quick edits like someone above mentioned and like it more than any later replacement (nano etc) if emacs is not there, not worth installing it for just quick change or when can't install on (embedded) or someone else's system for any reason.
Vi is often available also *bsd based appliances which I've been using like Junos, Netscalers, etc.
I disagree. Notable and impacting politics are often here and foster interesting discussions.
Everything is political, and nowadays everything has relation to tech. ICE is being supported by Palantir and many defense tech companies and that technology impacts and perfects the terror and abuse by ICE in Minneapolis.
It's important for us to talk about this, especially when it is uncomfortable.
Where else do we go? Reddit? The r/democrats is sold out to the corporate side. I’ve only found /democraticparty /marchagainstnazis /nokingsmovement /progressivehq and /NoKingsCoalition to be decent. But it’s more about reporting not action
For me, avoiding heap, or rather avoiding gc came when I was working (at work) on backend and web server using Java, and there was default rule for our code that if gc takes more than 1% (I don't remember the exact value) then the server gets restarted.
Coming (back then) from C/C++ gamedev - I was puzzled, then I understood the mantra - it's better for the process to die fast, instead of being pegged by GC and not answering to the client.
Then we started looking what made it use GC so much.
I guess it might be similar to Go - in the past I've seen some projects using a "baloon" - to circumvent Go's GC heuristic - e.g. if you blow this dummy baloon that takes half of your memory GC might not kick so much... Something like this... Then again obviously bad solution long term
The content of the stack is (always?) known at compile time; it can also be thrown away wholesale when the function is done, making allocations on the stack relatively cheaper. These FOSDEM talks by Bryan Boreham & Sümer Cip talk about it a bit:
Different people have different levels of internal monologuing or none at all. I don't generally think with words in sentences in my head, but many people I know do.
Internal monologue is a like a war correspondent's report of the daily battle. The journalist didn't plan or fight the battle, they just provided an after-the-fact description. Likewise the brain's thinking--a highly parallelized process involving billions of neurons--is not done with words.
Play a little game of "what word will I think of next?" ... just let it happen. Those word choices are fed to the monologue, they aren't a product of it.
If LLMs cannot reliably deal with this, how can they write reliable code? Following an instruction like "don't do X" is more basic than the logic of fizzbuzz.
This reminds me of the query "shirt without stripes" on any online image/product search.
Obligatory reminder that we used to live in a world where you could put "foo -bar" into a search engine, ctrl-F for foo on the top ten results and find it every time, and ctrl-F for bar on the top ten results and not find it.
Yeah, I've even had cases where DDG ignored my quoted string in the search. It's literally the whole point of the quotes but especially when it contains things like German umlauts it'll just accept any replacement letter for them. And yes, getting no results is acceptable, in fact it is the only correct outcome.
My eureka moment when I first started using Cursor a few weeks back was realising that I talking to it the same way I talk to my three year old and the results were fairly good (less so from my boy at times).
Yeah it's also kind of funny people discovering all the LLM failure modes and saying "see! humans would never do that! it's not really intelligent!". None of those people have children...
They don't. At least not for the duration that LLMs keep it up. They really don't.
If you want to pretend that being a 3 year old is not a transient state, and that controlling an AI is just like parenting an eternal 3 year old, there's probably a manga about that.
Maybe because none of those people are imagining children to be eternally stuck at that level of intelligence. At that age (regardless of being a parent or not) you can literally see them getting smarter over the course of weeks or months.
That's a great question, we were very concerned about the extra complexity Bazel was going to add to the daily workflows. We were able to hide most of it from most engineers. For the platform team however, the learning curve was brutal. In fact hired external expertise to consult us and answer our questions
