I talk about the cancelability state and how it can help us shortly after that statement: https://mazzo.li/posts/stopping-linux-threads.html#controlle... . In hindsight I should have made a forward reference to that section when talking about C++. My broad point was that combining C++ exceptions and thread cancellation is fraught with danger and imo best avoided.
I regret to be informed that they still haven't figured this out. I was very active in thread on Linux over 20 years ago, working on glibc and whatnot. That was before C++ had threads, needless to say. There was a time when cancelation didn't do C++ unwinding, only the PTHREAD_CLEANUP_PUSH handlers. So of course cancellation and C++ exceptions was a bad cocktail then.
As I note in the blog post in various places if one can organize the code so that cancellation is explicit things are indeed easier. I also cite eventfd as one way of doing so. What I meant to convey is that there's no easy way to cancel arbitrary code safely.
I have been using signalfd + epoll where it looks like I could use eventfd instead (or just epoll_pwait). Is there a significant benefit to one approach over another? I suspect eventfd might be more efficient (and doesn't use up a signal handler... when are we going to get SIGUSR3 ?!?).
I don't really get it. There are two possibilities here:
* You control all the IO, and then you can use some cooperative mechanism to signal cancellation to the thread.
* You don't control IO code at the syscall level (e.g. you're using some library that uses sockets under the hood, such as a database client library)... But then it's just obvious you're screwed. If you could somehow terminate the thread abruptly then you'll leak resources (possibly leaving mutexes locked, as you said), or if you interrupt syscalls with an error code then the library won't understand it. That's too trivial to warrant a blog post fussing about signals.
The only useful discussion to have on the topic of thread cancellation is what happens when you can do a cooperative cancel, so I don't think it's fair to shoot that discussion down.
Cancellation points and cancellability state are discussed in the post. In a C codebase that you fully control pthread cancellation _can_ be made to work, but if you control the whole codebase I'd argue you're better off just structuring your program so that you yield cooperatively frequently enough to ensure prompt termination.
But I also disagree with it. Yes, the logical conclusion of starting down that path is that you end up with full on use of coroutines and some IO framework (though I don't see the problem with that). But a simple wrapper for individual calls that is recv+cancel rather than just recv etc is better than any solution mentioned in the blog post.
The fact is, if you want to wait for more than one thing at once at the syscall level (in this case, IO + inter thread cancellation), then the way to do that is to use select or poll or something else actually designed for that.
I had this problem, and I solved it by farming the known-blocking syscalls to a separate thread pool. Then the calling thread can just abandon the wait. To make it a bit better, you can also use bounded timeouts (~1-2 seconds) with retries for some calls like recvfrom() via SO_TIMEOUT so that the termination time becomes bounded.
This is probably the cleanest solution that is portable.
Sure. But if you only use it to run blocking requests, it's probably going to be pretty trivial. It won't be super-high performance because of all the cache bounces, but if you're not using something like epoll, then you probably are not really focused on performance anyway.
I don't really claim that Lanczos interpolation as presented is the "best" 2D interpolation there is. It is definitely popular though, and I couldn't find a source explaining how it is derived, so I thought it'd be an interesting topic for a blog post.
(Disclaimer: I'm one of the authors of TernFS and while we evaluated Ceph I am not intimately familiar with it)
Main factors:
* Ceph stores both metadata and file contents using the same object store (RADOS). TernFS uses a specialized database for metadata which takes advantage of various properties of our datasets (immutable files, few moves between directories, etc.).
* While Ceph is capable of storing PBs, we currently store ~600PBs on a single TernFS deployment. Last time we checked this would be an order of magnitude more than even very large Ceph deployments.
* More generally, we wanted a system that we knew we could easily adapt to our needs and more importantly quickly fix when something went wrong, and we estimated that building out something new rather than adapting Ceph (or some other open source solution) would be less costly overall.
There are definitely insanely large Ceph deployments. I have seen hundreds of PBs in production myself. Also your usecase sounds like something that should be quite manageable for Ceph to handle due to limited metadata activity, which tends to be the main painpoint with CephFS.
I'm not fully up to date since we looked into this a few years ago, at the time the CERN deployments of Ceph were cited as particularly large examples and they topped out at ~30PB.
Also note that when I say "single deployment" I mean that the full storage capacity is not subdivided in any way (i.e. there are no "zones" or "realms" or similar concepts). We wanted this to be the case after experiencing situations where we had significant overhead due to having to rebalance different storage buckets (albeit with a different piece of software, not Ceph).
If there are EB-scale Ceph deployments I'd love to hear more about them.
Ceph has opt-in telemetry since a couple of years. This dashboard[0] panel suggests there are about 4-5 clusters (that send telemetry) within the 32-64 PiB range.
It would be really interesting to see larger clusters join in on their telemetry as well.
There are much larger Ceph clusters, but they are enterprise owned and not really publicly talked about. Sadly I can’t share what I personally worked on.
The question is whether there are single Ceph deployments are that large. I believe Hetzner uses Ceph for its cloud offering, and that's probably very large, but I'd imagine that no single tenant is storing hundreds of PBs in it. So it's very easy to shard across many Ceph instances. In our use-case we have a single tenant which stores 100s of PBs (and soon EBs).
Digital Ocean is also using Ceph[1]. I think these cloud providers could easily have 100s of PBs Clusters at their size, but it's not public information.
Even smaller company's (< 500 employees) in today's big data collection age often have more than 1 PB of total data in their enterprise pool. Hosters like Digital Ocean hosts thousands of these companies.
I do think that Ceph will hit performance issues at that size and going into the EB range will likely require code changes.
My best guess would be that Hetzner, Digital Ocean and similar, maintain their own internal fork of Ceph and have customizations that tightly addresses their particular needs.
Last point is an extremely important advantage that is often overlooked and denigrated. But having a complex system that you know inside-out because you made it from scratch pays in gold in the long term.
I've been using this phone as my full time phone for 1 year. It's a great compromise for people that ideally would not want a smartphone, but need to have one since many life situations require it.
I basically only use it for WhatsApp and music, but when some other need arises, it can do everything a normal smartphone can do.
The only problem is that the build quality is not good. The audio jack of the first one I bought (off the initial kickstarter) broke after 6 months or so. I bought another one, and the up volume button recently broke. But otherwise, no complaints.
Interesting. The headphone jack would be my main reason for buying this thing.
Recently forgot my iPad on a trip, and couldn't listen to anything on the plane because my goddamned iPhone lacks a headphone jack. So offensively stupid.
Why not just get a 3.5mm to lightning adaptor? They have knock-off/generic versions at gas stations that cost like 5 dollars and it beats lugging around a whole extra device just to use your headphones
i end up using an adapter (because samsung also arm-twisted me into doing that), but they are typically terrible quality/break, catch on to things, i need to always remember to pack one, and still keep forgetting/losing them. Our overlords at Apple (Samsung promptly followed) decided that we must all switch to airpods, but instead just made it a huge pain for people. Also strange for Samsung whose phones are gigantic, it's not like they don't have enough room.
i was referring more to the topic starter phone - 95.1 × 49.6 × 18.7 mm vs Galaxy S23 146.3 x 70.9 x 7.6. It does seem quite thicker than Galaxy actually. Maybe that's Samsung's excuse. I don't have much experience with (or much interest in) Apple phones, they seem to inspire Samsung to follow the same trends.
Not op, but for me, those things have been finicky and randomly disconnect, and when they do, it's more of a problem because you're removing the whole audio device instead of just the output plug (so like the audio might pause instead of just having some static).
Also, because I use my headphones on other devices with audio jacks, I lose those adapters all the time. Don't really like having a tail on my phone all the time. Vastly prefer having aux on my phones/tablets.
Another alternative is a small 3.5 mm to Bluetooth device. It allows for any 3.5mm output to use Bluetooth and best of all: already paired and battery is on the module not the headphones themselves.
Depends on how "old." Just as pretty much every car finally had an auxiliary input (even the cheapest rental car), Apple deleted the headphone jack from its best-selling music player.
And now we've regressed to no aux inputs, no audio outputs, and nothing but shitty Bluetooth. But the '90s Pioneer head unit in my car has an input, as does my stock 2009 Ranger.
A. I didn't know I didn't have my iPad until I was on the plane. I carry it on all trips. And this shouldn't be an issue anyway.
B. They suck. My girlfriend has a Belkin one in her car that produces so much hiss that it is perceivable as, I'd say, 60% of the volume of the music we're listening to. And when the music fades out, it has some absurd AGC that pumps the hiss up to program level.
C. You can't power the device if the Lightning port is occupied by a dongle.
It's disgusting that consumers tolerate this BS and then make excuses for it.
Note that I was fairly careless with it, and I'm pretty clumsy. It probably fell 20+ times. But still, it feels very cheap (and I suppose it makes sense given the price).
I have a Jelly pro , and has similarly fallen a fair few times and is fine. Feeling cheap doesn't necessarily mean it's less rugged though - a plastic case is generally going to absorb more shock than a glass or metal case like 'premium' phones have. I remember my first android (Galaxy S) was panned for feeling 'cheap' but I dropped that so many times and it's still alive today.
There are other android alternatives that have a headphone jack - though getting fewer each year unfortunately. I want a phone that takes good pictures, has long feature updates, and has an aux jack - I haven't been able to find one in years, so I've been compromising with ones that only get one new android version (plus security updates for 2-3 years)
I am, but I only type the messages I need to type. Which aren't that many. If there's some long explanation to be had I call or I leave a voice message. And yes, I am aware of the fact that everybody hates voice messages, but it's only fair if somebody requires my immediate attention :).
Typing is painful, but not disastrous actually. It's perfectly serviceable.
I used one for about a year. I thought I'd be using voice-to-text a lot to get around this issue, but couldn't get used to the idea. A swipe-style keyboard does make typing much less onerous that you might imagine though.
