I thought it really excelled at displaying the timeline—it was quite novel to see a timeline for a video I was watching that didn't occlude any part of the screen—but quite annoyingly it would go black due to inactivity.
And of course the virtual function keys were awful.
I've wondered for a while if it would be possible to do that with a USB FXS adapter[1], and something like a Pi, but you'd basically need a soft modem of some kind to make it work and the only module for Asterisk isn't up to the challenge (last I checked five years ago).
However, to be frank, it'd make more sense to do PPP over null modem with a straight serial connection.
You can set your ULA to something like "fddd:192:168::/48" and then on your vlan you prefix hint, say, "66". Now, any device on that vlan will be addressable by "fddd:192:168:66::$host". For example, your gateway ('router') for that vlan would be "fddd:192:168:66::1".
If you want to be really wonky you can script DHCPv6 to statically assign ULA IPv6 leases that match the IPv4, and expire them when the IPv4 lease expires, but like said upthread, addressing hosts via IPv6 is the wrong way to go about it. On your lan, you really want to be doing ".local" / ".lan" / ".home".
> addressing hosts via IPv6 is the wrong way to go about it. On your lan, you really want to be doing ".local" / ".lan" / ".home".
.local is fine as long as all the daemons work correctly, but AFAIK there's no way to have SLAAC and put hosts in "normal" internal DNS, so .lan/.home/.internal are probably out.
> On your lan, you really want to be doing ".local" / ".lan" / ".home".
The "official" is home.arpa according to RFC 8375 [1]:
Users and devices within a home network (hereafter referred to as
"homenet") require devices and services to be identified by names
that are unique within the boundaries of the homenet [RFC7368]. The
naming mechanism needs to function without configuration from the
user. While it may be possible for a name to be delegated by an ISP,
homenets must also function in the absence of such a delegation.
This document reserves the name 'home.arpa.' to serve as the default
name for this purpose, with a scope limited to each individual
homenet.
It may be the most officially-recommended for home use, but .internal is also officially endorsed for "private-use applications" (deciding the semantics of these is left as an exercise to the reader): https://en.wikipedia.org/wiki/.internal
".home" and ".lan" along with a bunch of other historic tlds are on the reserved list and cannot be registered.
Call techy people pathologically lazy but no one is going to switch to typing ".home.arpa" or ".internal". They should have stuck with the original proposal of making ".home" official, instead of sticking ".arpa" behind it. That immediately doomed the RFC.
I do it by abusing the static slaac address. I have a set of wierd vms where they are cloned from a reference image, so no fixed config allowed. I should have probably just have used dhcp6 but I started by trying slaac and the static address were stable enough for my purposes so it stuck.
How does that work? I initially assumed you meant you just statically assigned machines to addresses, which I think would work courtesy of collision avoidance (and the massive address space), but I can't see how that would work for VMs. Are you just letting VMs pick an IP at random and then having them never change it, at which point you manually add them to DNS?
Pretty much. A given mac address assigned in the vm config maps directly to a static slaac address(the ones they recommend you not use) and those preknown slaac address are in dns, Like I said, I should probably use dhcp6 but it was a personal experiment in cloning a vm for a sandbox execution environment. and those slacc address were stable enough for that. every time it gets cloned to the same mac address it ended up with the same ip6 address. works for me, don't have to faf around with dhcp6, put it in dns. time for a drink.
But the point is that is the address you would put in dns if you also wanted to use slaac. Most of the time however you will just set a manual address. And this was with obsd, where when slaac is setup you get the slaac address and a temporary address. I don't really know what linux does. Might have to try now.
Clarification for others: with privacy extensions disabled, SLAAC'd IPv6 addresses are deterministically generated based on MAC addresses. There's also an inbetween (IPv6 are stable per network by hashing).
There needs to be a happy medium. I don't like reduce motion because it amputates many of the spatial arrangement metaphors inherent in the iOS UI.
My biggest problem with authoring shortcuts is that the editor goes out of its way to obliterate context while you're working. Full-screen editors to change a setting lay on top everything else you're working on. Placeholders for variables, which themselves have no actual names. It's a mess.
> using a static v6 block, not only would this address never change, each device in my LAN would have an extra identifier attached to it.
This is not true.
IPv6 stack allocates at least 3 addresses:
- Link-local
- "Permanent" Address derived from the subnet and MAC
- Temporary address that changes several times per day
The default address for new connections is always the temporary address. So IP-based tracking from outside your network will be no better than it was before from one day to the next—the /64 will be the only constant here, just as your router's WAN IPv4 is for v4 connections.
Ah, handy! Though it can't always be true, at least for manual configuration ;-) I have two VPSes with v6 addresses (the others don't have it configured...), and both only have LL and their permanent Internet addresses.
My understanding is v6 has two different autoconf schemes, DHCPv6 and a more "native" solution. Do these both always result in interfaces having multiple (routable) addresses?
Most of my IPv6 experience has been setting it up on aforementioned VPS, and being rewarded with slow OS updates, since NetBSD's default CDN, Fastly, blackholes PMTUD, so I had to drop the MTU on the interface just to get v6 TCP connections to work at all[0]. And for point-to-point networking in an overlay VPN, where I just discovered that Chromium has an 11-year outstanding "bug" where it refuses to perform AAAA lookups if you don't have public IPv6 routing.
[0] I could switch mirrors, but the bandwidth drop isn't quite bad enough for me to bother...
Man... I typed that reply on my phone and dropped the ball formatting it lol.
> My understanding is v6 has two different autoconf schemes, DHCPv6 and a more "native" solution. Do these both always result in interfaces having multiple (routable) addresses?
The answer to that is "yes," but only insofar as DHCP is _not_ the norm for IPv6 networks. If you're planning to use DHCP to assign network addresses in an IPv6 range, you would run it in addition to using automatic configuration, and DHCPv6 would be responsible only for the "permanent" IPv6 address. Automatically-configured addresses (via RA with SLAAC or whatever) would still create the temporary address that you'd use for outbound internet connectivity, and the DHCP address hangs around for your use in DNS and for hosting "permanent" services like a webserver or whatever.
You've hit on one of the subtler problems of IPv6 being that it requires more things being let through the edge firewall[0], but given a stateful IPv6 firewall on the client side, the onus is on the hosting service's admin to ensure that works correctly (AFAIK).
A number of years ago I wanted to drop a webhook when a call came in on VoIP.ms but couldn't find any way to do it natively.
Ended up sticking a twilio endpoint in the ring group with a "press 1 to accept this call" message so it wouldn't eat the call, then was able to fire an http request with the call details.
It worked well, although I admit I was a little annoyed I couldn't do it directly with VoIP.ms.
That device was explicitly made with "not enough" memory, because if it had enough, it'd cannibalize a significant portion of their higher-margin products' sales.
I'd argue that if memory and storage were still customer-expendable, they wouldn't have even considered making this product.
reply