The LD_PRELOAD workaround is meant to "fix" the shellshock bug, sysdig doesn't do that, it just passively monitors every injection attempt up to the point where the injected function is actually read by a newly spawn bash.
With the LD_PRELOAD trick you can definitely secure your system, but you won't be able to see if there's a new service that is being used as an attack vector (for your own curiosity). With sysdig, you can, and if you capture a trace file you can also follow the exact process chain that caused the propagation of the environment variable.
That can get tricky as a general case, but would probably work OK for most people in this specific case. But, then again, hopefully you've patched bash already anyway, so blocking hosts that are scanning for a vulnerability that you've already fixed probably won't accomplish much.
Generally speaking, if you use something like iptables to block abusive hosts, you dive head-first into a very deep rabbit hole. Usually sysadmins don't want hosts blocked forever or iptables with 30k+ lines in them, so now you have to also add some kind of automated ban-clearing feature. Then you want to make sure you don't ban certain networks, so now you have to have some kind of whitelist feature. Then sysadmins will want to be able to tune which networks are trusted and which aren't, so now you have to add some configuration options for it. And so on.
I've written some software for my servers that does this for several different annoyances, and I spend almost as much time tuning the software as I spent dealing with the annoyances in the first place.
If sysadmins really want to auto-ban abusive hosts, you're probably better off letting them do it with something like Fail2Ban, and then all that muckety-muck becomes their problem, and not yours.
I wouldn't use a program B to circumvent a bug of another program A if not in a exceptional case in which patch of program A cannot be created.
This is exactly the case. If bash has a bug. that must be fixed. And it has been done already. Just update bash in major distributions and the bug is gone.
But still you want to have a tool like sysdig to detect if your system has already been compromised previously and it is out of sysadmin control.
Right now, browsers are the easiest platform where you can build an application that can be made available to a lot of different devices. And when it's a requirement, from a time-to-market point of view this is a huge benefit. And this should be taken seriously into account especially now that people tend to use 2 or 3 devices every single day.
On the other side, from application point of view both the browser and the operating system are containers that offer some sort of API to interact with the user, the device and other resources. I wouldn't say that one has to be necessarily better than the other, it depends on the goal of the application.
Depending on the kind of job, remote working is a perfect way to get the job done. If you feel this can be your case, then maybe your boss is not acting very smart.
In terms of job alternatives, if you feel that you would need to commute anyway, look around, I bet there are several open positions for which you would be able to work remotely (in some cases you might trade something like 1 day a week at the office).
At the end, give your boss another chance to understand your situation, go talk with him. It will be the ultimate way to know if that's the place you still want to work at or not.
A very interesting source of thoughts is the work done by Bret Victor http://worrydream.com/ (take a look at Recent Output section).
Code the way we know it today will change. After all, human languages keep changing.
However, changes will happen in a very natural way, with selection of the best compromise between efforts and results. For instance, programming languages might not change that much while we might end up with more and more powerful frameworks to build software.
Nevertheless, next 50 years of evolution will be very very interesting to follow.
Yeah Bret has some very interesting points. I don't think he's shipping stuff anymore, that's kinda sad...
I agree with your point about frameworks, Bubble is a framework in some ways. However, my point was that at some point, creating software will not be done via typing code, but more through a more pleasant input/user experience (independently of the framework, which will of course evolve).
Ok, that's a good and hopefully true point. Code and tools will both evolve, eventually you might not deal directly with code but with the abstraction offered by such tools.
Code itself won't likely disappear. It will be just buried behind more and more layers of abstractions.
