Many of the pieces of software which people claim are miserably slow are using one core irresponsibly. Usually because they're operating in a "only one thread can touch the UI" environment and that thread keeps blocking on everything.
Rotary vs fixed wing is more like GPU vs CPU programming. Within each you still need to understand the capabilities of the machine before you can go wide effectively.
2D might never die but modern 3D can be a compelling workflow for producing this kind of content.
The part that gets really painful with 2D sprites is animation. It can be a lot easier to model, rig and animate a 3D character and then place them into a special scene/camera arrangement for automatic capture into a sprite sheet.
Doing these by entirely by hand is a really difficult proposition in the current games economy.
> It can be a lot easier to model, rig and animate a 3D
Some do. The talking heads in Fallout were sculptures, for example (I think from paper, but cannot remember well).
But drawing vs rendering from 3D models can be either an aesthetic choice (Braid is an example) or an optimal choice depending on your workflow, expertise, equipment etc.
And in the current times, also Generative NNs I think were proven a possibility to generate animation.
> Doing these by entirely by hand is a really difficult proposition in the current games economy.
And yet, it's still very common in the indie space. I just played some Vampire Survivors, for example (although I don't think it's very good in terms of art direction, but that aside).
As for the 3d / 2d one, two games come to mind; one is Factorio (of course, it's very popular with software developers) where most assets are created in 3d then converted to 2d sprites. I want to claim it's great for performance given how much Stuff is on screen at any given time (just like Vampire Survivors), but then Satisfactory came out and showed that giant complex player-built factories can also work and perform well in 3D.
The other one is Hollow Knight where all art is hand drawn (digitally I presume but I don't actually know), but rendered in 3d (from a fixed perspective so it still looks and plays like a 2d game), easy parallax and high flexibility in the "spacing" of the layers and I'm sure there's other reasons too.
We are currently running nuclear at a capacity factor of around 91% in the US. Solar is somewhere around 24%.
1GW at noon vs 1GW forever. The area under the curve is what matters. Not the peak of the curve.
How much more would you be willing to spend to get 4x the nameplate capacity and to also get it whenever you need it?
The economics of a single plant are irrelevant in comparison to the requirements of the grid that it operates within. If someone could invent a source of power that magically scales exactly with the duck curve in Texas, I guarantee that would fetch a premium on the market, even if other economic characteristics are not competitive.
The solution to nuclear is to standardize the design and deployment process. France has demonstrated it can be done. Perhaps their engineers should be in charge of some new global standards body.
> Building a standalone agent product wouldn't work. Instead, it would force users out of their natural workflows and into a new app.
I am finding the opposite to be true with one of my clients. They explicitly want a new channel. The chat-style UI/UX is vastly preferred over their poorly maintained internal tooling.
I suppose if you are Stripe actual, most things would be well designed and more difficult to abandon. Most places aren't like Stripe.
The hard part is bringing everything that matters to the new channel, but it's certainly feasible to do this. I am doing it right now. We will soon be able to delete hundreds of wildly inconsistent cshtml views and related controllers in favor of a single agent tool that applies json patches. This will easily cover 99.9% of use cases. A manual json editor is retained for the rare case where we need some multi-megabyte merge operation.
If you don't have a clear mission to pursue with your tools, dissatisfaction is the next mandatory stop on your journey. You can change your tools as often as you want. If the mission is wrong it won't matter.
AI might be unique in that it can force a business into an inevitable failure state much faster than it would have experienced otherwise. From the perspective of long term economic activity, this might actually be a good thing. Most businesses will never be successful and this technology seems to be quite good at eliminating any ambiguity regarding that fact.
The real thing that is being tested here is the competence, discipline and focus of leadership. Executing well on AI in a team setting takes a lot of diplomacy and mentorship to get the nervous energy dealt with properly. Many failure modes with AI look like one lunatic employee going mad with a codex/claude subscription and slowly dragging everyone else into the cartoon fight dustball.
I had a meeting yesterday regarding deploying custom enterprise chatbot for a client wherein everyone was practically yelling over each other. We unanimously considered it an extremely productive call despite the chaos. I cannot imagine what is happening elsewhere. I like to believe the team I am working with is one of the better ones.
Until someone figures out an alternative to HBM I wouldn't call this hype.
The final effective yield for HBM based products is catastrophic compared to DRAM. But, the bandwidth, density and power characteristics of HBM are untouchable.
HBC (high bandwidth compute) seems like the most plausible successor.
High demand will only increase the incentive to improve the yield. If the incumbents don't want to increase output, China will happily undercut them eventually.
> it is mostly unacceptable for an enterprise product to have opinionated decisions about what authentication it works with. You either work with what we use or you are not viable as a product for our need. It's kinda simple.
I think HN would do really well if we took this in the more general sense (any product).
If the customer is asking really hard for something, maybe you should just take their money and move on. Forcing 100% of your customers to adopt or endure weird technological ideologies is not a path to happiness.
If SAML is taking you so much effort to implement that its complicating your sales & development process, you are either using the wrong tools or the wrong developers. It should not be this difficult if you make a genuine effort.
Not without attention or something approximating it.
The fact that gzip is relatively fast should be your first clue that something important is missing.
Gzip is great at predicting the next token for one very specific narrative. LLMs can predict next tokens for entire universes of narratives. Searching for the correct next token across this space scales ~quadratically with the input size. Gzip scales linearly. I can gzip a one terabyte file. Imagine feeding that much into an LLM. These are wildly different animals that happen to overlap in a very small way. Equating compression to intelligence looks increasingly silly to me.
If we must compare language models to compression, they are much more like jpeg and mp3 than they are gzip and flac. I can go fuck with a jpeg file pretty severely at the bitstream level and still have something resembling performance on the other side. Gzip cannot remotely approach this.
> Gzip scales linearly. I can gzip a one terabyte file.
In part because gzip only has a 32KiB window size, and I think it'd be at least quadratic within that window if you were going for optimal compression.
I'll concede the window part, but Gzip runs within the physical confines of a single cpu core and is typically entirely resident in local caches. The point is not just the quadratic scaling but also what it scales with.
Show me an LLM that can run at 300 megabytes per second. Even dedicated ASICs with weights burned in will never move this fast.
> if LLMs are used as compressors, how well is that expected to work
Quite well. This project[1], by Fabrice Bellard of ffmpeg fame, is quite old in AI years and uses an ancient LLM, but still beats xz by a solid margin.
A challenge as I understand it is reproducibility.
Normal LLM runtimes aren't typically fully reproducible even with same random seeds for distribution sampling, due to floating-point numbers, batching and such.
Though averaging over many runs could alleviate that I suppose.
While it would measure some aspects of intelligence, I'd argue it fails to capture other, more creative aspects.
Much like we get pilots comfortable in single engine aircraft before we have them fly around in 747s and AC130s.
reply