an-unknown

If you want to just buy a thing that exists, you could look for one of the "high end" networked audio interfaces out there with on-board DSP mixing + network control, e.g. MOTU AVB interfaces support that (e.g. MOTU 16A + some TOSlink to analog stereo out for the 17th/18th channel would be completely sufficient for your project). You would only have to develop the automation to remote control the volumes / routing and integrate it into your home automation, or if you want to get fancy, you could connect that to a PC and do literally anything you could imagine. Keep in mind that this will cost quite some money and I have no idea how much you want to spend on this project, but it will also give you high quality and low latency audio.

If you want to build it yourself and if you want to keep it cheap and simple: integrating an ADC or DAC on a custom board isn't that hard, at least if you don't need "perfect" "audiophile" audio quality; usually the datasheets of the ADC / DAC chips already tell you exactly how you're supposed to use them + external components you need and so on. In your case, you'll probably want to use a cheap FPGA for mixing (think of Spartan-6 or newer), since that can easily handle dozens of channels, unlike cheap MCUs which usually don't support the number of channels you'd need. With MCUs the limit isn't necessarily how much you could mix in software, but how many ADC/DAC channels you can physically attach to the chip. For zigbee (or whatever network protocol you prefer) you can find dozens of small chips which can interact with that. Since it sounds like your system is wired anyway, you could also think about Ethernet for the network. When you start playing around with this, I'd recommend building a simple and minimal prototype first with e.g. a stereo in/out + network, to keep the manufacturing costs low in case you mess up the design, and once this works as intended, build the "full" 14x18ch module. Don't forget to add some simple debug port like e.g. RS232, it's cheap to add and it makes your life during development much easier.

Take the gerber files from the Github repo, zip them, upload the zip file to jlcpcb.com, and you'll get 5 boards for around $20 including shipment. You'll still need the components like the AVR and LEDs and so on and you'll have to assemble them manually, but you'll have to do that with the offering from the link at oshpark too.

This could be used with modular synthesizer stuff, but you would have to be very careful about voltages, since the "logic module" here uses 3V and you'll most likely kill it with higher voltages or negative voltages on the inputs.

If you plan to use such digital logic gates in a modular synthesizer, you most likely want to add some protection circuit on the inputs and run the whole thing at 5V instead of 3V.

Yes, but if you connect a computer screen to a server, you'll notice that servers usually don't have GPUs for anything beyond "show a 1280x1024 console screen". Unlike a server, the Steam Deck is literally marketed as a device that can be used as a "desktop computer", that's the entire purpose of the optional USB-C dock.

The interesting question here would be if "Tell all their 3rd party publishers to stop publishing on Steam" would be legally OK or if it would result in a lawsuit against Nintendo because of e.g. anti-competitive behavior.

I think you are overestimating the difficulty of producing something. Start building stuff as a hobby, and decide that you want to build it as efficiently as possible because you are lazy. You'll quickly realize that building synthesizers and in particular Eurorack modules is easy and cheap if this is what you're focusing on.

What this means: with a Eurorack module, you don't need a case or power supply, since that's provided by the Eurorack "infrastructure". All you need is a "front panel" on your module as well as certain connectors, and probably one of the cheapest ways to build such a front panel is by manufacturing another PCB with the right size and the right holes. You can do that e.g. at JLCPCB, for <1€ per front panel. Building the synthesizer is similarly easy: design the circuit, create a PCB design that uses modern technology and SMT machine assembly, and you can get even "complex" designs manufactured cheaply, to the point that you can even beat Behringer yourself. After all, you don't have to live from selling such modules, and your development time is "free". And the best part: once you have a working design, you can get as many more modules manufactured as you want, for significantly decreasing prices if you manufacture them in slightly larger batches.

