Their results are simply not reliable. The matching approach often matches too many things (hey, this could be A or B or C or D or E or F ...or 42!), or picks up things that have nothing to do with the license of some target (hello randomly included file with some completely unrelated license header and is not even included in the build but is there for some reason, meet your new friend, the utility script copied from somewhere else also not included in the build with an header for another unrelated license. You two feel lonely? let me introduce you to this other wonderful script included in some particular form of packaging) and of course cannot compensate for poorly declared licenses, typos, weird non-standard (or simply archaic/deprecated) ways to specify the licenses and so on and so forth.
It's not a fault of the tools themselves, but in practice they don't help much in real world situations. Basically you end up in need to do so many checks and manual fixes that you might as well not use these tools in the first place.
In an enterprise context one of three things happens: (1) you end up relying on a commercial solution (which is also not that reliable but you delude yourself into thinking it's not your problem anymore... although to be fair commercial solutions have curated licenses attributions and facilitate handling this mess); (2) you build your own thing that uses these (and other) tools but automates a bunch of fixtures so you don't need to go insane every time you need to regenerate an accurate SBOM with related licenses; (3) you quit software engineering, move to a remote location and start an alternative career as an alpaca breeder while whomever takes on your role pretends to ignore the issue and keeps shipping inaccurate declarations of licenses for dependencies thinking that's fine because nobody really cares.
This is why several German automotive OSPOs are working together to build OSS Review Toolkit (ORT) - it kinda glues various open source tools like ScanCode but adds features like the ability to manually correct findings and a policy as code to do risk management at scale/speed. Full disclosure I one ORT maintainers.
As an italian who is told he's pretty good at cooking, some of this is on point but a few things sound "wrong" to me (I use quotes because there's really no objective way to do this literally right or wrong, I'm just comparing with my experience / what I perceive "we learn from grandmas"):
- Put the pasta into the pan with the sauce (which I guess is the main point of the article which starts off with "italian" restaurants putting sauce on top of the pasta in the plate): defintely yes, but...
- Add pasta water: it depends on which sauce you prepared and how you prepared it (and the type of pasta... not just shape, but fresh -vs- dry, and what it's made of). When one uses "pasta water", it's usually in the making of the sauce, not before putting the pasta in the sauce pan; sometimes cooking water is added to the sauce if it "shrinked" too much or the ingredients are not of amongst those which attach to the pasta well, but these are their own cases. All that "adding water and stirring" to get to the "perfect texture" might appear to make sense, but I'm pretty sure it will take too much time and it will mess your pasta consistency because it will get overcooked. Sure you can under-cook the pasta alone a bit to compensate, but what's the point in that? What I'm trying to say is that this trial and error thing might make sense for someone who does it for the first time, but after a while you figure out how the sauce ought to be in the first place, you put the past in, jump it (as in, move the pan to make the pasta "jump" in it so it doesn't attach to the pan) to the right consistency and everything gets where it needs to be pretty easy without all that fuss. At least this is what I do and what I see others that seem to really know how to cook (based on the results) do.
- The bit about using cooking water (that's another way we call the "pasta water") to adjust the consistency which turned bad because of the cheese thickening and liquids evaporating... well, unless we are talking about sauces which have significant cheese quantities in it (e.g., the "cheese and pepper", or "4 cheeses pasta") and have a different process on their own (as does the mentioned "carbonara", which I guarantee you'll screw up if you follow this process because you'll cook the egg too much), cheese usually goes on top of the pasta in the plate as a garnish. For some sauces (e.g., the "amatriciana"), you're even supposed to make the plates (with pasta already mixed with sauce) get a bit less hot before putting in the cheese, to avoid it melting too much. Putting cheese in the pan for a non-cheese based sauce and make it melt and then thick is sort of a cardinal sin (you can add all the "pasta water" you want, you'll never get it back to where you need it to be and it will mess up your dish)
- Add fat: what? Just, no. Olive oil is of very common use, but you don't add it "to the sauce" for texture, for most sauces you use it as the base for the sauce. Butter? Unless we are talking about a butter-based sauce (e.g., butter & sage), which are not that many or very common anyway in regions but the northern ones, nope. Not like that. Some add olive oil as a garnish, but again really depends on which sauce you are using, and it ain't that common
No offense intended, but all of your suggestions sound very stereotypically Italian, which is to say they put an enormous emphasis on the traditional ways that pasta and sauces are made in various places in Italy. There's nothing wrong with this, celebrate tradition and heritage all you want, but that's very different to what Kenji goes for in general and what Serious Eats goes for in general. Their goal is usually to provide techniques that are then used in recipes to achieve a desired outcome.
Whether that outcome is considered traditional or correct by anyone is not something that is considered. The techniques are a tool to achieve an outcome, and how much or little you use those tools is left to the cook, rather than being dictated by tradition or custom.
Pasta water contains starch, which helps to thicken sauces. If you want a thick and glossy sauce, it is one way to do it. End of story. It is a technique to achieve a desirable goal, nothing more. Whether anyone traditionally in Italy does this or not is immaterial.
Similarly, fats are flavorful. Adding flavorful fat to increase flavor in a sauce is desirable. Whether anyone traditionally does this is immaterial if people think it tastes good.
I think you misunderstood what I was trying to contribute though, since I was not attempting to celebrate anything nor to emphasize on traditions. I was just saying those "goals" have well known solutions that differs for some good reasons with what is described in the article, which claims (by its title) to explain "the right way" on basis that are unclear to me.
I do not know "Serious Eats" nor the author, so I'm sorry if I am antagonizing (not my intent, but I get it might be seen this way) a celebrity or his fans and in this upsetting people. I'm just contributing things I know from experience, whereas arguments like "this is one way, end of story" seems brittle to me, because you are basically dismissing the points that I probably didn't even explain decently (on your examples: you add pasta water, you get starch in the sauce which helps thickening things but you dilute other ingredients and will need to cook for more time to have the liquids evaporate thereby overcooking the pasta; you add "fats" like butter or oil at the end and you change the flavour of the dish significantly, other than its nutritions). Then again, if that's what you are looking for, great, I think I said at the beginning there's no objectively right or wrong, it's food we are talking about, if you are happy with eating the outcome good for you.
I mean, by all means please try it, and with that I mean actually get in the kitchen and do it, I think you'll realise there's a lot more than just "using a technique that makes sense in theory, end of story" to get your goals.
> how they determined this project is linked to NK hackers
If they have enough confidence to attribute and not disclose how/why, one can fairly guess they don't want to burn sources or indicators which might still be useful moving forward but likely won't be if disclosed...
(I'm not sure if you were joking or not and I know it's probably not in the same spirit you intended it here / a bit OT but...) I've been using literally that exact expression for a while to describe the situation in which, during somewhat complex discussions within a group, in order to not be perceived as jerks participants are forced to follow an unnecessarily long, repetitive, trivial and most often also completely pointless "line of reasoning" just to have their own attention completely derailed from any productive/actually-interesting argument anyone was trying to make, often ultimately resulting in giving up because recalling those lost mental threads is by then even more difficult and there is only so much mental energy (for you and collectively) to dedicate to that discussion.
Just saying, imho it's already a thing (with different incarnations in different contexts).
This is definitely a thing, but at least in my experience, it is also a thing that narcissists do. They can dig up emails and examples from the dark caverns where you were just having a water cooler chat, and they somehow took it as very serious and something you should have meant to defend if it left your lips.
Reordering and paraphrasing what they actually wrote:
I've been using that expression when giving up on participating during discussions.
Other people's line of reasoning are unnecessarily long, repetitive, trivial and most often also completely pointless. This derails my own productive/actually-interesting argument because I only have so much mental energy.
Plenty of good suggestions here, I don't have another one to add, let alone a better one. But I'll tell you this: you are not alone, this happens (a lot) and odds are it is not your fault. You asked how to deal with it, a lot of the stuff other comments said boils down to realising your professional universe is not so $negative_characterization_here like the place you are currently living in, it just seems that way probably because like a boiling frog you tried to adapt without seeing the hit coming, and came to think that's "normal" and you can't take "it" anymore. Time for a change, you'll do great in your next corner of the universe, and even if you find yourself into another bad one you'll recognise it soon enough and either fix it or leave it.
It's not a fault of the tools themselves, but in practice they don't help much in real world situations. Basically you end up in need to do so many checks and manual fixes that you might as well not use these tools in the first place.
In an enterprise context one of three things happens: (1) you end up relying on a commercial solution (which is also not that reliable but you delude yourself into thinking it's not your problem anymore... although to be fair commercial solutions have curated licenses attributions and facilitate handling this mess); (2) you build your own thing that uses these (and other) tools but automates a bunch of fixtures so you don't need to go insane every time you need to regenerate an accurate SBOM with related licenses; (3) you quit software engineering, move to a remote location and start an alternative career as an alpaca breeder while whomever takes on your role pretends to ignore the issue and keeps shipping inaccurate declarations of licenses for dependencies thinking that's fine because nobody really cares.