Saizaku

joined 1 year ago
[–] Saizaku@lemmy.dbzer0.com 25 points 1 week ago* (last edited 1 week ago)

Complete nothingburger of a study, which itself is locked behind a $25 paywall to access it. And the author of the article obviously didn't cause there's 0 mention in the article itself about the methodology used to determine the 20% revenue lost (nice round number might I add). The only thing that even alludes to the methodology used in the abstract is

When Denuvo is cracked very early on, piracy leads to an estimated 20 percent fall in total revenue on average relative to an uncracked counterfactual

Which really doesn't tell us much, how are these counterfactuals selected in the first place? What is the cirteria? How are you determining that the differences between revenue of a game that was cracked and that went uncracked are due to one game being cracked? How can anyone even confidently claim that they've normalazied the data set enoguh that these differences in revenue are mainly caused by a game being cracked, especially with how rare early denuvo cracks have been in the past few years. Statistically this sounds dubious at best, especially when we have fully open studies (like the one funded by the EU a few years back) that have found no statistical proof that piracy has any impact on revenue ( with the exception of box office revenue of big new movies being leaked and pirated while still in theaters). Surely they wouldn't have missed a 20% meadian difference in revenue.

Lastly you have major tech news outlets all reporting on a study less than a month after it was made available online. For context the journal containing this study will only be published in jan of 2025.

[–] Saizaku@lemmy.dbzer0.com 6 points 2 weeks ago

Because you would be using std::shared_ptr<> rather than a raw pointer, which will automatically deallocate the memory when a shared point leaves the scope in the last place that it's used in. Along with std::atmoic<shared_ptr> implements static functions that can let you acquire locks and behave like having a mutex.

Now this isn't enforced at the compiler level, mostly due to backwards compatibility reasons, but if you're writing modern c++ properly you wouldn't run into memory safety issues. If you consider that stretching the definition then I guess I am.

Granted rust does a much better job of enforcing these things as it's unburdened by decades of history and backwards compatibility.

[–] Saizaku@lemmy.dbzer0.com 5 points 2 weeks ago (2 children)

There's a reason why data races aren't considered a memory safety issue, because we have a concept that deals with concurrency issues - thread safety.

Also for all it's faults, thread and memory safety in java aren't issues. In fact java's concurrent data structures are unmatched in any other programming language. You can use the regular data structures in java and run into issues with concurrency but you can also use unsafe in rust so it's a bit of a moot point.

[–] Saizaku@lemmy.dbzer0.com 5 points 2 weeks ago (3 children)

Arguably modern c++ ( aka if you don't use raw pointers), fits all categories.

[–] Saizaku@lemmy.dbzer0.com 2 points 3 weeks ago

Didn't even open the link probably

[–] Saizaku@lemmy.dbzer0.com 4 points 2 months ago* (last edited 2 months ago)

i'm having a lot of trouble with doing so because i have a very rough history with jobs ( quitting without notice many times when i was much younger )

The neat part about writing your resume is that you can leave out parts of your employment history that make you look "bad" (kinda like japan does with WWII). So let's say you had 4 jobs over the course of a year, skip the two jobs that you had for the shortest amount of time. After that do some stretching, ex say you started a job a month earlier than you did and tack on a ~month - month and half to the end of it. Now never say you were fired or quit for no reason, you could say that it was a temp position from the start cause your employer had more business that time of the year and that there was no prospect of staying longer from the very start. Try to keep the gaps between jobs small (I'd say two - three months at most). Now if you have a lot of jobs where you quit early on you could just skip that entire part of your employment history and say you starter working later in life. Employers generally don't care about how old you were when you got your first job, and they have no way to get your employment history (some government jobs can and will check tho I think) so don't mention stuff that makes you look bad. And yes this will shorten your work experience but being inexperienced is more desirable than frequent job changes on a resume (dumb af, ik, but it is what it is).

