adamzegelin

Anything important and proprietary is now in firmware.

On Linux, /etc/services often contains a list of at least protocol names and numbers.

My comment was suggesting that it's more than just a "lightweight" HTTP/websockets/MQTT library.

The majority of the things I list are optional features of the core library (rather than examples) enabled by cmake flags, some of which look to be enabled by default:

  option(LWS_WITH_JPEG "Enable stateful JPEG stream decoder" ON)

I would be slightly surprised if I saw a dependency on "libwebsockets" and found that it brought in a JPEG decoder, for example.

All these extra features may imply that it's grown past its original goals, and that the other bits and pieces could be split into smaller parts, etc.

HTTP, websockets, MQTT, ... plus the kitchen sink it seems:

  - JSON parsing
  - DNS, DHCP and NTP clients
  - SOCKS5 proxy support
  - DBUS client and server
  - Threadpools
  - SSH
  - JPEG and PNG decoding
  - HTML and CSS parsing
  - DOM layout and rendering to a frame buffer
  - OTA update client
  - GPIO, i2c, PWM, SPI
  - SSH server
  - ACME client 
  - ...

Probably do-able using Pipewire/Pulseaudio.

I just tried, and I'm able to pair both my Macbook Pro and iPhone to my Linux desktop PC. The PC has Kensington Bluetooth USB dongle. Both the MBP and iPhone can simultaneously play audio over Bluetooth and I can route the incoming audio to a pair of wired headphones. The volume of each stream is independently adjustable via `pavucontrol`.

I also tried pairing a bluetooth headset, but the audio was choppy. Maybe too much bandwidth for 3 devices streaming audio at once? Maybe another dongle would work?

Note that at one point I was experimenting with receiving BT audio on my PC. I can't remember the exact set of configuration changes needed to make this work (if any -- it might've worked out of the box). But the stack is BlueZ + Pipewire on Archlinux.

Pipewire (and Pulse) have a lot of modules and config knobs. Might be possible to get auto-switch working too. They also expose a D-Bus interface, so control from some sort of e.g. Python webapp from your phone is likely.

Impressive that Apple keeps support documentation for such old products.

> Why does any of it operate on remote cloud API calls when it could operate locally?

Vendor lock-in, and gives them the ability in the future to hold your devices hostage by requiring you to pay a subscription fee.

Various IoT platforms, eg Tyua (which gets rebranded a lot), sell a complete package that is totally cloud oriented. Configure the product behavior online, click order, purchase 10000 controller chips preflashed with firmware implementing said behavior, integrate with devices, slap logo on it, sell.

Also, maybe the developers of these products only know how to write cloud enabled software? (slightly joking)

See also: Cassandra and CQL.

> installing the bootloader to the MBR

You mean copying bootx64.efi onto the ESP, right?

It's 2022... MBR is beyond ancient at this point!

You can also use Gimp via a RDP or VNC session, which will give much better performance on low-bandwidth connections, since those protocols do damage detection, only sending updates of what's changed, and (lossy) compression.

I'm not an expert, but my understanding is that the whole X11 is network transparent thing worked great when apps used the X11 drawing primitives. These days a significant number of X11 apps just render _everything_ (often including window decorations) "server-side" as bitmaps and then send them over the wire to the client to composite them. Essentially the X11 wire protocol has become a bitmap pipe.

Wayland does the "bitmap pipe" thing more efficiently than X11.

Just a quick experiment:

I started 4 copies of VLC. `top` shows this:

     PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                                                                                                                  
 1806287 adam      20   0 1091068  74664  56228 S   0.0   0.2   0:00.22 vlc                                                                                                                                                                      
 1806426 adam      20   0 1091064  74548  56128 S   0.0   0.2   0:00.21 vlc                                                                                                                                                                      
 1806537 adam      20   0 1091064  74572  56144 S   0.0   0.2   0:00.22 vlc                                                                                                                                                                      
 1806600 adam      20   0 1091064  74960  56536 S   0.0   0.2   0:00.23 vlc                                                                                                                                                                      

Summing RES (RSS) gives 298744.

VLC loads many shared libraries:

    $ lsof -p 1806426 | grep .so | wc -l
    195

I'd hope some/most of those are shared between the instances of VLC and are included in SHR (if I'm reading the top man page correctly).

Doing RES-SHR isn't totally correct either. Those shared pages might be "marked as shared" (i.e, a .so that's only loaded by one process). But lets assume that most of what VLC uses as SHR is shared libraries, and they're used by each instance.

RES-SHR = 73708

I also ran `free` before and after launching the 4 instances of VLC. Used increased by 66068. Hard to rely on the accuracy of this number since this is a desktop system and I'd imagine used goes up and down all the time. But it's strikingly close to the RES-SHR figure.

IMHO just summing RES isn't correct.

Linux memory usage is complex.