Interesting video, and can we please end the idea that Intel is still the more trustworthy option?
There have been so many scandals with Intel CPU’s for the past 10 years that there is no way they deserve to be deemed as the trustworthy option, when AMD pretty reliably have had much fewer compatibility reliability and security problems, despite being more innovative.
I don’t mean AMD has been better in total among the 3 categories, but better in ALL the categories!!
Yes, that was very weird to read, repeating the same thing twice for the same CPU?
I know it’s not the same process, but I’ve been hearing about silicon degradation for at least 2 decades now, but I’ve never seen evidence that it’s actually a thing.
By the way, I also have an Amiga 500 from late 80’s, that is still working! If silicon degradation was actually a thing, how is that even possible? Obviously they can’t last forever, but for sure they have always been able to last way beyond the point where they become obsolete.
Airports sometimes still use equipment from the 70’s and 80’s too. So I doubt degradation is actually a thing, even though modern processes may not be able to last for 60 years, I maintain that degradation in just a couple of years should be impossible.
Apparently due to silicon degradation.
It’s funny, because I have never experienced that, and I’ve always OCed and over volted my CPU’s. My current CPU is a 7 year old Ryzen R5 1600, that I have been running with both OC and higher voltage too. Every CPU I’ve had for 40 years now, has been replaced because they became obsolete. I’ve worked as an IT consultant for 10+ years in the 90’s and 00’s, and NEVER experienced silicon degradation. All sort of other problems, like faulty soldering when led became illegal, and capacitors when fake poor quality Chinese capacitors found their way into production. There is no way silicon degradation should be an issue within a short time span of a couple of years.
Anyways as it looks now it doesn’t seem like a good idea to buy Intel.
I think Facebook buying Oculus kind of killed the buzz there was around 3D gaming. It did for me.
Not a native English speaker, but if I understand correctly, that changes the meaning to the opposite?
I very rarely need to do anything in the terminal that takes more than a couple of minutes. I grew up with terminal based systems, and IMO nothing will ever beat the Amiga in clever design and nice terminal with way more intuitive commands. I never really liked Unix, and Linux is essentially like Unix when you use the Terminal.
I’ve been using computers since 1979, so I admit I don’t play with them like I used to.
Yes, grep is cool, but I use/need it so rarely, I can never remember the syntax.
My system has functioned so reliably for years, that I hardly ever need to do any fixing or configuration.
The only need for maintenance, is basically hardware upgrades. 👍
Pretty amazing IMO. 😀
lsblk is better, but still a bit confusing:
bh /mnt/tera-home/home/bh lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 931,5G 0 disk
ââsda1 8:1 0 300M 0 part
ââsda2 8:2 0 922,4G 0 part /mnt/tera-home
ââsda3 8:3 0 8,8G 0 part
sdb 8:16 0 238,5G 0 disk
ââsdb1 8:17 0 300M 0 part /boot/efi
ââsdb2 8:18 0 238,2G 0 part /
sdc 8:32 0 931,5G 0 disk
ââsdc1 8:33 0 931,5G 0 part
sdd 8:48 0 698,6G 0 disk
ââsdd1 8:49 0 512M 0 part
ââsdd2 8:50 0 698,1G 0 part
sde 8:64 0 256,2G 0 disk
What’s the weirdo “ââ” for? It would look 10 times better without.
Edit:
Ah apparently a terminal character compatibility problem, it’s supposed to be a graphics character showing indentation. 🤷♀️
I just removed snapd and snapd-glib and the list is 3 lines shorter.
OK I have something called snapd, which I may want to remove.
extra/snapd 2.61.1-1 [installed]
Service and tools for management of snap packages.
I don’t have Ubuntu snap, or anything called snaps installed. I’m using Manjaro, but if snap was there originally I have removed it. No way I’d use that.
What? Are you talking removable drives? Because there is no distro I’m aware of, that automatically mounts a newly installed disk.
Also usually systems don’t grant write privileges for EXT4 or other security featured formats. But only for FAT32 and ExFAT and other “lesser” formats.
So often you have to switch to root, and grant those privileges to your user account.
Yes, I know, but that’s not automatic, and automatic mount-points vary for removable drives based on DE and distro.
You don’t need to. It is handled automatically.
No it’s not, and you still need to identify what data is on what drive when swapping. I am not aware of a distro where a drive is auto-mounted with write privileges after you install it.
I have AMD stock😀, I was always an AMD guy and stuck with my trusty Bulldozer FX CPU when they were really bad compared to Core2, I predicted way back in 2016 AMD would compete with Nvidia on compute, and later AI. But even for me what Linus did was too thick.
Intel was still ahead in single threaded at the time, but Linus focused ONLY on negative things.
mount
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
dev on /dev type devtmpfs (rw,nosuid,relatime,size=8141320k,nr_inodes=2035330,mode=755,inode64)
run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755,inode64)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
/dev/sdb2 on / type ext4 (rw,noatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=37,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=22556)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,nosuid,nodev,relatime,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /tmp type tmpfs (rw,noatime,inode64)
/dev/sda2 on /mnt/tera-home type ext4 (rw,relatime)
/dev/sdb1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1629900k,nr_inodes=407475,mode=700,uid=1000,gid=1001,inode64)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1001)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1001)
Yes I can see that’s very convenient for seeing your drives. 😜
Could you please correct your bot to not use double return for new line, which causes empty lines? And instead use a double space at the end of the line, and then return, which works as a normal return.
I have no idea why Lemmy does formatting this very counter intuitive way, but that’s how it is.
That’s actually one of my biggest gripes with Linux, it seems very difficult to keep track of physical drives and their mount points for when you need to swap things out. I still find it a bit cumbersome, and I’ve been using Linux since 2005.
Security including but not limited to:
Spectre:
https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
Meltdown:
https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
Downfall:
https://en.wikipedia.org/wiki/Downfall_(security_vulnerability)
These issues stem from several areas of CPU optimizations, Unsafe Branch prediction, multi-threading, and memory optimizations. While some AMD CPU’s were somewhat touched by spectre/meltdown, they could be patched pretty easily, while Intel was hit for several complete generations of CPU’s, and patches caused speed decreases of sometimes 30%.
Stability:
Several issues with overheating:
https://www.youtube.com/watch?v=-kxlrez5dWo
Unclear guidelines for CPU setup:
https://www.pcgamer.com/hardware/processors/intel-pressures-all-motherboard-manufacturers-to-implement-default-power-settings-by-the-end-of-may/
This widespread malpractice caused unsafe and power hungry OC to be default on many motherboards.
Compatibility: There were compatibility problems with crashes when Intel introduced e-cores, where the solution was to disable e-cores. Unfortunately this problem is apparently now drowned out by newer problems with Intel CPU’s, so I can’t easily find sources.
In most cases these problems are not total killers, but they often cause the CPU not to perform as advertised. And they do cause occasional crashes, as we could see in the video, way more often with Intel than AMD for the past 2 generations, but there were also problems with 12th gen. and AFAIK with almost every gen since Kaby Lake (Spectre Meltdown).
This is a massive issue seen over time, so I have probably left things that are significant out. I have left out things that go too far back on purpose, because I don’t consider them relevant anymore, everything before Core2 is irrelevant now IMO.