Now regarding embellishing how long you worked at a certain place, the further back the job was the better. Employers will typically only check with your last one or two employers if they check at all ( again some gov jobs might be an exception). One more tip, most place won't keep a digitalized employee database where they could easily search up your contract, so when embellishing try to avoid jobs that you believe might have kept digital records ( like chains etc). A lot of customer facing jobs have a huge turnover anyways so there's a good chance that there's noone you worked with that stil works there, let alone rembers you by name to be able to dispute what you said on your resume. Lastly if you get confronted about embellishing the time you worked a specific job, there's two things you could do: I didn't have my old resume on hand since I haven't worked in 2yrs so I wrote it from memeory or (better imo if you can project confidence during the interview and if you claimed you started earlier than you did) you can claim that you were on a trial position before signing the full contract so the one they looked up probably doesn't reflect your actual time there. If you can sell this with enought confidence they won't bother calling again to check, as it's a perfectly reasonable explanation and they already confirmed you worked there. If you aren't feeling confident about lying about any of these things, first lies by omission are much easier to sell and second just practice with your friends/parents.

Now depending on how confident you are there is another approach (which is more effective imo and it's what I did). You could only list a year on your resume and then just positions and places where you worked during that year (again feel free to omitt some jobs here) without specifying the duration. This lets you wing it during your actual interview where you can meet, judge and lie just enough based on the person interviewing you. It also lets you avoid some lies that would be easily exposed by not telling them in the first place (ex. If your interviewer worked at the place you were gonna lie about there's a good chance they'll mention it when the topic of that job comes up, so you just don't lie about that one). Note that some jobs might not even invite you to an interview without specifying the length of employment at each position, but in such cases, of you notice you aren't hearing back from them at all, you could just reapply with version according to the first approach I gave. Fixing a resume and reapplying is super common and you aren't really losing anything (except some time ofc).

As for the two year gap as some have suggested saying that you worked freelance is an option. If you aren't feeling confident with that approach you could say that you had to take care of a sick/injured parent/relative, they can never get their hands on their medical records and asking about details would feel kinda rude for most people (but not all, so be prepared for questions just in case, but also know that if the question seems to detailed refusing to answer would be pretty normal) so that might be an easier sell.

Anyways hope you find some of this usefull, feel free to ask if you have any questions.

[–] Saizaku@lemmy.dbzer0.com 4 points 2 months ago (2 children)

Here's one, it's just the video of the fight, literally nothing happened:

https://youtu.be/nsFEpqbhrWA

[–] Saizaku@lemmy.dbzer0.com 2 points 2 months ago

That's a fair point, I guess I used binary numbers so much i uni that I just know the small ones by heart and that's why I find it easier. Following the example, I never convert 101 as 4+0+1, I just see it and know it's 5.

[–] Saizaku@lemmy.dbzer0.com 5 points 2 months ago* (last edited 2 months ago) (2 children)

Read, write, and execute are represented by the numbers 4, 2, and 1, respectively, and you add them together to get the permission

Maybe I'm the weird one here but this seems like a counter intuitive way to remeber/explain it. Each octal digit in the three digit number is actually just 3 binary digits ( 3 bit flags) in order of rwx. For example read and execute would be 101 -> 5.

[–] Saizaku@lemmy.dbzer0.com 1 points 3 months ago

At the (SQL) database level, if you are using null in any sane way, it means "this value exists but is unknown".

Null at the SQL means that the value isn't there, idk where you're getting that from. SQL doesn't have anything like JS's undefined, there's no other way to represent a missing value in sql other than null (you could technically decide on certain values for certain types, like an empty string, but that's not something SQL defines).

[–] Saizaku@lemmy.dbzer0.com 2 points 5 months ago (1 children)

They're probably being downvoted for making a huge leap just from wearing pointy highheels lol. They turned a trivial reason into a non-trivial characterization/flaw about a person.

[–] Saizaku@lemmy.dbzer0.com 3 points 11 months ago

I'm on ddg and get no such issues with the same query:

view more: next ›