ablob

I don't understand your question. The person you replied to never said anything about a boycott. They said that diversification is kind of necessary, so to use both Russian and American services, as both sides do censor/block different things.

Given the recent chat control disaster I'd say our say is rather slim when it matters. Just put a decision into urgency mode (even though technically that's only allowed for the first hearing) and let it be a default pass unless two thirds reject the proposition. If it hits the courtrooms, rewrite it a little bit and effectively keep the status quo.

I might be misinformed, but I believe that American citizens have a way of forcing specific regulation instead of only forcing it to be considered. That would be something we don't have in the EU. So in the end it might just even out in that regard.

I'd like to add an anecdote about machining. Some designers impose incredibly tight tolerances on part shapes that hardly change the overall behavior of the final machine, but are so difficult to produce that sometimes special tools have to be bought and instead of being able to produce 4 parts an hour it might just be one instead.

Maybe this sentiment stems from being software engineers, but at least for hardware it becomes abundantly clear that "good enough" is a desirable state unless you want to spend years in development. The only direct comparison I can find in software is computer graphics, where the endeavor often halts as soon as the average person can't perceive a difference anymore.

You have to deal with this no matter what unless you can live with wasting storage space. You have to arrange extra sales or try and donate stuff (basically, go through all possible options that exclude it from being exempted) if you want to get rid of an item. Your estimates on sales count need to be pretty spot on to keep that low. Donations are still taxable where I live, by the way, so all that shenanigans is added too. It's not just about the report itself. You can't get rid of products not valuable enough to keep around without adapting your whole business model. Even if you are _not_ looking for an exemption, you will have to accommodate.

No one bothered to make any of the other options easier, only the previously simplest option was barred behind trying everything else. This is what over-bureaucratization looks like.

To use a different example: No one wants to switch to public transport (which is already crowded anyway)? No problem, just ban driving unless you can prove that it's orders of magnitude faster and it's not feasible to move your residence. No further preparation is done; no thought goes beyond the horizon. "Eat this rule and deal with it, you don't have to deal with the paperwork if you're willing to spend 2 hours more on commuting". That's the line of thought here. There are no plans to make it actually viable to use the train, the other options are just barred behind this veil of plausible optionality. You can do it, of course. The issue arises from doing this with literally anything you tackle.

