HN user

RKearney

2,925 karma
Posts2
Comments570
View on HN
Grok 4.3 3 months ago

Is this satire? Ask it about June 4 1989, Taiwan independence, or Winnie the Pooh.

On macOS, I can't ping or bind to 127.0.0.2

     uname -a
    Darwin LT-JT6692XPXJ 23.5.0 Darwin Kernel Version 23.5.0: Wed May  1 20:12:58 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6000 arm64
    
    ~
     ifconfig lo0
    lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
     options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
     inet 127.0.0.1 netmask 0xff000000
     inet6 ::1 prefixlen 128
     inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
     nd6 options=201<PERFORMNUD,DAD>
    
    ~
     ping -c 1 127.0.0.2
    PING 127.0.0.2 (127.0.0.2): 56 data bytes
    
    --- 127.0.0.2 ping statistics ---
    1 packets transmitted, 0 packets received, 100.0% packet loss
    
    ~ 11s
     sudo ifconfig lo0 add 127.0.0.2
    Password:
    
    ~
     ping -c 1 127.0.0.2
    PING 127.0.0.2 (127.0.0.2): 56 data bytes
    64 bytes from 127.0.0.2: icmp_seq=0 ttl=64 time=0.824 ms
    
    --- 127.0.0.2 ping statistics ---
    1 packets transmitted, 1 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 0.824/0.824/0.824/nan ms
    
    ~
     ifconfig lo0
    lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
     options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
     inet 127.0.0.1 netmask 0xff000000
     inet6 ::1 prefixlen 128
     inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
     inet 127.0.0.2 netmask 0xff000000
     nd6 options=201<PERFORMNUD,DAD>
    
    ~

iMessage is not about the color of the bubble. While the color is what's most noticeable to the end user, a non-iMessage chat means:

  1. Unable to rename group chats
  2. Photo sharing quality is lowered  
  3. Video sharing quality is abysmal
  4. Messages traverse carrier networks in plain-text
  5. Loss of undo send and delete
  6. Loss of inline replies
  7. Loss of typing indicators and read-receipts (if enabled)
Just to name a few.

Remember, Android doesn't only run on mobile phones and managed addresses are just one part of DHCPv6.

You seem to be completely ignoring the other aspects of DHCPv6. Your response comes off as extremely hostile towards others who may have different requirements than yours. Please consider that there could be other use cases beyond what you've been exposed to in the past.

I don't even know what this means.

It means the Android operating system does not implement the DHCPv6 protocol.

How is it impacting users?

Users of Android devices will be unable to obtain a managed IPv6 address configuration, other configuration, or request an IPv6 prefix (read: prefix, not address) via DHCPv6 Prefix Delegation.

Are they crying out about it on support forums for the past several years?

For at least 10 years now[0].

[0] https://issuetracker.google.com/issues/36949085

Look closely at a lightning cable. The edge is metal. When you plug in a lightning cable, you briefly short every single pin together. There's probably a greater risk of bending a pin inside the port than there is shorting pins out.

Wasn't SolarWinds compromised for 6+ months? 7 days doesn't sound like enough time. Although maybe that's not a good comparison as this was open source and SolarWinds is closed source.

I remember watching a Walmart talk on Node.js and how they vet every single update to every single module before they pull it into their internal repository for internal distribution. Perhaps the answer is to stop blinding pulling down dependancies from the internet?

I've never come across a device that supports permanent summer time. You can typically opt out of daylight saving time and stay in standard time, but you can't stay in summer time.

These devices will either need to pick the standard timezone of the timezone to the east and disable daylight saving time, or we will have to change the offset of every timezone in the US, or devices will need to add an explicit summer timezone.

I don't see how any of this is easier than staying on standard time and disabling daylight saving time, which every device that tells time that I've come across seems to support.

They would need a unique IP for every single repo. While this isn't a problem for IPv6, it is completely unrealistic for IPv4.

When github.example.com is configured as a CNAME to my-gh-page.my-repo.github.com, the IP that is returned will have no idea that it's my-gh-page.my-repo.github.com that is being requested as github.example.com will be what is sent in the Host header and part of the TLS SNI.

EDIT: I misunderstood what OP was suggesting. Pointing a CNAME to a repo specific domain name would work only if that name is removed after the repo goes away. As previously mentioned, this should not be Github's responsibility and it is a domain owners responsibility to properly maintain their records.

Going IPv6 Only 4 years ago

Their cloud platform doesn't even fully support IPv6, so I doubt they would do this before at least getting their own public offerings on board.