It scored a 47% vs the humans 81%

That’s already pretty compelling that it’s scoring so well considering how this tech is still so new.

It’s very rapidly catching up.

Also keep in mind they were using a more generic ML model and not one specifically tuned to this task.

Dunno why ppl are down voting you, this is 100% the way.

Architecture as code is amazing, being able to completely wipe your server, re-install fresh, and turn it on and it goes right back to how it was is awesome.

GitOps version controlled architecture is easy to maintain, easy to rollback, and easy to modify.

I use k8s for my entire homelab, it has some initial learning curve but once you “get it” and have working configs on github, it becomes so trivial to add more stuff to it, scale it up, etc.

Why is it that blatantly lying about your political opponent and actively spreading clear disinformation that is easily reputable isn’t penalized?

And I don’t want like “cuz capitalism” zero effort responses, I’m wanting to know from an actual legal complexity standpoint what would go wrong if this was made illegal.

The fact it’s so clearly provably as a false claim by countless directions, it should be an open and shut “you spread obvious disinformation” and at least a notable slap on the wrist should occur each time.

Why can a candidate just go and openly lie and say whatever without penalty, legally? Shouldn’t this be under something like Libel, defamation, etc?

Shouldn’t Kamala’s crew be able to take Trump to court right now for defamation?

Mood, how are like 90% of articles pushing this narrative instead of pointing out Trumps latest new heights of dementia ranting.

We meed to push and down vote this Biden shit and post and share latest info on what new crazy shit trump is brain rotting about now and what implications it has.

My understanding is risk is low on this one as we already have a prepared and tested vaccine, and we have a known medicative treatment.

So it’d suck if it spreads but we at least have the tools to fight it on hand.

Might wanna read it again, it’s right there :)

The best architectures, requirements, and designs emerge from self-organizing teams.

It’s an incredibly critical part companies love to completely ignore.

If you assign devs to teams and lock em down, you’ve violated a core principle

And it’s a key role in being able to achieve these two:

Agile processes promote sustainable development.

And

The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

This is talked about at length by the likes of Fowler, who talk about how locking devs down us a super fast way to kill sustainable development. It burns devs out fast as hell.

Note that it’s careful not to say on the same project

That’s actually a pretty important part of its original premise.

It’s a big part of why scrum meetings were a thing, as the expectation was any curious dev could just join in to see what’s up, if they like.

Not tying devs down to 1 specific thing is like the cornerstone of agile, and over many years of marketing and corporate bastardization, everyone had completely forgotten that was literally the point.

The whole point of the process was to address 2 things:

1. That client requirements can’t easily be 100% covered day one (But you still need to get as many as you can!)

2. To avoid silo’ing and tying devs down to specific things, and running into the one bus rule (“how fucked would this project be if <dev> got hit by a bus?”)

And the prime solution posited is to approach your internal projects the same way open source works. Keep it open and available to the whole company, any dev can check it out, chime in if they’re familiar with a challenge, etc.

One big issue often noted in non-agile companies (aka almost all of them) is that a dev slent ages hacking away at an issue with little success, only to find out far too late someone else in the company already has solved that one before.

An actually agile approach should be way more open and free range. Devs should be constantly encouraged to cross pollinate info, tips, help each other, post about their issues, etc. There should be first class supported communication channels for asking for help and tips company wide.

If your company doesn’t even have a “ask for help on (common topic)” channel for peeps to imfoshare, you are soooooooo far away from being agile yet.

I’ve literally never actually seen a self proclaimed “agile” company at all get agile right.

If your developers are on teams that are tied to and own specific projects, that’s not agile.

If you involve the clients in the scrum meeting, that’s not agile.

If your devs aren’t often opening PRs on a variety of different projects all over the place, you very likely aren’t agile.

If your devs can’t open up a PR in git as the way to perform devops, you aren’t agile.

Instead you have most of the time devs rotting away on the sane project forever and everyone on “teams” siloed away from each other with very little criss talk, devops is maintained by like 1-2 ppl by hand, and tonnes of ppl all the time keep getting stuck on specific chunks of domains because “they worked on it so they knpw how it works”

Shortly after the dev burns out because no one can keep working on the same 1 thing endlessly and not slowly come to fucking losthe their job.

Everyone forgets the first core principle if an agile workplace and literally its namesake us devs gotta be allowed to free roam.

Let them take a break and go work on another project or chunk of the domain. Let them go tinker with another problem. Let them pop in to help another group out with something.

A really helpful metric, to be honest, of agile “health” at your company is monitor how many distinct repos devs are opening PRs into per year on average.

A healthy company should often see many devs contributing to numerous projects all over the company per year, not just sitting and slowly be coming welded to the hull of ThatOneProject.

It does mean something.

The skibidi toilet “creatures” are considered the antagonists, and the word is associated with their traits.

