As a Python developer, I am so happy right now.
But what TYPE of happy are you?
I don’t give a duck.
Log4jmemes.com: for those of us that need a laugh
61–70 of 115 posts
Re: Log4jmemes.com: for those of us that need a laugh
#62Re: Log4jmemes.com: for those of us that need a laugh
#63On a serious note, I think it's a good time to remember to donate some $ to open source, especially the Apache foundation for their incredible work over the years!
I disagree. If you are a software developer you should expect someone to pay you, so that you contribute to Open Source. Probably the bigger companies and indirectly the end user. It's time we break from this "free" stuff mentality. Nothing is free and even if we expect free stuff from developers, we shouldn't expect them to maintain that stuff for free at their expense.
Last time I needed an HTML/CSS framework, I was looking for the "best" open source and free one. I then decided to go with Tailwind and pay the $279 lifetime license fee. Now that I think more about, I'd have been happier with a subscription or paid updates than a "lifetime" license.
Re: Log4jmemes.com: for those of us that need a laugh
#64I'm missing one:
The number of customers confusing Apache Log4j with Apache Web Server
Is Too Damn High!Re: Log4jmemes.com: for those of us that need a laugh
#65I spent this weekend removing Elasticsearch usage in our project. Just earlier I saw that our API wasn't responding, and was wondering how the hell someone with log4j got to us. Turns our AWS West 2 was down. If it weren't for the fear of DDOS attacks, I'd put every webservice in a physical server in a basement somewhere and be done with it. I've been fighting this whole year to simplify and reduce the number of depe…
I'd put every webservice in a physical server in a basement somewhere and be done with it.
One of the benefits of working in healthcare is that if it's not on-premesis, it's a non-starter for many organizations.
My company's paranoia of cloud services has paid off several times in terms of security in the last few years, even if the cost in dollars was higher. At this very moment, a vendor is going through a ransomware attack and its SaaS service unavailable. Our locally-hosted version is unaffected.
We only rent other people's computers (cough "cloud" cough) when there is absolutely no alternative, including doing without. On the other hand, it's locked me out of a number of programs and services I'd like to use.
Still, startups have to learn that if you're serious about being in enterprise, having a locally hosted option opens doors. Very lucrative doors.
Re: Log4jmemes.com: for those of us that need a laugh
#66Earlier quoted context omitted.
I think you misunderstand the point of log4j. Logging is not free, and outputting to all three of those is quite expensive (especially in the Docker case, and it can even be dangerous as Docker - at least for a long time - did not implement proper backpressure and instead dropped logs). log4j allows libraries to implement logging and allow the end user to worry about where the logs go, at the application level, usual…
I'm not entirely sure libraries logging is a good idea anyway. I think there is a strong case that logging should be entirely an application concern not a library concern.
I've got a bug... the application that I've deployed isn't working in this configuration. It's not even hitting my controller for me to be able to log to a file.
So, I kick the log level from warn to debug and I see that Spring is booting it because it failed a CORS check. This was much easier than trying to reproduce it in my local system and attach a debugger to it.
There is a lot that goes on beneath and behind the code that a person writes within the libraries. I would contend that the log4j vulnerability is because people didn't realize the extent of what was going on beneath and behind.
Making a developer blind to what goes on inside a library is not the answer. The "what goes on inside of a library" is indeed a concern for the application and the developer and should be made as easy to access as possible.
Re: Log4jmemes.com: for those of us that need a laugh
#67Thanks for laugh. Corporate VPN: "This site is blocked due to a security threat."
> Corporate VPN: "This site is blocked due to a security threat." IT: Domain too new, so we're blocking it out of abundance of caution. (Works for blocking new and targeted threats, but you get this false-positive block.)
I have this specific rule turned on in NextDNS. It’s sometimes annoying, but seems like a reasonable policy to block any newly registered domains as extra protection against phishing attempts.
Re: Log4jmemes.com: for those of us that need a laugh
#68https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you... "If using log4j 2.10.0 or any later version, we recommend disabling message lookups globally by setting the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true by executing this command before Java applications are loaded in one of the system’s init scripts"
Re: Log4jmemes.com: for those of us that need a laugh
#69Re: Log4jmemes.com: for those of us that need a laugh
#70The one about using print/console.log/whatever lol. I've always done this, never have I used a library for this, because: - running manually? >myapp.log 2>&1 - using systemd? use journalctl - using docker/kubernetes? capture automatically the stdout/stderr of your containers and pipe them through logstash or something Real question: why would an application need to know where its logs go? This is not in the business…
> Am I wrong? You are not a real Java Programmer then.
Thank gawd for that!