• 0 Posts
  • 58 Comments
Joined 10 months ago
cake
Cake day: September 7th, 2023

help-circle
  • I would vote for docker as well. The last time I had to inherit a system that ran on virtual machines, it was quite a pain to figure out how the software was installed, what was where in the file system, and where all the configuration was coming from. Replicating that setup took months of preparation.

    By contrast, with Docker, all your setup is documented. The commands that were used to install our software into the virtual machines and were long gone are present right there in the Docker file. And building the code? An even bigger win for Docker. In the VM project, the build environment for the C++ portion of our codebase was configured by about a dozen environment variables, none of which were documented. If it were built in Docker, all the necessary environment variables would have been right there in the build environment. Not to mention the build commands themselves would be there too, whereas with VMs, we would often have developers build locally and then copy it into the VM, which was terrible for reproducibility and onboarding new developers.

    That said, this all comes down to execution - a well-managed VM system can easily be much better than a poorly managed Docker system. But in general, I feel that Docker tends to be easier to work with than a VM. While Docker is far from flawless, there are a lot more things that can make life harder with VMs, at least from my experience.


  • Your comment explains exactly what happens when post-expiration companies like Google try to innovate:

    Let’s be realistic here, google still pays out fat salaries. That would be more than enough incentive for me. I’d take the job and ride the wave until the inevitable lay offs.

    This is why it takes a lot more than fat salaries to bring a project to life. Google’s culture of innovation has been thoroughly gutted, and if they try to throw money at the problem, they’ll just attract people who are exactly like what you described: money chasers with no real product dreams.

    The people who built Google actually cared about their products. They were real, true technologists who were legitimately trying to actually build something. Over time, the company became infested with incentive chasers, as exhibited by how broken their promotion ladder was for ages, and yet nothing was done about it. And with the terrible years Google has had post-COVID, all the people who really wanted to build a real company are gone. They can throw all the money they want at the problem, but chances are slim that they’ll actually be able to attract, nurture and retain the real talent that’s needed to build something real like this.





  • why is it a bad idea that studenst get some tools, free of charge, that they are free to use

    I can’t find it right now, but there was a quote from a long time ago by Bill Gates where he basically said that it was fine if people were using Microsoft’s products for free because it would get them “addicted”. They would rather have people use Microsoft products even for free if it would prevent them from using alternatives.

    That’s why it’s harmful. It’s free for students in the short term, but it prevents them from learning how to use an alternative product that will most certainly be free for them to use forever. Students waste those years when they have a chance to learn something useful, and instead get hooked on proprietary tools that will most certainly fuck them over at some point in the future.


  • The best part of all of this is that now Pichai is going to really feel the heat of all of his layoffs and other anti-worker policies. Google was once a respected company and place where people wanted to work. Now they’re just some generic employer with no real lure to bring people in. It worked fine when all he had to do was increase the prices on all their current offerings and stuff more ads, but when it comes to actual product development, they are hopelessly adrift that it’s pretty hilarious watching them flail.

    You can really see that consulting background of his doing its work. It’s actually kinda poetic because now he’ll get a chance to see what actually happens to companies that do business with McKinsey.



  • Everyone in this thread is saying that this comes as no surprise, and that is certainly true. But the thing is, a lot of management types do know this already but they simply don’t care for two reasons:

    1. They care more about leverage/control over employees than they do about actual good work being done. You cannot understate at all how important employee control can be for managers and how seriously they’re willing to destroy their own business to keep this kind of power.

    2. RTO is basically a layoff program. As much as I love working remotely, it’s very important to keep in mind that remote workers are the first ones that will get laid off when the business wants to cut back - purely because of how easy it is to do. They can just mandate RTO without actually calling it a layoff and know many workers will outright quit, and the business won’t have to comply with whatever local regulations are in place around layoffs. Still, this shouldn’t sound like comfort for employees that do work in the office - there’s a good chance that once RTO is in place, another round of layoffs will strike when the company doesn’t meet its cut targets. So tl;dr: any time a business announces return to office, it means that there’s a good chance that layoffs will follow too.



  • Agreed. Objects are nice and a great way to program. Composition is great. Traits/interfaces are great. Namespaces are great. Objects are a really nice way to reap the benefits of principles like these.

    But then there are aspects of OOP that absolutely suck, like inheritance. I hate inheritance. The rules get very confusing very quickly. For example, try understanding overriding of methods. Do I need to call the superclass method or not? If not, does it get called automatically? If so, in what order? How do these rules change for the constructor? Now repeat this exercise for every OOP language you use and try not to mix them up… Java, C++, Python, etc.

    Fortunately, it feels like we rely on inheritance less and less these days. As an example, I really like how Java allows you to implement Runnable these days. Before, if you wanted to run a thread, you needed a separate object that inherited Thread. And what if that object needs to inherit from another one too? Things would get out of hand quickly. (This is a very old example, but with lambdas and other new features, things are getting even better now.)

    Anyway, long story short, I think OOP is a complicated way to achieve good principles, and there are simpler ways to achieve those principles than a full OOP implementation.



  • All your points are sound. The issue that I have with this is that remote disable functionality is not necessary to achieve any of these aims. Before they were connected to the internet, people were still able to rent/lease autos and the world managed to survive just fine. There were other ways for lenders to get remunerated for breaking lease terms - they could issue an additional charge, get a court order for repossession, etc. Remote disable was never needed or warranted.

    So let’s start by considering the due process here. Before, there was some sort of process involved in the repossession act. With remote disable however, the lender can act as judge, jury and executioner so to speak - that party can unilaterally disable the device with no oversight. And if the lender is in the wrong, there is likely no recourse. Another potential issue here is that the lender can change the terms at any time - it can arbitrarily decide that it doesn’t like what you’re doing with the device, decide you’re in breach, and hit that remote kill switch. A lot of these things could technically happen before too, but the barriers have been dramatically lowered now.

    On top of this, there are great privacy concerns as well. What kinds of additional information does the lender have? What right do they have to things like our location, our habits, when we use it, and all of the other personal details that they can infer from programs like this?

    There are probably lots of other issues here, but another part of the problem is that we can’t even start to imagine what kinds of nefarious behaviors they can execute with this new information and power. We are well into the age where our devices are becoming our enemies instead of our advocates. I shudder to think what the world would look like 20 years from now if this kind of behavior isn’t stopped.








  • I would say the biggest advantage is that OpenBSD is a very security-focused distribution, in a way that I don’t think any Linux-based distro has adopted.

    The other advantage is ZFS. 10-20 years ago, there was no equivalent, and btrfs was in its infancy. These days, btrfs has proven that it is pretty stable and resilient. There might still be some advantages of ZFS over btrfs, but I haven’t used either one at all, so I can’t really be sure.

    Outside of that, the BSDs are basically just different distros. Back in the 90s, when there was a lot more diversity in Unix, a lot of people just started out with *BSD because there was no clear choice at the time. People just like to use what they are more comfortable with - but most new users pick Linux over BSD these days, and a lot of people who started out on BSD have assimilated onto Linux.

    Still, diversity is a good, nice thing, especially with the advent of systemd. So I’m glad we still have the BSDs around, even if I disagree with their stance toward the GPL.