In many projects, especially open source, you being able to trust your code is less important than me being able to trust your code. So in that sense, it's not about best practices, but guardrails, and things that cannot happen.
For a potential customer deciding whether to trust a relatively small app (compared to Google and Apple) with their memories, these are useful numbers. 50% increase in paying customers this year. Nearly half a million registered users, with a 40% growth in the last 6 months. 5% of their users are paying customers. Revenue topping a million. That's stuff I want to know if I'm subscribing and uploading all my pics to their servers. I want to know if they'll be around, and my stuff is safe.
> So for folks that don’t know better, this is a very cool thing ente is doing. For folks that run businesses and know better...
Oh please. Perhaps work on not jumping to conclusions too quickly.
The transformer architecture is fundamentally unsuitable for local inference, while being efficient at scale. It's a fun experiment to try, but that's about it.
They seem to be making good progress, starting out from Trung Nguyễn's effort. This would be a massively impactful project, and could revive the Hackintosh.
Anything that can be written in Rust will be written in Rust.
I'm using Rust as a placeholder for a language with excellent performance and safety characteristics. It may not be a good thing, but there's no way around it.
It's fully functional now, but 2x slower than the original tsc and 10x slower than tsgo. But hopefully in a month or so, we'll get to C# and Rust targets and it should be able to compile itself to become nearly as fast as tsgo.
They're everywhere. But if you're short on time, buying the postcard is often easier than getting stamps and dropping it in a postbox.
One petty complaint - generally across the world, stamp design has nosedived. Compared to old postage stamps, they have terrible typography and gaudy colours. I've generally been disappointed when buying stamps to put on postcards. Old stamps were truly works of art.
I looked at his YouTube, and found a stream of industry gossip and beginner content like "web dev tutorials". I have nothing against such content and it may be useful and good fun to watch.
But does that say anything about this particular model? People have been using models effectively for web code since Gpt 3.x.
I would not trust AI on images. But I once had ChatGPT tell me that an MRI report was very likely to be incorrect based on the text, and offered a different diagnosis. Since it was semi insisting, I visited another doctor who made me do a retest. Long story short, ChatGPT was correct.
Again, this is just one single person's experience. So not worth much.
I was an avid reader during the web 2.0 days. Quite sad that his kind of tech journalism vanished; one could feel the decline of independent blogs month over month, while Facebook and Google were taking over the entirety of the web's traffic control.
At thousands of tokens per second, LLMs (harnesses) can start to do a broader tree search of possibilities even in inefficient token space. This unlocks capabilities outside programming.
Would prefer not to offend the author, but I do believe this article has very little for the HN audience. No new insight, and no numbers or new information.
Unrelated to the particular code above. There's a difference between writing code about or adjacent to a proven idea vs writing code in uncharted territory. I suspect that is what happened here. It's the same thing with say music and art. A lot of people today can play Chuck Berry.
Not the same. HttpOnly/Secure cookies were added much later and was not the default. They should have been inaccessible to JS by default from the beginning, and this policy has been a source of countless attacks.
> utility is of a standard that creates affordances for the insecure defaults
You could make the same argument about Cookies.
> as opposed to just designing it right from the beginning
And generally, it's quite difficult to design it right from the beginning because one would often start with the wrong assumptions. Most standards evolve, and it should be acceptable.
Lenses are only tested on bodies which are available at the time of manufacture. They might focus hunt on newer bodies, because of tweaks to AF algorithms (for example, the speed at which instructions are transmitted). Sometimes in ways that can potentially cause damage long term.
> at this point a lens for a mirrorless camera will have a USB-C port
Ideally, camera bodies should support firmware updates via the body in a non-discriminatory way, but until then I wish manufacturers support firmware updates via USB-C.
Looking at you Samyang Lens Station. I think users have been sufficiently upset, and they're adding USB-C to newer lenses.
Projects I maintain:
https://tsonic.org/ - TypeScript to native code compiler.
https://webjsx.org - A library for creating Web Components with JSX
https://tinqerjs.org - Type-safe, composable SQL query builder for TypeScript
https://bashojs.org - Lazy JavaScript Evaluator for building Shell pipelines.
github: https://github.com/jeswin