StressedDev

Once a computer (a smart phone is a computer) stops getting security updates, it should not be connected to a network. The reason is that device will get hacked and that is not good.

This person should have upgraded his iPhone 8 as soon as Apple stopped offering security updates. He either already got hacked or would have eventually got hacked if he continued to use an insecure phone. Note that not all hacks are visible. For example, information stealers (malware which steals passwords and data) are designed to run silently in the background. They don't want to victim to know they have been hacked.

You stated that "It looks like a lot of absolutely basic due diligence from investors was skipped, probably due to the prioritization of DEI initiatives and willingness to support them blindly." Do you have any proof that due diligence was skipped? Also, due diligence will not catch every fraud.

A lot has been learned. Unfortunately, people still make mistakes and hardware will continue to have security vulnerabilities.

AWS, Azure, and Google have data centers in Europe. I am sure lots of other companies (like Cloud Flare) have servers in Europe too. Most large providers are global companies which operate in as many countries as possible.

What if their choice was either raise prices or lose money?

Increasing prices is not "pulling the rug out from under you". Hertzer decided to raise their prices. Their customers can either continue using their service, reduce their use of the service, or go somewhere else.

Also, we live in a time of high inflation. We should expect price increases because they value of the dollar, euro, etc. is going down.

I think you are probably misreading the situation. My guess is that their costs went up and they are now increasing their prices so they don't lose money.

I don't think this is a fair comment. This happens sometimes but usually people go with Kubernetes because they really do need its power and scalability. Also, any technology can be misused and abused. It's not the technology's fault. It's the people who misuse the technology's fault ().

() Even here, a lot of it comes from ignorance and human nature. 99.9% of people do not set out to fail. They usually do the best they can and sometimes they make mistakes.

I think the takeaway was Kubernetes did not work for their team. Kubernetes was probably not the root problem but it sounds like they simplified their infrastructure greatly by standardizing on a small set of technologies.

Kubernetes is not an easy to use technology and sometimes its documentation is lacking. My gut feeling is Kubernetes is great if you have team members who are willing to learn how to use it, and you have a LOT of different containers to run. It probably is not the best solution for small to medium sized teams because of its complexity and cost.

This is not that surprising. First, it depends on how big the YAML files were and what was in them. If you have 200 services, I could easily see 200 YAML files. Second, there are non-service reasons to have YAML files. You might have custom roles, ingresses, volumes, etc. If you do not use something like Helm, you might also have 1 YAML file per environment (not the best idea but it happens).

My suspicion is the original environment (47 Kubernetes clusters, 200 YAML files, unreliable deployments, using 3 clouds, etc.) was not planned out. You probably had multiple teams provisioning infrastructure, half completed projects, and even dead clusters (clusters which were used once but were not destroyed when they were no longer used).

I give the DevOps team in the article a lot of credit for increasing reliability, reducing costs, and increasing efficiency. They did good work.

Congratulations to all of the employees at Databricks. This is a huge milestone.

Here are some lessons from this:

1) One of the most important aspects of software is support. No support means an insecure device.

2) Devices should state when they will stop receiving security updates. People should stop using devices once they stop receiving updates.

3) Do not buy from manufactures who do not state how long they support a product or do not tell you when they stop supporting a product. Note putting a notice on a page buried in a web site is not good enough. The product itself should tell people when it is no longer receiving security updates.

Software needs longer support life cycles in general. I find it frustrating that organizations do not support operating systems, hardware, and applications for at least 10 years. Note Apple is one of the better organizations on this. Consumer router companies are notorious for shipping unpatched software. Here is what I would like to see:

1. All hardware and software should come with a highly visible end of support date.

2. All hardware and software should notify people when it is no longer receiving security patches. It should also explain to users why running unpatched software or hardware is dangerous.

Every organization makes mistakes and every organization has outages. Netflix is not different. Instead, of bashing them because they are imperfect, you might want to ask what you can learn from this incident. What would you do if your service received more traffic than expected? How would you test your service so you can be confident it will stay up?

Also, I have never seen any Netflix employees who are arrogant or who think they are superior to other people. What I have seen is Netflix's engineering organization frequently describes the technical challenges they face and discusses how they solve them.

Not even close. If you think Amazon is awful, you have no idea how bad things can get. Amazon is probably a difficult place to work because of its high expectations and demanding culture. This (or requiring people to work at the office), do not come close to making it the worst employer.

Thank you for pointing this out. Article titles should not mislead readers.

Google recently changed who is running search. Basically, Prabhakar Raghavan was moved from running Search and ads to being Chief Technologist. Nick Fox is the new person running Google Search. This happened on 10/17/2024. For more information, please see https://searchengineland.com/google-shakes-up-leadership-rag... and https://www.theverge.com/2024/10/17/24272786/google-search-p... .

I wonder if Prabhakar Raghavan was moved out of Google Search because of Search's decline in quality?

