dafelst

But did you think about using a perfect hash function and table? Based on my prior research, it seems like they are almost universally faster on small strings than trees and tries due to lower cache miss rates.

Microsoft basically already has this (and has for the last ~20 years) as SmartScreen.

I have friends that work there, it is a great place to work, but not without it's problems.

What is EA in this context?

Or you know, just do what you want

To me the larger question is whether or not GPLv2 achieves the goal of forcing big companies to contribute back to a project better than a more permissable license does.

As stated in the article, Linux is the notable success story, but anecdotally it seems that the majority of projects with large company contributions are licensed with BSD/Apache/MIT but with contributor agreement attached.

I wonder if anyone has compiled any data on whether GPLv2 does actually encourage contributions more than the more permissive alternatives.

GPLv3 isn't even worth mentioning in this context, great concept, abject failure to thrive IMO.

You can be compelled to give up encryption passphrases, either through legal process or by force. If that data is irrecovably and provably erased, that is no longer an avenue for access.

There is an example in the article

It is entirely unclear to me what point you are trying to make. Is your mundane solution to just add more sanitization and analysis to C and C++? If so, that's great, more safety in any language is fantastic. My issue with that is that it is an optional addition to the language rather than the default behavior.

The point I am making is that safe Rust _by default_ straight up disallows compiling code that has the potential for the vast majority of memory safety issues. Code with those issues is just a plain invalid program, and will not compile. If you want to bypass those protections, you need to explicitly opt-in with the unsafe keyword.

C or C++ code with the same issues is perfectly valid, will compile and run, but it has the potential to be incorrect. You can (and should!) bolt on tools to fix that, but the issue is that the language allows that behavior by default. Until these tools are the defaults, the problem is only partially solved - you have to opt-in to a large chunk of safety features, and even if you do, you get fewer of them to boot.

I'm not saying you should use Rust by any means. If you like C++, continue using it. But the fact here is that Rust solves a bunch of problems here and now today that C and C++ cannot, so it is baffling to me that people have such a visceral negative reaction to it.

> Your blend of comments makes it sound like no one knew or cared about these issues other than Rust fanboys.

That is a strange takeaway from my post. Of course people care, but the difference is that one language and its toolchain was designed and built specifically to avoid these bugs and one wasn't.

I have been writing C++ professionally since around 2000-2001, and have been working with Rust for about 18 months. For single threaded code, the code I write in both is about equivalent in terms of robustness and stability, but for anything multithreaded, I trust my Rust code's correctness substantially more, even with all the checkers and sanitizers enabled on my C++ codebase.

Would I choose Rust for everything? Hell no, for evolutionary and fast moving code bases like in games, C++ is plenty good enough.

For anything systems related that requires parallelism and robustness, I will 100% stick with Rust.

In safe rust you cannot read uninitialized memory or variables, you cannot dereference a null or freed pointer, you can't concurrently mutate the same variable from multiple threads without locking primitives, you can't accidentally modify a variable after it has been moved out of scope - all of these things are enforced at compile time. If your code compiles, you are safe from all of these classes of bugs (outside the use of unsafe code).

In addition, you can't overflow a buffer nor unintentionally read outside the bounds of an array, that will cause a runtime panic and abort the program.

Doing this in C or C++ is possible, but the fact that even the best of the best programmers in these languages sometimes still make these mistakes shows the limitations of the paradigm.

Even the most novice Rust programmer who stays in the guardrails will produce programs free of these sorts of memory safety bugs. The same cannot be said about C or C++ programs.

Rust (without use of `unsafe`) eliminates several entire classes of bugs (including bugs that comprise the majority of security related memory safety issues) while providing performance comparable to C/C++.

That is really all there is to it - it is just the better option for systems programming by almost all available metrics, and I say this as someone who has been coding C and C++ professionally for coming up on 25 years.

Sure, but zstd soundly beats gzip on every single metric except ubiquity, it is just straight up a better compression/decompression strategy.

The problem here is that a good amount of perfectly serviceable items went into the trash instead of being donated. That is just straight up wasteful.

I agree with everything that you say here, but I think it is important to differentiate "good leaders" (which you have described) with "successful leaders" whose motives are often far more self-serving.

There are "good, successful leaders" but in my experience they are few and far between, and often the "successful" aspect is forced to plateau by the "good" part.

For what it's worth, I experienced the same sort of nightmares, though it typically wasn't a specific game or program, more like the computer being hacked/compromised/haunted.

Please do!

Are you serious? Linus has a long history of being abusive, it is no secret. He has gotten better for sure in recent years, but especially in the earlier days he would fairly regularly insult people, tell them to kill themselves because it would make the world a better place, and more.

I worked for Microsoft doing malware detection back 10+ years ago, and questionably sourced proxies were well and truly on the table

The borrow checker isn't just about UB, it is mostly about memory safety.

I'm sure you've seen plenty of use-after-frees/use-after-move/dangling pointer type things or null pointer derefs, or data races, etc etc. These are largely impossible to do in safe rust.

I agree, I feel like Pandora recommendations are far better than Spotify ones, at least for me. Spotify keeps me in my bubble, Pandora is constantly expanding it.

I'm still not following - you're talking about restrictions on use, but what restrictions on use does AGPL apply? What can I not do with AGPL software? What are the forbidden activities you reference?

The only caveat seems to be making the source code available to users of the software, which is also the case with GPLv2, just under narrower conditions.

I have no dog in this race, nor any particular attachment to any particular license, I'm just trying to better understand what these restrictions are that you're referencing.

Genuine question, how does AGPL restrict use? From my reading of it, it is only ensuring that any modifications to the source code must be made available if you "distribute" the software, where distribution now includes hosting it as a service.

It seems more or less in the original spirit of GPLv2 but updated for a SaaS driven world. If you consider v3 restrictive then you must also consider v2 restrictive, just in a more narrow way.

Don't forget Visual Sourcesafe, that came out around 1995 as well and was the standard source control package for most of the Windows shops in the 90s and even up to the mid 2000s (at least in my experience)

Crowdstrike also managed to take down a bunch of Debian boxes not too long ago - this is not a Windows problem, this is a problem with a vendor product auto deploying bad kernel modules.

I work in gaming, and crashes in oodle decompression during data validation and/or in GPU allocation (due to corruption on textures) on the 13 and 14 series K CPU variants are the top crashes in our crash trackers by a fairly large margin. Intel has really dropped the ball on their quality control here.

It seems like the issues can be mitigated in most cases at the BIOS level, but it's hard to get that memo out to everyone, even if they are comfortable making those adjustments.

I'm a fan of FreeBSD, but nothing really in this article really is super specific to switching to FreeBSD, aside from the customers lucking out that the crypto-miner that was injected into their system wasn't able to run on there.

This feels more like an "experienced dev/sysadmin shows inexperienced dev team how to better manage their environments" type article. That in itself is a good message and worthwhile, but the FreeBSD stuff is a bit besides the point.

Have you asked your boss why they're treating you this way? If not, that should be your first course of action.

I think what they're saying is that with some minor control over the data in your dataset, you don't need to care about escaping _in your parser_ at all. The same might be said of CSV but I would argue that in the majority of situations tabs are less semantically meaningful than commas and newlines, so it is generally fine just to strip them out.

Obviously this is not robust solution, but in cases I've seen, it works adequately. If one were to be doing it "the right way" then I agree with you wholeheartedly.

I feel this is fair payback for the number of times I have been violated by Kubernetes.