staging.inyokaproject.org

Ja, hallo liebe Brackets-Baustellen-Beobachter 😉

Ich habe mich inzwischen nochmals ein wenig in das Thema Brackets für Linux "eingearbeitet".

Gegenwärtig ist der Stand der folgende:

Beide Installations-Varianten, also via Snap- bzw. Debian-Paket, installieren die letzte verfügbare Linux-Version:

Release 1.14 build 1.14.1-17752 (release-1.14.1 959fed135) build timestamp: Thu Nov 28 2019 08:58:11 GMT+0000

Diese Version krankt, nebst der libcurl3-Abhängigkeit, welche ich ja mit meinem Script bereits gelöst habe, an nicht mehr gültigen URL-Einträgen für die Erweiterungen in der config.json.

Ich muss also mein Script aktualisieren, damit es im entpackten Debian-Paket nebst dem libcurl-Eintrag in der Paket-Konfiguration auch noch die gegenwärtig Korrekten URLs für die Erweiterungen in der config.json anpasst.

Dies funktioniert natürlich bei der Debian-Version einfacher, da diese, im Gegensatz zur Snap-Version, im Normalen Dateisystem mit Lese- und Schreibrechten installiert wird, während im Fall von Snap ein nur-Lese FS zum Einsatz kommt, was dann noch mehr "Turnerei" nach sich zieht.

In meiner Ubuntu 20.04 Test-VM läuft Brackets 1.14.1 bereits wieder mit korrekt funktionierender Erweiterungs-Verwaltung (Habe testhalber erfolgreich die Vimderbar-Erweiterung installiert).