You essentially only add rules and special cases without ever consolidating them or even considering possible impact on adjacent topics. Everything grinds to a halt by doing this and nothing ever gets simplified. It is a huge issue on a landscape that favored small businesses (that can't afford divisions dealing with this) when the way the law is written suddenly requires structures only big companies or consultancies can provide. It entombs the market structure and drowns any competition in regulatory capture. We haven't even seen what happens once the markets are dominated by oligopolies and monopolies. By that time the only way to deal with the fall out will be even more rules, as the competitive landscape will already be dead.

I'm not against the goal of this regulation, but the recent way the rules have been made favor a market structure I consider incompatible with the goals of the EU.

funny enough,

  2>&1 >/dev/null cat file

Don't phones have identifiers outside of phone number anyway? I feel like you have to trust the hardware/os vendor anyway. So if you don't trust apple to not misbehave, maybe not getting an iphone is better than chasing the whole phone-number idea.

I feel like your example is flawed, I just can't put my finger on it.

Maybe it's because I don't see how sleep regularity is a factor you can change as willingly as visits to the fridge, or maybe its because I don't see why people wouldn't just eat more before heading to bed.

It could also just be that I find a treatment of symptoms to be less desirable than causes.

Sigh, I don't know why a blog-post against micro benchmarks should alter my opinion on this topic. There are more metrics than just "speed" regarding an interface. You also want it to be discoverable and visually distinct.

How someone interacts with your software is absolutely measurable and the results will vary by how a user is likely to use it in frequency and variety of function. Someone that needs to do something specific with your software every day will interact with it quite differently than someone that just hops onto it every now and then to do a different task each time.

All of this requires actual studies and observation of users over time. Micro benchmarks have no space there. Testing how fast a find and replace is is meaningless. In case of software for writing text you'd test a user actually writing prose, changing font sizes, title colors, and maybe replace a word over the file too. You would have commonly used functions mixed in with less commonly used functions over how the software is used under a specific use case. (For example, writing text, revising text, and polishing a graph representation are different use cases)

This is not easy, which probably why it's not done all too often, but it is also most definitely unlike a micro benchmark (which your link argues against).

All that being said, I don't know of any person strictly pitting mouse against keyboard when testing UI for possible improvements.

Most knowledge about human computer interfaces was obtained through metrics. Groupings, menu bars, corner buttons, context menu orderings, and other things didn't just spawn into existence. There was a time where human pattern recognition and physiology was an active consideration for user interfaces. One of the reasons mouse input became popular is precisely because interfaces were created to be easy to use with it.

All of this brings me to my questions: Why do you reject measuring how good an interface is? Or given your dismay over keyboard based workflows, why do you think they would win most of the time?

I'd wager that if actually tested, in only a few scenarios the keyboard would win, while hybrids (with both mouse and keyboard input) perform best for most people.

The existence and growth of the codeberg project does, however.

You're right it doesn't. At least not completely. I was thinking about precision (i.e.: if the test is positive, what are the odds that its prediction is true). It turns out, that accuracy is not defined as "true positive / (true pos. + true neg.)", but "correct predictions / all predictions". The whole point of OP's statement: "It's kind o remarkable how even a 99.9% accurate heuristic is insufficient at scale.", which you actually support with your example.

There is an important difference between scenarios where we care about the relative versus absolute frequency of errors.

The context is chat control without probable cause over the whole population of Europe with a low prevalence. My point, and presumably that of OP, is that even a small relative frequency of errors will yield an unsustainably high absolute frequncy of errors.

This is merely information provided to a human agent.

It will be in theory. In practice the human agent will just forward the decision. A human agent is not sufficient; you need to test only with probable cause for the kind of scenario we're talking about. The exact opposite of "Chat Control 1.0 and 2.0".

P.S.: The comment I originally replied to choose a very convoluted way of saying that the false discovery rate of the test matters for a proper evaluation. Both you and they explain this by throwing numbers without context in combination with slightly inaccurate definitions. I got the definitions mixed up differently, which led to this follow-up.

There are implications by linguistics. If you learn a language you also passively obtain insight into cultural norms and expectations. Moreover, Learning a language is much easier if you're friends with natives and converse with them on a semi-regular basis. Being able to speak the language also means that there doesn't need to be a separate support structure for you, as you will be able to use the ones provided to everyone else.

I'd wager the sum of these things is something one may expect from a permanent resident (i.e.: cultural knowledge, some amount of integration, ability to function without specialized support structures). And it turns out, that language proficiency is a pretty good proxy for measuring that. Just because you don't accept the rationale behind the requirement it does not mean that there is none.

The requirements are not there to verify that you can live somewhere permanently, but if you _may_ live there permanently. Money is not the only dimension your so called "net positive" may be measured in.

The mentioned accuracy in the comment you are replying to already encapsulates the relation of true positives to false positives.

There is no progress without possible failure in medicine. Each treatment starts with assumptions and you can only go so far until you start testing on actual people. Until we understand the mechanisms completely there is no way around that.

Genes are an important part of lifeforms. Of course, you may object to tinkering with them and wait until nature has done the tinkering for you. That will inevitably slow down progress by obtaining information so much slower that countless lives will be miserable due to missing cures and treatments. This is a zone where there is no clear moral answer. The only thing I would say with confidence is that gene editing is very likely the key to a plethora of treatments and preventative measures.

Will they need to live their whole life for us to confirm the cure worked? People already do that right now without gene editing. A friend of mine is 10 years over the life expectancy of their condition just because their parents decided to have them live their whole life "to confirm the treatment worked". 9 out of 10 people with that condition died by the age of 12 if not within the first year of birth. I'd wager being part of a medical/scientific program to monitor your condition is the least of your concerns at that point.

What exactly do you mean by "solved NP-hardness"?

I wonder if it will feel significant. I can't remember being limited by the controller battery. The runtime on a single charge is probably still going to be measured in weeks, and at that scale I feel like it doesn't really matter.

Douglas afaik. Boeing moved HQ and quite a few engineering practices were abandoned.

I wonder by which metric you measure these scripts. Clearly it can't be on pronounciation or information density. If "amount of letters" is your pick, then Latin might be "objectively" the best system - you'd just be using a very bad metric.

If you're going to unify all the worlds language into one script, then you'd better pick a good measure for that. If everyone on the world learns it, then it doesn't matter if there are 50 or even 100 different characters.You will have to capture _all_ of the nuances of the languages without blowing them out of proportion in size. Good luck with that.

You may not be able to mix encodings, but mixing languages has always been possible. If you used a French encoding you would be able to write in English, but not the other way around. I'd wager there are similar cases for cyrillic text. What Unicode gave us is its universality (heh). You don't have to carefully select an encoding able to represent the languages you wish to use anymore.

Many users of CJK language would argue that CJK unification was a mistake.

Luckily it's not a decision without turning back. In most relevant contexts you should know the input language and can select a Font specifically using said variations. Of course this information will not be present in plain text, but if it turns out to become an issue I'd wager, since language codes do exist, that a control code-point for language selection can be added to the specification. There's already so many special cases in Unicode that it shouldn't be a huge issue (apart from backwards-incompatibility that would lead to tofu instead of no rendered glyph).

afaik this is a non-issue with modern text rendering engines. Modern font files include rulesets to determine the forms and shaping engines apply these rules to eventually reach the desired "shape" (i.e. order, position and which glyphs to render). For example, if you use HarfBuzz it should be able to calculate the Glyphs and offsets you need for a properly set script.

I personally spent way to much time trying to understand it, but at least according to this video (https://www.youtube.com/watch?v=VaA0v0V4RsU) it really is not that difficult if you leave out all the font-selection and emoji shenanigans.

I think at least FreeType (glyph rendering) and HarfBuzz (text shaping) make it needlessly complex through their documentation. It is extensive in describing what the parts do, but the only way to figure out what you need is by fiddling around. As soon as you want to do more complex stuff you're on your own. Especially figuring out which parts you don't need is annoying.

The lovecraftian horror of pdf mostly comes into play through the sheer amount of software that supply almost correct pdf. It's not enough to be able to read pdf anymore, you also have to be able to deal with software that emits subtly wrong documents.

I'd like to add that there is almost no way of "running away" from it. If I search for anything on the internet I am almost guaranteed to be handed pages and pages of AI generated content. In lieu of that I found that directly prompting for an answer tends to yield better results nowadays. Not because it's good per-se, but because having control over the prompt beats having little to no control over it though search by proxy.

It saddens me to see that high quality content is drowned in this sea of garbage to the point of being almost impossible to find.

I personally stumble upon many topics where I only care about the what. In that case all the theory is just a distraction I'm just wading through to get to the point. If it's optional, then looking into the how and why is certainly nice, but it should be part of an appendix or a commentary and not interspersed within the proof unless an uncommented version exists.

I feel like keeping the amount of molecules the same within the simulation needs to be justified. How would it look like if the average amount of molecule was the same across a um?

Isn't this just an issue with rsync? (or rather your ancient version of it) I think you'd run into the same issues when using an IPv4 address port combination. It was rsync's choice to use colon as an indicator in lieu of IPv6's existence. You'd be complaining all the same for other separator choices if rsync just happened to pick the same one.

Nonetheless I do agree that the choice of colons isn't great due to how it ambiguates their meaning.

Two fields should be fine, actually. The way caches are organized you are very unlikely to thrash with the lookups (due to n-way associativity) while only keeping relevant data in the cache at the same time. You still have roughly the following layout (in the cache), where A is the field and V is valid:

  | A1 A2 A3 A4 | A5 A6 A7 A8 | ...
  | V1 V2 V3 V4 | V5 V6 V7 V8 | ...

  | A1 V1 B1 C1 | ... | A2 V2 B2 C2  | ...

This is on par to linear search being faster than binary search for small n. As soon as caches and branch prediction chime in many rules of thumb just change. Most importantly, however, is that a distinction between small and large n basically _needs_ to happen at that point.

According to the thread rsync broke for incremental backups and increases the cpu load heavily. The whole thread only started because people noticed regressions and were wondering what happened.

Since I quite a few users are using distros that won't update for a while it gets even better: this trend may continue and as soon as the update actually happens we'll be so far down the road that it will be too late to take a step back and reconsider due to the delayed feedback. This is pretty much about the few people _already_ having issues with it.

That being said, if the creator wants to use AI to work on the project they are free to do so. I just hope nothing of value is lost because of it.

P.S.: If you stop writing by hand and start delegating - to AI or other people - something has changed. There shouldn't be any discussion about it. Delegation is different than writing it yourself.

If we're talking two's complement it's not undefined that is right. Having to emit checks though, that is where I beg to differ. A check is only useful if you want to actually change the behavior when it happens, otherwise it is useless. Furthermore, it might be "essentially free" from a branch prediction point, but low and behold caches exist. You would pollute both the instruction cache with those instructions _and_ the branch prediction cache. From this it doesn't follow at all, that there is no cost.

In the end small things do add up, and if you're adding many little things "because it doesn't cost much nowadays" you will end up with slow software and not have one specific bottleneck to look at. I do agree that having the option for checked operations is nice (see C#), but I have needed this behavior (branching on overflow) exactly once so far.

Somehow I highly doubt that a small game company is going to run a "huge network of interconnected cloud services". I've also yet to find a small game company running their own big online multiplayer game.