Microsoft Surface Pro goes „Debian Bookworm“ (Surface Kernel) Download Custom-ISO

Worum gehts?

Nachdem ich recht günstig ein MS Surface Pro 5 Tablet (gebraucht) erstehen konnte, das in einem herausragenden Zustand ist, wollte ich gleich mal testen, wie einfach (oder schwer) es ist, ein „Linux“ darauf zu installieren. Da ich der Meinung bin, dass Gnome für einen Touchscreen weit besser geeignet ist als KDE Plasma, installiere ich Gnome. (Auch wenn ich damit momentan noch nicht so ganz auf du und du bin. 😉

Damit auch der Touchscreen läuft…

Um alle Funktionen nutzen zu können, benötigt man ein „Custom Kernel“, genannt Surface Kernel. Hierfür gibt es eine Seite auf Github

Auf genannter Seite könnt ihr nachlesen, wie ihr das Surface-Kernel auf eure installierte Linuxdistribution bringt.

Adaptierte Debian Bookworm ISO mit Surface Kernel & Gnome  (Live Build mit Installer)

Wenn man sich die auf Github beschriebenen Anpassungen (Surface Kernel) sparen will, kann auf meine modifizierte Debian Bookworm ISO zurückgegriffen werden.

Download: https://drive.google.com/file/d/1b-tlvpw5-56rLfFA8B9sQLAIQRpbWN_0/view?usp=sharing

Details auf Youtube

 

Auswirkungen VMWARE ESXI Spectre & Meltdown VMkernel.Boot.hyperthreadingMitigation

Für alle, die sich fragen, welchen Impact das Aktivieren des ESXI Parameters VMkernel.Boot.hyperthreadingMitigation haben kann, 2 Diagramme (Readytime), aus der VCenter-Überwachung. Wichtig hierbei ist, dass der Wert so niedrig wie möglich sein sollte und möglichst nicht über rund 1500ms.

 

Wie oben ersichtlich, liegen wir bei einem Host mit 2 CPUs, je 8 Cores  – in Summe also 16-Cores, ohne Hyperthreading bei einem Wert von teilweise !!! 15.000ms !!! Dies hatte massive Auswirkungen auf die Performance des Hosts, auf dem 12VMs laufen. Insgesamt sind 38vCpus zugeordnet.

Der gleiche Host, mit deaktivierter Option „VMkernel.Boot.hyperthreadingMitigation“ und aktivem Hyperthreading:

Nicht täuschen lassen! Die Kurve scheint optisch extremer, aber schaut mal nach links zur Legende. Hier haben wir jetzt eine Wert von „nur“ noch max. 1.750ms. Danach pendelt sich der Wert ein. Dies hatte zur Folge, dass der Host und die darauf installierten VMs wieder normal liefen.

Hier wird man aufgrund der Situation dann zwangsläufig mit der Frage / Entscheidung konfrontiert, ob Sicherheit oder Leistung wichtig ist. In dem Fall habe ich mich (aufgrund der Begleitumstände, dass die Systeme in einer recht sicheren Umgebung laufen) für die Leistung entschieden. Allerdings hätte ich mir nie gedacht, dass der Parameter derartige Auswirkungen hat. Anzumerken ist auch, dass es sich hierbei um relativ alte CPUs handelte, nämlich: Intel(R) Xeon(R) Silver 4110 CPU @ 2.10GHz (Marktstart: 3. Quartal 2017)

Kobol is pulling the plug… :-(

Es ist nun schon einige Zeit her, dass ich meinen Blog mit neuen Beiträgen versorgt habe. Ich denke, dass der Beitragsoutput im Herbst-/Winter  wieder steigen wird. Eine Meldung jedoch, die zumindest mir eine Erwähnung wert ist, hat mich nun dazu veranlasst, wiedermal ein wenig in die Tasten zu „hauen“.

Ich hatte ja vor einiger Zeit für das KOBOL Helios 64 NAS eine Videoserie erstellt, die sich mit dem Zusammenbau & Setup des NAS-Bausatzes beschäftigt hat. Seit damals läuft das NAS bei mir im 24/7 Dauerbetrieb (ohne Probleme).

Alle Komponenten waren meiner Meinung nach sehr hochwertig. Beeindruckt war ich damals vor allem vom Metallgehäuse und dem durchdachten Design.

Und plötzlich ist Schluss…

Völlig unvorbereitet bekam ich dann gestern ein Email der Firma Kobol. Der Betreff „We are pulling the plug“, ließ mich Schlimmes vermuten.

Leider hatte ich mit meiner Vermutung recht.

Das Mail im Wortlaut:

Hi Folks, a bit saddened that after 4 months of radio silence we are coming up with a news that is clearly not the one you were expecting.

As the title says, we have decided to stop the adventure here. Quite a few reasons made us come up to this difficult decision, but it all comes down to 2 key points :

1. The still ongoing difficulties to manufacture electronics, to procure parts and mainly to control costs.

2. We made a rookie mistake of stretching ourselves very thin last year with the first delivery of Helios64 while being just a 3 men show. We should have brought few more people onboard sooner, but we waited too long until we were a bit burnt out.

Not seeing much improvement on the horizon and feeling like we didn’t ride the wave as we should have, our motivation started slowly to fade out lately. All of this is of course a bit frustrating and ironic because we had a great start with Helios64 plus a batch 2 waiting list that keeps growing and growing. We were also quite excited to come up with a refresh and improved version of Helios64.

But unfortunately sometimes it’s better to accept the fact that when the original motivation and passion are not there anymore then there is no point forcing it.

Now it’s time for us to go back to a more stable and sustainable work lifestyle. But who knows maybe Kobol will reborn again one day 😉

In the meantime we will post on the wiki all the blue prints of Heliso64. That should help people to tinker or even troubleshoot their board when necessary. We will try our best to provide still a bit of support during our free time. Sorry in advance for any inconvenience this will cause.

We are also happy to discuss editing access to our wiki if someone is interested to maintain the project a bit longer.

We want to thank you all very much to have followed us and supported us during this awesome adventure.

 

You can check directly the latest news on our BLOG.

Bleibt mir nur zu sagen, dass ich hoffe, dass es bald wiedermal so etwas gibt, denn die Idee dahinter fand ich durchwegs sehr gut.

Ich wünsche dem ehemaligen Kobol Team jedenfalls alles Gute!

Kobol Helios 64 NAS How-Tos (Videoserie)

Nachdem ich mein Helios64 NAS von Kobol nun in Echtbetrieb habe und im Zuge der Konfiguration eine Videoserie bzgl. Installation und Konfiguration erstellt habe, möchte ich diese nun auch hier veröffentlichen.

Unpacking / Die Komponenten

Kurze Info zum Zusammenbau

Detaillierte Assemblierung des gesamten NAS Systems

Installation Opemediavault

Konfiguration Openmediavault – Teil 1

Konfiguration Openmediavault – Teil 2 (Shares / SMB)

Manuelle Installation Pihole (parallel zu Openmediavault)

 

 

 

 

 

 

AMD Radeon RX 6800: Kruzifix schon wieder nix… [Paperlaunch auch bei Team red?]

18.11.2020 — 10:50h: Heute soll es soweit sein. Die neue AMD Grafikkartengeneration soll auf den Markt kommen. Bereits seit Tagen liest man auf diversen Internetseiten, dass es bezüglich die Verfügbarkeit der 6000er Serie – ähnlich wie bei NVIDIAS RTX 3080 – eher schlecht bestellt sein wird.

18.11.2020 — 18:21h: Wie bereits vermutet sind die AMD Radeon RX 6800 Karten so gut wie nicht verfügbar.

Dies spiegelt auch eine Abfrage auf der Preisvergleichsplattform geizhals.at wieder.

„Wie sie sehen, sehen sie NIX“… 0 Angebote vorhanden.

Im Endeffekt haben wir bei AMD eine identische Situation wie beim Launch der RTX 30xx Serie von NVIDIA. Die Karten sind nicht verfügbar.

Natürlich kann und wird die nach wie vor vorherrschende Corona-Pandemie ihr Übriges dazu beitragen. So gesehen spielt AMD hiermit NVIDIA in die Karten. Wäre es AMD gelungen die 6000er Serie zeitgerecht und in entsprechenden Mengen auf den Markt zu bringen, wäre dies ein zusätzlicher Vorteil im Kampf mit NVIDIA gewesen.

Ich vermute, wir werden -was die Preise angeht- ähnliches wie bei NVIDIA erleben:

Die Verfügbarkeit ist aktuell gegen 0 tendierend, die Nachfrage ist hoch… Der Preis wird in ungeahnte Höhen steigen.

Ich glaube, dass wir erst weit nach Jahreswechsel mit einer angemessenen Verfügbarkeit (und einem angemessenen Preis) rechnen können.

Schade eigentlich!