ablob

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 | ...

The former access pattern still yields a clean cache layout where no unnecessary data is loaded (which is the most costly operation here by far) as opposed to

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

In the general case there will exist a number of fields for which SOA layout will be worse if all are accessed close to each other, but for just a validity indicator this should not be the case. I think your statement is not wrong, but also not 100% correct.

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.

http3 operates on a different OSI layer

I just feel like "you can do this with Kubernetes" is a slippery slope. "You can do X with Y, so use Y" is a great way to add a dependency, especially if it is "community vetted" already. Sometimes simple is better - you don't need to add anything that implements some of you logic as a dependency to stay DRY or whatever you want to call it.

It really feels like we are drowning in self-imposed tech debt and keep adding layers to try and hold it for just a while longer. Now that being said, there is no reason not to add Kubernetes once a sufficient overlap is achieved.

afaik, you always have to break open abstractions for more performance. If you ignore cache-levels in your program you're gonna have a bad time - and depending on the system the layout (and with it how you should use it) is different. The same is true for how machines are interconnected. Depending on the wiring you have different throughput-values when sharing data between nodes. The whole area screams "not universal" to me.

So what would be such an HPC language that you're so fond of? A quick web search reveals only languages that use C++/CUDA code as a back end (python), are new and experimental (Julia) or FORTRAN. For what you're talking about none seem all to good, so you've peaked my curiosity.

C++ by comparison doesn't stand in your way too much either. I feel like the biggest gripe Rust has is what happens when you do have to go unsafe. That seems to be a strong point of contention for many folks. Maybe all the reasons that lead people to use unsafe rust go away or the attitude about it shifts in some manner.

For me Rust turned out to be less interesting after I saw the whole ceremony about typing. The amount of things I had to grasp just to get a glimpse into what a library does felt much more involved than any of the things I did with C++. The whole annotation-ting feels much less necessary and more like a proper opt-in there.

Anything that increases the entry time by a second or more is a pretty good way to make me (and probably others) just not bother with opening the website.

I think his point is that "form follows function". If you know what kind of semantics you're going to have, you can use that to construct a syntax that lends itself to using it properly.

I guess "back in the day" you had to be able to write an efficient parser, as no parser generators existed. If you couldn't implement whatever you wanted due to memory shortage at the parser level, then obviously it's gonna be a huge topic. Even now I believe it is good to know about this - if only to avoid pitfalls in your own grammar.

I repeatedly skip parts that are not important to me when reading books like this. I grabbed a book about embedded design and skipped about half of it, which was bus protocols, as I knew I wouldn't need it. There is no need to read the dragon book from front to back.

  > But there's a reason most modern resources skip over all of that and just make the reader write a recursive descent parser.

Unless the reason is explicitly stated there is no way to verify it's any good. There's a reason people use AI to write do their homework - it just doesn't mean it's a good one. I can think of plenty arguments for why you wouldn't look into the pros and cons of different parsing strategies in an introduction to compilers, "everyone is(or isn't) doing it" does not belong to them. In the end, it has to be written down somewhere, and if no other book is doing it for whatever reason, then the dragon book it shall be. You can always recommend skipping that part if someone asks about what book to use.

So you trade the overhead of SQL with the overhead of JSON?

The question was not if it was possible within price boundary X, but if it was possible at all. There is a difference, please don't confound possibility with feasibility.

C# has had the reputation of not being viable for Linux for a long time. Therefore, the people already on Linux didn't have a reason to use it or even try it. If you're already doing stuff in other languages it's hardly worth it to switch to C#.

I personally use it quite a lot - but I came as a windows user writing all my utilities in C#. Also, afaik C# is mostly used in corporate environments that don't open-source their projects. You're unlikely to hear from it unless you're working on it for this very reason.

A game is finished at some point. You might not need to evolve the code any further. Why optimize for a use-case that rarely applies to indie-games?

If you're using all services, then any partial outage is essentially a full outage. Of course, you can massage the numbers to make it look nicer in the way you described but the conservative approach is better for the customers. If you insist, one could create this metric for selected services only to "better reflect users".

That being said, even when looking at the split uptimes, you'd have to do a very skewed weighting to achieve a number with more than one 9.

I think multi-cursors can be seen as an extension of macros, just that instead of defining the macro and navigating to the relevant places you instead navigate first and then execute the commands interactively (in essence skipping the part where you have to record). As a side effect you also don't need to be that concerned about what to do after having made a mistake. I've had some pretty nasty string-wrangling with the substitute command that could've been avoided by just using a macro and the other way around. I'd argue these things complement each other and there is no need to restrict yourself arbitrarily. Having it and not using it is better than needing and not having. I can recall countless times where multi-cursor would've been just the sweet-spot I needed.

P.S.: multi-cursor is not about moving around the code base and therefore not taking lessons about navigation has no impact in this matter.