Beiträge von Agnes

Zitat von Berichtigung

Intel und AMD Patches sind von Linux Patches VÖLLIG verschieden, auch wenn viele sie für das gleiche halten (und sogar verwirrenderweise manchmal sogar fast gleich sind.)
ALLE Desktop Prozessoren -egal ob von Intel oder AMD - verwenden den Microcode von AMD namens amd64.

Der Microcode von Intel ist für XEON Prozessoren, und für sonst nichts.
Nachdem Intel vor Jahren die Xeon Reihe eingeführt hatte, wollten sie diesen Befehlssatz auf dem Markt durchdrücken und haben deshalb ihren Befehlsatz für die "normalen x_86 Prozessoren etwas vernachlässigt. Der Markt reagierte prompt und schwenkte sofort auf AMD um. Da der Microcode amd86 eh besser war, schwenkte Intel daraufhin auch auf diesen Microcode um. Es gibt heute NUR noch Desktoprozessoren der X_86- Gattung mit amd86.
Oder eben Xeon, was aber eine komplett andere Baustelle ist.

Das ist leider völlig falsch!
Du verwechselst hier ein CPU-Microcode-Update mit der amd64-Befehlserweiterung.

Lies mal bitte diesen Wikipediaartikel zu AMD64: en.wikipedia.org/wiki/X86-64

Zitat von en.wikipedia.org/wiki/X86-64

the AMD64 architecture was positioned by AMD from the beginning as an evolutionary way to add 64-bit computing capabilities to the existing x86 architecture, as opposed to Intel's approach of creating an entirely new 64-bit architecture with IA-64.

Im Gegensatz dazu lies bitte diesen Artikel über den CPU Microcode: en.wikipedia.org/wiki/Microcode
————————————————————————————————————————

Zitat von Berichtigung

Dass mache Distributionen, wie openSUSE zu schnell ein Microcodeupdate mit den Patches von Intel ausgeliefert haben, die dann schnell zurückgezogen wurden, ist typisch. Debian war da viel klüger.

Das stimmt ebenfalls nicht.
Debian hat alle Intel Microcode-Updates sofort ausgeliefert, wie in diesem Change log nachzulesen ist: U.a.: intel-microcode 20180108 und 20171215
launchpad.net/debian/sid/+source/intel-microcode/+changelog
———————————————————————————————————————

Zitat von Agnes

Den Intel-CPU-Microcode, der für die Benutzung unter Linux geeignet ist, kann jeder Endkunde selbst bei Intel runterladen:
downloadcenter.intel.com/download/27337?v=t

Zitat von Berichtigung

Na toll.
Du hast aber schon gelesen, was in deinem Link steht?

Du machst einfach weiter, und postest jetzt auch noch Links, damit noch mehr Unbedarfte sich ihr System zerschießen?!
Bravo.

Die Intel-Webseite habe ich selbstverständlich gelesen, aber du offensichtlich nicht.
Das Microcode-Update ist, soweit ich zählen könnte, für 2351 unterschiedliche Intel-CPUs anzuwenden und nicht nur allein für die Intel XEON Prozessoren, wie du behauptest.

Diesen aktuellen Intel-CPU-Microcode 20171117, den es nicht im openSUSE Update-Repo gibt, kann man sich bequem als RPM z.B. hier runterladen und installieren:
download.opensuse.org/repositories/home:/Sauerland/openSUSE_Leap_42.3/x86_64/ucode-intel-20171117-28.1.x86_64.rpm

Weiter: Das Microcode-Update von Intel ist nur für Intel CPUs, und das Microcode-Update von AMD ist nur für AMD CPUs.

Tut mir leid: Anderen Leuten wirfst du vor, sie sollen keinen Quark reden, bist aber selber nicht besser!
Siehe: www.opensuse-forum.de/thread/39997-tumbleweed-boot-problem-framebuffer-initialisierung/?postID=118631#post118631

Zitat von Berichtigung