To give you an idea, I recently built a small PCB with "transistor ladder filters", but since they are small and cheap, I extended them and made the feedback path voltage controlled and also added a VCA directly after every filter. A PCB with 8 of them, manufactured and assembled at JLCPCB, cost around 30€. For completeness, this was for a 8 voice polyphonic Eurorack synthesizer module, which means this PCB didn't need any knobs/buttons/jacks/displays. Meanwhile Behringer sells a single "Moog VCF" in Eurorack format for >100€.

> How do you mean, support mmap efficiently? Do you mean being able to close the mapping without a GC? If so then Panama is fixing that.

Everything relevant that can be done with Panama in this context can already be done in a Truffle language with sun.misc.Unsafe and e.g. Sulong used it for exactly this purpose. In fact the Unsafe allowed a lot more with a much simpler API because you really get a function for raw memory access to arbitrary addresses.

But what's the problem anyway? For any normal compiled program, the dynamic linker will mmap the code and data into memory during startup. And a standard memory allocator in the libc like what's used by malloc also uses mmap (and sbrk) internally. Some C programs also directly use mmap to map files into memory or to reserve large amounts of memory, potentially at fixed addresses and with custom protection bits. All of this requires a proper implementation of mmap in the VM if you want to run such programs, in a way that accesses to unmapped or protected memory can be caught without crashing the VM. Side note: Panama does not provide this. The problem here is that the emulated address space only contains a few mapped regions and a lot of unmapped space in between, so you have to come up with a good way how to implement this. You could implement the emulated memory purely in Java, but it is quite slow because you essentially recreate an MMU. For performance reasons you really have to use the hardware MMU in a smart way. It can be done in the GraalVM (and was done in the GraalVM based x86_64 interpreter [1]), but it's not obvious how to do it and it's not particularly efficient either, at least if you want to catch segfaults properly. To efficiently catch segfaults, changes to at least HotSpot would be necessary.

What's even worse here is that it's perfectly valid for a program to register a segfault handler, then cause a segfault and catch it. A few real world programs do exactly this, including the JVM itself. You might ignore such custom signal handling from the guest program, but you definitely have to avoid VM crashes caused by such signals. And again, Panama cannot do it.

> Yes, C can do anything and if it does stuff like trying to disassemble itself, then that will clearly fail. But then you could argue it's not really written in C.

Sure, C programs can do anything, but the problem is that on e.g. a Linux/x86_64 system many things are allowed, certain low level hacks are necessary for performance reasons, and therefore many real world Linux/x86_64 programs do weird things internally, even if it's hidden within some library where you'll never see it. If you want to run an "average" program, you'll have to handle many such cases in your VM. Otherwise you end up with a toy VM which can run a lot of toy programs but fails at larger "real world" programs.

You can do what Sulong does and say "I don't care, I'll just pass malloc/free/mmap/... calls directly to the OS", but then you run into various problems, like e.g. you'll be unable to properly sandbox memory = the guest program can easily crash the VM. You can also do what Sulong in GraalVM Enterprise does and say "we don't support certain features like mmap", but a lot of interesting real world programs won't run. Or you can do what the x86_64 interpreter does and properly (although with reduced performance) emulate all these features, but then you end up building a Java implementation of e.g. the Linux kernel.

In case you wonder, the x86_64 interpreter I mentioned started as a tech demo to show that you can in fact emulate x86_64 with a limited Linux userspace in a fully sandboxed and cross-platform way and with somewhat decent performance on the GraalVM. It even supported Truffle interop with standard Linux .so libraries in the past. Of course it also showed some limitations of the Graal compiler and Truffle, after all that was the entire point of the project. Don't expect Sulong-like peak performance, it's much slower than that. One of the more interesting findings was that machine code emulation with Graal is feasible and works even for larger real world programs like GCC or xpdf or CPython and peak performance can (or at least could at some point in the past) somewhat compete with qemu which uses a hand crafted JIT compiler. This was especially interesting since machine code is the worst imaginable "language" for Graal and Graal is absolutely not built for this.

[1] https://github.com/pekd/tracer/tree/master/vmx86