• creepy
• gross
• scary
• weird

Its an insult to and pretty much interchangeably with “creepy” with a splash of “cringe”

Often paired with “ohio” which means “bland” / " boring" / “mid”

Example:

“Yo he got that skibidi Ohio rizz”

Translation:

“This dude has zero game, in fact he is creepy and weird and has negative charisma, people find him repulsive and boring”

Yeah in fact you’re giving the llm additional data to train on what poisoned data looks like so it can avoid it better, as they can clear see the before vs after

Others have covered the fact it’s because of air pressure but haven’t fully answered why that is the way it is.

It’s simple really.

The force of gravity is also at play. As you go higher up, gravity gets weaker as you get farther from the earth’s centre.

And it is that gravitational force that increases the air’s density, same reason why if you keep going down in the water, the water gets denser.

For the heat to move around you need to be in a sort of goldilocks zone of density.

It needs to be dense enough that the fluid molecules can move around and spread the convection energy around… but not so dense they can’t move much either.

Furthermore there’s actually a couple different layers of our atmosphere.

First at our level is the troposphere, where heat is absorbed into the ground itself and radiated back out, as well as the perpetual heat from the earth’s core, and reflected off the ground too (visible light).

The troposphere is warm and gets colder as you get farther away from the earth’s surface, naturally. That heat is absorbed by the air itself so, as you get farther away it gets colder as it has more air to travel through.

Up higher is the Stratosphere, where it’s ice cold and the air thins out.

However we get a sudden uptick in temp as we go even higher into what is called the Stratopause, back to briefly warm temperatures between the Stratosphere and the Mesosohere. Why? How?

Simple, this is the little sweet spot Ozone molecules hang out, forming a protective convenient bubble around the earth. Ozone absorbs Ultraviolet light from the sun and turns out that stuff is HOT, so there’s a band of a hot zone right above and below the Ozone layer. Think of it as a toasty little bubble around us.

Above is the mesosphere which cools off again and gets back to being really frosty quickly, for the same reason the Stratosphere did, distance.

Then we hit the mesosphere, which is effectively the point when the atmosphere is so thin it stops protecting and is the “outside” of our protective blanket.

You can imagine this like earth being wrapped in a blanket, and the mesosphere is everything outside the blanket. Without any protection you are subject to the unbridled radiation of the sun which means you go back to being really toasty, as you get a bit higher you are effectively in space now and will soon enough hit temps that just cook you alive in a minute or two. Really bad sunburn zone.

So to answer the question overall:

Hot air rises… but only when there is air to rise.

Top of the mountains just don’t have enough air anymore for it to really rise much more. It still does but the hot air rising effect just gets weaker and weaker as the air gets thinner due to less gravity.

There aren’t standardized screens for smartphones, as the inside of the screens typically has a bespoke aluminum chassis they are adhered to as part of their construction.

And since every single phone model has different insides, every screen is bespoke to its model.

You have to look on ebay for your phones screen model.

If you look for ones with a couple dead pixels they are pretty affordable though.

There’s not really a nice way to frame “your post sounds like it was written by an extremely cringe teenager trying to cosplay as their idea of what constitutes a professional dev, demonstrated by the classic combination of ignoring everything prior written, attempting to represent a ball of mud as a badge of honor, and unironically trying to use lines of code count as a metric to measure by”

Literally checked off all the “lol sure bud” boxes in a single statement, and then if you aren’t picking up on the nuance, let me explain what I wrote after:

I hope you understand later how incredibly cringe what you wrote is, because the day you do is the day you have likely matured enough in knowledge and skill to call yourself a professional unironically, which is a good thing.

Until that day, stop prostrating shit like what you just wrote above if you ever want any developer worth their salt to take you even remotely seriously, otherwise you will likely find yourself the laughing stock very quickly of any serious circle.

Best of luck out there, and finally:

Next time someone is giving extremely useful advice, just write it down, don’t shit talk. That’s without a doubt the #1 divergence that separates the path between long term failure vs success.

Everything about what you just wrote, and the way you represented it, signals you are precisely the type of individual that should take everything about what I wrote above very much to heart, friend.

If you have no idea what I’m talking about, I hope one day you do :)

That’s code review.

Only on very small projects.

As the team grows, having just 1 person review your code is simply not sufficient.

Even 2-3 may not be enough to sanity check if a larger new feature on a massive project is good. If it impacts the team and means a fundamental shift in methodology, then you need more voices weighing in.

Now, can you merge the PR in first, then have the meeting after? Sure, I guess, but why would you?

If the team reacts negatively to what you built, finds flaws in it, or simply just doesn’t get it because you overengineered, now you have to revert the PR and go back to the drawing board.

It makes tremendously more sense to bring folks impacted in on a swarmed live PR review as you go over what you did, where you did it, and why… before you merge it in.

