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.
The games are on github (https://github.com/kennethpayne01/project_kahn_public/blob/m...) which might give better context as to how the simulation was run. Based on the code the LLMs only have a rough idea of the rules of the game. For example you can use 'Strategic Nuclear War' in order to force a draw as long as the opponent cannot win on the same turn. So as long as on your first turn you do 'Limited Nuclear Use' then presumably its impossible to actually lose a game unless you are so handicapped that your opponent can force a win with the same strategy. I suspect with knowledge of the internal mechanics of the game you can play in a risk free way where you try to make progress towards a win but if your opponent threatens to move into a winning position then you can just execute the 'Strategic Nuclear War' action.
From the article:
> They also made mistakes in the fog of war: accidents happened in 86 per cent of the conflicts, with an action escalating higher than the AI intended to, based on its reasoning.
Which I guess is technically true but also seems a bit misleading because it seems to imply the AI made these mistakes but these mistakes are just part of the simulation. The AI chooses an action then there is some chance that a different action will actually be selected instead.
reply