Canadian software engineer living in Europe.

  • 18 Posts
  • 483 Comments
Joined 1 year ago
cake
Cake day: June 7th, 2023

help-circle
  • So let’s get the licensing bit out of the way first. I am 100% confident that you’re wrong on this. The GPL is a copyright license and like all copyright licenses, it applies to the work and your rights to copy it. If you choose to copy the contents of a GPL project’s code into your own project, the license dictates that you must license your project under the GPL. For example, if you were to build a new kernel for your own special operating system and copy out significant portions of the Linux kernel to do it, your new kernel will be covered by the GPL.

    You may be confusing the GPL with the LGPL here, which specifically has an exemption for linking. Under that license, you can link to a GPL project (it’s not clear if a Python import would qualify as this was originally written for external modules in C projects) without your project being covered by the GPL.

    You’re also misunderstanding “distribution” here. While it’s true that there’s a distinction between the GPL and AGPL in how this word is defined, it does not affect how the license applies. To use another example, the fuzzywuzzy project is GPL-licensed, so if you were to use it in your Django project, it would necessarily make your Django project GPL. However, as “distribution” under the GPL applies only to sharing copies of the project with others and not to services provided over the web, your project will be GPL, but you’ll be under no obligation to share the source with anyone unless you were to copy the project onto someone’s laptop. So long as your project is just a webserver sending HTML to the user, you’re under no obligation to share the source code for your server.

    The AGPL on the other hand includes accessing the software over a network under its definition of “distribution” and so if fuzzywuzzy were AGPL licensed, this would require you to publish your Django project’s source publicly.

    Source: I too have been reading heavily on this front for about 23 years, so much so that I married a copyright lawyer. We talk about this stuff a lot.

    Regarding the secrets in-repo, I’m not going to fight you on this. In my experience it’s a Great Big Pain In The Ass to manage these things and I think you may be overlooking just how many of the devs on your team may need the rights to read/write production values.

    As for the making the distinction between settings and configuration, again I think you’re going to live to regret this as every company I’ve started at that employs this pattern has. You simply can’t have your development, testing, and production environments running different middleware classes (as your example suggests) and not be due for a surprise in production. No, your settings should be as close to production in all environments as possible, and breaking your settings up like this is just begging for deviation.

    As for the claim that only 99% of problems in production are data-related, that too is not my experience with such systems. If you’re talking to S3 in production and local folders in development, or SQS in production and synchronous execution in development, you will have problems, and you won’t be able to detect them, let alone debug and fix them in an environment that doesn’t match the place you’re deploying to.






  • I think what he’s missing is that he’s approaching the question of “how do I make these people care?” from a liberal position. It just seems like such a weird question to even ask someone who cares about others by default.

    If you think of it from the perspective of a self-centred conservative though, you can ask the question as “how can I frame the pain of others as their problem?”

    Try talking about solutions in a way that affects them personally:

    • You want transit and bike lanes 'cause nothing reduces traffic other than viable alternatives to driving. Get those other people off the road so you can drive.
    • You want to stop sending weapons to Israel because we’re spending your money on weapons for their war.
    • You want to divest from fossil fuels because renewables have better energy security. Your costs don’t go up whenever those people start a war over there.
    • You want high taxes on the rich because they’re festering parasites sleeping on a pile of gold and we want to spend that money on the poor so they aren’t so desperate that they steal your shit.

    The people do not (cannot?) care about how many children are killed by our bombs or about the fate of some bird, so constantly appealing to emotional arguments meant for liberals will never work on them.




  • So here’s the thing. If someone is going to say with a straight face that they “stand with Israel”, even when Israel is committing genocide in their name, then those people are effectively throwing in their lot with genociders and frankly I have little sympathy for them. Thankfully, nearly every Jew I’ve ever met has been very critical of Israel (including the Israeli citizens), many of which have confessed zero interest in an ethnostate, preferring a liberal democracy with no state religion. A secular state for both Jews and Muslims – from the river to the sea if you will.

    These people may well be the minority, but you’ll forgive me if I won’t accept the assumption that the majority of the 15 million Jews around the world support genocide. Call me a naïve optimist if you like, but I want to believe that most people are better than that.


  • Actually, this is one of the things that drives me crazy about Jesse’s take on this. Putting aside for the moment the base selfishness that would lead someone to ask: “how does your committing genocide affect me?”, he’s taking Israel’s position from the start that their actions are directly tied to the lives of Jews around the world. There are millions of Jews out there who are (a) not Israeli citizens, (b) are not Zionists, and © even actively condemn its actions purportedly in their name, but Jesse always starts with the position that Jews == Israel.

    It’s Israel’s favourite shield: to claim that their actions are linked to Jews everywhere. They use it to smear any opposition to their war crimes as antisemitism, and lines of questioning like this only reinforce this link. You just can’t bemoan how Jews are being linked to war crimes while starting from the position that Israel is inherently linked to Jewish identity. What you get is a conversation where both parties agree that Israel is both inexorably linked to Jews everywhere but that they’re also not responsible for their safety because they can’t be – they’re not Israelis.

    To put it another way, no one would do an interview with the Iranian ambassador and suggest that they’re somehow responsible for Islamophobia in Canada. That would be absurd, but because it’s in Israel’s interest to claim representation of all Jews everywhere, you get this ridiculous session where both parties agree on a distorted version of reality. Since journalism is supposed to be about distributing factual information, beginning an interview on such a flawed position is both illogical and irresponsible.


  • The former.

    Responsible journalism is more than simply showing up for an interview and broadcasting whatever lie the subject wants you to share for them. If he’s not going to fact-check the ambassador immediately, then he’s operating as a defacto mouthpiece for his subject. Attaching a fact-checking document, after the fact, in an entirely different medium that outlines just how much of the interview was obvious propaganda is not journalism.

    The worst part is that Jesse has levelled this very criticism in the past against other journalists! Specifically in reference to how Trump is covered, but others as well. You can’t just hand your mic, your platform over to a 3rd party and claim that you’re doing journalism when you’re really being complicit in the distribution of propaganda.




  • I rather like the directory structure change of placing the project “app” separate from the other apps, and am a big supporter of using just or task over make for a variety of reasons, but I’m going to push way back on two fronts: multiple configurations & settings files and secrets in the repo.

    Your configuration & settings should be identical between environments. Otherwise you’re injecting surprises into your project that only happen in certain environments. If your local development operates differently from production, how exactly to do expect to find & fix problems that only occur in production? I wrote a whole rant on this a couple weeks ago, so my frustration on this front is rather fresh. I see it all the time and it’s always a problem I need to un-break when I start a new job. Your environment can change, but the code executing within it should not. See the 12-factor app for further discussion on this topic.

    As for secrets in the repo (encrypted or not) I’ve seen this before at a previous job and while it works rather handily, I really don’t recommend it. It introduces a needless amount of complexity, can potentially leak production credentials, and requires a code change (+CI run, +deploy) to change any of the values.

    Think about all the places your source code goes:

    • Your (likely 3rd-party external) git host
    • Your (also likely 3rd-party external) CI runner
    • Every developer’s company laptop
    • Potentially many developer’s personal devices when they “just want to work on that thing”
    • Any copies they might keep for personal reference after they quit or are fired
    • Any computer or phone that was used to look at the code in a browser
      • …and any plugins that browser might be running

    Now consider how many of them likely have had access to the keys to decrypt certain values over time, how they might have stored the keys in plain text on their machine, or even been Super Careful with everything but were nonetheless compromised by a virus/hack because their kid used their computer that one time.

    All that might be acceptable if the benefits were high, but they aren’t. Now, instead of just one environment to configure, you have potentially dozens: production, staging, testing, and one for every developer who’s ever worked there. Each one with different values, only some have been updated. When Steve gets fired, how many files do you have to decrypt, edit, and re-encrypt to rotate the secrets? This replaces a small headache with a migraine.

    I address this in the post above as well, but the TL;DR is that you can bake known, insecure values into your project (in my case, in compose.yaml) and share any remaining actual secrets required for development sparingly via back-channels. When in staging or production, Compose isn’t in use, so your project will die unless these values are set in the environment – values which should be provided by whatever means that environment favours. Personally, I’m rather fond of tools like Secrets Manager & Vault because they offer an audit trail and a means to alter values without a code change, but a lot of companies prefer to use things like Kubernetes secrets. Whatever it is, it should not be a file in the repo.

    One last note about the license: I love the GPL, but you should know that under this license, anyone using your template in their project necessarily must license that project under the GPL. Your description suggests that it’s enough to say that any modifications to the template must be shared, but that’s not how the GPL works. If I were to use your template in a project about cats, I’d be creating a “derivative work” based on your template which, under the terms of the license means my cat project must also be GPL-licensed.

    What you perhaps could get away with would be treating this like documentation, and licensing it under something like the Creative Commons Attribution-ShareAlike license, where you provide it as a sort of guideline for other projects, but not as code upon which you’d base a project of your own.





  • I’ve been self-hosting my blog for 21years if you can believe it, much of it has been done on a server in my house. I’ve hosted it on everything from a dusty old Pentium 200Mhz with 16MB of RAM (that’s MB, not GB!) to a shared web host (Webfaction), to a proper VPS (Hetzner), to a Raspberry Pi Kubernetes cluster, which is where it is now.

    The site is currently running Python/Django on a few Kubernetes pods on a few Raspberry Pi 4’s, so the total power consumption is tiny, and since they’re fanless, it’s all very quiet in my office upstairs.

    In terms of safety, there’s always a risk since you’re opening a port to the world for someone to talk directly to software running in your home. You can mitigate that by (a) keeping your software up to date, and (b) ensuring that if you’re maintaining the software yourself (like I am) keeping on top of any dependencies that may have known exploits. Like, don’t just stand up an instance of Wordpress and forget about it. That shit’s going to get compromised :-). You should also isolate the network from the rest of your LAN if you can. Docker sorry of course this for you (though I hear it can be broken out of), but a proper demarcation between your laptop and a server on the Open web is a good idea.

    The safest option is probably to use a static site generator like Hugo, since then your attack surface is limited to whatever you’re using to serve the static sites (probably Nginx), while if you’re running a full-blown application that does publishing etc., then that’s a lot of stuff that could have holes you don’t know about. You may also want to setup something like Cloudflare in front of your site to prevent a DOS attack or something from crippling your home internet, though that may be overkill.

    But yeah, the bandwidth requirements to running a blog are negligible, and the experience of running your own stuff on your own hardware in your own house is pretty great. I recommend it :-)