I tried repeatedly to just stick with Makefiles but I kept having to add workaround and hack to do basic stuff. They got uglier and uglier. I checked out go task and cargo make, but eventually gave in to `just`. It has worked just fine and the files are infinitely more readable than the comparable ones w/ make.
What kind of workarounds and hacks? Make's task interface is essentially "anything you can do at the command line", generally with the same syntax (though you have to put extra parens around your variable names).
It's true that more modern tools have features make doesn't (especially with regard to manipulating complicated dependency graphs) or attack parts of the problem that make doesn't (hermetic build environments, language-aware features like package management).
But... I can't see "lack of ability to do basic stuff" as one of its problems. What basic things are you trying to do?
I see `.PHONY` as a hack, `MAKEFLAGS += --no-builtin-rules` as a workaround, and many of the builtin functions as being difficult to use, read, and understand. A long string of nested replacements generating the sources for a task is a pain to read and maintain.
What I want out of task runners nowadays is to run tasks. If I can't make a task without writing '.PHONY' - there's a problem with the task runner.
Meh. OK. Though almost always, "run tasks" implies some level of state. Are you tasks truly all idempotent and parallelizable? If not, maybe they should produce output and be tracked by dependencies? If so, then you probably have bugs in your "task runners" that will show up in weird ways.
It's absolutely true that ".PHONY" looks like a hack; it was sort of meant to. In general you shouldn't be using it, except maybe as a facade layer where you can put an "API" (c.f. the "all" or "clean" targets) on top of things that are themselves proper dependencies.
I'm not going to hold up make as the ultimate expression of a dependency-based build system. But I will say that history has a LONG trail of products that tried to replace it with decidedly mixed results. Categorical statements like yours tend to trigger my "code smell" layer, most of the time attempts to replace make produce worse results.
> Though almost always, "run tasks" implies some level of state.
Yes! But isn't one of the major design principles of Make that the host filesystem is the container for the state? (iirc Make decides when to re-run rules based on when the timestamp on a target is older than the timestamp on an input file)
Sure, so where does that state get stored in a pure "task runner" tool? Attempts to muck with this metaphor ("state is what is left behind when the tool is not running") are among the worst mistakes made by build systems. It's a feature, not a bug, and everyone who believes otherwise ends up rediscovering it the hard way.
1) Proxies and botnets obscure origin and make attacks appear globally distributed so basic rate limiting has little effect on these attacks.
2) Extrapolated averages on incomplete data are certainly suspect, they are meant to be taken with a grain of salt and are most applicable to people in the affected industries for them to validate against their own data. FWIW The highest percentage of malicious, automated traffic that I've seen has been 99% which, yes, is crazy and should sound unbelievable.
3) Noted, definitely. It is certainly a tough number to nail down because it is very dependent on all the things you mention. I trust our data because we've been at this the longest, were the earliest, and we see a lot of the unadulterated attack traffic that has gotten through many existing defenses so we see the stark difference on day one.
Disclaimer: I contributed to the report in question (but was not consulted or related to the posted article)
Couple this with the fact that mobile services are also subject to credential stuffing attacks constantly and, for the services that allow you to read SMS messages online, the attackers who take over your mobile account also gain a critical piece of your 2FA protection.
It's far more than affiliate schemes. Credential stuffing attacks result in account takeovers for many different types of companies and the value that can be extracted is different for each business.
San Diego JS is a presentation based meetup and we found that a lot of attendees were also interested in classes where they could work on actual code while having the ability to get advice and ask questions.
JSU is not intended to compete, but to fill that need without causing confusion as to what SDJS is. Using a separate, geography-agnostic name also allows us to expand the concept to other cities if anyone is so motivated.
