Weitere schlimme Erfahrung mit M$

Hi Arno,

" This page was last edited on 25 July 2018, at 13:11." Sorry, das ist schon sowas von uralt! Das ist schon lange nicht mehr aktuell. Mit derart veralteten Tipps kann man sich ganz schnell mal ein System versauen.

Marte

Ok, ist etwa zwei Jahre her. Da war es noch nicht ueberholt, sondern harte Realitaet.

Ja, aber im (Fast)-Ruhestand moechte ich keine Tausender mehr ausgeben fuer sowas.

Die gibt es schon sehr lange, aber nach wie vor unterstuetzt sie die kleinen Bricks nicht.

Probiert. Ging nicht. Ich stecke aber auch nicht mehr so viel Elan rein, weil die Chance, dass ich das alles brauche, mit der Zeit geringer wird. Und notfalls kann ich ja Win7 auf eine alten Computer haengen, notfalls per Boot Stick.

An den Signalhound kamen bei Kunden oft nichtmal gemietete teure Boliden von R&S und aehnlichen Platzhirschen ran. "Da draussen vor der Stahltuer steht vermutlich jemand, raucht eine Zigarette und klimpert auf dem Smart Phone" ... "Also jetzt spinnt der aber" ... rausgegangen ... "Da steht tatsaechlich einer!". Der Analyzer konnte aber nicht anzeigen, ob es Marlboro oder Camel Filter war :-)

Gruesse, Joerg

Vor vier Jahren oder so.

Ich kann nur immer wieder sagen, dass es im Windows Boot funktionierte, in der VM aber nicht. Mit dem Ergebnis, dass ich den Rechner die ganze Messzeit im Windows-Boot lassen musste und dort dann auch die Mess-Doku schreiben musste.

Ja, bei einiger meiner sehr alten SW muss es 32-bit sein. PoL ist eine schoene Sache. Da laeuft sogar Eagle sauber drin und man kann auf die Art Dependency Hell umschiffen.

Am 21.07.26 um 22:53 schrieb Marte Schwarz:

Ich habe $DAMALS einen der ersten DG8SAQ-Networkanalyzer gekauft, noch als Kit zum Selberlöten. Der war mit Virtual Box nicht wirklich betreibbar. Zu viele Sweeps sind hängengeblieben. Das hat sich augenblicklich gegeben als ich die Maschine nach VMware exportiert habe. Seitdem kein Blick zurück, auch wenn seit dem Verkauf von VMware an Broadcom Ende letzten Jahres eine gewisse Kundenfeindlichkeit Einzug gehalten hat.

Ich habe mal einen LT2500-32 ADC mit 1 MSPS an einem Beaglebone Black betrieben, ohne dass samples verloren gingen.

Auf dem BBB lief ein Debian für das Netzwerk/Socket-Interface, ein GPIB-artiger Kommandointerpreter und FFTW, the fastest FFT in the west.

Der TI-Sitara-SOC hat ausser dem ARM für Linux noch einen 200 MHz RISC der mit dem ARM über ein großes DualPortRam gekoppelt ist. Der kennt nicht mal Interrupts, aber er kann I/O mit 5 ns Zeitauflösung.

Das Platinchen im Hintergrund ist der ADC, zusammen mit ein paar LT3042 / LT3095? Spannungsreglern und einem Differenz-ADC-Treiber. Der ADC kann 100 MHz SPI.

In Empfangsrichtung formt der Xilinx Coolrunner2 das SPI wenigstens auf byte-breit um. Der 200 MHz Risc kann das einfach so wegfressen und in sein DualPortRam zur Linux-Seite stopfen. Der RISC wird auch in C programmiert. i++ kostet genau vorhersagbare 5 ns.

Gruß, Gerhard.

Jörg, was macht das Moppedd???

USB war allerdings nie für harte Echtzeitanforderungen gebaut und erfüllt diese auch nicht.

Grüße Marc

Den Traum musste ich aufgeben :-(

Nachdem ich probeweise versucht habe, eine hingelegte Yamaha WR250R hochzustemmen, rastete meine untere Wirbelsaeule voll aus. Das endete in der Notaufnahme und es sind Dauerschaeden entstanden. Die Kontrolle des linken Oberschenkels ist nun nicht mehr so gut und da sich das in sieben Monaten nicht gebessert hat, wird es wohl permanent sein. Getting older ... Bei Mountain Bike Fahrten muss ich jetzt aufpassen, dass ich nicht in Situationen komme, wo ich mich links irgendwo abstemmen muss. Jedenfalls nicht, wenn es bei einem potenziellen Sturz in eine Schlucht gehen koennte :-)

Suse hat im Universum der Linux-Distributionen eine eigenartige Stellung. Die Hauptvariante ist das Hauptprodukt eines börsennotierten Unternehmens mit immerhin 700 Mio USD Umsatz. Entsprechend greift auf der Ebene der Distribution die bei Großunternehmen übliche Dynamik von Wachstum und Shareholder-Value.

