No, it's a fuel rich staged combustion cycle: https://en.wikipedia.org/wiki/RS-25
991 karma · joined March 21, 2015
https://github.com/Badg
https://nickbadger.com
@nbadg
From the title alone, I'd expect a typical think-piece from someone (possibly outside the EU) about overregulation, "the solution is no regulation at all", etc. Instead, it's a solid critique of the recent packaging/packaging waste regulation debacle, from a constructive angle. The first section hits the nail on the head: "a good idea, a terrible implementation".
Unfortunately, this feels like a frequent refrain when it comes to the EU. And even more unfortunately, even just this ever-so-slightly-more-nuanced take seems to frequently be drowned out by the two extremes -- "all regulation is bad and we need pure unadulterated free market capitalism" or "all capitalism is bad and we need pure unadulterated regulation" -- which are by far the two loudest voices in the room.
The OP has some good suggestions about this particular regulation (which should definitely be considered! Fix things are broken; don't just throw the baby out with the bathwater!), but I'd personally be interested to see things that try to understand and treat the root cause instead of yet another symptomatic regulation. Maybe walking further down the path towards federalization? Iunno, but if I had a dime for every time I've thought "good idea, bad execution" as an EU resident... I'd have a lot of dimes.
If you can cripple the everyday workings of government, even temporarily, by shutting off access to Microsoft word, then that is a serious security concern. End of story.
The CSU/CDU Union party (from which Merz comes) has been, at least in recent historical time, consistently pro-nuclear (at least in terms of their actions). They have consistently voted to lengthen contracts with nuclear providers and consistently advocated for pro-nuclear policies, even when the power companies themselves had long since committed to ceasing all nuclear power production in Germany.
Additionally, the exit out of nuclear power was decided following public outcry after Fukushima -- ie, still squarely within the Merkel government. Merz has been consistently anti-Merkel.
So put into context, the article is saying "the current chancellor of Germany, Merz, thinks leaving nuclear behind was a strategic mistake!" while ignoring "whose party has consistently been pro-nuclear, whose predecessor, who (by the way) Merz doesn't like and frequently and loudly disagrees with, only presided over the decade-long phase-out in response to public outcry following a major nuclear disaster".
IMO this is about as newsworthy as what he ate for breakfast.
There may be some offset for goods imported from the US, but that's a minority of consumer goods globally, and even then, the purchase currency will usually still be the local fiat, and then the attractiveness of the US index fund still has to be weighed against the performance of non-US-based indices in that same local currency as opportunity cost.
Is this likely to increase inflation? And what does this mean for FX -- are we likely to see a further weakening of the dollar, particularly against ex EUR?
The benefit of uuid in this case is that it allows horizontally scalable app servers to construct PKs on their own without risk of collisions. In addition to just reducing database load by doing the ID generation on the app server (admittedly usually a minor benefit), this can be useful either to simplify insert queries that span multiple tables with FK relationships (potentially saving some round trips in the process) or in very niche situations where you have circular dependencies in non-nullable FKs (with the constraint deferred until the end of the transaction).
I've read people suggest using a UUIDv7 as the primary key and a UUIDv4 as a user-visible one as a remedy.
My first thought when reading the suggestion was, "well but you'll still need an index on the v4 IDs, so what does this actually get you?" But the answer is that it makes joins less expensive; you only require the index once, when constructing the query from the user-supplied data, and everything else operates with the better-for-performance v7 IDs.
To be clear, in a practical sense, this is a bit of a micro-optimization; as far as I understand it, this really only helps you by improving the data locality of temporally-related items. So, for example, if you had an "order items" table, containing rows of a bunch of items in an order, it would speed up retrieval times because you wouldn't need to do as many index traversals to access all of the items in a particular order. But on, say, a users table (where you're unlikely to be querying for two different users who happen to have been created at approximately the same time), it's not going to help you much. Of course the exact same critique is applicable to integer IDs in those situations.
Although, come to think of it, another advantage of a user-visible v4 with v7 Pk is that you could use a different index type on the v4 ID. Specifically, I would think that a hash index for the user-visible v4 might be a halfway-decent way to go.
I'm still not sure either way if I like the idea, but it's certainly not the craziest thing I've ever heard.
All in all I'd say, I'm impressed, and enjoyed it. Though I think the HN title ("handsdown one of the coolest 3D websites") is maybe a bit much. It's an extremely-well-executed portfolio site; no more, no less.
Huh, thanks for the clarification, that's an angle I hadn't considered.
> I think you're overlooking the part of the iceberg that's currently below the waterline of economic feasibility.
Hm. I think to a degree you probably have a point; I certainly agree that people tend to overlook the explosion of new development that is made possible by drastic cost reductions, though with the aside that having price insensitive applications is often instrumental in developing the technology that enables those cost reductions in the first place, because it allows for profitability early on in the technology's maturation, as opposed for "well it won't be profitable until we hit X milestone in Y years".
That being said, it's not clear to me how many mass-market biological applications would be possible under reasonable regulatory regimes. Maybe I'm just showing my ignorance when it comes to small-scale biological applications, but can you name some examples? (Or is this more of a "you never know until somebody does it" kind of thing?)
Biological applications (of which tooth and bone would of course be included) are extremely well-suited for additive manufacturing because they're frequently one-offs, and therefore cannot scale, and oftentimes highly insensitive to price. Mass market products are a whole different ball game; even for applications where there isn't currently an economical manufacturing method, I'm very skeptical that there's a path where AM could be scaled out to the volumes required to sell the end component at a commercially viable cost.
To be fair though, I didn't do a good job expressing that, because I just took it for granted that it would be clear that large ratios between feature size and nozzle size are rarely economical for FDM-style AM, which isn't necessarily an obvious observation.
At these kinds of physical scales, biology is almost certainly a much larger market than mechanical applications. A 20 um line width (slightly less than one thou for US folks) is certainly a tolerance you might encounter on a drawing for subtractive manufacturing, but for addative, feature sizes that small will be strength limited.
But McMaster and eg Amazon are optimizing for different things. McMaster knows its clientele isn't going shopping, they're solving problems. As such, McMaster focuses on helping your solve your problem and get back to work. Amazon, on the other hand, is focused on just selling you "as much 'anything' as possible" and wants you to spend as much time there as possible in the hopes that you'll stumble on an impulse buy.
But regardless of the transformation methodology: the import hook itself is just a delivery mechanism for the modified code. There's nothing stopping the library from using the same transformation mechanism but accessing it with dynamic programming techniques instead of an import hook. And there's nothing you can't do that way.
I mean if you really need super strong isolation, you can always create a copy of the library object; metaprogramming, dynamic classes, etc, all make it really easy to even, say, create a duplicate class object with references to the original method implementations. Or decorated ones. Or countless other approaches.
My point isn't that I don't see problems that could be solved by this; my point is that I can't think of any problems that this solves, that wouldn't be better solved by things that don't do any innards-fiddling in what is arguably the most sharply-edged part of python: packaging and imports.
And speaking from experience... if you think patching can fail in subtle edge cases, then I've got some bad news for you re: import hooks.
At the end of the day, people who might use this library are looking for a solution to a particular problem. When documenting things, it's really important to be explicit about the pros and cons of your solution, from the perspective of someone with a particular problem, and not from the perspective of someone who's built a particular solution. If I need to drive a nail, and you're selling wrenches, I don't want to hear about all of the features of your wrenches; I want to know if your wrench can drive my nail, and why I would ever want to choose it instead of a hammer.
I can think of a lot of differently-shaped metaphorical nails that fall under the broad umbrella of "I need to change some upstream code but don't want to maintain a fork". And I can think of a whole lot of python-specific specialty hammers that can accomplish that task. But I still can't think of a signle situation where using import hooks to solve the problem is doing anything other than throwing a wrench into a very delicate gearbox. That is the explanation I would need, if I were in the market for such a solution, to evaluate modshim as a potential approach.
I've done my fair share of that too, but I'm still not seeing the benefit vs patching.
Point being, it's a lot of really complicated fiddling with the python import system. And a lesson I have learned is that messing around with import internals in python is extremely tricky to get right. Furthermore, trying to coordinate correctly between modules that do and don't get modified my the hook is very finicky. Not to mention that supply side attacks on the import system itself could be a terrifying attack vector that would be absurdly difficult to detect.
All this to say, I'm not a big fan of monkeypatching, but I know exactly how it behaves, its edge cases, and what to expect if I do it. It is, after all, pretty standard practice to patch things during python unit tests. And even with all its warts, I would prefer patching to import fiddling any day of the week and twice on Sunday.
Feedback for the author: you need to explain the "why" of your project more thoroughly. I'm sure you had a good reason to strike out in this direction, and maybe this is a super elegant solution. But you've failed to explain to me under what circumstances I might also encounter the same problems with patching that you've encountered, in order to explain to me why the risk of an import hook is justified.
IMO, the trick to really enjoying python typing is to understand it on its own terms and really get comfortable with generics and protocols.
That being said, especially for library developers, the not-yet-existant intersection type [1] can prove particularly frustrating. For example, a very frequent pattern for me is writing a decorator that adds an attribute to a function or class, and then returns the original function or class. This is impossible to type hint correctly, and as a result, anywhere I need to access the attribute I end up writing a separate "intersectable" class and writing either a typeguard or calling cast to temporarily transform the decorated object to the intersectable type.
Also, the second you start to try and implement a library that uses runtime types, you've come to the part of the map where someone should have written HERE BE DRAGONS in big scary letters. So there's that too.
So it's not without its rough edges, and protocols and overloads can be a bit verbose, but by and large once you really learn it and get used to it, I personally find that even just the value of the annotations as documentation is useful enough to justify the added work adding them.
I guess I'd never really seriously considered the availability of loans for used cars (beyond the unsecured personal loans); it makes sense that they would exist, but in the ~30 years I lived in the states, I never once heard mention of them, or talked to anyone who had gotten one. Which is pretty crazy if you think about it. I think that, combined with the complete and total lack of regulation surrounding private sales (ie, no way for banks to de-risk the loan), made me assume they just weren't a thing. So I stand corrected.
But I think your anecdote might offer an even more compelling reason why: to satisfy the conditions to actually get one, you find yourself in territory where, from a short-term month-to-month financial perspective, you might as well just be buying new. And if you're struggling to make ends meet... welp, that's that.
The credit score is another good point; it might also be the case that the people who have a good enough credit score to land a decently-priced financing deal on a used car are almost by definition financially capable of buying new. Where I grew up, there was definitely a stigma against buying used, so that seems like it might also have some explanatory power.
Whether or not something like this makes sense to you is probably a question of your personal threat model.
Github shows java, js, rust, and typescript folders, though I didn't poke any further beyond literally just looking at the folder names. [2]
That being said, I'm not entirely sure that's the case here, and this is often also brought up in the context of strengthening the inheritance tax in Germany. In both the inheritance tax and the exit tax, the inherent applicability conditions are such that the end result is that there simply aren't that many people in a situation where it actually has a measurable impact. For the exit tax, you'd need to find people who 1. want to leave Germany, 2. already started a company here, 3. that company grew large enough that the Wegzugssteuer would really be a burden, and 4. that don't have enough liquidity, or cannot raise enough liquidity by selling some of their ownership, to cover the tax. That ends up being a really small number of people, which always eases questions about the reasonability (Angemessenheit) of the law. And in the context of inheritance tax, there's the added point that there's a floor to its application.
As another commenter mentioned, even for those situations where the exit tax actually is burdensome, just as with inheritance tax, there are two really simple solutions: first, create a floor for the minimum valuation by which the exit tax is actually assessed, and second, allow you to "sell" shares to the German government as a means of paying the tax, turning the Finanzamt into a silent shareholder in the company. I think both of these would be substantial improvements to both the German exit tax and inheritance tax.
In other words, it's not an additional claim. It's simply an enforcement mechanism for the money you already hypothetically owe.
That being said, politics aren't the only reason why it might not be deployed. Capitalization issues, for one, are also common. Additionally, you have to make a judgement call about what you consider included in "politics" -- for example, does corruption count?
There are two important things that make something blameless: phrasing and culture. If you've phrased something in such a way that there's a clear value judgement, your phrasing isn't blameless. And if you're writing in a culture where, no matter how precise the phrasing, the simple existence of a name will make people blame them for what happened, then your culture isn't blameless. Both are required for a blameless post mortem.
Also, think of it this way: no amount of anonymization will prevent the people involved from knowing who did what. If they're privately blaming the person for the incident, it's still not a blameless post mortem.
No amount of verbal wallpaper can fix a broken culture.