I’ll be honest, I have no idea what that is.
I’ll show you mine for reference, so you can guess how hard and expensive it is to replace…
Yes, that’s just a cheap button cell wrapped in plastic with a cable. Sometimes they even skip the “expensive” cable part and are directly clipped onto the board.
The 800M series is first generation Maxwell architecture, if that is your question (basically slightly upgraded processors from the 700 series rebranded for mobile). All but the early 860M which is still Kepler for some reason. Nvidia numbering is weird.
Honestly I have no clue how many EFI implementations actually fail there. Maybe it’s indeed a minor fraction. But I have personally seen two different ones (out of about a dozen -mostly laptops a few years old- systems where I tried it) and that’s enough to consider it a problem. (PS: Probably not conicidently one of those also had a broken SecureBoot implementation that rejected all key changes and only worked with the pre-installed MS ones. Maybe I’m simply good at finding the trashy ones.)
set up a second efi boot partition
This may or may not work. Recognizing a second ESP on the same disk is not required in the EFI standard. So it’s down to your board’s implementation if it works or just stops the moment it finds the first one.
No, you said these videos show common mistakes on purpose because real users would make them. Which is okay…
But it doesn’t matter if it was an honest mistake or one made on purpose because it’s a common thing.
Ignoring the chat telling him the problem (and that he caused it himself) and also not mentioning the problem’s origin anymore later was not an accident. Given the fact that he later made some offhand comment about “yeah, shader thing again” he understood the problem yet intentionally chose to not include the explanation in the video but leave it at “on Linux there are random freezes I don’t understand”.
I would at least pretend to learn from my mistakes. So when I skip the shader compilation, then experience freezes while shaders get loaded and the whole f***ing chat mentions it, letting them compile first and then seeing if that fixes the issue would be in fact the first thing I would try…
So no, this is not honest “showing common mistakes other people will experience” or “struggling with basics”. Because if it was honest there would be any mention of the underlying issue once he understood it. And he obviously did, judging by a later offhand comment about “yeah, shader issues…”
When using the systemd hooks for your initramfs (and using rd.luks.name=<UUID>=<name> instead of cryptdevice=UUID=<UUID>:<name> in the kernel parameters) it will try to decrypt all listed drives with the first password typed in, and only ask for additional passwords if that fails. Unlike the “traditional” busybox hooks that will ask for a password for each device. Doesn’t matter what you actually do with the drives themselves.
So yes, you can for example have partitions/devices /dev/sda1, /dev/sda2, /dev/sdb1 all encrypted with the same password, format sda1 as your classic swap partition, sda2 as the first half of your btrfs raid0 root device and sdb1 as the second half (let’s give them fitting names when decrypting, so /dev/mapper/cryptswap, /dev/mapper/cryptroot-a and /dev/mapper/cryptroot-b), with rd.luks.name=<UUID>=cryptswap rd.luks.name=<UUID>=cryptroot-a rd.luks.name=<UUID>=cryptroot-b in your kernel parameters.
And at boot you will be asked for the password only once, which will unlock all three encrypted partitions. (Unless you mistype. Then it will fall back to the default behavior of asking for 3 passwords, one for each.)
(PS: You can also just unlock other encrypted devices via /etc/crypttab later in the boot process. That’s the much easier option and should be prefered unless you really need them early… as in they are your (or part of your) root device, swap etc.)
The actual real question if you don’t want to figure out everything manually is which options the installer supports.
Your best options when you are already doing a fresh new install:
But that’s not related to BTRFS at all and can be done with any file system
If you can do this is mostly depending on the specific installer (I would assume only the first option works by default…). It’s definitely possible in general but “I’m not technical enough” doesn’t go well with all the details you have to figure out yourself when the installer doesn’t do all the work.
If they have the same password you can just unlog them at boot with one password. They SystemD hook for unlocking LUKS drives automatically tries the first provided password on all encrypted drives it’s supposed to unlock. Only if that fails it will ask for additional passwords.
No, I just reject the notion that the ongoing discussion about AI use in software production is a moral/ethical one. That’s a bullshit narrative to actually discredit all the good reasons against AI by making up a mostly fictional “but it’s just ideology”-argument.
Yes actions include moral choices. But actions that are stupid and make no sense at all don’t need to be discussed in terms of is it ethically okay to do it, because that’s not the interesting point there.
I won’t discuss about the moral choice of hitting my thumb with a hammer, even less to when I tried hammering in a screw like a moron. So I will also not discuss imaginary topics of ethical use of AI in coding. Because it’s bullshit. It produces low quality slob. It’s a scam trying to tell people with no clue about programmning that they can totally do it, too, while trying to gas-light programmers into believing that they really, really need to use that tool for coding or be left behind. Using AI for coding because you already used it for debugging tasks is not an ethical discussion. Just like using a hammer for a screw because you already hammered in nails is not one. It’s a discussion about what AI CAN do and what it CAN’T. Discussions if you SHOULD use AI for a specific task have to happen AFTER you determined if it makes sense first place. And to return the hammer analogy a third time (it’s a magic number after all…): If someone would try to argue that we need to discuss the ethics of hammering in a screw because it already worked with a nail, would you agree that all actions have ethical implications that need to be considered or would you dismiss him because the ethical discussion is not relevant. I did the latter in my comment.
Again: If using AI for coding for real world purposes (and I don’t talk about non-technical people building their low quality app here… that’s mostly a gimmick) was viable, sure… use it. Or let’s start an ethics discussion then. That’s fine with me, too.
But don’t pretend that the actual discussion right know, mainly lead by clueless people evaluating a new gimmick with very little understanding of its actual capabilities (and limits) and CEOs willing to believe in any snake oil if it promises to help them get rid of those obnoxious workers demanding pay (it won’t - every actual fact and number tells us that AI is in fact more expensive, even before figuring in the human employees also needed to hold the leash) is one about ethical use in coding. It isn’t. It’s about a discussion between those that use AI for the things it can do and avoid it where it’s useless and those that somehow have found their new religion and saviour and try to make everything about a) those in tech that use AI because they obviously have seen the light and converted and b) those still left in the dark and fighting their new god for made up moral or other reasons.
That’s a fairy tale completely ignoring the third group: technical people that use AI only and exactly where it makes sense. A fairy tale mostly pushed by a few people behind AI development because they already sunk such insane sums into it that they need to believe (and make you believe) that an (human level or more) artificial general intelligence is just around the corner. Just think about it: there people are actually taking about the equivalent of creating new life (new artificial conciousness) to justify their insane investments. And we should talk about the ethical implications of using AI in coding? How is that not a distraction?
Btw… now that I thought about it (and spelled some of it out) I want to walk back to my earlier statement. If AI is actually able to do soon™ what the morons behind it are proposing, that’s indeed the moment to start an ethics discussion. A very complicated one about definitions of conciousness and life… good thing that this will not actually happen.
Sorry but no. Contrary to what some activist types want you to believe it’s not about actual ethical use when we are talking about software.
It’s about LLMs being a tool that should be used where it’s the proper and efficient tool for the job (see: here) and that should definitely not be used where it isn’t the proper tool (vibe coded bullshit) just because some PR guy told you that this tool is your shiny new hammer and everything is a nail now.
When LLMs can produce proper reviewable code use them ffs… alas, they can’t in any case complex enough to actually justify their use.
I don’t know if Fedora (or plasma) do things differently but the normal default is that you need sudo to reboot/shutdown/etc.
Then on basically all distros using systemd this behavior is modified via logind session and polkit. So the first thing to look at would be if a shutdown rule exists in /etc/polkit-1/rules.d/ that allow users in a certain group to shutdown/reboot in the first place.
Mine looks like this:
/etc/polkit-1/rules.d/50-shutdown.rules
polkit.addRule(function(action, subject) {
if ((action.id == "shutdown" ||
action.id == "reboot") &&
subject.isInGroup("wheel"))
{
return polkit.Result.YES;
}
});
So every user in the wheel group can do it without password prompt. Without this UI elements for shutdown/reboot will try assuming they have the right but simply fail.
Arch
7.1.6
“the past few days”
Those 3 don’t go together…
Edit: Oh, wow… Scrap that.
I completely missed that the main kernel is still stuck on 7.1.6 as even the RealTime one usually lagging behind is on 7.1.8 already.
That being said I have seen comments about fixes to AMD GPUs in 7.1.8. So how about testing it with that kernel?
It is in fact.
With some added “let’s introduce AI for thew workload” nonsense mixed in.
Hating Arch is performative work for memes, so nothing you will find in comment sections… 😆
None of those graph ever are. Because Linux users are more prone to tinkering, keeping stuff private and blocking a lot of bullshit scripting, there is big dark area of Linux systems listing themselves as something else (usually Windows because of those asshole websites not playing well with Linux by design without an actual valid reason other than “we don’t like Linux”).
(PS: For the same reason a lot of sites believe I’m using Chrome. I don’t but I know they like to fuck with me when they see that Firefox user agent.)
Seriously… there will never be a wide-spread year of the Linux desktop. Because that would require lobbying and investments to get devices with pre-installed Linux by default to the clueless majority that doesn’t actually know what an OS is anyway.
And once a Linux distro goes commercial to fill that requirement it is incentivised to implement all the usual crap and enshittification that are missing in Linux normally.
Thing is you can often debunk any of these graphs for the same reason. Just a minority of Linux systems actually show up as Linux as the users are usually more inclined to block a lot of stuff for privacy reasons, then often also changing the user agent most tests fall back to.
Those headlines were the usual “mention (seemingly) big numbers without context”-bullshit. You can easily look up the actual amount of packages in the AUR…
They also did not “inject malicious code into AUR packages” because of some insecurity that needed fixing. They simply took over orphaned packages then modified them.
So actual reality boils down to:malicious actors took over a miniscule amount of AUR packages with so little public interest nobody even maintained them. And the AUR is as secure as it ever was. Which means not very secure at all because it’s public community content without any vetting. So look up the package and actually read the PKGFILE. Just as Arch is vocally warning you.
99.9% of changes are version numbering, checksum and rarely slight dependency changes. There is no chance anyone affected by a long orphaned package that got taken over and modified did ever read that one stupid file of just a few lines (or just the dif provided by several AUR helpers automatically).
I know Lemmy is very anti-AI
No, Lemmy isn’t very anti-AI, just very sane.
AI is a tool. If it does the job better than other tools that’s totally okay. It has so much potential to improve lives.
If on the other hand it’s about artificial general intelligence soon™ hallucinations, “we can totally replace all skilled workers”-fairy tales and other “stop using your brains and eat the slob”-bullshit it just needs to die… alongside the company CEOs snake oil buyers who (not so secretly anymore) dream about getting rid of all those pesky workers they have to pay proper wages.
And sadly 99% of the narratives we are constantly fed (and yes, that includes such “See Linus now supports AI! AI’s winning!!” bullshit stories, when it would be the perfect starting point to actually evaluate AI properly just once…) belong to the second category. Because AI companies in their insanity painted themselves into a corner. Their investments are insane, their market models unsustainable and telling the lie that everyone needs to use their AI and get integrated everywhere-even if it makes zero sense- is basically their only way to salvage something from that shitshow.
!iso8601@lemmy.sdf.org 👍