That said, i'm not impressed. A web-based solution is usually better performing, despite all the bloatware necessary. This says a lot about the state of software development unfortunately.

I just had to solve this problem recently. I've settled on Google Pixel Watch 4. There are some rabbit holes to go down though before it works reliably.

> PROPOSED MITIGATION. A straightforward mitigation is to have the client sign vault keys using the RSA private key in the keyset before encrypting them with the RSA public key.

> PROPOSED MITIGATION. [...] it would be easy for 1Password to prevent it entirely: the secret key can be used (with proper key derivation) to authenticate the KDF parameters with a cryptographic MAC.

To be fair, these issues are not really impacting long-time users. I have hundreds if not thousands of items in my vaults, there's no way i'm not noticing if they dissappear (which would be a side effect of these attacks).

Overall, I think 1password can be proud of their architecture and product quality, but i'd love to see these improvements - and maybe something like a "signal verification code" for sharing?

Saidly I don't remember the specifics, it was something along the lines of not all, but only specific routing features requiring it. Workspace settings are a moving target anyway, so the behavior probably changed more than once since.

I'm not saying it's a good idea to send emails without message id, but i'd also double-check that workspace configuration.

> The alert is not triggered immediately: it takes 8 hours during the day, 30 mins at night, and ...

But the warning system is by no means perfect. My family is split 50-50 between iOS and Androd ecosystems, and that's already enough to throw things off and get false positives semi-regularly.

Also, don't even ask the curriers how many alerts they get. Including airtags in valuable shipments is the de-facto standard nowdays.

It is a competetive advantage to reach our customers via their chat platform. Slack being the walled garden that is, it's basically a Slack-tax we pay.

Slack used to have a generous free tier, until they stopped having it.

The notable thing about this EoL is that it marks an end to the product line that Sourcegraph entered the AI coding assistant field with.

Comments URL: https://news.ycombinator.com/item?id=46639933

Points: 4

# Comments: 2

It's great that you can customize everything and use your own window manager, compositor, etc ... but these issues are the price you pay. It is unfair to compare this to Windows, where you don't even have these customization options.

Specifically for the network manager applet, it is not fixed because it's not really used anymore. GNOME Shell has it's own network selection menu that does not use the applet. It is the default on most systems, so users don't face this issue by default.

For our standards, we supply the strips with power at both ends and at every 5m in-between. (So an LED is at most 2.5m away from a supply). Your supply needs may vary significantly depending on the type of LED you use, these numbers worked for us on WS2812B 60led/m at 5V rail voltage.

> For long runs, do you prefer distributed power injection vs multiple smaller PSUs vs a higher-voltage backbone + local regulation?

Either should work fine, but when you use multiple PSUs or regularors, you may need to match their output voltage suprisingly precisely to get good results. A pair of thick copper wires is often easier.

> For addressable strips (WS281x/SPI/DMX), what are your go-to fixes for signal integrity over distance (grounding, buffering, differential, level shifting)?

WS28xx has built-in "reclocking" as long as your longest distance between two adjacent leds is <1m, you are absolutely fine. Be aware though that the number of chained LEDs impact your maximum refresh rate, which is an issue for animating. For a 60Hz refresh rate, you can't have more than ~250leds.

SPI is a nightmare over any distance. DMX is great if you respect the standard in terms of cabling and unit loads, but it i'm yet to see a DMX-enabled individually addessable LED strip. A DMX universe would be limited to 170 rgb or 128rgbw leds anyway.

> engineering patterns that scale and don’t become a maintenance nightmare.

Use a projector or a TV instead :-D

A migration is still possible, but needing to keep a client up and running to push up mails via IMAP will be a major painpoint.

Remote: Yes

Willing to relocate: Yes

Technologies: HW development, HW-SW integration, Phisycal Security, Big Data, Broadcast Television, special-use IP networks. (I prefer go, but code in C, C++, Python, PHP, Bash, etc...)

Résumé/CV: https://hu.linkedin.com/in/herczegzsolt

Email: hn@herczegzsolt.hu

I aim to maintain a very wide field of knowledge and specialize in integration between IT-related fields, especially in projects where both physical hardware and cloud is involved. I prefer fixed-term contract work even with recurring clients.

The only reason for me going with the Dell Premium 16 instead of framework, is that I need my 1920px screen width at 200% scaling.

Such a shame, the Framework is better in so many other ways.

1) I run services which give you different permissions depending on wheter you are local. Think a fileshare which is RW internally and RO externally. Yes, you could - and often should - do it differently, but IPv6 limitations should not be the reason that force you.

