For what it is worth, there is Muon, a third-party implementation of Meson written in C99 [1].
Haven't used it myself yet, though Muon has been in steady development over the last few years, and the developers claim that they implement the vast majority of the Meson core features.
I have been using OSQP [1] quite a bit in a project where I needed to solve many quadratic programs (QPs). When I started with the project back in early 2017, OSQP was still in early stages. I ended up using both cvxopt and MOSEK; both were frustratingly slow.
After I picked up the project again a year later (around 2019ish), I stumbled across OSQP again. OSQP blew both cvxopt and MOSEK out of the water in terms of speed (up to 10 times faster) and quality of the solutions (not as sensitive to bad conditioning). Plus the C interface was quite easy to use and super easy (as far as numerics C code goes) to integrate into my larger project. I particularly liked that the C code has no external dependencies (more precisely: all external dependencies are vendored).
First of all, there is no single accepted definition of "neuromorphic" [1]. Still, as a point in favour of the "neuromorphic systems are analogue" crowd: the seminal paper by Carver Mead that (to my knowledge) coined the term "neuromorphics" specifically talks about analogue neuromorphic systems [2].
Right now, there are some research "analogue" (or, more precisely "mixed signal") neuromorphic systems being developed [3, 4]. It is correct however that there are no commercially available analogue systems that I am aware of.
Unfortunately, the same can be said for digital neuromorphics as well (Intel Loihi is perhaps the closest to a commercial product, and yes, this is an asynchronous digital neuromorphic system).
I can't comment on the "power hungry" part, but FLAC only requires and (to my knowledge) has ever only required integer math. Source: just looked at my own FLAC implementation [1].
As weird as it may seem, you should not forget that free software licenses are built upon the fabric of copyright. Without copyright, free software could not exist in its current form.
For GPL-like "copyleft" licenses, there would be no way to enforce that binary distributions of derived works are accompanied by their source code. Similarly, in the context of permissive BSD/MIT-style licenses, there would be no way to enforce attribution.
So, given that FOSS---which a large portion of the HN crowd depends on---cannot work without copyright (at least not in its current form), the recent discussions may be less of a surprise.
This is just one example of the "analogue hole" [1] problem shared by all anti-cheat/DRM systems.
At least in theory, there is no technology that can prevent exploits like this short of dystopian levels of surveillance and locking down computing devices even further.
By that I mean encrypted communication on all computer buses (including USB, HDMI), and only allowing access to those busses via physically hardened "secure" enclaves, up to (in the end game) big-brother-like surveillance (think electronic proctoring solutions).
I think that this is exactly the problem with such DRM schemes---the ensuing cat-and-mouse game will inevitably lead to trampling the user's freedoms, because locking down computing devices and environments to ridiculous levels is the only way in which DRM can be made to work.
Of course, for now, cheats like the one featured in the article should be fairly easy to detect (at least from what I've seen in the linked video).
The motion of the bot is extremely jerky; a simple rule-based system, or, if you want to be fancy, a neural network based anomaly detection system should be able to detect this.
On the side of the cheat authors, this could be easily circumvented if they include a "calibration phase", where user input trains a simple neural network to stochastically emulate the dynamics of the user's sensor-action loop. The cheat could then act slightly faster than the user, giving them an edge while still using their unique dynamics profile.
I wonder where this will lead eventually, and I genuinely feel sorry for all the people who pour their heart and soul into competitive gaming; I don't think that this kind of cheating is something that can and should (see above) be prevented in the long-run.
The best possible outcome I can imagine is that online gaming becomes more cooperative or once more converges back to small groups of people who know and trust each other.
I agree that this is a much better option. Also, if you use two OpenWrt devices, you can enable WDS mode to build a true layer 2 bridge. That is, you won't need Proxy ARP and DHCP relay. For example, DHCP and IPv6 will just work out of the box.
Edit: From what I can tell, support for WDS depends on the WiFi chipset. "iw list" must explicitly include "WDS" as a "supported interface mode". At least the Broadcom chipset on the Raspberry Pi Zero does not support this, but, for example, the Atheros chipsets used in a variety of routers do.
Building something like this was kind of the idea of Scholarpedia [1], founded by Eugene M. Izhikevich (theoretical neuroscientist). The articles are reviews written by experts in the field, peer-reviewed, and supposed to be updated over time. Most articles happen to be in neuroscience and related fields, but that was more an accident and not by design.
Unfortunately, the project has never really taken off, and only few new articles have been added over the past few years. And of course, just as I am writing this comment, I realize that [2] now redirects to some domain squatter and is blacklisted by my DNS server...
Well, as at least one other commenter in this thread already pointed out, this is possible with WDS (Wireless Distribution System). However, this needs to be supported by the access points. If it is supported (for example on APs running OpenWRT), it is literally just a matter of enabling WDS on the station and client APs, and bridging the wireless interfaces to the ethernet interfaces.
I've been using this setup in my home network for years now (with a dedicated OpenWRT device for each wired "island") and it works great.
Edit: To clarify, yes, this establishes a single broadcast domain. For example, DHCP and ARP requests are propagated through the entire network.
You are certainly not wrong. In this specific case however, I'd like to point out that the author, leonerd, has been busily working on "making stuff" to this end for years now.
They are the lead author of libvterm, a popular modular terminal emulator library that is for example used in neovim and emacs-libvterm.
They have also been working on libtermkey, a library that accepts input from the divised keybinding system, now part of libtickit mentioned in the post.
The "code poem" at the beginning of the post reminds me of the "Bit Shift Variations in C-Minor" [1] by Robert S K Miles (chiptune music in 214 bytes of C; featured in the computerphile video "Code Golf & the Bitshift Variations").
As you expected, you probably shouldn't read to much into these calculations. ;-)
The Shannon-Nyquist sampling theorem guarantees that we (as in the DAC in your computer) can perfectly reconstruct the analogue signal for any discretised signal that is bandlimited to frequencies below Nyquist, i.e., 24 kHz for a 48 kHz sample rate. No matter how crooked the sample points may look to you. And 440 Hz is way below the 24 kHz limit.
Sure, this doesn't take quantisation into account, but 16 bit is sufficient to encode the difference in amplitude at the individual sample points between 440 and 440.8175 Hz with plenty of headroom (about 210 digital steps at 109 samples). Indeed, the smallest frequency difference that would have a zero difference after 109 samples due to quantisation is about 0.001 Hz (modulo mistakes in my hasty calculations). And this doesn't take dithering into account. Dithering essentially gives you an infinite dynamic range (depending on your definition of dynamic range) at the exchange of a higher noise floor. Of course your signal is likely also longer than 109 samples.
See this excellent video [1] by Xiph.Org's Chris Montgomery
for a whirlwind overview of digital signal processing.
Here is a recent update from Christian Schaller on PipeWire [1]. It looks quite promising; it's especially good to see that PipeWire comes with shims implementing the ALSA, PulseAudio, and Jack API, so it should be a drop-in replacement.
There are ways around this. See "content-aware chunking", e.g. implemented using rolling hashes [1]. This is for example what rsync does.
The idea is to make blocks (slightly) variable in size. Block boundaries are determined based on a limited window of preceding bytes. This way a change in one location will only have a limited impact on the following blocks.
If you worry about artifacts introduced by sample rate conversion, you shouldn't use a lossy format in the first place. The sample rate converter used by Opus (i.e., the speex resampler used in the opus-tools library) is completely transparent and does not introduce any audible artifacts. As per [1], the distortion caused by any lossy codec even at the highest bitrates is larger than that caused by re-sampling.
As for playback, most likely your sound card is already running at 48kHz; 44.1kHz may actually not be supported properly by your DAC (I guess since it requires a higher quality anti-aliasing filter). As [1] continues to explain, Opus is essentially shifting the burden of resampling to the encoding rather than the decoding side of things.
That being said, Opus technically supports odd sample rates such as 44.1kHz, but this has to be signalled in a side-channel. See [1] downwards.
Well, it's not a scan, it's a recording from a micro-electrode array (MEA) implanted directly into patient's brains who's skull was already opened for (I guess) surgery.
As others have pointed out, this article is not very convincing. I don't agree with the point that WASM is somehow more suitable for nefarious purposes than obfuscated JavaScript. I suppose that if anything, the execution model of WASM is much simpler than that of JS and it should thus be much easier to analyse.
> This prevents the user from escaping the scam by pressing keys like ESC or the CTRL+ALT+DELETE combination, or others as shown in the table.
The part about CTRL+ALT+DELETE is just nonsense. This key combination is directly handled by the Windows kernel and cannot be captured by a user space application. Hence the "Press CTRL+ALT+DELETE to login" prompt. [1]
I remember receiving an email from the BSI ("Bundesamt für Sicherheit in der Informationstechnik"; engl. "Federal Office for Security of Information Technology") regarding a misconfigured NTP server that could be abused for NTP reflection attacks.
The functions of the BSI are explained in English here [1] based on the following law [2]. I guess initiatives such as informing about the NTP problem fall into what is listed under §3.2.
The night began with a low-frequency hum that began in the northwest, then subsided into a softening, then continued on to the north, ending in a violent thud, which was followed by a pause of silence, followed by a long shower of thunder.
[1] https://sr.ht/~lattis/muon/