guenthert

Isn't biggest attack surface in drivers?

That would be my guess too, the current batch however is all over the place: Bluetooth, file systems, etc. (the network layer ones are probably the most interesting ones). And the severity is mixed as well, some are 'just' vulnerabilities to potential DOS attacks.

I expect distros to split less popular kernel modules into many separate opt-in packages

In the past questionable modules were blacklisted rather than removed.

How about the distinction between the boolean value false, the empty list and whether an empty list ought to be true or false? ]:->

Not sure about that. I rather think it's the very dynamic nature of Python (e.g. at run time one can add members to classes) which limits performance gains achievable by compilation. Iirc PyPy got to some five fold performance gain against CPython.

Common Lisp, as an example, makes some deliberate flexibility (and elegance) vs. performance trade-offs. I'd think to speed Python up more than PyPy could, one would have to sacrifice some of its features (some of those might not be all that popular or even desirable).

Nah, Python has its place. If its performance isn't adequate for the problem at hand, rewrite the bottlenecks in C++ and be done. LLMs should make that easy, no?

"Didn't have the time at that moment to file a bug report"

Because you were busy working on that so urgently needed port of Linux to the Sega 32X?

'social physics of conversation'? Were social dynamics of conversations meant?

"significantly more expensive" and "relatively small"

Well, both are true of course. You will have to put numbers on those to make sensible decisions.

Historically, creating processes in Linux has been cheaper than in other Unix-like OS (you might find results of an old Byte benchmark) and much cheaper than in Windows. Creating a thread will be undoubtedly cheaper still, but whether that will change the user experience or is worth the cost depends on details (how large the memory footprint is, pagesize, how many files are open, how many threads are to be executed, their lifetime, how many execution units are available, etc.).

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?

They ought to, but are they? In https://wiki.postgresql.org/wiki/Developer_FAQ I don't see a requirement to provide a regression test for a bug fix.

[too late to edit] I do realize that it might be more challenging to rent as a foreigner, particularly if you don't speak German well.

Especially given that there aren't interesting media to immerse yourself into in German, compared to other languages like Japanese or Korean.

There's nothing interesting to read im Land der Dichter & Denker? Perhaps following is to your taste? https://editionfaust.de/produkt/faust/

We bought our first home without fully understanding the laws, the government system, or the tax rules.

That's bizarre. In Germany about half the population rents their primary dwelling; many life-long. There's really no rush to buy real estate here.

(not that anybody would fully understand the tax rules)

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.

Managers don't really read or review the codes.

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.

A modern 300cc four stroke Vespa will use 3.3 litres of fuel per 100km

Uh, I know motorcycle engines aren't particularly fuel-efficient (it's not a priority), but there seems to be, er, room for improvement.

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.

There are precisely zero 32 bit ADCs in existence.

There are ADCs that will provide 32 bits per sample but that's entirely different.

Now that requires elaboration.

There is e.g. AD's LTC2500 (https://www.analog.com/en/products/ltc2500-32.html). Not meant for audio (too slow at 32b) and not noise free, but it's a bona-fide 32b ADC.

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.

Comparison here is FM, not FLAC.

DAB+ receivers can (and many do) display signal quality. Not playing distorted, noisy signals is a feature I greatly appreciate.

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.

Well, iSCSI is a standard, so chances are better that it's supported in a non-Linux OS, e.g. MS Windows. Years ago I booted a Windows (7, iirc) client that way, but gave up on it (too much hassle and performance limited by the network) when SSDs became cheap.

"I didn’t want to get into the hassle of repartitioning everything that the boot loader works with both Linux & Windows."

Hmmh? I haven't done so in years, but configuring multi-boot used to be considerably easier than disk-less operation.

I'm pretty sure it does. I would even think that it tries to optimize such, as a recent check-in comment claims improvements of TCO.