-
Posts
39 -
Joined
Reputation Activity
-
Boo Berry got a reaction from asus killer in Private Internet Access (Pre-Roll Landing Page)
Considering PIA is based in the US and within the "fourteen eyes" ... no thanks!
-
Boo Berry got a reaction from MaxFubar in Rough day on the graphics card hunt.
Miners are only part of the problem, the other (main) problem is the memory shortage, which affects the vendor's ability to manufacturer new GPUs to keep up with the demand.
I'd like to get a couple RX 580s or a Vega 56 right now, but don't think that'll happen anytime soon. =P
-
Boo Berry got a reaction from BluJay614 in Rough day on the graphics card hunt.
Miners are only part of the problem, the other (main) problem is the memory shortage, which affects the vendor's ability to manufacturer new GPUs to keep up with the demand.
I'd like to get a couple RX 580s or a Vega 56 right now, but don't think that'll happen anytime soon. =P
-
Boo Berry got a reaction from Sabir in Modi 2 Uber and Magni 3 or Sound BlasterX AE-5?
No, I don't believe the Schiit DACs (e.g. the Modi) don't support 5.1 or 7.1 however the Magni (attached to a DAC/sound card that does support 5.1/7.1) *may* be able to output multichannel audio via headphones, not sure as it's kinda vague/unknown there. Also the Modi 2 Uber (which I have) only supports up to 32-bit/192 kHz unlike the Sound BlasterX AE-5. But, there's barely any "hi-res" music downloads out there above 24-bit/192 kHz anyways, much less 32-bit/384 kHz (which I've NEVER seen for sale anywhere). IMO, sample rates that high are pointless anyways... and honestly, so is anything above 48 kHz but I can live with 88.2 kHz, 96 kHz or 192 kHz depending on the source of the digital downloaded media files.
-
Boo Berry got a reaction from Sabir in Modi 2 Uber and Magni 3 or Sound BlasterX AE-5?
Modi 2 Uber and Magni 3, hands down, has my vote. I don't deal with internal sound cards anymore.
-
Boo Berry got a reaction from laughingtnt in Win10 and Ubuntu
Oh, I still use GRUB2 for my Linux installs - both actually uses its own GRUB2!
Basically my setup is Clover being the 'main' bootloader so after POST it boots to Clover giving me a selection of the 4 OSes. I then choose an OS and let the OS' bootloader take over and boot that OS. So let's say with Ubuntu it goes from Clover > Ubuntu's GRUB2 with Ubuntu entries > boot to Ubuntu. Yeah, it's two chained bootloaders doing it this way (except with Mac, since Clover is its bootloader), but I don't have to mess with editing stuff except with Clover.
But... I can override that and boot any OS with its own bootloader if I want to during POST. Or I can boot into the UEFI BIOS and change the UEFI boot order if I need to boot another OS (but it's easier to press F11 during POST and choose a bootloader).
-
Boo Berry got a reaction from laughingtnt in Win10 and Ubuntu
In simple terms the two OSes bootloaders clash and override each other.
I have 4 OSes (all UEFI) on this PC (Windows 10, macOS, Arch Linux and Ubuntu) each installed on its own SSD. How do I keep their bootloaders from clashing with each other? When I install or reinstall OSes I simply unplug all of the SSDs/HDDs (except the SSD I'm installing to) so they can't override each other's bootloaders during installation. Then I use a "main" bootloader to boot all of the other OS' bootloaders (Clover, in this case). Works pretty good.
-
Boo Berry got a reaction from Linus Tech Tits in AMD burns Intel with the best Linux Kernel patch ever ensuring that AMD CPU performance is not affected by PTI
For those tl;dr users;
1) PTI is meant to 'fix' Meltdown (AKA variant 3), which ONLY affects Intel's CPUs (and maybe some ARM CPUs and iDevice CPUs). AMD CPUs are not vulnerable to Meltdown.
2) AMD (along with Intel and ARM) CPUs are vulnerable to one of the two variants of Spectre, AKA variant 1 or Spectre 1. AMD can 'fix' this in software - looks like it can't be fixed for Intel in software since the issue is at a hardware level for Intel. Also I've read that AMD is only vulnerable to Spectre 1 on Linux running a non-default kernel setting. This needs to be researched and verified. AMD CPUs are not vulnerable to variant 2 AKA Spectre 2.
3) PTI initially flagged all x86 CPUs are "insecure" as a precaution, until it was pointed out by AMD that they're not vulnerable to Meltdown.
4) AMD submitted a patch exempting AMD CPUs from PTI after it was known they don't need PTI enabled for AMD users (again, not vulnerable to Meltdown). There's no reason to enable PTI for AMD CPUs at the current time.
5) Said patch has been accepted and merged by upstream, so the next releases of the Linux kernel(s) will exempt AMD CPU users from PTI being enabled.
6) Intel CPUs are vulnerable to variant 1 (Spectre 1), variant 2 (Spectre 2) and variant 3 (Meltdown).
I don't see how this is a burn from AMD to Intel? AMD CPUs simply don't need PTI enabled for their CPUs since they're not vulnerable to Meltdown. So why enforce PTI on AMD when it clearly isn't needed?
-
Boo Berry got a reaction from AlTech in AMD burns Intel with the best Linux Kernel patch ever ensuring that AMD CPU performance is not affected by PTI
For those tl;dr users;
1) PTI is meant to 'fix' Meltdown (AKA variant 3), which ONLY affects Intel's CPUs (and maybe some ARM CPUs and iDevice CPUs). AMD CPUs are not vulnerable to Meltdown.
2) AMD (along with Intel and ARM) CPUs are vulnerable to one of the two variants of Spectre, AKA variant 1 or Spectre 1. AMD can 'fix' this in software - looks like it can't be fixed for Intel in software since the issue is at a hardware level for Intel. Also I've read that AMD is only vulnerable to Spectre 1 on Linux running a non-default kernel setting. This needs to be researched and verified. AMD CPUs are not vulnerable to variant 2 AKA Spectre 2.
3) PTI initially flagged all x86 CPUs are "insecure" as a precaution, until it was pointed out by AMD that they're not vulnerable to Meltdown.
4) AMD submitted a patch exempting AMD CPUs from PTI after it was known they don't need PTI enabled for AMD users (again, not vulnerable to Meltdown). There's no reason to enable PTI for AMD CPUs at the current time.
5) Said patch has been accepted and merged by upstream, so the next releases of the Linux kernel(s) will exempt AMD CPU users from PTI being enabled.
6) Intel CPUs are vulnerable to variant 1 (Spectre 1), variant 2 (Spectre 2) and variant 3 (Meltdown).
I don't see how this is a burn from AMD to Intel? AMD CPUs simply don't need PTI enabled for their CPUs since they're not vulnerable to Meltdown. So why enforce PTI on AMD when it clearly isn't needed?
-
Boo Berry got a reaction from rattacko123 in AMD burns Intel with the best Linux Kernel patch ever ensuring that AMD CPU performance is not affected by PTI
For those tl;dr users;
1) PTI is meant to 'fix' Meltdown (AKA variant 3), which ONLY affects Intel's CPUs (and maybe some ARM CPUs and iDevice CPUs). AMD CPUs are not vulnerable to Meltdown.
2) AMD (along with Intel and ARM) CPUs are vulnerable to one of the two variants of Spectre, AKA variant 1 or Spectre 1. AMD can 'fix' this in software - looks like it can't be fixed for Intel in software since the issue is at a hardware level for Intel. Also I've read that AMD is only vulnerable to Spectre 1 on Linux running a non-default kernel setting. This needs to be researched and verified. AMD CPUs are not vulnerable to variant 2 AKA Spectre 2.
3) PTI initially flagged all x86 CPUs are "insecure" as a precaution, until it was pointed out by AMD that they're not vulnerable to Meltdown.
4) AMD submitted a patch exempting AMD CPUs from PTI after it was known they don't need PTI enabled for AMD users (again, not vulnerable to Meltdown). There's no reason to enable PTI for AMD CPUs at the current time.
5) Said patch has been accepted and merged by upstream, so the next releases of the Linux kernel(s) will exempt AMD CPU users from PTI being enabled.
6) Intel CPUs are vulnerable to variant 1 (Spectre 1), variant 2 (Spectre 2) and variant 3 (Meltdown).
I don't see how this is a burn from AMD to Intel? AMD CPUs simply don't need PTI enabled for their CPUs since they're not vulnerable to Meltdown. So why enforce PTI on AMD when it clearly isn't needed?
-
Boo Berry got a reaction from Curufinwe_wins in macOS 10.13.2 already patched the Intel Security bug
If you want to split hairs about it (not like it really matters who had it 'first'), Microsoft had a KPTI in place back in November beginning with the Insider builds (17035).
So yeah, Meltdown has been mitigated in most OSes now. Spectre is the one people should actually worry about, since it can be exploited via Javascript in the web browser (though it's harder to exploit than Meltdown).
-
Boo Berry got a reaction from Red Hardware in AMD burns Intel with the best Linux Kernel patch ever ensuring that AMD CPU performance is not affected by PTI
For those tl;dr users;
1) PTI is meant to 'fix' Meltdown (AKA variant 3), which ONLY affects Intel's CPUs (and maybe some ARM CPUs and iDevice CPUs). AMD CPUs are not vulnerable to Meltdown.
2) AMD (along with Intel and ARM) CPUs are vulnerable to one of the two variants of Spectre, AKA variant 1 or Spectre 1. AMD can 'fix' this in software - looks like it can't be fixed for Intel in software since the issue is at a hardware level for Intel. Also I've read that AMD is only vulnerable to Spectre 1 on Linux running a non-default kernel setting. This needs to be researched and verified. AMD CPUs are not vulnerable to variant 2 AKA Spectre 2.
3) PTI initially flagged all x86 CPUs are "insecure" as a precaution, until it was pointed out by AMD that they're not vulnerable to Meltdown.
4) AMD submitted a patch exempting AMD CPUs from PTI after it was known they don't need PTI enabled for AMD users (again, not vulnerable to Meltdown). There's no reason to enable PTI for AMD CPUs at the current time.
5) Said patch has been accepted and merged by upstream, so the next releases of the Linux kernel(s) will exempt AMD CPU users from PTI being enabled.
6) Intel CPUs are vulnerable to variant 1 (Spectre 1), variant 2 (Spectre 2) and variant 3 (Meltdown).
I don't see how this is a burn from AMD to Intel? AMD CPUs simply don't need PTI enabled for their CPUs since they're not vulnerable to Meltdown. So why enforce PTI on AMD when it clearly isn't needed?
-
Boo Berry got a reaction from leadeater in AMD burns Intel with the best Linux Kernel patch ever ensuring that AMD CPU performance is not affected by PTI
For those tl;dr users;
1) PTI is meant to 'fix' Meltdown (AKA variant 3), which ONLY affects Intel's CPUs (and maybe some ARM CPUs and iDevice CPUs). AMD CPUs are not vulnerable to Meltdown.
2) AMD (along with Intel and ARM) CPUs are vulnerable to one of the two variants of Spectre, AKA variant 1 or Spectre 1. AMD can 'fix' this in software - looks like it can't be fixed for Intel in software since the issue is at a hardware level for Intel. Also I've read that AMD is only vulnerable to Spectre 1 on Linux running a non-default kernel setting. This needs to be researched and verified. AMD CPUs are not vulnerable to variant 2 AKA Spectre 2.
3) PTI initially flagged all x86 CPUs are "insecure" as a precaution, until it was pointed out by AMD that they're not vulnerable to Meltdown.
4) AMD submitted a patch exempting AMD CPUs from PTI after it was known they don't need PTI enabled for AMD users (again, not vulnerable to Meltdown). There's no reason to enable PTI for AMD CPUs at the current time.
5) Said patch has been accepted and merged by upstream, so the next releases of the Linux kernel(s) will exempt AMD CPU users from PTI being enabled.
6) Intel CPUs are vulnerable to variant 1 (Spectre 1), variant 2 (Spectre 2) and variant 3 (Meltdown).
I don't see how this is a burn from AMD to Intel? AMD CPUs simply don't need PTI enabled for their CPUs since they're not vulnerable to Meltdown. So why enforce PTI on AMD when it clearly isn't needed?
-
Boo Berry got a reaction from just_dave in AMD burns Intel with the best Linux Kernel patch ever ensuring that AMD CPU performance is not affected by PTI
For those tl;dr users;
1) PTI is meant to 'fix' Meltdown (AKA variant 3), which ONLY affects Intel's CPUs (and maybe some ARM CPUs and iDevice CPUs). AMD CPUs are not vulnerable to Meltdown.
2) AMD (along with Intel and ARM) CPUs are vulnerable to one of the two variants of Spectre, AKA variant 1 or Spectre 1. AMD can 'fix' this in software - looks like it can't be fixed for Intel in software since the issue is at a hardware level for Intel. Also I've read that AMD is only vulnerable to Spectre 1 on Linux running a non-default kernel setting. This needs to be researched and verified. AMD CPUs are not vulnerable to variant 2 AKA Spectre 2.
3) PTI initially flagged all x86 CPUs are "insecure" as a precaution, until it was pointed out by AMD that they're not vulnerable to Meltdown.
4) AMD submitted a patch exempting AMD CPUs from PTI after it was known they don't need PTI enabled for AMD users (again, not vulnerable to Meltdown). There's no reason to enable PTI for AMD CPUs at the current time.
5) Said patch has been accepted and merged by upstream, so the next releases of the Linux kernel(s) will exempt AMD CPU users from PTI being enabled.
6) Intel CPUs are vulnerable to variant 1 (Spectre 1), variant 2 (Spectre 2) and variant 3 (Meltdown).
I don't see how this is a burn from AMD to Intel? AMD CPUs simply don't need PTI enabled for their CPUs since they're not vulnerable to Meltdown. So why enforce PTI on AMD when it clearly isn't needed?
-
Boo Berry got a reaction from johnukguy in Having a hard time switching over to Ryzen CPU!
Possible (likely?) immunity from the Intel hardware bug (and the performance drop fixing it will incur).
-
Boo Berry got a reaction from DeadlyTitan in My take on Intel refuse to patch the bug.
Looks like Windows has enabled KPTI for AMD processors too, so expect a performance drop with AMD on Windows as well.
-
Boo Berry got a reaction from Trimak in Need help finding monitor 4K 60HZ
The Wasabi Mango UHD420 42" 4K AH-IPS HDMI 2.0 DP monitors on eBay are looking pretty good. Plus if you have an AMD card there's a firmware update for the monitor which enables FreeSync support.
http://www.ebay.com/itm/Perfect-Pixel-WASABI-MANGO-UHD420-REAL-4K-HDMI-2-0-42-LG-AH-IPS-UHD-DP-Monitor-/121679317065?hash=item1c54a70849
-
Boo Berry got a reaction from obsoletepotato in Windows 8.1/10 Product Key?
This is what you have to do anyways, actually. After upgrading from 8.1 to 10 you can then do another clean install of 10, skip the key entry and it should activate itself.
-
Boo Berry got a reaction from Captain Matt in FrozenCPU Closing Down (?)
Why own a shipwreck when you can create your own?
-
Boo Berry got a reaction from kpreg in FrozenCPU Closing Down (?)
Why own a shipwreck when you can create your own?
-
-
Boo Berry got a reaction from ivhyn in My problem with Mayhems (Specifically Michael Wood)
I'm going to be honest, no I'm not trying to start anything with this post... these are just my observations.
1. That sure looks like plasticizer to me, thus indicating the tubing is actually at fault here. What type(s) of tubing are you using? You said you used five different tubings/brands, right? I read your posts and nowhere did you post any conclusive proof that it's Mayhems at fault here and not the tubing. Did you test the tubing yourself for plasticizer? Did you scrape the inside of the tubing with a screwdriver to confirm the presence of plasticizer?
2. It seems to me you just want to blame Mayhems for the issues when many users, myself included, have use Mayhems without any issues at all. Instead, perhaps you should look into the tubing itself - perhaps you've got bad batches of tubing?
3. I do agree that Mick could of handled the situation better without the insults but like others said you're attacking his livelihood and his products. Still, there's no reason for his attitude towards the situation and instead he should be trying to help you by testing your tubing but I suspect it's your attitude towards him and vice versa that causing the issue here as well.
I've used Mayhems for several years now without issues with the products itself. However, I've had issues with plasticizer but that's due to the tubing itself - switching out the tubing to another brand (e.g. some Primochill tubing has had plasticizer issues for the last year or so but some Primochill tubing doesn't have an issue... it depends on the batch) made all problems go away.
-
-
-