Intel und AMD geben ihre Microcode Patches NUR an OEMs (OriginalEquipmentManufacturer) heraus. Und an so Grupppen, wie Linux, RedHat und solche Firmen. NIEMALS an Endkunden. Und wir hier sind Endkunden. Sonst nichts.

Den Intel-CPU-Microcode, der für die Benutzung unter Linux geeignet ist, kann jeder Endkunde selbst bei Intel runterladen:
downloadcenter.intel.com/download/27337?v=t
Die Version 20180108 wurde von dieser Seite natürlich längst entfernt.
Und es ist im Netz zu lesen, dass es vor 20180108 noch eine Microcode-Version 20171215 gegeben haben soll, die von Intel aber ganz schnell wieder zurückgezogen wurde.

Ach so: Eine interessante Frage ist noch, warum openSUSE für Leap 42.3 den Intel-CPU-Microcode 20170707 ausliefert, obwohl bei Intel die letzte aktuelle Version die 20171117 ist.

Zitat von sterun

Hallo Agnes,

habe ebenfalls heute das Update erhalten - verbaut ist jedoch eine Intel CPU.
Was mich mal interessieren würde:
Ich habe vor einiger Zeit "ucode-amd" deinstalliert (da Intel im Einsatz).
Demnach erhalte ich auch keine AMD-Updates (so, der Plan).

Du hast doch bestimmt noch die letzte Version von "ucode-intel" installiert gehabt, oder?
zypper se -si ucode-intel

Wenn ja - warum bei einer AMD CPU?
Falls nicht - warum hast du dann dieses Update erhalten?

LG sterun

Alles anzeigen

Hi sterun,

da fragst du leider die Falsche, warum ucode-intel auch bei AMD-CPUs installiert wird.
Ich würde mich aber sehr freuen, wenn sich noch ein Gesprächspartner zum Thema findet. Das hatte ich hier schon mal geschrieben: www.opensuse-forum.de/thread/39837-kurze-frage-zu-ucode-intel/?postID=117910#post117910

Alles, was ich zu Meltdown v3, Spectre v1 und Spectre v2 weiß, habe ich nur im Netz gelesen. Aber sicher hat nicht Jeder die Zeit und das Interesse dafür, das kann ich verstehen.
Das ucode-intel Update von gestern habe ich erhalten (siehe Beitrag 26), und ich erhalte neben ucode-amd auch alle Updates von ucode-intel automatisch.

Irgendwann wird Intel ja den neuen CPU-Microcode fertig haben, und dann wird er auch per Update in openSUSE verteilt. Konkrete Anwendungen für die 3 neuen Intel-CPU-Befehle (IBPB, STIBP und IBRS) soll es unter Linux geben, wenn in einer Virtuellen Maschine MS-Windows läuft, das darauf wegen Spectre v2 zwingend angewiesen ist. Unter MS-Windows gibt es kein Return Trampoline (Retpoline) sondern Branch Target Injection. Diesen (BTI) Patch "Intel-Code" oder auch Indirect Branch Speculation genannt hatte Intel bereits Linus Torvalds vorgelegt. Linus' Stellungnahme dazu findest du hier: lkml.iu.edu/hypermail/linux/kernel/1801.2/04628.html

openSUSE hat bei mir heute per Update-Repo einen neuen Intel-Microcode installiert. Den brauche ich natürlich nicht, weil ich AMD habe.

# zypper info ucode-intel
Loading repository data...
Reading installed packages...




Information for package ucode-intel:
------------------------------------
Repository     : Hauptaktualisierungs-Repository               
Name           : ucode-intel                                   
Version        : 20180108.revertto20170707-19.1                
Arch           : x86_64                                        
Vendor         : openSUSE                                      
Installed Size : 2.5 MiB                                       
Installed      : Yes (automatically)                           
Status         : up-to-date                                    
Source package : ucode-intel-20180108.revertto20170707-19.1.src
Summary        : Microcode Updates for Intel x86/x86-64 CPUs   
Description    :                                               
    This package contains the microcode update blobs for Intel x86 and x86-64 CPUs.

