singron

Google docs has gotten a little better in that time, but it's honestly surprisingly unchanged. I think what really changed is that we all stopped wanting to layout docs for printing and became happier with the simpler feature set (along with collaboration and distribution).

It's not clear to me that fine-tuning is even capex. If you fine tune new models regularly, that's opex. If you mean literally just the GPUs, you would presumably just rent them right? (Either from cloud providers for small runs or the likes of sfcompute for large runs) Or do you imagine 24/7 training?

I think this also requires user (i.e. unprivileged) namespaces since you have to manipulate traffic control queue disciplines (tc qdisc). You normally need to be root to do this, so it's only useful as an escalation if you can do it within a namespace or you can convince some root daemon to do the qdisc manipulation for you (I think unlikely?).

User namespaces opened up an enormous surface area to local privilege escalation since it made a ton of root-only APIs available to non-root users.

I don't think user namespaces are available on android, and it's sometimes disabled on linux distributions, although I think more are starting to enable it.

Relatedly, kernelCTF just announced they will be disabling user namespaces, which is probably a good idea if they are inundated with exploits: https://github.com/google/security-research/commit/7171625f5...

wasd are the default movement keys. asdf is just the qwerty left hand home row.

Note that this workload is a worst case for iops and you will get higher iops in nearly any optimized workload. E.g. postgres needs to sync the WAL in order to commit (which does look like this test), but there are a ton of other writes that happen in parallel on the heap and index pages in addition to any reading you do. IME the consumer drives that benchmark at 500K iops and get only 500 iops on this test might get 10K or 20K iops on a more typical mixed workload.

You can also "soft"-shard your read replicas. I.e. each replica has still has all the data, but you still direct queries to specific replicas as if they were sharded. We had success with this since each replica can have a high cache hit rate by keeping only the data from its shard in cache. This is a lot simpler than real sharding since all replicas can still answer all queries and resharding is very forgiving.

> Glitch’s 14-person staff will all make the move over to Fastly. However the Glitch union, which made history last year when it signed the white collar tech world’s first collective bargaining agreement, won’t be coming with it.

https://www.theverge.com/2022/5/19/23126349/glitch-fastly-ac...

[This had substantially less coverage than forming the union, so I wanted to link it here]

Linux marketshare is steadily increasing, especially among English speakers. It's complicated by how you want to count the Steam Deck, but the steam hardware survey has a clear upward trend: https://www.gamingonlinux.com/steam-tracker/

We could get to 30% in just 60 years!

I don't think AI bots will make unilateral decisions about firing the same way a line manager typically won't. E.g. a manager will typically make a recommendation to a director and/or HR who will than review and approve the final action. A smart director should investigate themselves and might reassign the IC to another manager or in rare cases fire the manager instead (e.g. if they suspect retaliation).

I think you might not get serious responses, but I think this is an interesting question since I think AI is a better fit for management than many other jobs.

Nobody would have believed it 10 years ago, but today AI is more likely to replace a concept artist than an accountant, so it's not beyond imagination to replace a manager even if the ICs are still human.

AI excels at summarization, which is a big part of the job for a lot of managers. They gather information, go to meetings, write reports, and generally re-share information appropriate for whatever audience.

At a lot of companies, the lowest level managers don't make a lot of decisions either. Tech leads make technical decisions, PMs make product decisions, and the skip-levels (e.g. Directors, VPs) make staffing decisions.

In practice, I don't think humans will report to AIs, but hierarchies might flatten (e.g. ICs report to Directors) and responsibilities might get shuffled around (e.g. some duties get assigned to HR).

If the workers are AI-bots, then I don't really see any skill overlap with management. If you manage only AIs, you are an IC, not management.

> Server actions are public, unauthenticated routes

Why can't they be authenticated? That seems like the obvious fix. Otherwise how you are handing out the correct customer_id unless you authenticate somehow?

This scheme also complicates API key rotation, although you can work around it by trying to decrypt with both the old and new key if you use e.g. authenticated encryption.

This also has no mechanism for expiration (besides API key rotation). If you add an expiration time and sign it, then you essentially created an authentication token that you use as the customer_id.

Yesterday, Today, Blockers. I.e. the typical standup update.

In an open office, room-less meetings are quite disruptive. I still remember what the completely unrelated team two rows away was working on 8 years ago since I listened to them talk about it for 10 minutes every day. (I also apologize to everyone else since our team did the same thing)

If "30" minute meetings start 5 minutes late, then you can only go 5 past reliably.

The two problems are highly related, which is why it can do both. At the end of the algorithm, you have a per-pixel assignment of the (approximately) closest seed pixel. If you want a voronoi diagram, then you color each pixel according to the identify of its seed pixel. If you want a distance function, then you color it with the distance to that pixel.

You might also be interested in JFA https://en.m.wikipedia.org/wiki/Jump_flooding_algorithm

> You'll have a monolith, it might break out into frontend, backend and a separate service for async background jobs

