If you're a power user, then I'd strongly recommend RawTherapee. It's more clunky than Lightroom, but its features are on par with or better than Lightroom, far as quality and choice.

You'll probably have to spend some time playing with it to find your "look", but once you do, Lightroom can't come close.

That said, it's missing a great organization/sorting workflow and painted adjustments, so if you rely on the latter or expect the former in your RAW processor, it might not be for you. A fantastic (commercial) alternative is CaptureOne. It's the Rolls Royce far as I'm concerned. Strongly recommend you stay away from Darktable, because it's close enough to Lightroom (but not as good) that you'll get frustrated.

Hope this helps!

If it’s bad for workflow and sorting, it’s a nonstarter for me.

Depends on your buffer size, bandwidth, and what you're demodulating/decoding, but it's pretty fast. With a narrow bandwidth on a fast port and simple modulation/encoding, maybe a few milliseconds?

Counter-intuitively, it is often difficult to reach low latency with "narrow bandwidth" (you mean low sampling rate), because many SDR interfaces are designed to fill full packets with data, not send tiny packets (ex: Ethernet packets). This problem goes away above 1-10Msps.

I've never seen anyone complain about this, so maybe I'm alone, but the runtime error messages are absolute garbage. Especially if you get an unexpected nil that bubbles up, you'll often see cryptic erlang messages that don't really identify what went wrong. (Think type errors that don't identify the expected type nor the type passed.)

And by that same line of thought, it's frustrating as a functional language given its almost complete absence of built-in monadic types and helpful sugar to use them. Instead of `Maybe`/`Option`, for example, you pass tuples around tagged with atoms. This wouldn't be the end of the world except that...

There's no static typing. Which means that `match` blocks can't enforce completeness. This isn't a huge deal, but for a dynamically typed language, it's surprisingly cumbersome to introspect at runtime. Languages like Ruby make such things first class, such brings me to...

Elixir is nothing like Ruby. With the exception of `def`, `unless`, and `do`, there are nary a few similarities. This isn't necessarily a negative, but the whole notion that Elixir and Ruby share syntax is only barely—and completely superficially—true. In large part, this is because...

There is no method-style syntax. That's not uncommon for a functional language, but it's problematic when the standard library is hugely inconsistent. Is the function you want in the `List` module? Or the `Enum` module? Or is it part of the `kernel`? Hunting around for the right module is a pain, but not as bad as...

Inconsistent naming of functions. Sometimes they're fully spelled out; other times they're abbreviated. And if you're really unlucky, if it's in the kernel, you can expect 1970's Unix-style abbreviations that are so short to be unreadable and have no consistency in how they're formed. US state abbreviations follow more strict rules than Elixir kernel function names. At least one thing Ruby got very right were easily-guessable method names.

There's a lot of good in Elixir; don't get me wrong. But I've spent over a year in it and keep stumbling on very un-aesthetic issues. For such an otherwise wonderful developer experience, these pain points ring loudly.

Frankly, unless you need a lot of parallel things to happen behind the scenes in real-time, I just don't see much use case for Elixir. Its ability to fail and keep going (a major selling point) is great, except that I find it too easy to write code that fails, which can bubble up and create inconsistency in its state. I much prefer something that will help me avoid failure in the first place (Rust us great for that), or something that lets me code fast and loose and makes that experience really enjoyable (like Ruby).

I think I'm alone in these criticisms, however, because I never really see anyone talk about them, so take this all with a grain of salt. I have used a ton of languages in my 25 year career, and I had a lot of hope for Elixir. But, frankly, I just don't get it.

For highly parallel networked applications, it makes sense. For very small things that would otherwise need external service dependencies (Redis, sqlite, etc), it makes sense.

But if your focus is any other use case, I really struggle to justify its adoption. It's not as fast as advertised for anything non-realtime parallel. (Go, Java, Rust, et al all provide much faster alternatives.) It's not as quick to whip up for medium sized projects. (Like Rails.) And it's not as fault tolerant as something like Rust, which can help you avoid the faults in the first place.

LiveView—the latest "must have" for web development—is likewise disappointing, in case that intrigues you. Single-language back- and front-end development sounds great. But it's just back-end streamed to the front end, which is problematic for any significant latency. None of the benefits of front-end except not refreshing the page. It's a fun (and very impressive) toy, but you get almost none of the benefits of a real front-end app. (Such as UI changes while the data is loading.)

While I only have a little experience with LiveView, I have plenty experience with latency-laden server-side echoing to know that when it breaks down without the client doing its own best-guess updates, nobody will have a good time.

Maybe I'm just salty because I expected the Elixir experience to be more than it turned out to be. And I do enjoy some of the things it forces you to do, by virtue of its being a functional language. But at the end of the day, I personally find its warts to be significant and not worth dealing with outside of very specific use cases that it uniquely handles very well.

Your mileage may vary, but I would ask yourself: does my application need lots of real-time, parallel functionality? If the answer is anything short of "hell freaking yes!", then I would look elsewhere for serious development.

I appreciate all the hard work Jose and Chris (and of course all others) have put into their respective portions of the Elixir experience. But I think it was oversold. And I think the number of packages that haven't been touched (or issues responded to) in over 3 years may indicate that others struggle to find its value in many areas in which it was advertised to be a game changer.

I want to like it.

I really don't like it.

I think it's important to dispute your recommendation to keep a mylar blanket in case of emergency.

Those blankets have practically zero thermal advantage, and really are only good to deflect wind, rain, and snow. (As well as signaling.)

Please keep a large wool blanket in your vehicle if you are in a location that threatens extreme cold with the inability to walk to safety.

I would hate for someone to be stuck in a tight spot and realize the useless thermal properties of those blankets the hard way.

People in cold climate know to always have a full set of outdoor clothes in the car, either wearing them or in a bag even for shorter drives. You don’t want to be the guy who freezes to death after not bothering to put on a jacket since you are only picking up a pizza in the next village 3 miles away and then freezing to death because your car broke down.

Well, the one I bought works damn well for heat and had one huge advantage over wool. I can bungee cord it to my car and be very, very visible to any search going on to find me.

I would hope people going out in winter also have proper coats and pants, but extra blankets as well a proper survival kit is a very good thing. Small grain shovels are also quite nice.

Yes. Keep wool clothes and a set of winter coveralls to quickly put on in an emergency

He also feels the same way about the technical crew; the lighting crew, at least. Don't remember where I read it, but he said he lights his stuff primarily with flat overhead lighting these days because he doesn't want the DP/lighting to "waste time" getting lights just right for a shot.

While I immensely enjoy his films, it seems that he has great distain for the fact that filmmaking is a community effort, and simultaneously doesn't have it in himself to fight for his choices, so he just eliminates choice where he can.

Watching his progression over the years, I feel like the penultimate David Fincher film would be sans-actors and camera movement, followed by a film of raw script text pages with his red marker notes scribbled on them.

> Don't remember where I read it, but he said he lights his stuff primarily with flat overhead lighting these days because he doesn't want the DP/lighting to "waste time" getting lights just right for a shot.

It seems like a valid approach for a highly budget-constrained indie director, but for someone in his position that is completely nuts. I wonder if he was being hyperbolic.

Might want to retool it for self-storage businesses. There are a ton of independent self-storage locations (at least in the US) and they predominantly use hotelier software/SAAS. But what makes yours different is that it's modern and looks good. This is a HUGE plus for client-facing services, especially bill paying.

Yes, they're cheapskates. And there's a ton of them, so initial sell is high touch. But there's been a lot of modernization among them, yet their client-facing web presence really isn't being served. So once you've got them, I'd expect to be able to hold on to them--low-touch--for a very, very long time.

Just an idea...

Thank you, I'll look into it!

> societies would soon fall into chaos as everyone is out for themselves.

I'm not sure how this accurate description of the entire history of human society is supposed to refute their hypothesis?

No, they shouldn't be praised for calling out their own errors--let alone be aligned with "courage"--just as one shouldn't praise an encyclopedia or scientific journal for correcting errors: it's supposed to be de facto matter of course.

The criticisms, however, are against their politically loaded decisions to run certain content in the absence of legitimate sources of truth. If this were an occasional thing, sure, accidents happen. But this has become the modus operandi of what once was the paper of record.

Between the absolute backpedaling of the 1619 Project, copious amounts of Russian influence narrative, and countless "anonymous sources" that turn out to be nobodies or absent integrity, the NYT is an embarrassment to journalism.

They do what you described, though: they build in back doors into their reporting so they can legitimately claim that they weren't "wrong" on a purely logical--but functionally bullsh*t--standing.

No, I don't believe they deserve "praise" for "courage and integrity", because they've left those--and other markers of high character--in the past as they cry their death throes in the changing media landscape.

Far as I know, the major calendaring protocols all use HTTP as it is. Do you just want a mediator/self hosted backup? Or do you want to host your own calendars?

If it's the latter, Radicale is awesome.[1]

1: https://radicale.org/3.0.html

I think my biggest difficulty is that I'd like to be able to look at a duration of time and determine the events within that range.

Pulling raw iCal data over HTTP is possible but if you say, set up a recurring event several months back, you need to fetch that original event (even if it recurs every day) to include it in your calculations... I'd love a self-hosted version of this Nylas API [0] for example.

[0]: https://docs.nylas.com/reference#calendars-free-busy

We’ve working on this for one of our side projects. When you have hundreds of calendars and need to find availability for some of them on a timeslot, or fetching the slots for a period of time (I.e, a week) it becames hard really fast.

We are evaluating if it may be interest on it to release as a separate SaaS.

You can find my email on my profile if you want to discuss further your needs.