Ich schätze, das ich die Anpassungen (inkl. Baustellen-Anleitung) im Verlauf dieser Woche erledigen kann (nicht weil ich Brackets gross nutze, sondern aus der Motivation heraus, was nicht (mehr) laufendes wieder zum Laufen zu bringen 😉

Gruss, kmu-net.ch

Hallo,

ja, aber warum willst du ein Programm, dass selbst gem. Hersteller EOL ist, künstlich am Leben erhalten? Das Programm bekommt nichts mehr, auch keine Sicherheitspatches. Will man doch gar nicht mehr benutzen. Zumal es reichlich alternativen gibt.

Gruß, noisefloor

noisefloor

Hallo & danke für die Rückmeldung. Da hast du natürlich grundsätzlich absolut recht. Ich habe ja auch schon mehrfach erwähnt, dass ich mit vscode und nicht mit Brackets arbeite. Spätestens seit Nadella CEO bei den Redmondern ist, hat sich deren Haltung gegenüber Unixoidem & quelloffener Saftwär ja erfreulich geändert und man profitiert enorm von den unzähligen gesponserten Mannsstunden, welche z.B. eben in vscode stecken. (Dass sie sich github einverleibt haben ist dann wieder 'ne andere Sache, und wie lange man vscode noch ausserhalb der Azure Cloud betreiben kann, auch - anderseits profitieren sie, wenn sie Entwickler kriegen, welche mit der IDE bereits vertraut sind, daher werden sie von ausschliesslichem Saftwär äs äi Sörvice wohl vorerst auch noch Abstand nehmen –> https://vscode.dev/)

Anderseits bin ich der Meinung, dass man, wenn man schon für Brackets ein Wiki zur Verfügung stellt, es dessen Kernaufgabe sein sollte, zu erläutern, wie man die Anwendung voll funktionstüchtig betreiben kann, gerade bei legacy-Anwendungen. Man soll natürlich auch darauf hinweisen, dass z.B. das Brackets-Erweiterungs-Repository gegenwärtig via http statt https ausliefert. Wer dann trotzdem ums Verr*** dennoch damit arbeiten möchte, aus welchen Gründen auch immer, sollte zumindest selber darüber entscheiden können.

Zumindest bis zum Erscheinen des 2-er Zweigs von Brackets für Linux ist der 1-er Zweig für Brackets-Anhänger wohl der Way to Go, zumal ich dann auch bezweifle, wie viele Erweiterungen von Anbeginn weg mit der 2-er Version laufen werden. Da die Installations-Anleitung wohl aus den Nähten zu platzen droht, könnte man sie ja auch in einen eigenen Artikel auslagern, wie wir das z.B. bereits bei Alte Kernel entfernen getan haben. Mittelfristig wird der Artikel wohl ohnehin ins Archiv wandern. Doch auch & gerade dort haben alle, die das wollen, noch immer die Möglichkeit, damit herum zu frickeln.

Ich gehöre nicht zu jener Spezies, im Gegenteil, ich bin eher derjenige, welcher inzwischen JavaScript via node bzw. deno einem klassischen Shell-Script vorzieht, aber die shell ist halt stets bereits installiert, die beiden erst genannten (bisher noch) nicht.

Wie auch immer, ich melde mich wieder, wenn ich die Anpassungen erledigt habe - bei meinem Script auf github werde ich dies ohnehin tun, da von letzterem auch ausserhalb des deutsch-sprachigen Raums bzw. ubuntuusers.de Gebrauch gemacht wird.

Gruss, kmu-net.ch

PS: Apropos legacy - es soll gar noch Leute geben, welche noch mit M$ Frontpage arbeiten 😉

Ich habe fertig...

Mein Script auf github erfuhr weitere 'Textverarbeitung' (sed 😉 ), somit sind auch die URLs des Erweiterungs-Repos wieder 'aktuell'.

Getestet in vanilla ubuntu 20.04.4 LTS VM, auch die Deinstallation via atp-get purge.

Baustellenartikel ist entsprechend aktualisiert. Bitte um Prüfung & hoffentlich baldiger Entlassung aus der Baustelle, damit ich mich wieder konkreten Dingen zuwenden kann 😉

Ich habe mich übrigens gewundert, dass unter Webeditoren vscode nicht gelistet ist. Meiner Meinung nach derzeit eines der fortgeschrittensten Teile, welche (noch ?) für lau zu haben sind, wenngleich von M$, aber manchmal ist halt ein wenig Pragmatismus angesagt 😉

Wie auch immer, Gruss & schö' WE,

kmu-net.ch

Hallo,

Anderseits bin ich der Meinung, dass man, wenn man schon für Brackets ein Wiki zur Verfügung stellt, es dessen Kernaufgabe sein sollte, zu erläutern, wie man die Anwendung voll funktionstüchtig betreiben kann, gerade bei legacy-Anwendungen.

Nein, sehe ich absolut nicht. Es braucht keinen Wikiartikel, der ein totes Pferd reitet, dass nur noch mir Workarounds und Hacks am Leben erhalten wird.

Wenn jetzt ein Programm so geil und trotz eingestelltem Support einzigartig wäre könnte man ggf. drüber reden - ist nun mal bei Editoren / IDEs aber definitiv nicht der Fall.

Was ist _persönlich_ an deiner Einstellung noch völlig n.i.O. finde ist, dass du selber nach eigenen Angaben VSCode nutzt, aber gleichzeitig das tote Pferd ohne Support Brackets anderen in Form des Wikiartikels schmackhaft machen willst. Das ist in meinen Augen ungefähr so wie Wein trinken und abgestandenes, möglicherweise kontaminiertes Wasser predigen.

Gruß, noisefloor

@noisefloor

Ja hallo & danke für die Rückmeldung.

Da prallen offensichtlich zwei Denkweisen aufeinander. Ich habe nie jemandem Brackets empfohlen. Allerdings bin ich der Ansicht, dass ein jeder die Wahl haben sollte, womit er arbeiten möchte.

Zum Thema legacy Software wurden schon Bände geschrieben. Software, deren Versteher in Rente gehen bzw. wegsterben. Im globalen Zahlungsverkehr, in Maschinensteuerungen etc. pp., wollt ihr gar nicht so genau wissen...

Aber egal, du bist der Chef hier, ich bin dann mal weg...

So long,

kmu-net.ch

Also, so wie ich das auf Github sehe, wird das Projekt ja aktiv als Fork vom Adobe-Brackets von der Community gepflegt. Soweit alles gut.

Allerdings: Es gibt wohl leider keine Linuxversion mehr:
https://github.com/brackets-cont/brackets/commit/242295b5231ad352b4919ac50429c98fc02bbc90

Sollte es eine Linuxversion wieder geben oder eine praktikable Lösung geben, den Editor trotzdem unter Ubuntu zu installieren und zu nutzen, kann der Artikel gerne online gehen.

kmu-net.ch schrieb:

Ich habe mich übrigens gewundert, dass unter Webeditoren vscode nicht gelistet ist. Meiner Meinung nach derzeit eines der fortgeschrittensten Teile, welche (noch ?) für lau zu haben sind, wenngleich von M$, aber manchmal ist halt ein wenig Pragmatismus angesagt 😉

Es gibt sogar einen eigenen Wikiartikel hier, schon seit 2017. 😉 Ist jetzt auch unter Webeditoren gelistet, danke für den Hinweis.

Ich wäre hier definitiv für Archiv.

@karzer

Das sehe ich auch so. Für diejenigen, welche Brackets weiterhin unter Linux nutzen möchten, habe ich einen Lösungsweg aufgezeigt. Dieser ist hier: https://github.com/andihafner/adobe-brackets-legacy4linux abrufbar. Damit ist die Angelegenheit für mich erledigt und es liegt mir fern, in dieser Sache weiteren Aufwand zu betreiben 😕

Der Artikel ist archiviert.