• 6 Posts
  • 108 Comments
Joined 2 years ago
Cake day: August 4th, 2023
  • TootSweet@lemmy.worldtoAsklemmy@lemmy.ml•What's the dumbest thing you've done to fix a tech issue?English
    11·
    2 months ago

    Originally posted here, quoted below for convenience:

    Real story.

    I was in my late teens. My parents were dragging me to a tiny, kinda culty church every fuckin’ weekend. Didn’t really have much choice. (Hell, I hadn’t even told anyone yet that I thought Christianity was 100% bullshit.)

    I had a reputation for knowing my stuff about computers. (Because normies – particularly boomer normies like Pastor Dipshit – don’t know the difference between programmers and PC support.)

    So, one Sunday after the service, Pastor Dipshit asks me to look at his computer. His Outlook was giving an error dialog. Something about not being able to find an email on disk. Clicking the “ok” button just resulted immediately in another dialog, and while the error dialog was present you couldn’t interact with the main window, so this rendered Outlook unusable.

    Turns out he’d gone and deleted a bunch of files from the filesystem. Like by navigating from “My Computer” down to the directory where Outlook stored its files. Rather than deleting emails through the Outlook GUI the way one is meant to.

    So, I mused “hmm, I wonder if it’s just giving one error message per email that was affected.” I could see in the window behind the error dialog that the total count of emails in his inbox was only a couple hundred or something.

    So I commenced to clicking as rapidly as I could. Probably about a minute of clicking later, no more error dialogs and Outlook was usable again.

    And everyone marveled at my “genius.”

    I wouldn’t be surprised if he didn’t learn his lesson and continued to delete random files from the filesystem, but he kindof lost what was left of his connection to consensus reality and scared even my culty family away and we quit attending that church not terribly long after that, so I couldn’t say for sure.

  • TootSweet@lemmy.worldtoLinux@lemmy.ml•Tips for getting better at Linux.English
    2·
    4 months ago

    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.

  • TootSweet@lemmy.worldtoLinux@lemmy.ml•Tips for getting better at Linux.English
    1·
    4 months ago

    Yes I am op.

    Ha! That’s what I get for posting on Lemmy at 2:00 am. Lol.

    So I guess I should just skip anything with a desktop environment like manjaro and just figure out how to install bare arch?

    You can certainly start with a bare Arch install and install on top of that a graphical environment. (Without a graphical environment, you wouldn’t be able to run a full-featured browser like Firefox or Chromium or whatever, for instance. I’d think if you intend to use this system as your daily driver – and I’d recommend you do for learning sake – you’ll probably want a graphical environment.) But, yeah. I’d say Arch isn’t that unapproachable to install without going the Manjaro route or the “archinstaller” route.

    With Arch, everything’s just packages. The difference between non-graphical Arch and graphical Arch is just that non-graphical Arch doesn’t have any graphical system packages installed.

    Now, I keep talking about “graphical systems”. There are two ways to go with that. There is X11 which is mature but a bit dated. And there’s Wayland which is the new hotness but support for it is still a bit lacking, so some features like screen grab may not be supported by all programs and some programs won’t work as straightforwardly on Wayland. (Basically, any time a program grabs an image or video of any portion of the screen of your graphical environment, that uses the “screen grab” API. Wayland does that differently than X11, so a lot of programs aren’t updated to use Wayland’s way yet.)

    I guess I’d probably lean toward recommending X11 at this point. I personally use a Wayland compositor (Sway, specifically), but I don’t think running Wayland is going to teach you much that X11 won’t, and running Wayland at this point is likely to introduce frustrating wrinkles. If after you have your Linux “sea legs” you want to try switching, that’s always an option as well.

    As for minimal X11 environments, first off, I’d say avoid things that describe themselves as “desktop environments”. They’re likely to hide details from you. Prefer “window managers.” Tiling window managers tend to be more minimal, but if you want to go with a more draggy-droppy, mouse-driven window manager that feels more like what you’re probably used to (but also doesn’t hide details), I’d recommend IceWM.

    And, finally, as far as a “bare Arch install”, the place to start is the install guide on the Arch Wiki. It goes step-by-step on how to do things. And take the time to understand the commands you’re running as you’re running them. There are a lot of links in the install guide to more in-depth articles. For instance, the “partitioning” section links to an article called “partitions” that goes in depth on what a “partition” even is.

    There’s a lot to learn, but it also pays off. Both in terms of just having the power to do the stuff you want with your own systems and in terms of benefits to your career. And it’s just plain fun!

Moderates