ValdikSS

This reminded me of a recent very detailed video on polyphony implementation on 8052

https://news.ycombinator.com/item?id=49895486

There's also a phone with YM2149

Very detailed video on Russian phones with built-in CallerID systems, which usually had features far beyond number identification (metronome, guitar tuner, alarm clock, music composer, voice changing).

The video is interesting not only from the historical, but also from technological and programming point of view.

https://youtu.be/DvfgnR6mVDI?si=VDRPSzXKnSA1bZQQ&t=1402 (23:21) — "Rus-28 Sonata" music on a Spectrum's YM2149 chip

https://youtu.be/DvfgnR6mVDI?si=W1IQGhcyxUnyn8lK&t=1574 (26:14) — HQ polyphony using 8-bit output of Intel 8052 clone.

https://youtu.be/DvfgnR6mVDI?si=X8uRz3geBbcxWj0-&t=3050 (50:50 - 01:00:17) — how this polyphony was implemented

https://youtu.be/DvfgnR6mVDI?si=0hrcI-P75zHXQt98&t=2775 (46:15) — poor man's FFT on 1-bit ADC using comparator, for number identification and guitar tuning

As one of the comments says, "Once upon a time, the Rus'-based CallerID phone was the only form of entertainment at home..."

Wow, I haven't heard about BK7258.

What BES chip are you referring to?

Here's a fascinating read about SHA implementation of Via Padlock: https://web.archive.org/web/20260123071403/http://www.logix....

Padlock hash engine can only hash the whole data, not a block of data (not init + update + update + ... + final), so the OpenSSL developer hacked up the MMU to prevent the CPU from accessing next regions and terminate the processing, emulating update() call :)

>but not as crippling problems

:)

I was reusing about 40 kg of Via Eden Esther 3 years ago, and they hang under certain conditions when the software uses SSE2 instructions.

Had to rebuild the kernel and all the software in 'pentium4' mode, to make it work without SSE2.

I had this issue on my VIA Nano U2250 server in online.net as well back in 2013 :)

Full operating system with all the compatibility and device drivers. Ease of development: you program on Linux, testing on desktop Linux, and then run on a small Linux. Need additional software? Just compile and use it, without porting or adaptation/integration. I've described everything above, don't know what could I add.

ESP32-S31 is no longer an MCU anymore if it has an MMU I guess. It's a full-blown "computer chip".

Of course people will, I'm looking forward to!

>There's also limited support for 32-bit RISC-V in distros so anyone looking to run Linux on this will need to build everything themselves.

For this kind of a device, "everything" is a kernel + your application/libraries + maybe busybox/toybox with some applets, all with XIP.

>Easier to just get a cheap ARM SoC that can probably run Android

It's at least twice as expensive for the features S31 provides. See my other messages here.

It's 802.11ax, it's much better than 802.11n.

The benefit of running Linux on a what used to be an MCU is that you're getting the best network stack, Bluetooth/Wi-Fi stack, one of the best device drivers (say for USB Host), stock and very well tested software, etc.

For your use case, you need raw performance and low-level control, and you have it. But for IoT device which is all about network more or less, there's usually no need to go low-level.

ESP32 for Wi-Fi handling uses wpa_supplicant port from Linux for example.

You can run a real, multi-user Linux with as low RAM as 8 MB. You get the benefit of running any Linux-supported programming languages (and combine any amount of them without extra effort, just on a real machine), established portable abstractions, established memory protection model, ease of debugging.

You can run both though. Both FreeRTOS and Linux simultaneously, where Linux is a FreeRTOS task on a dedicated core. That's how several Linux ports work, haven't checked if Espressif's works this way as well.

I don't know what's the final retail/bulk price of S31 and its modules will be, but S3 module with 16 MB NOR Flash and 8 MB PSRAM costs $3.5 for 500+ pcs, and the final PCB BOM cost is $4 or so.

According to Espressif website, current "reference price" for S31 sample module (1 piece) with 16MB flash + 16MB RAM is $6.2.

If S31 won't be much more expensive than S3 in bulk, it has a chance to become a very successful and what's more importantly really cheap full-featured Linux platform, in a small form factor, with flash, RAM, and radios integrated.

Espressif here could easily kill many contenders. You can count Wi-Fi-integrated Linux SoCs on one hand, let alone with RAM+Flash integrated, let alone cheap and available in quantities, and with reasonable soft and tech support.

Oh, and ESP module quite literally doesn't need anything more than a 3.3V power and maybe 2 capacitors to work.

Too bad Linux has removed Execute-in-place (XIP) support for RISC-V since 7.1. It allows to run the kernel (and applications) from NOR flash directly, without copying it into RAM first. Somebody should reintroduce it.

Espressif's port use 6.18 due to this exact reason. There's also another port, using 7.1, not sure if it supports XIP.

https://www.phoronix.com/news/RISC-V-XIP-Being-Removed

XIP is almost essential for these low-RAM devices. You can run Linux with 8 MB RAM with reasonable functionality.

There's entire industry to detect PDF forgeries. They analyze how exactly each software acts upon editing the file and detect these features.

Some software rewrap the page into say additional XObject, some add unique elements, some change one IDs but not the others.

I had a great blog post about it but can't find it right now. Will post if find the link.

There used to be a large site called keygenmusic.org, but it's closed now. There's a dump of all of its tracks on web archive: https://archive.org/details/key-gen-music-music-pack-2020-03...