> But the technique is general. It's not scripting or JVM specific and there's no specific reason the language your interpreter reads has to be textual. […] And that's how you can run C or any other language on the JVM without killing performance.

That's not entirely true though, because the Graal compiler has certain assumptions about your language (e.g. you need some form of "methods" and "calls", otherwise Graal won't compile anything), which means it is not exactly straight forward or efficient to run let's say x86 machine code on the GraalVM. It's also not easy to properly support an "mmap" call in an efficient way although it is required by virtually every compiled program that uses glibc, because none of the "scripting or JVM languages" need this and therefore there are no facilities in Truffle to support this.

That being said, a fully sandboxed x86_64 emulator for the GraalVM exists and IIRC it is roughly as fast as the JIT based qemu-x86_64 after warmup.

Sulong (the LLVM bitcode interpreter of GraalVM) is also not ideal, because it directly executes the LLVM IR although some C code assumes that it is compiled to machine code. This means some libraries use e.g. inline assembly, or try to do some stack walking, or use entire subroutines implemented in assembly, or rely on certain POSIX behavior, which isn't (fully) implemented in Sulong. A lot of programs work, but if something doesn't work, chances are it's caused by one of the few fundamental flaws of Sulong. Oracle is experimenting with a workaround by not running everything in LLVM IR in the future, but we'll have to wait and see how good this works in the end.

> What would be the point? For example, what would you gain by having a C compiler that compiled to bytecode?

You would use it for the same thing that you can do with GraalVM Enterprise today: use native libraries written in C/Fortran/… from your other JVM code in a sandboxed way, without any possibility that the entire VM can crash due to memory corruption bugs in the C/Fortran/… code.

> currently the cheapest alternative on Mouser is ~$5 (STM32F730V8T6TR). And that will have less flash!

Yes and no: with the STM32 you don't necessarily need an external flash chip (= significantly less PCB space consumed) and you get a lot more integrated high speed peripherals than the RP2040 has, including 50MHz SDMMC, 50Mbit/s SPIs, 27Mbit/s USARTs, and proper 480Mbit/s Hi-Speed USB 2.0. The STM32 is also significantly faster (216MHz), uses a Cortex-M7 instead of a Cortex-M0+, has a memory protection unit, and so on. The RP2040 is a toy in comparison.

It really depends on what you need for your project. Sometimes that weird RP2040 can be the perfect choice for a project, sometimes an even cheaper STM32 could be an even better choice, and sometimes you need a powerful chip like e.g. that STM32F730V8T6TR.

Seems like you never saw or used SpectraLayers (commercial tool from Steinberg) or Sonic Visualiser (OSS project). Both have much more advanced visualization capabilities than RX. However, RX definitely has the more advanced "semi-automated" editing / repair features.

But where is the fun then? You can easily build rather fancy CPUs on an FPGA, fancy enough to boot a small Linux system in the end.

To be fair, a lot of software already supports POWER right now, including the Linux kernel, compiler toolchains, the OpenJDK, various database engines, and so on. Don't forget that a lot of embedded devices used PowerPC in the past and it was easy to get PowerPC based hardware like e.g. old Mac computers or game consoles. Today you can get large POWER based servers which compete with big multisocket x86 servers.

I think the main problem of POWER today is that you can't get a "Raspi sized" development board, while you can easily get all kinds of ARM based SBCs as well as various RISC-V based SBCs. The smallest POWER system you can get right now is iirc a workstation from Raptor which essentially competes with Xeon workstations, if you don't want to play around with soft cores on FPGAs.

Yes, there are open core IPs for POWER:

- https://github.com/OpenPOWERFoundation/a2i

- https://github.com/OpenPOWERFoundation/a2o

- https://github.com/antonblanchard/microwatt

If I compare this feature list to e.g. features of xterm (VT52/VT100/VT220/VT320/VT420/partial VT520 support, graphics via Sixel/ReGIS/Tek4014, …), I don't see a single reason why wezterm should be roughly 100MB large (according to pacman on Archlinux) vs roughly 1MB for xterm.

