Putting work in a queue is only the start. Most organizations start there and gradually write ad hoc logic as they discover problems like dependencies, retries, & scheduling.
Dependencies: what can be done in parallel and what must be done in sequence? For example, three tasks get pushed in the queue and only after all three finish a fourth task must be run.
Retries: The concept is simple. The details are killer. For example, ifa task fails, how long should the delay between retries be? Too short and you create a retry storm. Forget to add some jitter and you get thundering hoards all retrying at the same time.
Scheduling: Because cron is good enough, until it isn't.
A good workflow solution provides battle tested versions of all of the above. Better yet, a great workflow solution makes it easier to keep business logic separate from plumbing so that it's easier to reason about and test.
Would "we screwed up by blindly trusting ChatGPT" annoy you less? Because that's how I read it.
Or more specially, given the context: "We were in a rush to translate a bunch of code and ChatGPT was doing such an impressive job helping that we became complacent and forgot that it just parrots back text it has seen before with something that looks like intelligence but without actual comprehension. So when it copied a common bug, we weren't paying enough attention to catch it."
Line 56 is executed as the file is loaded. Simplified, the line is essentially:
id = Column(default=str(uuid.uuid4()))
As written, a UUID is generated once and used to set a class-level attribute. Each Python process would generate a unique value, so it wouldn't be immediately obvious. Most of the time Python's ability to run code as a file is loaded is helpful, but this is one the well known gotchas.
Although I'm not a SQL Alchemy user, I assume the fix is essentially the same as it would be for Django. So the correct code would have been essentially:
id = Column(default=uuid.uuid4)
Instead of executing `uuid4()` and caching a single UUID value, it would have executed `uuid4()` each time a new object was created.
The author defined fair in a pretty industry standard way:
> One user should not be able to block another's work.
A multi-tenant architecture implies over committing resources to achieve better economics. Once upon a time, decades ago, when computers were so expense that companies payed for batch processing instead of owning their own, FIFO was acceptable. (And for a tiny part of the market it still is.) But ever since the rise of time-sharing operating systems, users have come to expect short delays for small tasks. If you let one customer monopolize your capacity because they submitted a mountain of work before a second customer submits a handful, you probably won't have the second customer much longer.
Was just going to say, they're merely making more obvious a situation that has long existed. But most people don't bother checking if packages they depend on are part of `main` or `universe` so I can see how this comes as a shock to some.
Ubuntu makes this worse by using "end-of-life" dates as End-of-ESM at various pages[0,1]. If you read that page, you'll assume all packages will be supported till EOL for all users. This is all it says about ESM:
> Extended Security Maintenance (ESM) provides security updates on Ubuntu LTS releases for additional 5 years. It is available with the Ubuntu Advantage subscription or a Free subscription.
The Pro page[2], now has a clear graphic comparing the security coverage, but this appears to be new.
Indeed. I see Ubuntu 20.04 imagemagick was updated with a security update in 2021 for free. Now, there is another update for imagemagick, but we have to pay for it.
The https://ubuntu.com/pro page says "best effort" for universe packages. Yet, they have an update for imagemagick, we just have to pay for the pro subscription to get it. How exactly is that "best effort"?
That doesn't really clarify things. It just says universe is supported by the community. Right now, we have an update for imagemagick, but we have to pay for it, whereas last year we had updates to imagemagick for free. How is that "best effort"? What they mean is, they are now putting more effort into universe, but you have to pay for the updates.
I don't mind having to pay for these updates if necessary. They should just be honest and transparent about what they are doing.
Looking into this further, I see that Ubuntu 20.04 has an identical version of imagemagick to that on Debian 10. This is a security update to imagemagick from 2020:
There are no later versions of imagemagick on ubuntu 10. So, my guess is that Ubuntu has (and will continue to) take any security updates that appear in the upstream Debian release, and add an Ubuntu Universe package for them. Now, I'm guessing, there will be additional security updates in the Universe package set for users paying for Ubuntu pro, where those packages are not available on Debian (i.e. Ubuntu themselves will package them).
If that's the case then there is nothing nefarious going on, just Canonical didn't explain it very well.
But are they now continuing to ship the known-vulnerable version in universe for new installs moving forward, but then notifying the user that an up-sell opportunity exists if they want the fixed version?
There are lots of security updates in the source code for the packages. Major vulnerabilities will (presumably) have Debian package updates, and those should continue to be ported to Ubuntu. What will happen now is that Ubuntu themselves will sometimes port security updates to Ubuntu even when there is no community (debian) update upstream. At least, that is based on my own analysis (see my other comments).
So, I think this is just a new offering from Canonical, allowing us to pay for more minor security updates to the Universe packages. But they explained it very badly!
> Why would you decouple the change from its context?
The issue is the context.
At work, we require a link to the issue/story because it makes SOC2 audits much easier. The commit message is a great place to explain the chosen implementation, but that's not all there is to software development.
It rarely makes sense to repeat in commits how the issue was reported, or why it was given a specific priority. And it can't track anything after merge, like how the change was tested, or whether the change was communicated to users.
Maybe you don't have to deal with auditors. Maybe your work has different processes to keep them happy. But as far as I'm concerned, is it important to link the issue for context? Yes! Just yes.
Experience has shown that often “worse is better”. Go does an amazing job of balancing complexity and power. I haven’t seen a ”better” language that isn’t either slower, harder to become productive, or both.
