scratcheee

That does seem sensible yes, I'm also not particularly interested in preventing people from doing stupid things to their cars if they're that insistent on doing them, it just hurts everyone else.

I guess the problem is how to encourage manufacturers to ensure their emissions functions remain high quality. If the _only_ feedback is customers eventually getting failed inspections and thus higher repair bills eventually, which presumably then leads to them complaining about the cost of the cars maintenance, that's a pretty weak feedback loop compared to direct punishment for producing products that fail emissions checks.

The problem is that once you punish manufacturers more directly they start installing these braindead systems in self defense, after all, if nobody can drive their cars when they're broken then they can't be punished for failing emissions checks.

I guess you could just forbid them from blocking customers at the same time as you punish them, but that's a little unsatisfying.

Maybe just require a way to detect modification or emissions override, and anyone who does that pays the fine if they fail inspection, and for anyone else the manufacturer pays. They'd presumably be begging people to install modifications so they can hand off any fines...

Out of curiousity, what solution do you think would work (assuming you accept that enforcing any sort of emissions standards is a good idea overall).

My best attempt: perhaps as long as systems to maintain emissions standards have failed, the vehicle could be made to pay a fine per X miles travelled that approximates the cost of correcting either the actual emissions of that engine or if such data is unavailable, a plausible worst case emissions of the engine. At a vague guess I could see that being $250 per 1000 miles or so (simplifying emissions to be "4x typical CO2 emissions of a van", which could be way off, and current best-case DAC costs to undo the damage ~$250 per tonne).

That's still a fairly steep fine, but at least it isn't artificially limiting the vehicle.

I've yet to see a normally configured browser _not_ be uniquely identifiable many times over through fingerprinting.

At some point it feels like trying to drain the ocean with a cup. Maybe we just need to accept that anyone who really wants to fingerprint you _can_ fingerprint you unless you use a specialist browser.

At that point the solution is fairly obvious, make it legally difficult to use unique fingerprinting and move on (ie stuff like gdpr). People will still do it, but they'll have to balance it with not falling foul of the law and wont be able to abuse it too much.

We wont stop real world facial recognition by all trying to make our faces more similar either, we have to accept it's generally possible to do, but discourage the actual doing of it rather than trying to make it impossible.

(note in both cases, actually preventing it when you have a reason to is totally possible and valid, via specialist browser modes and physical masks respectively)

It's generally true to be fair, reference counting could be used for every garbage collected language (and be much simpler). The only reason they switched to more complex schemes is they're faster on average. Even smart schemes that try to remove unnecessary ref count changes will tend to underperform compared to a (well built) tracing GC. As for a reference, https://en.wikipedia.org/wiki/Tracing_garbage_collection#Per...

The point about predictability is totally valid though (and combined with simplicity is the reason many languages still pick ref counting).

Technically yes, but if you only use it when you need it, it's often not a performance concideration.

And for systems programming, the often overlooked truth is that people care far less about perfect performance than they do about control - ref counting doesn't give up control to a mysterious oracle running in the background which may or may not wreck your performance in hard to predict ways, it just pays a known cost at the time you use it based on how you're using it. (that's not to say performance is irrelevant, but it's not always the top concern, and with control you can always rewrite slow code as needed).

The obvious question is "why can't we have an optional modern garbage collector built into a systems language?", and it's a good question (I remember reading there was one in rust for a while during early development, but it got removed), I think the main reason is that high quality garbage collectors are incredibly complicated, with many trade offs, and a gc that combines well with the rest of a language and various alternative memory tracking solutions is harder than most. The projects that really want one can always implement their own and choose their own tradeoffs, so there's not many use-cases where a generic language-provided one would justify the complexity of implementing it within the language.

The textual information of all books ever written is around 10s of TB.

So if the goal is to store all books for a rainy day, you can buy a grand of storage or you can build the largest library on earth.

That said, a few books would be wise in case of severe energy loss (it would have to be very severe to make running something like a kindle prohibative, but if we're playing doomer then I'll accept a couple of shelves would be sensible).

I believe they do not alter the colour in the region being focused on, they're trying to take advantage of the fact that our peripheral vision is primarily rod-based, and thus unable to discern colour.

So in theory, assuming the display can keep up with eye movements, it should never show you a tightened or limited colour range that you are actually capable of detecting through your eyes.

I suspect it'll be subtly detectable in a couple of ways though, either through rapid eye movements (though I admit I have no clue how fast eye tracking/screen response can be), and secondly (more confidently) that your nose will shine green in the reflected glow of all the green pixels they're cleverly shining where you can't see them directly, and you can definitely see your nose.

>the person writing about the new discovered weird trick almost always fails to precede the article with a big, red, bold "Please don't ever do this"

> It's has been explained enough times. It's just that looking things up for yourself seems to have gone out of fashion.

It appears you've countered your own complaint.

Whilst your point is fair, I do think the fitt's law benefits are pretty huge (ie the infinitely extending target because it's across the screen edge).

It really depends on usage patterns I guess. If you have lots of _really_ small windows then your point is entirely correct, but if people are using large windows then it becomes less clear - there's a fair chance they're moving almost as far to reach the edge of the window for the in-window menu bar, but not benefiting from the screen edge infinite target, at which point the macos model becomes superior.

The thing is I suspect the cut-off applies even for half-screen windows these days, I think the benefits of screen edge scale better than the benefits of window edge (since you can always move faster if you don't have to aim well). On the other hand, I guess there's an upper limit to practical window size, regardless of how large screens get.

The rich/poor divide does indeed exist and has always existed, but that floats separately to the poverty divide. changing one does not change the other. Imagine an ancient communist utopia where all the bread is split evenly - and the 20% who aren't making bread spread their more interesting items across the population equally. Maybe you'll get some nice pottery. By any modern measure of poverty, you have created a utopia of poverty, everyone would be below the modern poverty line.

The rich of ancient times had to scrape their wealth from the labour of _so many_ people.

Meanwhile, if we tried applying the ancient poverty line to a modern rich society, we'd have trouble defining it clearly, even homeless people might sit above it, it barely makes sense.

There's no doubt they help the poor a _little bit_ .

The question is whether there exist alternative solutions that help the poor a lot more by not wasting so much helping the rich (or especially in this case - those buying and selling fossil fuels, industries we'd prefer to be slowing down rather than encouraging with tax breaks).

Eg if the same money "spent" on this tax break had instead been a invested in raising the minimum income tax ceiling, benefits, and pensions (by equivalent amounts), it would presumably have gotten more money into the pockets of those most hurt by fuel inflation, which was the claimed goal of the change, but done less to benefit the fossil fuel industry and those who don't really need tax breaks.

Or to go more extreme you could add an untaxed fuel ration (there is a shortage after all), paid for by higher taxes on extreme usage, thus reducing overuse and increasing affordability at the same time. But that's practically communism, so can't possibly be done (to be fair, it'd be very expensive to implement, so not sure it's a serious suggestion).

It would be a lot simpler if anti-competitive behaviour only encompassed clearly immoral and unfair behaviour, but it tends to be more nuanced than that. There's no simple rule and a court would probably have to spend a long time concidering such a case.

The essential facilities doctrine might apply (the question isn't whether competitors are literally forbidden from the latest chips, it's whether they're "practically or reasonably" unable to access the latest chips, and all evidence suggests that's currently the case). Possibly it's the competitors own fault for refusing to pay the entirely reasonable price TSMC is insisting on, and perhaps Apple's contract with TSMC actually has carefully written clauses to ensure others could practically gain access without having to spend enormous amounts of money, but which nobody has been willing to use for their own reasons, but it certainly seems possible that the contracts effectively ensure Apple have sole access to the latest hardware, which would line up neatly with the apparent scenario we're in - that Apple currently has sole access to the latest hardware.

That's not to say it's a slam dunk case either. I wouldn't care to guess either way.

The <marquee> shall scroll again.

Needs some <blink> to be True Art though.

Feel free!

I mean, I don't think they were claiming the rust way is the only possible form, but rather that any solution as expressive and safe as the rust method will be about as complicated, which doesn't seem to disagree all that much with what you are saying to be honest.

The interesting question is whether there exists some system fundamentally/significantly simpler than the rust approach which still gives you comparable freedom and safety (without excessive runtime overhead).

As far as I know that is unsolved and a matter for research, not some obvious solution that the rust team totally missed when designing their language.

If your goal is lower than total memory safety, then obviously you'll have more options, but when it comes to memory models, you have to be quite careful in where you allow violations, since they tend to infect everything quickly if you don't find exactly the right way to encapsulate them, so having a "half-safe" language often just means you have an unsafe language. Part of the reason unsafe rust is so painful is they're adding exactly that sort of hole in the memory model, and suddenly anyone exposed to it can't deal with the "simple" memory model of rust, they have to deal with all the gory details _creating_ that simple model. Any language adding larger holes than unsafe will need more people to be aware of the full complexity of modern compilation more of the time, which doesn't seem like a win. Rust's unsafe works because it's almost never used. If unsafe was half the codebase, rust would be a failed language.

Another solution is to absolutely refuse to take advantage of your safer memory model in the compiler - so minimal optimizations, just compile literally and throw barriers all over the code, then anyone using a downgraded model doesn't need to know the additional rules they would otherwise need to follow to interact with the full model. That sounds pretty awful though, probably more expensive than just using a garbage collector.

Is there a better solution? Sure, probably, but I don't think humanity has discovered it yet.

The real problem is pretty much any model that doesn't shoot for complete memory safety (or a unsafety that is strongly discouraged and well encapsulated) is going to end up containing all the complexity that comes from unsafety, rust justifies its complexity by all the complexity it also removed (undefined behaviour is basically not a thing in Rust), if you half the complexity compared to rust but retain half the undefined behaviour complexity of C++, I think you'll have just grafted the worst of both together. I'm unconvinced there's a sweet spot in the middle, more like a mountain of extreme complexity (ala rust unsafe) between 2 valleys of relative simplicity (C-like, rust-like).

Better yet if the old tunnel was turned into pedestrian/cycle.

Then you get proper bus options through the taller tunnel, and proper human-powered options with nobody to run them over, win win.

And I guess we're not replacing lorries/vans for a while yet, so they can use the big tunnel with the busses I guess.

And cars can go via the m25, no need for them in the city. Maybe multi-pasenger/disabled only (incentivises carpooling, helps families who need a cubic meter of junk per baby, and disabled people have genuine needs for their adapted vehicles).

But yeah, the harder cars are to use in cities, the better for everyone (even the drivers often enough, still takes them the same time, but now they're not trapped queuing in a fuming tunnel, instead they're dancing playfully through one-way puzzles... ok, maybe it's not much better for them, but not _much_ worse either).

It's really "syntax classification by color" rather than highlighting. The goal is to make related parts of syntax the same color so the brain doesn't have to handle the classification itself (which it's bad at and will short circuit and get wrong sometimes, and take too long other times), sp the goal should usually be to just differentiate parts, not to emphasise/highlight parts (though emphasising code over comments is fairly justifiable, I admit).

You're right because internal combustion engines are so inefficient that more than 50% of energy is wasted before it can even contribute anything. But in terms of useful energy leaving the engine it's a different question.

Once you get to long-haul speeds, the energy cost is almost entirely split between air resistance and rolling resistance, but air resistance has the edge, (about 50%), rolling (30%), drivetrain (5%), and everything else (10%).

Things may change when(if) our machines get smarter than us.

Currently we're constantly expanding the complexity of our systems, but since they don't understand their underlying purpose, they can't help us manage that complexity without drastically limiting their flexibility, there's no working around that.

But if they knew what they were doing, instead of "I need to reorganise this database stack to reduce overhead" we'll be giving simple commands like "please stop taking over the world" and letting the machines handle the complex details.

Agreed that patting someone on the head and telling them they're a good boy despite their nazi views isn't the right move, though that's pretty clearly a strawman of what's being suggested here.

To just convey ideas? Of course it's not necessary. To convince someone to change their world view? This is nowhere near _enough_, just a small start.

They were not talking about couching every fact or snippet taught in physics class getting couched in all this extra "sugarcoating". They were talking about the kind of conversations that almost never go well at all - they're trying to improve the odds of an interaction convincing someone to change their polarized viewpoint from 0.01% to 0.03%.

For that use-case, obviously there's value in exploring different techniques, given the typical technique (scream at them and then block them) doesn't work well at all at actually changing their mind.

>as a result of that, the world's population has been growing and growing

At first yes, but not recently, now the opposite is true, if anything. We haven't had exponential growth since the 60s and are currently headed towards a steady state population because of improved standards of living. Turns out health and properity leads to smaller families.

We do still have significant growth, but that is largely because we're filling out the older demographics in many countries, the birth rate is largely under control already, and once the current generations spread through we'll be in a stead state (around 11 billion). In fact, there's no way to _stop_ this growth now, short of killing or sterilising people, since the birthrate is already under control, we're just waiting for the last exponential generations to get old.

see https://www.youtube.com/watch?v=2LyzBoHo5EI

Long term, we probably should encourage (slightly) sub-2 children per family to let the total population shrink, but that will take a long time (unless something disasterous happens)

The way the psychology of gambling has entered the games industry has indeed produced more money, but at the same kind of costs that the gambling industry has always created.

I don't advocate for killing this new gaming industry, just as I don't advocate for killing the more traditional gambling industry, but both need much stricter supervision than most markets because they attack a weak point in human psychology, and taken too far, they harm humanity more than they generate value.

In the end any "distortion" of the market requires a strong justification, but I think the justifications used against the gambling industry have always been pretty compelling, and they appear to apply just as well to modern games industry techniques.

Another way to put it is that the "value to society" of modern games techniques contains a negative externality: damage to the players comparable to that of gambling addictions. You could solve it with the equivalent of a carbon tax, though defining the cost of different tactics feels impossible, so I'd argue that the traditional gambling restrictions are a better fit (illegal in many places, illegal for children, legal limits, requiring various warnings and protections to discourage extreme behaviours, high taxes, etc).

Many families play boardgames with their children at home. Fewer visit blackjack tables. I think theres a fair argument that these broadly match the different financial strategies in the games industry. How much of this behaviour is parental wisdom and how much is limited accessibility thanks to legal restrictions is a hard question to answer, but I have a suspicion that the world would be a worse place with unrestricted gambling. But kids _do_ sit at home opening lootboxes as their parents watch tv, I'm not sure if the effects are much different.

The parent comment explained pretty well the advantages over __LINE__ imo.

Crafting macros is often black magic, but using them shouldn't be (if they're well crafted). Having an implicit rule in your macro that it cannot be used twice in the same line is surprising and potentially dangerous.

Another example is where you have a macro doing lots of work, if it needs to use a submacro multiple times that itself needs a unique identifier, then __LINE__ is no longer sufficient.

__UEXP_COUNTER__ is a little more difficult to imagine a use-case for, I'll admit (I can see it allows passing counters around, but I can't see why a parameter couldn't do the same).

Again, preprocessor macros are black magic, these additions seem a lot simpler to understand than `__VA_OPT__` (and its predecessor `##__VA_ARGS__`) or MSVCs awful stringify problems, as you brought up.

>Most developers that release iOS software seem to be doing ok with those “unreasonable” rules.

Surely given survivorship bias that means very little though?

If you did a survey today of living people you'd discover a 0% death rate, clearly humans are immortal.

The only way to avoid all-eggs-in-one-basket is to convince everyone to have hybrid everything (ie a gas boiler _and_ a heat pump, and their own personal generator), which would be insanely expensive (note: having mixed infrastructure of electricity for devices and gas for heating is not the same thing, having a charged mobile phone is cold comfort is you can't heat or cook, and having heating doesn't help you economically if a brown out takes down your computer so you can't work), so if we're going to have only 1 method of doing each thing, making that 1 method be electricity means we at least get the flexibility of producing the power from a range of sources and changing that generation on the fly.

Electricity can be produced pretty efficiently from almost any sources. Whilst it has a lead time, that lead time is measured in years to build power generation, rather than decades in replacing peoples devices and the transportation infrastructure.

Alternatives are almost always much less flexible, and are a much bigger danger of getting caught out by a volatile market.

The isolated content processes shouldn't have access to the other processes memory. There might be shared memory regions, but it seems unlikely they'd store the keys to the kingdom in shared memory.

Yeah, and to simplify further, the atmosphere's got a fixed amount of methane-removing capability, and as we exceed this capability it can't absorb methane any faster, so the ratio of methane that gets absorbed starts dropping even though the amount being absorbed doesn't drop.

The reality is more complicated because the cut off is very blurry - absorbsion does still increase as methane increases, just not fast enough to keep up, and it falls further behind the more methane we put out.

I disagree, it is in fact a very polite and fair minded way to respond to claim you find dubious. If anything they were being more polite than later in the comment when they suggested the claimed results should be impossible (though that's still a reasonable claim to make if they beleive it to be true).

Rather than saying the equivalent to "I think this cannot be true", a request for citation merely means "I am interested in this claim and would like to know the source" (even if phrased more tersely). The content is more indicative of the intent than the phrasing, and requesting a citation is not an accusation at all, it is a request for a source for further research.

liquid nitrogen would require better insulation at the least, since its much colder.

I suspect they're also taking advantage of the fact that dry ice is solid, so they're effectively sand-blasting the track (rather than merely pressure-washing it), but they're using sand that helpfully sublimates into the atmosphere without leaving residue (or poisoning anyone).

I imagine blasting sand or chemicals has the downside of leaving residue that can build up, meaning regular cleanup is required, and care required to use enough but not too much, with this you can spray as much as you can afford to buy/carry on the train and you don't have to worry about over-doing it.

Dry ice blasting is already a thing, so I guess they just realised it was a particularly promising technology for this application.