zalack

NVIDIA’s marketing overhypes, but their technical papers tend to be very solid. Obviously it always pays to remain skeptical but they have a good track record in this case.

It’s a remake that uses new, higher quality assets though, so isn’t an option in this case.

It’s worth pointing out that reproducible builds aren’t always guaranteed if software developers aren’t specifically programming with them in mind.

imagine a program that inserts randomness during compile time for seeds. Reach build would generate a different seed even from the same source code, and would fail being diffed against the actual release.

Or maybe the developer inserts information about the build environment for debugging such as the build time and exact OS version. This would cause verification builds to differ.

Rust (the programing language) has had a long history of working towards reproducible builds for software written in the language, for instance.

It’s one of those things that sounds straightforward and then pesky reality comes and fucks up your year.

The comment was about strategy, not objective.

It’s not that strange. A timeout occurs on several servers overnight, and maybe a bunch of Lemmy instances are all run in the same timezone, so all their admins wake up around the same time and fix it.

Well it’s a timeout, so by fixing it at the same time the admins have “synchronized” when timeouts across their servers are likely to occur again since it’s tangentially related to time. They’re likely to all fail again around the same moment.

It’s kind of similar to the thundering herd where a bunch of things getting errors will synchronize their retries in a giant herd and strain the server. It’s why good clients will add exponential backoff AND jitter (a little bit of randomness to when the retry is done, not just every x^2 seconds). That way if you have a million clients, it’s less likely that all 1,000,000 of them will attempt a retry at the extract same time, because they all got an error from your server at the same time when it failed.

Edit: looked at the ticket and it’s not exactly the kind of timeout I was thinking of.

This timeout might be caused by something that’s loosely a function of time or resources usage. If it’s resource usage, because the servers are federated, those spikes might happen across servers as everything is pushing events to subscribers. So, failure gets synchronized.

Or it could just be a coincidence. We as humans like to look for patterns in random events.

Sure, but that assumes this manager would be happy with generic “medical stuff” as an answer…

Right, but if you’re request for denied for something medically necessary unless you revealed it, you went anyway (because it’s necessary), and then you got fired… That feels like it shouldn’t be legal (obviously that doesn’t mean that it isn’t).

I’m not sure it would be legal if they were forced to reveal medical information.

I think better algorithms wouldn’t be a waste of developer resources. At the end of the day, the post feed algorithm is the core product, IMO.

Figuring out how to lower the weights on highly active subs is a good idea. As is ranking smaller subs’ content appropriately.

For all it’s faults, Reddit’s algorithm was pretty good. There was always a decent mix of small and large subs on my feed.

Kbin’s post ranking overall seems better than Lemmy’s and that was a major factor in me choosing it as my home base.

It’s because the producers want their counterparts spending time, energy, and perceived social capital negotiating over it rather than the things the Producers actually worry about having to give up.

IMO it’s pretty transparent, but creative people are pretty scared of AI right now so it might be a good bargaining tactic if they can get rank and file Union members to tie up the negotiatiors by reacting.

Crowd extensions are already pretty common with traditional VFX techniques.

I worked in Hollywood editorial for a bit and, IMO, the producers are playing up the AI stuff so that said stuff can be given to the writers and actors as a “victory” instead of the real spectres in the room:

• streaming residuals need to get the same payout and transparency as home video and syndication did

• streaming numbers need to be made available to creators to facilitate the above.

• the ‘mini-room’ system that totally disconnects writers from the productions they are writing for needs to be broken down.

Oldie but a goodie.

I posted a version of this in another thread:

I really think Lemmy, Kbin, and Mastodon need to figure out a way to have a default terms of service that ships with their product which forbids using the API to collect data for anything outside of user-facing social network interfaces, including account association heuristics and similar processes.

A way for users to set licenses on individual posts would be huge as well, with a default license instance admins can set.

That way for-profit instances could be forced to filter out posts with licenses that do not allow for-profit use. Honestly, even just a simple check mark “[ ] allow for-profit republication”, and have two licenses that can be attached: one that allows for-profit use and one that does not.

The fediverse should start baking in data control into it’s legal framework. Want to federate with Mastodon? You need to follow the ToS for what you can do with its posts. If we wanted to get really extreme we could even say the license should be copy-left. Any instance that wants to federate with a non-profit instances needs to also be non-profit.

That could block for-profit companies from becoming part of the network in the first place, even by use of stealth relay instances.

#threads

I really think Lemmy, Kbin, and Mastodon need to figure out a way to have a default terms of service that ship with their product which forbids using the API to collect data for commercial purposes.

Additionally, there should be a way for users to indicate licensing for individual posts, with a default license instance admins can set.

That way for-profit instances could be forced to filter out posts with licenses that do not allow for-profit use. Honestly, even just a simple check mark “[ ] allow for-profit republication”, and have two licenses that can be attached: one that allows for-profit use and one that does not.

Kbin generally seems to churn faster than Reddit for me, but posts on Lemmy do seem to stay around for a awhile.

I think it would be interesting to explore an API affordance for attaching licenses to fediverse content, with the admins being able to set a default license for their server.

So if Meta wants to get content from the fediverse, it has to check the headers of each post and make sure it’s licensed for commercial use.

The thing is that this can happen even without active malice.

If the product owners or engineers decide “hey, we want to add this cool feature, but it’s not supported by activity pub” the path of least resistance – bypassing the long process of changing the activity pub spec and getting everyone else on board – can be super tempting, and come from a place of wanting to make your product better.

Those ostensibly good intentions can lead to E/E/E without actively meaning to.

Thems the breaks when using what is essentially alpha software. The devs of both Lemmy and Kbin are aware that the admin tools need work, but stuff takes time.

Have unsecured messages be opt-in and have a warning banner on non-encrypted messages. Maybe even a confirmation dialog.

That way people who want or need to be that paranoid can be, but the rest of us can have something a bit more convenient.

By disallowing SMS messaging they’ve just made it so a lot of people who were being secure when their contacts allowed, aren’t being secure at all.

First off, cool your jets; you’re being kinda rude for no reason here. Just because we disagree doesn’t mean either of us is an idiot.

My point is just that you still develop features specifically for your admin-privileged users right? That’s the only thing I’m trying to say by calling admins users, that they still belong to the bucket of people you consider when adding features to your software, even if they are only admin-facing features. You’re right that it’s just a semantic difference, so let me rephrase using your terminology then;

Admins of the software may want to create and promote their own private sites using the lemmy software that federate with only a subset of other lemmy instances. For instance, a network of ‘academic’ lemmy instances run by universities – with high moderation requirements – that do not federate with the ‘popular’ fedeverse.

In that sense federation is a feature, to admins.

I’m also not 100% sold on it not mattering to end-users. Like I’m a user by your metric, and I like that Kbin can de-federate from extremist instances or instances run by corporations like Meta, and will likely move homes if it doesn’t and I start seeing too much content from those instances. It’s a feature I specifically appreciate about this platform.