If you think "but terminal multiplexing and SSH!", then feel free to add 0.9MB for screen (or 1MB for tmux) and 4.8MB for openssh, and you're still way below the size of wezterm.

> xterm was still better than most lightweight libvt-based terminals

Even worse: although many terminal emulators claim to emulate some "ANSI" terminal or be "VT100 compatible" and so on, most of them aren't at all. Simply run vttest in your terminal of choice and be surprised, especially by how many of them fail at very basic cursor movement tests. One of the few terminal emulators which gets most things right is xterm. It's also one of the very few terminal emulators which even supports exotic graphics capabilities like Sixel/ReGIS/Tek4014. Nobody should underestimate xterm …

> No human ear can hear frequencies above ~22kHz, meaning anything over the normal ~44kHz sample rate provably makes no difference.

The real fun is when "audiophiles" give you music with high sample rate (e.g. 384kHz) and it sounds objectively worse on a standard playback device because the playback device only supports e.g. 48kHz natively and has to resample internally, with a resampling algorithm that's worse than what you would get if the audio was resampled with a high quality resampling algorithm and directly stored as e.g. 48kHz.

> Some songs were harsh and sounded too airy.

Chances are you hear production mistakes/errors in these songs that you simply couldn't notice on the "worse" headphones. And if you produce music yourself, such "better" headphones might allow you to avoid making such mistakes/errors.

> I saw that the chip itself is surface mount, would I need to make my own PCBs to be able to make more "permanent" projects with it?

If you want to directly use an RP2040 chip: yes, but you can do that for a few $ at e.g. jlcpcb where they can directly assemble the SMD components on the board for you. If you build your own "more permanent" project, you most likely want to build a PCB anyway, to integrate all the peripherals and connectors you need. Otherwise there is the RPi Pico board which is a small PCB with the RP2040 on it. It's the standard "small PCB where you can install a pin header" type of development / eval board.

> Also, what kinds of external things I would need to get started, like specific programmer hardware, etc.

I helped someone else with an RP2040 project recently and apparently all you need is some crystal for the clock, some flash chip for the program code, potentially a voltage regulator, and either a USB connector or an SWD connector (or ideally both). If you have SWD, you can program and debug the RP2040 from another RP2040 based module (there is "SWD programmer" firmware available, there is also the "Raspi Debug Probe" available now), and if you have USB and add some form of boot switch, you can directly program it via USB.

> If your product needs to do X, Y, and Z, and that can be built in arduino in a few days, and built in some other "professional" toolchain in a few months, then you will save money by building your real product on arduino.

Not necessarily. This is only true if you only think about software. Your "real product" also consists of hardware, and if you can do X, Y, and Z on a certain chip with the Arduino environment, you can most likely do exactly the same on a smaller and cheaper chip without the Arduino environment. Simply replacing Arduino C++ by plain C code without useless abstractions can already give you a very noticeable performance improvement and code size reduction on small microcontrollers. Development time is essentially a one time investment, while the chip price is a fixed cost for every unit you build. It's purely a question of how many units you want to build in the end. And for the record, if you can build it in an Arduino environment within a few days, you can definitely build it in "some other 'professional' toolchain" in just a few more days at most.

> Nobody writes safe C. Believing otherwise is delusional. This has been known for decades. But many believers still exist.

This is factually incorrect. You can write safe C code which is even correct according to some specification, as in "guaranteed bug free". This is not what most people do (or even know how to do) though.

First of all, not everything has a big CPU: there are countless small embedded devices which have e.g. just an FPGA or maybe an FPGA and a microcontroller. Example: if you look into e.g. a MOTU AVB audio interface, you will only find one or two FPGAs (and no microcontroller/"CPU"/…) which handle real time Ethernet, USB, the audio DSP algorithms, the ADCs/DACs, the web server with the UI, and everything else that's in this audio interface.

