Which wouldn't be that weird, except that the earliest Roman calendar started in March and ended in December, having only 10 months!
The Romans were of course well aware that this left a gap of about two months between the end of one year in December, and the beginning of the next year in March. But they just didn't bother counting this period as part of the calendar year. Presumably because there was no agricultural reason to need accurate dates during winter.
I'm French and occasionally like to (re)read about the revolution period and every time I come to the calendar stuff I can't help but think "Really? This was stuff we wanted to spend time on?"
AIUI, there is some confusion over whether this is actually the case. The pre-Julian calendar had 12 months, plus an optional intercalated month (they were aware that their ‘year’ had the wrong number of days, and periodically shoved in some extra time to patch it up). The 10 month calendar, if it existed, would have been very early and there’s not much hard evidence that it was actually used. Numa Pompilius, who was allegedly responsible, is a mythical figure and probably not an actual historical king.
CBP's declaration (which the article links to) has more details. They're arguing that they can't currently issue refunds, and they can't even currently stop IEEPA duties from being charged on future liquidations, because of software limitations.
They say they're going to comply with the order, but they want 45 days to develop the required software changes and processes.
Of course it's worth noting that CBP repeatedly argued in its previous court filings that there was no need for an injunction to halt the tariffs while they were being litigated, because if the tariffs were found to be unlawful, it could easily refund them.
For instance:
> In other words, plaintiffs’ asserted irreparable harm is the purported inability to obtain a refund after a final and unappealable decision because of liquidation. But that asserted harm is nonexistent here because defendants have made very clear—both in this case and in related cases—that they will not object to the Court ordering reliquidation of plaintiffs’ entries subject to the challenged IEEPA duties if such duties are found to be unlawful. Because defendants’ representations make clear that liquidation will not interfere with the availability of refunds after a final decision, plaintiffs cannot be irreparably harmed by liquidation.
We need some mechanism in litigation (and imho in public life in general) that requires claims to be secured in some way. That is, if you go into court and make an argument like this, you have to chain it to consequences, such as being stripped of specific legal consequences or losing 10% of your shares or whatever.
It's illegal to commit perjury, but there are no real consequences for making bous legal arguments, and lawyers are structurally incentivized to make tacit misrepresentations on behalf of their clients - that is, to make inflated or handwavey claims in the hope that they're not challenged during the fact-finding stage, or even stipulated, due to an assumption of basic good faith.
> because if the tariffs were found to be unlawful, it could easily refund them.
I think it's worth emphasizing that the US government argued not only that it could issue refunds, but that it would issue refunds and that it would not oppose an order to do so. In addition to the quote from the US government's opposition to a motion for preliminary injunction, there are these quotes mentioned in the opinion for the linked order [0]:
> [E]ven if future entries are liquidated, defendants do not intend to oppose the [c]ourt’s authority to order reliquidation.... Such reliquidation would result in a refund of all duties determined to be unlawfully assessed, with interest.
> Defendants “will not oppose the [c]ourt’s authority to order reliquidation of entries of merchandise subject to the challenged IEEPA duties and that they will refund any IEEPA duties found to have been unlawfully collected, after a final and unappealable decision has been issued finding the duties to have been unlawfully collected and ordering defendants to refund the duties.”
> “If tariffs imposed on plaintiffs during these appeals are ultimately held unlawful, then the government will issue refunds to plaintiffs, including any post-judgment interest that accrues.”
> For any plaintiff who is an importer, even if a stay is entered and defendants do not prevail on appeal, plaintiffs will assuredly receive payment on their refund with interest. ‘[T]here is virtually no risk’ to any importer that they ‘would not be made whole’ should they prevail on appeal. The most ‘harm’ that could incur would be a delay in collecting on deposits. This harm is, by definition, not irreparable. Plaintiffs will not lose their entitlement to a refund, plus interest, if the preliminary injunction is stayed, and they are guaranteed payment by defendants should the [c]ourt’s decision be upheld. And defendants do not oppose the reliquidation of any entries of goods subject to IEEPA duties paid by plaintiffs that are ultimately found to be unlawful after appeal.
> To the extent that any future entries are liquidated, the [c]ourt may order reliquidation of entries subject to the challenged de minimis exemption if the duties paid by Axle are, in a final and unappealable decision, found to have been unlawfully collected. Such reliquidation would result in a refund of all duties determined to be unlawfully assessed, with interest.
Given that OpenAI is working with and doing business with the US military, it makes perfect sense that they would try to normalize militaristic usage of their technologies. Everybody already knows they're doing it, so now they just need to keep talking about it as something increasingly normal. Promoting usages that are only sort of military is a way of soft-pedaling this change.
If something is banal enough to be used as an ordinary example in a press release, then obviously anybody opposed to it must be an out-of-touch weirdo, right?
That doesn't mean there's a problem with the code, only with the documentation. So the article is wrong to call it a "real bug". At most it's poor code style that could theoretically lead to a bug in the future.
There's nothing inherently wrong with a function throwing an exception when it receives invalid input. The math.sqrt function isn't buggy because it fails if you pass it a negative argument.
“Two popular AES libraries, aes-js and pyaes, “helpfully” provide a default IV in their AES-CTR API, leading to a large number of key/IV reuse bugs. These bugs potentially affect thousands of downstream projects.”
Would you call that “poor code style that could theoretically lead to a bug in the future”, too?
The API in question is almost certainly internal. The only reason it isn’t marked as such is because Python doesn’t have great facilities for that kind of encapsulation.
Invariant-preserving types are always going to be the right way to eliminate certain classes of bugs, but they’re also completely overkill in this context given that the “bug” in question doesn’t even cause unsound program behavior; it just raises an exception, which is completely sound and well-defined.
If companies are taking raw materials worth more than zero, and turning them into clothing worth less than zero, then I think deterring them from doing that is beneficial to society overall.
If they knew in advance that the clothing wouldn't sell, they would never have made it!
But companies stockpile goods in anticipation of potential demand. For example, they'll "overproduce" winter coats because some winters are colder than average. This sort of anti-overproduction law means that the next time there's an unexpected need -- for example an unusually cold winter -- there will be a shortage because there won't be any warehouses full of "just in case" inventory.
They could, but it’s a tradeoff. Inventory costs money and if you cut production, that means laying off workers and possibly selling productive assets, at which point it becomes more expensive to scale production back up.
Every business decision is a tradeoff. Smart government interventions in the economy add weight to that tradeoff to reflect externalities not otherwise accounted for; this is how cap-and-trade on SO2 emissions works. Hamfisted government interventions set hard and fast rules that ignore tradeoffs and lead to unintended consequences.
I don't think this is accurate. It's more that the textiles are produced in Asia and transported in containers.
Due to the high shipping costs, they err on the side of filling up the containers to cover the fixed cost. After selling the clothes, there might be enough clothes left over to fill shipping containers to return the clothes, but they will be clothes from different brands and manufacturers.
It would require extraordinary coordination on both the origin and destination country to return the clothes to the manufacturer where they could add the left over clothes to the next batch that is being shipped out to a different country.
Do we really need warehouses full of "just in case" inventory? It's not life or death, it's just slightly more profitable for companies to overproduce than it is for them to attempt to meet demand exactly.
Climate change is coming, fast and brutal. I'm okay with these multi-billion-dollar revenue companies making a few points less in profits, if it means slowing climate change by even a fraction of a fraction of a point.
They don't need those profits. But our children need a viable planet.
Companies can't meet demand exactly, no matter what profit margin they take, because it's not possible to predict demand exactly. Biasing towards overproduction is how you minimize the risk of shortages when there's a bit more demand than you expected.
as far as a market clearing problem goes, we should be forcing them to sell it at lower and lower prices, or even going to negative and payoyng people to take it off their hands.
supply and demand is that an oversupply makes prices fall, rather than driving artificial scarcity
Well, it sounds like that's what the EU is going to try. My guess is that the manufacturers are mostly destroying stuff for economically rational reasons, and will respond with production cuts leading to that same artificial scarcity from a consumer perspective.
(Although the original commenter would say, I suspect, that it's perfectly OK if there are minor consumer shortages in luxury goods for the sake of the climate.)
> This sort of anti-overproduction law means that the next time there's an unexpected need -- for example an unusually cold winter -- there will be a shortage because there won't be any warehouses full of "just in case" inventory.
Clothes are something extremely overabundant in the EU. And even if they weren't, the unexpected overdemand will result in just using your old coat another year or buying one you like less. Workers are being unnecessarily exploited and resources are being unnecessarily wasted... so I think nudging companies in the right direction is way overdue. Will it work the way EU thinks? Probably not. Just like GDPR was well-intended, but the result is higher entry barrier to new companies and a bunch of annoying popups. But I'd argue that's a result of "not enough" regulation rather than "too much". Companies caught abusing our data should have been outright banned IMHO.
What about cases where 2 pieces of clothing when bundled together have value due to making it more efficient for people to find the right size, but over the right size is found the other becomes waste? A company can't prevent a consumer from ruining the wasted clothes.
But that is how physical stores currently work, where you can try the stuff on, before you buy it? If you care about this, you can of course take the upper one to try on, like all do and then buy the lowest one. But you wash the clothing anyways before actually wearing them, so it doesn't really matter. Honestly I don't get your point.
This thread is talking about vibe coding, not LLM-assisted human coding.
The defining feature of vibe coding is that the human prompter doesn't know or care what the actual code looks like. They don't even try to understand it.
You might instruct the LLM to add test cases, and even tell it what behavior to test. And it will very likely add something that passes, but you have to take the LLM's word that it properly tests what you want it to.
The issue I have with using LLM's is the test code review. Often the LLM will make a 30 or 40 line change to the application code. I can easily review and comprehend this. Then I have to look at the 400 lines of generated test code. While it may be easy to understand there's a lot of it. Go through this cycle several times a day and I'm not convinced I'm doing a good review of the test code do to mental fatigue, who knows what I may be missing in the tests six hours into the work day?
> This thread is talking about vibe coding, not LLM-assisted human coding.
I was writing about vibe-coding. It seems these guys are vibe-coding (https://factory.strongdm.ai/) and their LLM coders write the tests.
I've seen this in action, though to dubious results: the coding (sub)agent writes tests, runs them (they fail), writes the implementation, runs tests (repeat this step and last until tests pass), then says it's done. Next, the reviewer agent looks at everything and says "this is bad and stupid and won't work, fix all of these things", and the coding agent tries again with the reviewer's feedback in mind.
Models are getting good enough that this seems to "compound correctness", per the post I linked. It is reasonable to think this is going somewhere. The hard parts seem to be specification and creativity.
That sounds like it's basically impossible to implement your own non-trivial data structures. You can only use the ones that are already in the standard library.
For instance, how would you represent a binary tree? What would the type of a node be? How would I write an "insert node" function, which requires that the newly-created node continues to exist after the function returns?
I'm not necessarily saying that this makes your language bad, but it seems to me that the scope of things that can be implemented is much much smaller than C++.
The Romans were of course well aware that this left a gap of about two months between the end of one year in December, and the beginning of the next year in March. But they just didn't bother counting this period as part of the calendar year. Presumably because there was no agricultural reason to need accurate dates during winter.
reply