sratner

ECMAScript 2024, the 15th edition, added facilities for resizing and transferring ArrayBuffers and SharedArrayBuffers; added a new RegExp /v flag for creating RegExps with more advanced features for working with sets of strings; and introduced the Promise.withResolvers convenience method for constructing Promises, the Object.groupBy and Map.groupBy methods for aggregating data, the Atomics.waitAsync method for asynchronously waiting for a change to shared memory, and the String.prototype.isWellFormed and String.prototype.toWellFormed methods for checking and ensuring that strings contain only well-formed Unicode.

From: https://tc39.es/ecma262/2024/

Plenty of contracts have survivorship clauses. In particular, non-disclosure clauses and IP rights are the ones to most commonly survive termination.

In more complex embedded software you are likely to see free lists used to manage pools of preallocated resources (like event structs etc) or pools of fixed sized memory buffers.

No memory allocation/reallocation, preallocated resources managed in e.g. a free list. Also for things like packetized networks, lists are handy for filling as you progress down the stack while using fixed sized packet buffers, or reassembling fragments.

In embedded world, memory often needs to be exactly controlled, and allocation failures are fatal without a more complex MMU. In kernel world, I believe the main reason is that allocations can block.

Sometimes the promo committee can't tell the difference, i.e. was the problem complex to warrant the complex solution. They just see the effort put into solving it.

It's a Long Now thing - emphasizing that they are thinking/talking about problems on millennia timescales. They also did the 10000yr clock: https://en.wikipedia.org/wiki/Clock_of_the_Long_Now

I got a green card while on E-3. Make sure your visa doesn't expire while you are in a no-travel period, as you might not be able to renew it if you have a pending change of status (or so I hear - was not applicable in my case).

Without any claim to the accuracy of the data, there is no incentive to list a salary on the LCA that is higher than required. You can always pay more, never less, so it only limits future flexibility. I have certainly paid higher salaries to individuals than what's listed on their LCA, not to mention total packages which aren't stated on the LCA.

To be fair, the reason for this is to account for clock desync between systems, so it wouldn't be correct to say it is still valid for 30 seconds where it might not be in reality. Knowing what this actually means requires understanding the implementation of TOTP, so that you are not surprised in situations where it does fail. The existing authenticator app UX is likely correct for the average user.

Not to disagree with the cumbersome process - just want to point out that TOTP codes are valid for 30 seconds after the "expire" (60 seconds total). So as long as you are able to remember / copy the digits, there is no need to wait for the next code even if you don't have enough time to type it in. It will still work.

Tangentially, I really wish authenticator apps continued to show the previous code for 30 seconds so I can continue to refer to it for apps that don't allow copy and paste.

At least it opens in default browser, and not hardcoded to Edge like other system stuff.

Another option for hiring outside U.S. without a local entity is to involve a global payroll provider for a reasonable fee (we have used Papaya Global, and Rippling does it now as well for certain countries).

A global payroll provider effectively acts as the "local employer" (they have a local entity in each country) and contracts out the employee to your company, so while the employment contract is with the provider, you can still sign all sorts of side-letter contracts like NDAs, IP assignments, stock grants etc without issue.

Pros are that unlike a contractor, the employee is subject to local labour laws and protections. Cons are that the employee is subject to local labour laws and protections (and the employer is subject to local labour taxes, which the payroll provider will pass through to you).

In certain countries with employee-favourable labour laws, we found it easier to attract employees this way, as they may be unwilling to forego the protections and social security / pension payments they would normally get as an employee.

[Edit: but beware of the double edge of course - if you ever want to fire such an employee, you may run up against said strong labour laws.]

An experiment (with temperature probe) here. Summary: temperature control is non-existent, temperature doesn't hold, and even if it did get to required temperature, one wouldn't have a way to know. https://youtu.be/dSwzau2_KF8 (at 18:11).

Not at all, but I do think it peculiar to be subject to what from my perspective is a random set of jurisdictions. Of course I understand why this is the case, but out of a handful of servers I looked at, only two specified where their data is hosted - for the rest, the same legal provisions obviously apply, but I have no way of knowing what they are.

I also don't know the specifics of German law, so the fact that my account could get suspended for violating something I am not aware of is peculiar in itself. The point is that there is no single privacy policy and single jurisdiction to worry about - it is a guess, depending on where the instance is hosted, and may even move under you without notice.

[edit: I am in the process of selecting an instance personally - I have not decided yet, and the process of picking one seems somewhat fraught.]

I haven't seen any servers with peculiar rules.

I have seen two just today, listed explicitly in the rules of distinct servers, without particularly looking:

• No content that's illegal in UK or Germany.

• No crypto.

Currently some number of versions are also on humble bundle: https://www.humblebundle.com/software

