Bisakah menjalankan `yes> / dev / null` membahayakan Mac?


36

Baru-baru ini saya berlari yes > /dev/nullselama 3 menit untuk menguras baterai Mac saya. Selama waktu itu, suhu naik ke 72 ° C dan kipas berputar hingga 4000 RPM. Saya segera keluar dari proses.

Haruskah saya khawatir perangkat keras atau papan logika ini rusak?


9
Apakah Anda berpikir bahwa Mac dirancang untuk rusak dengan memainkan game 3D, menyusun proyek perangkat lunak besar, atau sebagainya?
user253751

3
Ingin menambahkan di sini bahwa seorang teman saya berhasil melelehkan keyboard notebook apel kecilnya (jangan tanya saya untuk model yang tepat) dengan menyusun beberapa proyek besar. Setelah itu kunci A agak cacat. Masih fungsional, tetapi Anda bisa melihat perbedaannya.
Byte Commander

3
Anda akan aus pada lubang di /dev/nullpelabuhan pada akhirnya sehingga Anda akan membutuhkan piston yang terlalu besar, tetapi tunggu sampai Anda melihat asap dari knalpot sebelum bergegas ke mekanik.
user207421

@ EJP - Itu memang benar, tetapi menyuntikkan pelumas sintetik yang baik langsung ke pelabuhan dapat membantu memperpanjang umur. Saya juga pernah mendengar bahwa Seafoaming pseudo tty memiliki manfaat yang signifikan.
Allan

Apa yang Anda maksud dengan komentar Anda? @EJP

Jawaban:


3

Tentu seperti yang dikatakan orang lain: CPU dan kernel keduanya memiliki strategi penyelamatan diri sendiri.

Saya akan menambahkan beberapa rasa tentang bagaimana yes menggunakan sumber daya komputer.

Perlu dibedakan antara perilaku BSD yesdan GNU yes.
macOS adalah BSD, jadi akan menggunakan distribusi BSD (lama) yes.

Diskusi yang baik tentang perbedaan ada di Bagaimana GNU yesbegitu cepat?

Dan diskusi tentang diskusi itu ada di utas Berita Peretas dengan nama yang sama .

BSD / macOS yesbenar-benar hanya berjalan puts("y");dalam satu lingkaran ketat
GNU yes... agak lebih serius. Ini memiliki optimasi jauh melampaui buffering I / O.


55

Petunjuk untuk yesmendapatkan permata kecil ini dari halaman manual :

Menggunakan yes menghasilkan penggunaan prosesor 100%, untuk alasan ini jarang digunakan selain untuk pengujian misalnya untuk memaksimalkan CPU komputer.

Yang berarti, tidak, Anda tidak akan merusak perangkat keras Anda. Menggunakan yesperintah adalah cara menggunakan semua (yaitu 100%) CPU Anda. Gejala-gejala yang Anda alami (yaitu kenaikan suhu dan peningkatan hasil RPM kipas) diharapkan dalam kondisi ini. Selain itu, CPU Anda akan "throttle back" dan akhirnya dimatikan jika ambang termal melebihi untuk mencegah kerusakan.


2
Setuju. Mesin-mesin dapat berjalan pada 100 derajat CPU selama berjam-jam dan memiliki banyak perlindungan untuk menurunkan penjadwalan cpu jika pendinginan tidak mengikuti.
bmike

1
Tetapi saya pernah mendengar bahwa ketika menjalankan loop sementara eksekusi dapat melelehkan beberapa bagian. Dan berapa banyak waktu yang harus saya tinggalkan agar perintah yes berjalan sehingga Mac saya mencapai 105 C?

3
Itu selalu terbaik untuk pergi dengan data empiris yang terdokumentasi daripada kabar angin. Misalnya, lihat: Intel - Bagaimana shutdown pada overheating berfungsi? Adapun waktu yang diperlukan, 1) itu tergantung pada lingkungan operasi fisik Anda, dan 2) apa yang ingin Anda capai? Namun, itu adalah pertanyaan yang berbeda dari apa yang awalnya diajukan.
Allan

3
Itu pernyataan yang cukup mengejutkan dari halaman manual! Saat menjalankannya sendiri, saya setuju, sangat tidak berguna, menyalurkannya ke perintah lain bisa sangat berguna dari waktu ke waktu.
Muzer


8

The yesperintah hanya berulang kali menulis string ke stdout, karakter y secara default. Mengarahkan ulang ( >) itu /dev/nullhanya menyebabkan aliran data dilupakan. Dengan kata lain ini tidak memiliki efek abadi pada kondisi komputer Anda yang terus-menerus, ini bukan perintah yang berbahaya melalui lensa ini.

Karena perintah yes menulis string ke stdout tanpa kendala pada kecepatan output, ini akan menyebabkan CPU mencapai pemanfaatan maksimal pada satu inti. Ini adalah penyebab kenaikan suhu prosesor dan peningkatan kecepatan kipas yang terkait.

