Buttons

joined 1 year ago
[–] [email protected] 1 points 1 week ago

Throttling everyone equally during times of congestion is also fair in its own way. I'd be okay with that.

[–] [email protected] 4 points 2 weeks ago (3 children)

When limiting is required, because many people are using the same network, limiting those who have already used the most seems fair.

[–] [email protected] 3 points 2 weeks ago* (last edited 2 weeks ago)

Your comment might cause me to do something. You're responsible. I don't care what the legal definitions say.

If we don't care about legal definitions, then how do we know you didn't cause all this?

[–] [email protected] 3 points 1 month ago* (last edited 1 month ago)

Epic vs Google turned out a lot different than Epic vs Apple.

Also, Epic vs Google was decided by jury.

[–] [email protected] 5 points 1 month ago* (last edited 1 month ago) (4 children)

How would you force someone to take time off?

If I was their boss I would say something like "you're job is to stay home and do anything besides work for the next week, you will still be paid for this time". Easy.

As for the on-call stuff. Yes, that's the point. It should be unsustainable for a company to continually rely on their daytime programmers for frequent on-call alert handling.

If off-hours issues happen often, the company can hire an additional team to handle off-hours issues. If off-hours issues are rare, then you can depend on your daytime programmers to handle the rare off-hours issue, and know that they will be fairly compensated for being woken up in the middle of the night.

I've been at too many companies where an off-hours alert wakes up a developer in the middle of the night and the next day the consensus is "that's not good, but we'll have to fix the underlying issue after we finish implementing the new UI the design team is excited about". It's not right for a developer to get woken up in the middle of the night, and then the company puts fixing that on the backburner.

I'll say it again. It's about aligning incentives. When things that are painful for the worker are also painful for the company, that is alignment. Unfortunately, most companies have the opposite of alignment, if a developer gets woken in the middle of the night the end result for the company is that they got some additional free labor, that's pain for the worker, reward for the company; that's wrong.

[–] [email protected] 36 points 1 month ago* (last edited 1 month ago) (19 children)

When I think of a tech worker union my thoughts first go to standardizing everyone's pay and limiting what I can earn myself. I've probably fallen to anti-union propaganda.

A tech worker union that says nothing about pay could still do so much.

A union could ensure that the company's incentives are aligned with worker's incentives around things like on-call.

I'd love a union that forced a company to give all on-call workers compensation. Something like:

  1. If you're woken up in the middle of the night, you automatically get 8 hours comp time (time off), plus 2x the time you spend on-call during off hours.
  2. Accrued comp time over 20 hours must be payed at 10x normal pay if the employee leaves the company for any reason. The idea here isn't for employees to accrue comp time, but to give the company a strong incentive to ensure employees use their comp time.

Basically, if a company is having lots of on-call alerts, or the company is preventing employees from using their comp time, you want this to be directly painful to the company. Incentives should be aligned, what is painful for the worker should be painful for the company.

Or, regarding "unlimited PTO". I'd love to see a union force companies to:

  1. "Unlimited PTO" policies are fine, but they must have a guaranteed minimum amount of PTO specified in writing. So none of this "yeah, we heave 'unlimited PTO'; oh, we're really busy this quarter, so can you wait to take PTO until next quarter?".

Tech workers have it good compared to a lot of workers, but there are still plenty of abuses a union could help with, even if the union never even mentions pay.

[–] [email protected] 15 points 1 month ago

What is the game? It's not being a shill to answer questions.

[–] [email protected] 8 points 1 month ago (1 children)

The reason why is that they need my email address?

[–] [email protected] 7 points 1 month ago* (last edited 1 month ago)

Like anything medically related in the US, it's our time to crack open our wallets and do our patriotic duty of paying half the nation.

Like, if I want to talk to a doctor for 5 minutes, then it's my time to pay the all the insurance industry workers, and I have to pay my part of those 3 minutes long drug commercials you see on TV every ad break and before every YouTube video, and I have to pay all those people locking down the medical devices so that the users can't use their own data. This is my time to shine, I got to pay for all this because I talked to the doctor for 5 minutes. Also, hopefully in the end I have a few cents left over to give to the doctor.

Fucking rent seekers...

[–] [email protected] 2 points 1 month ago* (last edited 1 month ago)

Look at the entire history.

In 2018 their stock price was about 24, now it's 2.

[–] [email protected] 4 points 1 month ago* (last edited 1 month ago)

The rumored 4th and 5th games...

[–] [email protected] 4 points 1 month ago

You guys had a house!?!

 

Git repos have lots of write protected files in the .git directory, sometimes hundreds, and the default rm my_project_managed_by_git will prompt before deleting each write protected file. So, to actually delete my project I have to do rm -rf my_project_managed_by_git.

Using rm -rf scares me. Is there a reasonable way to delete git repos without it?

 
 
 

My first experience with Lemmy was thinking that the UI was beautiful, and lemmy.ml (the first instance I looked at) was asking people not to join because they already had 1500 users and were struggling to scale.

1500 users just doesn't seem like much, it seems like the type of load you could handle with a Raspberry Pi in a dusty corner.

Are the Lemmy servers struggling to scale because of the federation process / protocols?

Maybe I underestimate how much compute goes into hosting user generated content? Users generate very little text, but uploading pictures takes more space. Users are generating millions of bytes of content and it's overloading computers that can handle billions of bytes with ease, what happened? Am I missing something here?

Or maybe the code is just inefficient?

Which brings me to the title's question: Does Lemmy benefit from using Rust? None of the problems I can imagine are related to code execution speed.

If the federation process and protocols are inefficient, then everything is being built on sand. Popular protocols are hard to change. How often does the HTTP protocol change? Never. The language used for the code doesn't matter in this case.

If the code is just inefficient, well, inefficient Rust is probably slower than efficient Python or JavaScript. Could the complexity of Rust have pushed the devs towards a simpler but less efficient solution that ends up being slower than garbage collected languages? I'm sure this has happened before, but I don't know anything about the Lemmy code.

Or, again, maybe I'm just underestimating the amount of compute required to support 1500 users sharing a little bit of text and a few images?

view more: next ›