The U.S. has always been bullies, fundamentalists, militant, entitled. All the things you don’t want in an ally. Yes, the U.S. is worse now. (I’m American, by the way.) But I hope U.S. allies have kindof seen this coming and made arrangements to weather this sort of thing, even if it lasts forever. Myabe that was kindof the point of the E.U., for instance.

The U.S. isn’t the only country going off the rails, though. Think of Brexit, for instance. I’m not saying the U.K. government is anywhere near as… quite frankly openly fascist as the U.S.'s is right now, but at least the U.K. isn’t immune. Unfortunately no country is.

Advertising? Even if only word-of-mouth.

It would have to be pretty secretive. But it’s not like there aren’t other services out there that do similar things illegally under cover of anonymity. (Silk Road, anyone?)

I don’t know where you got the idea that the key fob doesn’t transmit a signal when at rest. If you’re talking about keyless ignition with the button on the car (not remote start via key fob) the key fob transmits a response when it gets a request from the car.

The bad guys have a clever trick, though. They put one guy in your car and one guy next to you. The guy at the car hits the ignition button transmits the signal to the other guy, who transmits it to your fob. The second guy then transmits the response from your fob back to the guy in the car, who then sends it to the car. As far as your car knows, the fob is in the car. So it starts. A Faraday cage can protect against this.

Uninstall it and make the world a slightly better place?

“Bots” wasn’t the first thing that came to mind when I considered what the Bitcoin Cash community might be full of, actually.

But, yes. I’d be not even a little surprised if it was full of bots too.

I imagine sabots would do pretty well against graphics cards.

I… doubt it?

I took the liberty of looking in the developer tools as it failed, and there was a 500 response. The connection to Hulu’s servers was all over HTTPS and I didn’t get any certificate warning, so unless my ISP managed to get Hulu’s private key or got with a corrupt registrar willing to issue a valid replacement certificate, no ISP should be able to change response codes on a man-in-the-middle basis or a redirecting-traffic-to-a-hostile-server basis.

And given how many people have reported issues, I doubt it’s specific to any particular ISPs.

Net neutrality being dead is a huge bummer, but I don’t think this can be blamed on that.

I don’t disagree with anything you’re saying here. Yes, even though the pro-Trump folks don’t comprise a majority of Americans, it’s exceedingly concerning that they’re as close to 50% of the U.S. population as they are. I don’t think I said otherwise, though. I also didn’t say anything about whether the anti-Trump majority (if indeed it is a majority) is/isn’t/was/wasn’t/should be/shouldn’t be “silent.”

Were the anti-Trump folks really “silent” before the election? Was there something they weren’t saying that they should have? 'Cuz it’s not like there wasn’t anybody campaigning against him.

the majority of people voted for him

Eh… That’s not quite accurate. Current estimates are that 77,301,997 people voted for Trump, which is less than 50% of the 155,211,283 total votes cast. (But Kamala, the second-most-voted-for candidate got less than that at 75,017,626.)

But only about 64% of those eligible to vote voted.

So, not even half of those who did vote in the 2024 presidential election voted for Trump, let alone those who were eligible to voted, let alone all “people” in the U.S… But the ones who voted for Trump comprised many more than the number of people who voted for any other candidate.

Sources: one and two.

American here.

First, you’re right. About basically all of what you said above.

I think you particularly hit the nail on the head with this:

I’m always thinking “dude, you need to chill” cause literally no one is attacking them and they’re fully secure. But it seems like they’re always searching for a fight or something.

The media here, funded by the big corporations, manufacture tons of FUD (“fear, uncertainty, and doubt.”) Things to be scared of. “They’re putting chemicals in the water that’s turning the frogs” (and by extension, your kids) “gay.” “The ‘woke mafia’ is trying to convert your kids to atheism.” “The Democrats are going to take your guns so they can install a totalitarian one world government without any resistance.” Most of it’s not true at all. Some has a nugget of truth but it’s not actually any threat.

I will say the Republicans are worse about this than the Democrats (the Democrats’ concerns are more legitimate than the Republicans’), but the Democrats are far from immune. Both are living in fantasy worlds.

…until something very bad happens like the second civil war…

Indeed there’s plenty of rhetoric out there pushing the idea that the U.S. is in a civil war. Between the woke antifa (short for “antifascist”) and the fascist conspiracy theorists.

Does it really do any good for the drive to be encrypted if it doesn’t require a password (or Yubikey or retinal scan or other authentication factor) on boot? If you’re just going to put the plaintext key/password on the same drive but in a partition that’s not encrypted, there’s no point encrypting the drive, right?

So maybe “it asks for a password on boot” is more of a “works as intended” thing?

How will I access the encrypted devices after installation? (System Startup) During system startup you will be presented with a passphrase prompt. …

