redmagpie

Ooh that looks very promising, thank you very much!

That's really good to know, thank you!

Just a question, since I am definitely not experienced with PC gaming. Is the default Skyrim launcher different to that found on Steam?

Fantastic info, thanks so much; they both look great and this is an amazing headstart into modding the game.

Thanks for the reassurance re the mods I've listed as well. My thinking was the same as yours in that I'm not after anything graphically intensive, but I didn't know whether the engine had some quirks which flooded RAM if there were too many assets included in some mods, or whether some well-known mods were infamous for chewing up CPU cycles with borky scripts which would result in an unplayable game on the Deck.

Thanks so much for the swift reply, and the incredible info.

Yeah I've never modded games before (I'm techie, but not that into games) but there's a few tutorials knocking about which has made me confident that I can manage to wrap my head around it.

Thanks again this was incredibly useful :-)

No worries re long replies. That's really interesting. I've never used any LSP features before (I am definitely out of touch though) so perhaps this wouldn't be such a blocker.

Ah that sucks to hear :-( I didn't know there was even a plugin ecosystem to Android Studio but of course there is.

I might just use Android studio to set up the project and then do my actual keyboard-bashing in Neovim later. All I really want is the boilerplate set up properly and my app will be a single activity with maybe 3 views, so once that's all generated I'll try switching.

Out of interest, what has been the failure points for you trying this in the past?

Thanks for reply comrade. I'm not really a Javascript person, but it's good to know there are alternatives to use for building apps quickly. The last time I used Javascript for anything was jQuery on a website in 2017 and even I think it was outdated in favour of all the fancy frameworks. I haven't the head for keeping up with it al.

I also got burned by multiplatform frameworks back during my undergrad during a group project when the self-elected team lead — a proper bourgie moneyed type who went to like Stow or something — forced us to use Titanium to build an android app when the rest of us wanted to write it in native Android Java. It was godawful, and then when I later came to developing apps I had a pleasant enough time writing in Java.

Cheers for the reply comrade.

Since this is just a personal project I'll be installing the app just on my phone via USB and adb, and don't need a proper CI/CD build system. I just need to compile on my machine and stick the apk file onto my phone.

Thanks comrade, I've never worked with entr but it looks really cool! Thanks for the share.

I doubt I'd need the constant builds on this project but it's going into my list of tools to keep in the back pocket.

If you're wanting to lift weights I recommend Starting Strength. If you are open to training bodyweight calisthenics in a strength-training style, I seriously recommend Convict Conditioning.

When I lifted weights I did Starting Strength. Absolutely solid program, even if the author/coach gives off a few "don't tread on me vibes". I did this in my early twenties for about 18 months before I switched to a bodyweight strength training system, since I found bodyweight stuff to be more fun and allowed me to train outdoors in parks and whatnot.

For the last 10 years I've basically been training using a slightly-tweaked Convict Conditioning system. Beyond the "grr convicts" gimmick in the book, the contents are top-notch and aren't pitching anything other than using bodyweight exercises as a serious strength and muscle building tool. It really kickstarted the progressive calisthenics movement in the 2010s. I've grown bigger and stronger for a decade using the exercises in this and the follow-up book (which is focused on some assistance exercises). The author outright says that their goal is to give you the building blocks to make up your own routines from the basic principles and does a good job of this, but also provides some sample routines to get you started.

In 2019 I threw in some mid-distance running (5ks and 10ks) as well, although I can't run atm due to life things and injury. Running interferes pretty noticeably with recovery, and can slow down your strength/hypertrophy gains compared to a pure strength or hypertrophy system and some people really don't like this. I found that I could still progress but it was a lot slower than before running, although I liked having the basis in cardio to complement the strength. I didn't lose much strength or muscle mass because I ate more to compensate and over time my recovery ability increased notably.

I really don't like the tone of some parts of this. Some of it is good, like reassurances around the privacy measures that Mastodon instances take to protect user IPs.

The bit I most have an issue with specifically is the section on Embrace, Extend, Extinguish.

Well, even if Threads abandoned ActivityPub down the line, where we would end up is exactly where we are now. XMPP did not exist on its own outside of nerd circles, while ActivityPub enjoys the support and brand recognition of Mastodon.

I think this misses the point or dismisses of some of the fears around Embrace, Extend, Extinguish and jumps straight to the idea that Threads may abandon ActivityPub. I don't think this is the concern, and my major concern is around the Extend part of the strategy.

Here's the strategy, from the wikipedia page

1. Embrace: Development of software substantially compatible with a competing product, or implementing a public standard.
2. Extend: Addition and promotion of features not supported by the competing product or part of the standard, creating interoperability problems for customers who try to use the "simple" standard.
3. Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors that do not or cannot support the new extensions.

ActivityPub implementation is already pretty heterogeneous which is both a strength and introduces some fragility into "The Federation". We see this even between fediverse-centric platforms where certain interactions are supported or not supported. Right now, I can see a Mastodon account from a Lemmy interface but none of its posts. This is fine, because Lemmy is not Mastodon and its concerns are different and built around participation in communities; but it is a crack in the ActivityPub standard that's exploitable.

Following the strategy, Meta can start developing its own Threads-specific features which Fediverse implementors can choose to implement or not. Different Fediverse software implementations will need to make a decision as to whether they implement certain features, just as they do now. Some may refuse point-blank, which is fine. But this "[creates] interoperability problems for customers who try to use the 'simple' standard.".

Recent posts from @dansup@mastodon.social and the linked blog post from @Gargron@mastodon.social indicate that they are at least nominally on board with Meta's involvement in the Fediverse and are devolving the responsibility of blocking interaction with Threads onto Admins and Users. It's of course impossible to accurately predict the future, but to me that indicates that there may be willingness to develop Threads-friendly functionalities in the future, at least in Mastodon and Pixelfed codebases.

Certainly before the Reddit apocalypse, and arguably still now, Mastodon is seen as the flagship Fediverse platform. Eugene basically says it in his post:

while ActivityPub enjoys the support and brand recognition of Mastodon.

Again, fine. But that causes its own issues. This github issue highlights the concerns that diaspora* developers had over implementing ActivityPub as a federation protocol. In particular, this comment eloquently describes the heterogeneity of ActivityPub implementations. And also makes the following point, which I agree with:

The current modus operandi seems to be to just look at Mastodon and copy their implementation because that seems to be the only way to get something working. That, however, is not about supporting AP, it's about supporting Mastodon's dialect of AP, and their subset of that.

Mastodon is arguably a leader in the Fediverse space, and if Mastodon's development trends towards supporting Meta's extensions then everyone else may be inclined to keep up or risk losing some interoperability that users of their software have come to enjoy. Forking codebases doesn't fix the issue; it just means there's more implementations only supporting the "basic" implementation of the standard.

In terms of what it means for the average user on the Fediverse? Who knows. Joining instances not federated to Meta or refusing non-Meta features is definitely viable as a strategy.

For me personally, the major loss is the feeling that I'm in a space where there aren't any major corporate players. I left those other platforms to seek community-run spaces where the software was a little janky and the servers sometimes crashed, but it was fine because They weren't there. I feel that they've just barged back into my space now. I'll probably get over it in time. I don't use Mastodon and my Lemmy'ing is mostly limited to lemmygrad; but it's still a little sad in the short-term.