luciferofastora

joined 1 year ago
[–] luciferofastora@lemmy.zip 5 points 1 day ago (2 children)

Thousand Sons*

Also, pretty sure that it comes with a permanent controlling enchantment subjugating them to the next Sorcerer

[–] luciferofastora@lemmy.zip 2 points 1 day ago

Can we have both? A concise textual description and a video exemplifying the features?

[–] luciferofastora@lemmy.zip 2 points 1 day ago

I say we let them hang with us. They're a little confused, but they're adorable enough.

Also, talesfromtechsupport effectively became talesfromtech because just tech support is to small of a niche to sustain a sub with content. Likewise, if we banned all the not-strictly-programming humour, I don't know the community will thrive still. It might drive out both content and viewers, and while it's arguably correct, I don't think it's wise.

I'd rather have it be something vaguely resembling the type of humour programmers tend to have than a little walled-off box with a big sign "NERDS ONLY"

[–] luciferofastora@lemmy.zip 4 points 6 days ago (2 children)

Depends on your metric of value. If someone will pay $1,000 for it, it's worth at least that much to them.

[–] luciferofastora@lemmy.zip 10 points 1 week ago

The quillons are particularly interesting. The way the blade widens as it approaches the base means that the upper set of quillons is basically useless - either you catch whatever weapon you'd be trying to catch at a steep angle so the blade bites and binds, or it slides down, likely skipping right over those quillons.

Widening blades with a narrower part right above the cross-guard aren't uncommon. Typicay that will a Ricasso, a section that isn't sharpened for various reasons. You won't be cutting that close to the hilt anyway, so why bother? Occasionally it is also used to put your index finger over the cross-guard for greater control (particularly with later swords that got an extended guard, like a typical rapier).

But crucially, those swords all feature cross-guards either straight or curved forward, not backward, which - continuing the "weapon slides down my blade" scenario from above - will do a great job at not catching said weapon and instead letting it slide past your guard. Hopefully, it'll swing past you as well, but I wouldn't bet my life on it. Simultaneously, as the meme describes, the decorations and shape of the guard make it harder to put your hand all the forward for better control, let alone putting your index finger over the guard to at least attempt to justify those second quillons.

Add the material distribution putting the center of balance way forward and you've got a slab of metal that's very hard to control, if you can wield it at all.

Honestly, I don't think getting your sword caught in a thrust will be a problem. You'd have a hard time thrusting in the first place. If you can get it lined up to thrust at all without skewing your aim because your hand is a nautical mile away from the center of balance, you'd still have to contend with getting a fairly broad point into the target. If your aim is off though, or the target moves, chances are the alignment of the blade (particularly the center of balance) won't match the direction of your force and reduce its effect.

Before your blade even has a chance to get caught, you'll probably sprain your wrist.

[–] luciferofastora@lemmy.zip 1 points 1 week ago

I stuck with the ~mozillateam PPA for quite a while, regularly trying the snap and reporting bugs to Mozilla

Mad respect. I wouldn't have had that amount of time or patience due to personal circumstances, nor the ideological drive to see it work well, but it is people like you that compensate for those of us that can't or don't want to contribute to that same extent. All other preferences aside, I appreciate that contribution to a better ecosystem.

The alternative (not providing a Firefox deb in their repos any more, resulting in users with the firefox deb suddenly being abandoned) is a whole lot worse.

You're right, that would have been the worst "solution" - none at all.

What you're suggesting is, IMO, a move that simply confuses new users. "Firefox updates automatically. Why is it suddenly asking if this update is okay? clicks no, has an unmaintained Firefox"

Between my experiences with supporting users and corporate lingo, I don't think so. Provide a concise, maybe slightly propagandised ad about how snap is better and more secure, then provide the users with a highlighted button "Yes, I want to continue automatic security updates" and a subdued "No, I want to maintain it myself" along with a help pop-up for a slightly more technical "What's the difference".

