No, you misunderstand what is going on. htmx is an exercising in learning web development by someone who didn’t follow 2 decades of web development progress.
He is catching up though, now approaching the early 2010s jQuery (moxi) and backbonejs era with fixiproject.org
Htmx is a direct descendant of Intercooler.js, which has been around since circa 2013, more than a decade. Intercooler still exists and is used in production, and you can clearly see that it works almost exactly the same way as htmx does today, it just bundles jQuery together.
The creator has been working on these ideas for a long time, but the core idea–swapping HTML from the server into the DOM–has been constant throughout.
It's exactly because he followed the past two decades of web dev that htmx avoids almost everything about it. Fixi and htmx extensions follow the 80/20 principle and can work by just being dropped in with a script tag. You don't need an elaborate npm setup, same as everything else in the htmx ecosystem.
The creator is stuck in 2012 and so on as I said. If you look at project fixie, the reason htmx 4 exists, it shows how the 80/20 is an incomplete idea for something as general as a web framework. 80/20 might work for your specific use case, but as a general notion, it either gets built on reasonable constructs or grows into a Frankenstein. Htmx approach is a mirror of yaml in my ways. In denial of what it is trying to be and so turns into complete monster.
Taxing AI tokens and Robots is not going to work. We can’t even define a robot, tokens are also too abstract and there is endless ways of gaming it, and let’s not forget cross border operations.
Tax profits, it was always the most equitable option.
I do think taxing profits is still insufficient, because unless the tax rate is close to 100% (lol) the "k-shaped" economy is still reinforced, but just slowed slightly. In combination with a wealth/holdings tax, maybe.
Personally I think the idea of taxing robots/tokens directly is too narrow an idea.
It's undesirable by the companies, but it's not impossible. There's this constant talk about "Making American Great Again (Again)", but not much talk about the economic conditions that made America Great. Like high corporate tax.
That's half the battle. The other half is closing all the loopholes and making stuff that used to be illegal, illegal again (e.g. stock buybacks).
It is because personal income tax should have never existed. Nor should have taxes on primary residence. These are the most regressive taxes possible, it is basically serfdom.
Can you explain this? I think consumption taxes are the most regressive taxes possible because they are "flat" and thus affect lower-income people harder.
Marginal income taxes are regressive now in the sense that folks with more wealth have far more resources to avoid paying them, but otherwise the reasoning seems less regressive than a consumption tax (e.g. VAT)
Tax production as a whole, because profits get hidden in whatever is this week's tax haven. Taxing production has the added benefit of being able to drop every other tax tangentially related to revenue.
It is distasteful to make such accusations. Specially when the author has specifically left out the calculation and merely suggests of a “fraction” which is to be discovered with time.
It's not the only aggrandizing element of the blurb. The whole thing is baseless prediction presented as though it's hard truth, which is either deliberately dishonest or unconcerned with whether it's honest. If it's tasteless to point that out, I'll happily be crass about it.
No, you're not understanding mine. Nobody builds an OS/system expecting that every executable is perfectly well behaved with zero bugs and zero ill intent. Applications are allowed to run code. JITs just run code in that same process. They are already limited to what the process was already allowed to do in the first place.
And my point about C is literally that even without a JIT, applications can still have arbitrary execution vulnerabilities.
A JIT intended to run untrusted code as part of a sandbox, like a browser, is a big risk. But that's because of the untrusted code part, not the JIT. By comparison, something like a Python or Java JIT is as near as makes no difference completely risk free. The JIT is working on exclusively "trusted" code. Same basic concept applies here with this database usage.
Yes, but your claim is that applications can still have arbitrary execution vulnerabilities only on operating systems that allow dynamic executable code.
I am refuting that statement by showing that not allowing dynamic executable code is not enough. It is irrelevant to that end that you can mitigate ROP by other means.
If a process is allowed to execute code, it's always allowed to execute arbitrary code as well. Those two are fully intertwined, be it via dynamic executable code, ROP chains, because it has an interpreter, or because the initial binary itself already is the malicious payload in the first place.
To the OS those are all identical scenarios, it's irrelevant what caused the arbitrary code execution to happen.
> There’s a big difference between fiction when the viewer knows it’s make believe and when it’s presented as factual.
The difference is far more nuanced and borders on inconsequential when it comes to mass media influence on society.
Just because something is presented as fiction or for entertainment doesn’t mean it doesn’t impact your psyche or your perception of the world and others.
It’s complicated, yes, but my point is essentially just that someone saying “<ethnicity> are stealing our country! Force them out!” is specifically calling for violence directed against that group in a way that, say, a movie full of mayhem probably isn’t. That’s because, say, Paramount has editorial control and will never greenlight anything close to what many Facebook / X accounts with hundreds of thousands of followers say every day.
reply