I would love to switch but the battery draw on my mac is just too much! I like to move around to different places in my home as I work so being able to be on battery for a while is a must for me (not to mention that I do travel occasionally)
Hmm, I found Zed to consume battery less than VScode on my M1 MBP. It's ~100 vs ~200 12h power consumption on average according to Activity Monitor. Do you compare it to VSCode?
Are you trying to suggest that this is an example of a planned economy? Maybe you should look at definitions of planned vs market economies. You still have design and regulation in a market economy.
Waiting for your child to come home from a particularly difficult day of kindergarten
"He tasks me. He tasks me and I shall have him! I'll chase him 'round the moons of Nibia and 'round the Antares Maelstrom and 'round perdition's flames before I give him up!"
I have a pet theory that I like to contemplate which is that consciousness is a field that brings the universe into being sort of like how the Higgs field brings mass into being
I am considering dotnet Maui for a project. On the one hand, I am worried about committing to the Microsoft ecosystem where projects like Maui have been killed in the past and Microsoft has a lot of control. Also XML… On the other hand, I’ve been seeing so many impressive technical things about dotnet itself. Has anyone here used Maui and wants to comment on their experience?
I've been a C# developer my entire career and spent a few years building apps with Xamarin/Uno. At my current company, we evaluated MAUI and Flutter for our mobile app rewrite (1M+ monthly active users).
We first built a proof of concept with 15 basic tasks to implement in both MAUI and Flutter. Things like authentication, navigation, API calls, localization, lists, map, etc. In MAUI, everything felt heavier than it should've been. Tooling issues, overkill patterns, outdated docs, and a lot of small frustrations that added up. In Flutter, we got the same features done much faster and everything just worked. The whole experience was just nicer. The documentation, the community, the developer experience... everything is better.
I love C#, that's what we use for our backend, but for mobile developement Flutter was the clear winner. We launched the new app a year ago and couldn't be happier with our decision.
Aside from using an esoteric language and being a Google product with a risk of shutting down just because, Flutter's game-like UI rendering on a canvas was confirmed to be quite a questionable approach with the whole Liquid Glass transition. If anything, React Native is a more reliable choice: endless supply of React devs and native UI binding similar to MAUI.
I'd say Uno Platform[0] is a better alternative to Flutter for those who do not care much about the native look: it replicates WinUI API on iOS, Mac, Android, and Linux, while also providing access to the whole mature .NET ecosystem – something Flutter can't match for being so new and niche.
It simply can't use it because it does not use native UIs, but instead mimics them with its own rendering engine. This approach worked to some extent during the flat minimalist era, but now that Apple has added so many new animations and transitions, reproducing them all has become close to impossible.
At best, Flutter can implement some shaders for the glass'y look of the controls, but something as basic as the Liquid Glass tab bar would require a huge effort to replicate it inside Flutter, while in MAUI and RN it's an automatic update.
Not a single user cares about "native ui", it's only a debate among developers. Take the top 20 apps people are using, all of them use their own design system which isn't native.
Flutter will always have multiple advantages against React Native (and even Native toolkits themselves) in terms of upgradability, you can do 6 months of updates with only 30mins of work and make sure it 100% works everywhere.
The quality of the testing toolkit is also something which is still unmatched elsewhere and makes a big difference on the app reliability.
Classic HN comment with unapologetic statements. If Flutter were that good, it wouldn't have flatlined so fast after the initial hype a few years ago. I tried it last year, only to see rendering glitches in the sample project.
Not everything is related to tech, in my company for example, they picked React Native because they have the ability to tap into the front-end job market (or they think they do), certainly not for it's intrisic qualities.
Personally I've done a 50k+ line project in Flutter and I didn't hit any of these. There's been a few issues for sure but nowhere near what I experienced with React Native (and don't start me on native itself)
All those stats look great on paper, but a few months ago I checked job postings for different mobile frameworks, and Flutter listings were 2-3 times fewer than RN. Go on Indeed and see for yourself.
For a "28% of new iOS apps", the Flutter subreddit is a ghost town with regular "is it dying? should I pick RN?" posts. I just don't buy the numbers because I'm myself in a rather stagnant cross-platform ecosystem, so I know this vibe well.
If I ever leave .NET, no way I'd move to something like Flutter. Even Kotlin Multiplatform is more promising concept-wise. LLMs are changing cross-platform development and Flutter's strong sides are not that important anymore, while its weak sides are critical.
Rendering glitches may be due to completely new, lightweight rendering engine made from scratch, that has replaced Skia. Shoudn't be a problem when it matures a bit.
Speaking as an experienced desktop .NET Dev, we've avoided it due to years of instability and no real confidence it'll get fully adopted. We've stuck with WPF, which is certainly a bit warty, but ultimately fine. If starting fresh at this point I'd give a real look at Avalonia, seems like they've got their head on their shoulders and are in it for the long haul.
I highly recommend using MvvmCross with native UIs instead of MAUI: you get your model and view model 100% cross-platform, and then build native UIs twice (with UIKit and Android SDK), binding them to the shared VM. It also works with AppKit and WinUI.
In the past it was rather painful for a solo dev to do them twice, but now Claude Code one-shots them. I just do the iOS version and tell it to repeat it on Android – in many cases 80% is done instantly.
Just in case, I have an app with half a million installs on both stores that has been running perfectly since 2018 using this ".NET with native UIs" approach.
I have used MAUI at my previous job to build 3 different apps, used only on mobile (Android and iOS). I don't know why many people dislike XAML, to me it felt natural to use it for UI, I researched flutter and liked MAUI/XAML more. Although the development loop felt smoother with flutter. What I didn't like was the constant bugs, with each new version that I was eager to update to fix current issues, something new appeared. After spending countless hours searching through the projects GitHub, I am under the impression that there aren't much resources dedicated to MAUI development from Microsoft, the project is carried forward by few employees and volunteers. If I would start another project I would seriously look into Avalonia. But I always was a backend guy so now at my current job I do server backend development in C# and couldn't be happier.
If you're windows based, I'd unironically consider winforms, it's been re-added to dotnet in windows, and is one of the easiest and best ways to make simple GUI applications.
Sadly it's not cross-platform, which is a benefit of MAUI.
I don't really understand why Microsoft didn't do a Tauri like thing for C# devs instead of this Maui stuff. It would be a tiny project in comparison and then isn't completely going against the grain like Maui is. If you want a write once / run in more places compromise, the browser already does that very well.
Because web UI for a desktop app sucks compared to actual native UI. As a user, any time that I see an app uses Electron, Tauri or any of that ilk, I immediately look for an alternative because the user experience will be awful.
Maui Blazor Hybrid has a cool model where the HTML UI binds to native code (not WASM) for mobile and desktop. That is the closest you can get to Tauri-like. If you want to run that same app in a browser, then it'll use Blazor with WASM.
MAUI Blazor Hybrid is great if you won't want to learn XAML. Apple killed Silverlight, Microsoft kept it running for ~20 years. If you stayed close to what Xamarin was the migration to MAUI isn't bad from what I've seen.
Last time I had to create a C# desktop app, I went with Blazor Hybrid [1]. I'd say it's "Electron for C#". I don't want to use outdated stuff like WPF / WinForms, and I don't trust more recent frameworks, so for me building on top of the web platform felt safest.
I would say it really depends on your target. If you want only mobile, then there's different option's (see other comments). But if you want only desktop then Avilonia is good. However if you want both (like my team) then we did end up going for MAUI. However we use MAUI Blazor as we also want to run on a server. We're finding iOS to be difficult to target but I don't think that has anything to do with MAUI.
I generally don't think about storage I/O speed at that scale (I mean really who does?). I once used a RAID0 to store data to HDDs faster, but that was a long time ago.
I would have naively guessed an interesting caching system, and to some degree tiers of storage for hot vs cold objects.
It was obvious after I read the article that parallelism was a great choice, but I definitely hadn't considered the detailed scheme of S3, or the error correction it used. Parallelism is the one word summary, but the details made the article worth reading. I bet minio also has a similar scaling story: parallelism.
AWS themselves have bragged that the biggest S3 buckets are striped across over 1 million hard drives. This doesn't mean they are using all of the space of all these drives, because one of the key concepts of S3 is to average IO of many customers over many drives.
Unless you have a large cluster with many tens of nodes/OSDs (and who does in a homelab?) then using Ceph is a bad idea (I've run large Ceph clusters at previous jobs).
Disagree. I run Ceph in Proxmox and have for years on a small cluster of 3 used R620 servers without any SSDs.
It’s just worked. I’ve lost two of the machines due to memory failures at two different points in time and the k8s clusters sitting on top didn’t fail, even the Postgres databases running with cnpg remained ready and available during both hardware failures.
Oh sure it works, not denying that. My point is that performance isn't great and if you only have a small cluster then it doesn't take much to make everything fall over because your failure domains are huge (in your case, you only have 3).
But then to offset the above, it also depends on how important your environment is; homelabs don't usually require five nines.
I am a big Proxmox fan but I dislike how easy it makes Ceph to run (or rather, how it appears to be easy). Ceph can fail in so many ways (I've seen a lot of them) and most people who set a Ceph cluster up through the UI are going to have a hard time recovering their data when things go south.
Ceph's design is to avoid a single bottleneck or single point of failure, with many nodes that can all ingest data in parallel (high bandwidth across the whole cluster) and be redundant/fault tolerant in the face of disk/host/rack/power/room/site failures. In exchange it trades away some of: low latency, efficient disk space use, simple design, some kinds of flexibility. If you have a "small" use case then you will have a much easier life with a SAN or a bunch of disks in a Linux server with LVM, and probably get better performance.
How does it work with no single front end[1] and no centralised lookup table of data placement (because that could be a bottleneck)? All the storage nodes use the same deterministic algorithm for data placement known as CRUSH, guided by placement rules which the admin has written into the CRUSH map, things like:
- these storage servers are grouped together by some label (e.g. same rack, same power feed, same data centre, same site).
- I want N copies of data blocks, separated over different redundancy / failure boundaries like different racks or different sites.
There's a monitoring daemon which shares the CRUSH map out to each node. They get some data coming in over the network, work through the CRUSH algorithm, and then send the data internally to the target node. The algorithm is probabalistic and not perfectly balanced so some nodes end up with more data than others, and because there's no central data placement table this design is "as full as the fullest disk" - one full disk anywhere in the cluster will put the entire cluster into read-only mode until you fix it. Ceph doesn't easily run well with random cheap different size disks for that reason, the smallest disk or host will be a crunch point. It runs best with raw storage below 2/3rds full. It also doesn't have a single head which can have a fast RAM cache like a RAID controller can have.[2] Nothing about this is designed for the small business or home use case, it's all designed to spread out over a lot of nodes[3].
It’s got a design where the units of storage are OSDs (Object Storage Devices) which correspond roughly to disks/partitions/LVM volumes, each one has a daemon controlling it. Those are pulled together as RADOS (Reliable Autonomic Distributed Object Store) where Ceph internally keeps data, and on top of that the admin can layer user-visible storage such as the CephFS filesystem, Amazon S3 compatible object storage, or a layer that presents as a block device which can be formatted with XFS/etc.
It makes a distributed system that can ingest a lot of data in parallel streams using every node’s network bandwidth, but quite a lot of internal shuffling of data around between nodes and layers adding latency, and there are monitor daemons and management daemons overseeing the whole cluster to keep track of failed storage units and make the CRUSH map available to all nodes, and those ought to be duplicated and redundant as well. It's a bit of a "build it yourself storage cluster kit" which is pretty nicely designed and flexible but complex and layered and non-trivial.
There are some talks on YouTube by people who managed and upgraded it at CERN as targets of particle accelerators data which are quite interesting. I can only recommend searching for "Ceph at Cern" and there are many hours of talks, I can't remember which ones I've seen. Titles like: "Ceph at CERN: A Year in the Life of a Petabyte-Scale Block Storage Service", "Ceph and the CERN HPC Infrastructure", "Ceph Days NYC 2023: Ceph at CERN: A Ten-Year Retrospective", "Ceph Operations at CERN: Where Do We Go From Here?".
[1] If you are not writing your own software that speaks to Ceph's internal object storage APIs, then you are fronting its with something like a Linux machine running an XFS filesystem or the S3-compatible gateway, and that machine becomes your single point of failure and bottleneck. Then you front one Ceph cluster with many separate Linux machines as targets, and have your users point their software to different front ends, and in that case why use Ceph at all? You may as well have had many Linux machines with their own separate internal storage and rsync, and no Ceph. Or two SANs with data replication between them. Do you need (or want) what Ceph does, specifically?
[2] I have only worked on HDD based clusters, with some SSDs for storing metadata to speed up performance. These clusters were not well specced and the metadata overflowed onto the HDDs which didn't help anything.
[3] There are ways to adjust the balance of data on each node to work with different size or nearly full disks, but if you get to read-only mode you end up waiting for it to internally rebalance while everything is down. This isn't so different to other storage like SANs, it's just that if you are going for Ceph you probably have a big cluster with a lot of things using it so a lot of things offline. You still have to consider running multiple Ceph clusters to limit blast radius of failures, if you are thinking "I don't want to bother with multiple storage targets I want one Ceph" you still need to plan that maybe you don't just want one Ceph.
While most of what you speak of re Ceph is correct, I want to strongly disagree with your view of not filling up Ceph above 66%. It really depends on implementation details. If you have 10 nodes, yeah then maybe that's a good rule of thumb. But if you're running 100 or 1000 nodes, there's no reason to waste so much raw capacity.
With upmap and balancer it is very easy to run a Ceph cluster where every single node/disk is within 1-1.5% of the average raw utilization of the cluster. Yes, you need room for failures, but on a large cluster it doesn't require much.
80% is definitely achievable, 85% should be as well on larger clusters.
Also re scale, depending on how small we're talking of course, but I'd rather have a small Ceph cluster with 5-10 tiny nodes than a single Linux server with LVM if I care about uptime. It makes scheduled maintenances much easier, also a disk failure on a regular server means RAID group (or ZFS/btrfs?) rebuild. With Ceph, even at fairly modest scale you can have very fast recovery times.
Source, I've been running production workloads on Ceph at fortune-50 companies for more than a decade, and yes I'm biased towards Ceph.
I defer to your experience and agree that it really depends on implementation details (and design). I've only worked on a couple of Ceph clusters built by someone else who left, around 1-2PB, 100-150 OSDs, <25 hosts, and not all the same disks in them. They started falling over because some OSDs filled up, and I had to quickly learn about upmap and rebalancing. I don't remember how full they were, but numbers around 75-85% were involved so I'm getting nervous around 75% from my experiences. We suddenly commit 20TB of backup data and that's a 2% swing. It was a regular pain in the neck, stress point, and creaking, amateurishly managed, under-invested Ceph cluster problems caused several outages and some data corruption. Just having some more free space slack in it would have spared us.[1]
That whole situation is probably easier the bigger the cluster gets; any system with three "units" that has to tolerate one failing can only have 66% usable. With a hundred "units" then 99% are usable. Too much free space is only wasting money, too full is a service down disaster, for that reason I would prefer to err towards the side of too much free rather than too little.
Other than Ceph I've only worked on systems where one disk failure needs one hotspare disk to rebuild, anything else is handled by a separate backup and DR plan. With Ceph, depending on the design it might need free space to handle a host or rack failure, and that's pretty new to me and also leads me to prefer more free space rather than less. With a hundred "units" of storage grouped into 5 failure domains then only 80% is usable, again probably better with scale and experienced design.
If I had 10,000 nodes I'd rather 10,100 nodes and better sleep than playing "how close to full can I get this thing" and constantly on edge waiting for a problem which takes down a 10,000 node cluster and all the things that needed such a big cluster. I'm probably taking some advice from Reddit threads talking about 3-node Ceph/Proxmox setups which say 66% and YouTube videos talking about Ceph at CERN - in those I think their use case is a bursty massive dump of particle accelerator data to ingest, followed by a quieter period of read-heavy analysis and reporting, so they need to keep enough free space for large swings. My company's use case was more backup data churn, lower peaks, less tidal, quite predictable, and we did run much fuller than 66%. We're now down below 50% used as we migrate away, and they're much more stable.
[1] it didn't help that we had nobody familiar with Ceph once the builder had left, and these had been running a long time and partially upgraded through different versions, and had one-of-everything; some S3 storage, some CephFS, some RBDs with XFS to use block cloning, some N+1 pools, some Erasure Coding pools, some physical hardware and some virtual machines, some Docker containerised services but not all, multiple frontends hooked together by password based SSH, and no management will to invest or pay for support/consultants, some parts running over IPv6 and some over IPv4, none with DNS names, some front-ends with redundant multiple back end links, others with only one. A well-designed, well-planned, management-supported cluster with skilled admins can likely run with finer tolerances.
RAID doesn’t exactly make writes faster, it can actually be slower. Depends on if you are using RAID for mirroring or sharding. When you mirror, writes are slower since you have to write to all disks.
I think the article's title question is a bit misleading because it focuses on peak throughput for S3 as a whole. The interesting question is "How can the throughput for a GET exceed the throughput of an HDD?"
If you just replicated, you could still get big throughput for S3 as a whole by doing many reads that target different HDDs. But you'd still be limited to max HDD throughput * number of GETs. S3 is not so limited, and that's interesting and non-obvious!
I still feel like you're underselling the article however.
Is obviously ultimately parallelism, but parallelism is hard at scale - because things often don't scale - and incorrect parallelism can even make things slower. And it's not always obvious why something gets slower by parallelism.
As a dumb example, if you have a fictional HDD with one disk and one head, you have two straightforward options to optimize performance:
Make sure only one file is read at the same time (otherwise the disk will keep seeking back and forth)
Make sure the file is persisted in a way that you're only accessing one sector, never entering the situation in which it would seek back and forth.
Ofc, that can be dumped down to "parallelism", because this is inherently a question about how to parallelize... But it's also ignoring that that's what is being elaborated on: ways s3 used to enable parallelism
You're right if you're only looking at peak sequential throughput. However, and this is the part that the author could have emphasized more, the impressive part is their strategy for dealing with disk access latency to improve random read throughput.
They shard the data as you might expect of a RAID, 5, 6, etc array and the distributed parity solves the problem of failure tolerance as you would expect and also improves bandwidth via parallelism as you describe.
The interesting part is their best strategy for sharding the data: plain-old-simple random. The decision of which disks and at which sectors to shard the data is done at random, and this creates the best change that at least one of the two copies of data can be accessed with much lower latency (~1ms instead of ~8ms).
The most crude, simple approach turns out to give them the best mileage. There's something vaguely poetic about it, an aesthetic beauty reminiscent of Euler's Identity or the solution to the Basel Problem; a very simple statement with powerful implications.
The fractional part isn't helping them serve data any faster. To the contrary, it actually reduces the speed from parallelism. E.g. a 5:9 scheme only achieves 1.8x throughput, whereas straight-up triple redundancy would achieve 3x.
It just saves AWS money is all, by achieving greater redundancy with less disk usage.
It never hurts to remember that many of the original European settlers to what is now the US were religious radicals who were forced out of Europe because of their religious beliefs. Their influence lives on to this day
I've never been quite clear on this. We lionize the Pilgrims, but they were one specific bunch in one colony. As far as I can tell they didn't last long as a sect. Many people claim descent, but none are actually Puritans. (Though they may well be lower case puritans.)
Many of the vaunted Founding Fathers were deists, which is just this side of agnostic. They were probably also puritans but none were Puritans.
As far as I can tell we reinvented religion during various Revivals, and what we came up with has only the faintest connection to the version of Christianity that people came here with. They claim connection to that one particular sect, but without either genealogical, intellectual, or theological descent.
I don't fully understand the actual history. But much of what we claim about it is a myth.
Pilgrim "lionizing" is just more of a fairy tale situation. People aren't taught very much about them. Most of the history taught in my experience is in elementary school where obviously you can only go so deep.
The gist that is taught is that they were one of the first and took a big chance is really all it is. There's not much depth to it as far as adoration of the Pilgrims in the US.
I had to read / find some good documentaries later in life before I really learned about them:
This is also my hypothesized reason for the disparity in verbal communication skills between the average Americans and Brit.
If you watch a lot of TV from both countries you will see a very obvious difference in verbal communication. Americans (of which I am one) are so much less articulate when it comes English.
The difference is striking on The Graham Norton Show: almost every American guest stands out as less articulate. This is just one example. Another are interviews with regular people. That’s where it really became obvious.
If religion had been the cause of a lasting difference, I would have expected it to go in the opposite direction. Articulate, persuasive, emotive public testimony done in a declamatory style is part of the fabric of historical American Christianity, much more than the mostly liturgical traditions of British Christianity.
If there is a difference in communication skills, I don't think religious history explains it.
Interesting perspective. I don't find many religious people articulate or persuasive. And how often do they have to give public testimony?
The pilgrims lived in Holland for years in exile before deciding to go to the new world. It would seem to take an extreme group of people to do that, but articulate isn't one of the traits I would assign to them.
> It never hurts to remember that many of the original European settlers to what is now the US were religious radicals who were forced out of Europe because of their religious beliefs. Their influence lives on to this day.
Forced out?
Or wanted their particular version of religion to be 'the only one', (oh, as well as being 'persecuted')?
Whether they were forced out or whether they just had a victim complex (I really don't know enough about history to know and it may be a little of both), I think it is well documented that they weren't wanted there by many. I believe England outlawed whatever religion the Pilgrims were practicing there.
I wish the macro approach to SQLite in Swift was about generating types from a raw query rather than generating table types. I don’t want an ORM. I want to be able to write raw SQL and have the compiler check that SQL for correctness and generate the proper bindings and types for using it. Similar projects like sqlx in rust or safeql in typescript already do this.
> I want to be able to write raw SQL and have the compiler check that SQL for correctness and generate the proper bindings and types for using it.
Our library does allow this a little bit, in addition to a Swift API for building queries. You can write SQL as a string while still using the schema information exposed from the @Table macro. For example, a query to select all reminders lists along with a count of the reminders in each list:
@Table struct RemindersList {
let id: UUID
var title = ""
}
@Table struct Reminder {
let id: UUID
var title = ""
var remindersListID: RemindersList.ID
}
#sql("""
SELECT \(RemindersList.title), \(Reminder.id.count())
FROM \(RemindersList.self)
LEFT JOIN \(Reminder.self) ON \(RemindersList.id) = \(Reminder.remindersListID)
GROUP BY \(RemindersList.id)
""",
as: (String, Int).self
)
Thank you for GRDB! I am using it in a project now and it’s been great. About the benchmarks in this repo though, how can SQLiteData be faster if it uses GRDB under the hood? Are they doing something inefficient or are they bypassing GRDB in some way?
GRDB appears to encourage Codable which is very slow. It does not require it though and there are some alternatives, some of which are also slow. ("Slow" can still mean "fast enough", depending on the user.)
The alternative I've seen for doing this with GRDB seemed more cumbersome and lacks community adoption: https://github.com/Jasperav/GRDB-ORM You must define schema and queries in an unusual external file that a Rust tool transforms for you.
Yes. GRDB encourages Codable because the user can profit from the code generated by the compiler, and this implies that database values are accessed by column name, on top of the Codable runtime, and those layers have a high cost. When necessary it is possible to access database values by position, and in this case GRDB achieves speed of light (performance nearly identical as raw SQLite).
So it appears that there is lightning-fast and lighting-faster.
Of course aside from comparing the dev ergonomics (138 vs 33 lines for the respective benchmarks), either may be fast enough depending on the use case.
BTW I did also see some discussion in swift-evolution about a future replacement for Codable but haven't tracked its progress. I hope they do because Codable is very convenient but tragically slow.
Yes, GRDB even w/ manual help is obviously not as fast raw SQLite. As much respect I have for the author "performance nearly identical as raw SQLite" is incorrect. Lighter also achieves some of the performance characteristics by avoiding allocations for bound parameters (such being statically generated).
I didn't look into SharingGRDB yet, but it seems like those macros could accomplish similar performance, the other way around (Lighter works on the SQLite DB schema).
What I'm not entirely sure of yet is why it even sits on top of GRDB in the first place, instead of just doing the SQLite parts itself. Marketing I suppose.
Nope. And not sure where you get that idea. This release even involved a rename away from including "GRDB."
When 0.1 of the library was released, it was a simple adapter between our Sharing library and GRDB, thus the name SharingGRDB. As our needs grew, the tool evolved significantly, and both the Sharing component and GRDB have become more of an implementation detail. In the future we will consider supporting any SQLite adapter, even your libraries ;)
reply