fork() can fail: this is important

Ah, fork(). The way processes make more processes. Well, one of them, anyway. It seems I have another story to tell about it.

It can fail. Got that? Are you taking this seriously? You should. fork can fail. Just like malloc, it can fail. Neither of them fail often, but when they do, you can't just ignore it. You have to do something intelligent about it.

People seem to know that fork will return 0 if you're the child and some positive number if you're the parent -- that number is the child's pid. They sock this number away and then use it later.

Guess what happens when you don't test for failure? Yep, that's right, you probably treat "-1" (fork's error result) as a pid.

That's the beginning of the pain. The true pain comes later when it's time to send a signal. Maybe you want to shut down a child process.

Do you kill(pid, signal)? Maybe you do kill(pid, 9).

Do you know what happens when pid is -1? You really should. It's Important. Yes, with a capital I.

...

...

...

Here, I'll paste from the kill(2) man page on my Linux box.

If pid equals -1, then sig is sent to every process for which the calling process has permission to send signals, except for process 1 (init), ...

See that? Killing "pid -1" is equivalent to massacring every other process you are permitted to signal. If you're root, that's probably everything. You live and init lives, but that's it. Everything else is gone gone gone.

Do you have code which manages processes? Have you ever found a machine totally dead except for the text console getty/login (which are respawned by init, naturally) and the process manager? Did you blame the oomkiller in the kernel?

It might not be the guilty party here. Go see if you killed -1.

Unix: just enough potholes and bear traps to keep an entire valley going.

Source: https://rachelbythebay.com/w/2014/...

Normal human: Visits web store -> orders for product -> leaves store.

Me: Visits web store -> Stares at header -> Stares at logo -> Check if colors match -> Scroll to footer -> Frowns at ads -> Scroll back up -> Multi click product item for debounce -> Fuck i clicked twice but it added the product thrice -> Closes tab -> Drives to local store -> Purchase product -> leaves store.

That's a unique skill

I coded the app so good
I optimized the UX SO GOOD
I made the UI look GOOD
I made the error handling and input validation ROCK HARD SOLID BULLETPROOF

NO FUCKING WAY COULD YOU FUCK THIS UP

NO WAY COULD YOU BE DUMB ENOUGH NOT TO KNOW HOW TO USE IT AND NOT FUCK IT UP

I GAVE IT TO MY DAD AS A NORMAL USER TO TEST THE APP AND HE FUCKED IT UP ON THE FIRST TRY

HE DIDNT UNDERSTAND THE UX.

.

~rant
I think we need to change way how websites deliver themselves to its users. This HTML CSS JS clusterfuck is just a huge PITA in the ass.

What is a website?
It's an application where users find, communicate or share information, can buy or sell their penis pumps and loads of shady stuff.
Why must a website (the delivered application) be split into multiple languages/scripts and lots of HTTP requests?
In my opinion, PWA is a start to make us look at websites more like apps as we are used to on the machine, but they don't solve the mess.
Per my experience, many people working on websites regularly confuse what's executed on the server and what is on the client. They send data to the client via XHR, for example full DB tables of private data, just to then filter it in their beloved Array.filter function.
You can tell those people again and again and this is why I start thinking that the Web, as we know it, needs a big change.

I just gave a 20 minute presentation in front of fifty people, and apparently did well enough that I got five private compliments afterwards, including one from the vice president. 🥳

And all of that without a single drop of rum!

anyone knows someone like this...?

Yo mama so fat she can't store files larger than 4 gigabytes.

01010010 01100101 01100001 01100100 01101001 01101110 01100111 00100000 01100010 01101001 01101110 01100001 01110010 01111001 00100000 01101001 01110011 00100000 01101101 01101111 01110010 01100101 00100000 01110100 01101000 01100001 01101110 00100000 01100001 00100000 01110011 01101011 01101001 01101100 01101100 00101100 00100000 01101001 01110100 00100111 01110011 00100000 01100001 00100000 01101100 01101001 01100110 01100101 00100000 01100001 01101100 01110100 01100101 01110010 01101001 01101110 01100111 00100000 01100001 01100010 01101001 01101100 01101001 01110100 01111001 00101110 00001101 00001010 01000011 01101000 01100001 01101110 01100111 01100101 00100000 01101101 01111001 00100000 01101101 01101001 01101110 01100100

I just want to throw out there for Javascript developers, async and await are the two best things to ever happen to promises.

Once we were going to present a web service to governmental firm. All is going well so far and my boss asks me to host the web application the day before the presentation.

I hosted it and all was good with demo production tests, but I had a bad feeling.

While it was running on our server, I also ran it locally with a reverse proxy just in case.

* Meeting starts *

* Ice broken and down to business *

"And now our developer will run the demo for you..."

* Run the demo from my laptop to double check --> 500 Internal Server Error *

Holy shit!!!

* Opens reverse proxy link on my laptop. Present demo during meeting. Demo works like a charm. *

Firm representative: "Great! Looking forward to go live."

*Our team walks out*

GM: "Good job guys"

ME: