Daniel Quinn

@Daniel Quinn@lemmy.ca
6 Post – 195 Comments
Joined 1 years ago

Canadian software engineer living in Europe.

To be clear, I'm not throwing shade. That's an impressive piece of software. It's just, given the number of stories I've heard (and experienced) about Bash's tricky syntax leading to Bad Things, I'm less comfortable with running this than I would be with something in a language with fewer pitfalls.

But if others take the chance and it sticks around a bit, I'll come around ;-)

Thanks for the contribution! It's a great idea, and with Google fucking about with blocking things like NewPipe, a project like this is a great answer to that.

1 more...

That looks really impressive, but at nearly 1000 lines of Bash, I'm afraid I'm not comfortable running it on my machine. My Bash-foo isn't strong enough to be sure that there isn't a typo in there that could nuke my home folder.

3 more...

Ha! I wrote it! Well the original anyway. It's been forked a few times since I stepped away.

So yeah, I think it's pretty cool 😆

8 more...

Oof, that video... I don't have enough patience to put up with that sort of thing either. I wonder how plausible a complete Rust fork of the kernel would be.

16 more...

It's funny, before this, I was just going to buy a legit copy and play it on my Deck (I have a Switch, but prefer the Deck)

Now, fuck those guys. If I play at all, it'll be on a pirated copy.

Actually, I stepped away from the project 'cause I stopped using it altogether. I started the project to satisfy the British government with their ridiculous requirements for proof of my relationship with my wife so I could live here. Once I was settled though and didn't need to be able to bring up flight itineraries from 5 years ago, it stopped being something I needed.

Well that, and lemme tell you, maintaining a popular Free software project is HARD. Everyone has an idea of where stuff should go, but most of the contributions come in piecemeal, so you're left mostly acting as the one trying to wrangle different styles and architectures into something cohesive... while you're also holding down a day job. It was stressful to say the least, and with a kid on the way, something had to give.

But every once in a while I consider installing paperless-ngx just to see how it's come along, and how much has changed. I'm absolutely delighted that it's been running and growing in my absence, and from the screenshots alone, I see that a lot of the ideas people had when I was helming made it in in the end.

4 more...

Ubuntu. They've managed the worst of both worlds: like Debian, everything is old (though admittedly not as old), but unlike Debian, everything is broken/buggy/flakey. It's the old-and-busted distro that I'm routinely told is "the only Linux we support".

9 more...

Just use Firefox already.

6 more...

Great, do whatever you want. Just shut the fuck up about it, nobody cares.

You should really take your own advice on this one. That "article" was juvenile.

10 more...

Given that domain seizure is becoming such a common tool for this sort of thing, maybe we need a work around for DNS?

For example, we could distribute z-library name/IP pairs in the form of a hosts file via torrents and then write little wrapper programs for each OS that would just crawl the DHT for the latest version to update your local hosts file.

A more extreme option would be to build a pirate browser that has a bunch of name/IP pairs baked into it. People could just launch the browser and visit websites as usual without DNS being an issue.

I'm aware that using Tor is also an option, but there's a bunch of problems there with usability like installation and setup (for non-technical people). Onion URLs aren't easily discoverable either, and much of what you find in there just kids cosplaying as digital freedom fighters posting links that load really slowly... at least that was my experience the last time I tried out a TOR browser.

13 more...

There have been some great answers on this so far, but I want to highlight my favourite part of Docker: the disposability.

When you have a running Docker container, you can hop in, fuck about with files, break stuff as you try to figure something out, and then kill the container and all of the mess you've created is gone. Now tweak your config and spin up a fresh one exactly the way you need it.

You've been running a service for 6 months and there's a new upgrade. Delete your instance and just start up the new one. Worried that there might be some cruft left over from before? Don't be! Every new instance is a clean slate. Regular, reproducible deployments are the norm now.

As a developer it's even better: the thing you develop locally is identical to the thing that's built, tested, and deployed in CI.

I <3 Docker!

4 more...

