fizzynut

It is a common use case.

Every time you buy a computer it is generally going to be "bleeding edge" to various degrees and it's unlikely to work properly for X months/years.

It is only because people keep their machines for several years that the "average" machine running linux is several years old, yet it seems like a rite of passage for people to blame the user for having the audacity to buy a laptop that isn't 10 years old with X and Y but avoids Z wifi chipset.

Yes, but the risk is not quantified, one also exposes themselves to carcinogens when eating anything that has been smoked and I'm sure if you put kidney cells in a bath of carcinogens it would also not do so great.

Tthe fact that there is no clear data on the danger of microwaving plastic containers despite millions of people doing it all the time means suggests the danger is low/negligible.

It is strange to see people with such mistrust of a microwave because it is "unnatural" and therefore unhealthy.

The process of cooking anything using something "natural" like a fire creates a lot more carcinogens than a microwave.

You wouldn't put plastic in a pan or oven to cook your food in, so if you want to reduce your exposure to plastic just use another container, it would be useful to know what the objective harm of this practice is compared to say using gas stove.

Interesting idea, A small but impactful change I would make would be to change dollar amounts into tokens. e.g. 1 token = $50.

A company might want to buy 1000 tokens and allocate tokens individually to specific issues, but they also might want to put tokens in a pot the maintainer can access to "spend" on issues they want to prioritise for the project or allow them to "spend" tokens at a specific rate, etc.

It also means that money is committed upfront by the companies, i.e. the money is real and exists, has been set aside for this thing and in case of a dispute polar can make decisions, etc

The weight of the car only affects the fuel cost for accelerating to a given speed. Maintaining a speed is almost entirely the surface area * coefficient of drag * speed^2 some of which is used for cooling. Electric cars generally have better drag characteristics, the 3rd variable is largely the driver + speed limits, but yes bigger = worse.

The larger the buffer size, the larger the latency. This is mostly irrelevant for playing an audio file, but in some cases a long chain of buffers in the OS before it leaves to the speaker can be an issue for music.

The main place you will see this issue is playing audio in something like a video game due to an action like pressing a button, firing a weapon, etc then it can be very noticeable if you're buffering too much audio because it wont sync to what you're seeing and the game will feel laggy even if it's running at a high frame rate.

Ah, if you need to know that for certain then you'd be restricted to 18 balls (6,6,6), (2,2,2), (1,1). Otherwise I guess you would "only" know in 26/27 cases if it was heavier or lighter (off the balance in all 3 conditions).

....and now I understand, you would only initially know there is a difference in weight, not which side had the heavier or lighter ball.

I'm not sure why you say it won't work with 14 balls, this is solvable with up to 27 balls in 3 weighs.

Weigh 1: 9 vs 9 (18 on balance), 9 off

Weigh 2: 3 vs 3 (6 on balance ), 3 off

Weigh 3: 1 vs 1 (2 on balance ), 1 off

The default fonts are just plain awful. It's trivial to drop in a better font and make it indistinguishable from native.

Possibly a licensing issue as to why they don't include better ones by default as you have to bake it in? or they want to make the binary as tiny as possible by not using a bigger font file?

The issue in a browser is that you have a default zoom that is often not 100% and you can also "zoom" in/out of web pages which by will cause blurriness or overly sharp images. If you decide to ignore that in favor of the native resolution, then the content size is likely too big or small for what the user expects and it's not clear what the user wants it to look like or scale to even if you did implement that too because of the huge variety in screen sizes and ratios the content could be viewed from.

A native application does not generally have these issues because by nature of being native it was built for the form factor it is being used on.

Generally I'd say that what you're doing WASM can sometimes be a lot slower than native, but if you're using WebGL to do bilinear interpolation that is something that is entirely on the GPU and is basically free, so it's an odd point of reference?

Looking at the unoptimized code itself, it's getting ~150 MFLOPs which is close to C/C++ in the sense that it's only 10-20x slower than what a single core can do before manually doing any vectorization.

Win/Chrome, the clocks for both sides would be frozen if the bug happened then I had to press back, I often had to "redo" my move manually.

I had to click the "back" and "forward" buttons 10+ times during the game for the ai to "play" a move while my clock got significantly lower. Highly frustrating. Seemed related to how fast I played a move.

The problem is that humans fail in very different ways. I don't ever need to wonder if a human driver following behind a road maintenance truck visibly carrying traffic cones or stop signs is going to be a problem...

Besides the fact that these are terrible conditions for a population to live under, I'm not sure you realise how gay people can be perceived and persecuted in these countries, for those visiting for the world cup I can imagine a lot of problem scenarios.

A couple might try to stay at a hotel in a room together, but because they are both men it could suddenly become a serious problem. Maybe they aren't even a couple and are two friends trying to get a cheaper room, but they get arrested and have to prove they are not gay.

A couple might want to enjoy dinner together at a restaurant, maybe that becomes a problem.

A couple might have "incriminating" pictures on their phone and be arrested.

A lot of constants are known at compile time and constexpr solves a lot of problems. However, you do not need constexpr to solve your example- this is still a compile error:

void iter(std::vector<int>& vec) {

     auto& vec_size = vec.size();

     vec_size += 10; //compile error 

}

There are many ways of forcing compile errors for mutexes that people have built, but they all come with their own trade-offs.

I've not encountered a problem where I specifically needed "non-ref-counted shared references while statically avoiding dangling pointers", so I'm not an expert on it.