I use XMPP almost exclusively for the last 10 years and don't see any major issues, not with the protocol, not with the clients. Everything is pretty reliable and works fine.

>What for?

To prevent head-of-line blocking.

XMPP was not designed for human chat only, and XMPP foundation promotes it as an IoT communication protocol, like MQTT. Thanks to Daniel, the author of this post, we now have communication profiles which the IM-oriented servers and clients follow.

The same applies to Russian banks. Russian banks have switched to internal Ministry of Digital Development CA which is not trusted in common browsers.

https://crt.sh/?id=22899279066 (Revoked: privilegeWithdrawn)

>Firstly, an out-of-band upload is ridiculous

It is a bit, true, but the alternatives are worse. XEP-0231 (Bits of Binary) Base64-encoded data inside the text message is more ridiculous idea. Direct P2P connections, which were widely used before HTTP upload, are mostly not working in our day.

>it doesn't support upload resumption in case the network is bad.

There's a draft for HTTP for it: https://httpwg.org/http-extensions/draft-ietf-httpbis-resuma...

XMPP also supports push notifications using Android and iOS infrastructure. But it also works with persistent connections, and the client notifies server when the app is not in foreground, for server to push only important data (such as direct message) to conserve battery.

Everybody has switched to OMEMO. It's the same encryption standard which Signal uses. It supports multiple devices and encrypted group chats as well.

>If you tell people "on Android you should use this app, on iOS use that app" - you lose regular people fast.

People don't use single browser and single email client, why IM should be different? It's a deficiency when you're forced to use a single "official client".

XMPP has brilliant session management, it reconnects more seamlessly than many other protocols on mobile. It literally reconnects (rejoins the same session within different TCP connection, not replaces it with a new session).

>Also sending media (or even rich text) never really worked as each client implemented it differently.

Everyone use HTTP upload nowadays, it works all the time.

The talk about steps it took to hack into Nvidia CMP 170HX cards to unlock the performance and use all 64 GB soldered RAM instead of stock 8/10 GB.

It has been reported to Google (as a security bug) and to GrapheneOS as a comment in one of the very similar VPN leak issue on github. GrapheneOS has deleted my comment, probably because they assumed it was AI-generated or something, I've copied the report I sent to Google there.

Actually yes, why not? All the professional documentation has glossary in it, btw.

Android has a way to bind the socket to the interface: Network.bindSocket, this is a setsockopt(SO_BINDTODEVICE) wrapper with access control.

The access to it is controlled by the VPN application. Some applications could be allowed to connect directly when the VPN is active and routing all the traffic by default, some could use VPN if configured not to use it by default.

However starting with Linux kernel 5.7, the unprivileged userspace can now call setsockopt(SO_BINDTODEVICE) directly and use VPN or non-VPN interface even if restricted by the VPN client.

Not fixed in any Android (incl. Graphene, which has fixes for other leaks, but not this) to the day.

PoC is as simple as "curl --interface [ifname, not IP] ifconfig.co" in termux.

Do you have flea markets in DE? I'm pretty sure 10 kg of cables could be sold for more than €100 in a single day. Is it not common in DE?

Oh no, I wasn't, and that's definitely not my comfort zone. I mess with the printers and printing stack due to anger, not because I like it.

It's bugs on bugs, with bugs chasing bugs! So little developers, so complex stack with 25 years of technical debt, and little community around because it's not a sexy technology to be involved in.

That's why I have to dive deep and fix my bugs myself if I want to make it work properly as I would like it to. I also ended up making my own print server device, because China did not make a proper one for some reason for all these years.

PDF is very, very complicated standard which can't be handled properly on tiny MCUs with reasonable performance and spec conformance:

    - 4 font formats
    - 9 image formats
    - blending with transparency
    - different colorspaces, each image could use its own on the page
    - different dithering algorithms, each image with its own
    - the page can have elements from another pages (global elements)

This is only a small part from the top of my head.

Common simple home printers absolutely should not accept regular PDF as an input: thanks to Apple and IETF we now have Apple Raster and PWG Raster for printers, as a part of AirPrint and IPP Everywhere/Mopria driverless printing standards, which are very similar but have slightly different options and headers. It's a simple raster input for printers specifically.

Some companies, such as HP, invented a "raster PDF": PCLm / PCLms. Don't be confused by the name, it's a regular standard-conforming PDF which contain nothing but a full-page JPEG on each page, and don't use any other features. It's created only to be able to open "printed page" (driver output) in a standard PDF viewer on a PC for debugging or business logging needs, but otherwise it's like a regular JPEG with additional per-page metadata.

>penguin would shrink the result to fit its screen. >I declared A5 and Letter paper, media type stationery, and an output bin called face-up.

You can (and should!) define exact dimensions of your screen in `media-size-supported`. It will probably be a non-standard IPP name, that's why you should define that in `media-supported` as `om_NNNmmxYYYmm` or `oe_NNNinxYYYin`

That way you don't need to scale the incoming data, the PC will format it exactly to the dimensions of the screen.

Both PWG Raster and Apple Raster support 1-bit-per-pixel mode (instead of 8-bit-per-pixel you use), that's why the input could be 8 times less in size. Use `print-color-mode-{supported,default}=bi-level` instead of `monochrome` for that. And also tune `urf-supported`'s `W` option, use `W1` for this case.

The screen/dithering could be ass in 1-bit mode, see https://github.com/OpenPrinting/libcupsfilters/pull/160 where I added more dithering options (Linux-only though, Apple seems to abandon their CUPS).