berkut

People also said similar things in the past (I'm a musician as well: guitar, piano and bass) about Synths and Drum machines (and things like GarageBand which can do backing drums and even basslines semi-automatically now).

Some of those things enabled others to create new types of music or express themselves in different ways.

Not if you want better fidelity: the VFX industry for film moved from rasterisation to raytracing / pathtracing (on CPU initially, and a lot of final frame rendering is still done on CPU due to memory requirements even today, although lookdev is often done on GPU if the shaders / light transport algorithms can be matched between GPU/CPU codepaths) due to the higher fidelity possible starting back in around 2012/2013.

It required discarding a lot of "tricks" that had been learnt with rasterisation to speed things up over the years, and made things slower in some cases, but meant everything could use raytracing to compute visibility / occlusion, rather than having shadow maps, irradiance caches, pointcloud SSS caches, which simplified workflows greatly and allowed high-fidelity light transport simulations of things like volume scattering in difficult mediums like water/glass and hair (i.e. TRRT lobes), where rasterisation is very difficult to get the medium transitions and LT correct.

It's not clear that is does affect Airbus does it?

It looks like only the LEAP-1b engines are affected by this, and I was under the impression that LEAP-1b was 737-MAX-only?

(A320 has LEAP-1a as far as I can see).

No, that aircraft was a 737-800 (NG), whereas the LRD is only on the LEAP engines of the 737 MAX...

> or intentionally don't write const because writing it everywhere clutters up the code

I don't often like being judgemental (at least publicly!), but I'd argue that's just people being very bad developers...

You could argue having to add '&mut' at call sites everywhere (i.e. opposite to the way C++ does const in terms of call site vs target site) also clutters up the code in terms of how verbose it is, but it's still largely a good thing.

It used to in older (pre 2.0) versions, but due to Python's GIL lock (and the fact Python's quite a bit slower than lua anyway), it was pretty slow an inefficient using Python with AttributeScripts, so 2.0 moved to Lua with OpScripts...

Katana uses LuaJIT quite extensively for user-side OpScripts, and previously both DNeg and MPC (they've largely moved on to newer tech now) had quite a lot of Lua code...

As someone who's used Lua a lot as an embedded language in the VFX industry (The Games industry wasn't the only one that used it for that!), and had to deal with wrapping C++ and Python APIs with Lua (and vice-versa at times!), this is indeed very annoying, especially when tracing through callstacks to work out what's going on.

Eventually you end up in a place where it's beneficial to have converter functions that show up in the call stack frames so that you can keep track of whether the index is in the right "coordinate index system" (for lack of a better term) for the right language.

Word for Microsoft 365, and since November...

A 256-item float32 LUT for 8-bit sRGB -> linear conversion is definitely still faster than doing the division live (I re-benchmarked it on Zen4 and Apple M3 last month), however floating point division with the newer microarchs is not as slow as it was on processors 10 years ago or so, so I can imagine using a much larger LUT cache is not worth it.

I've tried a lot in the past as well, and after getting annoyed with proprietary OS X software (iBank in particular) back in 2009 or so, and not really liking GNUCash and KDEMoney (at least back in 2009) ended up writing my own open source simple app (native Cocoa, with a more recent Qt port for Linux) that I've been using every since on a daily basis.

In terms of the detail, I used to do very detailed breakdowns of categories, but now I don't really see the point: my app supports 'split transactions' (one of the reasons I actually made it, as existing solutions had poor support for them back in 2009), and I generally just use things like 'Food', 'Drinks', 'Essentials' as categories, as it never really made sense (at least for me) to detail them with such accuracy.

But for things like 'coffee', I do 'Drinks:Coffee', so I can see how much I am spending on fairly specific things, but I guess it's a balance in terms of whether it's worth the effort to record them so accurately compared to making use of the details.

Similarly, things like 'Car:Fuel', 'Car:Service', etc...

That's been within the last year I think - I too have been using Linux and Firefox for calls in Teams meetings from 2020 to last year when I had to move to the Teams Linux client (which they're deprecating, so having to move to Chrome or Edge).

Recommends adding glue to Pizzas as well to stop the cheese sliding off :

https://x.com/PixelButts/status/1793387357753999656

Isn't the SA-brought Genocide case the ICJ, not the ICC?

And is-odd depends on:

https://www.npmjs.com/package/is-number

I think the throughput is currently quite limited because of low levels of water in the natural lakes close to Panama which are used for both Panama's drinking water and for the locks in the canal, so they're restricting the number of ships per day...

I mean, it does read badly, and maybe the worst should be assumed, but at the same time:

> You hereby grant to Vultr a non-exclusive, worldwide and royalty-free license to copy, make derivative works, display, perform, use, broadcast and transmit on and via the Internet Your Content, solely for the benefit of You and to enable Vultr to perform its obligations under these Terms.

Given Vultr has a distributed CDN service, could not the "copy", "display", "broadcast" and "transmit" parts be charitably interpreted as part of that agreement? i.e. them serving your content via the CDN?

Edit: it looks like they've updated it already from what the blog post quotes it as?

Yeah, as someone who's been attempting to use VSCode to do Python and Rust dev over the past three years, I'm continually surprised by people who say VSCode and the Rust analyzer plugin is a Good/Great IDE env.

It so often seems non-functional to me: auto-completion just doesn't work consistently, even on really simple things - you firstly normally have to save your file first, and even then often if I restart VSCode it will then work again on something it didn't a minute ago, and other times I can never get it to complete things. And this is happening on two different Linux machines and a MBPro M2 in multiple projects, so I don't think it's just a one-off bad configuration I've somehow got.

Its auto-indenting when writing code is insane as well, it seems everyone must be running rustfmt all the time, even on code as they're writing it? It never seems to get the indents right on new lines for me, I'm either having to add them or remove them.

At the end of the day it's what you get used to I think, but Visual Studio 15-20 years ago was pretty good (other than the bloody pause for "Updating intellisense"), I've yet to find anything as good for Python as PyCharm, and QtCreator (CLion was pretty good as well) is still the best Linux/MacOS-based C/C++ dev env I've found (but recent versions of it are getting worse IMO what with all the complicated "Kit" build config stuff).

This sounds a bit like this issue:

https://www.aviationtoday.com/2015/05/05/boeing-787-power-is...

Which was an issue where the 787's Generator Control Units went into failsafe mode after being powered on for 248 days...

That used to be the case, but definitely Pak N Save and Gulf stations you pre-pay (at least put your card in and approve it) before hand...

Getting a Bandwidth Restricted error:

Bandwidth Restricted

The page you have tried to access is not available because the owner of the file you are trying to access has exceeded our short term bandwidth limits. Please try again shortly.

Is it possible they're just hearing the sound of them (you can often hear the sound they're making a few seconds before it hits where you are - I live in NZ) before us due to their much better hearing?

Yeah, I've noticed this as well with DDG recently: even with the localised checkbox disabled it still prioritises them, which often is very frustrating as the results are then almost totally useless.

However, more generally, I've personally found that DDG (and maybe Bing's then?) localised results are just really bad, and have been for the multiple years I've been using DDG and it's had this feature: I'm in New Zealand, and enabling localised / region-based search still often provides results to pages with TLDs like "co.uk", ".ca" and ".pl" (these latter are really common for content-generated spam in my experience), which I just can't understand...

Unfortunately, I have found that Google's results are usually a lot better in terms of being "location-aware" than DDG, at least when that's what you want...

It's interesting to me that being on A/C and Battery power showed a performance difference: when I benchmarked a M1 Pro MBPro against an Intel 2015 MBPro two years ago, I didn't notice any performance differences between being on battery or using mains power in either laptop, which surprised me at the time:

https://pixelesque.net/blog/2022/08/basic-apple-m1-pro-cpu-b...

I wonder what the difference is... Maybe my tests were too short to show the difference between mains and battery?

In my experience with llama.cpp using the CPU (on Linux) is very slow compared to GPU or NPU with the same models as my M1 MacBook Pro using Metal (or maybe it's the shared memory allowing the speedup?).

Even with 12 threads of my 5900X (I've tried using the full 24 SMT - that doesn't really seem to help) with the dolphin-2.5-mixtral-8x7b.Q5_K_M model, my MacBook Pro is around 5-6x faster in terms of tokens per second...

I haven't tried it yet, but people in the /r/chatgpt subreddit are claiming GPT-4-Turbo seems to have issues with understanding/remembering longer (say 100 lines) of code, whereas 3.5 and 4.0 seem to have handled things a bit better, implying that the context-window size isn't (currently) as large as claimed.

Anyone else seeing any evidence of this?

One thing I'm curious about is how they avoided lens flair from small bright lights - the iPhone's lenses in my experience produce multiple very pronounced lens flares when shooting bright lights (and older iPhones used to produce one large green flare as well, but I think that's been reduced in the 14 and 15 - I'm sure other phones do as well, I'm just only familiar with iPhones these days).

Very large light sources likely helped (as did the matte boxes), but maybe they carefully chose the camera angles as well to minimise this?

SSE2 is supported by all x64 processors (SSE and SSE2 are literally part of the AMD64/x86-64 spec), so in terms of support, I don't see how that could be "relatively esoteric"...

No it wasn't...

Unity used some of their tech in 2022 to create a demo with some lions in it.