> On iOS if an app remains in the background for over ~30 seconds, it gets killed.
Except 1) that's not entirely true (famously: music, Zoom) and 2) yes, cooperative state management. Users do not know or care that an app is not actually running if it appears that it is still running when they switch back to it. #2 obviously does not work for many dev use cases, but it would not impact my workflow if e.g. ChatGPT or Chrome were suspended when not in the foreground.
You forgot an important difference: the macbook neo has the A18 Pro chip (2 performance cores + 4 efficiency cores) whereas the macbook air has the M5 chip (4 performance cores + 6 efficiency cores)
Also the A18 Pro chip has a 5-core GPU whereas the M5 chip has 8 or 10.
Personally, the only dealbreaker in the list you posted is the amount of RAM.
macOS 15 uses ~5GB on startup without any app open. I'd be swapping all the time on 8GB of RAM.
> macOS 15 uses ~5GB on startup without any app open
Sort of? Mac very aggressively caches things into RAM. It should be using all of your RAM on startup. That's why they've changed the Activity Monitor to say "memory pressure" instead of something like "memory usage."
I'm typing this on an 8 GB MacBook Air and it works just fine. I've got ChatGPT, VSCode, XCode, Blender, and PrusaSlicer minimized and I'm not feeling any lag. If I open any of them it'll take half a second or so as they're loaded from swap, but when they're not in the foreground they're not using up any memory.
I write algorithms that operate on predictable amounts of data. It's very easy to work out the maximum amount of things we need to have and then allocate it all in fixed size arrays. If you allocate all your memory at startup you can never OOM at runtime. Some containers need over 100GB but like the parent comment said we've already bought the RAM.
The data I operate on come in from the outside world, I can't operate on all of it because most of it doesn't exist yet. I can't process an event that hasn't happened yet
Doesn’t Apple use pretty damn quick NVME? I wonder how much of a performance drop it actually is. Certainly not as bad as running a swap file on a 5400 rpm HDD…
Isn't that NVME also very expensive to replace because it's tied to hardware identifiers? If you keep swapping all the time, surely NVME would be the first part to fail
If you don't have any more disk space for swap, or memory pressure gets too high, you get the "You've ran out of application memory" dialog box with a list of applications you can force quit, and macOS leaves it up to the user on what to kill instead of the system choosing automatically.
> How often are ooms caused by lack of ram rather than programming?
You're right, but in a production deployment, that extra ram might mean the difference between a close call that you patch the next day and an all hands emergency to call in devops and engineers together during peak usage.
It’s counterintuitive but I learned this best by playing RTS games. If you don’t spend money your opponent can outdo you on the map by simply spending their money. But the principle extends, everything you have doing nothing (buildings units etc) is losing. The most efficient process is to have all your resources working for you at all times.
If you don't have savings to spend for a potential change of tactics, larger players, groups or players with different strategies can easily overtake you as your perfectly efficient economy collapses.
Going to also echo the comment that this isn't an RTS
> It’s counterintuitive but I learned this best by playing RTS games. If you don’t spend money your opponent can outdo you on the map by simply spending their money.
OK, hear me out over here:
We are not in an RTS.
Edit: in real-world settings lacking redundancy tends to make systems incredibly fragile, in a way that just rarely matters in an RTS. Which we are _not in_.
Why he wouldn't say it about HDD space? You buy HDD to keep them empty?
And as for the money analogy, what's the idea there, that memory grows interest? Or that it's better to put your money in the bank and leave it there, as opposed to buy assets or stocks, and of course, pay for food, rent, and stuff you enjoy?
1. Store your money in a 0% interest account—leave RAM totally unused—or put it in an account that actually generates some interest—fill the RAM with something, anything that might be useful.
2. Store your money buried in your backyard or put it in a bank account? If you want to actually use your money, it's already loaded into the bank.
Imperfect analogies because money is fungible. In either case though, money getting spent day-to-day (e.g. the memory being used by running programs) is separate.
Because wanting to utilize something as much as you can to get your money's worth, and wanting to fully exhaust it as a resource are two different things.
For slightly different reasons. My game drive is using about 900 GB out of 953 GB usable space - because while I have a fast connection, it's nicer to just have stuff available.
Same for some projects where we need to interface with cloud APIs to fetch data - even though the services are available and we could pull some of the data on demand, sometimes it's nicer to just have a 10 TB drive and to pull larger datasets (like satellite imagery) locally, just so that if you need to do something with it in a few weeks, you won't have to wait for an hour.
I am not following, isn't this just a graph that shows that how fast operations happen is largely dependent on the odds that it is in cache at various levels (CPU/Ram/Disk)?
The memory operation itself is O(1), around 100 ns, where at a certain point we are doing full ram fetches each time because the odds of it being in CPU cache are low?
Typically O notation is an upper bound, and it holds well there.
That said, due to cache hits, the lower bound is much lower than that.
You see similar performance degradation if you iterate in a double sided array the in the wrong index first.
O notation is technically meaningless for systems with bounded resources. That said, yes the performance is depending on the probability of cache hits, notably also the TLB. For large amounts of memory used and random access patterns, assuming logarithmic costs for memory access tends to model reality better.
The author of that post effectively re-defines "memory"/"RAM" as "data", and uses that to say "accessing data in the limit scales to N x sqrt(N) as N increases". Which, like, yeah? Duh, I can't fit 200PB of data into the physical RAM of my computer and the more data I have to access the slower it'll be to access any part of it without working harder at other abstraction layers to bring the time taken down. That's true. It's also unrelated to what people are talking about when they say "memory access is O(1)". When people say "memory access is O(1)" they are talking about cases where their data fits in memory (RAM).
Their experimental results would in fact be a flat line IF they could disable all the CPU caches, even though performance would be slow.
Memory access performance depends on the _maximum size of memory you need to address_. You can clearly see it in the graph of that article where L1, L2, L3 and RAM are no longer enough to fit the linked list. However while the working set fits in them the performance scales much better. So as long as you give priority to the working set, you can fill the rest of the biggest memory with whatever you want without affecting performance.
RAM is always storing something, it’s just sometimes zeros or garbage. Nothing in how DRAM timings work is sensitive to what bits are encoded in each cell.
This is an incorrect conclusion to make from the link you posted in the context of this discussion. That post is a very long-winded way of saying that the average speed of addressing N elements depends on N and the size of the caches, which isn't news to anyone. Key word: addressing.
Huh? There is nothing called "empty memory". There is always something being stored in the memory, the important thing is whether you care about that specific bits or not.
And no, the articles you linked is about caching, not RAM access. Hardware-wise, it doesn't matter what you have in the cells, access latency is the same. There is gonna be some degradation with #read/write cycles, but that is besides the point.
When you open up Activity Monitor, to the immediate left of the "Memory Used" and "Cached Files" that you see, you'll see the Memory Pressure graph that the guy above is talking about.
On my 64 GB M1 Macbook Pro right now, I have 53.41 GB of Memory Used and 10.72 GB of Cached Files and 6.08 GB of swap, but Memory Pressure is green and extremely low. On my 8 GB M1 Macbook Air I just bought for OpenClaw, I'm at 6.94 GB Memory Used and 1.01 GB of Cached Files with 2.05 GB of Swap Used, and Memory Pressure is medium high at yellow, probably somewhere around 60-70%.
You can open up the Terminal and run the command memory_pressure to get much more detailed data on what goes into calculating memory pressure - more than just the amount of swap used, it tracks swap I/O and a bunch of page and compressor data to get a more holistic sense of what's going on and how memory starved you're going to feel in practice.
In any case - I've been absolutely mindblown at how fast my 3 8GB M1 Macbook Airs I just bought for ~$350 brand new have been - even with tons of Chrome tabs open, multiple terminal windows open, running OpenClaw and Claude Code and VS Code and doing a ton of development and testing, never once have they ever felt slow. Oftentimes they actually feel faster than my 64 GB M1 Macbook Pro, which kind of blows my mind and makes me wonder wtf is going on on my monster machine. Moreover, my M1 Macbook Pro drains battery like crazy and uses a ton of charge, whereas the Macbook Airs stay constantly below 10 watts essentially always and even with Amphetamine keeping them on 24/7, with the display off and being fully on, they'll drop to a single watt of power draw. Truly insane stuff. I've lost all my concern about RAM, to be honest (which is shocking coming from someone who bought a top of the line maxed out RAM primary machine in 2021 specifically because I felt like RAM was so important)
don't thinkpads from the similar time go for the same amount of money? seems like an alright price for a machine of that vintage, although thinkpad is obviously superior here since it would always be able to run linux or windows (well that one is not guaranteed) without much, if any, trouble
Yes, the person you are replying to has explained that.
The old mental model of how ram and swap works doesn't fit neatly to how modern macos manages ram. 8GB is acceptable, although on the lower end for sure.
The old mental model doesn't fit how any OS manages RAM. Every OS plays all sorts of fun guessing games about caching, predicting what resources your program will actually need etc. The OS does a lot of work to ensure that everything just hums along as best as possible.
How do you define "swapping?" Even on Intel Macs, the memory statistics don't map the way one might expect. Be careful when making assumptions about what those metrics actually mean.
Unused RAM is wasted RAM. If your machine isn't reporting memory pressure and/or the user isn't experiencing pageouts, then the machine is well-suited to the user's workload.
I remember when Windows Vista had to contend against the same allegations when it was released. It did have a higher memory footprint, but a lot of the ridiculous usage numbers people had published were the SuperFetch just precaching commonly used programs to give better application startup times.
SpeedBoost was supported by vista through windows 10, and although windows 11 regognises a speed boost USB, I do not know it it uses it. When I put windows 11 on two i5 8gb machines and plugged in two speed boost drives, it did not swap a lot to them, whereas in windows 7, under memory load it would use them, at least until I found ChacheMem v2.1 it would manage memory much better than windows ever could.
Windows back to window 2.1 386 supported swapdisks, i.e fake ram.
I found Google Chrome makes an M1 MacBook Air with 8GB RAM almost unusable, unless you're really careful to keep only a few tabs only. I'm curious what browser you were using and if you had any similar experience.
It was my son’s laptop , he’s in high school. General Google Classroom / Google Docs / Gmail / web research stuff. He’s not technical at all. I bought him the 8GB machine thinking it would be fine, but it became a big problem for him.
I do think part of the problem was number of tabs open. It was a little better when I taught him how to manage tabs and I also turned up all the memory saving features in chrome.
But even with all of that, it would still slow down with what looked like a pretty minimal workload.
I spent a few hours with him on it, but he still had these kinds of issues.
It just seems like it requires a decent level of sophistication to work with a small RAM budget if you’re using Google software.
Using an M2 8GB Mac Mini, I only ever ran into problems when trying generative fill in Photoshop. There I get insufficient memory errors if the selection is too large.
> Your SSD is swapping like crazy and will die really fast.
Just how quickly do you think the SSDs will die? Because there are a lot of 8GB M1 machines out there that have been getting daily use for five years, mostly with 256GB or 512GB storage configs. When do you expect them to fail?
So you're predicting that 8GB machines will fail prematurely based on extrapolation from an extreme niche use case that doesn't remotely fit on those machines?
Memory compression is a feature on Windows PCs for years (decades maybe?), it somehow doesn't prevent people from raising valid complaints about swapping with 8Gb or RAM.
I wonder, why is it physically painful for some Apple owners to admit that 8Gb is not enough. Like, I'm using PCs for years and I will be the first in line to point their deficiencies and throw a deserved stone at MS, they never cease to provide reasons. Why is it so different at the Apple?
Because 8GB is literally enough? There are multiple 8GB Macs in this house and they are fine. I wouldn't use them for development work but they're completely competent at the basics.
What's basics? Of course one can always overbuy hardware compared to the tasks but we are discussing some usage more fitting to the laptop form factor. I would argue that for a laptop a basics is at least some kind of office white collar work or similar. And so it is most likely that at least 2-3 of the Electron monstrosities would be used, an office package or something along the lines, multiple loaded tabs in a browser a few of which will be memory leaking enterprise crap, a few communication apps etc. Nothing really outlandish, only handful of apps, but because they are all fat, they will eat the 3Gb margin super fast and start caching.
The storage is fast enough to not be too much of an issue, and the basics would be mostly a web browser, a lot of things can be done with only it, and if you need to do more than web browser, text editors, you probably should want more than the Neo in the first place
Tons of 8GB users out there who are happy. I'm on 16GB and its definitely enough for a power user - and running multiple coding environments, Docker, IDE's. MacOS is really good with caching.
> I wonder, why is it physically painful for some Apple owners
This wasn't necessary. I was just pointing out that 8GB hardware is not the full story. It's also true with windows, as you correctly point out. If you're coming from a slow SSD, or even Linux (it's a relatively new feature to have on by default) you might be pleasantly surprised.
Also, I'm an Apple owner and I have no problem saying it's not enough for anyone on this website. I tried it for a few years as my "second screen" computer, and would bump against it all the time, with glorious screeching as the audio skipped. But, I'm also a developer/power user.
The majority of people aren't power users.and that's the target audience for this. Clearly.
8GB has been completely fine for every non power user I know. Again, the majority of people do everything within a browser, maybe play some music/video at the same time, maybe open an office type app. It's completely acceptable for that, and that should not surprise you, as someone who has an understanding of memory usage and paging, and high bandwidth SSDs, in the slightest.
Perhaps because it's enough for a lot of things. I only came up against the 8GB limit when I ran a LLM locally using Ollama. It worked but wasn't workable.
8GB isn't ideal though and 16GB would've expanded its capacity to do more things. But soon as I want to do more things I shuffle over to my PC with it's dedicated GPU and 32GB o ram
I'm guessing Apple cuts capability to the lower end so as not to hurt sales of the higher end. Usage profile is often dependent on context. There are enough non-power users (when mobile) like me that 8GB isn't ideal but it's enough. And if it wasn't enough we could've paid more for the 16GB, but I personally decided it wasn't worth the ridiculous Apple ram price premium.
So these are my reasons for saying 8GB is enough. I'm also using an M1 MacBook Air, so the puniest of the lineup. Next laptop I'm considering is possibly a think pad with linux so I'm no macOS fanboi.
Not the OP, but I have an M1 MBA and it handles light "coding" stuff quite well, though haven't tried VSCode+Zoom+bunch of other stuff, as my work laptop is a M1 MBP.
I'm printing a new multi-laptop stand that can accommodate a work laptop I've just received. I've actually never used Orca, PrusaSlicer is the first one I tried and it's done everything I've needed.
There's a lot of different kinds of "using". "Memory pressure" includes some kinds of caching (ie running idle daemons when they could get killed) and not others (file caching). And there are also memory pressure warnings (telling processes to try to use less memory), so there's a lot of feedback mechanisms.
I don't suggest sitting and looking at Activity Monitor all day. I think that is a weird thing to do as a user. If you would like to do that in an office in Cupertino or San Diego instead then you can probably figure out where to apply.
i think the main point that GP was trying to make is that depending on the workload 8gb of memory might not be an issue.
the keywords here are "depending on the workload".
edit: i was thinking that it's gonna be interesting to see i/o performance on storage, that might end up determining if those 8 gigabytes are actually decent or not.
Put the M1 in your comparison - I think the A18 Pro compares favorably to it and it's a good baseline for people who bought in on Apple Silicon early and are still using it.
| device | cpu | single core | multi core |
|:----------------------------|:----------------------------------|------------:|-----------:|
| iPhone 16 Pro Max | Apple A18 Pro | 3428 | 8531 |
| iPhone 16 Pro | Apple A18 Pro | 3445 | 8624 |
| MacBook Pro (14-inch, 2021) | Apple M1 Pro @ 3.2 GHz (10 cores) | 2385 | 12345 |
| MacBook Air (13-inch, 2025) | Apple M4 @ 4.4 GHz (10 CPU cores) | 3696 | 14729 |
| MacBook Pro (14-inch, 2025) | Apple M5 @ 4.6 GHz (10 CPU cores) | 4228 | 17464 |
The single core performance difference is wild. Far more than I expected.
My ageing M1 Pro still has better multicore performance than these new laptops. But far worse single core performance. For most users this would be a large upgrade. Well, if you can get by with 8gb of RAM.
My M1 Pro MacBook Pro is only just now occasionally feeling a little slow and showing me a beach ball occasionally but I’m being super picky due to new machine FOMO and it is the best laptop I’ve had by a country mile.
My M1 macbook pro still handles everything I throw at it beautifully. I'd love an excuse to upgrade, but there's no reason to do yet. At least not for me.
I'm going to wait a few more years. The M1 is too good. So is my iphone 12. There's just nothing wrong with my phone other than the lightning port.
I have some clip-on USB-C to Lightning adapters that work really well for charging and Carplay. The connection got flaky at one point, but cleaning the port with some iFixit tools fixed that right up.
Clinging to my iPhone 13 Mini until it's natural death.
That's an M1 Pro chip. Looking at the base MacBook Pro / Air models with the base M1 chip, the multi-core score is about the same, and those laptops are also still going strong:
device | cpu | single core | multi core |
|:------------------------------|:----------------------------------|------------:|-----------:|
MacBook Pro (13-inch Late 2020)| Apple M1 @ 3.2 GHz (8 cores) | 2323 | 8186
If you're concerned about the amount of RAM, this isn't the laptop for you. Grandma doesn't need 16GB to browse Facebook and look at family photos.
I'm actually glad they restricted the memory, because it will create market pressure for devs to stop wasting system resources on bloated electron apps and NextJS. With RAM prices skyrocketing these days people need to be more conscious of how much system resources they're taking up.
> macOS 15 uses ~5GB on startup without any app open. I'd be swapping all the time on 8GB of RAM.
I have an older 8GB MacBook I use for testing. It’s actually fine for normal use with a web browser, Visual Studio Code, Slack, and Spotify running. You’d think it would be an unusable mess from the way some people talk about RAM, but modern OSes are good and swapping lesser used things to the SSD is fast.
Your OS may show 5GB used, but that doesn’t mean all 5GB need to be active in RAM all the time. Letting the OS swap rarely used things out to the SSD is fine.
I'm using a (fairly crappy) HP laptop with 16 gig, running Linux.
I find that the combination of FireFox and Visual Studio gets to the point where it fills up to the point where things get killed (with swap filled as well).
Mate system monitor hilariously reports code using 71MB and firefox-bin using 1.1GB because it has a tree view that doesn't show the usage of collapsed nodes beneath it.
Using smem shows each using multi GB and at my current level I've got 6GB of cache to eat up before it kills code again. Ordering by size Ghostty is the first thing that is not firefox or code at 78MB total. (and about 1GB of non-cache kernel use) . So essentially it's only those two apps that are the problem. Can Macs get by simply because Safari is better with RAM?
Mac is good at managing low memory conditions. Linux is not. When I was on Linux, if I hit 16gb ram used the entire system would freeze for minutes. I would have to go in TTY2 to kill something to get it responsive again.
Thats not how OS RAM usage works. I can’t find one definitive source. But on no modern operating system can you just blindly look at RAM usage by the OS and subtract that from the amount of physical RAM and say that is what is available for applications.
My Debian (KDE) uses just under 1GB on startup. If one is not using animations and things syncing in the background and daemons monitoring file system changes and whatnot, can the stock MacOS memory usage be reduced?
What, in fact, is it doing? I'm of the opinion that RAM not used is RAM wasted, but I prefer that philosophy for application memory, not background OS processes.
> macOS 15 uses ~5GB on startup without any app open. I'd be swapping all the time on 8GB of RAM.
Well for starters MacOS version is currently 26.3 (Tahoe).
Apple ecosystem, if you are not using RAM then it is wasted RAM. So it always optimise to use as much as possible.
The main point however is you are not the target audience. Apple realised that the majority of users don't do anything beyond the power of what the phone supplies. That who this is intended for.
Right now with "green" memory pressure and not so many Safari+FF tabs open, I see 16GB physical, 13.41 used, 2.68 cached, 2.32 swap, 6.57 app, 2.52 wired, 3.89 compressed. Why is there swap used when I have free memory?
I don't know, long ago gave up on understanding this fully. Memory pressure is the only good signal. Or just how slow the Mac feels.
That data may have been evicted during a previous moment of higher memory pressure. If it hasn't been needed since, leaving it in swap probably makes more sense than preemptively paging in data that's known to be cold.
Yeah you're right. But now I'm wondering if it preferred writing to swap over evicting the cache at that time... can make sense if the cache is being hit more than the pages it's swapping out.
13GB app usage is also odd. I feel like running the same thing with half the RAM wouldn't really result in like 5GB of swap.
The limited ram is planned obselescence. It leads to massively increased swap usage and will wear out your non-replaceable ssd to make you get a new machine. In theory
Snikket ( https://snikket.org/ ) is an easier way to self-host an XMPP server. It's a pre-configured Prosody server in a docker image, and you can use it with any XMPP client you like.
> I still use Signal for most day-to-day conversations and I’m not planning to stop.
This will allow you to use your Signal account from your XMPP client.
Bridging audio / video calls isn't currently possible. But most other feature work across the gateway.
I once looked into that and it just confuses me, it’s XMPP but requires an invite? And the snikket client only works with snikket servers, yet it’s actually all based on prosody and conversations? Everything about the project has alarms going off for me.
You're supposed to self-host it (or rent a hosted instance). But rather than having open registration (or creating accounts beforehand and sending the credentials), you generate invites and send them to your contacts. The invites onboard the users to install the app.
The Snikket client works with any XMPP server, and the Snikket server works with any XMPP client.
The Snikket clients are soft forks of existing clients. The reason of their existence is having consistent branding.
In fact, I recommend using Monal as an iOS client instead of the Snikket iOS one.
Note: you can set up invites on any regular Prosody / ejabberd server.
I'm the founder of both the Prosody and Snikket projects. Sorry about triggering alarms :) I can try to explain...
Prosody is a popular choice of XMPP server software. It's used for all kinds of stuff, from self-hosted chat servers to powering Jitsi Meet, to Internet-of-Things applications.
Prosody is extremely flexible, and has a bunch of configuration options that allow you to adapt it and extend it however you want. For some people, this is ideal. Those people should continue using Prosody.
Snikket has a different scope. It is specifically an answer to a question like "How can I easily make a self-hosted WhatsApp/Signal for my family/friends using open-source software?"
- Snikket contains Prosody, for the core chat part. But it's Prosody with a very specific configuration, and the configuration is part of the project, it's not intended to be modified by the person deploying Snikket. They only need to provide the domain name.
- Snikket also includes additional components that a modern chat service needs. For example, it includes a STUN/TURN server to ensure that audio/video calls work reliably (again, preconfigured).
- Snikket provides its own apps, which are tested and developed in sync with each other and with the server. This avoids the common problem of incompatibilities that occur when you have an open ecosystem such as XMPP, where different open-source project developers may develop features at different paces, leaving users to figure out which ones support which feature. It also solves the discoverability and decision fatigue for users (searching "Snikket" on an app store will get you an app that you know is compatible with your Snikket server, you don't have to go through a list of XMPP clients and figure out which one is suitable).
- Snikket servers are not designed to be open public servers (these are an administrative nightmare). Instead, your server is closed and private by default. As the admin, you choose who signs up to your server by sending invitation links. The invitations also serve to simplify the account setup process - no need to prompt users to "choose a server", etc. They just need to provide a username.
Projects such as Conversations differ by running a single public server (conversations.im) and guiding people to sign up on that server, or choose one of a long list of free public XMPP providers. In some cases that's all what you want. But onboarding a group of people that way is not fun (for example, they all have to share their addresses with the group add each other to their contact lists one-by-one - Snikket makes discovery of contacts within the same server automatic).
Beyond these things, Snikket is all open-source and XMPP. But there is a focus on making a good polished and secure "product", if you like, rather than supporting the entire diverse XMPP ecosystem which includes a range of software of varying quality (weekend projects and more recently, 100% vibe-coded clients). For example, Snikket servers require certain security and authentication features which some older codebases that have fallen far behind modern XMPP standards (think Pidgin, etc.) simply don't support today.
> it’s actually all based on prosody and conversations?
As mentioned, I develop Prosody. I also collaborate with the Conversations developer and other XMPP projects. There's nothing shady here. The goal is just to make a best-in-class XMPP project that solves one particular use case (and it was primarily my own use case to begin with of course - I wanted to move my family off WhatsApp).
Ohh, wow. First off, thanks for prosody, been using it for several years, ever since I switched from my early 2000s jabber.org account to selfhosted.
And yeah, I get what you are saying, I'm using it the same way you envision snikket, just for my wife and I. Considering how much time I spent on the initial setup, I can very much see wanting a preconfigured version.
I guess the site was just too "non technical" and went over my head when I tried to grok it (before, a while ago, and now before writing the comment), the lack of a download option for the client on the snikket site combined with repeatably talking about invites just rubbed me wrong.
As I have already setup my server, and have gajim/conversations (which afaik are the best modern Windows/Android clients, for Windows probably even the only one storing modern xmpp) for desktop/mobile, I have no need for snikket, but my view now went from negative to very positive ;)
I'm still experimenting with the messaging on the Snikket website. However my general approach with the site was to pitch Snikket to people who don't know what XMPP is, which is, frankly, the majority of people. Instead, I wanted to focus on explaining features it enables rather than protocol details. But I'm aware it has caused a lot of head-scratching among people who already know Snikket uses XMPP :)
I see Snikket as kind of a gateway into the XMPP ecosystem for people who are unfamiliar with it. After all, if you're already familiar with XMPP then the chances are you'll probably be happier with Prosody or ejabberd, and you'll already have opinions about which clients you want to use (e.g. the upstreams of Snikket).
Yes, definitely. To me, the idea of a chat server that doesn't federate is as absurd as setting up an email server that doesn't federate. I understand that today people know more contacts with email addresses than XMPP addresses, but if we ever want to free ourselves from the current walled gardens, we need to stop treating chat as something that only happens in walled gardens.
Some people get worried about the idea of "federation", thinking that it somehow means their server is less private, and their data is being spread across a mesh of servers, and stuff like that. That's true in some decentralized/distributed chat protocols, but not in XMPP. Connections between servers only happen on-demand, similar how when you send email between different email providers, they will connect to each other to deliver the messages.
However we do have a feature which allows disabling federation access for specific accounts, for example to prevent kids from communicating with anyone outside their own Snikket server. This is a feature I want to expand on, so that you can permit communication with a limited number of approved contacts on other servers.
I am the current lead developer of Pidgin, and would like to reinforce the level of collaboration in the XMPP world. Even with Pidgin being very far behind in XMPP (and everything else) everyone has been very helpful as we're trying to catch back up and answering questions about the prosody instance we run ourselves.
This is a great explanation; Prosody/ejabberd seem to kind of be "everything to everybody" but because they are so general it's hard to know if they're a good fit for any one particular purpose.
Snikket seems to just be a focus or lens on Prosody that answers that question for the mission statement you gave.
Invite only isn't that unusual for personal/friend&family servers. The author also set that in their prosody config.
The snikket client works with many different XMPP servers, why wouldn't it? As you mentioned it's based on Conversations and for iOS on Siskin.
ejabberd is so much easier to set up than prosody, especially containerized. I would highly recommend checking multiple servers out before settling on one tbh.
> In the past, Apple has usually let you hold back on an older version and shipped security updates for all devices, not just ones that are incapable of running the new OS, but not this time.
So, you can't really compare. On iOS you can have 3GB of RAM and it wouldn't be a bottleneck.
reply