If I were to start publishing video content I'd probably try for Vimeo first, self-hosted second. (No affiliation.)
718 karma · joined October 4, 2015
Then “free email” providers on the early consumer Internet were able to compete on things like storage, because that was something it was still acceptable to expect people to pay attention to. One of GMail's original big draws was “lots and lots of storage”.
Email being in decline for social purposes feels partly related to changing feedback expectations and UI inertia, but I'd guess also some relation to a “mental association with uncool things” including both spam and stressful/boring transactional email; it's become more of a business thing. The spam side of that is related to the gradual federation lockdown, and something similar could happen to Mastodon, but at least there's some discussion about it happening in advance now.
I'm not sure what this all adds up to.
Doesn't exist anymore (often enough).
> Just user-oriented effort instead of the constant barrage of difficult-to-setup tech demos.
Things like identity management and data storage make these barriers pretty deep. “I can delete my post and it basically won't be accessible anymore” (there can be physical exceptions so long as they're legibly exceptions to the social reality), “I don't have to think about how big my images are and can just post as much as I want”, “I can lose any of my own hardware and everything will still be there because it's in the cloud”, and “I can tell who my friends are based on common knowledge within my circles of their unique name which is easy to remember and meaningful” are all things that heavily constrain what you can do “on the inside”.
Mastodon has meanwhile managed to either do something right or get lucky wrt the path dependency of building structures where prosocial hosting behavior is convenient: a whole bunch of mostly-volunteer instances have sprung up, adopters have managed to make instance choice part of identity so that the domain-part isn't just a “meaningless extra thing to remember”, and federation remains reasonably strong; meanwhile, financial support for server costs has mostly leant toward the Patreon model, allowing a fraction of generous users to help support a bunch of free riders while not having to directly participate in administration. At the same time, despite Mastodon having almost exactly copied Twitter's model in terms of available user interactions, the zeitgeist has repeatedly suggested that users getting on board for the first time often had no idea what instances even could be, and had to have the very concept explained several different ways before it got real traction. Random instance death is also a problem that's tempering the mood nowadays, because keeping the server up requires enough motivation which sometimes runs out, and some instances have started having problems with media storage requirements, which, see above (though I'm told the internal architecture could use some optimization too).
There's something deeper in here surrounding the thorough conflation of type with instance in the popular side of the digital world; I feel as though something critical to the more literate concept of this didn't make it into the default folk model, such that only centralized services are legible. I have some hope that Mastodon and related ActivityPub-based federated services absorbing waves of people fleeing the abusive behavior of major social media (such as the recent Tumblr exodus) will make a dent in this and cause the appropriate concepts to reach critical cultural density.
Is this still true when “telling who's a ‘robot’” is such a common thing to have happen? For instance, I've heard of at least one major platform both sending back quite a lot of UI telemetry and considering third-party clients a violation of their ToS; I haven't heard of strong action being taken yet. (I'm avoiding naming them both because I'm operating partly on hearsay and because I'm more interested in the general question.) Hasn't bigtech had a lot of time and motivation to advance “how to detect people who are using some weird software to talk to us”?
Simpler forms of technical barriers, like with the AIM protocol, were defeated in the past, but it seems like massively upgraded data backchannels, machine learning algorithms, and the new normality of silent automatic updates all the time might strongly favor a centralized defender. Plus IIRC the CableCARD wars didn't go so great, and there were presumably a lot of people motivated to save money on expensive TV packages, whereas risking losing access to all your friends for having slightly better control over something that's notionally “free” anyway sounds like a harder sell.
I don't think it's easy to defeat “socially required tech” + “automatic updates” + “machine learning” at all.
In larger, topic-oriented, and/or highly generalist communities, ones that are looser and more impersonal in general, it's been more as you describe.
I actually suspect you're mostly right (the EV color is green, not gray, in the Chromium I'm using, but I can imagine this not being easily visible under many conditions), but the way you've decided to talk about this has made me very hesitant to openly agree with you. But for those whose answers are meant as “it says ‘Not Secure’, therefore it's adequately different”, I might be skeptical on the grounds of “having the user know that requires clearing a higher attention bar first”, aka “users don't read”.
On at least modern GNU/Linux, malloc can and does still use brk/sbrk, but will also use mmap for particularly large allocations, as can (on my system) be shown by stracing this C program:
#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
printf("%p %p\n", malloc((size_t)1 << 14),
malloc((size_t)1 << 20));
return 0;
}
Regarding the other two factors you mention: firstly, if you make a large number of allocations on a brk-based heap and then free most of them, a page from that heap can still only be paged out if none of the live allocations intersects it. (If you make a single large allocation, see above re automatic use of mmap.) If the heap is highly fragmented, you may not be able to page out many pages. If the heap is a brk-based heap and is not highly fragmented after the free phase, it's more likely there would be a bunch of space near the top, and then malloc could shrink the heap at the OS level too. One allocation pattern I can imagine where what you say would have a higher chance of happening, though, is “allocate many times for intermediary data during an operation, then allocate for the result, then free all the intermediary data”, in which case the result might well be stuck at the top of the heap with a bunch of dead pages underneath. But you still take lazy disk I/O doing the paging, and you still take a reservation across system virtual memory as a whole. On the whole I'm not all that convinced that this is a “mitigation” that's worth paying attention to from a developer perspective; it might be more useful from a sysadmin perspective.
For the second, terminology-wise, I've never heard “memory-mapped file” used to refer to anonymous mmap; I think I've only ever heard it called mmap in a Unixy context. On Windows, VirtualAlloc and MapViewOfFile are separate API functions, and VirtualAlloc is the equivalent of anonymous mmap.
Windows allows the creation of additional heaps for HeapAlloc such that a heap can be destroyed all at once, and I presume these use their own VirtualAlloc regions underneath. There are various C libraries that allow arena-based allocation on Unixy systems as well. These can even both reduce manual effort and increase performance if your memory usage patterns involve a large number of allocations for some operation followed by freeing everything, because then you don't have to free every block individually; you just throw away the entire arena, like an in-process equivalent of what exit() does to whole-process memory resources. Your main option in C if malloc is causing fragmentation/performance problems for you isn't usually to jump to raw mmap unless you're writing your own allocator on top of that; it's to jump to picking a more advanced malloc and maybe giving it some extra context about what you're doing with the memory.
Dedicating a time slot in the usual sense is very socially costly if they've gravitated to a presenceless, fast-moving platform, because psychological consensus and topic closure operates more on the perceived speed of communication of the group. If 90% of the other people respond within an hour, and you get there eight hours later, the conversation's moved on, so if everyone else is in the habit of checking their phone every fifteen minutes, there's pressure for you to be too. So, yes, you can “dedicate a time slot” at the end of every pomodoro, if that's what you meant.
This is more true in “channel”-based environments where “new in thread” is inconvenient or unavailable. If you're not careful, you can even be disruptive. Even on slow-moving, old-style Web forums, “necroposting” is considered rude; a chat-like medium with little to no threading support can just lower the threshold for it from weeks to hours if there's enough activity.
For the other part, I'll grant that “get a word in on something important” was badly worded, though I can't think of a better phrase this instant. I was imagining things like “we've changed the meetup location because someone raised a problem, is this okay with everyone or does someone need a ride” or “I'd like comments on which direction I should go with the next part of this piece” or “I'm going to see if some of us can do X together tomorrow, I want three more people, who's with me”. All of these can easily render your participation irrelevant if you show up too late, and “too late” is by default defined by what's usual and convenient, not by abstract considerations of what's good for people's habit formation.
“Hey, I like what we're doing, we should set up a group for it to make it easier to keep up with events and stuff.”
“Telegram? That's what everyone else seems to use.” “Yeah, I've already got that on my phone.” “Me too.” “Yup! And I've got this great sticker pack I want to show you…” “Hey, can you show me how to install it?” “Sure, it's easy, just…”
“Awesome, I'll set it up.” (tap, tap, tap)
(Substitute Facebook, or Discord, or whatever else.)
Gradually people just kinda forget to post things anywhere else, because it's convenient and lets them post from their phone and they get all the encouraging responses they wanted there, and so it gradually becomes common knowledge that that's the place. The choice of platform isn't in their community identity, so the default is whatever people gravitate to that doesn't require doing something unusual.
If you don't integrate psychologically with the popular platforms, you're not really choosing to not be part of a specific community, because that's what “popular” means: you're choosing that the set of communities you can explore in the first place is whittled way down, and your membership in any you do find is now precarious. “Pick a community that doesn't do that” not only raises the difficulty at the beginning, but it also doesn't save you later.
If you've got the kind of social life and communication you need, great. And I agree that many people who are in an accidental too-much-FOMO situation probably didn't need all the extra tweets and whatnot flung their way and it's mostly junk. In that case, just turning most of it off is a reasonable idea.
But if you're in a position where the communities you need to be making more of an effort with use fast-moving, presenceless platforms for most of their socialization (Telegram, Twitter, etc.—maybe even, say, Slack?), good luck snagging those limited opportunities to learn which people to get to know better or get a word in on something important without constantly checking everything. (This might be a good argument to not do that for your next community!)
The idea of more closely regulating the feeling so that it's not overdriven and occupying your whole mindset is still relevant, but it takes on quite a different form if you can't actually afford to check out of the fast side; you have to do a trickier balancing act.
I see some major forces for counterpressure to centralization-gravity on Mastodon:
(1) Mastodon starts with a homogeneous software base (ironically enough) giving “standard” back and front ends—which is then AGPL, meaning that instance owners can and do produce forks, but the forks cannot be held as Secret SaaS for lock-in since anyone who can access the instance can copy the source code from them. (It's probably possible to produce proprietary products that interop through ActivityPub, but this is harder—and importantly, you'll be the odd node out.)
(2) The idea of a “local culture” is prevalent and visible, with differences in content policy, theming, and contents of local/federated timelines. The forks from (1) can amplify this by acting like per-instance customizations with “partial stickiness”. Being on casual-contact terms with your instance administrator is also not uncommon and sometimes encouraged, whereas email is much more impersonal.
(3) The pervasive visibility of (2), mostly from instances doing their own CSS/text tweaks, provides a bridge to the “me but in a different social context” cues that are often missing in centralized social networks, which a number of people are starting to pay more attention to the need for. This while the interfaces remain basically isomorphic enough that there isn't a major UI/model-learning cost to jumping between instances.
(4) Conversely to (3), for users that want efficient access, third-party clients that support multiple accounts at once are very common. But a Web browser also counts as an intermediate form of multi-account client—so long as your accounts are on different instances, which is thus encouraged for convenience!
That's far from the perfect opposite of “distributed and open”, since these habits can be more fluidly shifted and alternate versions of the convenience processes can exist in theory, but it's also far from what I usually hear people implying when they expect things to be socially distributed as well as technically.
(I'm told that GMail similarly changes the nature of email by making it socially unsafe to operate email addresses in certain ways, but I believe this effect is weaker and I don't have real experience with it.)
A colleague of mine said that this suggested what was really necessary was to allow simple prosocial spending that wasn't too in-your-face, along the lines of how it's possible for one person to rent a game server for several people. Less individual anxiety over spending, since among other things there's enough of a social script for that.
Making it purely up to the individual to decide these things when they have to decide in a coordinated way or else connections break down results in unhappy situations. Right now, we have enough coordination anarchy in digital social networks that it leads to some combination of entrenchment, pseudorandomness, and fashion cycles (at least as far as I can see).
In the US, mail became a regulated monopoly, and the telephone network has regulation to try to give newcomers a better playing field and avoid capture effects (not that this always works—but things like “in this metro area, all ten digits must always be dialed so that the new numbers being introduced don't become the lower-class numbers that everyone fights to avoid anyway” have happened). Structure and usage regulations for physical shared community spaces have enough difference in focus and constraints that they don't seem to get applied the same way, and the localization and nature of enforcement mean they don't have the same kind of massive leverage. It is my strong suspicion that the lack of a single consensus “physics” in shared digital spaces (and attendant shared approach/instinct; cultural differences and training aside, human bodies have substantially similar baseline physical capabilities and constraints across the world) means that even with arbitrarily “benevolent” (whatever that means) government intervention, the idea of a level field doesn't work the same way to start with, and there's a panoply of little technical decisions that have “already been made” that combine to make things amazingly awkward on that level as well.
We've tried “just stop using it!” since Stallman started saying it ages ago, and it doesn't work in practice for a lot of people (“because not everyone does it!” is of course the exact coordination problem I'm calling out above). Regulation seems almost untenable from this position, at least assuming pace-of-advancement continues to be a serious concern and expectations haven't globally converged, though I wouldn't be surprised if some particularly fluid kind of regulation popped up (especially from the European sphere) that would break logjams better. What else can usefully be tried if we don't want to wind up in the Big Social hegemony world?
One that I rarely see is “capitulate in an accelerationist manner, let them become governments, and then push to make them good ones”—interesting as a thought experiment, but I wouldn't want to try to put that in practice from here. Can we extract useful information from that, though?
A related observation: to some extent, the success of Mastodon (within several communities I'm part of, enough so that I can use it as part of the primary “social network” set in the same way many people use Twitter and observe a lot of jumping ship there from Twitter along the way, even though in terms of absolute popularity it may still be far weaker) mimics what's been called the Amish-congregation government model to me (you are heavily bound by your choice of instance but it generally remains practical to switch), and instance leaders seem to be taking a much more active and community-centered role than Big Social allows. But that's still ultimately based enough on the Twitter model of interaction that there are lingering social problems (at least I find them to be problems) from that, and the currents of code changes are still a coordination/effort problem of their own, though that's partly mitigated by several instances running interesting forks already while leaving interoperability intact. I'll be very curious to see how that evolves.
I have a project in which I'm juggling a large amount of files imported from external sources, which need to be variably processed and used as-is and in either case must have their names preserved. I wanted to use Make to handle the dependency chaining, but munging file names when inducting them means that I have to unmunge them on every output. Suddenly you can't just zip or grep -H a selection of some of the files anymore; you have to do a whole dance of copy-and-unmunge-name, clean-up-the-temporary-directory, and so on and so on and.
If I could just assign my own names, I could just as well avoid spaces, if it were purely an aesthetic issue. But it really isn't. You don't often need “something that displays as a space but you still get to decide its representation”, you need “passing through exactly the ASCII space without having to worry about it”, or the interoperability concerns still explode in your face one way or another (if they exist in the first place).
People who already have a bunch of good connections can relax because they know they're embedded enough in the minds of their friends and colleagues that dropping off Twitter for a week won't be risking missing the one opportunity that they need to break into the next social class up.