Looking at the function the addr value should always equal end but also it looks like on x86 this value is discarded in pte_free_tlb so maybe this is not the problem or I’m looking at a different version.
In the UK you can make an order of information to compel directors of a company that is in debt to answer questions about company assets, accounts and records under oath. This can be done in County Court and my understanding it is inexpensive. I'm not sure how useful this is for carrying out an audit because I think its meant to be used for seeing if the debtor has the ability to pay. I think generally incorrect trading during an insolvency is meant to be discovered by the receivers during the insolvency process. Also, I'm not sure if there is an equivalent to an order of information in the US system.
I think if the consignor has not taken the correct steps then there is a risk the receiver would be able to pay other secured creditors using the consignors assets. For example if there are other creditors with liens on the inventory then you are meant to take steps to notify them of your claims on the consigned goods because otherwise the consigned goods could look like inventory to the secured creditor (https://www.lowenstein.com/news-insights/publications/articl...)
hackernews capitalising Int makes this question kind of confusing. Because the question is meant to be about c++ behaviour but `Int` is not a standard c++ type. But Int is not java because java uses Integer and `Int` is not c# because c# has uses the explicit IntBitsize types. I think maybe the only languages where the title makes sense in is Scala or Swift.
I think the original commenter confused taking the CUBIC implementation from the kernel and rewriting that in Rust for use in their QUIC implementation or they just jumbled their wording. It does make sense to use an existing battle tested implementation of a congestion algorithm because there are potential many real world failure modes that you might not anticipate if you try and write an implementation from scratch.
It basically makes no odds, unless you consider applying a constant AND and constant OR operator complicated - as UUID v4 is just 122 random bits and 6 bits fixed.
UUID v7 is a 48 bit timestamp, 74 random bits and 6 bits fixed. Sure, this is a little more complicated, but it's often worth it for many applications because it can be sorted, so keys will be approximately monotonically increasing.
I think UUIDv7 could make sense but I suspect the recommendations in the spec predate UUIDv7. Also, if you want sorted schemes then there are slightly more efficient schemes than UUIDv7. With UUID you are always sacrificing some bits to distinguish between the UUID types which I guess does not really matter in practice but it seems unnecessary.
Yeah, in practice the 6 bits you lose aren't important. Redoing his calculations with 122 bits and a quadrillion generated IDs (that's a million billion), the probability of a collision is 9.4 x 10^-8 (or one in 10 million) using UUID v4.
In my opinion, UUID v7 is useful because you per millisecond, you still have 74 bits split between user defined (up to 12) or randomness (minimum 62). If you choose the minimum 64 bits randomness, you can read the numbers straight from the article - 1 million UUIDs per millisecond with less than one in a million chance of collision, but you still have 10 bits to add additional data, such as which machine generated it.
If you stick with just time and have the full 74 bits of randomness, you can generate a trillion (10^12) UUIDs per millisecond with less than one in 40 billion chance of collision (2.6 x 10^-11) using UUID v7.
I think the fact the formula is (k^2/2N) actually shows that having a time component makes better use of the bits than a purely randomised space. In this example, we have a lower chance of collision with a trillion (10^12) UUIDs generated per millisecond than a quadrillion (10^15) UUIDs across all time.
BTW I realised I didn't address why those bits are necessary - actually, while it might seem you are increasing randomness with more bits and so reducing the risk of collisions, that's not necessarily true.
The old schemes generated numbers that weren't uniformly distributed across the 128-bit space as they were intentionally biased in certain ways, such as time [0] and MAC addresses [1]. This means that most of the IDs generated in previous schemes would have many bits in common, and so the UUIDs that had been generated were not uniformly distributed across that 128-bit space [2] and so if you just used the whole 128-bits for random data, but didn't use those extra bits to avoid conflicts with the previous schemes, then random IDs that happened to be valid in the previous schemes would be more likely to collide.
Of course, this only matters if the properties of globally unique matter to you. For a closed system with a guaranteed scope, sure who cares? But given that the extra randomness doesn't add any useful value beyond a certain threshold, you might as well use a UUID because you don't know what that identifier might end up being used for in the future, plus you can use off-the-shelf systems to generate them.
[0] Ironically, future proofed time fields with many bits are more likely to be non-linearly distributed - e.g. the original version 0 UUID supported timestamps from 1582AD to 5236AD but was only used from 1987 for around a decade.
[1] With certain manufacturers of network cards massively more popular than others, their MAC address prefixes showed up significantly more frequently, and there were privacy concerns were you could correlate between UUIDs generated on a single machine, and sometimes infer machines that might be on the same network because they had similar MAC addresses and so the cards were probably all from the same manufacturing batch.
[2] Which is fine within the scope of UUIDs as they are still very likely to be globally unique, so it doesn't really matter if bits are wasted in this scheme
And there’s a good reason for that, because UUIDs have additional properties. I don’t know if versioning, partial ordering, or stable references are useful for traces or not, but with UUIDs those could’ve been a possibility.
The problem with Apache 2 is it might not be completely clear how this works with a Saas product. Of course if you are distributing binaries or source to customers then you are going to run into issues with Apache Licensing. But if you are just running code on your servers then its not so straight forward. However, I guess its likely they were distributing javascript code so that could be a problem for them. Also, I guess regardless of the licensing issues not being honest with your customers when you are a compliance company is not going to be great for business.
it seems like if these statements that were part of the grants were 1FA protected then they should not have been part of the grants in the first place. since having 1FA protected statements in the grants allows the government to compel speech by favouring grants that make approved statements in the same way they can suppress speech by targeting grants that include disfavoured statements. people were previously claiming certain buzzwords needed to be included in order to hurdle the grant process. of course this is probably completely unworkable in practice since you need some kind of description of the grant and almost anything could be seen as some kind of speech that might be favored or punished for political reasons.
What do you mean by 1FA? It reads like your saying "Grants should not include first-amendment-protected statements," but that is not how the first amendment works. It's passive; speech is protected by default.
https://github.com/torvalds/linux/blob/master/mm/memory.c#L1...
Assuming addr is a virtual address it probably makes sense that pte_free_tlb does not need it.
https://github.com/torvalds/linux/blob/master/arch/x86/mm/pg...
reply