You make an excellent point. I have a lot more patience for something I can understand, control, and most importantly, modify to my needs. Compared to an iThing (when it's interacting with other iThings anyway) Linux is typically embarrassingly user hostile.

Of course, if you want your iThing to do something Apple hasn't decided you shouldn't want to do, it's a Total Fucking Nightmare to get working, so you use the OS that supports your priorities.

Still, I really appreciate the Free software that goes out of its way to make things easy, and it's something I prioritise in my own Free software offerings.

6 more...

There's a conversation going on in that Mastodon thread where one dude is proposing a static site fueled by a fact-checked list, but that's the only thing I've seen other than BDS.

1 more...

There's a couple angles you can take on this. My favourite is from the dotCommunist Manifesto:

Society confronts the simple fact that when everyone can possess every intellectual work of beauty and utility—reaping all the human value of every increase of knowledge—at the same cost that any one person can possess them, it is no longer moral to exclude.

Essentially, this argues that the unethical position is the one that creates the false scarcity.

Another less extreme position would be that many countries allow for exemptions for format shifting: if you buy a CD with some music, you're legally permitted to rip it so long as you don't distribute copies. One could argue that someone in your position is operating within the spirit of these laws... provided that you haven't torrented the videos since that necessarily includes some partial distribution.

Finally, the least generous interpretation would point out that you didn't buy the videos in the first place, but rather a licence to let Vudu stream them to you. Given that you don't own anything, you're not morally entitled to own it in a different format. This is why many people have rejected the streaming model.

As someone in camp #1, I think you're a-ok ethically, but I thought you might want a broader perspective.

1 more...

What exactly is the appeal of Docker Desktop on Linux? I can run docker just fine without it, so what's it doing for me?

7 more...

I don't know. I posted it here because CicleCI is a popular tool for Open source projects.

Mozilla's VPN is just reselling Mullvad, so you can support Mozilla and use Mullvad at the same time if you like.

2 more...

Actually, someone did, changing the name to "Glimpse". They announced it as an explicit fork that would continue development under the new name.

As far as I know, that's as far as they got.

3 more...

These are fun questions! There's a few other things you have to consider though before you can have some answers.

If the work was done for your employer (non-commercial, academic, or otherwise) you should be sure that your work for that organisation did not include the transfer of ownership of the work you create to said organisation. Most organisations that employ people to write software usually include a stipulation in your contract that anything you create "in the course of your employment" (this is a legal term meaning work you do for your job as well as work you might do related to you job as inspiration/necessity for your job etc) is owned by the employer. If that's the case for you, you can't simply re-license the software, even if it's already publicly viewable. You need to seek the consent of the copyright owner to either (a) transfer the ownership to you, or (b) agree to a new license.

Which brings me to the first thing people tend to forget about copyright: unless otherwise stipulated (like through the inclusion of a LICENSE file) all creative works are copyrighted and cannot be copied, imported, modified, distributed, etc. without the express consent of the copyright holder (usually through a licensing agreement).

So with that in mind, and assuming that you already have the copyright to this code, I'll answer your three questions:

1. Can I just add a license after the fact and it will be valid for all prior work?

This is fun question because it hinges on a silly technicality of software development. If you add a license to your repo today, the license applies to the code as of that point in the commit history. There's no official way to say (through the standard of including a file in the repo) that this license applies retroactively, but if you're the sole copyright holder (see notes on this below) of the work in its current state as well as everything that came before (ie. you didn't get PRs from other people thinking they were committing to a project under a proprietary license) then practically speaking, you can apply a Free license to all the old versions because you're the copyright holder -- you can do whatever you want. The problem is a practical one: without a LICENSE file, it's not clear that this software is Free.

Unless you've got a bunch of other people/teams/organisations working off of forks of your current codebase though, it's really just a thought experiment: no one will care because the latest version is Freely licensed. Someone could conceivably fork your repo from an earlier point in history, but without a LICENSE file in that fork, legally speaking that code is solely your property, so copying it would be illegal unless you made a copy for them with a LICENSE file included.

2. Do I have to make sure the license is included in all branches of the repo, or does this not matter? There are for instance a couple of branches that are used to freeze the state of code at a certain time for reproducibility’s sake (I know this could be solved in a better way, but that’s how it is).

There's a lot of overlap here with #1. Basically your old release branches will be copyrighted by you and not licensed Freely. If it's important to you that these releases also be under your new Free license, then yeah, you're going to have to include a new commit on each release branch with your LICENSE file. Personally though, I wouldn't bother. If anyone is using an old release, they'll get the Free version once they upgrade and that's usually good enough for most people.

3. I have myself reused some of the code in my current work for a commercial entity (internal analysis work, only distributed within the organization). Should this influence the type of license I choose? I am considering a GPL-license, but should I go with (what I believe to be) a more permissive license like MIT because of this?

So much of this centres around the current ownership of all code in the repo. If this were a personal project into which no one but you has ever committed any code and for which there's no existing contract stating that your-employer-not-you owns the code, then the answer is really simple: it's your work, you can do whatever you like.

For example, you can write a program, license it under the AGPL3, and post it on GitLab for all the world to see. Strangers from the other side of the planet can download it, modify it, and run it in their own projects so long as they adhere to the AGPL3 license. So long as you don't accept any merge requests from anyone else, you can also re-license the code (or a portion thereof) to a private company (your employer, a contract gig, whatever). Remember, it's your code, you can do with it as you like, so if you choose to give it to a company to build into their proprietary project, there's no problem.

The problem comes once you accept code from someone else. If I submit a merge request to your project that fixes a bug, I do so under the terms of that project's license. My code is AGPL3 because the project's license is AGPL3. You can't now take my bugfix and copy that into a private project because I didn't grant you that right. This is why re-licensing a Free software project, even from GPL-2 to GPL-3 can be really painful: you have to contact each contributor and acquire the right to change the license.

So, TL;DR: if it's 100% your code, you can make 10 copies, all under different licenses. Do whatever you want. If it's 99% your code, you're bound by the license in affect at the time those other contributions were made.

[Source: I'm a Free software nerd with a penchant for copyright, so much so that I married a copyright lawyer so we talk about this stuff a lot.]

6 more...

Can anyone else confirm this? As a long time user and champion of Gitlab, this is a deal-breaker for me.

The URL provided was missing the https:// portion. Here's a working link.

1 more...

Not throwing any shade, just some advice for the future: try to always consider the problem in the context of the OSI model. Specifically, "Layer 3" (network) is always a better strategy for routing/blocking than "Layer 5" (application) if you can do it.

Blocking traffic at the application layer means that the traffic has to be routed through (bandwidth consumption) assembled and processed (CPU cost) before a decision can be made. You should always try to limit the stuff that makes it to layer 5 if you're sure you won't want it.

The trouble with layer 3 routing of course is that you don't have application data there. No host name, no HTTP headers, etc., just packets with a few bits of information:

  • source IP and port
  • destination IP and port
  • A few other firewall-specific bits of information like whether this packet is part of an established connection (syn) etc.

In your case though, you already knew what you didn't want: traffic from a particular IP, and you have that at the network layer.

At that point, you know you can block at layer 3, so the next question is how far up the chain can you block it?

Most self-hosters will just have their machines on the open internet, so their personal firewall is all they've got to work with. It's still better than letting the packets all the way through to your application, but you still have to suffer the cost of dropping each packet. Still, it's good enoughâ„¢ for most.

In your case though, you had setup the added benefit of Cloudflare standing between you and your server, so you could move that decision making step even further away from you, which is pretty great.

2 more...

I was thinking of experimenting with a Firefox extension that upon hitting a YouTube page, it just launches yt-dlp [url] &amp;&amp; mpv [downloaded file]. Is there any interest here in that sort of thing?

4 more...

JetBrains ran aground of this years ago when they introduced a subscription model for their (excellent) software. People (rightly) lost their fricking minds when they heard that if they cancelled their subscription, they'd lose the ability to continue using the software they'd already paid for.

So JetBrains went back and reworked their system so that a cancelled subscription would continue to have the rights to install all the software that existed up to the day of cancellation. Effectively meaning that if v3 came out the day before you cancelled, you can still install and use v3 10 years later.

12 more...

GNOME has one built in. Just hit the "print screen" button and it should appear.

4 more...

I have no idea, but here's a screenshot:

screenshot.

Debian, with a Kubernetes cluster on top running a bunch of Debian & Alpine containers. Never ever Ubuntu.

5 more...

While I generally agree, the OP is asking about an M1, so they're probably considering a used laptop. No profits to Apple, and better for the environment.

This is really disappointing. I had hoped for a lot more representation for the AGPL and GPL.

1 more...

One red flag from that podcast:

When asked how they might deal with abuse of the service to distribute illegal files, he suggested that you could compare uploaded files to hashes of known files. This doesn't make sense in a system where the server has no knowledge of the unencrypted file, since the same file encrypted with two different passwords will result in two different hashes.

3 more...

I'd want to look into where the limitation is.

  • If it's with DNS, you can just set your local resolver to 1.1.1.1 (Cloudflare)
  • If it's on the port, then you can try tunnelling traffic over port 443 to somewhere that simply relays your traffic onward, like a personal server running SSH on port 443.
  • If it's on the IP, blocking access to any IPs not in a whitelist of known WhatsApp IPs, you may be SOL.

I'm not him, just someone sharing his story.

1 more...

I quite like Thunderbird for this.

4 more...

I spent a year of my life writing an extension to it that allowed you to control various streaming services and Kodi with it. When I released it, a bunch of guys in their developer community bitched me out at length because I licenced it under the AGPL and they wanted MIT.

It pretty much killed any interest I had in the product.

Mullvad is looking pretty good. You can even sign up for them through FirefoxVPN and then you're also supporting Mozilla.

Very cool trick. I've never been comfortable with how Python package installation is effectively arbitrary code execution. It's also a nice reminder that installing packages into a Docker environment is generally safer than going bare back metal.

Upon a cursory read, it sounds like you host a server and then relay all of your data through their centrally controlled system all while also pushing your account data to them.

I'm not sure they understand what "federated" means. Or rather, they know, but they're hoping we don't care.