Most casual users I know that just want things to work - myself included, in some cases - will just skim it, see the appealing buzzwords, click "Yeah whatever, I don't care". The more technical ones would probably google it, read the ensuing arguments and recommendations, and either decide like you did to give it a shot or end up responsible for their own thing (which is both the liberty and the jeopardy of Linux in general: you can do your own thing, but if it breaks, that's on you).

A Pin-Priority of 1 would have been the "correct" way to do it IMO, as that blocks automatic installation as a dependency, but still allows automatic upgrades if the user manually installs the package. But instead, Linux Mint took a hostile approach of choosing a negative number, which actually tells apt to remove the package even if the user has manually installed it. This is overriding user choice in a way that neither Ubuntu nor KDE Neon did.

I wasn't aware of that detail (given I never cared about snap anyway, I never would have run into the issue). Paired with the unwillingness to remedy resulting problems, that is indeed a shitty move. I'd consider it on par with suddenly replacing my firefox with a version that worked very poorly*, which also caused me confusion and frustration, but unlike the firefox case, I don't see any graceful way of handling that transition in a user friendly manner.

*It just occurred to me that some of the issues may have been exacerbated by running on an HDD as opposed to an SSD. Prior to tossing Windows entirely, my SSD held my Win7 installation, while Ubuntu got its own partition on the HDD. I never migrated it to the SSD, instead using its limited 256GB to hold whatever games I was playing at the time.

Re: Linux Mint hostility, apathy about resulting problems, misinformation, paternalism

Those are all good points.

Being hardliners about their philosophy is a common phenomenon in the Linux sphere. While I agree that it's not particularly user-friendly (and generally value open debate), I also feel that a distributor is within their rights to do what they feel is right rather than caving to users. Conversely, that's a philosophy I wouldn't want to endorse either.

The charge of paternalism is one I would level at Canonical too, given the concerns I expressed about pushing towards a monolithic, corporate controlled system. Good intentions notwithstanding, I worry it may pave the path to hell. They're more subtle about it, but that's no more of a redeeming quality to me than MS slowly creeping in new bullshit. (I'd gladly be wrong about that, of course - even if I may not want to use it, options are a good thing.)

But misinformation is an problem and I concede that I may well have fallen prey to it myself. I did try to search for info about open source options like what you mention, but my results and interpretations may have been biased, and I didn't spend enough time for a comprehensive understanding. I could make excuses, but that won't change the fact of my error.

I'm just elaborating on the one thing since you didn't seem to get why it's a problem.

I didn't. Thank you for taking the time.

There were bugs about a decade ago about unattended upgrades not obeying pins correctly, but those were bugs and, AFAIK, have long since been resolved.

It can't have been more than a few years ago, given that the snap move happened with 22.04 which released about 2.5y ago and I encountered that error. But I was, for all intents and purposes, a noob, so I can't exclude the possibility of user error. I'll take your word that this no longer happens.

nix, immutable distros / building blocks, Android comparison

I've never tried either nix or immutable distros. The idea of an immutable base, vetted for compatibility issues between what you refer to as the "building blocks", seems appealing from a "I don't want to worry about the details" perspective for casual use.

Android is convenient for another reason where I'm not sure how relevant it is to our context. It offers a unified version with a common set of features and interfaces, allowing app development relying on that version.

Exchangeable blocks can introduce complication in the same way that, for an example I'm familiar with, node package dependencies will feature a whole set of "at least this version" or occasionally "exactly this (major) version" specifications to ensure the individual parts all meet the requirements.

It's a tradeoff between modularity and reliability, as I see it, and both have their merits. I do tend to favour modularity, which is why I do appreciate the concept of snap as I have now come to understand it. Like I said, my misgivings are with Canonical more than the technology itself.

I've enjoyed this conversation with you, because we're each giving opinions and learning from each other. [...] It was, to be entirely honest, entirely different from the type of conversation I was expecting coming into this thread, which began as yet another piling on and telling people not to use snaps specifically because of factoids that are misinformation. Thanks for the very good conversation instead!

Likewise. I'm no fan of the adversarial nature of many conversations in the tech sphere either. Progress thrives on creativity, if tempered by skepticism and scrutiny. If we're willing to share perspectives, we can catch each other's blind spots. And if it comes down to personal opinions in the end, at least we can form those consciously and part ways a little wiser than before.

I'd be curious to hear about your other misgivings some time, but this conversation has been going on a while now and I may not have much time to read or respond the next few days. In any event, thanks for taking the time!

[–] luciferofastora@lemmy.zip 3 points 1 week ago

I don't think you trust

[–] luciferofastora@lemmy.zip 1 points 1 week ago (2 children)

For me the Linux Mint developers' hostility to snaps (which in my experience tend to be the best trade-offs for my needs) is one of the many reasons I won't use or suggest Mint.

I mean, analogous to firefox example you supplied, you could just delete nosnap.pref and be on your way.

Also, snapd keeps a snapshot of your per-revision configuration from an app for a while after you remove it. You can run snap saved to see all the current snapshots. It doesn't remove your $SNAP_USER_COMMON directory for that snap (which is where the Firefox snap stores its profiles), so moving from the snapped Firefox to the version from apt is just a matter of moving the .mozilla directory out of ~/snap/firefox/common to ~/

I could have sworn I checked that, but I was a lot less familiar with these things at the time, so maybe I missed it.


I don't think snaps are a bad thing on principle, my own bad experiences with them notwithstanding. I could also live with a for-profit operating its own curated package repository as part of its service. I'd personally prefer not to use a client locked into one particular package provider, but if that's the tradeoff for that provider's security guarantee that your packages are all Canonical-certified safe, I'd accept that. If it were preinstalled with an OS, that's fine. If they make it the default Software Store, we're on par with the Microsoft Store and other App Stores and those too provide a utility and convenience, particularly for those less technically minded. The ship on "don't bundle your browser with your OS because that's monopoly grabbing" has sailed long ago anyway.

All of these are things I'm fine with, even if I personally would choose not to use them. If that was all, I'd still recommend Ubuntu as a beginner distro, because it was my intro to Linux too and I found it good at the time.

The thing that irks me is when they're being dishonest about it. You no longer wanna support a deb package in your repos? Fine, let me know, offer me a one-click migration option for installing the snap instead and moving my data over, give me the whole marketing routine of telling me how much better your new solution is, but make it my choice.

Having a transition package for a name change or breaking up a larger project into modular packages is one thing. Using it to instead run an entirely different package manager pulling from a proprietary repo?

Worse still, if you had trouble with one app so you went and found a non-snap repo, you pinned it with higher priority, reinstalled it from the new source and thought you were in the clear because that worked as expected.
But you forgot or didn't know to also put a negative priority on the snap source because pin priorities seem intuitive enough, only for unattended upgrades to look at the pins and say "That sign can't stop me, because I can't read" (pins from repos I don't know) and reinstall the snap...
I get that automatic upgrades don't pull from all repos by default for security reasons, but at least look at the priorities and realise "Ope, not gonna touch that, I'll notify the user to do it manually if they trust the update".

And that, for me, is the part that takes it from apathy to disdain; the part that goes beyond "each distro has its own preferences, no big deal"; the part that reeks of a profit-oriented company aiming for vendor lock-in.

To close the topic out: All of this is just explaining my stance; I'm not telling anyone what to do or not to do. You gave your point, I gave mine. By all means, if it works best for you, I'm not getting in your way. I just wish there was a better option.

[–] luciferofastora@lemmy.zip 1 points 1 week ago* (last edited 1 week ago) (4 children)

Thanks for that correction then. I wasn't conscious of that detail.

In any case, the issue remains that, if the vendor's default repositories push for a type of package I don't want, I either have to manually find and vet third party repositories I trust or find someone else to rely on for defaults I'm fine with.

The difference between "I want a different source for a single package, so I'll manually select a different source for that one" and "I don't trust Canonical to select sources I agree with anymore" is one of scale. I'm fine with manually pinning the transitional package, uninstalling it and the snap (hopefully remembering to back up my profile before realising that it also deletes user data) adding a ppa, reinstalling it and reimporting my profiles just for firefox.

But if I feel like I have to fight my distro vendor over not using their preferred package distribution system, it's probably better to jump ship - other vendors have beautiful distros too.

(Also, "you can just use a different source" is part of the reason people prefer not to use snap, where you can't do that)

[–] luciferofastora@lemmy.zip 2 points 1 week ago (6 children)

Correct me there, but wasn't the "select source" thing intended to be about different deb sources?

The issue is that what you expect to be a deb package manager ends up redirecting to snap anyway. It's not a different source, it's a different system. If I have to manually take steps to avoid using the distro vendor's default sources because they just redirect to a system I don't want to use, I might as well look for a different vendor.

And so I did

[–] luciferofastora@lemmy.zip 2 points 1 week ago (8 children)

IIRC, the issue was that - unless you take steps to explicitly prevent it - Ubuntu would occasionally reinstall the snap version. I don't remember the details, been a while since I had to dance that dance, but I recall it being one of the things that put me off snap in particular, Ubuntu in general and sparked my search for a different distro.

I'm now on Nobara, a Fedora-based gaming-oriented distro maintained by GloriousEgroll (who also maintains the popular Proton-GE)

 

My Objective:
Repurpose an obsolete OS Filesystem as pure data storage, removing both the stuff only relevant for the OS and simplifying the directory structure so I don't have to navigate to <mount point>/home/<username>/<Data folders like Videos, Documents etc.>.

I'm tight on money and can't get an additional drive right now, so I'd prefer an in-place solution, if that is feasible. "It's not, just make do with what you have until you can upgrade" is a valid answer.


Technical context:

I've got two disks, one being a (slightly ancient) 2TB HDD with an Ubuntu installation (Ext4), the second a much newer 1TB SSD with a newer Nobara installation. I initially dual-booted them to try if I like Nobara and have the option to go back if it doesn't work out for whatever reason.

I have grown so fond of Nobara that it has become my daily driver (not to mention booting from an SSD is so much faster) and intend to ditch my Ubuntu installation to use the HDD as additional data storage instead. However, I'd prefer not to throw away all the data that's still on there.

I realise the best solution would be to get an additional (larger) drive. I have a spare slot in my case and definitely want to do that at some point, but right now, money is a bit of a constraint, so I'm curious if it's possible and feasible to do so in-place.

Particularly, I have different files are spread across different users because I created a lot of single-purpose-users for stuff like university, private files, gaming, other recreational things that I'd now like to consolidate. As mentioned in the objective, I'd prefer to have, say, one directory /Documents, one /Game Files, one /Videos etc. on the secondary drive, accessible from my primary OS.


Approaches I've thought of:

  1. Manually create the various directories directly in the filesystem root directory of the second drive, move the stuff there, eventually delete the OS files, user configs and such once I'm sure I didn't miss anything
  2. Create a separate /data directory on the second drive so I'm not directly working in the root directory in case that causes issues, create the directories in there instead, then proceed as above
  3. Create a dedicated user on the second OS to ensure it all happens in the user space and have a single home directory with only the stuff I later want to migrate
  4. Give up and wait until I can afford the new drive

Any thoughts?

view more: next ›