As long as we're pedantic ... the subject is shared memory. Unless you specify the same, non-null, target address in the call to mmap (and the kernel happens to grant you that mapping on all calling sites), the addresses will be different; the address space is not shared (each mapping might also have different access permissions).
That distinction is important as pointers generally cannot be shared (a problem which can of course be solved with one more indirection ;-) .
I think it's rather unfortunate that writing regression tests is seen as a heavy burden. Compared to determining the cause of a bug and the right strategy to fixing it in a maintainable way, writing such a test should be simple, no?
I'm not at ease regarding LLM generated code changes to a project with a (hopefully) long expected life time, but LLM generated regression tests should be less contentious. I wouldn't expect them to be maintained much; rather, if they don't perform as intended against a future build, just have them recreated.
This seems to be a multi-phased project. First phase (completed) was the re-write in Rust. There doesn't seem to be a performance gain and no significant one should be expected. In a 2nd phase a new architecture is implemented which malisper claims to perform much better.
I wished the two phases would have been tackled in reverse order.
Dunno. I got rather the impression that it's ambitious single-developer projects with no intention of maintenance which leverage those 'AI' code generators the most.
Who wants to contribute to an unmaintainable code base?
> suddenly the final decision is not what was agreed upon in the meeting.
Are you sure you're not reading too much into that? I've witnessed plenty of times (in the USA) that agreements of a meeting were later 'forgotten' (no doubt often indeed due to poor memory). To the point that it was best to insist on a written record of a meeting.
What makes it a Russian company? The team is allegedly spread across the globe, the company (Flipper Devices Inc.) is registered in DE, USA and there's a London office.
There's such and such. In some companies, the leaf engineers report to a team lead, which might or might not be granted this 'manager' title. Those poor fellows essentially doing double-duty and are the most likely candidates for burn-out.
There are many reasons to use a dedicated host (or VM) for a DB server, but if only the accessible memory needs to be limited a container is the simpler, more efficient tool. Said that, I would expect to be able to configure how much memory a DB process is allowed to allocate. I remember distinctly that PostgreSQL allows such. But of course both can be configured simultaneously, a belts&suspenders approach if you will.
Whether failed transactions are actually so much more desirable than a OOM-killed process isn't quite obvious, but it might be easier to troubleshoot.
One cannot create a noise-free, perfectly linear 32b ADC using 2 lesser ADCs as described above. That is however not needed and I suspect isn't what they are attempting.
If, say, two 24b ADC (20b noise free, non-linearity 2LSB) with one receiving the input signal with an approximate 10bit higher gain (+60dB) and one would combine their outputs with that 10b shift (and ignoring the input of the low gain path, if the signal falls below a given threshold to reduce the noise contribution of that ADC and the input of the high gain path if the signal exceeds another threshold in order to avoid clipping), then one could construct a 32b float.
This doesn't improve resolution (which arguably would be pointless) or linearity (not all that critical in audio methinks) but dynamic range, which I can see some appeal of (in extreme recording situations, say you'd want to record the breathing of a shooter followed by the gun shot -- there remains the challenge of finding a microphone capable of a 120dB range, but perhaps one could use two different ones ...).
Correct me if I'm wrong, but if a profound insight is gathered in session 1 with user A and stored in context A1, this might be available to user A in session 2, if that still has access to context A1, but won't be available to user B in any of his/her sessions until that NN is retrained with input which includes at least some of the information from context A1.
What? You still operate your ADCs without active cooling?
I'm writing in jest, but long time ago, -hp- used actively cooled FETs (not a very popular approach today as that caused problems with condensation and we have better FETs now).
> use two separate ADCs at two different gains and combine their output
That's what could be done if ADCs were perfectly linear and noise free and limited only by their bit-width. Sadly, they are not. The non-linearity one can in theory measure and correct for, but the noise can be corrected for only by oversampling. And then you might as well use a single ADC of lesser bit width and higher sampling rate.
Now there might be no ADC which provides 32b wide noise-free samples at sample rates needed for audio and given the absurdly low level of a LSB signal that might be as infeasible as it would be pointless, but that's a bit of a different statement.
Some more than others. E.g. Deutschlandfunk Kultur is broadcasted in decent quality, as is NDR3. Klassik Radio fares poorer, but that's due to the bandwidth allocated to them.
> Theoretically, given a sufficient networking configuration/VPN/etc., you could pull your smart card out of the Sun Ray in your university office, go home, and then drop your smart card into a Sun Ray at home and still have everything back where you left off.
They (well, the late models) had a Cisco compatible VPN client built in. Worked like a charm at my place of work in the late naughts.
That distinction is important as pointers generally cannot be shared (a problem which can of course be solved with one more indirection ;-) .