|
Paul MaudDib posted:No, AMD added some additional testing that catches the worst of the bunch (chips with poor ASIC quality that segfault almost immediately) and this has reduced the incidence rate, but there are still some new-production chips that have the issue. There are plenty of people in the AMD community thread or on Reddit with 1726 or 1733 chips that segfault (I've seen all combination of 1726, 1733, SUS, and PGT). Dang, I RMA'd a week 15 untested so I wouldn't have to deal with cleaning up thermal paste and had read they were hand testing the replacement(old info now I guess). At least they made the RMA super easy, approved it in a day and I should hopefully be getting a tracking number for the new one soon.
|
#
?
Nov 23, 2017 04:59
|
|
|
|
| # ? Apr 20, 2024 00:15 |
|
|
Obsurveyor posted:Dang, I RMA'd a week 15 untested so I wouldn't have to deal with cleaning up thermal paste and had read they were hand testing the replacement(old info now I guess). At least they made the RMA super easy, approved it in a day and I should hopefully be getting a tracking number for the new one soon. Yeah AMD is just shipping people new chips off the line now, the boxes are no longer getting opened and tested. But the chips off the line actually stand a chance of passing now, whereas before week 25/week 30 they have a near-100% failure rate, so you shouldn't feel bad about getting it replaced. Odds are very good your old CPU had the issue, just be sure to test your replacement too.
|
|
#
?
Nov 23, 2017 05:07
|
|
|
im doing a new build with a 1600 and a gigabyte x370 k5 that i got a screaming deal on at microcenter. The primary use will be gaming. I remember reading about ram speed being pretty important on ryzen. Where does it stop being worth it? Do I pay the extra $20 for 3000 over 2666 or does it not matter enough?
|
|
#
?
Nov 23, 2017 07:33
|
|
|
Fauxtool posted:im doing a new build with a 1600 and a gigabyte x370 k5 that i got a screaming deal on at microcenter. 3200ish is the magical spot where it slows down substantially, the difference between 3200 and 3400 or 3600 absolutely ins't worth the stupid high cost of those kits.
|
|
#
?
Nov 23, 2017 08:04
|
|
|
Methylethylaldehyde posted:3200ish is the magical spot where it slows down substantially, the difference between 3200 and 3400 or 3600 absolutely ins't worth the stupid high cost of those kits. Related question, does the same thing apply to Intel? I already have 16 gb of pretty nice 3200 in my Intel system. If it's not as important there I can move it to my new ryzen build and then buy cheaper lower speed ram to replace it.
|
|
#
?
Nov 23, 2017 09:03
|
|
|
Paul MaudDib posted:Yeah AMD is just shipping people new chips off the line now, the boxes are no longer getting opened and tested. But the chips off the line actually stand a chance of passing now, whereas before week 25/week 30 they have a near-100% failure rate, so you shouldn't feel bad about getting it replaced. Odds are very good your old CPU had the issue, just be sure to test your replacement too. I wonder if the pile of returned ones is getting mixed up with the pile of R5s and that's why we're seeing R5s showing up once in a whilej with 8C/16T. They're actually just repainted segfaulting R7s and when someone gets a segfault they're forced to choose between RMAing it and losing two cores or just not using the thing for compiling eight kernels at once.
|
|
#
?
Nov 23, 2017 09:43
|
|
|
Kazinsal posted:I wonder if the pile of returned ones is getting mixed up with the pile of R5s and that's why we're seeing R5s showing up once in a whilej with 8C/16T. They're actually just repainted segfaulting R7s and when someone gets a segfault they're forced to choose between RMAing it and losing two cores or just not using the thing for compiling eight kernels at once. No, they most certainly go to OEMs, where they get stuffed in consumer prebuilts to minimize the impact the segfault issue has.
|
|
#
?
Nov 23, 2017 09:46
|
|
Fauxtool posted:Related question, does the same thing apply to Intel? I already have 16 gb of pretty nice 3200 in my Intel system. If it's not as important there I can move it to my new ryzen build and then buy cheaper lower speed ram to replace it. There are gains for going up to 3200 on Intel too, but they are much smaller, like ~10% or so in games that do a lot of stream loading, the gains are much larger on Ryzen and they affect a much broader number of applications. Ryzen is more sensitive as far as RAM compatibility goes so before you buy RAM for either system you'll want to test the faster RAM in the Ryzen system and make sure it will actually run at its rated speed there.
|
|
|
#
?
Nov 23, 2017 12:55
|
|
|
https://imgur.com/a/xh2ny
|
|
#
?
Nov 23, 2017 14:57
|
|
|
FaustianQ posted:No, they most certainly go to OEMs, where they get stuffed in consumer prebuilts to minimize the impact the segfault issue has. Erm, do you really think that AMD (or Intel for that matter) could get away with shipping used chips that have been overvolted/overclocked to OEMs?  Regardless, even if AMD was giving OEMs bottom-binned chips that failed validation at the factory, that's still a really dangerous game to be playing. They are only one OS update or application update away from hitting the trigger conditions, and if OEMs have to start replacing whole PCs under warranty they're gonna get pissed. I guess the saving grace is that CPUs without iGPUs are small potatoes, APUs are where the real volume is... I suppose the other angle is, if there was a process error they could have done some failure-lab stuff and then gone back to the fab and had them tweak it a little... but if the fault is in the design itself there's only so much you can do. They obviously haven't been able to eliminate it entirely, so I kinda suspect binning is in play. At least Ryzen+ isn't that far off at this point. (there is a cool video of NVIDIA's failure lab where they discuss some of this stuff) Paul MaudDib fucked around with this message at 18:56 on Nov 23, 2017 |
|
#
?
Nov 23, 2017 18:15
|
|
|
Segfaulting seems to only happen under extreme load, and the overall bin of the chips seems fine regardless of whether it segfaults or not, so rotating them to OEM use in prebuilts where they are least likely to be run at extremes seems a better plan than merely chucking them. I doubt they get thrown back into the consumer mix, and it's not like cutting them down helps since it seems to be an uncore problem as even R3 1200s will segfault. Or maybe AMD could do a charity project with them for good PR.
|
|
#
?
Nov 23, 2017 20:27
|
|
|
Didn't they show that the segfaults happen to Intel too?
|
|
#
?
Nov 23, 2017 22:22
|
|
|
PerrineClostermann posted:Didn't they show that the segfaults happen to Intel too? Nope, that was Phoronix screwing up their test methodology and confusing people. They found a way to "reproduce" the Ryzen segfault bug that had a 100% false positive rate, including on Intel machines, because they were looking at segfaults intentionally triggered by the compilers self-test scripts. The actual segfault-during-compilation problem only happened on Ryzen.
|
|
#
?
Nov 23, 2017 22:31
|
|
|
FaustianQ posted:There has to be a lot going down right now between AMD and Intel right now. Like WTF. If I was intel right now, I'd be looking at AMD and saying "they're not my competition, they're my partner in keeping x86 relevant" The worst AMD can do to Intel is take some market share. OTOH every phone in the world has an ARM chip, and every compsci grad student just bought an nvidia card to run deep learning projects. That's what would frighten me a lot more than AMD.
|
|
#
?
Nov 24, 2017 10:29
|
|
|
repiv posted:Nope, that was Phoronix screwing up their test methodology and confusing people. They found a way to "reproduce" the Ryzen segfault bug that had a 100% false positive rate, including on Intel machines, because they were looking at segfaults intentionally triggered by the compilers self-test scripts. Declaring the segfault bug 'fixed' because AMD gave him a binned replacement wasn't the smartest move either. He's pretty quick to jump to conclusions. Paul MaudDib fucked around with this message at 19:54 on Nov 24, 2017 |
|
#
?
Nov 24, 2017 19:48
|
|
|
Paul MaudDib posted:Declaring the segfault bug 'fixed' because AMD gave him a binned replacement wasn't the smartest move either. He's pretty quick to jump to conclusions. Phoronix is kind of a garbage fire, he loves stirring up drama any time Lennart Poettering farts. The benchmarking is really what redeems that site, but only just because that's often full of flaws and is of questionable use anyway.
|
|
#
?
Nov 24, 2017 23:46
|
|
|
Measly Twerp posted:Phoronix is kind of a garbage fire, he loves stirring up drama any time Lennart Poettering farts. The benchmarking is really what redeems that site, but only just because that's often full of flaws and is of questionable use anyway. Phoronix is the perfect benchmarking/etc site for your stereotypical Linux Uber Alles type PC master race nerd. The benchmarks mean poo poo when comparing to any other platform for myriad reasons so naturally they look really good on Linux systems. Dude knows exactly what he's doing and somehow manages to sustain the site and I guess himself off it.
|
|
#
?
Nov 25, 2017 00:09
|
|
|
Kazinsal posted:Phoronix is the perfect benchmarking/etc site for your stereotypical Linux Uber Alles type PC master race nerd. The benchmarks mean poo poo when comparing to any other platform for myriad reasons so naturally they look really good on Linux systems. Dude knows exactly what he's doing and somehow manages to sustain the site and I guess himself off it. phoronix owns if u want someone else to read the mailing lists for you and paste them into posts with ads on them
|
|
#
?
Nov 25, 2017 00:32
|
|
|
i'm the guy still benchmarking portal 1 at 1080p when an rx580 is pushing close to a thousand frames per second
|
|
#
?
Nov 25, 2017 00:50
|
|
|
Measly Twerp posted:Phoronix is kind of a garbage fire, he loves stirring up drama any time Lennart Poettering farts.
|
|
#
?
Nov 25, 2017 01:25
|
|
|
I mostly just lurk this thread, but the discussions of how they make/produce these chips is pretty awesome once I look up all the terms over my head. I have a question though: what happens (errors?) in manufacturing that would keep a chip from using hyperthreading? I'm assuming when they bin the chips some don't hyperthread well and get binned as 4/4 or whatever instead of 4/8. Darth Llama fucked around with this message at 01:57 on Nov 25, 2017 |
|
#
?
Nov 25, 2017 01:54
|
|
|
Darth Llama posted:I mostly just lurk this thread, but the discussions of how they make/produce these chips is pretty awesome once I look up all the terms over my head. I have a question though: what happens (errors?) in manufacturing that would keep a chip from using hyperthreading? It's just market segmentation, there are no manufacturing defects that would break SMT specifically.
|
|
#
?
Nov 25, 2017 02:34
|
|
|
Combat Pretzel posted:TBH, Poettering is a grade A+ assclown. I've heard this a lot, but to be honest I've not seen it. What I have seen is people absolutely flip the gently caress out at the suggestion that their distro might use some of his software, and then completely fail to justify their reactions. The Phoronix forums are insanely awful. Kazinsal posted:Phoronix is the perfect benchmarking/etc site for your stereotypical Linux Uber Alles type PC master race nerd. The benchmarks mean poo poo when comparing to any other platform for myriad reasons so naturally they look really good on Linux systems. Dude knows exactly what he's doing and somehow manages to sustain the site and I guess himself off it. The main problem with his benchmarks is the poor control of variables, like just arbitrarily changing anti-aliasing for no good reason making it impossible to compare month to month, year on year.
|
|
#
?
Nov 25, 2017 04:22
|
|
|
Measly Twerp posted:I've heard this a lot, but to be honest I've not seen it. What I have seen is people absolutely flip the gently caress out at the suggestion that their distro might use some of his software, and then completely fail to justify their reactions. The Phoronix forums are insanely awful. My favorite Poettering is his reaction to the time-honored tradition of doing "rm -rf /" and seeing what's left over... and it turns out that since systemd mounts efivars read/write that this will brick your system permanently on some boards (which was also covered by Phoronix). quote:Well, there are tools that actually want to write it. We also expose /dev/sda accessible for root, even though it can be used to hose your system. quote:To make this very clear: we actually write to the EFI fs in systemd. Specifically, when you issue "systemctl reboot --firmware" we'll set the appropriate EFI variable, to ask for booting into the EFI firmware setup. And because we need it writable we'll mount it writable for that. I mean, it's not like there are already safety flags like --no-preserve-root or bless commands... if I write direct to a /dev/sda it could trash my installation... therefore I should be smart enough to avoid bricking my whole system and you should be too! Not to mention the sycophant kernel hacker, whose perspective happens to be the exact same: https://twitter.com/mjg59/status/693496443395399680 Well, hypothetically I can write a program which disables all the safeties in 20 lines... or hypothetically I could write directly to /dev/sda and trash your installation... therefore it's OK for an innocuous one-line command to perma-brick your whole system! This poo poo is the problem with Poettering. It's not that his code is bad, it's not even that his approach is bad... but he has very little perspective for the people who don't have a bootloader-level perspective of the whole system - and to be frank even less respect for their perspective. You can't obey the principle of least surprise if you aren't capable of understanding what "surprising" might be. Anyone remember what Linus' mantra is? Oh right: we never break userspace. Absolute respect for the users from the kernel team, it does what you expect, or at the absolute minimum what it did 10 years ago when you wrote your poo poo. What would Linus say about something that ran fine three years ago but perma-bricks your motherboard today? I'm going to bet that it would start with "REEEEEEEEE" and end with "EEEEEEEEE" and have someone being banned from ever contributing to kernel in between. Paul MaudDib fucked around with this message at 04:58 on Nov 25, 2017 |
|
#
?
Nov 25, 2017 04:34
|
|
|
Darth Llama posted:I mostly just lurk this thread, but the discussions of how they make/produce these chips is pretty awesome once I look up all the terms over my head. I have a question though: what happens (errors?) in manufacturing that would keep a chip from using hyperthreading? All of the AMD/Intel consumer chips practically have the same marginal costs to make. Enabling HT or not is entirely market segmentation aka Economics 101, since selling only HT enabled chips at the same or lower price is leaving money on the table.
|
|
#
?
Nov 25, 2017 04:42
|
|
|
Paul MaudDib posted:My favorite Poettering is his reaction to the time-honored tradition of doing "rm -rf /" and seeing what's left over... and it turns out that since systemd mounts efivars read/write that this will brick your system permanently on some boards (which was also covered by Phoronix). That's one hell of an odd issue, it seems to be a fundamental issue with how everything is a file that anything can modify in Linux. Wouldn't a more appropriate fix to be running SELinux or similar to prevent unwanted modification of these files? Unfortunately it seems it would have to fall to specific distros to configure their system by default to protect those files. Which makes sense as some distros are more user friendly and others intentionally less so. It seems odd to put this on Poettering when systemd is actually behaving as expected, and any other program that needs to mount that same resource read/write would trigger the same issue. I strongly suspect that if Poettering was not involved next to nobody would care about this.
|
|
#
?
Nov 25, 2017 05:17
|
|
|
Measly Twerp posted:That's one hell of an odd issue, it seems to be a fundamental issue with how everything is a file that anything can modify in Linux. Wouldn't a more appropriate fix to be running SELinux or similar to prevent unwanted modification of these files? Given the response, I don't think you can put it on anyone except Poettering that systemd mounts efivars read-write by default, and he refuses to alter that or have a "bless" call for processes that should be trusted not to trash the efivars and brick your motherboard. Mostly people were against that except for him. Even if it were the decision of a lieutenant (it wasn't) this would still be the thing that Linus would stomp someone flat over. Because conceptually most people would expect there to be a difference between "I want to edit /etc" and "I want to brick my motherboard" level privileges, and they certainly wouldn't expect that something that was fine to run last year as a class assignment would brick your hardware today, and that's the thing you should put your foot down on as a project leader, then grind hard. Not everything in Linux is actually a file, that's just an ideal. Stuff that's actually problematic or dangerous are not actually files, or need a "--im-being-stupid-please-do-it-anyway" flag to do the thing. Again, like "rm -rf /" and the "--no-preserve-root" flag. People should be isolated from the footgun as a general principle, unless directly requested beyond any shadow of a doubt. I guess that's back to being a novel argument? Paul MaudDib fucked around with this message at 05:48 on Nov 25, 2017 |
|
#
?
Nov 25, 2017 05:24
|
|
|
Paul MaudDib posted:Given the response, I don't think you can put it on anyone except Poettering that systemd mounts efivars read-write by default, and he refuses to alter that or have a "bless" call for processes that should be trusted not to trash the efivars and brick your motherboard. Mostly people were against that except for him. Even if it were the decision of a lieutenant (it wasn't) this would still be the thing that Linus would stomp someone flat over. Because conceptually most people would expect there to be a difference between "I want to edit /etc" and "I want to brick my motherboard" level privileges, and they certainly wouldn't expect that something that was fine to run last year as a class assignment would brick your hardware today, and that's the thing you should put your foot down on as a project leader, then grind hard. The difference here is that those files need to be writable for the system to work (userland programs that need to write to them). Now, which ones are critical and which ones can be safely removed if need be, that's another problem and unfortunately that's not a systemd problem. It should be an UEFI problem and after that a kernel problem. On this one I agree with Leonard, there's nothing for systemd to do here.
|
|
#
?
Nov 25, 2017 05:58
|
|
|
Volguus posted:The difference here is that those files need to be writable for the system to work (userland programs that need to write to them). Now, which ones are critical and which ones can be safely removed if need be, that's another problem and unfortunately that's not a systemd problem. It should be an UEFI problem and after that a kernel problem. On this one I agree with Leonard, there's nothing for systemd to do here. How much are userland programs writing to efivars nowadays? I guess shutdown needs to, but like that's probably systemd already, so what else? The idea that this is not a whitelist/bless/enumerable amount is actually explicitly concerning in and of itself. And if this is just SPI flashmem, the memory itself may wear out under this load at some point...
|
|
#
?
Nov 25, 2017 06:19
|
|
|
Paul MaudDib posted:How much are userland programs writing to efivars nowadays? I guess shutdown needs to, but like that's probably systemd already, so what else? The idea that this is not a whitelist/bless/enumerable amount is actually explicitly concerning in and of itself. The idea that linux is not standardized is explicitly concerning in and of itself. Microsoft solved that problem by saying "my way or the highway" to everyone else. The attempt to standardize some parts of a linux system is being met with extreme resistance (Leonard and some of the other members of the team being idiots doesn't help) . So, who is writing to efivars? Everyone. And gently caress you for even thinking that I need to specifically whitelist my bash script before writing there. And how would I even know that is a bash script writing there and not plain old cat? Or echo? Or ... 1 million other ways/programs to write to files? Whitelist everyone? Then what's the gain? Are you really really sure that you will have cat and echo on a linux system? And, by the way, that particular cat and echo (shasum or something to check) and not a custom compiled one? The thing is, standardization helps in a lot of ways, hurts in a few others. So far, any program written for linux (not to mention the wider *NIX) cannot make any assumptions on the underlying tools, capabilities or .. anything else really, except the kernel. Distributions however, can. And they can configure the tools that they ship with (selinux?) to protect the user from dumb mistakes. But that's on the distros, not on the program.
|
|
#
?
Nov 25, 2017 06:33
|
|
|
Volguus posted:The idea that linux is not standardized is explicitly concerning in and of itself. Microsoft solved that problem by saying "my way or the highway" to everyone else. The attempt to standardize some parts of a linux system is being met with extreme resistance (Leonard and some of the other members of the team being idiots doesn't help) . So, who is writing to efivars? Everyone. And gently caress you for even thinking that I need to specifically whitelist my bash script before writing there. And how would I even know that is a bash script writing there and not plain old cat? Or echo? Or ... 1 million other ways/programs to write to files? Whitelist everyone? Then what's the gain? Are you really really sure that you will have cat and echo on a linux system? And, by the way, that particular cat and echo (shasum or something to check) and not a custom compiled one? No really, don't give me handwavey bullshit about Microsoft, I am asking a specific question: what userland programs actually write to efivars during normal operation? This is actually concerning to me 
Paul MaudDib fucked around with this message at 06:40 on Nov 25, 2017 |
|
#
?
Nov 25, 2017 06:34
|
|
|
Paul MaudDib posted:No really, don't give me handwavey bullshit, I am asking a specific question: what non-trivial userland programs actually write to efivars during normal operation? This is actually concerning to me On my fedora installation i can see this: efibootdump efibootmgr efikeygen efisiglist efivar I presume there can be many others, past or future. Why is this concerning? I see it as normal. I used the boot one to fix lovely defaults on my UEFI system quite a few times. Any time I would need to mess with the UFEI I would use a program, wouldn't I? The entire point of the 'vars' would be that I could modify and update them from the OS, without the need to reboot and go into the bios.
|
|
#
?
Nov 25, 2017 06:40
|
|
|
Volguus posted:On my fedora installation i can see this: efibootdump efibootmgr efikeygen efisiglist efivar I don't think mounting device firmware r/w into the default filesystem is a very good idea. And I definitely don't think devices should be doing lots of writes to it. Color me old-fashioned. Paul MaudDib fucked around with this message at 06:54 on Nov 25, 2017 |
|
#
?
Nov 25, 2017 06:41
|
|
|
Paul MaudDib posted:I don't think mounting device firmware r/w into the default filesystem is a very good idea. And I definitely don't think devices should be doing lots of writes to it. Color me old-fashioned. But that is the entire point of the interface. Well, kind-of, one being to provide a unified interface to the firmware, second to allow to modify it from the OS. The fact that it appeared as a filesystem on linux is probably more related to the fact that everything is a file (wouldn't it be cool to be able to grep for X) than anything else. But, again, that's not a systemd issue. Not caused by systemd not solvable by systemd. And the "my system is bricked" problem was solved at the kernel level, where it should be, not in the userland.
|
|
#
?
Nov 25, 2017 06:55
|
|
|
Volguus posted:But that is the entire point of the interface. Well, kind-of, one being to provide a unified interface to the firmware, second to allow to modify it from the OS. The fact that it appeared as a filesystem on linux is probably more related to the fact that everything is a file (wouldn't it be cool to be able to grep for X) than anything else. But, again, that's not a systemd issue. Not caused by systemd not solvable by systemd. And the "my system is bricked" problem was solved at the kernel level, where it should be, not in the userland. Everything is a file is (more or less) fine - although not everything trivally maps into being a file. Everything (including device firmware) mounted r/w by default? Or trivially accessible by userspace? That's an accident waiting to happen. Why not mount kernel internals r/w to userspace? Surely accidents are never going to happen, anyone who wants to write to that will know what they're doing. Right? Paul MaudDib fucked around with this message at 10:27 on Nov 25, 2017 |
|
#
?
Nov 25, 2017 10:25
|
|
|
Volguus posted:But that is the entire point of the interface. Well, kind-of, one being to provide a unified interface to the firmware, second to allow to modify it from the OS. The fact that it appeared as a filesystem on linux is probably more related to the fact that everything is a file (wouldn't it be cool to be able to grep for X) than anything else. But, again, that's not a systemd issue. Not caused by systemd not solvable by systemd. And the "my system is bricked" problem was solved at the kernel level, where it should be, not in the userland.
|
|
#
?
Nov 25, 2017 10:26
|
|
|
Again, serious question: are so many programs writing to efivars that this is not actually enumerable? If so, why? Because that's all I'm saying: write a whitelist of poo poo That Actually Needs To Write To The Device Firmware, and maybe add an "efivars-bless" utility or "mount" alias to enable those intrepid hackers, godspeed  but a random one-liner should not be able to brick your system, full stop. Poettering is a  for even suggesting it, even by Linus standards. especially by Linus standards, even.
Paul MaudDib fucked around with this message at 10:37 on Nov 25, 2017 |
|
#
?
Nov 25, 2017 10:31
|
|
|
Yeah instead of using ioctls like windows they mount efivars as rw without access control so any dumbass script can brick the system? Lmao Doesn't ryzen put the EFI / bios on the chip itself like a SoC? Bricking a CPU would be ace
|
|
#
?
Nov 25, 2017 10:35
|
|
|
Sorry, nerds, there's a little hardware news today: https://www.notebookcheck.net/Our-first-Ryzen-5-2500U-benchmarks-are-in-and-Intel-has-every-reason-to-worry.266618.0.html R5 2500U is looking pretty good, close to KBL, KBL-R in benches with less thermal throttling (3% dip on longer tests in the tested Envy x360 15"). The 8CU Vega solution is placing between the 940MX and MX150/GT1030. TDP is looking very good, too. The charts and whatnot are in there, but it makes me rather excited to see what the R5 2700U can do, as well as the R7 models.
|
|
#
?
Nov 25, 2017 17:22
|
|
|
|
| # ? Apr 20, 2024 00:15 |
|
|
Paul MaudDib posted:Again, serious question: are so many programs writing to efivars that this is not actually enumerable? If so, why? They are not written to regularly. Neither are any of the other dozen other things mounted in /sys that are all writable by root. By default that's the limit of file permissions in Linux. Paul MaudDib posted:Because that's all I'm saying: write a whitelist of poo poo That Actually Needs To Write To The Device Firmware, and maybe add an "efivars-bless" utility or "mount" alias to enable those intrepid hackers, godspeed That is the responsibility of the distributions. Not everyone running Linux wants or needs this protection, but using a tool like SELinux you could certainly expect distros like Fedora and RHEL to add this whitelist to protect those files. Paul MaudDib posted:but a random one-liner should not be able to brick your system, full stop. Poettering is a I'm still now sure what you think this has to do with systemd, yes it is the reason that filesystem is mounted, but no, it is not responsible for controlling or protecting that filesystem. Let me be blunt, your reaction to this is exactly the dumb kind of poo poo I've seen over at Phoronix, where every little thing that can be massaged into being Poetterings fault is. It's unfortunate, because I think there could be interesting things to discuss related to this issue. Obviously this isn't the thread for it.
|
|
#
?
Nov 25, 2017 17:55
|
|