691–700 of 750 posts
Earlier quoted context omitted.
They have 2800 employees with 5-10 reports per manager.
That's a really crazy number of employees considering they have one product that barely seems to change and is at best on par with similar products created by comparatively miniscule teams (Phabricator, Forgejo).
May 12, 2026 17:56 UTC INVESTIGATING
We are seeing elevated error rates across GitLab.com and GitLab.com services.
We are investigating the issue and will continue to update as we have more information.
May 12, 2026 17:37 UTC INVESTIGATING
We're investigating elevated error rates on GitLab.com. Some users may experience intermittent failures or degraded performance while we work to identify the cause.
We'll share another update as soon as we have more information.
------
Earlier quoted context omitted.
Whats right with it? Its slow, large, excessively complex and not that resilient to failure. You either want a bunch of NFS machines backed on to ZFS on nvme, with a central jumping off point that allows sharding (this is critical to allow one or more NFS server to fuck up and not kill access to everything else.) Or, pay the money and use GPFS
You are calling infra teams green for using ceph but then recommending hand rolling a sharded system on top of nfs? I think you have it backwards.
The problem with things like ceph-fs (and lustre and to a lesser extent, GPFS, although its not entirely comparable) is that the metadata store is your weak link. Ceph scales great if you have loads of large files where you're read/writing in parallel. (ie pulling thousands of PAR files or images, videos or binaries) it scale almost linearly with the number of object stores. It also works well when your writing to the middle of a file. (far fucking better than s3 like systems)
git is monster metadata eater. Everything git wise is a metadata lookup. That means that when you are running thousands of concurrent git ops on a distributed filesystem, your object throughput will fall off the floor. so you could have 100 ODSs all on 100 gig network with massive nvme stripes, but your global throughput will be shite because your MDS is the limiting factor. You can add more metadata servers, but then ceph is choosing how to shard, not you.
either way, deleting a large git repo, then all your metadata operations start crawling.
This means that you need to think about doing optimisations like keeping git inside a tar or some other container container that are pulled out, loaded in ram, operated on, and forced back as a binary blob. the result means that your thousands of metadata ops are reduced to two or three, and your back to being network bound.
So yeah, no I stand by my original position.
Earlier quoted context omitted.
I've used this text autocomplete to autocomplete me a Python setup and to autocomplete automatically running it. It that scrapes Hn it works. Ironically, it's why I'm here.
Why would you scrape HN when they offer free, generous API?
This stumped me for a while! what are the interpretations, infinite or 0?
Earlier quoted context omitted.
Whats right with it? Its slow, large, excessively complex and not that resilient to failure. You either want a bunch of NFS machines backed on to ZFS on nvme, with a central jumping off point that allows sharding (this is critical to allow one or more NFS server to fuck up and not kill access to everything else.) Or, pay the money and use GPFS
As someone who's in charge of close to an exabyte on Ceph, I couldn't disagree with you more. Done correctly, Ceph is extremely reliable, resilient, and fast. Once you get over the initial learning curve, dare I say, even a joy to work with.
But for metadata heavy operations, ie git, its not the FS I would choose. like lustre it can be fast, if your workload aligns with it's tradeoffs. but high metadata loads are not ceph-fs's strong point, (or many other distributed filesystems either)
Earlier quoted context omitted.
They have almost a billion dollars in revenue
And what good is that for the workers that still got laid off? Maybe software devs should have residuals.
Earlier quoted context omitted.
And what would that make yours? I think, therefore I am. You parrot, therefore you are... ?
So you're saying humans essentially do the same thing. We agree!
Earlier quoted context omitted.
> It all still functions with text prediction >> Wilful ignorance can't be fixed. As the saying goes, you can lead a horse to water but you can't make it drink. I can point you to ReAct loops and tool-calling and agent-based systems. If after being pointed those you still choose to be stuck on the "it's just text prediction" then that's a problem you are creating for yourself, and only you can get unstuck on a proble…
> Tool calling? The model emits JSON as it autocompletes the prompt, and the json is then parsed out and transformed into an HTTP call. No. Code assistants determine which tool they can execute to meet a specific goal. They pick the tool, the execute the tool (meaning, they build command line arguments, run the command line app, analyze output, assess outcome) as subtasks. And they do it as part of ReAct loops. If th…
And they do this - wait for it - by emitting tokens. Which are then parsed into a function call.
You’re just confusing a harness around an LLM for something more. And the core, the LLM takes input tokens and outputs the most likely next tokens. Those tokens might be interpreted into a tool call or anything else, but it’s still just token prediction.
If you disagree, explain what the actual difference is. I claim that LLMs “use” tools by emitting tokens which are taken and passed to a tool call. If you disagree, how?