This is one of my next learning goals: getting a better feel for which models to use when. "100% claude 4 Sonnet" worked pretty well, but I want to keep pushing myself out of local maxima.
It's niche, but I wasn't really able to find anything else like it. I wanted to project our some retirement scenarios and my options seemed to be:
- Any of a few dozen "retirement calculators," each consisting of 6 fields and very simple outputs
- Building out a series of buggy spreadsheets
- Projection Lab
After messing around for it a bit, it was a "shut up and take my money" situation. It was cheap, it was powerful, it was nice to use, and it has been the foundation for my personal financial strategy for the last few years!
1. D&D mechanics, like all games, are a simplification of the real world using primitives like "firing a bow" and "passing an item" and "downing a potion"
2. The real world is fractaly deep and uses primitives like "plank length" and "quark spin"
3. Therefore there will always be places where the real world and the simplification don't line up. Finding those gaps might be a fun meme, but it's not an exploit. We play with the simplification's primitives, not the real-world physics'.
My approach is that there is a tension between three things:
1. The "combat simulator" built into the rules. I run this according to the spirit of the rules, so that players' investments in classes and feats pays off as expected. Otherwise my players feel cheated.
2. The simulation of the world. This is important because it makes the world feel real and believable (and because as DM, I get many of my plot ideas by "simulating" consequences).
3. The story. The campaign should ideally tell a story. Sometimes this means involving what I think of as "the Rule of Cool (But It's Only Cool the First Time)."
The "peasant railgun", unfortunately, fails all three tests. It isn't really part of the intended combat rules. It doesn't make sense when simulating the world. And it probably doesn't fit into the campaign's narrative because it's too weird.
On the other hand, if a player proposes something really cool that fits into the logic of the world, and that also fits into the story, then I'll look for ways to make it happen.
Let's say the PCs find 200 peasant archers, and set them up on a high hill, and have them all rain down arrows on a single target. That seems like it ought to work, plus it's a great story about bringing the villagers together to save the day. So in this case, I'll happily handwave a bunch of rules, and declare "rain of arrows" to be a stupidly powerful AoE.
But different tables like different things, so this isn't one-size-fits-all advice!
Enough peasants should be devastating, right? Get a couple thousand and at least some will crit per round. Rolling it might be hard. Against a sufficiently armored enemy, might make more sense to just do “expected number of crits per round” or something…
To me this is one of the better things about combat in Dwarf Fortress and one of my least favorite things about most rule sets. It doesn't matter how "high level" you are; outside of specific edge cases a ridiculous number of opponents all landing hits simultaneously ought to do anyone in. Unfortunately most rule sets seem to stop at "lol high AC" with little to no nuance.
Considering a crit always hits in a lot of systems, I don't see how a swarm of weak enemies couldn't overwhelm high level players given enough numbers.
I'm going to be that guy - because I love being that guy, and I won't apologize for it - and point out that we're not even sure if those are primitives!
Haha, yeah, I, I was considering putting some disclaimers around those. "What actually are the true, base-level primitives of physics?" has been an ongoing project for centuries. :)
Yep. Clickhouse is absolutely great for tons of production use cases.
Unless you try to join tables in it, in which case it will immediately explode.
More seriously, it's a columnar data store, not a relational database. It'll definitely pretend to be "postgres but faster", but that's a very thin and very leaky facade. You want to do massively a complex set of selects and conditional sums over one table with 3b rows and tb of data? You'll get a result in tens of seconds without optimization. You want to join two tables that postgres could handle easily? You'll OOM a machine with TB of memory.
So: good for very specific use cases. If you have those usecases, it's great! If you don't, use something else. Many large companies have those use cases.
The majority of our queries have joins (plus our core logic often depends on fact table expansion with `arrayJoin()`s) before aggregations and we're doing fine. AFAIK whenever we hit memory issues, they are mostly due to high-cardinality aggregations (especially with uniqExact), not joins. But I'm sure it can depend on the specifics.
Definitely agree with this, I think ClickHouse can do a lot with joins if you don't implement them naively. Keeping the server up-to-date is a part of it too.
They've made strides in the last year or two to implement more join algorithms, and re-order your joins automatically (including whats on the "left" and "right" of the join, relating to performance of the algorithm).
Their release notes cover a lot of the highlights, and they have dedicated documentation regarding joins[1]. But we've made improvements by an order-of-magnitude before by just reordering our joins to align with how ClickHouse processes them.
> More seriously, it's a columnar data store, not a relational database.
Could you explain why you don't think ClickHouse is relational? The storage is an implementation detail. It affects how fast queries run but not the query model. Joins have already improved substantially and will continue to do so in future.
The storage is not just an implementation detail because it affects how fast things run, which affects which tasks it's better or worse for. There's a reason people reach for a columnar datastore for some tasks and something like postgres or mysql for other tasks, even though both are technically capable of nearly the same queries.
Honestly, it's been pretty great at my tiny startup. The designer has a list of tweaks he wants that I could do pretty quickly... once I'm done with my current thing in a day or two. Or he can just throw claude at it. We've got CI, we've got visual diff testing, and I'll review his simple `margin-left: 12px;`->`margin-left: 16px;`.
But we're unlocking:
A) more dev capacity by having non-devs do simple tasks
B) a much tighter feedback loop between "designer wants a thing" and "thing exists in product"
C) more time for devs like me to focus on deeper, more involved work
Not the person you're replying to, but I often use "fractal complexity" to describe problems with a certain character, and I (and I assume this poster as well) mean it in the more precise sense: as Wikipedia puts it, fractals have "detailed structure at arbitrarily small scales". Fractal problems have complexity at every level of resolution; they're tricky in broad strokes, and if you zoom into one area it's internally complex, and if you zoom into any sub-area it's internally complex, and so on, forever.
Most of computing is this way if we're honest about it; the space of possible sub-disciplines of software engineering is nearly infinite, as is every possible subfield thereof, or sub-sub-field, or...
GeneralMayhem captured it pretty well, but yeah: it's complex at every scale. You see some complexity, you zoom in, and you find that the bit you zoomed in on is just as complex!
Our founders are pretty deep domain experts on aws cost management. At this point one of them has pretty much a catch phrase: whenever I say how I think some little aspect of aws billing works, he'll reply with "Let me complicate that for you" and describe 2-3 edge cases where what I thought I knew doesn't quite apply. :)
Sounds like this is the result of "accelerated depreciation." As far as I can tell, that's a strategy that ultimately allows you to pay less tax one year and more tax in a later year. I don't have a strong feeling on the value of that particular tax law, but it seems somewhat less nefarious than the implied "not paying taxes at all."
Others have pointed out the strategy allows for picking the best year to pay taxes and therefore avoiding a lot of taxes. I'd add to that argument that the current administration is likely to create exceptionally favorable policies for Tesla specifically so they really should burn every trick now since they are about to get a whole new bag of them. I can just see it now, legislation built for Tesla. Of course it will be named something like Save The Children Clean Air Tax Credit Act but it will apply to Tesla almost exclusively as a way to plow money towards loyalist.
I think this is a tax avoidance strategy that may save a lot on taxes. E.g. use accelerated depreciation to avoid taxes in a really profitable year and then if you have a loss or much lower profit in a subsequent year, you have successfully avoided a bunch of taxes. Not an accountant or tax lawyer so there may be a catch here.
That makes no sense, the integral of the tax credit is always the total value of the asset so it doesn't matter unless there are relevant tax brackets here? Businesses can also carryforward losses right?
I'm guessing in a different year the rate will be much lower: afterall, he gave away $1 million a day to a random registered republican voter in a key swing state to get around laws that prevent buying votes and paying people to register to vote.
Ah I forgot his money has nothing to do with tesla and he doesn't run tesla or have a huge stake in it. And he in no way benefits from how future tax changes affect them, right?
This seems somewhat useful. I've definitely found I have a much better signal-to-noise ratio on more focused job boards. The more focused, the better.
Eg when hiring at tiny startups, WorkAtAStartup (or Wellfound, if I'm not currently at a YC company) get a lot more candidates who are actually interested in working at a startup than general tech (or, god forbid, completely-general) job boards.
This is true. Also, there's a really neat platform called partunity.com that's strictly geared towards the world of early-stage startups, resources, and job boards. Worth checking out too.
I'm really interested in this bit: "the fracture with the community is not about licensing, or at least it’s not mainly about licensing"
I wish he'd elaborated a bit more on what he thought it was about. My understanding is that it's 100% about the license. That's certainly why I'll reach for valkey instead of redis next time I need it. That's also what I've heard from everyone else in a similar position. What else would the community split be about?
For somebody, like you and many others, it was very important to retain an OSI license. But I feel that in general given that the new license is IMHO good for almost every user, from the POV of what they can do with the code, and that the cloud situation was quite self evident, I believe that with better communication, and immediate developments/merges in the core, to counter balance the license switch, many people would understand the license matter.
We will not win back you as a user, and I respect that. But many, many users that see openness, good features and documentation, the github repository at the center of everything: I believe they will appreciate this, and can decide that Redis is good for them.
> is IMHO good for almost every user, from the POV of what they can do with the code
I think the thing that hurts a lot of folks is the one thing they wanted to do with Redis is use a managed version of it in AWS. And now they can't. We're trying to figure out our migration path right now and it's almost surely going to be Valkey.
Large vendors were never going to pay up and so it's all loss for everyone involved. I have to do work, every project that works with Redis has to do work to support Valkey now, the eventual divergence will force people to pick a side which will probably also be Valkey for everything other than the client libraries Redis Labs personally develops. It's a mess.
Open core proprietary add-one for new fancy AI features could have avoided the split and gotten you in the door with big cloud vendors willing to sell your add-on in the marketplace with revenue sharing. They did it with Bedrock and Anthropic is making bank off it.
> I think the thing that hurts a lot of folks is the one thing they wanted to do with Redis is use a managed version of it in AWS. And now they can't.
Hum, I have not considered this aspect before - I mean I've realized that AWS probably cannot use Redis [until they pay back], but that users (customers) would be affected...likely I'm biased here cuz not using managed services of that sort, sat having Redis + Sentinel setup of our own.
It sounds like your opinion is that the communication around the relicensing was the issue rather the relicensing itself, but from the standpoint of the people who decided there was enough of an issue to switch away from Redis, is that the case? As an outsider to the Redis community both before and after the schism, I don't know that you're wrong, but I have to imagine that if I were someone concerned enough to consider forking (or switching to a fork), I wouldn't be happy with someone involved in the project making a blanket statement about whether my motivations were actually about the licensing or not. Ironically, this seems like it's exactly the type of communication that could exacerbate concerns around licensing.
How many, outside a few vocal voices, actually cares about the licensing? My company would choose Redis 100/100 times, because it's the known and trusted brand, and not some fork they've never even heard of. And the license change doesn't affect us in any way.
Additionally, I think it's a bit entitled to be so up in arms about a product everyone is using for free. There is a big issue with how open source is unmaintainable to do in our industry, and I applaud Redis' attempt at trying to fix it.
I don't personally have a strong opinion about relicenses to try to prevent competitors from selling cloud-bases services (either in the case of Redis or in general; if anything, having worked at MongoDB at the time when it was relicensed to SSPL biases me a little bit in favor of companies who do relicenses like this). My perception is that there's a non-trivial contingent of users who migrate whenever something like this occurs, but you're not wrong that this might be influenced by a smaller number of louder voices.
I do agree with you about open source developers being within their rights to maintain as they see fit. My personal philosophy is that while open source maintainers have no obligation to maintain in a way that conforms to user expectations, users still have the right to voice their opinions on that (although the maintainers are free to ignore it, per the previous point). To me, the distinction that matters isn't about whether users are "entitled" or not but whether they're voicing opinions about an open source project (including decisions about how to maintain it) versus personal insults at individuals. I don't see anything wrong with someone being vocally upset about a license change; I just also don't see anything wrong with a maintainer choosing not to care about it.
> I do agree with you about open source developers being within their rights to maintain as they see fit.
I used to agree with this, but it now seems a rather narrow view of how open source actually works. Open source projects tend to make a big deal about being a "community," and this is certainly true of many that are backed by commercial vendors. To me the use of community does imply mutual obligations between developers and users or the word has no meaning.
Unless, that is, you think community is just a synonym for "marketing funnel."
One thing is the normal user concerns, that are granted, and I understand and respect them. Another thing is forking, that in the specific case of ValKey was an effort whose impulse was provided by companies having an economic damage because of the license switch. So I think those are two orthogonal questions.
Hmm, I think I see. If I understand correctly, your opinion is that independent of the motivations of the forks, independent users switching to the forks could have been avoided with better communication? I guess that's a fair stance, although I'm not sure I fully agree with it. From what I can tell, there's a fairly large contingent of open source users who won't be happy with a license being changed to something they don't consider open source regardless of the rationale.
I hear you, but at the same time it was badly done. I’ve been referring to Redis as “a proprietary fork of Valkey,” and that message has clearly resonated.
That's like saying Xfree86 is a fork of X.org, MySQL is a fork of MariaDB, or OpenOffice is a fork of LibreOffice. "Forking" is an event that happens in time, so project A cannot be a fork of project B if A existed before B.
Valkey is as much Redis as it is Valkey? Then why isn't it called "Redis"? Clearly there's a distinction or the fork would never have happened. Is Redis also as much Valkey as it is Redis?
Names signal who has control over a project, not anything about its history/implementation/license. Otherwise every piece of software that goes through a rewrite should change its name.
Projects also don’t necessarily change names when control over them changes either. It’s the Ship of Theseus kind of thing. There is no single property that would delimit when software stops being itself. And the name is hardly the most important part.
After all, the identity of ever-changing entities is ephemeral and is only in our heads.
"Valkey" is not called "Redis" because as much as the development is shared by the community, the trademark isn't.
A lot of developers and users are sticking with the community and the license instead of sticking with the trademark holder.
> Names signal who has control over a project
Trademark is a specific form of intellectual property and there are many others. I don't understand how you got to that conclusion to be honest. A restaurant in my neighborhood had to change name recently because it was too similar to a big chain, does that mean it's a different restaurant now?
> But I feel that in general given that the new license is IMHO good for almost every user
That is the nub of the sticking point.
The new is OK for people who only care about getting things done. But for people interested in building and being part of a community, giving as well as taking, not so much
This:
You may not make the functionality of the Software or a Modified version
available to third parties as a service or distribute the Software or a
Modified version in a manner that makes the functionality of the
Software available to third parties.
I care about getting things done but don't want to take on the risk of an encumbered license and the volatility that comes with license changes.
To me, these products are booby traps that are more likely to need replaced in the future when something changes again.
Put another way, it's a sign of an unhealthy ecosystem.
There's so much gray area in these terms you have to keep the lawyers involved not only in the initial indentation but product features in the future to make sure you don't accidentally cross a very poorly defined line.
I'm a vendor of some packaged on-premise solution. We are using a Redis as a cache layer inside. Risk of being forced to GPL out our installer is unacceptable for us.
In your use case, you could not even use the AGPL, basically? Is that what you mean? Thanks. That would be an interesting point, but it goes over the borders of the SSPL itself. Would be more BSD/MIT vs all the rest.
No, we can provide proprietary scripts that install GPLed software (i.e. setup Linux machines), but can't provide proprietary scripts that install AGPL.
also, lack of japanese and korean support... and non-willingness to integrate this when developers native speakers even want to and volunteer to improve it.
you can see there is shift from roots in redis. original over-the-write protocol was human-redable by design. now more and more over last couple years API and instrumentation, docs, gets non-human readable at all (mix of ASCII and hex binary encoding, say in FT.SEARCH, speaking of FT.SEARCH it is barely readable even when in non-binary form...)
Yeah, even if the split isnt entirely about licensing (and I do think it mainly is), the rest is a result of the licensing changes as well in terms of the implications and side-effects. Its the way people felt rug pulled and eroding the trust, which is now forever lost.
Techbros and large corporations still have the original source code they built their business on. What they want is free community updates and support forever while they give almost nothing back. So it's not a licensing problem. It's not a free software problem. It's a "free as in beer" support problem.
AGPL only slightly prevents this by forcing them to share their changes to the source. And usually this is not very useful to the community, anyway. And very little effort. And the same people scream it's an evil license. They want free (as in beer) stuff forever and it's not just the source code. It's very ungrateful of them.
That's not been my experience. My limited experience at a large corporation was "throw money at vendors for enterprise support"
The bigger issue was startups and small/medium sized companies with limited technical support and limited money to buy enterprise support or in-house experts. These are the same companies heavily leaning on managed services from vendors like AWS.
