torginus

That's a really good point. There are types of people (like ones who are really anal about following QA/release processes, folks who are insanely paranoid about security), that I've found to be really unpleasant to interact with, but with time, I've come to realize them being exactly like this is what allows me to sleep soundly at night.

You are not really narrowing it down

I don't get the hype. AVIF is marginally better than WebP which is marginally better than JPG. AVIF is also free, and since it's literally the I-frame of an AV1 stream, it can be decoded directly on the GPU, meaning you don't have to store the decoded picture in memory.

JPEG XL can't be decoded in such a way, and tons of people still use JPG.

> Ultramarine 1 Flash is Fable-class on knowledge work spanning finance, law, consulting, and operations. It is also 60x cheaper than Fable.

This is not a general purpose model, it makes sense to only bench it on tasks it's supposed to be good at, which is to help out finance-related knowledge work.

Other posts made me understand what it actually measures and why is it meaningful - it tells you if you lend this entity money at the govt bond interest rate, will this entity be able to pay back more or less eventiually?

Obviously a financially rational person wouldn't lend money with worse returns it can get from the government risk-free as that would be charity, hence these are considered 'junk'.

However well intentioned your post may be in explaining this, it misses my point.

There's no single oldschool look, as people writing software renderers didn't have a sanctioned way of doing so - a lot of them weren't even using triangles, or were using a mix of techniques.

You are describing how to make a game look like the PS1 games, but the PS1 actually had a - somewhat flawed, but unique - GPU which kind of forced the limitations you outlined here, and forced a singular way of rendering.

That wasn't really true with Quake or Duke3D or the PC in general. You just drew to the screen with whatever technique you chose, which resulted in a unique look for each game.

I welcome AI based PCB layout. Routing PCBs by hand is a tedious slog of educated trial and error. Essentialy the kind of tedious knowledge task like reverse engineering, that AI is very good at.

I have some friends who work on designing wafers and they told me compared to autorouting, hand layout is always better, with quality asymptotically approaching a certain ideal with hours invested.

Based on how many engineer-hours you can put in, you can get a single or even double digit increase in silicon density, it's just that nobody actually has the manpower to actually get close to that ideal, but the difference is very noticeable between 'tier 1' and 'tier 2' manufacturers, the former of which can afford an army of highly educated engineers who will slog through this task, with the latter having to decide where to spend the effort.

This is one of the reasons why second or third generations of CPU architectures perform better even on the same or very similar process node, because this logic optimization builds up.

I think there's more to it. In Quake, the software renderer decides the color of each pixel, based on running some code on the CPU, which can do anything. GPU rasterization is far more standardized, with standards defining how each triangle ought to be sampled at each pixel coordinate (and the fact that you're sampling triangles in the first place).

The whole process is standardized with GPU rendering, leading to ways of rendering and content authoring that's quite different from how things used to be, and while definitely possible, modern 'retro' games often render like GPU accelerated games and just disable texture filtering, which doesn't quite give you the look.

He mentions Build games, which are not strictly polygonal.

While general purpose computation exists on GPUs, and the standard rasterization pipeline can be implemented in software, graphics cards have pushed people towards a 'look and feel' which comes partly from standardized data structures, content authoring and rendering approaches, that have made games feel samey.

Whereas with software rendering, essentially you have an array of pixels which you can set to a certain color, and the rest is up to you, which made devs come up with unique ways of rendering and authoring content.

The intricate level designs that were made possible with BSP based tools and are basically 'free' to render in software, had hell of a time making the transition to GPUs, as they rely on traversing the tree while drawing pixels, whereas for the GPU, you need to submit a list of triangles (unless you go GPGPU)

Personally, I used to use a hacked PSP in 'portrait' to read. It fit really well in my hand and I could operate the shoulder button by squeezing it against my palm. It worked really well, and actually I just took it out of the drawer, and it's still pretty comfortable to operate.

Wonder why they never innovated on the clearly limited smartphone touch controls.

I would also try going the other way, and build transreflective color LCDs - those don't have latency or refresh issues, like these weird hybrids.

They also consume nonzero (but very little) power, which is a moot point imo, since most Android eInk tablets run the computer in the background, which drains the battery anyways.

Personally no. I've been reading a lot on LCD screens (PDAs if you know what those were), way back before eInk existed.

First, eInk used to be glossy, and not backlit which sucked, since you needed a light source to illuminate it well enough, but not so much that it shone on the screen and caused weird reflections.

After they added backlight, it became much better, but I'm not sure how it's better than an LCD (I dont think it is).

The only thing that sucks both about the iPad and most ereaders is the lack of physical buttons to flip pages, which makes 1 handed operation clumsy at best.

Not sure - perhaps true for an oversocialized subset or people who try to wield and gather social influence.

Robinson Crusoe has no use for rationalization. Him rationalizing the berry he ate is not poisonous, or that the shack he built will hold up in the storm is outright dangerous, and definitely useless.

I don't get this whole thing. This sounds like a small model, that's very possible to run on the edge, and it seems like most of the things it does actually are useful there.