This is not surprising. Hindenburge Research (a short seller) documented SuperMicro’s problems in August 2024 (https://hindenburgresearch.com/smci/).

Proton Mail and iCloud’s hide my e-mail feature allow users to have unlimited e-mail addresses. You can also get unlimited e-mail addresses by running your own e-mail server or using something like Office 365’s business e-mail (costs about $4 per month).

How is Apple violating people’s privacy? They have done a far better job than other companies from what I'm have seen.

Advertisers absolutely do want people’s personal data. It helps them build better dossiers on individuals. This helps them target ads. Improving ad targeting improves publishers and advertisers profits because consumer responses to advertisements increase as advertisement relevance increases.

Typically, developers have to tell the operations/sys admin/devops people a lot of things to get their application running in test/pre-production and production. Here are some examples:

- Network ports the service listens on - What security permissions does the application need - What commands have to be run so the application starts - What platform does the service use? Java, Node, C#, C/C++, Go, something else? - What GIT repository or repositories contains the service's code? - How does the build work? - What needs to deployed to the machine? - Any configuration changes the application needs

There are also a lot of join decisions where the operations engineer and the software engineers have to work together. Here are some examples: - What cloud will the team use? (AWS, Azure, GCE, etc.)? - What cloud technologies will the team use? - What database will the team use? - How will logs and alerts work? - How will the on-call rotation work?

My main point is you cannot just tell an operations person to deploy something and expect good results. They will have a lot of reasonable questions and software engineers should be able to answer them.

Nope - A large portion of the world works like this. If you work for a place which demands you work all of the time, you either work for an abusive employer, or you get paid a lot of money to be at their beck and call.

If the employer is abusive, find another job. If you are paid a large salary to be a slave to company, consider finding a job with a better work/life balance.

Same here. The fact is no one can be on call 24/7. People need downtime. I have never worked with a manager who demanded people be contactable at any time. I have been on call but that makes sense. Note that on a good team, being on call is easy because the service rarely goes down.

You can do a lot more than just keep Windows up to date. Here are some other things you should do:

1) Use separate accounts and machines for administration tasks. Basically, IT people should never use their e-mail, web browsing, and development machine for system management tasks. They should use a separate machine with a different account for these tasks. The main reason is the system management machine has a much smaller attack surface. Ideally, it should only run a communications program (IRC, Slack, MS Teams, etc.), and the tools the person needs to do their job. Examples of tools people need include SSH, Remote Desktop, kubectl (Kubernetes tool to manage a cluster), etc. The machine should have a web browser BUT the web browser should be restricted to the bare minimum number of sites needed to administer the systems. Examples of acceptable sites include the Azure Portal, the AWS web site, web sites to configure equipment, etc. Examples of things which are not allowed include web mail, documentation, etc. The goal is to have the smallest possible attack surface.

2) People need to be mindful of what they install on their machines. I have seen a lot of people who will install anything which looks useful on their machine. This is a great way to get hacked. Here are the questions people need to ask before installing software.

- Why do I trust the people who wrote the software? - Why was the software created? What was the motivation of the author? - How does the author support himself or herself? What would happen if one of the authors was in financial distress? - How will I know when the software needs to be updated? - What are the capabilities of the software's authors? Do the authors understand how to write secure software? How do the authors handle security bug reports?

Basically, you ask these questions because you want to avoid malware, and you want to use software which fixes its security problems.

3) Consider putting system management machines on a different network or VPN. Basically, it's harder to hack a machine if you can't easily communicate with it.

4) System management machines should not be listening on any ports (or should have a firewall which blocks all connection attempts). It's harder to break into a machine when an attacker cannot connect to it.

5) Put the system management machines behind a firewall.

6) Consider what happens when an account is eventually hacked. Many people assume that only dumb or incompetent people get hacked. Unfortunately, this is not true. Systems should be designed to assume accounts will get hacked. The best designs limit the blast radius (damage) of account attacks.

7) All users should have limited privileges. Basically, they should get the privileges they need to do their jobs. Very few people should be allowed to have the equivalent of root/Administrator for the entire system (obviously, people may have these permissions for some machines but almost no account should be able to do anything on any system the organization runs).

Windows XP machines should not be connected to a network because they no longer receive security patches. They will get hacked if they are connected to a network (and please remember that not every piece of malware is obvious, some malware is stealthy, and just steal information from the hacked machine).

Also, you connect a machine which can be hacked, you are not just hurting yourself. That machine can be used for a lot of malicious purposes including DDOS attacks, sending SPAM, allowing attackers to hide their true location, etc.

If you are doing Windows C/C++ development, you can use the strsafe.h functions (https://learn.microsoft.com/en-us/windows/win32/api/strsafe/). When I wrote C/C++, I found them easier to use than the standard C functions because they handled all of the usual failure cases (buffer too small, integer overflow, etc.). It was also easy to check if there was a failure because all of the functions returned a failure code if something went wrong.

In this case, StringCchCopyW(), or StringCbCopyW() would be a better choice than strcpy.

No - Seriously, an article with a title like this is unhelpful. First, hating Google seems unproductive because Google created many successful products people love, or like to use. Examples include Android, Google Search, GMail, Chrome Books, Google Cloud, etc. Second, I can understand why people prefer non-Google products, but I cannot see hating Google. Google is a business which has not killed or harmed anyone.

At worst, Google has a few persistent problems. 1) It creates dossiers on people so it can show more relevant ads. This is not good but it is also not a reason to hate Google. 2) It tends to be somewhat dysfunctional. Examples include recent declines in search quality, and the refusal continue to invest in business which are not instant successes (the exception to this rule is Google Cloud). 3) It is very hard to get any customer support. The solution here is to go to a company which has more accessible customer support if you do not like Google's approach.

I have not seen any reason to hate, or even dismiss Google. Google has created a lot of good products. We would not have modern search without Google. Hating Google seems like an unhelpful extreme behavior. Ars Technica should not publish articles like this.

This is not typical in the US. I have never heard or seen a gun shot fired while someone committed a crime.

I have never had to initiate a chargeback to get customer service.