Posts
1429Following
133Followers
172"what a fascinating yet quietly terrifying being
" @kirakira@furry.engineer "turbo queer" @kasdeya@cryptid.cafe
repeated
repeated
horrowfide
horrowfiddy@mastodon.socialCongrats to Charlie Kirk on going 50 days without saying anything racist. 👍
4
4
0
repeated
i’m not gonna maintain it or write code for it, but damn if its not an Okay piece of software
eli (ˈe̝ːli), vampire kitsune
rowan@tempest @kasdeya i feel the point of familiarity and preference is underappreciated in general and i like this post values it. individuals “misuse” irl tools all the time because of convenience and familiarity and because they dont want to have 29384293429 highly specific tools to decide between. if they have something that works what for what they do, why change? only when that tool isn’t doing the job or new requirements have surfaced should they really consider whether they need something new. there are obviously cases where this isn’t true (eg. the use of the tool is harmful to themselves or others) but outside of those… why evangelize to them?
1
0
3
repeated
Show content
@rowan @kasdeya we strongly agree with this. to add an example from our field to augment the ECS one: let's talk containers
the use case that they were designed to be used in is deployment of web software, typically in a commercial setting. that's where they actually make sense, so let's start there
the most obvious alternative is to install an application and all its dependencies directly on the host, and this is more straightforward in basically every way — it's easier to get started with, easier to debug, on many systems it's the same mechanisms as installing it on a desktop machine, what could be easier right?
the difficulty with this approach is really only going to show when we start going past this simplified scenario. if we ever in the future need to move this application to new hardware, that's now a non-trivial operation; or say this organization has both a web app and an API for their mobile app, and those are managed by different teams with different dependencies — keeping track of what part of the system exists for what app is easy to mess up and time consuming to fix; worse still, these situations compound on each other: in three years when the mobile app traffic is overwhelming the web server and we want to split these up we may find ourselves asking "wait why is there a modified fork of curl in /opt/ again, which app was this for?"
ostensibly this could be solved purely with documentation, but if there's a manager out there who gives time for that we've never heard of them — so for basically as long as we've been in this space, there have been tools that try to encapsulate an application, its dependencies, and its runtime environment, so they are easier to keep track of in those kinds of situations. there are tools that were in use before containers (VMs, basic chroot jails, isolated user environments, etc) but containers became widespread because they managed to be easier to use (and more easily standardized across languages) than the other broadly available options for mitigating this encapsulation problem
so that was its initial reason for existing, but since becoming more widespread it's been adopted for additional reasons (all with their pros and cons as well)
- containerized development environments to standardize tools and versions across members of a team
- providing a pre-configured runtime environment for self-hosted apps
- running legacy software in an isolated environment where it's less of a risk to be using outdated tools or libraries
all of these are kind of "worse" reasons to use containers (we doubt any of them would have popularized them on their own) but they exist because they're piggybacking on the fact that containers have become such a widespread thing; to a developer who already knows a bit about running containers for deployment reasons, these uses are more or less an easy bonus (but to someone who doesn't already know that, it's absolutely overcomplicated)
1
1
2
repeated
N33R "Räuberischer Angriff auf Kraftfahrer" ⚸ 🩸 
N33R@fops.cloud
Show content
FUCK A PUMPKIN
FUCK A PUMPKIN
FUCK A PUMPKIN
FUCK A PUMPKIN
FUCK A PUMPKIN
FUCK A PUMPKIN
FUCK A PUMPKIN
FUCK A PUMPKIN
FUCK A PUMPKIN
FUCK A PUMPKIN
FUCK A PUMPKIN
FUCK A PUMPKIN
In June 2003, Amnesty International published reports of human rights abuses by the U.S. military and its coalition partners at detention centers and prisons in Iraq. [26]
0
2
0
repeated
RAPIDPUNCHES
RAPIDPUNCHES@mastodon.art
1
2
0
repeated
eli (ˈe̝ːli), vampire kitsune
rowansaw “mdnidnidni” in someone’s profile and now i just want to make a recursive mdni* generator to cover every possibility
1
1
9
eli (ˈe̝ːli), vampire kitsune
rowanShow content
@fridgelite @freeplay clumsy kbity 
1
0
2
@kasdeya using ecs as an example: it’s found a home in game development because it solves a non-trivial amount of game dev specific problems.
some common problems in game dev
- game objects can be expensive to create / destroy but games often require this very frequently
- in non-ecs development, this is often solved with object pools – a collection of objects which are pulled from the pool, manipulated for whatever use its needed for, and then released back to the pool
- many game objects are variations of one another with just a few changes but many standard object-oriented patterns (inheritance) become fragile when applied and force a lot of redundant code
- there are object-oriented patterns which are similar to ECS like what godot and unity do
- much of a game’s code runs 60+ times per second. it needs to be fast and organized such that only code which needs to run that often actually does, and it should be as done as cheaply as possible
enter ecs: component-based development allows for extremely modular design, data-oriented programming is focused on highly performant code, and entities being simple identifiers means that creating/destroying them is very cheap.
however, explaining this to say – a web dev, they may only understand this at a conceptual level if they’ve had little or no exposure to making applications like this. they may look at whats required to write ECS code and think to themselves, “couldnt we just solve this with observables / events / whatever other pattern we use frequently?” thats because these are the tools in their daily toolset and its how they solve their problems elegantly. they are very proficient with using these tools and will reach for them first.
to be clear: that web dev is not stupid. it is not a statement to their proficiency as a developer or anything else. its just that programming and computer science is both vast in breadth ( 
) and depth and we have to specialize.
0
0
6
@kasdeya im of the school of thought that much of this is at the intersection of domain-specific needs and personal preference. it’s really difficult to explain this because, in order to explain it, one must recreate the original problem in its entirety and then layout the history of all the other things we’ve done to get to [current solution]. not to mention, we all think about problems differently – one approach may seem exceedingly simple to one individual and needlessly complex to another (looking at you, functional programming). this isn’t even including familiarity because of course, once you learn a toolset, you then begin to expand your understanding of all the ways a tool may be applied. within your chosen toolset, it may seem elegant and simple to solve it with X when the rest of the world is using Y. is X better than Y? maybe, but probably not. it’s more likely because Y isn’t in your typical toolset for some reason so reaching for it feels unnatural.
2
1
8
eli (ˈe̝ːli), vampire kitsune
rowanShow content
@h33h33wuffi3 i extremely support and agree with this take.
i think baby trans, for many, can also have problematic intersections with passing. the idea that the goal of transition is passing on the gender binary is goofy and ridiculous and transphobic. on one hand, i can appreciate a willingness for a community to identify individuals who have recently discovered / accepted their transness and want to make room for them to learn and grow, but on the other hand, the idea of a gradation of baby trans -> elder trans is extremely weird. we’re all learning at our own rate and just because i dont know all the specifics of, say, hrt, it doesnt mean im not learning an entirely separate aspect of my trans identity. moreover, the atypical gender transitions due to poor access to healthcare and finance is going to teach us just as much about our identities as anything else – because we are trans.
1
0
4
repeated
ash3r‽ ⚙️🌌🃏(it/ey/she)
h33h33wuffi3@plush.cityShow content
one thing i've come to realize is how much i dislike the term "baby trans". it implies a few things that i don't really like. it implies that:
1. being 'baby trans' is a state that all trans people exist in at some point, before "growing up" after a period of time.
2. trans people who are not "baby trans" are more wise or knowledgeable than those who are.
3. people deemed "baby trans" are hapless and need guidance
for real its all just privilege
1
1
1