Brief items

Any vulnerabilities found outside of GKE [Google Kubernetes Engine] (like Kubernetes or the Linux kernel) should be reported to the corresponding upstream project security teams. To make this program expansion as efficient as possible for the maintainers, we will only reward vulnerabilities shown to be exploitable by stealing a flag. If your exploit relies on something in upstream Kubernetes, the Linux Kernel, or any other dependency, you need to report it there first, get it resolved, and then report it to Google. See instructions here.

The GKE lab environment is built on top of a CTF [capture the flag] infrastructure that we just open-sourced on GitHub. The infrastructure is new, and we are looking forward to receiving feedback from the community before it can be actively used in CTF competitions. By including the CTF infrastructure in the scope of the Google VRP [vulnerability rewards program], we want to incentivise the community to help us secure not just the CTF competitions that will use it, but also GKE and the broader Kubernetes ecosystems.

When law enforcement agencies tout their latest cybercriminal arrest, the defendant is often cast as a bravado outlaw engaged in sophisticated, lucrative, even exciting activity. But new research suggests that as cybercrime has become dominated by pay-for-service offerings, the vast majority of day-to-day activity needed to support these enterprises is in fact mind-numbingly boring and tedious, and that highlighting this reality may be a far more effective way to combat cybercrime and steer offenders toward a better path.

If you choose to use a 80-column terminal, you can live with the line wrapping. It's just that simple.

And longer lines are simply useful. Part of that is that we aren't programming in the 80's any more, and our source code is fundamentally wider as a result.

Yes, local iteration variables are still called 'i', because more context just isn't helpful for some anonymous counter. Being concise is still a good thing, and overly verbose names are not inherently better.

But still - it's entirely reasonable to have variable names that are 10-15 characters and it makes the code more legible. Writing things out instead of using abbreviations etc.

No, thank you!

C is a symbolic language, not a text language. Encouraging newbies to declare

    int iterator;

instead of

    int i;

does the language a disservice.

It's true, nobody uses a TTY33 anymore. Those of us who have done so understand how "{" is preferable to "BEGIN" and why tabs are better than multiple spaces. A narrow "terminal" requires less neck and mouse movement. Any width limit is arbitrary, so to the extent anyone might care, I advocate 80 forever.

We have over 200 booting devices now. Yes, booting is the operative word, with most of these ports you get more of a Raspberry Pi alternative than a functional phone experience with postmarketOS.

The hard economic truth for engineers is that technical excellence is overwhelmingly irrelevant, and the history of our profession is full of cases that demonstrate this. Javascript as a language, for instance, largely came to dominate the browser ecosystem only due to the Netscape marketing department, who decided on a clever marketing ploy to circumvent Sun Microsystems and give their own new language cachet by hijacking existing name of Java. While we can’t attribute all of Javascript’s success to this naming, it is quite likely this trick was sufficient to convince enough non-technical stakeholders to make a significant difference in early adoption. These kinds of marketing tricks and positioning are likely the most fruitful path to reaching a large technical audience.