That said, knowing the commit ID something is fixed in, so that the PM can track what build it emerges in is useful.

If a developer is being asked to do that, it's a good sign that the PM isn't doing their job properly.

[PRJ-123] Changed blah to foo

Blah didn't handle the wangle flange properly in some cases, foo is a better fit for customer requirements.

The "why" that justifies the change, is already contained in the JIRA ticket PRJ-123 and explains exactly what the customer requirement was that necessitated the change. It will almost certainly contain a lot of detail that isn't relevant to the commit message, because that isn't the place to be documenting customer requirements, and probably relates to a number of other tickets. Perhaps the code itself might have a comment explaining the code change, if it's a non-obvious implementation, but otherwise the ticket is the best place for that information.

Additionally, if a change requires multiple commits, you don't want to be repeating the justifications for the entire feature in every commit message. It's redundant. But the commits will all be tied together by the ticket reference in the commit message.

In over 30 years of using source control, I've never once worked on something where it's useful to include the component (article calls it scope) in the description in a standardised way. It's obvious what components are affected based on where in the source tree the affected files are. Similarly "bug", "fix" or "feature" adds no useful value. It's important or it wouldn't be checked in.

The only thing I've found useful, and which the article doesn't even consider, is a link / id for the relevant change request. The commit already contains all the information about what was done in the change, what's missing is the context about why.

Even on my solo projects I include a JIRA reference in square brackets before the description. If it's just something I randomly decided to fix during the course of development, I'll create a short 1 line JIRA to get an id and explain the why there.

Assuming you mean for a VPS, the majority of providers provide IPv6, and a good many would advertise your IPv6 prefix and route it to your box for a nominal fee. It's far cheaper to do anycast IPv6 than IPv4 because of the cost of IPv4 address space.

If you actually meant on-site for a business, that again depends on your provider, but again most providers should be able to give you a static IPv6 prefix from their own range if they're able to provide you a static IPv4 address. If not, you can always tunnel IPv6 to your site.

GPS is suprisingly low power. I believe the satellites themselves transmit between 20W and 50W, and in general the signal is quieter than the background noise threshold. It's only by correlating with the PRNG stream [1] that the data signal can be detected at all [2].

[1] The PRNG stream is 1023 bits at 1.023Mbps, so repeats every 1ms, and only autocorrelates with the correct stream when they are aligned. When the streams are not aligned, the data looks like random noise, and each transmitter has a different LFSR configuration to provide a different sequence such that each stream has a low level of correlation with another.

[2] The PRNG stream bits at 1.023Mbps are exclusive-or'd with the data stream at 50bps, so when the decoder is using the correct PRNG and sequence offset, exclusive-or'ing with that produces detectable long pulses at the expected 50bps.

In addition, that's just the initial IPO free float value, and other shareholders will be free to shed their shares after IPO (and presumably, that's where the bulk of index investment funds will actually buy from), so the free float will be higher, pushing up that share even higher.

Sure, in terms of overall market fluctuations, 0.5% is significantly less than a typical day of market volatility, but on the other hand in terms of my current portfolio, as a dollar amount that's significantly more than my monthly expenditure when I'm not vacationing. I don't particularly want to be funding Elon's exit strategy when I already believe it to be a scam. Thanks to S&P's decision, about 25% of my investments are safe, but approximately 60% of my funds are linked to FTSE World indicies, which is changing the rules.

As I stated in another post, this is just a cheap stunt to force passive investors to prop up the price before it has a chance to settle. The majority of IPOs settle on a price below the IPO price in the months afterwards, and never before have we seen an IPO with such a high P/E ratio. This is literally unprecedented, and the sensible thing to do would be to stick to the old rules to allow the market time to discover the true value before inclusion in the indices. At the moment, the valuation is just a number in Elon's head rather than a fair market valuation. Forcing index-following funds to purchase it at the artificially high price is reckless at best and profiteering at worst.

In addition, it's not just 0.5%. It's 0.5% now, and then the same for Anthropic, and then the same for OpenAI, then all the other IPOs in the future. To put that into perspective, most investors would baulk at 0.38% TER for a passive fund and move to 0.12% TER. 0.5% isn't nothing.

All we have at the moment is just Elon saying "I think this is worth $1.5T, convincing a small subset of people to buy shares, and then because of this change, market following funds will be forced to pile in before the market has had time to discover the actual true fair price, thus artificially propping up the price until Elon has had time to unload a load more shares. The rule changes serve only Elon, not regular investors.

Historically, the share price falls sharply after an IPO in the vast majority of cases. In this case, with the asking price masssively over earnings, significantly more than any other company, it should be expected that the price will fall significantly in the weeks after IPO.

Shortening the window before it gets included in the index is a cheap trick to force passive investors to pile in at the inflated prices, in an attempt to artificially boost demand and prop up the share price.

If the company genuinely was worth the valuation being asked for in the IPO, they would have no problems with just waiting a few months before it would be included under the existing rules.

People often have a vested interest to lie about themselves, and often people may not remember historical details about their lives as accurately as they believe they do.

That said, "no really, I am still alive" seems like something that should be trusted as a source.

But essentially, using UUID v7 you actually have less risk of collisions than with UUID v4.

Because of the birthday paradox, if you have N bits of randomness, you can expect a collision approximately after (2^((N/2)-1)) random numbers.

With v4, you have 122 bits of entropy over all time, so will see a collision after 2^60 allocations, approx 1.2 x 10^18.

With v7, you sacrifice 48 bits of entropy to give you 74 bits of entropy every millisecond, so you will see a collision after approximate 2^36 allocations per millisecond, approx 6.8 x 10^10 per millisecond.

You could argue that the risk of a collision is too high per millisecond because it's likely that 68 billion UUIDs are generated every millisecond. And maybe I'd agree. But the counter argument is that with v4 you'd expect a collision after 2^24 milliseconds, or 280 minutes, allocating at the same rate of 68 billion UUIDs per millisecond.

Obviously "all time" is longer than "280 minutes", so v7 is actually statistically less likely to cause collisions than v4, even though it seems counter-intuitive because it has a smaller space devoted to entropy. The key insight is that the time provides bits that are guaranteed to be unique, so only collisions within the same timestamp are significant, and every bit used to provide known-unique values is worth 2 bits of entropy.

That's generally enough IDs per second for most of my edge nodes, but the central worker nodes need more, so I give them a different split and use 4 bits for the device ID and 28 bits for serial number instead.

If a node overflows its serial number that second, I kind of cheat and increment the seconds field early. Every time this happens, I persist the seconds field to the database, and when the app restarts, it starts its seconds count at the last persisted seconds plus one. If the current time in seconds is greater than the last used seconds, I also update it and reset the serial number. Works remarkably well for smoothing out very occasional spikes in ID generation while still approximately remaining globally sortable.

I also "waste" a bit of the 32-bit time field by considering it to be signed, even though it's not really because I don't expect this system to last long enough to reach times where the MSB gets set. But if I ever change my system, I'll set that bit and everything will stay ordered. I'll probably reset the epoch at that point too.