HN user
It will. No program is perfect.
Rust and Go advocates will have you think that they have conquered security via the memory mgmt and API front but there is still the off chance they haven't..or that the SA (what is left of that maligned profession outside playbooks and the devops marketing you read here and online) has allowed you a chance for glory.
There are basically two rules to a well written C program (if I am now allowed to speak despite the public outcry).
1. Do not trust user input. This is a cardinal rule in whatever source. If the rule were followed vigorously in every case there would be 90% less exposure. When you take user input, filter. 2. Learn the standard and stick to it.
Finally #3 (unix) Write an application to do a certain thing well.
Better C++ than Go or Rust. Antecedents and track record counts. Young people like the new thing. Go and Rust are capitalizing on that. Learn C. Take the time..it takes a couple years and some pain to learn it and then you will be amply rewarded. These languages (go|rust) are reactive and suffice for some purposes but they really kind of suck in every other possible way.
What a clumsy, terrible, crappy workaround. Congrats.
*...it's a total mess...theoretically it's possible....speculation on standard behavior based on platform behavior...namespace(x)<-threads->chosen implementation detail...functional language reference... -- Translation: Design is broken
I read this crap in language design and despair. This is why C is my only recourse for systems programming in *nix environments.
How incredibly naive.
It's not that nobody is interested anymore. It is that the onus is on regular citizens to protect themselves. Once you have an understanding of the magnitude of the privacy problem and see what you would have to do to protect yourself you tend to tip your hat to the empowered opposition and industry partners and realize,in the venerable argot of our time: you lost the game.
War. These are the men who are missing out on the great civilized purge of useless, direction-less, education-less, baby dads. Not practicable anymore. There is no great enemy, the military services don't want these problem children.
Our direction is unsustainable but nobody likes this particular historical necessity.
This looks like a clusterf*ck.
External monitoring from AWS or a colo. Simple icmp checks and tcp connects + possible up to app layer checks allowed from these failsafes. Obfuscate as needed.
Don't know that they have more but most colos I've used are using akamai.
By the time you outgrow TCL you are a really good programmer. You choose and advocate appropriately.
Medication is a problem unless you are sick. We all need confirmation and less pressure...are we sick because of that?
TBH I did once and they were angry and rude.
Cats are cool. They love you and hang out regardless. I've followed this pattern recently and realized that there is a balance that can be met in the middle. Do the easy stuff all and any of the time and do the hard stuff as little as possible. That way you can make the $$ and stay sane.
The trick there is to at least do the hard stuff some of the time so you stay up to date and ready for the next thing.
Oh, yes. Strikes a chord. Work till you drop and not make any friends = disaster.
Lol. Genius. We see the converts and owners here take exception.
Not following on this. Something about value and unions and continuous delivery and process/products and other poop. Seems like someone wanted to whittle the overt jargon into incomprehensibility.
There is no 'self-healing' system. Nothing can detect a 'real' failure as opposed to a counterfeit failure without heuristics that depend on an interpretation that is inherently fallible.
Ops was about discipline and method. Restrict the problem set to known values. The one thing that I see these days is that developers don't have a fucking clue about ops but they do see that the basic task responsibility is toilsome, counter-creative and that 90% of it can be automated by reliance on coded procedures in write once argot that hopefully is editable and doesn't give up the family jewels when posted in pub github.
How about the default sort? Ouch or no ouch?
What is an app I wonder? Is it sort of a codeword for frontend embedded in logic impossible for the user to decipher with invisible sys hooks everywhere because the os is opaque to the user or is it something else?
You know, architecturally, at application level no one wants to deal with this but devs orchestrate nightmarish dependencies for deploys and hit 'endpoints' with aplomb in service architectures with only a playbook or data blueprint to follow. What's the point of fighting this?
Let the kids play.
Perfect storm.
Last time I checked lock free meant no locks.
I've met a couple who are purposefully overbearing and intolerant.
It's time and space. Northern Virginia in 1978 and now. That's a mindf*ck.
That is sort of the Vingean 'mystery' take. If you enjoy his writing style and SF 'Marooned in Real Time' is worth a read.
Not a singularity but any cyber augmented memory interface would lend the appearance of genius until the inputs/outputs are all wrong. Then you have artificial alzheimers and dementia.
1. The only reason to use C these days _is_ performance and portability. Write the code to your level of expertise or use a different language to cater to the 'du jour' audience.
2. This was advice straight of Der lindens Deep C secrets back in the mid 90s. It wasn't always true then and it isn't always true now. I often use macros and don't find them a problem to understand in others code.
3. Give me a break. Except when you don't need to allocate and manage memory which is almost every time you write a tool that does one thing well. This is not a good general principle.
4. This is the way it works for me. Do it. Nope.
5. Ok, some of this is common sense writing portable code. 'GNU is a blight on this earth': "..now we see the violence inherent in the system.."
6. Yes, finally a good point but not about C per-se. 7. Ok, but this is not about C per-se. 8. Hrrmmm. A culture of blame is what produces restrictive rules like these.
This article is fodder for the Rust and other anti-c devotees here to glom onto and point out all the problems with the author and his language as the ultimate straw man. To me it sounds like this person wasn't writing C in the 90s.