HN user
https://github.com/astoeckel
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).
Depends ;-)
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).
[1] https://iopscience.iop.org/article/10.1088/1741-2560/13/5/05...
[2] https://authors.library.caltech.edu/53090/1/00058356.pdf
[3] https://brainscales.kip.uni-heidelberg.de/
[4] https://web.stanford.edu/group/brainsinsilicon/documents/ANe...
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].
[1] https://github.com/astoeckel/libfoxenflac/blob/master/foxen/...
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.
[1] https://en.wikipedia.org/wiki/Analog_hole
Edit: Spelling, grammar, and clarity
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.
[1] https://blogs.gnome.org/uraeus/2020/09/04/pipewire-late-summ...
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.
[1] https://wiki.xiph.org/OpusFAQ#What_is_Opus_Custom.3F
edit: clarity
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.
Direct link to the article (with paywall): https://science.sciencemag.org/content/367/6482/1131
DOI: 10.1126/science.aba0672
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]
[1] https://en.wikipedia.org/wiki/Control-Alt-Delete#Windows
Related PBS Space Time episode about the "Black Hole Information Paradox" (in general, not about the particular paper discussed in the article):
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.
[1] https://www.bsi.bund.de/EN/TheBSI/Functions/functions_node.h...
[2] https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/BSI/bsig...
It was a dark and stormy night.
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.
More information on‒what I guess‒is the relevant backstory (RMS making reprehensible statements related to the Epstein scandal) can be found (among other places) in this blog post [1] by Matthew Garrett (original source referenced in the post is [2]).
[1] https://mjg59.dreamwidth.org/52587.html
[2] https://medium.com/@selamie/remove-richard-stallman-fec6ec21...
I just looked into Julia (1.1) for scientific use (simulation of very simple dynamical systems) a few days ago. I have to admit that by the end of the day I was surprisingly frustrated. I felt that type annotations were insufficient (one of the reasons to move away from Python); in particular, I didn't find a way to specify statically sized array types as you can do with Eigen, a feature that I find incredibly useful to find mistakes at compile time. Furthermore, just plotting something (using Gadfly) took about 30 seconds the first time after Julia was started and about 20 seconds every consecutive call (on a high-end workstation, mind you).
The next day I just ended up using C++/Eigen with a simple matplotlib binding [1]. The code is nearly indistinguishable from Python/Julia (except for having more verbose types where it makes sense, using "auto" otherwise), and the entire compile+run cycle takes less time for some short runs than it takes Julia to print "Hello World".
That being said, I'm not advocating for people to use C++. I would love to use Julia, and applaud the developers for their hard work and contribution to scientific computing, but as it stands right now, it doesn't seem to be the right tool for me, since I'm relying on fast editing/execution cycles.
1. Programming AVR µCs via ISP/SPI
2. Home automation based on a 433 MHz transmitter
3. Media centre
4. Small router bridging from WiFi to Ethernet
Same here. I got a E5510 when I started University and upgraded it with an SSD and a new battery a few years ago. I really like all the connectors (RS232, VGA, separate microphone and headphone jack, full-sized Ethernet port), and dread the day I have to replace it.
Well analog computation being noisey could be the reason we experience things like emotion.
Hm, I don't really see why this should be the case. Emotions are a pretty well studied in both animals and humans and are, to put it very handwavingly, merely a global change of brain state/equilibria, for example modulated by brain regions such as the Amygdala and/or the release of neuromodulators [1]. From my understanding, there is nothing about emotions that cannot be computed by a digital computer, and there is little about emotions that is related to noise.
I'll let philosophers think about the experience part of your statement.
Yes, thank you for the clarification, my statement is ambiguous.
I meant to say that the theory required to describe a computation on a practical analogue computer (that is noisy) is no different than the theory required to describe the same computation on a digital computer, because they essentially are both discrete systems.
However, as you point out (at least as I understand your first paragraph), when we analyse/build systems on an abstract level we assume (often as a simplification) that they are ideal continuous systems.
Digital computers deal with integers, binary sequences, deterministic logic, algorithms, and time that is idealized into discrete increments. Analog computers deal with real numbers, non-deterministic logic, and continuous functions, including time as it exists as a continuum in the real world.
As a computer scientist/computational neuroscientist, I don't really buy the analogue vs. digital distinction. Basic information theory tells us that any noisy continuous system is equivalent to a discrete system of a certain resolution/bit-depth. As the author continues to write
[...] analog computers embrace noise; a real-world neural network needing a certain level of noise to work.
A few bits are sufficient to describe the output of a real-world neuron. Action potential timing has jitter in the sub-millisecond range, which means that relatively coarse discrete time steps are sufficient for a simulation. Yes, our brains are extremely noisy systems, yet this is exactly the reason why they (in theory at least) can be simulated on a discrete/digital computer.
In practice there is little to be gained from analogue computation, except for a (potentially) reduced energy consumption compared to a digital implementation of the system in question. But on a theoretical level, nothing changes.
The ICU [1] transliterator does this. Here is an example showing how to use it:
icu::ErrorCode status;
auto t = icu::Transliterator::createInstance("Any-Latin; NFKD", UTRANS_FORWARD, status);
t->transliterate("unicode string");
I've written my own placeholder image generator based on Delaunay triangulation inspired by this blog-post. The generator produces reasonable placeholder images at about 300 bytes. The overall effect is not as nice as the images produced by Primitive though. However, Delaunay triangulation is deterministic and relatively fast. Furthermore, the triangles can be efficiently serialized as triangle strips.
In case anyone is interested, the code is on GitHub [1].
I really like Floyd's algorithm for sampling n elements without duplicates in linear time.