And when you break these out, you don't actually have to split your code at all. You can deploy your normal monolith with a flag telling it what role to play. The background worker can still run a webserver since it's useful for healthchecks and metrics and the loadbalancer will decide what "roles" get real traffic.

Anyone know how this compares to Terrain3D?

https://github.com/TokisanGames/Terrain3D

NixOS works really well for me. I used to write these kinds of idempotent scripts too but they are usually irrelevant in NixOS where that's the default behavior.

The original complaint alleges that the training process requires copying the material into the model and thus requires consent of the copyright holder. (Copyright protects copying but notably not use, so the complaint has to say they copied it in order to have standing). Then it says they didn't have consent.

They also mention Books3, but they don't appear to actually allege anything against Meta in regards to it and are just providing context.

I don't think it actually changes anything material about this complaint if Meta bought all the books at a bookstore since that also doesn't give you the right to copy the works.

The original complaint is 2 years old though, so I don't really know the current state of argumentation.

https://www.courtlistener.com/docket/67569326/1/kadrey-v-met...

Note that incidental copying (i.e. temporary copies made by computers in order to perform otherwise legal actions) is generally legal, so "copying" in the complaint can't refer merely to this and must refer more broadly to the model itself being a copy in order to have standing.

It's interesting you say that, since this turned an infra scaling problem into a worker problem for us. Previously, we would get terrible head-of-line throughput issues, so we would use an egregious number of partitions to try to alleviate that. Lots of partitions is hard to manage since resizing topics is operationally tedious and it puts a lot of strain on brokers. But no matter how many partitions you have, the head-of-line still blocks. Even cases where certain keys had slightly slower throughput would clog up the whole partition with normal consumers.

The parallel consumer nearly entirely solved this problem. Only the most egregious cases where keys were ~3000 times slower than other keys would cause an issue, and then you could solve it by disabling that key for a while.

Do you have an example use case for this? This does seem like something unsuited to kafka, but I'm having a hard time imagining why you would structure something like this.

Check out the parallel consumer: https://github.com/confluentinc/parallel-consumer

It processes unrelated keys in parallel within a partition. It has to track what offsets have been processed between the last committed offset of the partition and the tip (i.e. only what's currently processed out of order). When it commits, it saves this state in the commit metadata highly compressed.

Most of the time, it was only processing a small number of records out of order so this bookkeeping was insignificant, but if one key gets stuck, it would scale to at least 100,000 offsets ahead, at which point enough alarms would go off that we would do something. That's definitely a huge improvement to head of line blocking.

I'm not OP, but if you are a reasonably high-earning professional common on this site, you trigger a ton of stuff. I used to take about that long to do mine, although I've gotten much faster. In a normal year, I typically file forms 1040, Schedule A, Schedule B, Schedule D, Schedule 2, 6251, 8606, 8949, 8959, 8960, 8995 + state versions of some of those. I'm also married, so I calculate all permutations of joint/separate with itemized/non-itemized, which also requires you to actually figure your taxes instead of leaving it blank and letting the IRS do it.

It gets really complicated very quickly, but if you are single, have less income, and it's only from wages, it's much simpler.

1040-EZ was discontinued in 2018. You just fill out 1040 now and leave lines blank. If you only have W2 income and don't make too much, it is really easy. You just fill out lines 1a, 12, 25a and the IRS will figure the rest (you can calculate the intermediate numbers if you want to, but they will do it for you).

However, knowing it's that easy requires reading a lot of instructions, and if you make enough money (depending on filing status), it suddenly gets much more complicated (forms 8959, 8960, 6251 have income triggers), and if you have 1099s (INT or DIV) you might need to file Schedule B and form 8995. And if you have a mortgage, you should do your taxes twice to see if itemizing with Schedule A is better. And god forbid you sold anything and have to do Schedule D and forms 8949.

It's a principle of capitalism, but taken to the extreme, it's just a strawman. At this point, I think we are pretty sure that some interventions make capitalism better.

This post is specifically about Industrial Policy: https://en.wikipedia.org/wiki/Industrial_policy

But other effective interventions are anti-trust and demand-inducing regulation (e.g. people want to fly because they know it's safe).

You can just read and write the notebook directly with ordinary calendar/todo-list UIs and get 99% of the utility without an LLM. I'm not really seeing value in the LLM except the butler voice? It is just reading the notebook right? E.g. they ask the butler to remember a coffee preference, but then that's never used for anything?

Post-acquisition products can still dominate their market even if they have declining quality. E.g. they can be bundled with other offerings from the parent company. This is exactly the point of anti-trust.

> Jim Barksdale, used to say there’s only two ways to make money in business: One is to bundle; the other is unbundle

https://a16z.com/the-future-of-work-cars-and-the-wisdom-in-s...

It might be too late now, but I've successfully negotiated (before signing) retention deals like this to be pro-rated in the event of non-voluntary termination. It's perfectly reasonable for exactly this reason, and companies have no legitimate reason to deny it.