ashtonkem

> e.g. by opening malicious attachments in e-mails

And how pray tell do those malicious emails take over a system if an insecure OS isn’t at fault too?

Log emission can often have a negative impact on performance, especially since peak logs and peak traffic tend to coincide. I’ve seen P95 latencies suffer just because of logs.

> How much log data do you think cloudwatch and the other majors filter per hour?

How much do you think the major providers pay for that infrastructure per hour, and are you willing to shoulder that cost too?

(Hint: log ingestion is $0.50 per gigabyte in cloudwatch. So a terabyte of logs an hour is $512/hr)

Hindsight bias. Keep in mind that Log4j is older than most log aggregators by a solid decade. This is a solid reason to not use log4j going forward, but an ahistoric charge against it in the era when it was first written and adopted.

Most of us have log4j in our system because it's used by some various dependency of one type or another, and up until now it has generally just worked.

It's a bit of conservative culture, and a bit the result of success. There is a lot of Java code out there, and a lot of it is quite old. Finding and replacing every single instance of log4j out there would be a lot of work, and before this incident of relatively low benefit to everyone involved.

> I was once, but haven't used it professionally for a while.

This is why I ask. Java has changed a lot since ~1.8, and it is super common to see ex or non java developers making grandiose and sweeping statements about a community and language that they are no longer part of. Having developed in Java on and off since ~1.7 and Spring 3, I can certainly say that I have seen a strong movement towards less complexity and more convention. It's not perfect by any stretch, but I think saying that the space is "in love with complexity" is incorrect.

You of course don't have to go and re-use Java on my suggestion. We all have our preferences, and that's ok! But I would generally recommend against such sweeping and dismissive general statements about a culture that you are no longer part of. Things change, and your experience back then is probably not representative of things today.

> Oh, and now that you described it with so many details, the attachment to complexity does look more like addiction than love.

There's a fine line between disagreement and insult, and you are over it.

You act as if “restarting” the logging system is easy and doesn’t require the same facade that you decry for a reconfigurable one. With dependency injection, there are loggers everywhere in the system, possibly in sections of the code you didn’t even rewrite. Restarting such a system while continuing to run everything else is just as complex as reconfiguring, possibly more complex.

Also, I noticed you didn’t answer my question about whether you’re a Java developer.

> It's a logging library. You don't reconfigure logging, you just make another logger and use it.

Prior company had a shared plugin that let you turn up the logging for a given logger remotely for 30 minutes (it self reset). Extremely helpful for incident debugging.

Now we can have an interesting discussion about whether that capability is worth the complexity, but that’s a very different discussion than unilaterally declaring that other people’s use cases just don’t exist.

> Despite what people claim, the Java culture of loving complexity never did go away.

Do you develop in Java? Because I do, and your takes don’t match my daily experience one bit. My experience going from Spring 3 to Spring Boot 2 is in fact one of reducing complexity (goodbye XML bean configuration!) and to more “it just works” situations than before.

> Here's what I don't get: What is so complicated about logging that you can't implement the necessary functionality in your own codebase, and instead have to adopt a third-party library?

Transitive dependencies for one thing. I rather enjoy having my DB driver, connection pool, kafka client, and web framework all emit their own logs, which is not possible if I wrote my own logging library.

> I get that the tradeoff it is worth it for complicated things (e.g. crypto libraries). But logging, really?

Logging at scale is more complicated than people give it credit for. Personally I've had my services suffer noticeable performance degredations due to poor logging framework config. We've ended up with a fairly complicated logging config that allows us to carefully balance collecting as much developer useful information as possible against the need to drop excessive logs during periods of heavy activity. Oh, and it's gotta be converted into JSON for aggregation into our observability tools, and decorated appropriately so that our logs can be correlated with our application traces, because that is incredibly useful during incidents.

Oh, and it all needs to work no matter what threading configuration you throw at it. That matters a lot too.

Do we need all those things? Arguably no, but then again they are helpful tools to have. Without them, the team would have a harder time developing on our systems. You have to understand the use case that people need to fulfill before dismissing the entire thing as unnecessary and pointless.

> Software development culture today is too quick to adopt a huge tree of dependencies of unknown quality, rather than thinking about how to minimize dependencies to only those truly necessary. The leftpad fiasco was but an extreme example of this, but I see it all the time, and it seems probable that there are hundreds (maybe even thousands) of similarly severe problems out there in widely used dependencies that we just don't know about yet.

