Pretty classic enshittification. I expect one response might end up being 'contract' developers who sign a contract of 3 years to develop an application and then after three years they go out and find a new contract.
I reason to this because software in hardware produces revenue only during hardware sales which typically fall off after the initial wave. Without continual revenue your business model goes upside down when you have developers for whom you don't have any work. So we get bullshit work and eventually we get 'RMR' or recurring monthly revenue because well we need to pay these folks.
Of course building an enterprise like that would require retooling your process with massive emphasis on sustainable build tools that are 'done' and similarly libraries. We massive documentation on taking the product firmware out of the archive and re-createing the entire build / test workflow with new developers.
A company like that might have 500 developers during initial product development and first shipments, that then reduces down to 10 or fewer for maintenance needs.
The surprising thing is that a lot of open source is actually kind of like this, a new 'thing' is out there and the number of people making contributions grows, and then it is 'shipped' or 'done' and the number of contributors reduces down to a handful, sometime zero, developers. Growing again when a zero day or CVE needs to be fixed and then back to zero. Because its OSS nobody is paying them, or maybe they are being paid by another company that uses the package and needs a fix, but the whole software development model is going to be completely changed over the next 10 - 20 years.
I think that's an interesting insight. Another model like this is game development, most games are built with an explicit intention to not maintain that code forever, to stop development as soon as possible.
... and a lot of games rely on fans for fixing the remaining (often critical) issues. Not exactly something that should even remotely be acceptable for productivity software.
Nice! Takes me down memory lane when my very first computer was a "Digital Group" Z-80 system I built from a kit with 10K of RAM! (8K memory board + 2K on the CPU board). Mouse was a faster and more compact than Tiny BASIC. It was also slightly less brain bending than Forth :-). I'll have to put it on my emulated IMSAI 8080.
It is fun to note the number of models of small languages that emerged from the early days of computing which would all fit in the L1 cache of a current processor. But they could also be used as an interesting way of doing GPU/APU macros. When I worked at Intel I implemented a simple interpreter like this to drive the compute element of the 82786 graphics chip that Intel had produced. As that 'engine' didn't have much stack support my interpreter was more like Mouse than Forth. It let me write simple exerciser tests for the chip like "fill a window region with a pattern" or "do cookie cutter blits between two regions."
I also find it fun when students learn a language like this and suddenly internalize the difference between "programming" and "computation". We joke you can write Fortran in any language but that joke is funny for me because it expressed the difference between someone who was programming by 'pattern matching' and people who were programming by 'expressing computation through language elements.' (yeah it sounds kind of snooty but it isn't, it is the difference between algorithms which can be expressed in any language vs using the statements of known programming language to similarly express that algorihm in a different language). The more ways you learn to express something I feel like the better you understand what is part of the algorithm vs what is part of the language syntax.
Nice work! I look forward to following your development. As a radio amateur I was looking at a Luneburg lens for a 10GHz point to point link, with luck this will let me play around with that idea. Is there a discord server or forum where folks are discussing applications?
Awesome. That is pretty much exactly what I was thinking of doing. My thought was that you could more easily weatherize something like this rather than a parabolic dish which has a lot of wind loading.
Based on the literature the measure would be 6dBi (relative to isotropic). This is often referred to as 'gain' as it represents sensitivity to the band of interest at a given angle of arrival.
In the paper they were measuring signal gain between two antennas, and as such the 6dBm gain appears to be the effect of collating more of the beam spread into the receiver (as one would expect of a lens). Given my schedule I don't think I'll have enough time to print one by November but it would make for some excellent discussion! Reading the permittivity paper that was linked here was also quite good and I'm wondering if something could be integrated into openEMS which would tie the two together.
I'm also tickled by the idea of a 'Newtonian' RF telescope using two lenses.
I like this article, it asks an interesting question (albeit I think it is the wrong question but still it is an interesting one) about how accurately linear systems can be approximated by discrete systems. If you get into digital signal processing (DSP) either through audio/synth stuff or software defined radio or some other way, the trade-offs and how discrete mathematics differs from continuous mathematics are a very deep topic. If I understand the current papers on quantum mechanics it seems that physicists are thinking more and more of reality in discrete terms rather than continuous terms. All of which is fascinating, and yet the first question here for audio stuff should be;
What is the absolute best capability of the human ear to relative to its frequency response and dynamic range?
If you have an answer for that, then when your digital emulation has as good or better frequency response and dynamic range as the best ever measured human ear? Well that would be, by definition, indistinguishable from an analog counter part. (and yes, you can consider infra-sound, ultrasound, and blood bone harmonic resonance and all the other things the 'oxygen free' cable crowd sells you on :-)).
Eric has a penchant for saying things he thinks before thinking about how they might be heard. He famously said, "There is no privacy, get over it. If you're not doing anything wrong you don't have anything to worry about."
I must have missed this when it happened last year (April apparently). Perhaps not surprisingly I associate the name "Emerson" with comically large integrated stereos (boom boxes). But apparently they are building up a test and measurement group.
I am aware, and it is unfortunate for Emerson Electric in terms of branding things in the electronics space. I don't doubt they will retain the National Instruments and/or Digilent brands for that reason.
It will make me chuckle every time I see that Digilent banner "An Emerson company."
I know, really? It's hard to appreciate future shock until you bump into it. When cheap microcontrollers can emulate big-league workstations of the past, you know you're in the future. We long ago reached the point where you could emulate a PDP-11 faster than any real one ever built.
I run 3 IBM 4381's with Hercules (and two Altair Z80 machines, with SimH) out of a Docker Swarm cluster of four RPi Zero W's mounted inside an Ikea picture frame.
reply