Rust isn’t necessary. It can be mildly helpful, but it’s also hurt in that it’s community tends to make it actively unhelpful, just like in this case.

Linux development happened just fine for decades before rust, and while there are benefits to rust from a security point of view, if they can’t maintain the code, they’ll just go back to C and deal with process and policy for managing memory safety.

I mean, that’s kind of my point though. You either get worse than useless, over detailed to the point of useless, or you have to spend weeks pulling hacky crap with tags to try to jury-rig your own useful billing system out of their clusterfuck.

Amazon’s billing tool is the most useless thing I’ve ever seen lol. it’s like “$XYZ of your bill was server compute!” like, there’s 40 ec2s, elastic beanstalk instances, fargate, kubernetes, like what the fuck is ‘server compute’ and what’s the breakdown of the actual individual parts?

It’s not even unhelpful, it’s literally worse than useless lmao

The other thing they forgot to mention is that getting Amazon to actually tell you what anything will cost, or a breakdown of what your bill is, is like pulling teeth.

Yes, absolutely. Constantly, in fact.

Rust the language is great.

Rust the community makes me hate rust, never want anything to do with it, and actively advise people not to use Rust. Your community is so, so important to a programming language, because that’s who makes your documentation, your libraries, fills out the discords, IRC, and mailing lists. As a developer, any time you’re doing anything but rote boilerplate zombie work, you’re interacting with the community. And Rust has a small, but extremely vocal, section of their community that are just absolute shitheads.

Maybe in 5-10 years when the techbros stop riding its’ dick and go do something else will Rust recover its reputation, but for now? Absolutely no.

np

gdb gives you waaaaaaaaaaaaaaay more than a stack trace.

https://wiki.ubuntu.com/Apport

It intentionally acts as an intercept for such things, so that core dumps can be nicely packaged up and sent to maintainers in a GUI-friendly way so maintainers can get valuable debugging information even from non-tech-savvy users. If you’re running something on the terminal, it won’t be intercepted and the core dump will be put in the working directory of the binary, but if you executed it through the GUI it will.

Assuming, of course, you turn crash interception on- it’s off by default since it might contain sensitive info. Apport itself is always on and running to handle Ubuntu errors, but the crash interception needs enabled.

Imagine if you knew the most basic foundational features of the language you were using.

Next we’ll teach you about this neat thing called the compiler.

Correct, I agree you run it with an eye on it (which you should probably do anyway) instead of firing and forgetting (which, to nginx’s credit, is typically stable enough you can do that just fine).

That said, nginx treats experimental as something you explicitly run in production- when they announced they added it into experimental they actually specifically say to run it in prod in an A/B setup.

https://www.nginx.com/blog/our-roadmap-quic-http-3-support-nginx/

Really dude? I never once devolved to name calling, I stated that s/he lied when s/he made false statements. What else am I supposed to say there?

I also don’t understand how saying they doesn’t know what the subject matter s/he’s taking a stance on is ‘know-knowing’ either? S/He’s straight up said they doesn’t know what a CVE is, doesn’t know what experimental means, and while they claims to be in this field of work, they doesn’t know what a web worker is and confused a web transaction with a database transaction.

Sure, I could have been nicer about it when they started escalating, but I never made it personal, and have no intentions of doing so either.

EDIT: realized I was assuming their gender.

1. I’m glad we agree a DoS is a vulnerability.
2. CVE best practices state that CVEs are required to be assigned to experimental features. F5’s company policy is that CVE best practices are followed. F5 is the company that owns nginx. Therefore, it was required. Nice ‘legal requirement’ strawman. Also, ‘Common’ in this situation is not defined as ‘Widespread; prevalent,’ it’s defined as ‘Of or relating to the community as a whole; public.’
3. That was a typo regarding ‘stable,’ my bad. I meant to say ‘It is just not available on stable, but is both via commercially and via the open source version.’ However, it’s still available on commercial versions and open source, and ‘non-stable’ versions are not inherently unstable, they’re just called ‘mainline’. Proof: https://nginx.org/en/download.html Stable is basically just ‘long term support/LTS’ versions of nginx.
4. Again, you are intentionally misusing the definitions of the word common. Lets see what MITRE has to say about it, hmm?

Common Vulnerabilities and Exposures (CVE) is a dictionary of common names (i.e., CVE Identifiers) for publicly known information security vulnerabilities. CVE’s common identifiers make it easier to share data across separate network security databases and tools, and provide a baseline for evaluating the coverage of an organization’s security tools. If a report from one of your security tools incorporates CVE Identifiers, you may then quickly and accurately access fix information in one or more separate CVE-compatible databases to remediate the problem.

Source: https://cve.mitre.org/about/

5. Yes, I would consider notifying the development mailing list as ‘quietly’ fixing it, as most all companies using it will not be on the development mailing list. It’s meant to be an area for developers to discuss things. They didn’t inform the public, they informed the devs.
6. Where are you getting database from? You’ve randomly pivoted into talking about database transactions then started babbling about how you somehow think using a production mainline release with production options on a fully supported commercial binary is somehow inherently unsafe, as though it wouldn’t still be in dev or test.

Since you seem to have no idea about how web servers work, or indeed, experimental features, I’ll let you in on a secret- The only difference between a non-experiemntal option in nginx and an experimental option is that they’re unsure if they want that feature in nginx, and are seeing how many people are actually using it/interested in, or they think that usage patterns of the feature might indicate another, better method of implementation. “Experimental” does not mean “unfinished” or “untested.”

If you know nothing about programming, CVEs, or even web engines, please stop embarrassing yourself by trying to trumpet ill-thought out bad takes on subjects you don’t understand.

There is an astounding number of lies in your post, good lord.

1. It is an issue. A DoS is a fairly serious vulnerability, and very much is a vulnerability.
2. Experimental features are explicitly defined to require their vulnerabilities to be assigned CVEs.
3. It is not just available on the stable version, but both commercially and via the open source version.
4. CVEs are not just for serious issues, they are for vulnerabilities. All vulnerabilities. It is a number that allows you to reference an vulnerability, nothing more, nothing less.
5. Mentioning a CVE on the mailing list is the absolute least they should be doing.
6. ‘workers can just be restarted anyway’ shows a deep misunderstanding of what a worker does. Any pending or active transactions that worker had now hangs, meaning that the service is still being denied. Trying to recover automatically from a DoS does not mean the DoS is not happening- it just means that the DoS is slower to get rolling, or intermittently seems to work mid-DoS.

Experimental features are explicitly defined as requiring CVEs. You are supposed to run them in production, that’s why they’re available as expiermental features and not on a development branch somewhere. You’re just supposed to run them carefully, and examine what they’re doing, so they can move out of experiment into mainline.

And that requires knowledge about any vulnerabilities, hence why it’s required to assigned CVEs to experimental features.

And I’m not sure why you think a DoS isn’t a vulnerability, that’s literally one of the most classic CVEs there are. A DoS is much, much more severe than a DDoS.

Nah, c suite was pretty clearly in the right here. Dude left because he was pissed that a vulnerability got assigned a CVE instead of just… Not informing anyone so they could quietly fix it.

You’re not missing anything, dude just threw a hissy fit because he’s not the king of his fiefdom anymore.

If you’re willing to deal with terminal, you don’t need a gpu at all. You can merely connect over serial (which could be a DB8 connector, or an ethernet connector, or whatever), and a directly plugged in screen/keyboard (which is usually also supported, though maybe not over HDMI or anything) will also work.

And to be honest, if you want to play with servers, you should get used to terminal- it will do you a lot of good in general.

on the contrary, CLI is the BEST way to deal with firewall rules.