I see this argument a lot, and I think it's a great example of "grass is greener" syndrome. People don't think through the practical consequences of drastically reducing their library usage. I personally worked on a project that had basically no external libraries due to the language choice, and we wasted inordinate amounts of time trying to chase down bugs we wrote in things like our database library, localization library, and yes, our logging library. Looking back I can say with very strong confidence that what we were doing was a massive waste of the company's resources, and rewriting it into Java or C# would have been the right call, even with the complexities those ecosystems bring to the table.

Yes, using external libraries comes with tradeoffs. Fixing bugs like this is one unpleasant possibility. But let's be clear that the alternative is a massive drop in developer productivity to write basic functionality that already is implemented elsewhere. Having been on both sides of this equation, I can confidently say that you'll spend way less time fixing security issues as they arise than you will reinventing the metaphorical wheel.

(I do agree that leftpad is an example of going way too far with libraries, but I think the library culture for NPM and the Java ecosystem are quite different).

Google Analytics should be on the default list, I didn't have to take any explicit steps to block it other than select whichever blocklist the pihole developers recommended.

I am not. Although one of my direct's decisions to setup a parent pom to manage versions across all our apps is paying back dividends this week.

Slf4j is one of the two examples I point to for really great java design. It's broken down into one jar for the no-op interfaces, and other jars for the various implementations. This lets library owners instrument their libraries for logging without having to make a final decision on the actual logging library and its settings. It's great.

The other example for those that are curious is micrometer. The basic API and the implementations (prometheus, statsd, etc.) are separate jars.

DNS level blocking with a Pihole is much safer in this regard, but also less capable, since it only works on anything that uses a dedicated domain that can be identified.

In this case, google analytics only goes through analytics.google.com, so it’s easy to block at a DNS level.

You can legally dual license if you have ownership over all the code in question. This is common for open source industrial software; pay for a different license so you can embed it in a closed source project. The GPL doesn’t restrict you from offering the same code with a different license if you own it.

Often the issue is that some projects don’t require contributors to sign over copyright ownership as part of contributing. So you have a project that’s licensed uniformly, but each contributor still owns their individual contribution. Unwinding this after the fact can be a nightmare, as it involves either finding every contributor and asking them to sign over their code, or manually removing every bit of code you don’t own as a project.

This is why a lot of bigger projects require you sign a contributors agreement that assigns copyright before you can contribute to the main repo. Doing this in advance saves the project a lot of headaches down the road if dual licensing is deemed useful. This is true even if you want to license under two different open source licenses, as only the copyright holder can change the license.

I think this is overly reductive, even if it’s largely pointed in the right direction.

For example, I think the best way to interpret the pandemic isn’t through ethical systems, it’s through state capacity and competence. America didn’t fumble the pandemic because of deontological ethics, it fumbled because the federal government was just straight up incompetent. Without the federal government coordinating the crisis, every state was left to try its own strategy, which really does not work during a pandemic.

Furthermore china might have eventually taken a “utilitarian” approach, but only after their first strategy of denial and repression failed. Like many authoritarian regimes China’s first interest is in their own stability, not prosperity per se. In cases where the prosperity of the citizens and the pride of the party are in conflict, China will clearly favor the latter over the former.

Also, KYC and AML are mandatory the moment you actually interact with the regular US banking system or USD at all. So any place where you can buy crypto or sell it is going to do KYC and AML on you, including asking uncomfortable questions if your behavior looks suspicious.

I’m sure the brick and mortar stores felt similar before Amazon came and ate their lunch. Expensive and difficult to replicate infrastructure is a protective measure until it suddenly becomes a millstone around your neck due to its cost and inertia.

On the other hand customer trust is also a great moat to protect you from being usurped, and no company will ever come to rue having too much consumer trust. Amazon is foolish to spend this consumer trust down for increased profits.

- Introduces exchange risk and tax complexities for most merchants.

Yeah, Musk blatantly lying about these things really doesn’t help their case one bit. It’s hard to hide behind “autopilot is just marketing” when their popular CEO is lying about its capabilities left and right.

There's a big difference between "we're going to the rooftop for a project" and "we just left the rooftop door permanently unlocked". The former is fine, the latter is where I'd say that the University is probably making a mistake.

Exceptions of course for high traffic rooftops specifically designed for human occupation, with appropriate amenities and guard rails. The ones my university locked off were either full of industrial equipment (ACs, etc.), or had low stone ledges that were no longer up to modern spec. Closing them off was the right call.

There's also the question whether any given institution is even capable of addressing the underlying causes, or whether it's in its best interest to do so. Sometimes the causes are big and deeply rooted, and a college is not capable of pushing back the metaphorical tide.

