I feel like if Google really wanted to improve search, a much better investment than these LLMs would be to figure out how to train an "AI" to weed out the SEO garbage. That could actually improve things, 'cos then you could have a page-rank style algorithm work again... but that would not be very sexy, 'cos then the "AI" would just be a backend filter component. That's probably the common theme with modern technology, where the stuff that "just works" somewhere behind the scenes isn't sexy, so instead we have a bunch of flashy junk to waste everyone's time.

I have a fairly similar experience, though it was on PC with GWBasic which mainly taught me that I needed a real programming language instead. My main language of choice ended up being C and later C++ .. but it was really the direct access to the capabilities of the machine (with inline assembler if necessary, though I quickly grew interested in the types of programs where that's not necessarily the way to go; you'd think kids wanted to program arcade games, but I wanted to do things like compilers and what not by the time I was a teenager) rather than the capabilities of whatever was built into the basic interpreter that was the real eye-opener.. like suddenly you could do anything the machine was capable of rather than spend time trying to work around interpreter bugs and try to remember line numbers.

Perhaps I should clarify as I wasn't really trying to argue as much as just add more thoughts into the discussion. As a plugin developer I generally think that having every plugin oversample internally is overall the better engineering trade-off (and sometimes you want different amounts of oversampling for different stages in a single plugin), but the real point I was trying to bring up is that when processing audio, the bandwidth beyond what's audible can often become meaningful due to distortion (including aliasing) products in non-linear processing. It's generally agreed that we only need about 20kHz of bandwidth as far as ears are concerned, but producing 20kHz of clean audio might require more bandwidth during processing.

The same applies to precision too. For distribution of end-user audio going past 16 bits is IMHO pure marketing snake-oil, but this doesn't mean that you might not want to use significantly higher precision when processing, because then numerical errors come into play. When considering feedback in IIR filters, even single-precision floats are sometimes insufficient and in extreme cases this might even lead to unstable algorithms. Sometimes you can fix this by choosing an alternative algorithm with better numerical behaviour, but in some cases you might opt to have your plugins work in double precision. Even simple volume control (and certainly sample rate conversion if you're playing 44.1kHz on a 48kHz DAC) does lose a tiny bit of numerical precision, so there's no harm in having the PC convert the 16 bit media to higher precision for mixdown before sending it to the DAC... but that doesn't mean there's any real benefit in distributing anything more than 16 bits.

Overall I feel like the biggest problem with a typical discussion (online or offline) with regards to audio quality, sampling rates and precision is that it's very common for people to read something that applies to processing and then insist that it also applies to distribution media where in fact the engineering tradeoffs for the two are very different. A fancy high gain guitar amp sim might want to process with 16x oversampling and use double-precision floats internally to improve the numerical behaviour of it's circuit simulation, but that absolutely doesn't mean that there's any benefit whatsoever in 700kHz/64bits for distribution. For whatever reason, people treat audio as if it was made of magic pixie dust (and that's really what I was talking about with the gold plated ethernet cables). In the real world there's no magic and digital audio really is just regular engineering and all about finding the right engineering trade-offs which tend to be different depending on the purpose.

Oversampling DACs are a thing, but usually you'd be oversampling with something like 1-4 bits in order to produce a signal that's equivalent to the 24 bits signal that you're advertising, rather than to try and improve beyond (since that's already mostly beyond the analog limits).

Oversampling in audio processing is also very much a thing to mitigate aliasing from non-linear processing (ie. any sort of distortion). This way hopefully the most significant aliasing will fall into the excess bandwidth so it can be filtered out by the downsampling filters, rather than folding over to contaminate the baseband. Usually it makes little sense to manually work with higher rate audio here though, since the oversampling is usually built into FX processors and plugins directly (generally makes more sense in terms of CPU efficiency, since you'd need the filtering mostly equivalent to resampling between different processors anyway to avoid letting the aliasing accumulate further).

Finally recording "ultrasounds" at high rates can be useful for stuff like SFX work where it's perfectly normal to record some ordinary everyday sound and then play it back at much slower rate to produce an extraordinary impression. When slowed down, the ultrasounds become audible and the results tend to be more convincing when the final Nyquist rate doesn't exceed the original Nyquist rate.

So... there are reasons to work with higher sampling rates for audio, but basically none of them have anything to do with anyone's hearing in terms of the final media. Even with 24 bits the extra dynamic range is mostly useful in a studio (ie. don't need to worry about leaving plenty of headroom). For final distribution media going past 44.1kHz/16bit is basically about as useful as using a gold plated ethernet cable for watching youtube.