4) If a device does not work when connected to my network, but works on other, than this is my problem. Good luck explaining that it's a device bug to anyone. If they even understand it, they are not gonna care.

This specific case is only a practical issue, when you have multiple networks interconnected, because the "correct" local prefix is always closer than the erroneously cached one. Besides, with a public-addr-only* network, this is not an issue.

5) Yes, it is stupid, but nobody is going to blame apple for the issues it causes to other devices. It's a problem with the network!

I have no idea about the RA preference, i filter them away on the switchport. I may check sometime.

> As for the advertisement contents:

That is a misunderstanding. I meant to keep the network configuration simple in general, (like no ULAs, no splitbrain DNS, ...) not specifically the RA contents.

But now that you mention it: Android still does not support DHCPv6, so the "Other configuration" flag is a funny one. I also put the PREF64 address in the RA for the NAT64, because apple devices require it. Android uses the ipv4only.arpa dns lookup instead. Isn't it lovely how consistently they behave?

> As for DNS:

Well, we completely disagree on this for multiple reasons: - DNS over HTTPS and users connecting to other "privacy nameservers" or "adblocking nameservers" will not be solved by the low TTL - Also 60 seconds is not an acceptable time for outage when nothing is phyisically broken - That 60 seconds is often 300, because I have seen way to many recursors just extend TTL to a minimum of 5min. Again absolutely their fault and my problem.

[1] Just give them a "static lease" at the DHCP(v4) and it's never an issue again. Also, you should use DHCP-snooping (just like RA filtering) in switches all the time ;-)

*yes, there are still link-local addrs, but those are not used for any practical stuff, so it does not matter much.

::ffff:0:0/96 IPv6-mapped This space is intended for an OS or network stack to map IPv4 addresses towards higher layers, so applications could technically be IPv6 only. The packet was/will be standard IPv4 when it reaches the network wire.

::/96 and ::ffff:0:0:0/96 IPv6-compatible/IPv6-mapped These were originally intended to be used on networks to differentiate IPv4 addresses depending on the capability of the target and decide who will do the translation. These are now deprecated, but the whole ::/8 is reserved, and these addresses are promised to never be assigned to anything else.

64:ff9b::/96 IPv6-translated This is the space for IPv6 to IPv4 NAT translators. Actually the whole /48 is reserved, so you can run address multiple private translators in a single network if required. This is widely used and supported.

As a side note Teredo addresses (2001::/32) and 6to4 addresses (2002::/16) all embed the entire IPv4 address space, although they are more complex than a simple 1-to-1 mapping. They are rarely used.

When trying to connect to ULA from outside, that's not going to work.

When trying to connect to the public address from the inside, I face a firewal/config problem. Either I treat them as "outsider" and block/limit them incorrectly, or I need to dynamically update the setup to know what is internal.

2) DNS over HTTPS: which is forced by more and more things by default. They will always resolve to the outside address, even when on the local network. Causing the same problem as caching.

3) Source addr selection "stuck" on ULAs: When I loose the public prefix for a brief period, things tend to start using the ULA as a source for public destinations. This is not going to work as expected. However, when I get a new prefix, some things tend to be stuck for a long time on trying to use the ULA instead of using the new prefix.

4) I've seen devices incorrectly keep a ULA address from a different network, and attempting to use that on mine. This is definitely a bug in the device, but now it is my problem.

5) A variant of issue 4. is that some apple devices (TVs and similar) will just make up and start advertising their own ULA prefix. This is related to Matter support.

They should detect that there is already a ULA prefix and use that, but this detection is far from perfect, so sometimes they just do it anyway. Now my whole network has two ULAs. All devices should still use their "nearest" address to communicate, but - bugs again - sometimes they don't do that.

But hey, apple provides me with free pentesting to see if I have the RA filtering correctly setup in switches :-)

---

The list goes on, this is just what came to my mind immediately. There are really 3 conclusions I came to:

- Split-brain DNS is an outdated concept, being broken every day by new tech. You can't rely on the devices talking to the specific NS you want.

- There are a lot of buggy IPv6 implementations out there. Unless I control all devices on the network, I need to keep the advertised config very basic to keep everything working.

- Dual-stack and happy-eyeballs hide these issues too well. It is hard to detect and report them. Even if you do, vendors often just don't care or bother fixing because the issues do not have an immediate impact.

Remembering and communicating mildly complex byte sequences should be an issue which is solved already.

If you need IPv6 on Android, your only option is SLAAC.