Always had the impression that same could be said about solving math problems at school/uni. Some planning, knowing the right algo or tools, some creative thinking, many ways to get the desired output. Linear algebra was particularly fun when approached this way.
It's not like you couldn't transport troops on a passenger train, so I'd say may they never see the light of day again ¯\_(ツ)_/¯. In reality though, I doubt this will result in any serious repercussions for whoever called the shots.
This is exactly what you wrote, a vision. The first major obstacle is our urge to lower the effort one needs to get through the day doing all the chores, groceries, work etc. If you tell someone that now they need to move their lazy ass, and ride a bike for a some for kilometers, a couple of times a week and then some more for the so called „greater good”, I’d expect a lot of push back.
I don't think anyone is expecting you to donate to literally every project you use. However, say your business is to build and sell a product done in JS. You already have a bunch of JS devs, whom you may have even bought those sweet MacBooks. Let's also say, you're invested in keeping the code quality high, which you boast about in your product web page. Why not donate a $100/month to the JSLint project which is part of your toolchain anyway and helps you achieve your goals? The annual cost is probably less then you'd spend on the toilet paper for the office. You get a maintained product, they get some money to support their efforts. It's clearly a win win.
That's a fine pitch for the merit of donating to ESLint, but if that pitch isn't working for the developer then he should either make peace with doing the work for free, or stop doing the work.
Yes, completely. If there's no business contract in place, it's hard to expect compensation of any sort. It's all hinged on the other party's willingness to recognize the value in keeping the project alive. Very few do.
For starters, assuming the Linux variant, build a statically compiled application, pack it into an initramfs as the only file there, for simplicity name it `/init`, bundle the initramfs with the kernel, boot. At this point, your app should be the PID 1 and the only process running (with the exception of a bunch of kernel threads). At this point you can do whatever you want.
There are projects that permit statically linking a traditional kernel with a traditional application into a unikernel. NetBSD pioneered this with their rump kernel build framework, and I believe there's at least one Linux build framework that mimics this. The build frameworks cut out the syscall layer; an application calling read(2) is basically calling the kernel's read syscall implementation directly. Often you don't need to change any application source code. The build frameworks handle configuring and building the kernel image, and statically linking the kernel image with your application binary to produce the unikernel image.
I probably should have mentioned I've built unikernels with some of the tooling you've described here. It just seems very academic and edge case compared to a single static user space Linux binary that while technically isn't a by the book unikernel, all I guess I meant was that it's diminishing returns beyond that.
> This is the same technique used in Go and many others for preemption. If you don't add this, futures that don't yield can run forever, stalling the system.
The first one is indeed non-obvious, but the remaining snippets presented as bugs would not pass a review unless hidden inside 1k+ LOC PRs. Some are so blatantly obvious (seriously for loop and not passing current value as variable?) that I'm surprised that authors have listed them as if they're somehow special.
> for loop and not passing current value as variable
In most languages, current for loop value is always accessed a variable, not a reference. The only languages where it's not the case that I know of are Go and Python (JavaScript used to also have this problem with for(var ...), it was fixed with for(let ...)). So if you don't regularly write Go, it's easy to make this mistake.
I stopped reading the articles, but the last one I can recall was Barcelona I think. Just some random search engine hits since I don't exactly bookmark the articles:
> It's not really about motivation. Difficulty of terminating employment can make employees a real liability when you're small if they turn out to be a bad fit.
Given significantly smaller salaries and the typical 3-6 months probationary period before going full time, I don't think this is much of a risk. If someone turns out to be a 'bad' fit 6 months in, the employee isn't the only thing in need of looking into.