Like I said, use constexpr.

  constexpr int a = 4;
  auto& b = a;
   
  a+= 1; // compile error
  b+= 1; // compile error

Trying to make b constexpr with "a" as an int is also a compile error.

By definition you can't safely access "non-thread-safe data" from another thread unless it was already safe to access despite being "non-thread-safe", but there are also many ways to make something thread safe.

You can prevent dangling pointers using strong/weak pointers or many other ways depending on the context, most examples are quite contrived though and the only "dangling pointers" I see are usually those relating to resources/handles to things from the OS where the lifetimes need to be managed more carefully, i.e. audio/video/gpu/etc, how would a rust program handle a handle to the currently playing audio device being unplugged and invalidating your handle? Every OS also has its own quirks, so how would it work cross platform?

Constexpr primatives/functions have compile time guarantees and can't be changed.

How is it occams razor?

This person has been caught cheating in the past several times including for prize money tournament so it's much more likely they have cheated many other times and were not caught.

There are many ways you could cheat in a OTB match, most people don't understand how easy it would be, one of the ways you can tell someone is cheating is that they don't understand why their move was good, often computer lines are very unintuitive and moves sacrificing a piece without any positional or tactical compensation mean it has found an idea that requires calculating more moves ahead than any human can.

In the post game analysis hans gave, it was terrible, lines that he suggested often being 1 or 2 move blunders, not expanding on insanely complicated positions, but simply claiming "the chess speaks for itself" and misevaluating who is winning in many variations that were shown, often when deciding between two different lines how well you evaluate the end position is critical to picking the correct line.

I don't know if hans did cheat in this tournament, but if he didn't then he was quite actively giving the impression to the other players that he was, which has would give a huge psychological advantage, not because the opponent "can't concentrate on chess", but because if your opponent is offering you pawns or a piece for "free", in a game against a human you will take it, in a game against an engine taking it means you have already lost.

Please don't make this adversarial.

I've not introduced a security bug in every for loop I've written. What I've written shouldn't be controversial, just take a look at Googles style guide:

"We use int very often, for integers we know are not going to be too big, e.g., loop counters. Use plain old int for such things. You should assume that an int is at least 32 bits, but don't assume that it has more than 32 bits. If you need a 64-bit integer type, use int64_t or uint64_t.

For integers we know can be "big", use int64_t.

You should not use the unsigned integer types such as uint32_t, unless there is a valid reason such as representing a bit pattern rather than a number, or you need defined overflow modulo 2^N. In particular, do not use unsigned types to say a number will never be negative. Instead, use assertions for this.

If your code is a container that returns a size, be sure to use a type that will accommodate any possible usage of your container. When in doubt, use a larger type rather than a smaller type.

Use care when converting integer types. Integer conversions and promotions can cause undefined behavior, leading to security bugs and other problems."

I don't think a for loop using an int is bad or even "more wrong than right". If anything int is much better than using size_t.

Using an integer, in the 1000s of for loops I've written, none get even remotely close to the billions - it is optimizing for a 1 in a million case, and if I know something can run into the billions of iterations I'm going to pay more attention to anyway. I've seen 0 occurrences of bugs relating to this kind of overflow.

Using a size_t, it is effectively an unsigned integer that risks underflowing which can easily cause bugs like infinite loops if decrementing or other bugs if doing any index arithmetic. I've seen many occurrences of these kind of bugs.

That's an interesting way to frame it.

I would say the context of such a sentence is usually something along the lines of:

"Because X wasn't designed with <problem> security, observability, availability, privacy, security, recoverability, documentation, scalability, and long term supportability </problem> in mind, to just do Y it is now also my responsibility to do <problem>"

Ok, a real life comparison, lets say there are 1000s of real life mines around the world that currently mine gold for say $50 per gram, but suddenly a processing technique lowers that cost for all miners to $0.50 per gram. In any normal market the price of gold should trend down.

That's my point though, after the merge the proof of stake nodes are earning a lot of ETH for a fraction of the previous cost, the only way price should stay stable is if everyone with a stake agrees not to undercut each other.

Those with a "stake" of ETH will be gaining $xxxx of ETH for a cost of $x, so why would you not sell for a giant profit?

Given that the merge reduces the electricity cost for new Ethereum by ~1000x, won't the price just tank in a race to the bottom?

Yeah the main issues with visual programming are:

- Logic tends to take up a lot more screen space than real code

- There is no defined way to read the code. In real code you start top left and read left to right and down, but in visual code if there are lots of "paths" then your eyes end up darting around everywhere.

There's many other issues to mention, but in the "memory safe" languages you have poor control over memory allocation and fragmentation, which over time can cause issues with performance, size, swapping, etc.

I would not like to have to interact with an "IT" department for my personal email.

I would not like my email service to store the required personal information to prove who I am.

I would not like to give away personal information to some poorly trained stranger / I would not want to pay whatever the ridiculous cost it is to have 1000s of people employed for this completely automatable job - I don't want to live in Japan.

I think the process of making good decisions about "big" things should involve practicing making many more decisions about smaller things and evaluating the outcome.

There are a lot of insightful heuristics from decision making that can make big decisions much better/easier/etc.

I don't think people would spend any more time on big decisions if they made faster/fewer decisions with little "value" to gain, if anything I think their habit of making fast decisions would mean they spend less time/worse on the big ones!