Für die Leute, die glauben, dass ihnen durch dieses Downdate etwas wertvolles gestohlen würde, soll dies als Warnung dienen.

Unabhängig davon, wieviel in den letzten acht Jahren in cdrecord gefixed, geändert und Neues eingebaut wurde, ist das nur eine rhetorische Frage gewesen.

AN-3.00 2010-06-01 sourceforge.net/projects/cdrtools/files/AN-3.00/download
AN-3.01 2015-08-26 sourceforge.net/projects/cdrtools/files/AN-3.01/download
AN-3.02a09 2017-12-10 sourceforge.net/projects/cdrtools/files/alpha/AN-3.02a09/download
Einfach mal jeweils unter Cdrecord: nachlesen. Es ist sehr viel.

Zitat von Trekkie00

Es geht hier wohl nicht um die Brennqualität. So wie ich das sehe, legt das Programm Projektdateien an (analog zu audacity's aup Dateien). Diese sind wohl proprietär.
Er müsste diese dann tatsächlich erst als wave, flac oder wie auch immer speichern um diese dann mit k3b als Audio CD zu brennen (funktioniert hervorragend).
Wären die Aufnahmen nicht bereits abgeschlossen wäre es tatsächlich am sinnvollsten mit audacity aufzunehmen, zu bearbeiten und danach zu brennen.

Es geht nicht um die Brennqualität, aber darum, warum die fertigen Audiotracks von Magix als wav nicht unter Linux gebrannt werden "dürfen".

Da fällt mir aber noch eine andere rhetorische Frage ein:
Angenommen, cdrecord (Linux) wäre von 2009 und Magix (Windows) von 2017:
Würde man da immer noch in den Raum stellen, dass die Brennqualität am Ende die Selbe sei?

Rhetorische Frage: Liefert ein Magix von 2009 bessere CD-Brennqualität als das OpenSource cdrecord 3.02a09 aus dem Jahr 2017?

Zitat von jgmail

@Agnes
Ich habe von Magix das Programm Audio Cleaning Lab 16 deluxe von 2009. Damit habe ich vor Jahren Schallplatten aufgenommen, die ich dann auf Audio-CD´s brenne.

Ganz unabhängig vom Brennen unter VirtualBox, kannst du die fertig bearbeiteten Audio-Dateien in Magix Audio Cleaning Lab einfach als .wav exportieren.
Anschließend kopierst du diese Dateien aus der VM heraus in dein /home und brennst die .wav-Dateien unter Linux auf CD. Ich nehme jetzt X-CD-Roast dafür.

Warum nimmst du eigentlich nicht Audacity zum Bearbeiten? wiki.ubuntuusers.de/Audacity

# zypper info audacity
Loading repository data...
Reading installed packages...
Information for package audacity:
---------------------------------
Repository     : Packman              
Name           : audacity                          
Version        : 2.2.1-18.8                        
Arch           : x86_64                            
Vendor         : http://packman.links2linux.de     
…
Description    :                                   
    Audacity is a program that manipulates digital audio wave forms.
    In addition to multitrack recording capabilities with effects, it
    imports and exports many sound file formats, including WAV, AIFF,
    AU, IRCAM, MP, and Ogg Vorbis. Wave data larger than the available
    physical memory size can be edited.

Tipp: Eine gute Plattennadel ist durch nichts zu ersetzen.

Zitat von jgmail

Aber ich habe ein Programm von Magix womit ich Audio-CDs brenne und das funktioniert nur mit Windows.

Was ist denn so besonderes an diesem Programm?
Und ist denn das ein externer USB-CD-Brenner, den du hast?

@imho X-CD-Roast als eine Reise in die Vergangenheit, das kann ich nicht beurteilen.
Das Programm bietet interessante Optionen für Audio-CDs, die ich so noch gar nirgends gesehen habe. Und ich bin HiFi-Fan.

@jgmail Geht es dir ums Brennen unter VirtualBox oder ums Brennen mit Nero?