FPGAs give you the ability to process a lot of data in parallel, with very low latency. As soon as you make use of this, a CPU has a very hard time to compete. If you have e.g. radio data from an SDR, you might want to process it on an FPGA → if you look at various SDR modules, you'll find an onboard FPGA to do exactly that. If you want to process video signals with low latency and with low power consumption, again, you might want to do it on an FPGA → look at video interface cards from BlackMagic Design and most of them will have an FPGA on board. If you have complex mathematical models to emulate e.g. some vintage analog audio hardware, which would create some serious CPU load on a PC, you might want to do it on an FPGA instead → this is what some companies like e.g. UAD do with FPGA based accelerators. If you have high-speed interfaces, like e.g. in a network router/switch, you might want to implement the packet processing in an FPGA → this is what some network equipment does, unless it uses an ASIC. There are countless applications for FPGAs.

Sometimes FPGAs are also the prototype "playground" where you can validate your design before you build an ASIC.

And finally, many FPGAs aren't really that expensive, at least if you ignore the crazy price increase from 2020+. The FPGA alone from the Basys-3 development board from the article (an XC7A35T) costs something around $20-25, at least if you don't need the exact same package. Of course that's only the FPGA and you still might want to add some external configuration flash, RAM and connectivity, but that's still very cheap. To give you an idea, a 256MB DDR3 RAM chip costs maybe $3-5. If you want to connect this to your computer, you could use PCIe, which is directly supported by these Artix-7 FPGAs. Of course there are much bigger and more expensive FPGAs available, but I think you can imagine already that you can do a lot with a $1000 hardware budget.

Simulation in software is much slower than running the design in FPGAs.

RISC has nothing to do with instruction counts. Think of it as a "set of reduced instructions", not a "reduced set of instructions". It's the fact that every instruction only does something "simple" which you can directly implement in hardware that matters here.

In case it's still not obvious: PowerPC is obviously a RISC ISA, but it has just as many instructions as some CISC ISAs out there. Meanwhile PDP-8 has 8 instructions, but it's clearly a CISC ISA.

This is factually wrong. There are even multiple different authentication and encryption schemes defined for telnet, see e.g.: https://www.iana.org/assignments/telnet-options/telnet-optio...

Just because some old and rudimentary telnetd or telnet client doesn't implement it doesn't mean it doesn't exist / isn't used.

Not sure why everyone thinks that telnet is "not suitable for today especially in the case of security", although telnet over TLS exists. There are also certain things that telnet can do which SSH cannot (e.g. transport data for a block terminal).

And everyone who uses "telnet as a program for connecting to a server on any port and talking the protocol manually" forgot that telnet is a real protocol and this type of abuse only works if the telnet client is sufficiently dumb / doesn't negotiate parameters. There is a reason why netcat exists.

> and in fact the VM pretty much has to be written in C

What makes you think that you need C/C++ for this? Compilers were and still are written in many languages, and you can always come up with a compiler written in an "arbitrary" language which outputs e.g. an executable ELF file containing your VM runtime code.

There are a few examples of this in the wild btw, look at e.g. the GraalVM and its SubstrateVM sub-project.

And which of these announcements really required manual intervention on a VPS running a webserver? A webserver clearly doesn't use a GUI library like wxwidgets, probably won't run keycloak, and the GRUB change depends on your environment, with good chances that it will still work without re-writing the bootloader.

In any case, just subscribe to the arch announcements mailing list and you'll get an email notification in these cases. Not sure if I would put pacman -Syu into cron though.

> What is actually possible to get your hands on now?

You can get your hands on many different chips right now, including many different STM32 microcontrollers. The more important question is "at what price" though, because some of these chips are more than 10x more expensive than years ago.

> I don't think it's fair to blame France, they have long been pushing for nuclear as evidenced by their energy sources […]

… and right now you can see how "successful" they are with their nuclear power plants: so "successful" that they have to import energy because a lot of their nuclear power plants are currently offline, due to unexpected problems related to safety. Even better, the current hot weather also causes serious problems and reduces power output.