Nicht wirklich. Sollten sich die Hauptentwickler einer der größeren Distros überraschend zurückziehen, dann werden andere Entwickler wahrscheinlich schneller einspringen als Du von dem Rückzug mitbekommen hast. Wenn die ursprünglichen Maintainer die Weiterabe der Fackel verweigern, dann ist ein Fork nicht nur rechtlich und technisch möglich, sondern wahrscheinlich. Für Dich bedeutet der Umstieg auf den Fork dann lediglich einen Namenswechsl. Die Funktionen sind erstmal exakt gleich.

Diese Aussichten beziehen sich ausdrücklich auf die größeren, populären Distros. Bei Mini-Projekten mit nur wenigen Anwendern sieht es anders aus. Aber niemand zwingt Dich, eine dieser Nischen-Distros auf Deiner Hardware zu installieren.

---<)kaimartin(>---

S. auch die causa "Open Office" vs. "Libre Office". KiCad vs. EAGLE ist vielleicht kein so ganz treffender Vergleich, aber ein gutes Beispiel dafür, was passiert, wenn ein Forschungskonsortium (hier das CERN) etwas Geld in die Hand nimmt und Open-Source-Produkte fördert. Könnte man in Deutschlands Behörden auch tun, anstatt nur über "digitale Souveränität" zu schwadronieren.

Die Kontroverse um Audacity...

Für Helmut und die anderen Fanboys, die behaupten, Windows sei alternativlos und Linux-Betriebssysteme die Pest, bedeutet das rein gar nichts. Die wollen einfach ein seit Jahrzehnten kultiviertes Vorurteil am virtuellen Stammtisch für alte Herren weiter verbreiten. Das ist schon OK, aber bei Berichten über "schlimme Erfahrungen mit MS" kommt mir dann doch ein kleiner Lacher aus.

Volker

Und wenn bei der kommerzielle Konkurrenz nicht mehr wirklich entwickelt wird, sondern Hans-im-Glück gespielt wird. Konkret wandelte sich Eagle vom Hauptprodukt des Inhaber-geführten Unternehmens CADsoft über den Zwischenwirt Farnell in eine nicht mehr einzeln erhältliche Komponente eines großen CAD-Anbieters (Autodesk). Parallel wandelte sich das Geschäftsmodell von dauerhaft verkauftem Programm auf physikalischem, Datenträger zu im Jahrestakt ablaufender Nutzungslizenz und der Notwendigkeit sich alle zwei Wochen beim Lizenzserver zu "melden".

Und dann sollten sie nicht beim ersten Gegenwind alles wieder rückgänig machen. Abschreckendes Beispiel dazu ist LiMux. München wäre jetzt fein raus, wenn sie nicht 2020 den Rückwärtsgang eingelegt hätten.

Was ich so lese, ist 3.0.2 die letzte Version vor der Etablierung von Telemetrie.

Ich persönlich nutze für die wenigen Audiobearbeitungen, diue ich so mache tenacity. Das ist das Projekt, das das Forkspiel gewonnen hat. Das wird aktiv weiterentwickelt - ablesbar an den letzten Änderungen im Codeberg- Repo. Die anderen Abspaltungen sind wohl nach und nach verkümmmert.

Ein kleiner Nachteil ist, dass es noch kein Debian-Paket gibt. Stattdessen muss man sebst kompilieren. Das hat bei mir recht reibungslos funktioniert. In der Build-Anleitung gab es einen apt-get-Aufruf mit allen von Ausdacity gebrauchten Abhängigkeiten. Danach lief cmake ohne viel Gemecker durch. Die Anwendung selbst macht einen moderenen, sauberen Eindruck.

Ein anderes Beispiel für erfolgreiche Forks ist gogs zu gitea zu forgejo. Gogs war/ist ein Ein-Mann-Projekt, bei dem der eine Mann vom Erfolg überollt wurde. Er kam einfach nicht mehr wirklich mit dem Review von Merge-Requests nach. Als Reaktion haben andere Entwickler eine Art Testversion aufgesetzt. Das entwickelte sich schnell zu einem echten Fork. Sechs Jahre später haben sich dann die Gründer und Inhaber der Namensrechte an "gitea" so weit vom Open-Source-Gedanken entfernt, dass eine Gruppe von Entwicklern koordiniert gegangen sind und mit forgejo ihr eigenes Projekt auf Codeberg aufgemacht haben. Durch die Subtilitäten der beteiligten Lizenzen kann forgejo zwar Dinge von gitea übernehmen. Der umgekehrte Weg ist aber versperrt. Forgejo setzt auf GPL3.

---<)kaimartin(>---

Am 01.09.26 um 03:49 schrieb Kai-Martin Knaak:

leider war das eine politische Selbstsabotage (Entscheidung), von einem MS-Fan aus der spd.

peter

Man sollte bei solchen Entscheidungen nicht ganz ausschließen dass irgendwo Gegenleistungen im Spiel waren.

/ralph