The dive reflex thing is fantastic. I find that it works even with warm water for me - in the shower, just inhale, hold your breath and let water run directly over your face. A wave of calmness just washes over, the feeling is quite strange and amazing, and I am constantly surprised by its immediacy.

By tracking all devices, noting when one address disappears and a new one appears, and correlating it with the perceived signal strength to reasonably guess whether this is the same device vs. a new one entering your detection radius. On top of that, there is often a fair amount of information besides the address in the contents of the advertisement packet, the set of services this device implements, battery level, manufacturer data fields, ... - much like browser fingerprinting by checking for fonts and canvas edge cases.

Maybe not easy, but also not hard. The only thing that screws you up is someone playing with the airplane mode toggle of their phone while moving within your detection radius.

Any single SSS share does not disclose any additional information about the private key (i.e. it is not like splitting the key itself into parts).

Most phone snatchers aren't after the information on the phone. The point is not that this would not be a targeted attack (it would be), but that it might not require a particular combination of circumstances or set-up to follow one around and snap just-the-right-angle photo.

There is a reasonable chance that the print is available on the very device it is needed to unlock (the phone screen, for example), perhaps enough for a thief who snatches your phone to have a decent chance.

Is there a reasonable explanation why the new Pay app doesn't work with custom domain / business accounts? I am guessing it isn't resourcing.

The old one did; luckily I can still use that with my personal profile until I upgrade my phone, unluckily I didn't install it in time on my work profile - which is where I pay for many more things.

[Don't mean to bash on you personally, it doesn't sound like you are even on the app team, just annoyed by the downgrade.]

This isn't the punitive part - that's what fines are for.

I see this particular requirement more as a corrective action - to actually give back to users the choice that Google took away through abuse of their market position. Users don't particularly care who is making money in the process, while their rights are not infringed.

I am perfectly fine with the corrective action being dollar-neutral for Google, or even slightly positive. There is nothing wrong with incentivising good behaviour, as long as those incentives themselves don't become abused. If the right thing to do by your users is also the better thing to do from a business perspective, we might not have to wait for a court decision next time.

It is often more precise, not necessarily more accurate. People often don't distinguish between the two.

I haven't run into that use of -0000, that's insane.

I suspect a side-effect of libraries lacking support for the full range of ISO8601 (for example, refusing to parse a value without an offset, forcing people to use such hacks). Wouldn't surprise me; iOS doesn't even have a consistent way to parse ISO8601 values with and without milliseconds.

[edit:

Apparently this is a RFC3339 thing, did not know that: https://tools.ietf.org/html/rfc3339#section-4.3

Negative zero offset is invalid in ISO8601, but valid and carries the meaning you describe in RFC3339. I misread what that meaning actually is from your comment - it is different to a "floating" or unqualified local time, it always represents a UTC time but with an unknown local time offset. ]

It wouldn't really be much different if we had ISO8601.1 and ISO8601.2, would it? The standard can define two different types, and it makes it clear what it means to have a time without an offset specifier. It also defines formats for durations, intervals, and repeating intervals.

Is the distinction in representation too subtle?

We accept this subtlety elsewhere; we are used to 0 and "0" being different things, and expect them to behave differently under operators. Few would find the following surprising:

    0 + 0 == 0
    "0" + "0" == "00"

   20200710T010000Z + `3 hours`
   20200710T010000 + `3 hours`

ISO8601 is a representation standard, not a standard for abstract concepts.

https://news.ycombinator.com/item?id=23783603 called for Unicode but for Time, which I think is perfect. In that framing, ISO8601 is UTF-8, but it is Unicode that is needed for everyone to agree on what is "code point" and what is a "character" (equivalently, what is a "calendar date", what is an "absolute timestamp", etc).

consider offsets (Z or -0500 etc) required rather than "optional"

ISO8601 without an offset is semantically different to one with an offset, it represents a time in local timezone (context-dependent). It isn't an "optional" offset in the sense that you can just omit it, it is a fundamentally different data type.

Without this distinction, there is no way to specify a local time in ISO8601, which would be highly inconvenient for certain applications. For example, how do you represent an event that occurs at 9am every day regardless of location? After all, dates and times are used for more than just storing absolute timestamps.

You are absolutely correct that offsets are also not timezones, which makes the ability to specify local "floating" times even more important (i.e. you can't just denormalize the above concept into a list of timestamps with offsets for each timezone you care about, as the offsets will change over time [edit: and tz->offset conversion is lossy and not reversible]).

Personally, I prefer Luxon's timezone handling. I get the appeal of not providing custom classes, but _actually changing the underlying timestamp_ to adjust for timezone has always caused nothing but trouble for me. It becomes an all-or-nothing system (you must use `date-fns-tz` to manipulate the dates) with nothing to actually enforce that.

The difference is that you can continue tracking a person indefinitely, even after they are no longer infectious. It requires explicit user action to avoid that (opt-out vs opt-in).