Kunix
Joined 14 years ago
Joined 14 years ago
It's similar to UUIDv7 (it leaks the creation time), but it's not an issue for me.
So I am able to have a single 64 bit key, which can easily be formatted into a small string for user-facing urls.
[^1]: https://instagram-engineering.com/sharding-ids-at-instagram-...
One question: It seems it could be troublesome to have to move / resize everything when adding a new card once a canvas is already quite busy. Is there something like auto-layout in the work, to handle these situations? (like to automatically re-layout cards and groups once adding a new item in between)
Recently switched to do the same on Notion, moving items in a "Worklogs" database at the end of each month (with one entry per month) to keep the Worklog size manageable. If a task gets too long I can just create a sub-page for it (or a toggle), put all the context information there, and just add a link to the TODO item.
As much as I recognize this can be good advice, this comment makes me sad.
It's like "start underperforming" is the answer given to bad management problems.
Which I agree actually makes sense in a lot of companies (if pro-active efforts are not already being recognized, then it's hard to change the culture).
I also think that a lot of comments here are directed toward financial success, but many people are actually looking for meaningful ways to contribute. People for which the "re-active" approach might not be a solution.
What would be the solution for those people? How unlikely is it to actually switch to a company which recognizes employees willing to be more involved?
It would allow to maintain versioned versions of always improving models everyone can update with a `npm update`, `git pull` or equivalent.
Question: Do you have something better to suggest? (something that could realistically get implemented)
Conventions like the one suggested here are the baseline on agreeing on common rules. It allows accountability, boundaries, and once accepted open the way to discuss possible sanctions.
I would much rather see positive steps like this one than no progress at all.
- I was expecting the package to either be revoked, or to have a new `6.1.64-2` version being published with the previously good known state.
Maybe it wasn't done because it was not possible (mirrors being write-only, and maybe other complications in publishing a 6.1.64-2).
- I was expecting some guidelines to be published for affected machines. I've seen questions being asked [1], but no answers to them yet (so users are not sure if it would be safe to rollback to the previous kernel version (6.1.55-1) or not).
Maybe it's because the problem is not well understood yet, or maybe there are not enough people available to answer such questions on a weekend?
If someone can provide some context about "how these things work", it would be interesting to learn more about this.
[^1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057843#33