The quote above is from Fedora documentation here

This is your root FS that’s encrypted that we’re talking about, correct?

If you really want an encrypted root but no password on boot and the plaintext decryption password/key on the same drive, there are ways to do it. (It would probably require customizing the initramfs somehow. But it’s Linux, and Linux certainly isn’t going to prevent you from doing such things. Just try to dissuade you.)

If we’re not talking about a root filesystem, that would likely change some things. If it’s Luks, I’m pretty sure it wouldn’t matter particularly where on your filesystem the key was so long as your /etc/crypttab refers to it. I’d say that sort of setup would probably only provide additional security if the encrypted drive is an external drive that you might worry could be stolen or physically accessed when the attacker doesn’t have physical access to your root filesystem.

Also, if you shared what encryption scheme was in use (Luks, Anaconda, etc), that would probably help as well.

Edit: Ah. Ok. You gave more info while I was typing the above response. What you want is unlocking via ssh. For sure.

The GPL family of licenses was designed to cover code specifically. AI engines are code and are covered in most jurisdictions by copyright. (Disclaimer: I know a lot less about international intellectual property law than about U.S. intellectual property law. But I’m pretty confident what I’ll say here is at least true of the U.S…) But you don’t really have a functional generative AI system without weights. And it’s not clear that weights are covered by any particular branch of intellectual property in any particular jurisdiction. (And if they are, it’s not clear that the legal entity who trained the engine owns those rights on those weights rather than the rights holders who hold rights to the materials being used as training data.) It’s the weights that would make for any biases or purposefully nefarious output. Nothing that isn’t covered by intellectually property can meaningfully be said to be “licensed”, really. Under the AGPLv3 or any other license. To speak of something not covered by any intellectual (or non-intellectual, I suppose) property as “licensed” is just kindof nonsensical.

Like, since Einstein’s General Relativity isn’t covered by any intellectual property, it’s not possible for General Relativity to be “licensed”. Similarly, unless some law is passed making LLM weights covered by, say, copyright law, one can’t speak of those weights being “licensed”.

By the way, there are several high-profile cases of companies like Meta releasing LLMs that you can run locally and calling them “Open Source” when there’s nothing “Open Source” about them. As in, they don’t distribute the source code of LLaMa at all. That’s exactly the opposite of “Open Source” and the weights aren’t code and can’t really be said to be “Open Source”. More info here.

Now, all that said, I don’t think there’s actually any inherent benefit to LLMs, AGPLv3 or otherwise, so I don’t have any interest even in AGPLv3 engines. But I’m all for more software being licensed AGPLv3. I just don’t think AGPLv3 is a concept that applies to any portion of LLMs aside from the engine.

Dad² joke

This seems like not the right community for this post, but I appreciate the sentiment.

Great article and just as relevant today. Probably more so, honestly.

Even in the software engineering profession, there’s a lot of that kind of illiteracy going on. Not to the extent of thinking their computer is off because the monitor is off. But for instance:

• Not thinking to narrow down the problem they’re having to whether it’s a problem with their build script(s) or a problem with their IDE. (“It’s got red squigglies” means it won’t build, right? If I had a nickel for every time a developer on my team came to me with red squigglies saying they’d tried X, Y, and Z changes to the build script without even trying to run a build from the terminal to see if that worked (and when they did try that at my suggestion, it did build just fine), I’d’ve invested in a piggy bank by now.)
• Writing/modifying code, but just having no idea (or desire to have any idea) how to start an application from scratch, tweak any of the code/processes that deploy the application (let alone build new processes for deploying), troubleshoot at least some issues with dependencies/libraries (for instance, by consulting the source code of FOSS dependencies), etc.
• Spending hours writing a web app in Java or whatever to do some simple thing that would be a 30-second Bash one-liner. (Or 10-minute Bash one-liner including learning curve.) Just because they don’t think it’s… feasible?.. to learn how to write, say, a for loop in Bash.
• Writing/maintaining the back end of web apps daily but having zero understanding of the HTTP protocol or JS.

And of course, this isn’t everyone. And I don’t expect anyone who has just finished their college degree to show up to their first day of work knowing how to generate their own certificate authority using OpenSSL on the command line in less than 5 minutes, fully understanding every step of the process. But the above examples are all pretty senior folks. And some folks come straight out of college and pick that sort of stuff up extremely quickly. So, it’s not just about how much experience they have.

Yeah, no. If I want to learn fiction, I’ll watch Battlestar Galactica or something.

Just about everyone looks better when they smile.

You’re the one who brought looks into it.

My favorite pharaoh is Bing Butankhamun.

This is the dadest dad joke.

Great question!

So, first off, if I knew what app(s) specifically you have in mind, that’d help me answer better, but in general:

• First off, I’ll say it’s mostly less that they support pacman than that Arch supports them. There may be some exceptions, but it’s usually Arch developers building the pacman packages rather than the author of the software in question. Even when it’s a proprietary application, it’s usually bundled into a packman package (or at least a PKGBUILD for it lives on AUR, but we’ll get to that) by one of the Arch developers or other volunteers.
• Your first option for software that isn’t in the official Arch repositories is AUR. It’s for packages that aren’t as officially supported as those in the official Arch repositories. Anything in AUR, you’ll have to build the package itself (which usually involves compiling, unless it builds the package from an already-compiled binary), but the process is usually pretty straightforward. (Download and unzip the tarball from AUR somewhere, cd into the directory, and then makepkg -sf && sudo pacman -U <something>.tar.xz. You can also get some helper scripts that do some of those steps for you for convenience. Definitely worth having the experience of doing it manually a few times first, though, I’d say.) Even if the only way to get the software in question from the publisher is in .deb form, you may still find a package on AUR that will unpackage the .deb and package the result up into an Arch package.
• You can run the software in an isolated way. There are snap packages and flatpacks, but… well, there are good reasons why they get a bad rap. Lol. Another option is to build an Ubuntu chroot in which to install the package in there. The cleanest and most straightforward option for running software isolated like this is probably Docker. (Running graphical apps in Docker can definitely be done, though it is a little tricky.)
• You can grab the software in question and install it manually somewhere in your home directory. Somewhere like $HOME/install/<softwarename>. This can work even if the software is only available as a .deb file. You can just extract the .deb without installing it with the command ar x <blah>.deb and a tar -xf data.tar.gz and then put the files from within that .deb file where you want them.
• There are some other options that I’ve never tried (and only learned of just now by googling) that… aren’t recommended. Here’s a link for reference, but to somewhat explain the problems that those approaches there can cause, when you install a package from any particular package manager, the package manager installs dependencies. (Typically those dependencies are shared libraries. Think ".dll"s.) And those dependencies live in specific places. But if, say, you had pacman and apt-get installed on the same system and install the same dependency (including if that dependency is installed automatically as part of installing something else) via both package managers, it’s likely to get one version of the dependency from one package manager and another from the other. Either one package manager is going to error out (“these files already exist in the filesystem, I think something’s wrong that a human should fix”) or overwrite files potentially breaking things. (Now, all that said, I know that pacman is actually in the official Ubuntu repositories and can be installed on Ubuntu alongside apt get. I have to admit I don’t know if and if so how it goes about avoiding problems if both are installed. Maybe it’s not a good idea to install pacman on Ubuntu for the same reason. Who knows!)
• So, there is also the option to write your own PKGBUILD. (A “PKGBUILD” is a script that tells your Arch system how to build a Pacman package. They’re what you download from AUR when you want to build/install something from AUR. A couple of reference links.) It does require doing a little Bash programming, but It’s not as hard as it sounds. (And it’s easier than building Ubuntu packages.) I’ll talk about what to do if you truly can’t get the package in question anyhow except in .deb form. But first, if you can get the source code, you can typically grab a PKGBUILD from the official Arch repositories or from AUR that installs something “similar” to what you’re wanting to install and modify it. (Like, for a simple example, if you’re trying to install something written in C, you can look for a PKGBUILD for something written in C that would probably have similar dependencies.) If you can’t get the source code but can get a compiled distribution of the software in question, you can still write a PKGBUILD, and you’ll probably be able to find some PKGBUILDs to start from that would be pretty similar to what you need.
• If you truly can’t get the software in question except in .deb form and you want to write a PKGBUILD for it, that can be done. It just involves writing a PKGBUILD that extracts the files from the .deb file and then packages them back up into an Arch package. I’ve done this before and I have a funny personal story about that. More info here in an answer to another question in this same Lemmy community.

Just in case it’s useful to you, I’ll share the PKGBUILD I wrote for converting the Ubuntu kernel into an Arch package. It demonstrates how you’d go about extracting files from a .deb file in order to build them into an Arch package.

