Since model size determines die size, and die size has absolute limits as well as a correlation with yield, eventually it hits physical and economic limits. There was also some discussion about ganging chips.
From what I read here, the required chip size would scale linearly with the number of model weights. That alone puts a ceiling on the size of model.
Also the defect rate grows as the chip grows. It seems like there might be room for innovation in fault tolerance here, compared to a CPU where a randomly flipped bit can be catastrophic.
Fully agree, responsible parents should not allow their kids (including teenagers) to use Shorts or TikTok. It is a shame that YouTube does not support blocking that crap. It is obvious "Don't be evil" is not Google's motto anymore.
You can create two Google accounts and parental control yourself. You can also use ublock or other browser addons, and of course, NewPipe. Youtube should have more settings for this, it's clearly going down the drain, but it's not like you can do nothing.
Honestly, it's one of the reasons I don't want to pay for Youtube Red, why would I pay for "no ads", when I still feel like I'm the product, because of my complete lack of control over the algorithm and user experience.
Squash merges are a hacky solution to the git bisect problem that was solved correctly by --first-parent 20 years ago. There are fully employed software developers working on important stuff that literally were never alive in a world where squash merges were needed.
Don't erase history. Branch to a feature branch, develop in as many commits as you need, then merge to main, always creating a merge commit. Oftentimes, those commit messages that you're erasing with a squash are the most useful documentation in the entire project.
Using git history as documentation is hacky. A majority of feature branch commit messages aren't useful ("fix test case X", "fix typo", etc), especially when you are accepting external contributions. IF I wanted to use git history as a form of documentation (I don't. I want real documentation pages), I'd want the history curated into meaningful commits with descriptive commit messages, and squash merging is a great way to achieve that. Git bisect is not the only thing I do with git history after all.
And if I'm using GitHub/Gitlab, I have pull requests that I can look back on which basically retain everything I want from a feature branch and more (like peer review discussion, links to passing CI tests, etc). Using the Github squash merge approach, every commit in the main branch refers back to a pull request, which makes this super nice.
As far as I'm concerned, the git history of a project is the root source of truth of why a change was made, at that point in time. External documentation is mostly broad strokes, API references, or out of date. Code comments need to be git blamed anyway to figure out when they were added, and probably don't exist for every little change. Pull requests associated with a given commit give the broad description of "what feature was being implemented or bug was being fixed" for a given change, but a commit message tells me what, specifically, during that work, triggered this particular change. I want to know, for example, that the reason this url gets a random value appended to it is that while implementing a new page to the site it was found that the caching service would serve out-of date versions of some iframe. It never made it out of dev testing, so it never became a full-blown bug, it wasn't the purpose of the feature branch, so it wasn't discussed in the PR. But the commit message of "Add some cache-busting to iframe" (even something that brief), can go wonders to explaining why some oddity exists.
Agree to disagree I guess, but IME, git history is good for low level detail, not for high level information. Git history is a poor source for understanding architecture, code organization, and other aspects of the codebase. More often, git commit messages tell me what changed - not why the change was made or who it impacted or etc.
Reading through git history should be my last resort to figure something out about the codebase. Important knowledge should be written somewhere current (comments, dev docs, etc). If there is a random value being appended to a url, at least a code comment explaining why so I don’t even have to git blame it. Yes, these sources of knowledge take some effort to maintain and sure, if I have a close-knit team on a smaller codebase, then git history could suffice. But larger, long-lived codebases with 100s of contributors over time? There’s just no possible way git history is good enough. I can’t ask new team members to read through thousands of commits to onboard and become proficient in the codebase (and certainly not 5x-10x that number of commits, if we are not squashing/rebasing feature branches into main. Although, maybe now an LLM can explain everything). So I really need good internal/dev documentation anyway, and I want useful git history but don’t care so much about preserving every tiny typo or formatting or other commit from every past feature branch.
Also iirc, with github, when I squash merge via the UI, I get a single squashed commit on main and I can rewrite the commit message with all the detail I like. The PR forever retains the commit history of the feature branch from before the squash, so I still have that feature branch history when I need it later (I rarely do) so I see no reason to clutter up history on main with the yucky feature branch history. And if I tend toward smaller PRs, which is so much nicer for dev velocity anyway, even squashed commits can be granular enough for things like bisect, blame, and so on.
How about possibly also failing for being too US centered, basically being an "internet portal" but mainly for the US. Sure Yahoo where _huge_ 2000, but it was never the main goto portal in Scandinavia where I grew up using internet from the mid 90s.
Here Altavista was the defacto standard for search until Google replaced. For the portal aspect of Yahoo, there were local alternatives with more relevant material.
Of course it possible to limit the number of virtual threads. A web server can have a limit on number of virtual threads too, and queue incoming request before dispatching to to workers (virtual threads).
As other have said, this can be achieved with a semaphore and the bulkhead pattern. You can also limit the number of number of connections.
I would expect any "production ready" web server using virtual threads having some sort of limiting. That must be the case right?
"This seems rather … procedural. Even though we get all the nice guarantees of working with side effectful functions in Haskell, the code itself reads like any other procedural language would. With Haskell, we get the best of both worlds."
Working with the IO monad is much more complex, especially if you want to use other monadic types inside that code.
> Working with the IO monad is much more complex, especially if you want to use other monadic types inside that code.
Yes, mixing other monadic types with IO can be a challenge. One possible solution to that is not just not use other monadic types inside the code. Just use a general-purpose effect system instead. I recommend effectful or Bluefin (the latter my own project).
For me it is if in a cosy position and doing something cognitively demanding. Fell asleep very often during my university studies reading literature. It can happen also if trying to learn something new technical at work, but only if I don't sit at a desk.
> The main benefit of Liskov's substitution principle is ensure developers don't need to dig into each and every concrete implementation to be able to reason locally about the code.
Yeah, but doesn't help in this context (enable local reasoning) if the objects passed around have too much magic or are mutated all over the place. The enterprise OOP from 2010s was a clusterfuck full of unexpected side effects.
I suspect that enterprise anything is going to be a hot mess, just because enterprises can't hire many of the best people. Probably the problem we should address as an industry is: how to produce software with mostly low wattage people.