Dalam mesin modern, terutama yang dirancang dengan baik seperti laptop Apple, perangkat keras akan melindungi dirinya dari kerusakan akibat panas berlebih. Pertama dengan meningkatkan kecepatan kipas, kemudian dengan mengurangi kecepatan clock prosesor, dan akhirnya dengan menghentikan prosesor. Tanpa sengaja menghindari fitur-fitur ini, perangkat keras Anda tidak kepanasan. Mesinnya baik-baik saja.

Anda menyebutkan suhu 72 ° C secara khusus. Ini bukan suhu yang sangat tinggi untuk CPU mati. CPU seluler sederhana, i5-7260U, menentukan suhu maksimum yang diizinkan 100 ° C. Anda dapat melihat spesifikasi sebagai T_Junction di bagian spesifikasi paket halaman ini: http://ark.intel.com/products/97539/Intel-Core-i5-7260U-Processor-4M-Cache-up-to-3_40- GHz


-2

Kebenaran yang menyedihkan adalah: ini bisa "Membahayakan Mac ".

Contoh aktual yang diberikan dalam tubuh untuk pertanyaan: ini sangat mungkin tidak membahayakan perangkat. Memang.

Tetapi sebagai jawaban umum untuk pertanyaan dalam judul: Itu tergantung pada jenis Mac yang kita bicarakan. Saran dan alasan yang diberikan sejauh ini pada pertanyaan ini atau dalam komentar tidak secara universal benar dan bisa sangat berbahaya! Ada terlalu banyak kepercayaan dan keyakinan yang diberikan hanya pada kepercayaan bahwa perangkat keras Apple adalah yang terbaik yang ada.

Tidak benar bahwa Apple mendesain sekarang atau dirancang di masa lalu semua sistemnya untuk benar-benar tidak membahayakan diri mereka sendiri karena terlalu panas. Meskipun benar bahwa ini seharusnya tidak terjadi , tetapi juga benar bahwa hal itu terjadi . Dan apakah:

Contoh utama untuk ini adalah MacBook Pro, terutama yang dari 2010-2012. Sementara chip Intel yang terutama ditekankan yespada semua thread untuk waktu yang lama akan melambat, akan menangani suhu tinggi dengan cukup baik dan bahkan OS akan menendang dan meningkatkan kernel_task untuk melakukan apa pun yang berguna kecuali membantu mendinginkan mesin, diskrit chip pada heatpipe yang sama adalah mitra yang rentan di sana.

Menekan sistem ini dengan sia-sia, seperti dengan yes, mempercepat kegagalan chip grafis RadeonGate. Ada banyak contoh pertanyaan untuk 2011, 8,2 yang paling banyak dipengaruhi pada situs web ini. Kegagalan GPU ini adalah masalah termal. Bahkan ada panduan di luar sana tentang cara membunuh mesin dengan hanya menjalankan rendering 3D berat atau benchmark untuk sementara waktu. Sistem ini diiklankan untuk tetapi tidak cocok untuk mis rendering atau game. Tuntutan class action (hanya terancam) dan Perbaikan Program Ekstensi berbicara sendiri.


1
Saya memiliki MacBook awal 2015 dengan Retina display bukan MacBook 2011 untuk video info.Nice.

Jawaban ini pada dasarnya salah. yesbagaimanapun juga tidak berinteraksi dengan GPU. The sumber untuk yeshanya panggilan paling perpustakaan dasar; tidak satupun dari mereka yang menjadi perpustakaan matematika (minimal diperlukan untuk mengakses GPU). Kedua, video yang Anda tautkan tidak terhubung yesdengan GPU yang gagal. Rossman menghubungkan GPU yang gagal dengan manufaktur yang buruk.
Allan

Ini pada dasarnya tidak salah pada perangkat yang diberikan. Jawaban saya adalah tentang membedakan antar perangkat. Dan ini tentang manufaktur yang buruk dan desain yang buruk. yesMenekankan CPU. CPU yang stres menjadi hangat. Temperatur kemudian meningkat pada heat sink dan heat sink yang sama harus mendinginkan GPU yang rentan. Heat sink / desain termal gagal melakukannya secara teratur pada sebagian besar 8,2 MBP.
LаngLаngС

@LangLangC - Heat sink / desain termal gagal. Itu kesalahan logis. Tidak ada bukti bahwa CPU hangat (er) menghalangi sifat disipasi energi dari heat sink yang menyebabkan GPU gagal dan Anda memberikan bukti untuk mendukung klaim. Video yang Anda tautkan (semuanya 17 menit) tidak menyebutkan suhu CPU yang lebih tinggi atau menekankan CPU.
Allan

Buktinya ada dalam tingkat kegagalan di unit-unit ini. Pernahkah Anda melihat heatsink ini? Ini fisika sederhana.
LаngLаngС
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.