Focusing in on students specifically, I suspect (but do not know) that the extremely high pressure nature of going to a University in India is a factor. If that assumption is true, it's not clear whether the University is capable or willing to change that.

You can do that by comparing the rates in various states against the rate of firearm ownership. There does seem to be a positive correlation between firearm ownership and suicide in the United States, although other correlations are equally present and might be causative as well. Rural areas tend to to have high suicide rates[0], and tend to both be more poor and have more firearms than urban areas per capita.

Globally it's more complicated, as there are plenty of countries with fewer firearms than the US and more suicides, as well as countries with fewer firearms and fewer suicides. Material conditions (poverty, etc.), prevailing attitudes around substance use, hard to describe social well being factors, and stigma/quality of mental health care seem to be factors.

For my part, I think that easy access to a means of suicide, such as firearms, is one part of the equation, but not the dominant part. The dominant part is the prevailing experience in the population as a whole, as a population that feels like it's lost hope is more likely to attempt suicide on average than one that has not. But it does seem like wide spread misery and access to an easy and quick means of suicide is a very bad combination.

0 - https://www.cdc.gov/media/releases/2017/p1005-rural-suicide-...

Yes, I intended the phrase “suffering” to encompass the causes leading to suicide as well, and clearly cut my wording a bit too short for clarity. My apologies.

> That wasn’t the point that people were making. The point they were making is that removing fans doesn’t address the underlying mental health issues.

That is a fair argument, but not how I interpreted GP. In the context it seemed like they were arguing against any measure that removes means of suicide away from people because “they’ll just do it regardless”.

> If anything, arguing that everyone is ok now because fewer people are dying

Literally nobody here is saying this. Everyone here has acknowledged that this doesn’t solve the underlying mental health issues (or material issues, per a now dead comment), but might be a good band aid (over a “bullet wound” per another commenter).

What’s more common here is the acknowledgment that this doesn’t solve the mental health issue, and the grim realization that the university won’t do anything about it either way.

Assuming teenagers and low 20 something’s are the similar the world over, they should have restricted access to terraces and rooftops for a variety of reasons unrelated to suicide. Alcohol and heights tend not to be very close friends, and my college restricted access to the latter as much as they could (the former was a lost cause).

That is a common meme, but it’s wrong. For every ten people who attempt suicide and fail, only one will eventually die by suicide[0]. 70% of survivors will never even reattempt suicide, and only 7% or so of suicide survivors will eventually successfully commit suicide.

Furthermore, I’m disturbed by the cavalier attitude here. Suicide isn’t a predestined thing that we’re helpless to prevent as a society. There is real suffering and we can do something about it in aggregate. Framing it as something “they’ll do anyways” is both factually incorrect, and absolves society of any responsibility to help prevent suicide.

0 - https://www.hsph.harvard.edu/means-matter/means-matter/survi...

So don't buy macs.

Either way, in this case they blocked a developer that was making what sure as hell looks like spyware to me, I'm not convinced this is a bad thing.

Also, you absolutely do need a license to operate a car. Probably not a good metaphor for your case.

If I had to guess on something external to MS, I'd blame the same storm system that caused a us-west-2 outage today.

Assuming children don't count? Their website has testimonials from people using it to monitor their spouse, which seems like quite the red flag to me.

This is a bit like arguing that one shouldn't be punished for a traffic violation because not every other potential offender got caught.

I disagree, quite strongly.

Let's leave behind this app for a second, and speak in generalities. What should Apple do if it believes that an account is making and distributing spyware or malware? Should they not ban the account altogether? In fact, wouldn't you be mad if you found out that there were playing whack-a-mole with individual submissions from a developer that they'd already decided was harming end users? I personally would be pretty annoyed if it turns out that they let a malicious developer produce spyware and continually tweak and re-submit their apps it until the approvers let it through, and would absolutely support a policy of banning whole developer accounts for certain infractions. I doubt I am in the minority here, even if there are disagreements about what those ban-worthy infractions should be.

So, the question here is whether or not this app is spyware or not. I personally am beginning to suspect yes, both because parental software always toes that line, and based the apps marketing and the developer's comments in this forum. Others might disagree. But while it's reasonable to disagree about whether this is spyware, given the above logic I think we can agree that it's perfectly reasonable for Apple to ban an account that it has determined is making spyware. You should disagree with the determination, and understand that the ban follows that determination directly.

Personally I think the weirdest thing here is the recommendation to make a new account. Generally most companies hate it when you try and recreate an account after a prior ban, and an official recommendation here seems quite odd.