Why does this thing have to be another Web API?

Industrial sites are almost always connected to the grid with backfeed. And even if they can't push out their entire wattage, in accounting terms, that power is priced the same as you get from the grid.

So I'm almost certain they are being counted

I know, but as far as the programming experience is concerned, it feels quite similar.

But expensive. Stuff like Api Gateway is just absurd (but necessary since you don't want that stuff to reach your lambdas, which are dog slow to handle). Paying per request is like charging for every breath.

Another big advantage (and I guess the reason this exists), is for some reason, AWS lambda is a hostile environment for node, with its ephemeral VMs, performance is quite bad (much worse than expected)

Something very similar to this was already possible via serverless-express for node:

https://github.com/CodeGenieApp/serverless-express

This wraps Lambda's 'handler' function and allows express to run on top of it, essentially you get a node web server with no persistence between requests which usually isn't a good thing to rely on, but you can also kinda have that with persistent tcp connections.

Of course since this is not real HTTP, things like WebSocket aren't available, but it's good enough to build a CRUD backend or two.

Similar libs exist for other runtimes as well.

It's really common to see integrated iPads in all sort of kiosk/control panel applications. Afaik iPad has a dedicated kiosk mode which doesn't allow you to exit the running app. Android tablets too.

Afaik this really isn't true. Most of the drone parts used both by Russia and Ukraine are coming from China, or Soviet surplus.

It used to be much more true. The Biden admin sent a lot more US weapons to fight Russia, Trump used to be much more amenable to send similar weapons provided somebody paid for it.

Nowadays US materiel is either tied up in the middle east or somewhere else (Patriots), or has been neutralized by Russian EW (HIMARS), or the US is just unwilling to part with it for whatever justification.

I would like this to be true but I'm not sure (at least when talking about NATO = Continental Europe). A quick search reveals Russia made 41 jet fighters last year, Europe made 40.

I suspect when it comes to the production of certain kinds of advanced war materiel, like missiles, shells or drones, Europe lags or doesn't have a clear advantage.

GDP doesn't matter, despite European defense stocks benefiting majorly from the Ukraine war, this didn't seem to have translated into a similar increase in output, which indicates there are bottlenecks in the system somewhere.

Zero Hour might be better (as my CnC knowledge drops off at RA2 and Tiberian Sun), but mass Allied tank and mass GDI Titan was the dominant strategy.

Was this a good idea to share this, financially speaking?

This implies that the TAM of the $200+ subs is 20m people, translating to $4B/mo or $48B/year.

I had the idea to think about path checking as compile-time tracing GC. You have GC roots know by the compiler, and at any point in the code, you can perform liveness analysis, with roots on the stack, and every time a root goes out of scope, you do 'liveness analyisis' and deallocate everything that went out of scope.

I think very much so.

I have a few friends who used to really get into C&C games, and factional balance is basically nonexistent (with the resident 'good guy' faction being the best), and usually the winning strategy is to just mass produce whatever bang for buck unit that faction has (basic tanks most likely).

I mean the article doesn't talk about this aspect of the language, but Send and Sync are orthogonal to borrow checking. I don't see why you couldn't use Rust's exact design in Valen.

This was the idea behind std::vector<bool> which is a bit array with template specialization, and has been tha bane of C++ devs for decades.

I mean, all allocators in all languages do this, Rust C++ etc.

Also this information is of limited use to the programmer. There's no guarantee the buffer you get is going to be the size you asked for. Lots of allocators use nearest power of 2 sizes for small allocations.

For example mimalloc has separate regions by allocation size, so there's nowhere to put this info.

It didn't (fully), but adding it wouldn't have been more than a days work. You have a hierarchy of enclosing layout rectangles, you take an invalidation rectangle, and you recursively intersect children and them draw them with the painters algorithm.

Vestiges of the system did exist, as there were scrollable panels and controls had an idea that they were not visible due to falling outside of their parent rect, and all drawing functions were aware of being clamped to a boundary box.

So I'd say some of the hard(ish) stuff was already done, and people did end up using it in production so it actual survived contact with a paying customer, which is saying something.

Both have weaknesses, but with an OS, you have certain bottlenecks - like your app memory is paged and has its own memory space, data structures are often duplicated in user and kernel memory, syscalls have cost, which is why io_uring is a thing in Linux.

This is all unnecessary overhead and complexity, as the OS doesn't really mediate hardware access in this case.

But you're right on some points, it's not really more secure, but there's a hell of a lot less complexity where things can go wrong.

Not a money guy, but isn't measuring accuracy of a price model via least squares misguided?

A model that predicts the market with 99% accuracy (1% LS error), but reacts to price changes in a delayed manner is not very valuable, while the same model that is early is basically a money printer.

This isn't too dissimilar to DOS programs. DOS also gave you a filesystem, memory management, a shell a process loder, driver interface, but it was all in real mode, and you were free to replace these components with your own as you pleased.

Or if you're more familiar with embedded, like a BSP or RTOS