• 0 Post
  • 9 Comment
Joined 1Y ago
Cake day: Jun 28, 2020


The key with Nheko probably is: the latest release is from April. AFAIK they are planning a new release after e2e is “finished”, but I guess final 10% is the toughest one…

In other words, one might need to use the nightly builds to get better experience.

…how does this violate privacy?

It’s possible of course, but have you noticed how difficult it is to get people to move on to a new communication platform? And one of the reasons often is “but all my contacts are on the other network” and then “but I don’t want to run multiple chat apps”.

Btw, somewhat related, I discovered a friend has been sending me—rarely—messages on WhatsApp to my mobile number.

This is all great and well except I’ve never used the app. So they just get sent but nobody (but I guess FB and NSA ;-)) reads them.

Further: Logisim development is suspended indefinitely. [More information] (11 Oct 2014)

  1. cron won’t do that. You can use anacron or systemd timers to handle those scenarios.
  2. Maybe. I believe fstrim can be—or used to be—nicer than filesystem options because trimming is/used to be an operation that didn’t queue properly, so doing it in bulk when you’re not using it can be better. But who knows, maybe this is better nowadays. I guess it can increase your chances of doing “recover removed files”-kind of operations successfully if you haven’t trimmed the device [automatically by the filesystem].

I would try an initrd hook that when mounting rootfs instead setups an overlayfs built of the original root filesystem and a tmpfs.

Btw, as you do note, your use case may not still be reliable, if you cannot enforce MAC-client mapping.

For a secure setup I suggest you set up another WiFi SSID for only the printer and other similar class devices. You can then put that complete WiFi network to its own VLAN and configure other rules as you wish. Your WiFi AP should support multiple SSIDs and distinct VLANs for them and then your WiFi AP would be connected via a trunk link (or possibly a hybrid one).

They are intended to be used that way.

But sometimes switches or routers have bugs.

I have this one managed switch connected to a wifi access point with vlan 100 and to the central switch via a trunk port (all vlans). Normal lan activity is in vlan 10. I have configured that the management interface of the switch is only accessible over vlan 10, but the vlans 10 and 100 are bridged to each other in my router. Basically, this means lan and wlan seem like one network, except all traffic between them can be inspected in the router.

Well, it turns out I cannot access the management interface over wifi. This should work because the management traffic arrives via vlan 10 to the managed switch (even if originated from the vlan 100 wifi ap). But it fails because (my theory) it also sees that the same mac is in another port with vlan 100. Quite a curious failure mode.

At least this time it erred on the cautious side.

it’s very hostile against Tor users, though it became slightly less problematic after CF switched from recaptcha

I guess the pragmatic option is to provide a tor-hosted service for them. I imagine it is also protected against DoS-attacks, or if not, then it only impacts tor users.