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.
This shows a profound ignorance for how much of modern life, especially within a bureaucracy, is powered by banal software like office suites.
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.
I get it, for a forum of people who build software for a living, it's upsetting to confront the idea that the stuff you make doesn't actually matter that much, especially in a post-AI world. Hell, even pre-AI you can just install LibreOffice and it will functionally be the same.
But honestly, if we're comparing ENERGY and FERTILIZER to productivity software, it's no contest as to which is more important for the functioning of modern life.
You cannot vibe code your way out of an energy shortage or switch to 'open-source' fertilizer as soon as tomorrow.
Given how fragile unreliable those processes are, you probably can without doing much damage. Its not like replacing good quality software with something vibe coded.
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.
I mean, for retail investors outside the US, the question you're asking boils down to „does purchasing power parity follow popular US domestic market indices?“, to which the answer is a resounding no.
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.
Putting aside, for a moment, a lot of important questions around (gestures broadly at the political situation in the US), what are the economic implications of a conflict between the US and Venezuela?
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?
I don't think you can meaningfully answer this without knowing the military goals or the ultimate outcome.
The worst-case outcome for the US is that it gets pulled into another unpopular, long-term conflict that undermines its international standing and allows assorted rogues to advance their goals (Ukraine, Taiwan, who knows what else).
The best-case outcome is that this is a successful regime change operation which nets the US a resource-rich trading partner, undermines Russia, and scares Iran. How you assess the likelihood of these outcomes sort of depends on your priors.
I would say, however, that the recent history of US military interventions doesn't inspire a lot of confidence. Venezuela is nowhere near being the cluster---- that we've dealt in Afghanistan, Iraq, Syria, etc, but who knows.
Intelligence seems more capable nowadays compared to 2003, probably due to better cyber/SIGINT. It took 3 years for the coalition to find Saddam despite a large ground presence. I wouldn't give Maduro more than a month if the US was intent on taking him out, after the capabilities that we saw in Iran and South Lebanon the last two years that simply did not exist 2 decades ago. For the first time, war has been inverted, and it's the regime that dies first instead of the soldiers.
Second difference is the absence of political Islamism as a dominant ideology in the culture. This makes it more comparable to regime change wars against Japan and Germany in WW2 than recent wars in MENA.
What about radical communism as a binding ideology instead of radical Islamism? I swear that I've heard during at least 5 different wars in my lifetime that things would turn out differently. And I'm not old. Now I want consequences.
I could say the same thing about radical fascism in Germany and Japan, and yet.
Historically, fascism and authoritarianism communism have been temporary secular hysterias that come and go. Ukraine post-Maidan, for example, embraced democracy because they tried communism already and learned that it sucks.
Islamism seems more potent and durable and always rears its head in instability like in Bangladesh most recently, or the Arab Spring before. My explanation for this durability is that it is tied in with religion and is believed to be divinely ordained, rather than just a human made system that sucks.
This is unlike Christianity which is structurally secular by doctrine ('render unto Caesar').
> Islamism seems more potent and durable and always rears its head in instability like in Bangladesh most recently, or the Arab Spring before. My explanation for this durability is that it is tied in with religion and is believed to be divinely ordained, rather than just a human made system that sucks.
> This is unlike Christianity which is structurally secular by doctrine ('render unto Caesar').
That's historical crackpottery. Christianity went through two centuries of religious warfare starting in the early 1500s, with the German population suffering a per-capita death toll higher than WW2. Before that, it launched centuries-long crusades into the Middle East - at some point wiping out the non-Christian people of the city of Jerusalem, which was, and eventually returned to being, a multi-religious city under Muslim rule.
Radical Islamism has only existed since 1979 because of the Iranian revolution. It looks like it's on the decline now. It might have only emerged because of failed efforts at modernising. Europe and the West might have only lapped MENA because they were geographically well-placed to pillage the Americas - not because of any cultural superiority.
[EDIT: I've just read over this, and I'd like to clarify that I like Christianity and Christians in many respects, even though I'm not a Christian myself. I also like the modern West. I just hate lying, hypocritical, cowardly, proud and murderous xenophobes like you]
> I could say the same thing about radical fascism in Germany and Japan, and yet.
Germany and Japan stopped being fascist because nobody was going to let them go back to gassing people.
I'm sorry that I spoke so uncarefully as to cause this reaction in you. I did not knowingly lie, although I may be wrong about many things. I will try to speak with more care next time, especially on topics related to people's identities, which is understandably a sensitive area of discussion that can contribute to fears even if that is not the intention. The world definitely doesn't need more xenophobia on social media.
> The best-case outcome is that this is a successful regime change operation which nets the US a resource-rich trading partner, undermines Russia, and scares Iran.
There is no need to scare Iran. The mullahs are already scared shitless and were utterly humiliated this summer. They could have easily been removed, but it was decided that it was not worth it, as the next regime could be even worse. A weak, scared Iran is the best outcome.
It won't help with oil. The Permian's breakeven prices have crept upwards and, because VZ crude grades are high-sulfur, the US refinery complex can't absorb it without retooling away from the plants specialised for the low-sulfur Permian output.
Possibly dragging supply down, with no net effect at best.
>90% of Venezuelan crude has been refined in China in recent years.
This is going to hurt China economically, and in a way that isn’t going to be seen as targeted at China or unfair by international community.
Russia’s production and refining capacity has been seeing attrition from Ukraine’s efforts. They’re producing less oil, selling it for less, and for rubles that each buy less.
I’ve said before on HN that I thought Venezuela was intended to soak up Russian resources - this is just the next step.
What is the risk calculation one would perform before attempting to invade Taiwan while Trump is calling shots? Whatever else you think about Trump, for better or worse, he is not bound by establishment prerogatives: make the "wrong" move, as Trump exclusively defines it, and anything — literally any conceivable thing plus a distant horizon of things you are cognitively incapable of conceiving — might happen.
Maduro is in a cage somewhere pondering this right now. Iran's leaders are all thinking about the threats Trump made not 48 hours ago, possibly to the great benefit of rebels in the streets right now. Federal investigators are closing in on Walz and friends in Minnesota right now: he could find himself in a cell within earshot of Maduro at any time.
Probably not much. If Maduro is kicked out, you still need time to establish a new government and ramp up oil production. That's bullish, but it's far from guaranteed; there could be coups, instability, etc. If Maduro isn't kicked out, things get murky. Will the US intervene with boots on the ground? Will they just keep sanctions in place? For how long? Will there be resistance?
Actually, thinking about it more, this makes little sense. There's very little upside (and it's far off), while there's plenty of short and long-term downside. Great geopolitical strategizing out there.
I'm also not a huge fan of leaking server-side information; I suspect UUIDv7 could still be used in statistical analysis of the keyspace (in a similar fashion to the german tank problem for integer IDs). Also, leaking data about user activity times (from your other comment) is a *really* good point that I hadn't considered.
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.
I think a bigger benefit from doing that would be that inserts would be cheaper. Instead of an expensive insert into the middle of an index for every table that needs an index on that key, you can do a cheaper insert at the end of the index for all of them except for the one that uses uuid4.
But if you are doing that, why not just use an incrementing integer instead of a uuidv7?
Certainly for many applications, the autoint approach would be fine.
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).
For those that can't get it to load (it takes a minute, and I noticed my desktop's fan kick it up a notch while things were getting initialized, so... YMMV): this is a portfolio site done via a cozy-gaming-style AWSD game where you drive around in a jeep-like thingamabob. There are some cute easter eggs, including a sort of... shrine to each of the socials, which you can run into with your car and knock over (though the links remain clickable, of course!). It also looks like there's some degree of global state; for example, you can "sacrifice yourself to the gods of chaos" (ie drive into a portal) and a counter on the side of the portal goes up, presumably for everyone (since I certainly didn't drive into it 1700 times myself!). There's a strongly consistent art style, and just generally... seems pretty polished. Or at least, that's what it felt like after 5 minutes of driving around.
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.
If you count game demos on the web, then Epic Citadel, based on the port of Unreal Engine to various mobile and web platforms including HTML5/WebGL/asm.js, had a much detailed and more 3D world - it used all 3 dimensions fully, unlike OP which appears to be a flat world that’s quite restricted vertically. That demo first came out about 15 years ago, with the HTML5 version coming out a few years later.
Since then I’ve seen several other sites along similar lines, since Unity released a similar capability, but I haven’t kept track of them. The problem is they’re all essentially games that are more impressive for their look than their functionality, so they tend to have a spike of interest when people first see them and then you never hear of them again. And typically, the tech bitrots and the sites stop working after a while.
You say that as if I've got any control over the browser on the end users device, some of which will be configured to not apply these rules globally for accessibility reasons...
I am irked that on desktop it does not work in Firefox, but only in Chrome (and presumably other Chromium based browsers).
I'm not a big fan of Chrome, for a variety of reasons, but principally because I don't trust it and can no longer use a good ad blocker, so I never really enjoy having to fire it up.
After watching developer's "making of" video, I went and grabbed my USB gamepad (from twenty years ago) — whenever the gamepad is plugged in, Bruno's gamesite stops responding (until controller is unplugged).
I would recon if this isn't playing on your end, it has more to do with using uncommon hardware configurations (not necessarily lack of horsepower).
When it avoids a chrome (and thus google) monopoly: yes. And don’t talk to me about Firefox engine. Its market share is negligible and the whole thing only even still exists because google allows it.
The App Store is the walled garden that doesn't allow anyone else to ship a browser engine, except in certain markets where they have been forced by law to create a "Web Browser Engine Entitlement" that non-WebKit browsers can use with super special permission from Apple.
Because so many people use iPhones as their primary devices it's hard for businesses to accept making their websites only support browsers which are built off Chromium. It somewhat limits the power Google has to unilaterally dictate web standards.
From TFA, they're using it to print bioinks. Think scaffolding for cell cultures.
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.
Mechanical applications at that scale are not well developed, but that doesn't mean their potential is small.
Member sizes below the critical diameter for flaw-sensitivity are crucial to the hardness and durability of, for example, human teeth and limpet teeth, as well as the resilience of bone and jade. Nearly all metals, glasses, and ceramics are limited to a tiny percentage of their theoretical mechanical performance by flaw-sensitivity.
Laparoscopes that require smaller incisions are better laparoscopes. Ideally you could thread in a biopsy-needle instrument through a large vein to almost anywhere in the body.
Visible-light optical metamaterials such as negative-index lenses require submicron feature sizes.
I know a research group that is gluing battery-powered RFID transponders to honeybees.
Electrophoretic e-paper displays are orders of magnitude more power-hungry than hypothetical MEMS flip-dot displays. We just don't have an economical way to make those.
And of course MEMS gyroscopes, accelerometers, and DLP chips are already mass-market products.
There's still a lot of room at the bottom, even if EUV takes thetakes purely computational opportunities off the table.
I'm not trying to say that there aren't plenty of applications for small scale mechanical devices, but rather that the applications where FDM-style 3d printing would be an appropriate manufacturing process are likely to be largely biological.
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.
I largely agree, but I'll take the opportunity to fill in some of the other gaps in the conversation.
I didn't mean that you could 3-D print tiny laparoscopes or even visible-light metamaterials; I meant that you could 3-D print machines for making tiny laparoscopes and visible-light metamaterials.
I agree that FDM-like 3-D printing is not currently attractive for feature sizes many times larger than the nozzle size. You'd need printers with thousands or millions of "hotends".
With respect to biological applications of 3-D printing, I think you're overlooking the part of the iceberg that's currently below the waterline of economic feasibility. Biological applications of 3-D printing are frequently highly-price-insensitive one-offs that cannot scale because people don't even consider the things that will become possible when prices drop by a factor of a billion or a trillion.
> I didn't mean that you could 3-D print tiny laparoscopes or even visible-light metamaterials; I meant that you could 3-D print machines for making tiny laparoscopes and visible-light metamaterials.
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?)
Having used both extensively, Geizhals doesn't hold a candle to McMaster. McMaster is, bar none, the single best e commerce website I've ever used (if you already know what you're looking for, and definitely still top shelf if you don't).
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.
For context: one of the several projects I'm working on right now is an automated extraction system for literate-code-style documentation in python. This isn't the place nor time to talk about the why of it (especially compared to other existing similar solutions). The important thing is the how: it uses a temporary import hook to stub out all module imports, allowing the docs generator to process each module independently at runtime, track imports between them, etc. At the end of the process, it also cleans itself up nicely.
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.
I didn't really get why I'd want to actually use it (vs. just a cool demo) either, until:
> means if you want to make changes to a third-party package, you don't have to take on the maintenance burden of forking, you can package and distribute just your changes.
That's a big win. I've seen and done my share of `# this file from github.com/blah with minor change X to L123` etc.
If the goal is to actually package and distribute the changes via import hook, that makes the supply chain attack question particularly relevant. And it still doesn't explain why you couldn't just package and distribute the monkeypatch itself, instead of creating a whole new import ecosystem surrounding hooks.
I've done my fair share of that too, but I'm still not seeing the benefit vs patching.
Let me explain what inspired me to create modshim:
I've written a Jupyter client for the terminal (euporie), for which I've had to employ monkey-patching of various third-party packages to achieve my goals and avoid forking those packages. For example, I've added terminal graphics support & HTML/CSS rendering to prompt-toolkit (a Python TUI library), and I've changed aiohttp to not raise errors on non-200 http responses. These are things the upstream package maintainers do not want to maintain or will not implement, and likewise I do not want to maintain forks of these packages.
So far I've got away with monkey-patching, but recently I implemented a kernel for euporie which runs on the local interpreter (the same interpreter as the application itself). This means that my patches are exposed to the end user in a REPL, resulting in potentially unexpected behaviour for users when using certain 3rd party packages in Python through euporie. Modshim will allow me to keep my patched versions isolated from the end user.
Additionally, I would like to publish some of my patches to prompt_toolkit as a new package extending prompt_toolkit, as I think they would be useful to others building TUI applications. However, the changes required need to be deeply integrated to work, which would mean forking prompt_toolkit (something I'd like to avoid). modshim will make it possible for me to publish just my modifications.
Perhaps it's a somewhat niche use-case, and modshim is not something most Python users would ever need to use. I just thought it was something novel enough to be of interest to other HN users.
> messing around with import internals in python is extremely tricky to get right
This is true! modshim has been the most complicated thing I've written by some way!
Monkey patching an object attribute, such as a method or a function of a module, may affect 3rd party libraries code that use said object.
This solution is interesting, as it provides the patched code as if it were a new package, indendant of the existing one you have installed, like vendoring, but without the burden of it.
In case you want to be the only one seing your patch, this is great. It also makes the whole maintenance easier, as you don't have to wonder if you patch it at the right time or in the right way. MK can fail in many subtle edge cases.
Inheritance, particularly, is a great Mk pitfall I expect this method to transparently work with.
If you only want your own code to see the patch, then why not just wrap it?
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 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.
All these examples have the dependency order wrong, and you're right on those - it's simpler to wrap them somehow. But this is doing something different, that is either much harder or outright impossible with those methods: Tweaking something internal to the module while leaving its interface alone. This is shown in both their examples where they modify the TextWrapper object but then use it through the library's wrap() function, and modify the Session object but then just use the standard get() interface to requests.
In that case I'd opt for dynamic module creation using metaprogramming instead of an import hook. And I personally would argue that grabbing the code objects from module members and re-execing them into a new module object to re-bind their globals is simpler than an AST transformation.
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.
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.