At this point you can QnA, get suggestions, feedback, etc.

Now typically most of my response to live chat feedback is “aight, can you add that as a comment on the PR itself so I can see it after?” And then they go and do that asap, usually typing it up as I answer other folks questions. Because at this stage the PR is literally the perfect place for feedback to go.

I’ve been down the path of “1 person LGTMs the PR, huge new feature is added, I document it on the wiki rigorously, I post the new feature to chat… 1/10 people bother to use it and 9/10 give blank glassy stares when I bring it up”

It. Doesn’t. Work.

Period, lol. And don’t get me wrong, I wish it did, but people just don’t RTFM mate, that’s a fact of life a d the sooner you accept that, the easier the job gets.

it’s rare that a single PR introduces anything but a small slice of a feature

Yes, I never said this was a common occurrence. This is indeed rare but it dies happen.

And we’re not really talking about a PR review at this point

No, this is 100% still part of the PR review, I was pretty explicit about that. This process should happen for a large feature/service/etc as this simply cannot be covered by a “LGTM!” Comment on a PR.

These meetings primarily cover when you’ve established something that needs to be followed or used moving forward. IE: “This new feature makes our lives a lot easier and now (annoying thing) is much easier to implement. This is how I used it in my PR and I wanna make sure all the rest of the team is on the same page about it, and everyone else starts using it in the future.”

This 100% comes up here and there and it absolutely necessitates an actual meeting, because any dev worth their salt knows what happens if you dont get everyone on the same page on it…

The inevitable “why didn’t you use (thing I made explicitly for this purpose)?” Convo comes up a month or two later, because all you did was document the new thing and open a PR, get a couple "LGTM!"s, and you posted a blurb about it in the chat and pinged some folks.

And if you’ve gone through this process before you will know that simply just never works, full stop. Doesn’t matter the team, doesn’t matter how well documented, doesn’t matter how good your write up is… People. Don’t. Read.

There’s a reason “RTFM” is such a meme in linux communities, people don’t fuckin read mate, abd that’s why critical big PRs 100% need a 20-30 min QnA meeting so people can actually talk about it.

I’d estimate tops 10-20% of devs that should read your docs, will actually do it.

Do you not do demo meetings after introducing entirely new features?

Sometimes a PR can be quite large as it involves an entirely brand new feature that simply didn’t exist before.

And if it’s an internal tool/service for fellow devs to use to make their lives easier, yes, it likely deserves a meeting so the devs can have a chance to QnA about it. Usually 5-10 minutes going over the who/what/why/where/how, then 20 mins or whatever of any needed QnA if devs are curious for more info about specifics, like performance or extensibility or etc.

If you create a new tool like that abd then just hand it off with all the devs have to go on being “here’s the manual, figure it out” you know what happens?

Almost no one reads it, and pretty much no one uses it, because parsing a giant manual of info is difficult co.pared to seeing a live demo

1. Make branch for the ticket
2. Make periodic commits to branch
3. Open PR from branch to main
4. (optional) if the changes are big, I have a meeting with devs to discuss it. If I can’t easily explain to the junior devs what I did and why, it means I did something wrong.

As a senior dev, I’ve found “can the junior devs grok wtf I did/made” to be an excellent “did I overengineer?” Litmus test.

A good implementation should be not too hard to explain to the juniors, and they should be able to “get it” in a single short 20-30 minute meeting at most.

If they are curious/interested and ask questions, that’s a good sign I made something useful and worthwhile.

If I get a lot of “I’m not sure I get it” and blank stares, I probably have overcomplicated the solution.

If that “ooooh, okay!” Comes quickly, then we are good!

The two acts should be distinct for sure.

You should be also able to delete all history without deleting account.

Basically should be 2 distinct buttons/actions entirely.

The fact you bring up scraping at all indicates you have no idea what this is about.

Data privacy and protection isn’t about that.

“Some third party could just…” is indeed trying to whataboutism it, it’s completely irrelevant.

Other instance owners are completely irrelevant.

You’ll need to wrap your head around the fact that legally lemmy has to support the takedown request per instance, not federation wide.

If I truly wanted my data gone I’d have to make the request to each individual server. That’s fine.

Data privacy and protection compliance means that I can request specifically server A take down my data, and still be fine with server B retaining a copy.

If I wanted both to drop the data, I’d have to request it from both individually.

Scrapers aren’t involved here.

The protection isn’t about “oh no people on the internet can see my posts”

It’s more about “oh man it came to light Server B’s owner is selling people’s data and I don’t want my data included in that”

This is a legal requirement, id recommend lemmy instance owners check in with their local lawyers about this, because a lack of compliance could get individual instance owners in hot water, and if multiple large instance owners realize this, it should put more pressure on the debs to fix that shit.