avidamoeba

joined 1 year ago
[–] avidamoeba@lemmy.ca 1 points 8 months ago* (last edited 8 months ago) (2 children)

What you lose in space, you gain in redundancy. As long as you're not looking for the absolute least redundant setup, it's not a bad tradeoff. Typically running a large stripe array with a single redundancy disk isn't a great idea. And if you're running mirrors anyway, you don't lose any additional space to redundancy.

[–] avidamoeba@lemmy.ca -1 points 8 months ago* (last edited 8 months ago) (7 children)

Adding new disks to an existing ZFS pool is as easy as figuring out what new redundancy scheme you want, then adding them with that scheme to the pool. E.g. you have an existing pool with a RAIDz1 vdev with 3 4TB disks. You found some cheap recertified disks and want to expand with more redundancy to mitigate the risk. You buy 4 16TB disks, create a RAIDz2 vdev and add that to the existing pool. The pool grows in storage by whatever is the space available from the new vdev. Critically pools are JBODs of vdevs. You can add any number or type of vdevs to a pool. The redundancy is done at the vdev level. Thus you can have a pool with a mix of any RAIDzN and/or mirrors. You don't create a new pool and transition to it. You add another vdev with whatever redundancy topology you want to the existing pool and keep writing data to it. You don't even have to offline it. If you add a second RAIDz1 to an existing RAIDz1, you'd get similar redundancy to moving from RAIDz1 to RAIDz2.

Finally if you have some even stranger hardware lying around, you can combine it in appropriately sized volumes via LVM and give that to ZFS, as someone already suggested. I used to have a mirror with one real 8TB disk and one 8TB LVM volume consisting of 1TB, 3TB and 4TB disk. Worked like a charm.

[–] avidamoeba@lemmy.ca 12 points 8 months ago (1 children)

By all means, if it works already, don't fuck with it.

This community hates on Ubuntu but these are the kinds of corner cases that can make or break a new user's journey. Experienced users can resolve those with no emotion and we often discount the difficulty and importance of such issues to less experienced users. There's been a lot of work put in Ubuntu to tackle these kinds of issues - paper cuts. Recall the One Hundred Paper Cuts project. This is why I won't stop recommending Ubuntu LTS for new users.

[–] avidamoeba@lemmy.ca 11 points 8 months ago* (last edited 8 months ago) (3 children)

Being unable to boot from a USB drive in UEFI mode sounds like a Mint problem. I just booted from an Ubuntu LTS USB on a similar machine, installed with all default BIOS. Haven't touched Secure Boot either. No trouble.

[–] avidamoeba@lemmy.ca 2 points 8 months ago

I'd install it alongside and buff the edges. If there's no sources to install it from, or there are problems, I'd kill it and wait till it's better.

[–] avidamoeba@lemmy.ca 5 points 8 months ago* (last edited 8 months ago) (1 children)
top

Because it exists in nearly every environment I might need to check usage. From my desktop, through laptops, lab machines, routers, embedded systems, IoT to cloud, I don't have to keep the muscle memory of more than one app.

[–] avidamoeba@lemmy.ca 1 points 8 months ago* (last edited 8 months ago) (1 children)

Snaps work too if you use Ubuntu and trust Canonical, as he mentions. I'm a bit annoyed at Flatpak for being inferior to Snap in that it can't be used to install system components. Snap allows for a completely snappy system, without the need to build the base OS one way and the user apps another. The OS from-traditional-packages, user-apps-from-Flatpaks model is an unfortunate compromise but I guess we're gonna get to live with it long term. It's better than the status quo.

BTW I completely disagree with him that everyone should be using rolling releases. As a software developer, user, and unpaid IT support, this is a mind boggling position.

[–] avidamoeba@lemmy.ca 69 points 8 months ago* (last edited 8 months ago) (9 children)

They better increase quickly. Apple's bank account is large.

[–] avidamoeba@lemmy.ca 3 points 8 months ago* (last edited 8 months ago) (4 children)

No argument. The security aspect is something that seemingly a lot of people in this thread don't get. The some-person-creates-a-package-I-install model works as reliably as it does without sandboxing only when that person is a well known trusted individual or group. For example the Debian maintainers team. It's a well known group of people who are trusted due to their track record to not produce malware-ridden packages intentionally or unintentionally. That is the line of defense you got. If you remove that, you end up in download-random-shit-on-Windows land in regards of security.

What's worse, this extends to the bundled libraries. Unlike central systems with shared libraries like Debian, bundling libraries means that the problem extends to the sources of those libraries! Package A and package B both include libjpeg-v1, it's got a remote exploit gaping hole. Developer A has time to follow CVEs and updates theirs. Developer B doesn't or has moved on. The system gets a patched libjpeg-v1, app A gets it, assuming it can be auto-updated. App B remains open for exploitation.

Therefore given all that, sandboxing is a requirement for safely using packages from random people. Even when the packages from those come from a central source like Flathub or Snap Store. Sandboxing is why this model works without major security incidents on Android.

Anyway, won't be the first bad practice advocated by some in this community.

[–] avidamoeba@lemmy.ca 4 points 8 months ago* (last edited 8 months ago)

Well, theoretically if the developer had bundled the libs they assumed would be present on Ubuntu into the AppImage, maybe it would have worked. Would it be larger? Sure. 😂

[–] avidamoeba@lemmy.ca 3 points 8 months ago (6 children)

I mean, I'm not saying they aren't. I think the original argument is valid. I just think they're better than the alternative, which isn't Flatpak but self-extracting .sh files.

[–] avidamoeba@lemmy.ca 1 points 8 months ago* (last edited 8 months ago)

Check the logs around that time. journalctl is your friend. Meticulously walk over the events from beginning to enter sleep to the wakeup. See where it stops sleeping and what event precedes it.

view more: ‹ prev next ›