Ignoring hardware considerations (eg. whether the chips can be write-protected), at least from the usability point of view the "lazy user" problem could be solved rather trivially: just make the jumper (or perhaps a dip-switch) both enable firmware updates and disable normal booting at the same time. This way as long as the firmware update mode is enabled you will not be able to use the computer for anything else and doing the wrong thing is no longer an option.

From the point of view of a functioning society going forward, I feel like it might make sense to focus at least some of the mandatory CS education in schools (not just in US, but worldwide) on teaching people the basics of what they need to understand about internet security (hands on, so the point really get across). I'm not talking about security in the sense that a programmer would need to know about it, but rather in the sense of what every modern human needs to understand in order to protect themselves from basic scams, how support personel will never need your password for anything, how an email or SMS can be spoofed or sent by malware, things like that.

Most people seem to learn to hate math in school and I personally feel like trying to teach them to also hate programming is probably not going to be that useful. When the most common password is apparently still '123456' teaching people some basics of how to avoid the dark alleys of the digital society would seem like something that should have a much better return of investiment to the society as a whole, than trying to teach everyone to write code.

The whole point here is that when you're writing a program that is supposed to be running as setuid (especially setuid root), you're NOT supposed to expect "normal operation" (or normal values of environment variables, or normal anything) but rather prepare for the absolutely worst non-sense that your program could technically be subjected to, because pretty much every time you fail to account for some possibility, it's probably a local priviledge escallation waiting for exploitation.

This is why you don't just set any old program to setuid, because most "normal programs" expect "normal operation" and setuid binaries just don't get that priviledge (pun intended). Writing setuid programs is very much a topic that needs to be studied specifically (and preferably restudied every time you start writing a new setuid program), because simply following normal good development practices (whether or not those were followed here) is simply not enough when your program effectively becomes part of the security policy and therefore part of the attack surface.

Complex numbers do not behave like 2D vectors, but they do behave like scaled (by complex magnitude) 2x2 rotation (by complex polar angle) matrices (or 2x2 sub-matrices in case your complex numbers are already elements of some matrix).

It'd be interesting to see the numbers pooled differently, comparing those with private offices vs. those with shared offices (or cubicles, or open plan or whatever). Now, there is likely going to be some correlation between "manager" and "has a private office" but it'd be interesting to see how much correlation there would be to the actual office conditions, rather than just the job description.

You should be able to find any of these by searching directly in your podcast app.

99% Invisible - Things about the world you don't notice at first glance
Cautionary Tales - "lessons learned" for adults
Death, Sex, and Money - about the big questions and hard choices that are often left out of polite conversation. Has interviews with regular and famous people.
Ear Hustle - A podcast about prison life recorded from the inside (this has intense moments, FYI).
BBC In Our Time - Each show delves into a historical topic (I delete about half of them, but they can be very interesting)
BBC Witness History -10ish minute blurbs on historical moments from "people that were there"
BBC Documentary Podcast - Various BBC radio documentaries

...

FWIW, I wrote up a somewhat in-depth analysis of this SFLC / Conservancy dispute here: http://www.rants.org/2017/11/c...

TL;DR: Software Freedom Conservancy is behaving appropriately, and SFLC is not.

LattePanda ? http://www.lattepanda.com/

I'm currently considering one of these for a DSP/Synth project I am working on. Although that will still have a small squadron of smaller boards (including 'Pis) working with it.

I love the horsepower, memory potential, and especially the M2 connection of the SolidRun but, as you said, for my uses GPIO etc is a must

So, even more over bloated, inefficient, security challenging, buggy current slurping rubbish except that its now embedded in a unit that isn't going to be updated because its locked into a poorly conceived quickly hacked to market 'embedded' system. Lovely....

"every book I've read, every professor I've talked to, every lecture I've attended" pretty much says it all.

Some of us have been in this game a long time. Decades. Some of us still love the subject and, unlike the more recent crop of 'developers' still care about efficiency and choosing the right tool for the job. Smaller, more efficient, low power consuming and easy to program 8/16 bit units are used all the time, and for good reason. An RTOS does add additional overheads and can consume precious clock cycles and, thus, current. Sometimes that trade off is worthwhile but, increasingly in the world of IoT, the relevance of these 'ancient' ideas are again being seen as critically relevant.

Given your comment, I can only assume you are still in school or have only just left it. That means that, no matter how good your academic record is, and no matter how clever you think you have been with any little amateur/school projects you might have completed , you are still wet behind the ears and, apparently, quite arrogant. Give it a couple of years before shooting your mouth off as, while not all, quite a few of your elders are your betters.

PS. Good move on posting as an AC. It might have saved you a few lost job interviews.