pkgname='linux-ubuntu'
pkgdesc='The Ubuntu kernel, modules, and headers'
pkgver='5.15.0'
_pkgver="$(cut '-d.' -f 1,2 <<< "${pkgver}")"
_firmware_ver='1.187.29'
_suffix_ver='20.04.2'
pkgrel='25'
arch=('x86_64')
options=('!strip')
url='http://ubuntu.com/'
source=(
    'http://archive.ubuntu.com/ubuntu/pool/main/l/linux-firmware/linux-firmware_'"${_firmware_ver}"'_all.deb'
    'http://archive.ubuntu.com/ubuntu/pool/main/l/linux-hwe-'"${_pkgver}"'/linux-headers-'"${pkgver}"'-'"${pkgrel}"'-generic_'"${pkgver}"'-'"${pkgrel}"'.'"${pkgrel}"'~'"${_suffix_ver}"'_amd64.deb'
    'http://archive.ubuntu.com/ubuntu/pool/main/l/linux-hwe-'"${_pkgver}"'/linux-hwe-'"${_pkgver}"'-headers-'"${pkgver}"'-'"${pkgrel}"'_'"${pkgver}"'-'"${pkgrel}"'.'"${pkgrel}"'~'"${_suffix_ver}"'_all.deb'
    'http://archive.ubuntu.com/ubuntu/pool/main/l/linux-signed-hwe-'"${_pkgver}"'/linux-image-'"${pkgver}"'-'"${pkgrel}"'-generic_'"${pkgver}"'-'"${pkgrel}"'.'"${pkgrel}"'~'"${_suffix_ver}"'_amd64.deb'
    'http://archive.ubuntu.com/ubuntu/pool/main/l/linux-hwe-'"${_pkgver}"'/linux-modules-'"${pkgver}"'-'"${pkgrel}"'-generic_'"${pkgver}"'-'"${pkgrel}"'.'"${pkgrel}"'~'"${_suffix_ver}"'_amd64.deb'
    'http://archive.ubuntu.com/ubuntu/pool/main/l/linux-hwe-'"${_pkgver}"'/linux-modules-extra-'"${pkgver}"'-'"${pkgrel}"'-generic_'"${pkgver}"'-'"${pkgrel}"'.'"${pkgrel}"'~'"${_suffix_ver}"'_amd64.deb'
    'linux.preset'
)
noextract=(
    'linux-firmware_'"${_firmware_ver}"'_all.deb'
    'linux-headers-'"${pkgver}"'-'"${pkgrel}"'-generic_'"${pkgver}"'-'"${pkgrel}"'.'"${pkgrel}"'~'"${_suffix_ver}"'_amd64.deb'
    'linux-hwe-'"${_pkgver}"'-headers-'"${pkgver}"'-'"${pkgrel}"'_'"${pkgver}"'-'"${pkgrel}"'.'"${pkgrel}"'~'"${_suffix_ver}"'_all.deb'
    'linux-image-'"${pkgver}"'-'"${pkgrel}"'-generic_'"${pkgver}"'-'"${pkgrel}"'.'"${pkgrel}"'~'"${_suffix_ver}"'_amd64.deb'
    'linux-modules-'"${pkgver}"'-'"${pkgrel}"'-generic_'"${pkgver}"'-'"${pkgrel}"'.'"${pkgrel}"'~'"${_suffix_ver}"'_amd64.deb'
    'linux-modules-extra-'"${pkgver}"'-'"${pkgrel}"'-generic_'"${pkgver}"'-'"${pkgrel}"'.'"${pkgrel}"'~'"${_suffix_ver}"'_amd64.deb'
)
sha256sums=(
    '22697f12ade7e6d6a2dd9ac956f594a3f5e2697ada3a29916fee465cc83a34a1'
    '595794e8ad28ed130af60e6ec8699313e1935ae70f7530a00b06dff67fb4d40e'
    '22dbdc1895f91d3ad9d4c5b153352f1cc8359291dba6ea1a0e683cc6871b0f58'
    '5705cefab39dd5512bcc515918d09153715c7bb365d6bc29cc9b0580e5723eef'
    '3d207388812e957447162c067fb637b4d06eccb4f303b801e8402046a7d3cf48'
    '2f1214dbb04cb47ce8d096bff969fca9c78c26ec21a395c12922eca43cc18e26'
    '75d7d4b94156b3ba705a72ebbb91e84c8d519acf1faec852a74ade2accc7b0ea'
)

package() {
    for f in "${noextract[@]}" ; do
        ar x "${f}"
        tar -xf "data.tar.xz" -C "${pkgdir}"
    done
    rm -r "${pkgdir}"'/usr/share'
    rm -r "${pkgdir}"'/usr/lib'
    mv "${pkgdir}"'/lib' "${pkgdir}"'/usr'
    install -Dm644 'linux.preset' "${pkgdir}"'/etc/mkinitcpio.d/linux.preset'
}

(I omitted the linux.preset file. It’s just in the same directory with the PKGBUILD and it gets bundled into the Arch package. But it’s not really important for what you’re doing unless you’re trying to install a different kernel than the official Arch kernel on an Arch system.)

The part that extracts the files from the .deb packages is the ar x command and the tar -xf command. The package() function there is what decides exactly what files will be in the Arch package and where. And makepkg builds the package archive after running package().

That covers all the options for installing software not in the Arch repos that I can think of.